idnits 2.17.1 draft-hoffman-ikev2bis-03.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 5895. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 5906. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 5913. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 5919. 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. 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. -- 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 (February 25, 2008) is 5905 days in the past. Is this intentional? 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 2091, but not defined == Missing Reference: 'KEi' is mentioned on line 5570, but not defined == Missing Reference: 'KEr' is mentioned on line 5572, but not defined == Missing Reference: 'CP' is mentioned on line 717, but not defined -- Looks like a reference, but probably isn't: '0' on line 3652 -- Looks like a reference, but probably isn't: '1' on line 3653 == Missing Reference: 'IDr' is mentioned on line 5521, 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 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) -- Obsolete informational reference (is this intentional?): RFC 3513 (ref. 'IPV6ADDR') (Obsoleted by RFC 4291) -- Obsolete informational reference (is this intentional?): RFC 2408 (ref. 'ISAKMP') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2251 (ref. 'LDAP') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) -- 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 2486 (ref. 'NAI') (Obsoleted by RFC 4282) -- Obsolete informational reference (is this intentional?): RFC 2138 (ref. 'RADIUS') (Obsoleted by RFC 2865) Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 24 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 P. Eronen 7 Expires: August 28, 2008 Nokia 8 February 25, 2008 10 Internet Key Exchange Protocol: IKEv2 11 draft-hoffman-ikev2bis-03 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 28, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This document describes version 2 of the Internet Key Exchange (IKE) 45 protocol. It is a restatement of RFC 4306, and includes all of the 46 clarifications from RFC 4718. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 51 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 6 52 1.1.1. Security Gateway to Security Gateway Tunnel . . . . . 6 53 1.1.2. Endpoint-to-Endpoint Transport . . . . . . . . . . . 7 54 1.1.3. Endpoint to Security Gateway Tunnel . . . . . . . . . 8 55 1.1.4. Other Scenarios . . . . . . . . . . . . . . . . . . . 8 56 1.2. The Initial Exchanges . . . . . . . . . . . . . . . . . . 9 57 1.3. The CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 11 58 1.3.1. Creating New CHILD_SAs with the CREATE_CHILD_SA 59 Exchange . . . . . . . . . . . . . . . . . . . . . . 13 60 1.3.2. Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange . 14 61 1.3.3. Rekeying CHILD_SAs with the CREATE_CHILD_SA 62 Exchange . . . . . . . . . . . . . . . . . . . . . . 14 63 1.4. The INFORMATIONAL Exchange . . . . . . . . . . . . . . . 15 64 1.5. Informational Messages outside of an IKE_SA . . . . . . . 17 65 1.6. Requirements Terminology . . . . . . . . . . . . . . . . 17 66 1.7. Differences Between RFC 4306 and This Document . . . . . 18 67 2. IKE Protocol Details and Variations . . . . . . . . . . . . . 19 68 2.1. Use of Retransmission Timers . . . . . . . . . . . . . . 20 69 2.2. Use of Sequence Numbers for Message ID . . . . . . . . . 21 70 2.3. Window Size for Overlapping Requests . . . . . . . . . . 21 71 2.4. State Synchronization and Connection Timeouts . . . . . . 23 72 2.5. Version Numbers and Forward Compatibility . . . . . . . . 25 73 2.6. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 27 74 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . 29 75 2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 30 76 2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 31 77 2.8.1. Simultaneous CHILD_SA rekeying . . . . . . . . . . . 33 78 2.8.2. Rekeying the IKE_SA Versus Reauthentication . . . . . 35 79 2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 36 80 2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 38 81 2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 39 82 2.11. Address and Port Agility . . . . . . . . . . . . . . . . 39 83 2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 40 84 2.13. Generating Keying Material . . . . . . . . . . . . . . . 40 85 2.14. Generating Keying Material for the IKE_SA . . . . . . . . 42 86 2.15. Authentication of the IKE_SA . . . . . . . . . . . . . . 42 87 2.16. Extensible Authentication Protocol Methods . . . . . . . 44 88 2.17. Generating Keying Material for CHILD_SAs . . . . . . . . 46 89 2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA Exchange . . . . 47 90 2.19. Requesting an Internal Address on a Remote Network . . . 48 91 2.19.1. Configuration Payloads . . . . . . . . . . . . . . . 49 92 2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 51 93 2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 51 94 2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 52 95 2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 54 96 2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 57 97 3. Header and Payload Formats . . . . . . . . . . . . . . . . . 57 98 3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 58 99 3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 61 100 3.3. Security Association Payload . . . . . . . . . . . . . . 63 101 3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 65 102 3.3.2. Transform Substructure . . . . . . . . . . . . . . . 66 103 3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 69 104 3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 70 105 3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 71 106 3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 73 107 3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 73 108 3.5. Identification Payloads . . . . . . . . . . . . . . . . . 74 109 3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 77 110 3.7. Certificate Request Payload . . . . . . . . . . . . . . . 79 111 3.8. Authentication Payload . . . . . . . . . . . . . . . . . 81 112 3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 82 113 3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 83 114 3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 84 115 3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 87 116 3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 89 117 3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 90 118 3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 91 119 3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 93 120 3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 95 121 3.15.1. Configuration Attributes . . . . . . . . . . . . . . 96 122 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 99 123 3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 101 124 3.15.4. Address Assignment Failures . . . . . . . . . . . . . 101 125 3.16. Extensible Authentication Protocol (EAP) Payload . . . . 102 126 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 104 127 5. Security Considerations . . . . . . . . . . . . . . . . . . . 106 128 5.1. Traffic selector authorization . . . . . . . . . . . . . 108 129 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 109 130 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 110 131 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 110 132 8.1. Normative References . . . . . . . . . . . . . . . . . . 110 133 8.2. Informative References . . . . . . . . . . . . . . . . . 112 134 Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 115 135 Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 117 136 B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 117 137 B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 117 138 Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 118 139 C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 118 140 C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 119 141 C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 120 142 C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying 143 CHILD_SAs . . . . . . . . . . . . . . . . . . . . . . . . 121 145 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA . . . . 121 146 C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 121 147 Appendix D. Changes Between Internet Draft Versions . . . . . . 121 148 D.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 121 149 D.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 122 150 D.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 124 151 D.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 124 152 D.5. Changes from draft -02 to draft -03 . . . . . . . . . . . 125 153 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 127 154 Intellectual Property and Copyright Statements . . . . . . . . . 129 156 1. Introduction 158 {{ An introduction to the differences between RFC 4306 [IKEV2] and 159 this document is given at the end of Section 1. It is put there 160 (instead of here) to preserve the section numbering of RFC 4306. }} 162 IP Security (IPsec) provides confidentiality, data integrity, access 163 control, and data source authentication to IP datagrams. These 164 services are provided by maintaining shared state between the source 165 and the sink of an IP datagram. This state defines, among other 166 things, the specific services provided to the datagram, which 167 cryptographic algorithms will be used to provide the services, and 168 the keys used as input to the cryptographic algorithms. 170 Establishing this shared state in a manual fashion does not scale 171 well. Therefore, a protocol to establish this state dynamically is 172 needed. This memo describes such a protocol -- the Internet Key 173 Exchange (IKE). Version 1 of IKE was defined in RFCs 2407 [DOI], 174 2408 [ISAKMP], and 2409 [IKEV1]. IKEv2 was defined in [IKEV2] and 175 clarified in [Clarif]. This single document is intended to replace 176 all of those RFCs. 178 IKE performs mutual authentication between two parties and 179 establishes an IKE security association (SA) that includes shared 180 secret information that can be used to efficiently establish SAs for 181 Encapsulating Security Payload (ESP) [ESP] and/or Authentication 182 Header (AH) [AH] and a set of cryptographic algorithms to be used by 183 the SAs to protect the traffic that they carry. In this document, 184 the term "suite" or "cryptographic suite" refers to a complete set of 185 algorithms used to protect an SA. An initiator proposes one or more 186 suites by listing supported algorithms that can be combined into 187 suites in a mix-and-match fashion. IKE can also negotiate use of IP 188 Compression (IPComp) [IPCOMP] in connection with an ESP and/or AH SA. 189 We call the IKE SA an "IKE_SA". The SAs for ESP and/or AH that get 190 set up through that IKE_SA we call "CHILD_SAs". 192 All IKE communications consist of pairs of messages: a request and a 193 response. The pair is called an "exchange". We call the first 194 messages establishing an IKE_SA IKE_SA_INIT and IKE_AUTH exchanges 195 and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL 196 exchanges. In the common case, there is a single IKE_SA_INIT 197 exchange and a single IKE_AUTH exchange (a total of four messages) to 198 establish the IKE_SA and the first CHILD_SA. In exceptional cases, 199 there may be more than one of each of these exchanges. In all cases, 200 all IKE_SA_INIT exchanges MUST complete before any other exchange 201 type, then all IKE_AUTH exchanges MUST complete, and following that 202 any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur 203 in any order. In some scenarios, only a single CHILD_SA is needed 204 between the IPsec endpoints, and therefore there would be no 205 additional exchanges. Subsequent exchanges MAY be used to establish 206 additional CHILD_SAs between the same authenticated pair of endpoints 207 and to perform housekeeping functions. 209 IKE message flow always consists of a request followed by a response. 210 It is the responsibility of the requester to ensure reliability. If 211 the response is not received within a timeout interval, the requester 212 needs to retransmit the request (or abandon the connection). 214 The first request/response of an IKE session (IKE_SA_INIT) negotiates 215 security parameters for the IKE_SA, sends nonces, and sends Diffie- 216 Hellman values. 218 The second request/response (IKE_AUTH) transmits identities, proves 219 knowledge of the secrets corresponding to the two identities, and 220 sets up an SA for the first (and often only) AH and/or ESP CHILD_SA. 222 The types of subsequent exchanges are CREATE_CHILD_SA (which creates 223 a CHILD_SA) and INFORMATIONAL (which deletes an SA, reports error 224 conditions, or does other housekeeping). Every request requires a 225 response. An INFORMATIONAL request with no payloads (other than the 226 empty Encrypted payload required by the syntax) is commonly used as a 227 check for liveness. These subsequent exchanges cannot be used until 228 the initial exchanges have completed. 230 In the description that follows, we assume that no errors occur. 231 Modifications to the flow should errors occur are described in 232 Section 2.21. 234 1.1. Usage Scenarios 236 IKE is expected to be used to negotiate ESP and/or AH SAs in a number 237 of different scenarios, each with its own special requirements. 239 1.1.1. Security Gateway to Security Gateway Tunnel 241 +-+-+-+-+-+ +-+-+-+-+-+ 242 | | IPsec | | 243 Protected |Tunnel | tunnel |Tunnel | Protected 244 Subnet <-->|Endpoint |<---------->|Endpoint |<--> Subnet 245 | | | | 246 +-+-+-+-+-+ +-+-+-+-+-+ 248 Figure 1: Security Gateway to Security Gateway Tunnel 250 In this scenario, neither endpoint of the IP connection implements 251 IPsec, but network nodes between them protect traffic for part of the 252 way. Protection is transparent to the endpoints, and depends on 253 ordinary routing to send packets through the tunnel endpoints for 254 processing. Each endpoint would announce the set of addresses 255 "behind" it, and packets would be sent in tunnel mode where the inner 256 IP header would contain the IP addresses of the actual endpoints. 258 1.1.2. Endpoint-to-Endpoint Transport 260 +-+-+-+-+-+ +-+-+-+-+-+ 261 | | IPsec transport | | 262 |Protected| or tunnel mode SA |Protected| 263 |Endpoint |<---------------------------------------->|Endpoint | 264 | | | | 265 +-+-+-+-+-+ +-+-+-+-+-+ 267 Figure 2: Endpoint to Endpoint 269 In this scenario, both endpoints of the IP connection implement 270 IPsec, as required of hosts in [IPSECARCH]. Transport mode will 271 commonly be used with no inner IP header. If there is an inner IP 272 header, the inner addresses will be the same as the outer addresses. 273 A single pair of addresses will be negotiated for packets to be 274 protected by this SA. These endpoints MAY implement application 275 layer access controls based on the IPsec authenticated identities of 276 the participants. This scenario enables the end-to-end security that 277 has been a guiding principle for the Internet since [ARCHPRINC], 278 [TRANSPARENCY], and a method of limiting the inherent problems with 279 complexity in networks noted by [ARCHGUIDEPHIL]. Although this 280 scenario may not be fully applicable to the IPv4 Internet, it has 281 been deployed successfully in specific scenarios within intranets 282 using IKEv1. It should be more broadly enabled during the transition 283 to IPv6 and with the adoption of IKEv2. 285 It is possible in this scenario that one or both of the protected 286 endpoints will be behind a network address translation (NAT) node, in 287 which case the tunneled packets will have to be UDP encapsulated so 288 that port numbers in the UDP headers can be used to identify 289 individual endpoints "behind" the NAT (see Section 2.23). 291 1.1.3. Endpoint to Security Gateway Tunnel 293 +-+-+-+-+-+ +-+-+-+-+-+ 294 | | IPsec | | Protected 295 |Protected| tunnel |Tunnel | Subnet 296 |Endpoint |<------------------------>|Endpoint |<--- and/or 297 | | | | Internet 298 +-+-+-+-+-+ +-+-+-+-+-+ 300 Figure 3: Endpoint to Security Gateway Tunnel 302 In this scenario, a protected endpoint (typically a portable roaming 303 computer) connects back to its corporate network through an IPsec- 304 protected tunnel. It might use this tunnel only to access 305 information on the corporate network, or it might tunnel all of its 306 traffic back through the corporate network in order to take advantage 307 of protection provided by a corporate firewall against Internet-based 308 attacks. In either case, the protected endpoint will want an IP 309 address associated with the security gateway so that packets returned 310 to it will go to the security gateway and be tunneled back. This IP 311 address may be static or may be dynamically allocated by the security 312 gateway. {{ Clarif-6.1 }} In support of the latter case, IKEv2 313 includes a mechanism (namely, configuration payloads) for the 314 initiator to request an IP address owned by the security gateway for 315 use for the duration of its SA. 317 In this scenario, packets will use tunnel mode. On each packet from 318 the protected endpoint, the outer IP header will contain the source 319 IP address associated with its current location (i.e., the address 320 that will get traffic routed to the endpoint directly), while the 321 inner IP header will contain the source IP address assigned by the 322 security gateway (i.e., the address that will get traffic routed to 323 the security gateway for forwarding to the endpoint). The outer 324 destination address will always be that of the security gateway, 325 while the inner destination address will be the ultimate destination 326 for the packet. 328 In this scenario, it is possible that the protected endpoint will be 329 behind a NAT. In that case, the IP address as seen by the security 330 gateway will not be the same as the IP address sent by the protected 331 endpoint, and packets will have to be UDP encapsulated in order to be 332 routed properly. 334 1.1.4. Other Scenarios 336 Other scenarios are possible, as are nested combinations of the 337 above. One notable example combines aspects of 1.1.1 and 1.1.3. A 338 subnet may make all external accesses through a remote security 339 gateway using an IPsec tunnel, where the addresses on the subnet are 340 routed to the security gateway by the rest of the Internet. An 341 example would be someone's home network being virtually on the 342 Internet with static IP addresses even though connectivity is 343 provided by an ISP that assigns a single dynamically assigned IP 344 address to the user's security gateway (where the static IP addresses 345 and an IPsec relay are provided by a third party located elsewhere). 347 1.2. The Initial Exchanges 349 Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH 350 exchanges (known in IKEv1 as Phase 1). These initial exchanges 351 normally consist of four messages, though in some scenarios that 352 number can grow. All communications using IKE consist of request/ 353 response pairs. We'll describe the base exchange first, followed by 354 variations. The first pair of messages (IKE_SA_INIT) negotiate 355 cryptographic algorithms, exchange nonces, and do a Diffie-Hellman 356 exchange [DH]. 358 The second pair of messages (IKE_AUTH) authenticate the previous 359 messages, exchange identities and certificates, and establish the 360 first CHILD_SA. Parts of these messages are encrypted and integrity 361 protected with keys established through the IKE_SA_INIT exchange, so 362 the identities are hidden from eavesdroppers and all fields in all 363 the messages are authenticated. 365 In the following descriptions, the payloads contained in the message 366 are indicated by names as listed below. 368 Notation Payload 369 ----------------------------------------- 370 AUTH Authentication 371 CERT Certificate 372 CERTREQ Certificate Request 373 CP Configuration 374 D Delete 375 E Encrypted 376 EAP Extensible Authentication 377 HDR IKE Header 378 IDi Identification - Initiator 379 IDr Identification - Responder 380 KE Key Exchange 381 Ni, Nr Nonce 382 N Notify 383 SA Security Association 384 TSi Traffic Selector - Initiator 385 TSr Traffic Selector - Responder 386 V Vendor ID 387 The details of the contents of each payload are described in section 388 3. Payloads that may optionally appear will be shown in brackets, 389 such as [CERTREQ], indicate that optionally a certificate request 390 payload can be included. 392 The initial exchanges are as follows: 394 Initiator Responder 395 ------------------------------------------------------------------- 396 HDR, SAi1, KEi, Ni --> 398 HDR contains the Security Parameter Indexes (SPIs), version numbers, 399 and flags of various sorts. The SAi1 payload states the 400 cryptographic algorithms the initiator supports for the IKE_SA. The 401 KE payload sends the initiator's Diffie-Hellman value. Ni is the 402 initiator's nonce. 404 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 406 The responder chooses a cryptographic suite from the initiator's 407 offered choices and expresses that choice in the SAr1 payload, 408 completes the Diffie-Hellman exchange with the KEr payload, and sends 409 its nonce in the Nr payload. 411 At this point in the negotiation, each party can generate SKEYSEED, 412 from which all keys are derived for that IKE_SA. All but the headers 413 of all the messages that follow are encrypted and integrity 414 protected. The keys used for the encryption and integrity protection 415 are derived from SKEYSEED and are known as SK_e (encryption) and SK_a 416 (authentication, a.k.a. integrity protection). A separate SK_e and 417 SK_a is computed for each direction. In addition to the keys SK_e 418 and SK_a derived from the DH value for protection of the IKE_SA, 419 another quantity SK_d is derived and used for derivation of further 420 keying material for CHILD_SAs. The notation SK { ... } indicates 421 that these payloads are encrypted and integrity protected using that 422 direction's SK_e and SK_a. 424 HDR, SK {IDi, [CERT,] [CERTREQ,] 425 [IDr,] AUTH, SAi2, 426 TSi, TSr} --> 428 The initiator asserts its identity with the IDi payload, proves 429 knowledge of the secret corresponding to IDi and integrity protects 430 the contents of the first message using the AUTH payload (see 431 Section 2.15). It might also send its certificate(s) in CERT 432 payload(s) and a list of its trust anchors in CERTREQ payload(s). If 433 any CERT payloads are included, the first certificate provided MUST 434 contain the public key used to verify the AUTH field. The optional 435 payload IDr enables the initiator to specify which of the responder's 436 identities it wants to talk to. This is useful when the machine on 437 which the responder is running is hosting multiple identities at the 438 same IP address. The initiator begins negotiation of a CHILD_SA 439 using the SAi2 payload. The final fields (starting with SAi2) are 440 described in the description of the CREATE_CHILD_SA exchange. 442 <-- HDR, SK {IDr, [CERT,] AUTH, 443 SAr2, TSi, TSr} 445 The responder asserts its identity with the IDr payload, optionally 446 sends one or more certificates (again with the certificate containing 447 the public key used to verify AUTH listed first), authenticates its 448 identity and protects the integrity of the second message with the 449 AUTH payload, and completes negotiation of a CHILD_SA with the 450 additional fields described below in the CREATE_CHILD_SA exchange. 452 The recipients of messages 3 and 4 MUST verify that all signatures 453 and MACs are computed correctly and that the names in the ID payloads 454 correspond to the keys used to generate the AUTH payload. 456 {{ Clarif-4.2}} If creating the CHILD_SA during the IKE_AUTH exchange 457 fails for some reason, the IKE_SA is still created as usual. The 458 list of responses in the IKE_AUTH exchange that do not prevent an 459 IKE_SA from being set up include at least the following: 460 NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, 461 INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED. 463 {{ Clarif-4.3 }} Note that IKE_AUTH messages do not contain KEi/KEr 464 or Ni/Nr payloads. Thus, the SA payloads in the IKE_AUTH exchange 465 cannot contain Transform Type 4 (Diffie-Hellman Group) with any value 466 other than NONE. Implementations SHOULD omit the whole transform 467 substructure instead of sending value NONE. 469 1.3. The CREATE_CHILD_SA Exchange 471 {{ This is a heavy rewrite of most of this section. The major 472 organization changes are described in Clarif-4.1 and Clarif-5.1. }} 474 The CREATE_CHILD_SA exchange is used to create new CHILD_SAs and to 475 rekey both IKE_SAs and CHILD_SAs. This exchange consists of a single 476 request/response pair, and some of its function was referred to as a 477 phase 2 exchange in IKEv1. It MAY be initiated by either end of the 478 IKE_SA after the initial exchanges are completed. 480 All messages following the initial exchange are cryptographically 481 protected using the cryptographic algorithms and keys negotiated in 482 the first two messages of the IKE exchange. These subsequent 483 messages use the syntax of the Encrypted Payload described in 484 Section 3.14. All subsequent messages include an Encrypted Payload, 485 even if they are referred to in the text as "empty". For both 486 messages in the CREATE_CHILD_SA, the message following the header is 487 encrypted and the message including the header is integrity protected 488 using the cryptographic algorithms negotiated for the IKE_SA. 490 The CREATE_CHILD_SA is also used for rekeying IKE_SAs and CHILD_SAs. 491 An SA is rekeyed by creating a new SA and then deleting the old one. 492 This section describes the first part of rekeying, the creation of 493 new SAs; Section 2.8 covers the mechanics of rekeying, including 494 moving traffic from old to new SAs and the deletion of the old SAs. 495 The two sections must be read together to understand the entire 496 process of rekeying. 498 Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this 499 section the term initiator refers to the endpoint initiating this 500 exchange. An implementation MAY refuse all CREATE_CHILD_SA requests 501 within an IKE_SA. 503 The CREATE_CHILD_SA request MAY optionally contain a KE payload for 504 an additional Diffie-Hellman exchange to enable stronger guarantees 505 of forward secrecy for the CHILD_SA. The keying material for the 506 CHILD_SA is a function of SK_d established during the establishment 507 of the IKE_SA, the nonces exchanged during the CREATE_CHILD_SA 508 exchange, and the Diffie-Hellman value (if KE payloads are included 509 in the CREATE_CHILD_SA exchange). 511 If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of 512 the SA offers MUST include the Diffie-Hellman group of the KEi. The 513 Diffie-Hellman group of the KEi MUST be an element of the group the 514 initiator expects the responder to accept (additional Diffie-Hellman 515 groups can be proposed). If the responder selects a proposal using a 516 different Diffie-Hellman group (other than NONE), the responder MUST 517 reject the request and indicate its preferred Diffie-Hellman group in 518 the INVALID_KE_PAYLOAD Notification payload. {{ 3.10.1-17 }} There 519 are two octets of data associated with this notification: the 520 accepted D-H Group number in big endian order. In the case of such a 521 rejection, the CREATE_CHILD_SA exchange fails, and the initiator will 522 probably retry the exchange with a Diffie-Hellman proposal and KEi in 523 the group that the responder gave in the INVALID_KE_PAYLOAD. 525 {{ 3.10.1-35 }} The responder sends a NO_ADDITIONAL_SAS notification 526 to indicate that a CREATE_CHILD_SA request is unacceptable because 527 the responder is unwilling to accept any more CHILD_SAs on this 528 IKE_SA. Some minimal implementations may only accept a single 529 CHILD_SA setup in the context of an initial IKE exchange and reject 530 any subsequent attempts to add more. 532 1.3.1. Creating New CHILD_SAs with the CREATE_CHILD_SA Exchange 534 A CHILD_SA may be created by sending a CREATE_CHILD_SA request. The 535 CREATE_CHILD_SA request for creating a new CHILD_SA is: 537 Initiator Responder 538 ------------------------------------------------------------------- 539 HDR, SK {SA, Ni, [KEi], 540 TSi, TSr} --> 542 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni 543 payload, optionally a Diffie-Hellman value in the KEi payload, and 544 the proposed traffic selectors for the proposed CHILD_SA in the TSi 545 and TSr payloads. 547 The CREATE_CHILD_SA response for creating a new CHILD_SA is: 549 <-- HDR, SK {SA, Nr, [KEr], 550 TSi, TSr} 552 The responder replies (using the same Message ID to respond) with the 553 accepted offer in an SA payload, and a Diffie-Hellman value in the 554 KEr payload if KEi was included in the request and the selected 555 cryptographic suite includes that group. 557 The traffic selectors for traffic to be sent on that SA are specified 558 in the TS payloads in the response, which may be a subset of what the 559 initiator of the CHILD_SA proposed. 561 {{ 3.10.1-16391 }} The USE_TRANSPORT_MODE notification MAY be 562 included in a request message that also includes an SA payload 563 requesting a CHILD_SA. It requests that the CHILD_SA use transport 564 mode rather than tunnel mode for the SA created. If the request is 565 accepted, the response MUST also include a notification of type 566 USE_TRANSPORT_MODE. If the responder declines the request, the 567 CHILD_SA will be established in tunnel mode. If this is unacceptable 568 to the initiator, the initiator MUST delete the SA. Note: Except 569 when using this option to negotiate transport mode, all CHILD_SAs 570 will use tunnel mode. 572 {{ 3.10.1-16394 }} The ESP_TFC_PADDING_NOT_SUPPORTED notification 573 asserts that the sending endpoint will NOT accept packets that 574 contain Traffic Flow Confidentiality (TFC) padding over the CHILD_SA 575 being negotiated. {{ Clarif-4.5 }} If neither endpoint accepts TFC 576 padding, this notification is included in both the request and the 577 response. If this notification is included in only one of the 578 messages, TFC padding can still be sent in the other direction. 580 {{ 3.10.1-16395 }} The NON_FIRST_FRAGMENTS_ALSO notification is used 581 for fragmentation control. See [IPSECARCH] for a fuller explanation. 582 {{ Clarif-4.6 }} Sending non-first fragments is enabled only if 583 NON_FIRST_FRAGMENTS_ALSO notification is included in both the request 584 proposing an SA and the response accepting it. If the peer rejects 585 the proposal of the SA, the peer only omits NON_FIRST_FRAGMENTS_ALSO 586 notification from the response, but does not reject the whole 587 CHILD_SA creation. 589 1.3.2. Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange 591 The CREATE_CHILD_SA request for rekeying an IKE_SA is: 593 Initiator Responder 594 ------------------------------------------------------------------- 595 HDR, SK {SA, Ni, [KEi]} --> 597 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni 598 payload, and a Diffie-Hellman value in the KEi payload. The KEi 599 payload SHOULD be included. New initiator and responder SPIs are 600 supplied in the SPI fields. 602 The CREATE_CHILD_SA response for rekeying an IKE_SA is: 604 <-- HDR, SK {SA, Nr,[KEr]} 606 The responder replies (using the same Message ID to respond) with the 607 accepted offer in an SA payload, and a Diffie-Hellman value in the 608 KEr payload if the selected cryptographic suite includes that group. 610 The new IKE_SA has its message counters set to 0, regardless of what 611 they were in the earlier IKE_SA. The window size starts at 1 for any 612 new IKE_SA. 614 1.3.3. Rekeying CHILD_SAs with the CREATE_CHILD_SA Exchange 616 The CREATE_CHILD_SA request for rekeying a CHILD_SA is: 618 Initiator Responder 619 ------------------------------------------------------------------- 620 HDR, SK {N, SA, Ni, [KEi], 621 TSi, TSr} --> 623 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni 624 payload, optionally a Diffie-Hellman value in the KEi payload, and 625 the proposed traffic selectors for the proposed CHILD_SA in the TSi 626 and TSr payloads. 628 {{ 3.10.1-16393 }} The REKEY_SA notification MUST be included in a 629 CREATE_CHILD_SA exchange if the purpose of the exchange is to replace 630 an existing ESP or AH SA. {{ Clarif-5.4 }} The SA being rekeyed is 631 identified by the SPI field in the Notify payload; this is the SPI 632 the exchange initiator would expect in inbound ESP or AH packets. 633 There is no data associated with this Notify type. 635 The CREATE_CHILD_SA response for rekeying a CHILD_SA is: 637 <-- HDR, SK {SA, Nr, [KEr], 638 Si, TSr} 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 KEi was included in the request and the selected 643 cryptographic suite includes that group. 645 The traffic selectors for traffic to be sent on that SA are specified 646 in the TS payloads in the response, which may be a subset of what the 647 initiator of the CHILD_SA proposed. 649 1.4. The INFORMATIONAL Exchange 651 At various points during the operation of an IKE_SA, peers may desire 652 to convey control messages to each other regarding errors or 653 notifications of certain events. To accomplish this, IKE defines an 654 INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur 655 after the initial exchanges and are cryptographically protected with 656 the negotiated keys. 658 Control messages that pertain to an IKE_SA MUST be sent under that 659 IKE_SA. Control messages that pertain to CHILD_SAs MUST be sent 660 under the protection of the IKE_SA which generated them (or its 661 successor if the IKE_SA was replaced for the purpose of rekeying). 663 Messages in an INFORMATIONAL exchange contain zero or more 664 Notification, Delete, and Configuration payloads. The Recipient of 665 an INFORMATIONAL exchange request MUST send some response (else the 666 Sender will assume the message was lost in the network and will 667 retransmit it). That response MAY be a message with no payloads. 668 The request message in an INFORMATIONAL exchange MAY also contain no 669 payloads. This is the expected way an endpoint can ask the other 670 endpoint to verify that it is alive. 672 {{ Clarif-5.6 }} ESP and AH SAs always exist in pairs, with one SA in 673 each direction. When an SA is closed, both members of the pair MUST 674 be closed (that is, deleted). Each endpoint MUST close its incoming 675 SAs and allow the other endpoint to close the other SA in each pair. 677 To delete an SA, an INFORMATIONAL exchange with one or more delete 678 payloads is sent listing the SPIs (as they would be expected in the 679 headers of inbound packets) of the SAs to be deleted. The recipient 680 MUST close the designated SAs. {{ Clarif-5.7 }} Note that one never 681 sends delete payloads for the two sides of an SA in a single message. 682 If there are many SAs to delete at the same time, one includes delete 683 payloads for in inbound half of each SA pair in your Informational 684 exchange. 686 Normally, the reply in the INFORMATIONAL exchange will contain delete 687 payloads for the paired SAs going in the other direction. There is 688 one exception. If by chance both ends of a set of SAs independently 689 decide to close them, each may send a delete payload and the two 690 requests may cross in the network. If a node receives a delete 691 request for SAs for which it has already issued a delete request, it 692 MUST delete the outgoing SAs while processing the request and the 693 incoming SAs while processing the response. In that case, the 694 responses MUST NOT include delete payloads for the deleted SAs, since 695 that would result in duplicate deletion and could in theory delete 696 the wrong SA. 698 {{ Demoted the SHOULD }} Half-closed ESP or AH connections are 699 anomalous, and a node with auditing capability should probably audit 700 their existence if they persist. Note that this specification 701 nowhere specifies time periods, so it is up to individual endpoints 702 to decide how long to wait. A node MAY refuse to accept incoming 703 data on half-closed connections but MUST NOT unilaterally close them 704 and reuse the SPIs. If connection state becomes sufficiently messed 705 up, a node MAY close the IKE_SA; doing so will implicitly close all 706 SAs negotiated under it. It can then rebuild the SAs it needs on a 707 clean base under a new IKE_SA. {{ Clarif-5.8 }} The response to a 708 request that deletes the IKE_SA is an empty Informational response. 710 The INFORMATIONAL exchange is defined as: 712 Initiator Responder 713 ------------------------------------------------------------------- 714 HDR, SK {[N,] [D,] 715 [CP,] ...} --> 716 <-- HDR, SK {[N,] [D,] 717 [CP], ...} 719 The processing of an INFORMATIONAL exchange is determined by its 720 component payloads. 722 1.5. Informational Messages outside of an IKE_SA 724 If an encrypted IKE request packet arrives on port 500 or 4500 with 725 an unrecognized SPI, it could be because the receiving node has 726 recently crashed and lost state or because of some other system 727 malfunction or attack. If the receiving node has an active IKE_SA to 728 the IP address from whence the packet came, it MAY send a 729 notification of the wayward packet over that IKE_SA in an 730 INFORMATIONAL exchange. If it does not have such an IKE_SA, it MAY 731 send an Informational message without cryptographic protection to the 732 source IP address. Such a message is not part of an informational 733 exchange, and the receiving node MUST NOT respond to it. Doing so 734 could cause a message loop. 736 {{ 3.10.1-11 }} The INVALID_SPI notification MAY be sent in an IKE 737 INFORMATIONAL exchange when a node receives an ESP or AH packet with 738 an invalid SPI. The Notification Data contains the SPI of the 739 invalid packet. This usually indicates a node has rebooted and 740 forgotten an SA. If this Informational Message is sent outside the 741 context of an IKE_SA, it should only be used by the recipient as a 742 "hint" that something might be wrong (because it could easily be 743 forged). 745 {{ Clarif-7.7 }} There are two cases when such a one-way notification 746 is sent: INVALID_IKE_SPI and INVALID_SPI. These notifications are 747 sent outside of an IKE_SA. Note that such notifications are 748 explicitly not Informational exchanges; these are one-way messages 749 that must not be responded to. In case of INVALID_IKE_SPI, the 750 message sent is a response message, and thus it is sent to the IP 751 address and port from whence it came with the same IKE SPIs and the 752 Message ID copied. In case of INVALID_SPI, however, there are no IKE 753 SPI values that would be meaningful to the recipient of such a 754 notification. Using zero values or random values are both 755 acceptable. 757 1.6. Requirements Terminology 759 Definitions of the primitive terms in this document (such as Security 760 Association or SA) can be found in [IPSECARCH]. {{ Clarif-7.2 }} It 761 should be noted that parts of IKEv2 rely on some of the processing 762 rules in [IPSECARCH], as described in various sections of this 763 document. 765 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 766 "MAY" that appear in this document are to be interpreted as described 767 in [MUSTSHOULD]. 769 1.7. Differences Between RFC 4306 and This Document 771 {{ Added this entire section, including this recursive remark. }} 773 This document contains clarifications and amplifications to IKEv2 774 [IKEV2]. The clarifications are mostly based on [Clarif]. The 775 changes listed in that document were discussed in the IPsec Working 776 Group and, after the Working Group was disbanded, on the IPsec 777 mailing list. That document contains detailed explanations of areas 778 that were unclear in IKEv2, and is thus useful to implementers of 779 IKEv2. 781 The protocol described in this document retains the same major 782 version number (2) and minor version number (0) as was used in RFC 783 4306. 785 This document makes the figures and references a bit more regular 786 than in [IKEV2]. 788 IKEv2 developers have noted that the SHOULD-level requirements are 789 often unclear in that they don't say when it is OK to not obey the 790 requirements. They also have noted that there are MUST-level 791 requirements that are not related to interoperability. This document 792 has more explanation of some of these requirements. All non- 793 capitalized uses of the words SHOULD and MUST now mean their normal 794 English sense, not the interoperability sense of [MUSTSHOULD]. 796 IKEv2 (and IKEv1) developers have noted that there is a great deal of 797 material in the tables of codes in Section 3.10.1. This leads to 798 implementers not having all the needed information in the main body 799 of the docment. Much of the material from those tables has been 800 moved into the associated parts of the main body of the document. 802 In the body of this document, notes that are enclosed in double curly 803 braces {{ such as this }} point out changes from IKEv2. Changes that 804 come from [Clarif] are marked with the section from that document, 805 such as "{{ Clarif-2.10 }}". Changes that come from moving 806 descriptive text out of the tables in Section 3.10.1 are marked with 807 that number and the message type that contained the text, such as "{{ 808 3.10.1-16384 }}". 810 This document removes discussion of nesting AH and ESP. This was a 811 mistake in RFC 4306 caused by the lag between finishing RFC 4306 and 812 RFC 4301. Basically, IKEv2 is based on RFC 4301, which does not 813 include "SA bundles" that were part of RFC 2401. While a single 814 packet can go through IPsec processing multiple times, each of these 815 passes uses a separate SA, and the passes are coordinated by the 816 forwarding tables. In IKEv2, each of these SAs has to be created 817 using a separate CREATE_CHILD_SA exchange. 819 This document removes discussion of the INTERNAL_ADDRESS_EXPIRY 820 configuration attribute because its implementation was very 821 problematic. Implementations that conform to this document MUST 822 ignore proposals that have configuration attribute type 5, the old 823 value for INTERNAL_ADDRESS_EXPIRY. 825 This document adds the restriction in Section 2.13 that all PRFs used 826 with IKEv2 MUST take variable-sized keys. This should not affect any 827 implementations because there were no standardized PRFs that have 828 fixed-size keys. 830 A later version of this document may have all the {{ }} comments 831 removed from the body of the document and instead appear in an 832 appendix. 834 2. IKE Protocol Details and Variations 836 IKE normally listens and sends on UDP port 500, though IKE messages 837 may also be received on UDP port 4500 with a slightly different 838 format (see Section 2.23). Since UDP is a datagram (unreliable) 839 protocol, IKE includes in its definition recovery from transmission 840 errors, including packet loss, packet replay, and packet forgery. 841 IKE is designed to function so long as (1) at least one of a series 842 of retransmitted packets reaches its destination before timing out; 843 and (2) the channel is not so full of forged and replayed packets so 844 as to exhaust the network or CPU capacities of either endpoint. Even 845 in the absence of those minimum performance requirements, IKE is 846 designed to fail cleanly (as though the network were broken). 848 Although IKEv2 messages are intended to be short, they contain 849 structures with no hard upper bound on size (in particular, X.509 850 certificates), and IKEv2 itself does not have a mechanism for 851 fragmenting large messages. IP defines a mechanism for fragmentation 852 of oversize UDP messages, but implementations vary in the maximum 853 message size supported. Furthermore, use of IP fragmentation opens 854 an implementation to denial of service attacks [DOSUDPPROT]. 855 Finally, some NAT and/or firewall implementations may block IP 856 fragments. 858 All IKEv2 implementations MUST be able to send, receive, and process 859 IKE messages that are up to 1280 octets long, and they SHOULD be able 860 to send, receive, and process messages that are up to 3000 octets 861 long. {{ Demoted the SHOULD }} IKEv2 implementations need to be aware 862 of the maximum UDP message size supported and MAY shorten messages by 863 leaving out some certificates or cryptographic suite proposals if 864 that will keep messages below the maximum. Use of the "Hash and URL" 865 formats rather than including certificates in exchanges where 866 possible can avoid most problems. {{ Demoted the SHOULD }} 867 Implementations and configuration need to keep in mind, however, that 868 if the URL lookups are possible only after the IPsec SA is 869 established, recursion issues could prevent this technique from 870 working. 872 {{ Clarif-7.5 }} The UDP payload of all packets containing IKE 873 messages sent on port 4500 MUST begin with the prefix of four zeros; 874 otherwise, the receiver won't know how to handle them. 876 2.1. Use of Retransmission Timers 878 All messages in IKE exist in pairs: a request and a response. The 879 setup of an IKE_SA normally consists of two request/response pairs. 880 Once the IKE_SA is set up, either end of the security association may 881 initiate requests at any time, and there can be many requests and 882 responses "in flight" at any given moment. But each message is 883 labeled as either a request or a response, and for each request/ 884 response pair one end of the security association is the initiator 885 and the other is the responder. 887 For every pair of IKE messages, the initiator is responsible for 888 retransmission in the event of a timeout. The responder MUST never 889 retransmit a response unless it receives a retransmission of the 890 request. In that event, the responder MUST ignore the retransmitted 891 request except insofar as it triggers a retransmission of the 892 response. The initiator MUST remember each request until it receives 893 the corresponding response. The responder MUST remember each 894 response until it receives a request whose sequence number is larger 895 than or equal to the sequence number in the response plus its window 896 size (see Section 2.3). 898 IKE is a reliable protocol, in the sense that the initiator MUST 899 retransmit a request until either it receives a corresponding reply 900 OR it deems the IKE security association to have failed and it 901 discards all state associated with the IKE_SA and any CHILD_SAs 902 negotiated using that IKE_SA. 904 {{ Clarif-2.3 }} Retransmissions of the IKE_SA_INIT request require 905 some special handling. When a responder receives an IKE_SA_INIT 906 request, it has to determine whether the packet is retransmission 907 belonging to an existing "half-open" IKE_SA (in which case the 908 responder retransmits the same response), or a new request (in which 909 case the responder creates a new IKE_SA and sends a fresh response), 910 or it belongs to an existing IKE_SA where the IKE_AUTH request has 911 been already received (in which case the responder ignores it). 913 It is not sufficient to use the initiator's SPI and/or IP address to 914 differentiate between these three cases because two different peers 915 behind a single NAT could choose the same initiator SPI. Instead, a 916 robust responder will do the IKE_SA lookup using the whole packet, 917 its hash, or the Ni payload. 919 2.2. Use of Sequence Numbers for Message ID 921 Every IKE message contains a Message ID as part of its fixed header. 922 This Message ID is used to match up requests and responses, and to 923 identify retransmissions of messages. 925 The Message ID is a 32-bit quantity, which is zero for the 926 IKE_SA_INIT messages (including retries of the message due to 927 responses such as COOKIE and INVALID_KE_PAYLOAD {{ Clarif-2.2 }}), 928 and incremented for each subsequent exchange. Thus, the first pair 929 of IKE_AUTH messages will have ID of 1, the second (when EAP is used) 930 will be 2, and so on. {{ Clarif-3.10 }} 932 Each endpoint in the IKE Security Association maintains two "current" 933 Message IDs: the next one to be used for a request it initiates and 934 the next one it expects to see in a request from the other end. 935 These counters increment as requests are generated and received. 936 Responses always contain the same message ID as the corresponding 937 request. That means that after the initial exchange, each integer n 938 may appear as the message ID in four distinct messages: the nth 939 request from the original IKE initiator, the corresponding response, 940 the nth request from the original IKE responder, and the 941 corresponding response. If the two ends make very different numbers 942 of requests, the Message IDs in the two directions can be very 943 different. There is no ambiguity in the messages, however, because 944 the (I)nitiator and (R)esponse bits in the message header specify 945 which of the four messages a particular one is. 947 Note that Message IDs are cryptographically protected and provide 948 protection against message replays. In the unlikely event that 949 Message IDs grow too large to fit in 32 bits, the IKE_SA MUST be 950 closed. Rekeying an IKE_SA resets the sequence numbers. 952 2.3. Window Size for Overlapping Requests 954 In order to maximize IKE throughput, an IKE endpoint MAY issue 955 multiple requests before getting a response to any of them if the 956 other endpoint has indicated its ability to handle such requests. 957 For simplicity, an IKE implementation MAY choose to process requests 958 strictly in order and/or wait for a response to one request before 959 issuing another. Certain rules must be followed to ensure 960 interoperability between implementations using different strategies. 962 After an IKE_SA is set up, either end can initiate one or more 963 requests. These requests may pass one another over the network. An 964 IKE endpoint MUST be prepared to accept and process a request while 965 it has a request outstanding in order to avoid a deadlock in this 966 situation. {{ Downgraded the SHOULD }} An IKE endpoint may also 967 accept and process multiple requests while it has a request 968 outstanding. 970 {{ 3.10.1-16385 }} The SET_WINDOW_SIZE notification asserts that the 971 sending endpoint is capable of keeping state for multiple outstanding 972 exchanges, permitting the recipient to send multiple requests before 973 getting a response to the first. The data associated with a 974 SET_WINDOW_SIZE notification MUST be 4 octets long and contain the 975 big endian representation of the number of messages the sender 976 promises to keep. The window size is always one until the initial 977 exchanges complete. 979 An IKE endpoint MUST wait for a response to each of its messages 980 before sending a subsequent message unless it has received a 981 SET_WINDOW_SIZE Notify message from its peer informing it that the 982 peer is prepared to maintain state for multiple outstanding messages 983 in order to allow greater throughput. 985 An IKE endpoint MUST NOT exceed the peer's stated window size for 986 transmitted IKE requests. In other words, if the responder stated 987 its window size is N, then when the initiator needs to make a request 988 X, it MUST wait until it has received responses to all requests up 989 through request X-N. An IKE endpoint MUST keep a copy of (or be able 990 to regenerate exactly) each request it has sent until it receives the 991 corresponding response. An IKE endpoint MUST keep a copy of (or be 992 able to regenerate exactly) the number of previous responses equal to 993 its declared window size in case its response was lost and the 994 initiator requests its retransmission by retransmitting the request. 996 An IKE endpoint supporting a window size greater than one ought to be 997 capable of processing incoming requests out of order to maximize 998 performance in the event of network failures or packet reordering. 1000 {{ Clarif-7.3 }} The window size is normally a (possibly 1001 configurable) property of a particular implementation, and is not 1002 related to congestion control (unlike the window size in TCP, for 1003 example). In particular, it is not defined what the responder should 1004 do when it receives a SET_WINDOW_SIZE notification containing a 1005 smaller value than is currently in effect. Thus, there is currently 1006 no way to reduce the window size of an existing IKE_SA; you can only 1007 increase it. When rekeying an IKE_SA, the new IKE_SA starts with 1008 window size 1 until it is explicitly increased by sending a new 1009 SET_WINDOW_SIZE notification. 1011 {{ 3.10.1-9 }}The INVALID_MESSAGE_ID notification is sent when an IKE 1012 message ID outside the supported window is received. This Notify 1013 MUST NOT be sent in a response; the invalid request MUST NOT be 1014 acknowledged. Instead, inform the other side by initiating an 1015 INFORMATIONAL exchange with Notification data containing the four 1016 octet invalid message ID. Sending this notification is optional, and 1017 notifications of this type MUST be rate limited. 1019 2.4. State Synchronization and Connection Timeouts 1021 An IKE endpoint is allowed to forget all of its state associated with 1022 an IKE_SA and the collection of corresponding CHILD_SAs at any time. 1023 This is the anticipated behavior in the event of an endpoint crash 1024 and restart. It is important when an endpoint either fails or 1025 reinitializes its state that the other endpoint detect those 1026 conditions and not continue to waste network bandwidth by sending 1027 packets over discarded SAs and having them fall into a black hole. 1029 {{ 3.10.1-16384 }} The INITIAL_CONTACT notification asserts that this 1030 IKE_SA is the only IKE_SA currently active between the authenticated 1031 identities. It MAY be sent when an IKE_SA is established after a 1032 crash, and the recipient MAY use this information to delete any other 1033 IKE_SAs it has to the same authenticated identity without waiting for 1034 a timeout. This notification MUST NOT be sent by an entity that may 1035 be replicated (e.g., a roaming user's credentials where the user is 1036 allowed to connect to the corporate firewall from two remote systems 1037 at the same time). {{ Clarif-7.9 }} The INITIAL_CONTACT notification, 1038 if sent, MUST be in the first IKE_AUTH request, not as a separate 1039 exchange afterwards; however, receiving parties need to deal with it 1040 in other requests. 1042 Since IKE is designed to operate in spite of Denial of Service (DoS) 1043 attacks from the network, an endpoint MUST NOT conclude that the 1044 other endpoint has failed based on any routing information (e.g., 1045 ICMP messages) or IKE messages that arrive without cryptographic 1046 protection (e.g., Notify messages complaining about unknown SPIs). 1047 An endpoint MUST conclude that the other endpoint has failed only 1048 when repeated attempts to contact it have gone unanswered for a 1049 timeout period or when a cryptographically protected INITIAL_CONTACT 1050 notification is received on a different IKE_SA to the same 1051 authenticated identity. {{ Demoted the SHOULD }} An endpoint should 1052 suspect that the other endpoint has failed based on routing 1053 information and initiate a request to see whether the other endpoint 1054 is alive. To check whether the other side is alive, IKE specifies an 1055 empty INFORMATIONAL message that (like all IKE requests) requires an 1056 acknowledgement (note that within the context of an IKE_SA, an 1057 "empty" message consists of an IKE header followed by an Encrypted 1058 payload that contains no payloads). If a cryptographically protected 1059 message has been received from the other side recently, unprotected 1060 notifications MAY be ignored. Implementations MUST limit the rate at 1061 which they take actions based on unprotected messages. 1063 Numbers of retries and lengths of timeouts are not covered in this 1064 specification because they do not affect interoperability. It is 1065 suggested that messages be retransmitted at least a dozen times over 1066 a period of at least several minutes before giving up on an SA, but 1067 different environments may require different rules. To be a good 1068 network citizen, retranmission times MUST increase exponentially to 1069 avoid flooding the network and making an existing congestion 1070 situation worse. If there has only been outgoing traffic on all of 1071 the SAs associated with an IKE_SA, it is essential to confirm 1072 liveness of the other endpoint to avoid black holes. If no 1073 cryptographically protected messages have been received on an IKE_SA 1074 or any of its CHILD_SAs recently, the system needs to perform a 1075 liveness check in order to prevent sending messages to a dead peer. 1076 Receipt of a fresh cryptographically protected message on an IKE_SA 1077 or any of its CHILD_SAs ensures liveness of the IKE_SA and all of its 1078 CHILD_SAs. Note that this places requirements on the failure modes 1079 of an IKE endpoint. An implementation MUST NOT continue sending on 1080 any SA if some failure prevents it from receiving on all of the 1081 associated SAs. If CHILD_SAs can fail independently from one another 1082 without the associated IKE_SA being able to send a delete message, 1083 then they MUST be negotiated by separate IKE_SAs. 1085 There is a Denial of Service attack on the initiator of an IKE_SA 1086 that can be avoided if the initiator takes the proper care. Since 1087 the first two messages of an SA setup are not cryptographically 1088 protected, an attacker could respond to the initiator's message 1089 before the genuine responder and poison the connection setup attempt. 1090 To prevent this, the initiator MAY be willing to accept multiple 1091 responses to its first message, treat each as potentially legitimate, 1092 respond to it, and then discard all the invalid half-open connections 1093 when it receives a valid cryptographically protected response to any 1094 one of its requests. Once a cryptographically valid response is 1095 received, all subsequent responses should be ignored whether or not 1096 they are cryptographically valid. 1098 Note that with these rules, there is no reason to negotiate and agree 1099 upon an SA lifetime. If IKE presumes the partner is dead, based on 1100 repeated lack of acknowledgement to an IKE message, then the IKE SA 1101 and all CHILD_SAs set up through that IKE_SA are deleted. 1103 An IKE endpoint may at any time delete inactive CHILD_SAs to recover 1104 resources used to hold their state. If an IKE endpoint chooses to 1105 delete CHILD_SAs, it MUST send Delete payloads to the other end 1106 notifying it of the deletion. It MAY similarly time out the IKE_SA. 1108 {{ Clarified the SHOULD }} Closing the IKE_SA implicitly closes all 1109 associated CHILD_SAs. In this case, an IKE endpoint SHOULD send a 1110 Delete payload indicating that it has closed the IKE_SA unless the 1111 other endpoint is no longer responding. 1113 2.5. Version Numbers and Forward Compatibility 1115 This document describes version 2.0 of IKE, meaning the major version 1116 number is 2 and the minor version number is 0. {{ Restated the 1117 relationship to RFC 4306 }} This document is a clarification of 1118 [IKEV2]. It is likely that some implementations will want to support 1119 version 1.0 and version 2.0, and in the future, other versions. 1121 The major version number should be incremented only if the packet 1122 formats or required actions have changed so dramatically that an 1123 older version node would not be able to interoperate with a newer 1124 version node if it simply ignored the fields it did not understand 1125 and took the actions specified in the older specification. The minor 1126 version number indicates new capabilities, and MUST be ignored by a 1127 node with a smaller minor version number, but used for informational 1128 purposes by the node with the larger minor version number. For 1129 example, it might indicate the ability to process a newly defined 1130 notification message. The node with the larger minor version number 1131 would simply note that its correspondent would not be able to 1132 understand that message and therefore would not send it. 1134 {{ 3.10.1-5 }} If an endpoint receives a message with a higher major 1135 version number, it MUST drop the message and SHOULD send an 1136 unauthenticated notification message of type INVALID_MAJOR_VERSION 1137 containing the highest (closest) version number it supports. If an 1138 endpoint supports major version n, and major version m, it MUST 1139 support all versions between n and m. If it receives a message with 1140 a major version that it supports, it MUST respond with that version 1141 number. In order to prevent two nodes from being tricked into 1142 corresponding with a lower major version number than the maximum that 1143 they both support, IKE has a flag that indicates that the node is 1144 capable of speaking a higher major version number. 1146 Thus, the major version number in the IKE header indicates the 1147 version number of the message, not the highest version number that 1148 the transmitter supports. If the initiator is capable of speaking 1149 versions n, n+1, and n+2, and the responder is capable of speaking 1150 versions n and n+1, then they will negotiate speaking n+1, where the 1151 initiator will set a flag indicating its ability to speak a higher 1152 version. If they mistakenly (perhaps through an active attacker 1153 sending error messages) negotiate to version n, then both will notice 1154 that the other side can support a higher version number, and they 1155 MUST break the connection and reconnect using version n+1. 1157 Note that IKEv1 does not follow these rules, because there is no way 1158 in v1 of noting that you are capable of speaking a higher version 1159 number. So an active attacker can trick two v2-capable nodes into 1160 speaking v1. {{ Demoted the SHOULD }} When a v2-capable node 1161 negotiates down to v1, it should note that fact in its logs. 1163 Also for forward compatibility, all fields marked RESERVED MUST be 1164 set to zero by an implementation running version 2.0, and their 1165 content MUST be ignored by an implementation running version 2.0 ("Be 1166 conservative in what you send and liberal in what you receive"). In 1167 this way, future versions of the protocol can use those fields in a 1168 way that is guaranteed to be ignored by implementations that do not 1169 understand them. Similarly, payload types that are not defined are 1170 reserved for future use; implementations of a version where they are 1171 undefined MUST skip over those payloads and ignore their contents. 1173 IKEv2 adds a "critical" flag to each payload header for further 1174 flexibility for forward compatibility. If the critical flag is set 1175 and the payload type is unrecognized, the message MUST be rejected 1176 and the response to the IKE request containing that payload MUST 1177 include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an 1178 unsupported critical payload was included. {{ 3.10.1-1 }} In that 1179 Notify payload, the notification data contains the one-octet payload 1180 type. If the critical flag is not set and the payload type is 1181 unsupported, that payload MUST be ignored. Payloads sent in IKE 1182 response messages MUST NOT have the critical flag set. Note that the 1183 critical flag applies only to the payload type, not the contents. If 1184 the payload type is recognized, but the payload contains something 1185 which is not (such as an unknown transform inside an SA payload, or 1186 an unknown Notify Message Type inside a Notify payload), the critical 1187 flag is ignored. 1189 NOTE TO IMPLEMENTERS: Does anyone require that the payloads be in the 1190 order shown in the figures in Section 2? Can we eliminate the 1191 requirement in the following paragraph? If not, we will probably 1192 have to add a new appendix with the order, but there is no reason to 1193 do that if no one actually cares. {{ Remove this paragraph before the 1194 document is finalized, of course. }} 1196 {{ Demoted the SHOULD in the second clause }}Although new payload 1197 types may be added in the future and may appear interleaved with the 1198 fields defined in this specification, implementations MUST send the 1199 payloads defined in this specification in the order shown in the 1200 figures in Section 2; implementations are explicitly allowed to 1201 reject as invalid a message with those payloads in any other order. 1203 2.6. Cookies 1205 The term "cookies" originates with Karn and Simpson [PHOTURIS] in 1206 Photuris, an early proposal for key management with IPsec, and it has 1207 persisted. The Internet Security Association and Key Management 1208 Protocol (ISAKMP) [ISAKMP] fixed message header includes two eight- 1209 octet fields titled "cookies", and that syntax is used by both IKEv1 1210 and IKEv2, although in IKEv2 they are referred to as the "IKE SPI" 1211 and there is a new separate field in a Notify payload holding the 1212 cookie. The initial two eight-octet fields in the header are used as 1213 a connection identifier at the beginning of IKE packets. {{ Demoted 1214 the SHOULD }} Each endpoint chooses one of the two SPIs and needs to 1215 choose them so as to be unique identifiers of an IKE_SA. An SPI 1216 value of zero is special and indicates that the remote SPI value is 1217 not yet known by the sender. 1219 Unlike ESP and AH where only the recipient's SPI appears in the 1220 header of a message, in IKE the sender's SPI is also sent in every 1221 message. Since the SPI chosen by the original initiator of the 1222 IKE_SA is always sent first, an endpoint with multiple IKE_SAs open 1223 that wants to find the appropriate IKE_SA using the SPI it assigned 1224 must look at the I(nitiator) Flag bit in the header to determine 1225 whether it assigned the first or the second eight octets. 1227 In the first message of an initial IKE exchange, the initiator will 1228 not know the responder's SPI value and will therefore set that field 1229 to zero. 1231 An expected attack against IKE is state and CPU exhaustion, where the 1232 target is flooded with session initiation requests from forged IP 1233 addresses. This attack can be made less effective if an 1234 implementation of a responder uses minimal CPU and commits no state 1235 to an SA until it knows the initiator can receive packets at the 1236 address from which it claims to be sending them. 1238 When a responder detects a large number of half-open IKE_SAs, it 1239 SHOULD reply to IKE_SA_INIT requests with a response containing the 1240 COOKIE notification. {{ 3.10.1-16390 }} The data associated with this 1241 notification MUST be between 1 and 64 octets in length (inclusive), 1242 and its generation is described later in this section. If the 1243 IKE_SA_INIT response includes the COOKIE notification, the initiator 1244 MUST then retry the IKE_SA_INIT request, and include the COOKIE 1245 notification containing the received data as the first payload, and 1246 all other payloads unchanged. The initial exchange will then be as 1247 follows: 1249 Initiator Responder 1250 ------------------------------------------------------------------- 1251 HDR(A,0), SAi1, KEi, Ni --> 1252 <-- HDR(A,0), N(COOKIE) 1253 HDR(A,0), N(COOKIE), SAi1, 1254 KEi, Ni --> 1255 <-- HDR(A,B), SAr1, KEr, 1256 Nr, [CERTREQ] 1257 HDR(A,B), SK {IDi, [CERT,] 1258 [CERTREQ,] [IDr,] AUTH, 1259 SAi2, TSi, TSr} --> 1260 <-- HDR(A,B), SK {IDr, [CERT,] 1261 AUTH, SAr2, TSi, TSr} 1263 The first two messages do not affect any initiator or responder state 1264 except for communicating the cookie. In particular, the message 1265 sequence numbers in the first four messages will all be zero and the 1266 message sequence numbers in the last two messages will be one. 'A' 1267 is the SPI assigned by the initiator, while 'B' is the SPI assigned 1268 by the responder. 1270 {{ Demoted the SHOULD }} An IKE implementation should implement its 1271 responder cookie generation in such a way as to not require any saved 1272 state to recognize its valid cookie when the second IKE_SA_INIT 1273 message arrives. The exact algorithms and syntax they use to 1274 generate cookies do not affect interoperability and hence are not 1275 specified here. The following is an example of how an endpoint could 1276 use cookies to implement limited DOS protection. 1278 A good way to do this is to set the responder cookie to be: 1280 Cookie = | Hash(Ni | IPi | SPIi | ) 1282 where is a randomly generated secret known only to the 1283 responder and periodically changed and | indicates concatenation. 1284 should be changed whenever is 1285 regenerated. The cookie can be recomputed when the IKE_SA_INIT 1286 arrives the second time and compared to the cookie in the received 1287 message. If it matches, the responder knows that the cookie was 1288 generated since the last change to and that IPi must be the 1289 same as the source address it saw the first time. Incorporating SPIi 1290 into the calculation ensures that if multiple IKE_SAs are being set 1291 up in parallel they will all get different cookies (assuming the 1292 initiator chooses unique SPIi's). Incorporating Ni into the hash 1293 ensures that an attacker who sees only message 2 can't successfully 1294 forge a message 3. 1296 If a new value for is chosen while there are connections in 1297 the process of being initialized, an IKE_SA_INIT might be returned 1298 with other than the current . The responder in 1299 that case MAY reject the message by sending another response with a 1300 new cookie or it MAY keep the old value of around for a 1301 short time and accept cookies computed from either one. {{ Demoted 1302 the SHOULD NOT }} The responder should not accept cookies 1303 indefinitely after is changed, since that would defeat part 1304 of the denial of service protection. {{ Demoted the SHOULD }} The 1305 responder should change the value of frequently, especially 1306 if under attack. 1308 {{ Clarif-2.1 }} In addition to cookies, there are several cases 1309 where the IKE_SA_INIT exchange does not result in the creation of an 1310 IKE_SA (such as INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). In such a 1311 case, sending a zero value for the Responder's SPI is correct. If 1312 the responder sends a non-zero responder SPI, the initiator should 1313 not reject the response for only that reason. 1315 {{ Clarif-2.5 }} When one party receives an IKE_SA_INIT request 1316 containing a cookie whose contents do not match the value expected, 1317 that party MUST ignore the cookie and process the message as if no 1318 cookie had been included; usually this means sending a response 1319 containing a new cookie. 1321 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD 1323 {{ This section added by Clarif-2.4 }} 1325 There are two common reasons why the initiator may have to retry the 1326 IKE_SA_INIT exchange: the responder requests a cookie or wants a 1327 different Diffie-Hellman group than was included in the KEi payload. 1328 If the initiator receives a cookie from the responder, the initiator 1329 needs to decide whether or not to include the cookie in only the next 1330 retry of the IKE_SA_INIT request, or in all subsequent retries as 1331 well. 1333 If the initiator includes the cookie only in the next retry, one 1334 additional roundtrip may be needed in some cases. An additional 1335 roundtrip is needed also if the initiator includes the cookie in all 1336 retries, but the responder does not support this. For instance, if 1337 the responder includes the SAi1 and KEi payloads in cookie 1338 calculation, it will reject the request by sending a new cookie. 1340 If both peers support including the cookie in all retries, a slightly 1341 shorter exchange can happen. Implementations SHOULD support this 1342 shorter exchange, but MUST NOT fail if other implementations do not 1343 support this shorter exchange. 1345 2.7. Cryptographic Algorithm Negotiation 1347 The payload type known as "SA" indicates a proposal for a set of 1348 choices of IPsec protocols (IKE, ESP, and/or AH) for the SA as well 1349 as cryptographic algorithms associated with each protocol. 1351 An SA payload consists of one or more proposals. {{ Clarif-7.13 }} 1352 Each proposal includes one protocol. Each protocol contains one or 1353 more transforms -- each specifying a cryptographic algorithm. Each 1354 transform contains zero or more attributes (attributes are needed 1355 only if the transform identifier does not completely specify the 1356 cryptographic algorithm). 1358 This hierarchical structure was designed to efficiently encode 1359 proposals for cryptographic suites when the number of supported 1360 suites is large because multiple values are acceptable for multiple 1361 transforms. The responder MUST choose a single suite, which may be 1362 any subset of the SA proposal following the rules below: 1364 {{ Clarif-7.13 }} Each proposal contains one protocol. If a proposal 1365 is accepted, the SA response MUST contain the same protocol. The 1366 responder MUST accept a single proposal or reject them all and return 1367 an error. {{ 3.10.1-14 }} The error is given in a notification of 1368 type NO_PROPOSAL_CHOSEN. 1370 Each IPsec protocol proposal contains one or more transforms. Each 1371 transform contains a transform type. The accepted cryptographic 1372 suite MUST contain exactly one transform of each type included in the 1373 proposal. For example: if an ESP proposal includes transforms 1374 ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256, 1375 AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one 1376 of the ENCR_ transforms and one of the AUTH_ transforms. Thus, six 1377 combinations are acceptable. 1379 Since the initiator sends its Diffie-Hellman value in the 1380 IKE_SA_INIT, it must guess the Diffie-Hellman group that the 1381 responder will select from its list of supported groups. If the 1382 initiator guesses wrong, the responder will respond with a Notify 1383 payload of type INVALID_KE_PAYLOAD indicating the selected group. In 1384 this case, the initiator MUST retry the IKE_SA_INIT with the 1385 corrected Diffie-Hellman group. The initiator MUST again propose its 1386 full set of acceptable cryptographic suites because the rejection 1387 message was unauthenticated and otherwise an active attacker could 1388 trick the endpoints into negotiating a weaker suite than a stronger 1389 one that they both prefer. 1391 {{ Clarif-2.1 }} When the IKE_SA_INIT exchange does not result in the 1392 creation of an IKE_SA due to INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN, 1393 or COOKIE (see Section 2.6), the responder's SPI will be zero. 1394 However, if the responder sends a non-zero responder SPI, the 1395 initiator should not reject the response for only that reason. 1397 2.8. Rekeying 1399 {{ Demoted the SHOULD }} IKE, ESP, and AH security associations use 1400 secret keys that should be used only for a limited amount of time and 1401 to protect a limited amount of data. This limits the lifetime of the 1402 entire security association. When the lifetime of a security 1403 association expires, the security association MUST NOT be used. If 1404 there is demand, new security associations MAY be established. 1405 Reestablishment of security associations to take the place of ones 1406 that expire is referred to as "rekeying". 1408 To allow for minimal IPsec implementations, the ability to rekey SAs 1409 without restarting the entire IKE_SA is optional. An implementation 1410 MAY refuse all CREATE_CHILD_SA requests within an IKE_SA. If an SA 1411 has expired or is about to expire and rekeying attempts using the 1412 mechanisms described here fail, an implementation MUST close the 1413 IKE_SA and any associated CHILD_SAs and then MAY start new ones. {{ 1414 Demoted the SHOULD }} Implementations may wish to support in-place 1415 rekeying of SAs, since doing so offers better performance and is 1416 likely to reduce the number of packets lost during the transition. 1418 To rekey a CHILD_SA within an existing IKE_SA, create a new, 1419 equivalent SA (see Section 2.17 below), and when the new one is 1420 established, delete the old one. To rekey an IKE_SA, establish a new 1421 equivalent IKE_SA (see Section 2.18 below) with the peer to whom the 1422 old IKE_SA is shared using a CREATE_CHILD_SA within the existing 1423 IKE_SA. An IKE_SA so created inherits all of the original IKE_SA's 1424 CHILD_SAs, and the new IKE_SA is used for all control messages needed 1425 to maintain those CHILD_SAs. The old IKE_SA is then deleted, and the 1426 Delete payload to delete itself MUST be the last request sent over 1427 the old IKE_SA. 1429 {{ Demoted the SHOULD }} SAs should be rekeyed proactively, i.e., the 1430 new SA should be established before the old one expires and becomes 1431 unusable. Enough time should elapse between the time the new SA is 1432 established and the old one becomes unusable so that traffic can be 1433 switched over to the new SA. 1435 A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes 1436 were negotiated. In IKEv2, each end of the SA is responsible for 1437 enforcing its own lifetime policy on the SA and rekeying the SA when 1438 necessary. If the two ends have different lifetime policies, the end 1439 with the shorter lifetime will end up always being the one to request 1440 the rekeying. If an SA has been inactive for a long time and if an 1441 endpoint would not initiate the SA in the absence of traffic, the 1442 endpoint MAY choose to close the SA instead of rekeying it when its 1443 lifetime expires. {{ Demoted the SHOULD }} It should do so if there 1444 has been no traffic since the last time the SA was rekeyed. 1446 Note that IKEv2 deliberately allows parallel SAs with the same 1447 traffic selectors between common endpoints. One of the purposes of 1448 this is to support traffic quality of service (QoS) differences among 1449 the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and section 4.1 of 1450 [DIFFTUNNEL]). Hence unlike IKEv1, the combination of the endpoints 1451 and the traffic selectors may not uniquely identify an SA between 1452 those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on 1453 the basis of duplicate traffic selectors SHOULD NOT be used. 1455 {{ Demoted the SHOULD }} The node that initiated the surviving 1456 rekeyed SA should delete the replaced SA after the new one is 1457 established. 1459 There are timing windows -- particularly in the presence of lost 1460 packets -- where endpoints may not agree on the state of an SA. The 1461 responder to a CREATE_CHILD_SA MUST be prepared to accept messages on 1462 an SA before sending its response to the creation request, so there 1463 is no ambiguity for the initiator. The initiator MAY begin sending 1464 on an SA as soon as it processes the response. The initiator, 1465 however, cannot receive on a newly created SA until it receives and 1466 processes the response to its CREATE_CHILD_SA request. How, then, is 1467 the responder to know when it is OK to send on the newly created SA? 1469 From a technical correctness and interoperability perspective, the 1470 responder MAY begin sending on an SA as soon as it sends its response 1471 to the CREATE_CHILD_SA request. In some situations, however, this 1472 could result in packets unnecessarily being dropped, so an 1473 implementation MAY defer such sending. 1475 The responder can be assured that the initiator is prepared to 1476 receive messages on an SA if either (1) it has received a 1477 cryptographically valid message on the new SA, or (2) the new SA 1478 rekeys an existing SA and it receives an IKE request to close the 1479 replaced SA. When rekeying an SA, the responder continues to send 1480 traffic on the old SA until one of those events occurs. When 1481 establishing a new SA, the responder MAY defer sending messages on a 1482 new SA until either it receives one or a timeout has occurred. {{ 1483 Demoted the SHOULD }} If an initiator receives a message on an SA for 1484 which it has not received a response to its CREATE_CHILD_SA request, 1485 it interprets that as a likely packet loss and retransmits the 1486 CREATE_CHILD_SA request. An initiator MAY send a dummy message on a 1487 newly created SA if it has no messages queued in order to assure the 1488 responder that the initiator is ready to receive messages. 1490 {{ Clarif-5.9 }} Throughout this document, "initiator" refers to the 1491 party who initiated the exchange being described, and "original 1492 initiator" refers to the party who initiated the whole IKE_SA. The 1493 "original initiator" always refers to the party who initiated the 1494 exchange which resulted in the current IKE_SA. In other words, if 1495 the "original responder" starts rekeying the IKE_SA, that party 1496 becomes the "original initiator" of the new IKE_SA. 1498 2.8.1. Simultaneous CHILD_SA rekeying 1500 {{ The first two paragraphs were moved, and the rest was added, based 1501 on Clarif-5.11 }} 1503 If the two ends have the same lifetime policies, it is possible that 1504 both will initiate a rekeying at the same time (which will result in 1505 redundant SAs). To reduce the probability of this happening, the 1506 timing of rekeying requests SHOULD be jittered (delayed by a random 1507 amount of time after the need for rekeying is noticed). 1509 This form of rekeying may temporarily result in multiple similar SAs 1510 between the same pairs of nodes. When there are two SAs eligible to 1511 receive packets, a node MUST accept incoming packets through either 1512 SA. If redundant SAs are created though such a collision, the SA 1513 created with the lowest of the four nonces used in the two exchanges 1514 SHOULD be closed by the endpoint that created it. {{ Clarif-5.10 }} 1515 "Lowest" means an octet-by-octet, lexicographical comparison (instead 1516 of, for instance, comparing the nonces as large integers). In other 1517 words, start by comparing the first octet; if they're equal, move to 1518 the next octet, and so on. If you reach the end of one nonce, that 1519 nonce is the lower one. 1521 The following is an explanation on the impact this has on 1522 implementations. Assume that hosts A and B have an existing IPsec SA 1523 pair with SPIs (SPIa1,SPIb1), and both start rekeying it at the same 1524 time: 1526 Host A Host B 1527 ------------------------------------------------------------------- 1528 send req1: N(REKEY_SA,SPIa1), 1529 SA(..,SPIa2,..),Ni1,.. --> 1530 <-- send req2: N(REKEY_SA,SPIb1), 1531 SA(..,SPIb2,..),Ni2 1532 recv req2 <-- 1534 At this point, A knows there is a simultaneous rekeying going on. 1535 However, it cannot yet know which of the exchanges will have the 1536 lowest nonce, so it will just note the situation and respond as 1537 usual. 1539 send resp2: SA(..,SPIa3,..), 1540 Nr1,.. --> 1541 --> recv req1 1543 Now B also knows that simultaneous rekeying is going on. It responds 1544 as usual. 1546 <-- send resp1: SA(..,SPIb3,..), 1547 Nr2,.. 1548 recv resp1 <-- 1549 --> recv resp2 1551 At this point, there are three CHILD_SA pairs between A and B (the 1552 old one and two new ones). A and B can now compare the nonces. 1553 Suppose that the lowest nonce was Nr1 in message resp2; in this case, 1554 B (the sender of req2) deletes the redundant new SA, and A (the node 1555 that initiated the surviving rekeyed SA), deletes the old one. 1557 send req3: D(SPIa1) --> 1558 <-- send req4: D(SPIb2) 1559 --> recv req3 1560 <-- send resp3: D(SPIb1) 1561 recv req4 <-- 1562 send resp4: D(SPIa3) --> 1564 The rekeying is now finished. 1566 However, there is a second possible sequence of events that can 1567 happen if some packets are lost in the network, resulting in 1568 retransmissions. The rekeying begins as usual, but A's first packet 1569 (req1) is lost. 1571 Host A Host B 1572 ------------------------------------------------------------------- 1573 send req1: N(REKEY_SA,SPIa1), 1574 SA(..,SPIa2,..), 1575 Ni1,.. --> (lost) 1576 <-- send req2: N(REKEY_SA,SPIb1), 1577 SA(..,SPIb2,..),Ni2 1578 recv req2 <-- 1579 send resp2: SA(..,SPIa3,..), 1580 Nr1,.. --> 1581 --> recv resp2 1582 <-- send req3: D(SPIb1) 1583 recv req3 <-- 1584 send resp3: D(SPIa1) --> 1585 --> recv resp3 1587 From B's point of view, the rekeying is now completed, and since it 1588 has not yet received A's req1, it does not even know that there was 1589 simultaneous rekeying. However, A will continue retransmitting the 1590 message, and eventually it will reach B. 1592 resend req1 --> 1593 --> recv req1 1595 To B, it looks like A is trying to rekey an SA that no longer exists; 1596 thus, B responds to the request with something non-fatal such as 1597 NO_PROPOSAL_CHOSEN. 1599 <-- send resp1: N(NO_PROPOSAL_CHOSEN) 1600 recv resp1 <-- 1602 When A receives this error, it already knows there was simultaneous 1603 rekeying, so it can ignore the error message. 1605 2.8.2. Rekeying the IKE_SA Versus Reauthentication 1607 {{ Added this section from Clarif-5.2 }} 1609 Rekeying the IKE_SA and reauthentication are different concepts in 1610 IKEv2. Rekeying the IKE_SA establishes new keys for the IKE_SA and 1611 resets the Message ID counters, but it does not authenticate the 1612 parties again (no AUTH or EAP payloads are involved). 1614 Although rekeying the IKE_SA may be important in some environments, 1615 reauthentication (the verification that the parties still have access 1616 to the long-term credentials) is often more important. 1618 IKEv2 does not have any special support for reauthentication. 1619 Reauthentication is done by creating a new IKE_SA from scratch (using 1620 IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify 1621 payloads), creating new CHILD_SAs within the new IKE_SA (without 1622 REKEY_SA notify payloads), and finally deleting the old IKE_SA (which 1623 deletes the old CHILD_SAs as well). 1625 This means that reauthentication also establishes new keys for the 1626 IKE_SA and CHILD_SAs. Therefore, while rekeying can be performed 1627 more often than reauthentication, the situation where "authentication 1628 lifetime" is shorter than "key lifetime" does not make sense. 1630 While creation of a new IKE_SA can be initiated by either party 1631 (initiator or responder in the original IKE_SA), the use of EAP 1632 authentication and/or configuration payloads means in practice that 1633 reauthentication has to be initiated by the same party as the 1634 original IKE_SA. IKEv2 does not currently allow the responder to 1635 request reauthentication in this case; however, there are extensions 1636 that add this functionality such as [REAUTH]. 1638 2.9. Traffic Selector Negotiation 1640 {{ Clarif-7.2 }} When an RFC4301-compliant IPsec subsystem receives 1641 an IP packet and matches a "protect" selector in its Security Policy 1642 Database (SPD), the subsystem protects that packet with IPsec. When 1643 no SA exists yet, it is the task of IKE to create it. Maintenance of 1644 a system's SPD is outside the scope of IKE (see [PFKEY] for an 1645 example protocol), though some implementations might update their SPD 1646 in connection with the running of IKE (for an example scenario, see 1647 Section 1.1.3). 1649 Traffic Selector (TS) payloads allow endpoints to communicate some of 1650 the information from their SPD to their peers. TS payloads specify 1651 the selection criteria for packets that will be forwarded over the 1652 newly set up SA. This can serve as a consistency check in some 1653 scenarios to assure that the SPDs are consistent. In others, it 1654 guides the dynamic update of the SPD. 1656 Two TS payloads appear in each of the messages in the exchange that 1657 creates a CHILD_SA pair. Each TS payload contains one or more 1658 Traffic Selectors. Each Traffic Selector consists of an address 1659 range (IPv4 or IPv6), a port range, and an IP protocol ID. 1661 The first of the two TS payloads is known as TSi (Traffic Selector- 1662 initiator). The second is known as TSr (Traffic Selector-responder). 1663 TSi specifies the source address of traffic forwarded from (or the 1664 destination address of traffic forwarded to) the initiator of the 1665 CHILD_SA pair. TSr specifies the destination address of the traffic 1666 forwarded to (or the source address of the traffic forwarded from) 1667 the responder of the CHILD_SA pair. For example, if the original 1668 initiator requests the creation of a CHILD_SA pair, and wishes to 1669 tunnel all traffic from subnet 192.0.1.* on the initiator's side to 1670 subnet 192.0.2.* on the responder's side, the initiator would include 1671 a single traffic selector in each TS payload. TSi would specify the 1672 address range (192.0.1.0 - 192.0.1.255) and TSr would specify the 1673 address range (192.0.2.0 - 192.0.2.255). Assuming that proposal was 1674 acceptable to the responder, it would send identical TS payloads 1675 back. (Note: The IP address range 192.0.2.* has been reserved for 1676 use in examples in RFCs and similar documents. This document needed 1677 two such ranges, and so also used 192.0.1.*. This should not be 1678 confused with any actual address.) 1680 IKEv2 allows the responder to choose a subset of the traffic proposed 1681 by the initiator. This could happen when the configurations of the 1682 two endpoints are being updated but only one end has received the new 1683 information. Since the two endpoints may be configured by different 1684 people, the incompatibility may persist for an extended period even 1685 in the absence of errors. It also allows for intentionally different 1686 configurations, as when one end is configured to tunnel all addresses 1687 and depends on the other end to have the up-to-date list. 1689 When the responder chooses a subset of the traffic proposed by the 1690 initiator, it narrows the traffic selectors to some subset of the 1691 initiator's proposal (provided the set does not become the null set). 1693 To enable the responder to choose the appropriate range in this case, 1694 if the initiator has requested the SA due to a data packet, the 1695 initiator SHOULD include as the first traffic selector in each of TSi 1696 and TSr a very specific traffic selector including the addresses in 1697 the packet triggering the request. In the example, the initiator 1698 would include in TSi two traffic selectors: the first containing the 1699 address range (192.0.1.43 - 192.0.1.43) and the source port and IP 1700 protocol from the packet and the second containing (192.0.1.0 - 1701 192.0.1.255) with all ports and IP protocols. The initiator would 1702 similarly include two traffic selectors in TSr. If the initiator 1703 creates the CHILD_SA pair not in response to an arriving packet, but 1704 rather, say, upon startup, then there may be no specific addresses 1705 the initiator prefers for the initial tunnel over any other. In that 1706 case, the first values in TSi and TSr can be ranges rather than 1707 specific values. 1709 The responder performs the narrowing as follows: {{ Clarif-4.10 }} 1711 o If the responder's policy does not allow it to accept any part of 1712 the proposed traffic selectors, it responds with TS_UNACCEPTABLE. 1714 o If the responder's policy allows the entire set of traffic covered 1715 by TSi and TSr, no narrowing is necessary, and the responder can 1716 return the same TSi and TSr values. 1718 o If the responder's policy allows it to accept the first selector 1719 of TSi and TSr, then the responder MUST narrow the traffic 1720 selectors to a subset that includes the initiator's first choices. 1721 In this example above, the responder might respond with TSi being 1722 (192.0.1.43 - 192.0.1.43) with all ports and IP protocols. 1724 o If the responder's policy does not allow it to accept the first 1725 selector of TSi and TSr, the responder narrows to an acceptable 1726 subset of TSi and TSr. 1728 When narrowing is done, there may be several subsets that are 1729 acceptable but their union is not. In this case, the responder 1730 arbitrarily chooses one of them, and MAY include an 1731 ADDITIONAL_TS_POSSIBLE notification in the response. {{ 3.10.1-16386 1732 }} The ADDITIONAL_TS_POSSIBLE notification asserts that the responder 1733 narrowed the proposed traffic selectors but that other traffic 1734 selectors would also have been acceptable, though only in a separate 1735 SA. There is no data associated with this Notify type. This case 1736 will occur only when the initiator and responder are configured 1737 differently from one another. If the initiator and responder agree 1738 on the granularity of tunnels, the initiator will never request a 1739 tunnel wider than the responder will accept. {{ Demoted the SHOULD }} 1740 Such misconfigurations should be recorded in error logs. 1742 It is possible for the responder's policy to contain multiple smaller 1743 ranges, all encompassed by the initiator's traffic selector, and with 1744 the responder's policy being that each of those ranges should be sent 1745 over a different SA. Continuing the example above, the responder 1746 might have a policy of being willing to tunnel those addresses to and 1747 from the initiator, but might require that each address pair be on a 1748 separately negotiated CHILD_SA. If the initiator generated its 1749 request in response to an incoming packet from 192.0.1.43 to 1750 192.0.2.123, there would be no way for the responder to determine 1751 which pair of addresses should be included in this tunnel, and it 1752 would have to make a guess or reject the request with a status of 1753 SINGLE_PAIR_REQUIRED. 1755 {{ 3.10.1-34 }} The SINGLE_PAIR_REQUIRED error indicates that a 1756 CREATE_CHILD_SA request is unacceptable because its sender is only 1757 willing to accept traffic selectors specifying a single pair of 1758 addresses. The requestor is expected to respond by requesting an SA 1759 for only the specific traffic it is trying to forward. 1761 {{ Clarif-4.11 }} Few implementations will have policies that require 1762 separate SAs for each address pair. Because of this, if only some 1763 parts of the TSi and TSr proposed by the initiator are acceptable to 1764 the responder, responders SHOULD narrow the selectors to an 1765 acceptable subset rather than use SINGLE_PAIR_REQUIRED. 1767 2.9.1. Traffic Selectors Violating Own Policy 1769 {{ Clarif-4.12 }} 1771 When creating a new SA, the initiator needs to avoid proposing 1772 traffic selectors that violate its own policy. If this rule is not 1773 followed, valid traffic may be dropped. 1775 This is best illustrated by an example. Suppose that host A has a 1776 policy whose effect is that traffic to 192.0.1.66 is sent via host B 1777 encrypted using AES, and traffic to all other hosts in 192.0.1.0/24 1778 is also sent via B, but must use 3DES. Suppose also that host B 1779 accepts any combination of AES and 3DES. 1781 If host A now proposes an SA that uses 3DES, and includes TSr 1782 containing (192.0.1.0-192.0.1.255), this will be accepted by host B. 1783 Now, host B can also use this SA to send traffic from 192.0.1.66, but 1784 those packets will be dropped by A since it requires the use of AES 1785 for those traffic. Even if host A creates a new SA only for 1786 192.0.1.66 that uses AES, host B may freely continue to use the first 1787 SA for the traffic. In this situation, when proposing the SA, host A 1788 should have followed its own policy, and included a TSr containing 1789 ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead. 1791 In general, if (1) the initiator makes a proposal "for traffic X 1792 (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator 1793 does not actually accept traffic X' with SA, and (3) the initiator 1794 would be willing to accept traffic X' with some SA' (!=SA), valid 1795 traffic can be unnecessarily dropped since the responder can apply 1796 either SA or SA' to traffic X'. 1798 2.10. Nonces 1800 The IKE_SA_INIT messages each contain a nonce. These nonces are used 1801 as inputs to cryptographic functions. The CREATE_CHILD_SA request 1802 and the CREATE_CHILD_SA response also contain nonces. These nonces 1803 are used to add freshness to the key derivation technique used to 1804 obtain keys for CHILD_SA, and to ensure creation of strong pseudo- 1805 random bits from the Diffie-Hellman key. Nonces used in IKEv2 MUST 1806 be randomly chosen, MUST be at least 128 bits in size, and MUST be at 1807 least half the key size of the negotiated prf. ("prf" refers to 1808 "pseudo-random function", one of the cryptographic algorithms 1809 negotiated in the IKE exchange.) {{ Clarif-7.4 }} However, the 1810 initiator chooses the nonce before the outcome of the negotiation is 1811 known. Because of that, the nonce has to be long enough for all the 1812 PRFs being proposed. If the same random number source is used for 1813 both keys and nonces, care must be taken to ensure that the latter 1814 use does not compromise the former. 1816 2.11. Address and Port Agility 1818 IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and 1819 AH associations for the same IP addresses it runs over. The IP 1820 addresses and ports in the outer header are, however, not themselves 1821 cryptographically protected, and IKE is designed to work even through 1822 Network Address Translation (NAT) boxes. An implementation MUST 1823 accept incoming requests even if the source port is not 500 or 4500, 1824 and MUST respond to the address and port from which the request was 1825 received. It MUST specify the address and port at which the request 1826 was received as the source address and port in the response. IKE 1827 functions identically over IPv4 or IPv6. 1829 2.12. Reuse of Diffie-Hellman Exponentials 1831 IKE generates keying material using an ephemeral Diffie-Hellman 1832 exchange in order to gain the property of "perfect forward secrecy". 1833 This means that once a connection is closed and its corresponding 1834 keys are forgotten, even someone who has recorded all of the data 1835 from the connection and gets access to all of the long-term keys of 1836 the two endpoints cannot reconstruct the keys used to protect the 1837 conversation without doing a brute force search of the session key 1838 space. 1840 Achieving perfect forward secrecy requires that when a connection is 1841 closed, each endpoint MUST forget not only the keys used by the 1842 connection but also any information that could be used to recompute 1843 those keys. In particular, it MUST forget the secrets used in the 1844 Diffie-Hellman calculation and any state that may persist in the 1845 state of a pseudo-random number generator that could be used to 1846 recompute the Diffie-Hellman secrets. 1848 Since the computing of Diffie-Hellman exponentials is computationally 1849 expensive, an endpoint may find it advantageous to reuse those 1850 exponentials for multiple connection setups. There are several 1851 reasonable strategies for doing this. An endpoint could choose a new 1852 exponential only periodically though this could result in less-than- 1853 perfect forward secrecy if some connection lasts for less than the 1854 lifetime of the exponential. Or it could keep track of which 1855 exponential was used for each connection and delete the information 1856 associated with the exponential only when some corresponding 1857 connection was closed. This would allow the exponential to be reused 1858 without losing perfect forward secrecy at the cost of maintaining 1859 more state. 1861 Decisions as to whether and when to reuse Diffie-Hellman exponentials 1862 is a private decision in the sense that it will not affect 1863 interoperability. An implementation that reuses exponentials MAY 1864 choose to remember the exponential used by the other endpoint on past 1865 exchanges and if one is reused to avoid the second half of the 1866 calculation. 1868 2.13. Generating Keying Material 1870 In the context of the IKE_SA, four cryptographic algorithms are 1871 negotiated: an encryption algorithm, an integrity protection 1872 algorithm, a Diffie-Hellman group, and a pseudo-random function 1873 (prf). The pseudo-random function is used for the construction of 1874 keying material for all of the cryptographic algorithms used in both 1875 the IKE_SA and the CHILD_SAs. 1877 We assume that each encryption algorithm and integrity protection 1878 algorithm uses a fixed-size key and that any randomly chosen value of 1879 that fixed size can serve as an appropriate key. For algorithms that 1880 accept a variable length key, a fixed key size MUST be specified as 1881 part of the cryptographic transform negotiated (see Section 3.3.5 for 1882 the defintion of the Key Length transform attribute). For algorithms 1883 for which not all values are valid keys (such as DES or 3DES with key 1884 parity), the algorithm by which keys are derived from arbitrary 1885 values MUST be specified by the cryptographic transform. For 1886 integrity protection functions based on Hashed Message Authentication 1887 Code (HMAC), the fixed key size is the size of the output of the 1888 underlying hash function. 1890 It is assumed that pseudo-random functions (PRFs) accept keys of any 1891 length, but have a preferred key size. The preferred key size is 1892 used as the length of SK_d, SK_pi, and SK_pr (see Section 2.14). For 1893 PRFs based on the HMAC construction, the preferred key size is equal 1894 to the length of the output of the underlying hash function. Other 1895 types of PRFs MUST specify their preferred key size. 1897 Keying material will always be derived as the output of the 1898 negotiated prf algorithm. Since the amount of keying material needed 1899 may be greater than the size of the output of the prf algorithm, we 1900 will use the prf iteratively. We will use the terminology prf+ to 1901 describe the function that outputs a pseudo-random stream based on 1902 the inputs to a prf as follows: (where | indicates concatenation) 1904 prf+ (K,S) = T1 | T2 | T3 | T4 | ... 1906 where: 1907 T1 = prf (K, S | 0x01) 1908 T2 = prf (K, T1 | S | 0x02) 1909 T3 = prf (K, T2 | S | 0x03) 1910 T4 = prf (K, T3 | S | 0x04) 1912 continuing as needed to compute all required keys. The keys are 1913 taken from the output string without regard to boundaries (e.g., if 1914 the required keys are a 256-bit Advanced Encryption Standard (AES) 1915 key and a 160-bit HMAC key, and the prf function generates 160 bits, 1916 the AES key will come from T1 and the beginning of T2, while the HMAC 1917 key will come from the rest of T2 and the beginning of T3). 1919 The constant concatenated to the end of each string feeding the prf 1920 is a single octet. prf+ in this document is not defined beyond 255 1921 times the size of the prf output. 1923 2.14. Generating Keying Material for the IKE_SA 1925 The shared keys are computed as follows. A quantity called SKEYSEED 1926 is calculated from the nonces exchanged during the IKE_SA_INIT 1927 exchange and the Diffie-Hellman shared secret established during that 1928 exchange. SKEYSEED is used to calculate seven other secrets: SK_d 1929 used for deriving new keys for the CHILD_SAs established with this 1930 IKE_SA; SK_ai and SK_ar used as a key to the integrity protection 1931 algorithm for authenticating the component messages of subsequent 1932 exchanges; SK_ei and SK_er used for encrypting (and of course 1933 decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are 1934 used when generating an AUTH payload. The lengths of SK_d, SK_pi, 1935 and SK_pr are the preferred key length of the agreed-to PRF. 1937 SKEYSEED and its derivatives are computed as follows: 1939 SKEYSEED = prf(Ni | Nr, g^ir) 1941 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } 1942 = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) 1944 (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, 1945 SK_pi, and SK_pr are taken in order from the generated bits of the 1946 prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman 1947 exchange. g^ir is represented as a string of octets in big endian 1948 order padded with zeros if necessary to make it the length of the 1949 modulus. Ni and Nr are the nonces, stripped of any headers. For 1950 historical backwards-compatibility reasons, there are two PRFs that 1951 are treated specially in this calculation. If the negotiated PRF is 1952 AES-XCBC-PRF-128 [RFC4434] or AES-CMAC-PRF-128 [RFC4615], only the 1953 first 64 bits of Ni and the first 64 bits of Nr are used in the 1954 calculation. 1956 The two directions of traffic flow use different keys. The keys used 1957 to protect messages from the original initiator are SK_ai and SK_ei. 1958 The keys used to protect messages in the other direction are SK_ar 1959 and SK_er. 1961 2.15. Authentication of the IKE_SA 1963 When not using extensible authentication (see Section 2.16), the 1964 peers are authenticated by having each sign (or MAC using a shared 1965 secret as the key) a block of data. For the responder, the octets to 1966 be signed start with the first octet of the first SPI in the header 1967 of the second message (IKE_SA_INIT response) and end with the last 1968 octet of the last payload in the second message. Appended to this 1969 (for purposes of computing the signature) are the initiator's nonce 1970 Ni (just the value, not the payload containing it), and the value 1971 prf(SK_pr,IDr') where IDr' is the responder's ID payload excluding 1972 the fixed header. Note that neither the nonce Ni nor the value 1973 prf(SK_pr,IDr') are transmitted. Similarly, the initiator signs the 1974 first message (IKE_SA_INIT request), starting with the first octet of 1975 the first SPI in the header and ending with the last octet of the 1976 last payload. Appended to this (for purposes of computing the 1977 signature) are the responder's nonce Nr, and the value 1978 prf(SK_pi,IDi'). In the above calculation, IDi' and IDr' are the 1979 entire ID payloads excluding the fixed header. It is critical to the 1980 security of the exchange that each side sign the other side's nonce. 1982 {{ Clarif-3.1 }} 1984 The initiator's signed octets can be described as: 1986 InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI 1987 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR 1988 RealIKEHDR = SPIi | SPIr | . . . | Length 1989 RealMessage1 = RealIKEHDR | RestOfMessage1 1990 NonceRPayload = PayloadHeader | NonceRData 1991 InitiatorIDPayload = PayloadHeader | RestOfIDPayload 1992 RestOfInitIDPayload = IDType | RESERVED | InitIDData 1993 MACedIDForI = prf(SK_pi, RestOfInitIDPayload) 1995 The responder's signed octets can be described as: 1997 ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR 1998 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR 1999 RealIKEHDR = SPIi | SPIr | . . . | Length 2000 RealMessage2 = RealIKEHDR | RestOfMessage2 2001 NonceIPayload = PayloadHeader | NonceIData 2002 ResponderIDPayload = PayloadHeader | RestOfIDPayload 2003 RestOfRespIDPayload = IDType | RESERVED | InitIDData 2004 MACedIDForR = prf(SK_pr, RestOfRespIDPayload) 2006 Note that all of the payloads are included under the signature, 2007 including any payload types not defined in this document. If the 2008 first message of the exchange is sent twice (the second time with a 2009 responder cookie and/or a different Diffie-Hellman group), it is the 2010 second version of the message that is signed. 2012 Optionally, messages 3 and 4 MAY include a certificate, or 2013 certificate chain providing evidence that the key used to compute a 2014 digital signature belongs to the name in the ID payload. The 2015 signature or MAC will be computed using algorithms dictated by the 2016 type of key used by the signer, and specified by the Auth Method 2017 field in the Authentication payload. There is no requirement that 2018 the initiator and responder sign with the same cryptographic 2019 algorithms. The choice of cryptographic algorithms depends on the 2020 type of key each has. In particular, the initiator may be using a 2021 shared key while the responder may have a public signature key and 2022 certificate. It will commonly be the case (but it is not required) 2023 that if a shared secret is used for authentication that the same key 2024 is used in both directions. 2026 Note that it is a common but typically insecure practice to have a 2027 shared key derived solely from a user-chosen password without 2028 incorporating another source of randomness. This is typically 2029 insecure because user-chosen passwords are unlikely to have 2030 sufficient unpredictability to resist dictionary attacks and these 2031 attacks are not prevented in this authentication method. 2032 (Applications using password-based authentication for bootstrapping 2033 and IKE_SA should use the authentication method in Section 2.16, 2034 which is designed to prevent off-line dictionary attacks.) {{ Demoted 2035 the SHOULD }} The pre-shared key needs to contain as much 2036 unpredictability as the strongest key being negotiated. In the case 2037 of a pre-shared key, the AUTH value is computed as: 2039 AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), ) 2041 where the string "Key Pad for IKEv2" is 17 ASCII characters without 2042 null termination. The shared secret can be variable length. The pad 2043 string is added so that if the shared secret is derived from a 2044 password, the IKE implementation need not store the password in 2045 cleartext, but rather can store the value prf(Shared Secret,"Key Pad 2046 for IKEv2"), which could not be used as a password equivalent for 2047 protocols other than IKEv2. As noted above, deriving the shared 2048 secret from a password is not secure. This construction is used 2049 because it is anticipated that people will do it anyway. The 2050 management interface by which the Shared Secret is provided MUST 2051 accept ASCII strings of at least 64 octets and MUST NOT add a null 2052 terminator before using them as shared secrets. It MUST also accept 2053 a hex encoding of the Shared Secret. The management interface MAY 2054 accept other encodings if the algorithm for translating the encoding 2055 to a binary string is specified. 2057 2.16. Extensible Authentication Protocol Methods 2059 In addition to authentication using public key signatures and shared 2060 secrets, IKE supports authentication using methods defined in RFC 2061 3748 [EAP]. Typically, these methods are asymmetric (designed for a 2062 user authenticating to a server), and they may not be mutual. {{ In 2063 the next sentence, changed "public key signature based" to "strong" 2064 }} For this reason, these protocols are typically used to 2065 authenticate the initiator to the responder and MUST be used in 2066 conjunction with a strong authentication of the responder to the 2067 initiator. These methods are often associated with mechanisms 2068 referred to as "Legacy Authentication" mechanisms. 2070 While this memo references [EAP] with the intent that new methods can 2071 be added in the future without updating this specification, some 2072 simpler variations are documented here and in Section 3.16. [EAP] 2073 defines an authentication protocol requiring a variable number of 2074 messages. Extensible Authentication is implemented in IKE as 2075 additional IKE_AUTH exchanges that MUST be completed in order to 2076 initialize the IKE_SA. 2078 An initiator indicates a desire to use extensible authentication by 2079 leaving out the AUTH payload from message 3. By including an IDi 2080 payload but not an AUTH payload, the initiator has declared an 2081 identity but has not proven it. If the responder is willing to use 2082 an extensible authentication method, it will place an Extensible 2083 Authentication Protocol (EAP) payload in message 4 and defer sending 2084 SAr2, TSi, and TSr until initiator authentication is complete in a 2085 subsequent IKE_AUTH exchange. In the case of a minimal extensible 2086 authentication, the initial SA establishment will appear as follows: 2088 Initiator Responder 2089 ------------------------------------------------------------------- 2090 HDR, SAi1, KEi, Ni --> 2091 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 2092 HDR, SK {IDi, [CERTREQ,] 2093 [IDr,] SAi2, 2094 TSi, TSr} --> 2095 <-- HDR, SK {IDr, [CERT,] AUTH, 2096 EAP } 2097 HDR, SK {EAP} --> 2098 <-- HDR, SK {EAP (success)} 2099 HDR, SK {AUTH} --> 2100 <-- HDR, SK {AUTH, SAr2, TSi, TSr } 2102 {{ Clarif-3.10 }} As described in Section 2.2, when EAP is used, each 2103 pair of IKE_SA initial setup messages will have their message numbers 2104 incremented; the first pair of AUTH messages will have an ID of 1, 2105 the second will be 2, and so on. 2107 For EAP methods that create a shared key as a side effect of 2108 authentication, that shared key MUST be used by both the initiator 2109 and responder to generate AUTH payloads in messages 7 and 8 using the 2110 syntax for shared secrets specified in Section 2.15. The shared key 2111 from EAP is the field from the EAP specification named MSK. The 2112 shared key generated during an IKE exchange MUST NOT be used for any 2113 other purpose. 2115 EAP methods that do not establish a shared key SHOULD NOT be used, as 2116 they are subject to a number of man-in-the-middle attacks [EAPMITM] 2117 if these EAP methods are used in other protocols that do not use a 2118 server-authenticated tunnel. Please see the Security Considerations 2119 section for more details. If EAP methods that do not generate a 2120 shared key are used, the AUTH payloads in messages 7 and 8 MUST be 2121 generated using SK_pi and SK_pr, respectively. 2123 {{ Demoted the SHOULD }} The initiator of an IKE_SA using EAP needs 2124 to be capable of extending the initial protocol exchange to at least 2125 ten IKE_AUTH exchanges in the event the responder sends notification 2126 messages and/or retries the authentication prompt. Once the protocol 2127 exchange defined by the chosen EAP authentication method has 2128 successfully terminated, the responder MUST send an EAP payload 2129 containing the Success message. Similarly, if the authentication 2130 method has failed, the responder MUST send an EAP payload containing 2131 the Failure message. The responder MAY at any time terminate the IKE 2132 exchange by sending an EAP payload containing the Failure message. 2134 Following such an extended exchange, the EAP AUTH payloads MUST be 2135 included in the two messages following the one containing the EAP 2136 Success message. 2138 {{ Clarif-3.5 }} When the initiator authentication uses EAP, it is 2139 possible that the contents of the IDi payload is used only for AAA 2140 routing purposes and selecting which EAP method to use. This value 2141 may be different from the identity authenticated by the EAP method. 2142 It is important that policy lookups and access control decisions use 2143 the actual authenticated identity. Often the EAP server is 2144 implemented in a separate AAA server that communicates with the IKEv2 2145 responder. In this case, the authenticated identity has to be sent 2146 from the AAA server to the IKEv2 responder. 2148 2.17. Generating Keying Material for CHILD_SAs 2150 A single CHILD_SA is created by the IKE_AUTH exchange, and additional 2151 CHILD_SAs can optionally be created in CREATE_CHILD_SA exchanges. 2152 Keying material for them is generated as follows: 2154 KEYMAT = prf+(SK_d, Ni | Nr) 2156 Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this 2157 request is the first CHILD_SA created or the fresh Ni and Nr from the 2158 CREATE_CHILD_SA exchange if this is a subsequent creation. 2160 For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman 2161 exchange, the keying material is defined as: 2163 KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr ) 2165 where g^ir (new) is the shared secret from the ephemeral Diffie- 2166 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 2167 octet string in big endian order padded with zeros in the high-order 2168 bits if necessary to make it the length of the modulus). 2170 For ESP and AH, a single CHILD_SA negotiation results in two security 2171 associations (one in each direction). Keying material MUST be taken 2172 from the expanded KEYMAT in the following order: 2174 o The encryption key (if any) for the SA carrying data from the 2175 initiator to the responder. 2177 o The authentication key (if any) for the SA carrying data from the 2178 initiator to the responder. 2180 o The encryption key (if any) for the SA carrying data from the 2181 responder to the initiator. 2183 o The authentication key (if any) for the SA carrying data from the 2184 responder to the initiator. 2186 Each cryptographic algorithm takes a fixed number of bits of keying 2187 material specified as part of the algorithm, or negotiated in SA 2188 payloads (see Section 2.13 for description of key lengths, and 2189 Section 3.3.5 for the definition of the Key Length transform 2190 attribute). 2192 2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA Exchange 2194 The CREATE_CHILD_SA exchange can be used to rekey an existing IKE_SA 2195 (see Section 2.8). {{ Clarif-5.3 }} New initiator and responder SPIs 2196 are supplied in the SPI fields in the Proposal structures inside the 2197 Security Association (SA) payloads (not the SPI fields in the IKE 2198 header). The TS payloads are omitted when rekeying an IKE_SA. 2199 SKEYSEED for the new IKE_SA is computed using SK_d from the existing 2200 IKE_SA as follows: 2202 SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr) 2204 where g^ir (new) is the shared secret from the ephemeral Diffie- 2205 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 2206 octet string in big endian order padded with zeros if necessary to 2207 make it the length of the modulus) and Ni and Nr are the two nonces 2208 stripped of any headers. 2210 {{ Clarif-5.5 }} The old and new IKE_SA may have selected a different 2211 PRF. Because the rekeying exchange belongs to the old IKE_SA, it is 2212 the old IKE_SA's PRF that is used. 2214 {{ Clarif-5.12}} The main purpose of rekeying the IKE_SA is to ensure 2215 that the compromise of old keying material does not provide 2216 information about the current keys, or vice versa. Therefore, 2217 implementations SHOULD perform a new Diffie-Hellman exchange when 2218 rekeying the IKE_SA. In other words, an initiator SHOULD NOT propose 2219 the value "NONE" for the D-H transform, and a responder SHOULD NOT 2220 accept such a proposal. This means that a succesful exchange 2221 rekeying the IKE_SA always includes the KEi/KEr payloads. 2223 The new IKE_SA MUST reset its message counters to 0. 2225 SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as 2226 specified in Section 2.14. 2228 2.19. Requesting an Internal Address on a Remote Network 2230 Most commonly occurring in the endpoint-to-security-gateway scenario, 2231 an endpoint may need an IP address in the network protected by the 2232 security gateway and may need to have that address dynamically 2233 assigned. A request for such a temporary address can be included in 2234 any request to create a CHILD_SA (including the implicit request in 2235 message 3) by including a CP payload. 2237 This function provides address allocation to an IPsec Remote Access 2238 Client (IRAC) trying to tunnel into a network protected by an IPsec 2239 Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an 2240 IKE_SA and a CHILD_SA, the IRAC MUST request the IRAS-controlled 2241 address (and optionally other information concerning the protected 2242 network) in the IKE_AUTH exchange. The IRAS may procure an address 2243 for the IRAC from any number of sources such as a DHCP/BOOTP server 2244 or its own address pool. 2246 Initiator Responder 2247 ------------------------------------------------------------------- 2248 HDR, SK {IDi, [CERT,] 2249 [CERTREQ,] [IDr,] AUTH, 2250 CP(CFG_REQUEST), SAi2, 2251 TSi, TSr} --> 2252 <-- HDR, SK {IDr, [CERT,] AUTH, 2253 CP(CFG_REPLY), SAr2, 2254 TSi, TSr} 2256 In all cases, the CP payload MUST be inserted before the SA payload. 2257 In variations of the protocol where there are multiple IKE_AUTH 2258 exchanges, the CP payloads MUST be inserted in the messages 2259 containing the SA payloads. 2261 CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute 2262 (either IPv4 or IPv6) but MAY contain any number of additional 2263 attributes the initiator wants returned in the response. 2265 {{ 3.10.1-37 }} The FAILED_CP_REQUIRED notification is sent by 2266 responder in the case where CP(CFG_REQUEST) was expected but not 2267 received, and so is a conflict with locally configured policy. There 2268 is no associated data. 2270 For example, message from initiator to responder: 2272 CP(CFG_REQUEST)= 2273 INTERNAL_ADDRESS() 2274 TSi = (0, 0-65535,0.0.0.0-255.255.255.255) 2275 TSr = (0, 0-65535,0.0.0.0-255.255.255.255) 2277 NOTE: Traffic Selectors contain (protocol, port range, address 2278 range). 2280 Message from responder to initiator: 2282 CP(CFG_REPLY)= 2283 INTERNAL_ADDRESS(192.0.2.202) 2284 INTERNAL_NETMASK(255.255.255.0) 2285 INTERNAL_SUBNET(192.0.2.0/255.255.255.0) 2286 TSi = (0, 0-65535,192.0.2.202-192.0.2.202) 2287 TSr = (0, 0-65535,192.0.2.0-192.0.2.255) 2289 All returned values will be implementation dependent. As can be seen 2290 in the above example, the IRAS MAY also send other attributes that 2291 were not included in CP(CFG_REQUEST) and MAY ignore the non- 2292 mandatory attributes that it does not support. 2294 The responder MUST NOT send a CFG_REPLY without having first received 2295 a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS 2296 to perform an unnecessary configuration lookup if the IRAC cannot 2297 process the REPLY. In the case where the IRAS's configuration 2298 requires that CP be used for a given identity IDi, but IRAC has 2299 failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and 2300 terminate the IKE exchange with a FAILED_CP_REQUIRED error. 2302 2.19.1. Configuration Payloads 2304 Editor's note: some of this sub-section is redundant and will go away 2305 in the next version of the document. 2307 In support of the scenario described in Section 1.1.3, an initiator 2308 may request that the responder assign an IP address and tell the 2309 initiator what it is. {{ Clarif-6.1 }} That request is done using 2310 configuration payloads, not traffic selectors. An address in a TSi 2311 payload in a response does not mean that the responder has assigned 2312 that address to the initiator: it only means that if packets matching 2313 these traffic selectors are sent by the initiator, IPsec processing 2314 can be performed as agreed for this SA. 2316 Configuration payloads are of type CFG_REQUEST/CFG_REPLY or CFG_SET/ 2317 CFG_ACK (see CFG Type in the payload description below). CFG_REQUEST 2318 and CFG_SET payloads may optionally be added to any IKE request. The 2319 IKE response MUST include either a corresponding CFG_REPLY or CFG_ACK 2320 or a Notify payload with an error type indicating why the request 2321 could not be honored. An exception is that a minimal implementation 2322 MAY ignore all CFG_REQUEST and CFG_SET payloads, so a response 2323 message without a corresponding CFG_REPLY or CFG_ACK MUST be accepted 2324 as an indication that the request was not supported. 2326 "CFG_REQUEST/CFG_REPLY" allows an IKE endpoint to request information 2327 from its peer. If an attribute in the CFG_REQUEST Configuration 2328 Payload is not zero-length, it is taken as a suggestion for that 2329 attribute. The CFG_REPLY Configuration Payload MAY return that 2330 value, or a new one. It MAY also add new attributes and not include 2331 some requested ones. Requestors MUST ignore returned attributes that 2332 they do not recognize. 2334 Some attributes MAY be multi-valued, in which case multiple attribute 2335 values of the same type are sent and/or returned. Generally, all 2336 values of an attribute are returned when the attribute is requested. 2337 For some attributes (in this version of the specification only 2338 internal addresses), multiple requests indicates a request that 2339 multiple values be assigned. For these attributes, the number of 2340 values returned SHOULD NOT exceed the number requested. 2342 If the data type requested in a CFG_REQUEST is not recognized or not 2343 supported, the responder MUST NOT return an error type but rather 2344 MUST either send a CFG_REPLY that MAY be empty or a reply not 2345 containing a CFG_REPLY payload at all. Error returns are reserved 2346 for cases where the request is recognized but cannot be performed as 2347 requested or the request is badly formatted. 2349 "CFG_SET/CFG_ACK" allows an IKE endpoint to push configuration data 2350 to its peer. In this case, the CFG_SET Configuration Payload 2351 contains attributes the initiator wants its peer to alter. The 2352 responder MUST return a Configuration Payload if it accepted any of 2353 the configuration data and it MUST contain the attributes that the 2354 responder accepted with zero-length data. Those attributes that it 2355 did not accept MUST NOT be in the CFG_ACK Configuration Payload. If 2356 no attributes were accepted, the responder MUST return either an 2357 empty CFG_ACK payload or a response message without a CFG_ACK 2358 payload. There are currently no defined uses for the CFG_SET/CFG_ACK 2359 exchange, though they may be used in connection with extensions based 2360 on Vendor IDs. An minimal implementation of this specification MAY 2361 ignore CFG_SET payloads. 2363 {{ Demoted the SHOULD }} Extensions via the CP payload should not be 2364 used for general purpose management. Its main intent is to provide a 2365 bootstrap mechanism to exchange information within IPsec from IRAS to 2366 IRAC. While it MAY be useful to use such a method to exchange 2367 information between some Security Gateways (SGW) or small networks, 2368 existing management protocols such as DHCP [DHCP], RADIUS [RADIUS], 2369 SNMP, or LDAP [LDAP] should be preferred for enterprise management as 2370 well as subsequent information exchanges. 2372 2.20. Requesting the Peer's Version 2374 An IKE peer wishing to inquire about the other peer's IKE software 2375 version information MAY use the method below. This is an example of 2376 a configuration request within an INFORMATIONAL exchange, after the 2377 IKE_SA and first CHILD_SA have been created. 2379 An IKE implementation MAY decline to give out version information 2380 prior to authentication or even after authentication to prevent 2381 trolling in case some implementation is known to have some security 2382 weakness. In that case, it MUST either return an empty string or no 2383 CP payload if CP is not supported. 2385 Initiator Responder 2386 ------------------------------------------------------------------- 2387 HDR, SK{CP(CFG_REQUEST)} --> 2388 <-- HDR, SK{CP(CFG_REPLY)} 2390 CP(CFG_REQUEST)= 2391 APPLICATION_VERSION("") 2393 CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar 2394 Inc.") 2396 2.21. Error Handling 2398 There are many kinds of errors that can occur during IKE processing. 2399 If a request is received that is badly formatted or unacceptable for 2400 reasons of policy (e.g., no matching cryptographic algorithms), the 2401 response MUST contain a Notify payload indicating the error. If an 2402 error occurs outside the context of an IKE request (e.g., the node is 2403 getting ESP messages on a nonexistent SPI), the node SHOULD initiate 2404 an INFORMATIONAL exchange with a Notify payload describing the 2405 problem. 2407 Errors that occur before a cryptographically protected IKE_SA is 2408 established must be handled very carefully. There is a trade-off 2409 between wanting to be helpful in diagnosing a problem and responding 2410 to it and wanting to avoid being a dupe in a denial of service attack 2411 based on forged messages. 2413 If a node receives a message on UDP port 500 or 4500 outside the 2414 context of an IKE_SA known to it (and not a request to start one), it 2415 may be the result of a recent crash of the node. If the message is 2416 marked as a response, the node MAY audit the suspicious event but 2417 MUST NOT respond. If the message is marked as a request, the node 2418 MAY audit the suspicious event and MAY send a response. If a 2419 response is sent, the response MUST be sent to the IP address and 2420 port from whence it came with the same IKE SPIs and the Message ID 2421 copied. The response MUST NOT be cryptographically protected and 2422 MUST contain a Notify payload indicating INVALID_IKE_SPI. {{ 3.10.1-4 2423 }} The INVALID_IKE_SPI notification indicates an IKE message was 2424 received with an unrecognized destination SPI; this usually indicates 2425 that the recipient has rebooted and forgotten the existence of an 2426 IKE_SA. 2428 A node receiving such an unprotected Notify payload MUST NOT respond 2429 and MUST NOT change the state of any existing SAs. The message might 2430 be a forgery or might be a response the genuine correspondent was 2431 tricked into sending. {{ Demoted two SHOULDs }} A node should treat 2432 such a message (and also a network message like ICMP destination 2433 unreachable) as a hint that there might be problems with SAs to that 2434 IP address and should initiate a liveness test for any such IKE_SA. 2435 An implementation SHOULD limit the frequency of such tests to avoid 2436 being tricked into participating in a denial of service attack. 2438 A node receiving a suspicious message from an IP address with which 2439 it has an IKE_SA MAY send an IKE Notify payload in an IKE 2440 INFORMATIONAL exchange over that SA. {{ Demoted the SHOULD }} The 2441 recipient MUST NOT change the state of any SAs as a result, but may 2442 wish to audit the event to aid in diagnosing malfunctions. A node 2443 MUST limit the rate at which it will send messages in response to 2444 unprotected messages. 2446 2.22. IPComp 2448 Use of IP compression [IPCOMP] can be negotiated as part of the setup 2449 of a CHILD_SA. While IP compression involves an extra header in each 2450 packet and a compression parameter index (CPI), the virtual 2451 "compression association" has no life outside the ESP or AH SA that 2452 contains it. Compression associations disappear when the 2453 corresponding ESP or AH SA goes away. It is not explicitly mentioned 2454 in any DELETE payload. 2456 Negotiation of IP compression is separate from the negotiation of 2457 cryptographic parameters associated with a CHILD_SA. A node 2458 requesting a CHILD_SA MAY advertise its support for one or more 2459 compression algorithms through one or more Notify payloads of type 2460 IPCOMP_SUPPORTED. This notification may be included only in a 2461 message containing an SA payload negotiating a CHILD_SA and indicates 2462 a willingness by its sender to use IPComp on this SA. The response 2463 MAY indicate acceptance of a single compression algorithm with a 2464 Notify payload of type IPCOMP_SUPPORTED. These payloads MUST NOT 2465 occur in messages that do not contain SA payloads. 2467 {{ 3.10.1-16387 }}The data associated with this notification includes 2468 a two-octet IPComp CPI followed by a one-octet transform ID 2469 optionally followed by attributes whose length and format are defined 2470 by that transform ID. A message proposing an SA may contain multiple 2471 IPCOMP_SUPPORTED notifications to indicate multiple supported 2472 algorithms. A message accepting an SA may contain at most one. 2474 The transform IDs currently defined are: 2476 Name Number Defined In 2477 ------------------------------------- 2478 RESERVED 0 2479 IPCOMP_OUI 1 2480 IPCOMP_DEFLATE 2 RFC 2394 2481 IPCOMP_LZS 3 RFC 2395 2482 IPCOMP_LZJH 4 RFC 3051 2483 RESERVED TO IANA 5-240 2484 PRIVATE USE 241-255 2486 Although there has been discussion of allowing multiple compression 2487 algorithms to be accepted and to have different compression 2488 algorithms available for the two directions of a CHILD_SA, 2489 implementations of this specification MUST NOT accept an IPComp 2490 algorithm that was not proposed, MUST NOT accept more than one, and 2491 MUST NOT compress using an algorithm other than one proposed and 2492 accepted in the setup of the CHILD_SA. 2494 A side effect of separating the negotiation of IPComp from 2495 cryptographic parameters is that it is not possible to propose 2496 multiple cryptographic suites and propose IP compression with some of 2497 them but not others. 2499 2.23. NAT Traversal 2501 Network Address Translation (NAT) gateways are a controversial 2502 subject. This section briefly describes what they are and how they 2503 are likely to act on IKE traffic. Many people believe that NATs are 2504 evil and that we should not design our protocols so as to make them 2505 work better. IKEv2 does specify some unintuitive processing rules in 2506 order that NATs are more likely to work. 2508 NATs exist primarily because of the shortage of IPv4 addresses, 2509 though there are other rationales. IP nodes that are "behind" a NAT 2510 have IP addresses that are not globally unique, but rather are 2511 assigned from some space that is unique within the network behind the 2512 NAT but that are likely to be reused by nodes behind other NATs. 2513 Generally, nodes behind NATs can communicate with other nodes behind 2514 the same NAT and with nodes with globally unique addresses, but not 2515 with nodes behind other NATs. There are exceptions to that rule. 2516 When those nodes make connections to nodes on the real Internet, the 2517 NAT gateway "translates" the IP source address to an address that 2518 will be routed back to the gateway. Messages to the gateway from the 2519 Internet have their destination addresses "translated" to the 2520 internal address that will route the packet to the correct endnode. 2522 NATs are designed to be "transparent" to endnodes. Neither software 2523 on the node behind the NAT nor the node on the Internet requires 2524 modification to communicate through the NAT. Achieving this 2525 transparency is more difficult with some protocols than with others. 2526 Protocols that include IP addresses of the endpoints within the 2527 payloads of the packet will fail unless the NAT gateway understands 2528 the protocol and modifies the internal references as well as those in 2529 the headers. Such knowledge is inherently unreliable, is a network 2530 layer violation, and often results in subtle problems. 2532 Opening an IPsec connection through a NAT introduces special 2533 problems. If the connection runs in transport mode, changing the IP 2534 addresses on packets will cause the checksums to fail and the NAT 2535 cannot correct the checksums because they are cryptographically 2536 protected. Even in tunnel mode, there are routing problems because 2537 transparently translating the addresses of AH and ESP packets 2538 requires special logic in the NAT and that logic is heuristic and 2539 unreliable in nature. For that reason, IKEv2 can negotiate UDP 2540 encapsulation of IKE and ESP packets. This encoding is slightly less 2541 efficient but is easier for NATs to process. In addition, firewalls 2542 may be configured to pass IPsec traffic over UDP but not ESP/AH or 2543 vice versa. 2545 It is a common practice of NATs to translate TCP and UDP port numbers 2546 as well as addresses and use the port numbers of inbound packets to 2547 decide which internal node should get a given packet. For this 2548 reason, even though IKE packets MUST be sent from and to UDP port 2549 500, they MUST be accepted coming from any port and responses MUST be 2550 sent to the port from whence they came. This is because the ports 2551 may be modified as the packets pass through NATs. Similarly, IP 2552 addresses of the IKE endpoints are generally not included in the IKE 2553 payloads because the payloads are cryptographically protected and 2554 could not be transparently modified by NATs. 2556 Port 4500 is reserved for UDP-encapsulated ESP and IKE. When working 2557 through a NAT, it is generally better to pass IKE packets over port 2558 4500 because some older NATs handle IKE traffic on port 500 cleverly 2559 in an attempt to transparently establish IPsec connections between 2560 endpoints that don't handle NAT traversal themselves. Such NATs may 2561 interfere with the straightforward NAT traversal envisioned by this 2562 document. {{ Clarif-7.6 }} An IPsec endpoint that discovers a NAT 2563 between it and its correspondent MUST send all subsequent traffic 2564 from port 4500, which NATs should not treat specially (as they might 2565 with port 500). 2567 The specific requirements for supporting NAT traversal [NATREQ] are 2568 listed below. Support for NAT traversal is optional. In this 2569 section only, requirements listed as MUST apply only to 2570 implementations supporting NAT traversal. 2572 o IKE MUST listen on port 4500 as well as port 500. IKE MUST 2573 respond to the IP address and port from which packets arrived. 2575 o Both IKE initiator and responder MUST include in their IKE_SA_INIT 2576 packets Notify payloads of type NAT_DETECTION_SOURCE_IP and 2577 NAT_DETECTION_DESTINATION_IP. Those payloads can be used to 2578 detect if there is NAT between the hosts, and which end is behind 2579 the NAT. The location of the payloads in the IKE_SA_INIT packets 2580 are just after the Ni and Nr payloads (before the optional CERTREQ 2581 payload). 2583 o {{ 3.10.1-16388 }} The data associated with the 2584 NAT_DETECTION_SOURCE_IP notification is a SHA-1 digest of the SPIs 2585 (in the order they appear in the header), IP address, and port on 2586 which this packet was sent. There MAY be multiple 2587 NAT_DETECTION_SOURCE_IP payloads in a message if the sender does 2588 not know which of several network attachments will be used to send 2589 the packet. 2591 o {{ 3.10.1-16389 }} The data associated with the 2592 NAT_DETECTION_DESTINATION_IP notification is a SHA-1 digest of the 2593 SPIs (in the order they appear in the header), IP address, and 2594 port to which this packet was sent. 2596 o {{ 3.10.1-16388 }} {{ 3.10.1-16389 }} The recipient of either the 2597 NAT_DETECTION_SOURCE_IP or NAT_DETECTION_DESTINATION_IP 2598 notification MAY compare the supplied value to a SHA-1 hash of the 2599 SPIs, source IP address, and port, and if they don't match it 2600 SHOULD enable NAT traversal. In the case of a mismatching 2601 NAT_DETECTION_SOURCE_IP hash, the recipient MAY reject the 2602 connection attempt if NAT traversal is not supported. In the case 2603 of a mismatching NAT_DETECTION_DESTINATION_IP hash, it means that 2604 the system receiving the NAT_DETECTION_DESTINATION_IP payload is 2605 behind a NAT and that system SHOULD start sending keepalive 2606 packets as defined in [UDPENCAPS]; alternately, it MAY reject the 2607 connection attempt if NAT traversal is not supported. 2609 o If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches 2610 the expected value of the source IP and port found from the IP 2611 header of the packet containing the payload, it means that the 2612 system sending those payloads is behind NAT (i.e., someone along 2613 the route changed the source address of the original packet to 2614 match the address of the NAT box). In this case, the system 2615 receiving the payloads should allow dynamic update of the other 2616 systems' IP address, as described later. 2618 o If the NAT_DETECTION_DESTINATION_IP payload received does not 2619 match the hash of the destination IP and port found from the IP 2620 header of the packet containing the payload, it means that the 2621 system receiving the NAT_DETECTION_DESTINATION_IP payload is 2622 behind a NAT. In this case, that system SHOULD start sending 2623 keepalive packets as explained in [UDPENCAPS]. 2625 o The IKE initiator MUST check these payloads if present and if they 2626 do not match the addresses in the outer packet MUST tunnel all 2627 future IKE and ESP packets associated with this IKE_SA over UDP 2628 port 4500. 2630 o To tunnel IKE packets over UDP port 4500, the IKE header has four 2631 octets of zero prepended and the result immediately follows the 2632 UDP header. To tunnel ESP packets over UDP port 4500, the ESP 2633 header immediately follows the UDP header. Since the first four 2634 octets of the ESP header contain the SPI, and the SPI cannot 2635 validly be zero, it is always possible to distinguish ESP and IKE 2636 messages. 2638 o Implementations MUST process received UDP-encapsulated ESP packets 2639 even when no NAT was detected. 2641 o The original source and destination IP address required for the 2642 transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) 2643 are obtained from the Traffic Selectors associated with the 2644 exchange. In the case of NAT traversal, the Traffic Selectors 2645 MUST contain exactly one IP address, which is then used as the 2646 original IP address. 2648 o There are cases where a NAT box decides to remove mappings that 2649 are still alive (for example, the keepalive interval is too long, 2650 or the NAT box is rebooted). To recover in these cases, hosts 2651 that are not behind a NAT SHOULD send all packets (including 2652 retransmission packets) to the IP address and port from the last 2653 valid authenticated packet from the other end (i.e., dynamically 2654 update the address). A host behind a NAT SHOULD NOT do this 2655 because it opens a DoS attack possibility. Any authenticated IKE 2656 packet or any authenticated UDP-encapsulated ESP packet can be 2657 used to detect that the IP address or the port has changed. 2659 Note that similar but probably not identical actions will likely be 2660 needed to make IKE work with Mobile IP, but such processing is not 2661 addressed by this document. 2663 2.24. Explicit Congestion Notification (ECN) 2665 When IPsec tunnels behave as originally specified in [IPSECARCH-OLD], 2666 ECN usage is not appropriate for the outer IP headers because tunnel 2667 decapsulation processing discards ECN congestion indications to the 2668 detriment of the network. ECN support for IPsec tunnels for IKEv1- 2669 based IPsec requires multiple operating modes and negotiation (see 2670 [ECN]). IKEv2 simplifies this situation by requiring that ECN be 2671 usable in the outer IP headers of all tunnel-mode IPsec SAs created 2672 by IKEv2. Specifically, tunnel encapsulators and decapsulators for 2673 all tunnel-mode SAs created by IKEv2 MUST support the ECN full- 2674 functionality option for tunnels specified in [ECN] and MUST 2675 implement the tunnel encapsulation and decapsulation processing 2676 specified in [IPSECARCH] to prevent discarding of ECN congestion 2677 indications. 2679 3. Header and Payload Formats 2681 In the tables in this section, some cryptographic primitives and 2682 configuation attributes are marked as "UNSPECIFIED". These are items 2683 for which there are no known specifications and therefore 2684 interoperability is currently impossible. A future specification may 2685 describe their use, but until such specification is made, 2686 implementations SHOULD NOT attempt to use items marked as 2687 "UNSPECIFIED" in implementations that are meant to be interoperable. 2689 3.1. The IKE Header 2691 IKE messages use UDP ports 500 and/or 4500, with one IKE message per 2692 UDP datagram. Information from the beginning of the packet through 2693 the UDP header is largely ignored except that the IP addresses and 2694 UDP ports from the headers are reversed and used for return packets. 2695 When sent on UDP port 500, IKE messages begin immediately following 2696 the UDP header. When sent on UDP port 4500, IKE messages have 2697 prepended four octets of zero. These four octets of zero are not 2698 part of the IKE message and are not included in any of the length 2699 fields or checksums defined by IKE. Each IKE message begins with the 2700 IKE header, denoted HDR in this memo. Following the header are one 2701 or more IKE payloads each identified by a "Next Payload" field in the 2702 preceding payload. Payloads are processed in the order in which they 2703 appear in an IKE message by invoking the appropriate processing 2704 routine according to the "Next Payload" field in the IKE header and 2705 subsequently according to the "Next Payload" field in the IKE payload 2706 itself until a "Next Payload" field of zero indicates that no 2707 payloads follow. If a payload of type "Encrypted" is found, that 2708 payload is decrypted and its contents parsed as additional payloads. 2709 An Encrypted payload MUST be the last payload in a packet and an 2710 Encrypted payload MUST NOT contain another Encrypted payload. 2712 The Recipient SPI in the header identifies an instance of an IKE 2713 security association. It is therefore possible for a single instance 2714 of IKE to multiplex distinct sessions with multiple peers. 2716 All multi-octet fields representing integers are laid out in big 2717 endian order (also known as "most significant byte first", or 2718 "network byte order"). 2720 The format of the IKE header is shown in Figure 4. 2722 1 2 3 2723 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 2724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2725 | IKE_SA Initiator's SPI | 2726 | | 2727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2728 | IKE_SA Responder's SPI | 2729 | | 2730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2731 | Next Payload | MjVer | MnVer | Exchange Type | Flags | 2732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2733 | Message ID | 2734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2735 | Length | 2736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2738 Figure 4: IKE Header Format 2740 o Initiator's SPI (8 octets) - A value chosen by the initiator to 2741 identify a unique IKE security association. This value MUST NOT 2742 be zero. 2744 o Responder's SPI (8 octets) - A value chosen by the responder to 2745 identify a unique IKE security association. This value MUST be 2746 zero in the first message of an IKE Initial Exchange (including 2747 repeats of that message including a cookie). {{ The phrase "and 2748 MUST NOT be zero in any other message" was removed; Clarif-2.1 }} 2750 o Next Payload (1 octet) - Indicates the type of payload that 2751 immediately follows the header. The format and value of each 2752 payload are defined below. 2754 o Major Version (4 bits) - Indicates the major version of the IKE 2755 protocol in use. Implementations based on this version of IKE 2756 MUST set the Major Version to 2. Implementations based on 2757 previous versions of IKE and ISAKMP MUST set the Major Version to 2758 1. Implementations based on this version of IKE MUST reject or 2759 ignore messages containing a version number greater than 2. 2761 o Minor Version (4 bits) - Indicates the minor version of the IKE 2762 protocol in use. Implementations based on this version of IKE 2763 MUST set the Minor Version to 0. They MUST ignore the minor 2764 version number of received messages. 2766 o Exchange Type (1 octet) - Indicates the type of exchange being 2767 used. This constrains the payloads sent in each message and 2768 orderings of messages in an exchange. 2770 Exchange Type Value 2771 ---------------------------------- 2772 RESERVED 0-33 2773 IKE_SA_INIT 34 2774 IKE_AUTH 35 2775 CREATE_CHILD_SA 36 2776 INFORMATIONAL 37 2777 RESERVED TO IANA 38-239 2778 PRIVATE USE 240-255 2780 o Flags (1 octet) - Indicates specific options that are set for the 2781 message. Presence of options are indicated by the appropriate bit 2782 in the flags field being set. The bits are defined LSB first, so 2783 bit 0 would be the least significant bit of the Flags octet. In 2784 the description below, a bit being 'set' means its value is '1', 2785 while 'cleared' means its value is '0'. 2787 * X(reserved) (bits 0-2) - These bits MUST be cleared when 2788 sending and MUST be ignored on receipt. 2790 * I(nitiator) (bit 3 of Flags) - This bit MUST be set in messages 2791 sent by the original initiator of the IKE_SA and MUST be 2792 cleared in messages sent by the original responder. It is used 2793 by the recipient to determine which eight octets of the SPI 2794 were generated by the recipient. 2796 * V(ersion) (bit 4 of Flags) - This bit indicates that the 2797 transmitter is capable of speaking a higher major version 2798 number of the protocol than the one indicated in the major 2799 version number field. Implementations of IKEv2 must clear this 2800 bit when sending and MUST ignore it in incoming messages. 2802 * R(esponse) (bit 5 of Flags) - This bit indicates that this 2803 message is a response to a message containing the same message 2804 ID. This bit MUST be cleared in all request messages and MUST 2805 be set in all responses. An IKE endpoint MUST NOT generate a 2806 response to a message that is marked as being a response. 2808 * X(reserved) (bits 6-7 of Flags) - These bits MUST be cleared 2809 when sending and MUST be ignored on receipt. 2811 o Message ID (4 octets) - Message identifier used to control 2812 retransmission of lost packets and matching of requests and 2813 responses. It is essential to the security of the protocol 2814 because it is used to prevent message replay attacks. See 2815 Section 2.1 and Section 2.2. 2817 o Length (4 octets) - Length of total message (header + payloads) in 2818 octets. 2820 3.2. Generic Payload Header 2822 Each IKE payload defined in Section 3.3 through Section 3.16 begins 2823 with a generic payload header, shown in Figure 5. Figures for each 2824 payload below will include the generic payload header, but for 2825 brevity the description of each field will be omitted. 2827 1 2 3 2828 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 2829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2830 | Next Payload |C| RESERVED | Payload Length | 2831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2833 Figure 5: Generic Payload Header 2835 The Generic Payload Header fields are defined as follows: 2837 o Next Payload (1 octet) - Identifier for the payload type of the 2838 next payload in the message. If the current payload is the last 2839 in the message, then this field will be 0. This field provides a 2840 "chaining" capability whereby additional payloads can be added to 2841 a message by appending it to the end of the message and setting 2842 the "Next Payload" field of the preceding payload to indicate the 2843 new payload's type. An Encrypted payload, which must always be 2844 the last payload of a message, is an exception. It contains data 2845 structures in the format of additional payloads. In the header of 2846 an Encrypted payload, the Next Payload field is set to the payload 2847 type of the first contained payload (instead of 0). The payload 2848 type values are: 2850 Next Payload Type Notation Value 2851 -------------------------------------------------- 2852 No Next Payload 0 2853 RESERVED 1-32 2854 Security Association SA 33 2855 Key Exchange KE 34 2856 Identification - Initiator IDi 35 2857 Identification - Responder IDr 36 2858 Certificate CERT 37 2859 Certificate Request CERTREQ 38 2860 Authentication AUTH 39 2861 Nonce Ni, Nr 40 2862 Notify N 41 2863 Delete D 42 2864 Vendor ID V 43 2865 Traffic Selector - Initiator TSi 44 2866 Traffic Selector - Responder TSr 45 2867 Encrypted E 46 2868 Configuration CP 47 2869 Extensible Authentication EAP 48 2870 RESERVED TO IANA 49-127 2871 PRIVATE USE 128-255 2873 (Payload type values 1-32 should not be assigned in the 2874 future so that there is no overlap with the code assignments 2875 for IKEv1.) 2877 o Critical (1 bit) - MUST be set to zero if the sender wants the 2878 recipient to skip this payload if it does not understand the 2879 payload type code in the Next Payload field of the previous 2880 payload. MUST be set to one if the sender wants the recipient to 2881 reject this entire message if it does not understand the payload 2882 type. MUST be ignored by the recipient if the recipient 2883 understands the payload type code. MUST be set to zero for 2884 payload types defined in this document. Note that the critical 2885 bit applies to the current payload rather than the "next" payload 2886 whose type code appears in the first octet. The reasoning behind 2887 not setting the critical bit for payloads defined in this document 2888 is that all implementations MUST understand all payload types 2889 defined in this document and therefore must ignore the Critical 2890 bit's value. Skipped payloads are expected to have valid Next 2891 Payload and Payload Length fields. 2893 o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on 2894 receipt. 2896 o Payload Length (2 octets) - Length in octets of the current 2897 payload, including the generic payload header. 2899 {{ Clarif-7.10 }} Many payloads contain fields marked as "RESERVED". 2900 Some payloads in IKEv2 (and historically in IKEv1) are not aligned to 2901 4-octet boundaries. 2903 3.3. Security Association Payload 2905 The Security Association Payload, denoted SA in this memo, is used to 2906 negotiate attributes of a security association. Assembly of Security 2907 Association Payloads requires great peace of mind. An SA payload MAY 2908 contain multiple proposals. If there is more than one, they MUST be 2909 ordered from most preferred to least preferred. Each proposal 2910 contains a single IPsec protocol (where a protocol is IKE, ESP, or 2911 AH), each protocol MAY contain multiple transforms, and each 2912 transform MAY contain multiple attributes. When parsing an SA, an 2913 implementation MUST check that the total Payload Length is consistent 2914 with the payload's internal lengths and counts. Proposals, 2915 Transforms, and Attributes each have their own variable length 2916 encodings. They are nested such that the Payload Length of an SA 2917 includes the combined contents of the SA, Proposal, Transform, and 2918 Attribute information. The length of a Proposal includes the lengths 2919 of all Transforms and Attributes it contains. The length of a 2920 Transform includes the lengths of all Attributes it contains. 2922 The syntax of Security Associations, Proposals, Transforms, and 2923 Attributes is based on ISAKMP; however the semantics are somewhat 2924 different. The reason for the complexity and the hierarchy is to 2925 allow for multiple possible combinations of algorithms to be encoded 2926 in a single SA. Sometimes there is a choice of multiple algorithms, 2927 whereas other times there is a combination of algorithms. For 2928 example, an initiator might want to propose using ESP with either 2929 (3DES and HMAC_MD5) or (AES and HMAC_SHA1). 2931 One of the reasons the semantics of the SA payload has changed from 2932 ISAKMP and IKEv1 is to make the encodings more compact in common 2933 cases. 2935 The Proposal structure contains within it a Proposal # and an IPsec 2936 protocol ID. Each structure MUST have a proposal number one (1) 2937 greater than the previous structure. The first Proposal in the 2938 initiator's SA payload MUST have a Proposal # of one (1). A proposal 2939 of AH or ESP would have two proposal structures, one for AH with 2940 Proposal #1 and one for ESP with Proposal #2. 2942 Each Proposal/Protocol structure is followed by one or more transform 2943 structures. The number of different transforms is generally 2944 determined by the Protocol. AH generally has two transforms: 2945 Extended Sequence Numbers (ESN) and an integrity check algorithm. 2946 ESP generally has three: ESN, an encryption algorithm and an 2947 integrity check algorithm. IKE generally has four transforms: a 2948 Diffie-Hellman group, an integrity check algorithm, a prf algorithm, 2949 and an encryption algorithm. If an algorithm that combines 2950 encryption and integrity protection is proposed, it MUST be proposed 2951 as an encryption algorithm and an integrity protection algorithm MUST 2952 NOT be proposed. For each Protocol, the set of permissible 2953 transforms is assigned transform ID numbers, which appear in the 2954 header of each transform. 2956 If there are multiple transforms with the same Transform Type, the 2957 proposal is an OR of those transforms. If there are multiple 2958 Transforms with different Transform Types, the proposal is an AND of 2959 the different groups. For example, to propose ESP with (3DES or AES- 2960 CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two 2961 Transform Type 1 candidates (one for 3DES and one for AEC-CBC) and 2962 two Transform Type 3 candidates (one for HMAC_MD5 and one for 2963 HMAC_SHA). This effectively proposes four combinations of 2964 algorithms. If the initiator wanted to propose only a subset of 2965 those, for example (3DES and HMAC_MD5) or (IDEA and HMAC_SHA), there 2966 is no way to encode that as multiple transforms within a single 2967 Proposal. Instead, the initiator would have to construct two 2968 different Proposals, each with two transforms. 2970 A given transform MAY have one or more Attributes. Attributes are 2971 necessary when the transform can be used in more than one way, as 2972 when an encryption algorithm has a variable key size. The transform 2973 would specify the algorithm and the attribute would specify the key 2974 size. Most transforms do not have attributes. A transform MUST NOT 2975 have multiple attributes of the same type. To propose alternate 2976 values for an attribute (for example, multiple key sizes for the AES 2977 encryption algorithm), and implementation MUST include multiple 2978 Transforms with the same Transform Type each with a single Attribute. 2980 Note that the semantics of Transforms and Attributes are quite 2981 different from those in IKEv1. In IKEv1, a single Transform carried 2982 multiple algorithms for a protocol with one carried in the Transform 2983 and the others carried in the Attributes. 2985 1 2 3 2986 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 2987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2988 | Next Payload |C| RESERVED | Payload Length | 2989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2990 | | 2991 ~ ~ 2992 | | 2993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2994 Figure 6: Security Association Payload 2996 o Proposals (variable) - One or more proposal substructures. 2998 The payload type for the Security Association Payload is thirty three 2999 (33). 3001 3.3.1. Proposal Substructure 3003 1 2 3 3004 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 3005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3006 | 0 (last) or 2 | RESERVED | Proposal Length | 3007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3008 | Proposal # | Protocol ID | SPI Size |# of Transforms| 3009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3010 ~ SPI (variable) ~ 3011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3012 | | 3013 ~ ~ 3014 | | 3015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3017 Figure 7: Proposal Substructure 3019 o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the 3020 last Proposal Substructure in the SA. This syntax is inherited 3021 from ISAKMP, but is unnecessary because the last Proposal could be 3022 identified from the length of the SA. The value (2) corresponds 3023 to a Payload Type of Proposal in IKEv1, and the first four octets 3024 of the Proposal structure are designed to look somewhat like the 3025 header of a Payload. 3027 o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on 3028 receipt. 3030 o Proposal Length (2 octets) - Length of this proposal, including 3031 all transforms and attributes that follow. 3033 o Proposal # (1 octet) - When a proposal is made, the first proposal 3034 in an SA payload MUST be #1, and subsequent proposals MUST be one 3035 more than the previous proposal (indicating an OR of the two 3036 proposals). When a proposal is accepted, the proposal number in 3037 the SA payload MUST match the number on the proposal sent that was 3038 accepted. 3040 o Protocol ID (1 octet) - Specifies the IPsec protocol identifier 3041 for the current negotiation. The defined values are: 3043 Protocol Protocol ID 3044 ----------------------------------- 3045 RESERVED 0 3046 IKE 1 3047 AH 2 3048 ESP 3 3049 RESERVED TO IANA 4-200 3050 PRIVATE USE 201-255 3052 o SPI Size (1 octet) - For an initial IKE_SA negotiation, this field 3053 MUST be zero; the SPI is obtained from the outer header. During 3054 subsequent negotiations, it is equal to the size, in octets, of 3055 the SPI of the corresponding protocol (8 for IKE, 4 for ESP and 3056 AH). 3058 o # of Transforms (1 octet) - Specifies the number of transforms in 3059 this proposal. 3061 o SPI (variable) - The sending entity's SPI. Even if the SPI Size 3062 is not a multiple of 4 octets, there is no padding applied to the 3063 payload. When the SPI Size field is zero, this field is not 3064 present in the Security Association payload. 3066 o Transforms (variable) - One or more transform substructures. 3068 3.3.2. Transform Substructure 3070 1 2 3 3071 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 3072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3073 | 0 (last) or 3 | RESERVED | Transform Length | 3074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3075 |Transform Type | RESERVED | Transform ID | 3076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3077 | | 3078 ~ Transform Attributes ~ 3079 | | 3080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3082 Figure 8: Transform Substructure 3084 o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the 3085 last Transform Substructure in the Proposal. This syntax is 3086 inherited from ISAKMP, but is unnecessary because the last 3087 Proposal could be identified from the length of the SA. The value 3088 (3) corresponds to a Payload Type of Transform in IKEv1, and the 3089 first four octets of the Transform structure are designed to look 3090 somewhat like the header of a Payload. 3092 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 3094 o Transform Length - The length (in octets) of the Transform 3095 Substructure including Header and Attributes. 3097 o Transform Type (1 octet) - The type of transform being specified 3098 in this transform. Different protocols support different 3099 transform types. For some protocols, some of the transforms may 3100 be optional. If a transform is optional and the initiator wishes 3101 to propose that the transform be omitted, no transform of the 3102 given type is included in the proposal. If the initiator wishes 3103 to make use of the transform optional to the responder, it 3104 includes a transform substructure with transform ID = 0 as one of 3105 the options. 3107 o Transform ID (2 octets) - The specific instance of the transform 3108 type being proposed. 3110 The tranform type values are: 3112 Description Trans. Used In 3113 Type 3114 ------------------------------------------------------------------ 3115 RESERVED 0 3116 Encryption Algorithm (ENCR) 1 IKE and ESP 3117 Pseudo-random Function (PRF) 2 IKE 3118 Integrity Algorithm (INTEG) 3 IKE*, AH, optional in ESP 3119 Diffie-Hellman Group (D-H) 4 IKE, optional in AH & ESP 3120 Extended Sequence Numbers (ESN) 5 AH and ESP 3121 RESERVED TO IANA 6-240 3122 PRIVATE USE 241-255 3124 (*) Negotiating an integrity algorithm is mandatory for the 3125 Encrypted payload format specified in this document. Future 3126 documents may specify additional formats based on authenticated 3127 encryption, in which case a separate integrity algorithm is not 3128 negotiated. 3130 For Transform Type 1 (Encryption Algorithm), defined Transform IDs 3131 are: 3133 Name Number Defined In 3134 --------------------------------------------------- 3135 RESERVED 0 3136 ENCR_DES_IV64 1 (UNSPECIFIED) 3137 ENCR_DES 2 (RFC2405), [DES] 3138 ENCR_3DES 3 (RFC2451) 3139 ENCR_RC5 4 (RFC2451) 3140 ENCR_IDEA 5 (RFC2451), [IDEA] 3141 ENCR_CAST 6 (RFC2451) 3142 ENCR_BLOWFISH 7 (RFC2451) 3143 ENCR_3IDEA 8 (UNSPECIFIED) 3144 ENCR_DES_IV32 9 (UNSPECIFIED) 3145 RESERVED 10 3146 ENCR_NULL 11 (RFC2410) 3147 ENCR_AES_CBC 12 (RFC3602) 3148 ENCR_AES_CTR 13 (RFC3686) 3149 RESERVED TO IANA 14-1023 3150 PRIVATE USE 1024-65535 3152 For Transform Type 2 (Pseudo-random Function), defined Transform IDs 3153 are: 3155 Name Number Defined In 3156 ------------------------------------------------------ 3157 RESERVED 0 3158 PRF_HMAC_MD5 1 (RFC2104), [MD5] 3159 PRF_HMAC_SHA1 2 (RFC2104), [SHA] 3160 PRF_HMAC_TIGER 3 (UNSPECIFIED) 3161 PRF_AES128_XCBC 4 (RFC4434) 3162 RESERVED TO IANA 5-1023 3163 PRIVATE USE 1024-65535 3165 For Transform Type 3 (Integrity Algorithm), defined Transform IDs 3166 are: 3168 Name Number Defined In 3169 ---------------------------------------- 3170 NONE 0 3171 AUTH_HMAC_MD5_96 1 (RFC2403) 3172 AUTH_HMAC_SHA1_96 2 (RFC2404) 3173 AUTH_DES_MAC 3 (UNSPECIFIED) 3174 AUTH_KPDK_MD5 4 (UNSPECIFIED) 3175 AUTH_AES_XCBC_96 5 (RFC3566) 3176 RESERVED TO IANA 6-1023 3177 PRIVATE USE 1024-65535 3179 For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs 3180 are: 3182 Name Number Defined in 3183 ---------------------------------------- 3184 NONE 0 3185 768 Bit MODP 1 Appendix B 3186 1024 Bit MODP 2 Appendix B 3187 RESERVED TO IANA 3-4 3188 1536-bit MODP 5 [ADDGROUP] 3189 RESERVED TO IANA 6-13 3190 2048-bit MODP 14 [ADDGROUP] 3191 3072-bit MODP 15 [ADDGROUP] 3192 4096-bit MODP 16 [ADDGROUP] 3193 6144-bit MODP 17 [ADDGROUP] 3194 8192-bit MODP 18 [ADDGROUP] 3195 RESERVED TO IANA 19-1023 3196 PRIVATE USE 1024-65535 3198 For Transform Type 5 (Extended Sequence Numbers), defined Transform 3199 IDs are: 3201 Name Number 3202 -------------------------------------------- 3203 No Extended Sequence Numbers 0 3204 Extended Sequence Numbers 1 3205 RESERVED 2 - 65535 3207 {{ Clarif-4.4 }} Note that an initiator who supports ESNs will 3208 usually include two ESN transforms, with values "0" and "1", in its 3209 proposals. A proposal containing a single ESN transform with value 3210 "1" means that using normal (non-extended) sequence numbers is not 3211 acceptable. 3213 3.3.3. Valid Transform Types by Protocol 3215 The number and type of transforms that accompany an SA payload are 3216 dependent on the protocol in the SA itself. An SA payload proposing 3217 the establishment of an SA has the following mandatory and optional 3218 transform types. A compliant implementation MUST understand all 3219 mandatory and optional types for each protocol it supports (though it 3220 need not accept proposals with unacceptable suites). A proposal MAY 3221 omit the optional types if the only value for them it will accept is 3222 NONE. 3224 Protocol Mandatory Types Optional Types 3225 --------------------------------------------------- 3226 IKE ENCR, PRF, INTEG*, D-H 3227 ESP ENCR, ESN INTEG, D-H 3228 AH INTEG, ESN D-H 3230 (*) Negotiating an integrity algorithm is mandatory for the 3231 Encrypted payload format specified in this document. Future 3232 documents may specify additional formats based on authenticated 3233 encryption, in which case a separate integrity algorithm is not 3234 negotiated. 3236 3.3.4. Mandatory Transform IDs 3238 The specification of suites that MUST and SHOULD be supported for 3239 interoperability has been removed from this document because they are 3240 likely to change more rapidly than this document evolves. 3242 An important lesson learned from IKEv1 is that no system should only 3243 implement the mandatory algorithms and expect them to be the best 3244 choice for all customers. For example, at the time that this 3245 document was written, many IKEv1 implementers were starting to 3246 migrate to AES in Cipher Block Chaining (CBC) mode for Virtual 3247 Private Network (VPN) applications. Many IPsec systems based on 3248 IKEv2 will implement AES, additional Diffie-Hellman groups, and 3249 additional hash algorithms, and some IPsec customers already require 3250 these algorithms in addition to the ones listed above. 3252 It is likely that IANA will add additional transforms in the future, 3253 and some users may want to use private suites, especially for IKE 3254 where implementations should be capable of supporting different 3255 parameters, up to certain size limits. In support of this goal, all 3256 implementations of IKEv2 SHOULD include a management facility that 3257 allows specification (by a user or system administrator) of Diffie- 3258 Hellman (DH) parameters (the generator, modulus, and exponent lengths 3259 and values) for new DH groups. Implementations SHOULD provide a 3260 management interface through which these parameters and the 3261 associated transform IDs may be entered (by a user or system 3262 administrator), to enable negotiating such groups. 3264 All implementations of IKEv2 MUST include a management facility that 3265 enables a user or system administrator to specify the suites that are 3266 acceptable for use with IKE. Upon receipt of a payload with a set of 3267 transform IDs, the implementation MUST compare the transmitted 3268 transform IDs against those locally configured via the management 3269 controls, to verify that the proposed suite is acceptable based on 3270 local policy. The implementation MUST reject SA proposals that are 3271 not authorized by these IKE suite controls. Note that cryptographic 3272 suites that MUST be implemented need not be configured as acceptable 3273 to local policy. 3275 3.3.5. Transform Attributes 3277 Each transform in a Security Association payload may include 3278 attributes that modify or complete the specification of the 3279 transform. The set of valid attributes depends on the transform. 3280 Currently, only a single attribute type is defined: the Key Length 3281 attribute is used by certain encryption transforms with variable- 3282 length keys (see below for details). 3284 The attributes are type/value pairs and are defined below. 3285 Attributes can have a value with a fixed two-octet length or a 3286 variable-length value. For the latter, the attribute is encoded as 3287 type/length/value. 3289 1 2 3 3290 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 3291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3292 |A| Attribute Type | AF=0 Attribute Length | 3293 |F| | AF=1 Attribute Value | 3294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3295 | AF=0 Attribute Value | 3296 | AF=1 Not Transmitted | 3297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3299 Figure 9: Data Attributes 3301 o Attribute Format (AF) (1 bit) - Indicates whether the data 3302 attribute follow the Type/Length/Value (TLV) format or a shortened 3303 Type/Value (TV) format. If the AF bit is zero (0), then the 3304 attribute uses TLV format; if the AF bit is one (1), the TV format 3305 (with two-byte value) is used. 3307 o Attribute Type (15 bits) - Unique identifier for each type of 3308 attribute (see below). 3310 o Attribute Value (variable length) - Value of the Attribute 3311 associated with the Attribute Type. If the AF bit is a zero (0), 3312 this field has a variable length defined by the Attribute Length 3313 field. If the AF bit is a one (1), the Attribute Value has a 3314 length of 2 octets. 3316 Note that the only currently defined attribute type (Key Length) is 3317 fixed length; the variable-length encoding specification is included 3318 only for future extensions. Attributes described as fixed length 3319 MUST NOT be encoded using the variable-length encoding. Variable- 3320 length attributes MUST NOT be encoded as fixed-length even if their 3321 value can fit into two octets. NOTE: This is a change from IKEv1, 3322 where increased flexibility may have simplified the composer of 3323 messages but certainly complicated the parser. 3325 Attribute Type Value Attribute Format 3326 ------------------------------------------------------------ 3327 RESERVED 0-13 3328 Key Length (in bits) 14 TV 3329 RESERVED 15-17 3330 RESERVED TO IANA 18-16383 3331 PRIVATE USE 16384-32767 3333 Values 0-13 and 15-17 were used in a similar context in IKEv1, and 3334 should not be assigned except to matching values. 3336 The Key Length attribute specifies the key length in bits (MUST use 3337 network byte order) for certain transforms as follows: {{ Clarif-7.11 3338 }} 3340 o The Key Length attribute MUST NOT be used with transforms that use 3341 a fixed length key. This includes, e.g., ENCR_DES, ENCR_IDEA, and 3342 all the Type 2 (Pseudo-random function) and Type 3 (Integrity 3343 Algorithm) transforms specified in this document. It is 3344 recommended that future Type 2 or 3 transforms do not use this 3345 attribute. 3347 o Some transforms specify that the Key Length attribute MUST be 3348 always included (omitting the attribute is not allowed, and 3349 proposals not containing it MUST be rejected). This includes, 3350 e.g., ENCR_AES_CBC and ENCR_AES_CTR. 3352 o Some transforms allow variable-length keys, but also specify a 3353 default key length if the attribute is not included. These 3354 transforms include, e.g., ENCR_RC5 and ENCR_BLOWFISH. 3356 Implementation note: To further interoperability and to support 3357 upgrading endpoints independently, implementers of this protocol 3358 SHOULD accept values that they deem to supply greater security. For 3359 instance, if a peer is configured to accept a variable-length cipher 3360 with a key length of X bits and is offered that cipher with a larger 3361 key length, the implementation SHOULD accept the offer if it supports 3362 use of the longer key. 3364 Support of this capability allows a responder to express a concept of 3365 "at least" a certain level of security -- "a key length of _at least_ 3366 X bits for cipher Y". However, as the attribute is always returned 3367 unchanged (see Section 3.3.6), an initiator willing to accept 3368 multiple key lengths has to include multiple transforms with the same 3369 Transform Type, each with different Key Length attribute. 3371 3.3.6. Attribute Negotiation 3373 During security association negotiation initiators present offers to 3374 responders. Responders MUST select a single complete set of 3375 parameters from the offers (or reject all offers if none are 3376 acceptable). If there are multiple proposals, the responder MUST 3377 choose a single proposal. If the selected proposal has multiple 3378 Transforms with the same type, the responder MUST choose a single 3379 one. Any attributes of a selected transform MUST be returned 3380 unmodified. The initiator of an exchange MUST check that the 3381 accepted offer is consistent with one of its proposals, and if not 3382 that response MUST be rejected. 3384 If the responder receives a proposal that contains a Transform Type 3385 it does not understand, or a proposal that is missing a mandatory 3386 Transform Type, it MUST consider this proposal unacceptable; however, 3387 other proposals in the same SA payload are processed as usual. 3388 Similarly, if the responder receives a transform that contains a 3389 Transform Attribute it does not understand, it MUST consider this 3390 transform unacceptable; other transforms with the same Transform Type 3391 are processed as usual. This allows new Transform Types and 3392 Transform Attributes to be defined in the future. 3394 Negotiating Diffie-Hellman groups presents some special challenges. 3395 SA offers include proposed attributes and a Diffie-Hellman public 3396 number (KE) in the same message. If in the initial exchange the 3397 initiator offers to use one of several Diffie-Hellman groups, it 3398 SHOULD pick the one the responder is most likely to accept and 3399 include a KE corresponding to that group. If the guess turns out to 3400 be wrong, the responder will indicate the correct group in the 3401 response and the initiator SHOULD pick an element of that group for 3402 its KE value when retrying the first message. It SHOULD, however, 3403 continue to propose its full supported set of groups in order to 3404 prevent a man-in-the-middle downgrade attack. 3406 3.4. Key Exchange Payload 3408 The Key Exchange Payload, denoted KE in this memo, is used to 3409 exchange Diffie-Hellman public numbers as part of a Diffie-Hellman 3410 key exchange. The Key Exchange Payload consists of the IKE generic 3411 payload header followed by the Diffie-Hellman public value itself. 3413 1 2 3 3414 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 3415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3416 | Next Payload |C| RESERVED | Payload Length | 3417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3418 | DH Group # | RESERVED | 3419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3420 | | 3421 ~ Key Exchange Data ~ 3422 | | 3423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3425 Figure 10: Key Exchange Payload Format 3427 A key exchange payload is constructed by copying one's Diffie-Hellman 3428 public value into the "Key Exchange Data" portion of the payload. 3429 The length of the Diffie-Hellman public value MUST be equal to the 3430 length of the prime modulus over which the exponentiation was 3431 performed, prepending zero bits to the value if necessary. 3433 The DH Group # identifies the Diffie-Hellman group in which the Key 3434 Exchange Data was computed (see Section 3.3.2). If the selected 3435 proposal uses a different Diffie-Hellman group (other than NONE), the 3436 message MUST be rejected with a Notify payload of type 3437 INVALID_KE_PAYLOAD. 3439 The payload type for the Key Exchange payload is thirty four (34). 3441 3.5. Identification Payloads 3443 The Identification Payloads, denoted IDi and IDr in this memo, allow 3444 peers to assert an identity to one another. This identity may be 3445 used for policy lookup, but does not necessarily have to match 3446 anything in the CERT payload; both fields may be used by an 3447 implementation to perform access control decisions. {{ Clarif-7.1 }} 3448 When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr 3449 payloads, IKEv2 does not require this address to match the address in 3450 the IP header of IKEv2 packets, or anything in the TSi/TSr payloads. 3451 The contents of IDi/IDr is used purely to fetch the policy and 3452 authentication data related to the other party. 3454 NOTE: In IKEv1, two ID payloads were used in each direction to hold 3455 Traffic Selector (TS) information for data passing over the SA. In 3456 IKEv2, this information is carried in TS payloads (see Section 3.13). 3458 The Identification Payload consists of the IKE generic payload header 3459 followed by identification fields as follows: 3461 1 2 3 3462 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3464 | Next Payload |C| RESERVED | Payload Length | 3465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3466 | ID Type | RESERVED | 3467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3468 | | 3469 ~ Identification Data ~ 3470 | | 3471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3473 Figure 11: Identification Payload Format 3475 o ID Type (1 octet) - Specifies the type of Identification being 3476 used. 3478 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 3480 o Identification Data (variable length) - Value, as indicated by the 3481 Identification Type. The length of the Identification Data is 3482 computed from the size in the ID payload header. 3484 The payload types for the Identification Payload are thirty five (35) 3485 for IDi and thirty six (36) for IDr. 3487 The following table lists the assigned values for the Identification 3488 Type field: 3490 ID Type Value 3491 ------------------------------------------------------------------- 3492 RESERVED 0 3494 ID_IPV4_ADDR 1 3495 A single four (4) octet IPv4 address. 3497 ID_FQDN 2 3498 A fully-qualified domain name string. An example of a ID_FQDN 3499 is, "example.com". The string MUST not contain any terminators 3500 (e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII; 3501 for an "internationalized domain name", the syntax is as defined 3502 in [IDNA], for example "xn--tmonesimerkki-bfbb.example.net". 3504 ID_RFC822_ADDR 3 3505 A fully-qualified RFC822 email address string, An example of a 3506 ID_RFC822_ADDR is, "jsmith@example.com". The string MUST not 3507 contain any terminators. 3509 RESERVED TO IANA 4 3511 ID_IPV6_ADDR 5 3512 A single sixteen (16) octet IPv6 address. 3514 RESERVED TO IANA 6 - 8 3516 ID_DER_ASN1_DN 9 3517 The binary Distinguished Encoding Rules (DER) encoding of an 3518 ASN.1 X.500 Distinguished Name [X.501]. 3520 ID_DER_ASN1_GN 10 3521 The binary DER encoding of an ASN.1 X.500 GeneralName [X.509]. 3523 ID_KEY_ID 11 3524 An opaque octet stream which may be used to pass vendor- 3525 specific information necessary to do certain proprietary 3526 types of identification. 3528 RESERVED TO IANA 12-200 3530 PRIVATE USE 201-255 3532 Two implementations will interoperate only if each can generate a 3533 type of ID acceptable to the other. To assure maximum 3534 interoperability, implementations MUST be configurable to send at 3535 least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and 3536 MUST be configurable to accept all of these types. Implementations 3537 SHOULD be capable of generating and accepting all of these types. 3539 IPv6-capable implementations MUST additionally be configurable to 3540 accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable 3541 to send only ID_IPV6_ADDR. 3543 {{ Clarif-3.4 }} EAP [EAP] does not mandate the use of any particular 3544 type of identifier, but often EAP is used with Network Access 3545 Identifiers (NAIs) defined in [NAI]. Although NAIs look a bit like 3546 email addresses (e.g., "joe@example.com"), the syntax is not exactly 3547 the same as the syntax of email address in [MAILFORMAT]. For those 3548 NAIs that include the realm component, the ID_RFC822_ADDR 3549 identification type SHOULD be used. Responder implementations should 3550 not attempt to verify that the contents actually conform to the exact 3551 syntax given in [MAILFORMAT], but instead should accept any 3552 reasonable-looking NAI. For NAIs that do not include the realm 3553 component,the ID_KEY_ID identification type SHOULD be used. 3555 3.6. Certificate Payload 3557 The Certificate Payload, denoted CERT in this memo, provides a means 3558 to transport certificates or other authentication-related information 3559 via IKE. Certificate payloads SHOULD be included in an exchange if 3560 certificates are available to the sender unless the peer has 3561 indicated an ability to retrieve this information from elsewhere 3562 using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note that the 3563 term "Certificate Payload" is somewhat misleading, because not all 3564 authentication mechanisms use certificates and data other than 3565 certificates may be passed in this payload. 3567 The Certificate Payload is defined as follows: 3569 1 2 3 3570 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 3571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3572 | Next Payload |C| RESERVED | Payload Length | 3573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3574 | Cert Encoding | | 3575 +-+-+-+-+-+-+-+-+ | 3576 ~ Certificate Data ~ 3577 | | 3578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3580 Figure 12: Certificate Payload Format 3582 o Certificate Encoding (1 octet) - This field indicates the type of 3583 certificate or certificate-related information contained in the 3584 Certificate Data field. 3586 Certificate Encoding Value 3587 ---------------------------------------------------- 3588 RESERVED 0 3589 PKCS #7 wrapped X.509 certificate 1 UNSPECIFIED 3590 PGP Certificate 2 UNSPECIFIED 3591 DNS Signed Key 3 UNSPECIFIED 3592 X.509 Certificate - Signature 4 3593 Kerberos Token 6 UNSPECIFIED 3594 Certificate Revocation List (CRL) 7 3595 Authority Revocation List (ARL) 8 3596 SPKI Certificate 9 UNSPECIFIED 3597 X.509 Certificate - Attribute 10 3598 Raw RSA Key 11 3599 Hash and URL of X.509 certificate 12 3600 Hash and URL of X.509 bundle 13 3601 RESERVED to IANA 14 - 200 3602 PRIVATE USE 201 - 255 3604 o Certificate Data (variable length) - Actual encoding of 3605 certificate data. The type of certificate is indicated by the 3606 Certificate Encoding field. 3608 The payload type for the Certificate Payload is thirty seven (37). 3610 Specific syntax for some of the certificate type codes above is not 3611 defined in this document. The types whose syntax is defined in this 3612 document are: 3614 o X.509 Certificate - Signature (4) contains a DER encoded X.509 3615 certificate whose public key is used to validate the sender's AUTH 3616 payload. 3618 o Certificate Revocation List (7) contains a DER encoded X.509 3619 certificate revocation list. 3621 o {{ Added "DER-encoded RSAPublicKey structure" from Clarif-3.6 }} 3622 Raw RSA Key (11) contains a PKCS #1 encoded RSA key, that is, a 3623 DER-encoded RSAPublicKey structure (see [RSA] and [PKCS1]). 3625 o Hash and URL encodings (12-13) allow IKE messages to remain short 3626 by replacing long data structures with a 20 octet SHA-1 hash (see 3627 [SHA]) of the replaced value followed by a variable-length URL 3628 that resolves to the DER encoded data structure itself. This 3629 improves efficiency when the endpoints have certificate data 3630 cached and makes IKE less subject to denial of service attacks 3631 that become easier to mount when IKE messages are large enough to 3632 require IP fragmentation [DOSUDPPROT]. 3634 Use the following ASN.1 definition for an X.509 bundle: 3636 CertBundle 3637 { iso(1) identified-organization(3) dod(6) internet(1) 3638 security(5) mechanisms(5) pkix(7) id-mod(0) 3639 id-mod-cert-bundle(34) } 3641 DEFINITIONS EXPLICIT TAGS ::= 3642 BEGIN 3644 IMPORTS 3645 Certificate, CertificateList 3646 FROM PKIX1Explicit88 3647 { iso(1) identified-organization(3) dod(6) 3648 internet(1) security(5) mechanisms(5) pkix(7) 3649 id-mod(0) id-pkix1-explicit(18) } ; 3651 CertificateOrCRL ::= CHOICE { 3652 cert [0] Certificate, 3653 crl [1] CertificateList } 3655 CertificateBundle ::= SEQUENCE OF CertificateOrCRL 3657 END 3659 Implementations MUST be capable of being configured to send and 3660 accept up to four X.509 certificates in support of authentication, 3661 and also MUST be capable of being configured to send and accept the 3662 two Hash and URL formats (with HTTP URLs). Implementations SHOULD be 3663 capable of being configured to send and accept Raw RSA keys. If 3664 multiple certificates are sent, the first certificate MUST contain 3665 the public key used to sign the AUTH payload. The other certificates 3666 may be sent in any order. 3668 3.7. Certificate Request Payload 3670 The Certificate Request Payload, denoted CERTREQ in this memo, 3671 provides a means to request preferred certificates via IKE and can 3672 appear in the IKE_INIT_SA response and/or the IKE_AUTH request. 3673 Certificate Request payloads MAY be included in an exchange when the 3674 sender needs to get the certificate of the receiver. If multiple CAs 3675 are trusted and the cert encoding does not allow a list, then 3676 multiple Certificate Request payloads SHOULD be transmitted. 3678 The Certificate Request Payload is defined as follows: 3680 1 2 3 3681 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 3682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3683 | Next Payload |C| RESERVED | Payload Length | 3684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3685 | Cert Encoding | | 3686 +-+-+-+-+-+-+-+-+ | 3687 ~ Certification Authority ~ 3688 | | 3689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3691 Figure 13: Certificate Request Payload Format 3693 o Certificate Encoding (1 octet) - Contains an encoding of the type 3694 or format of certificate requested. Values are listed in 3695 Section 3.6. 3697 o Certification Authority (variable length) - Contains an encoding 3698 of an acceptable certification authority for the type of 3699 certificate requested. 3701 The payload type for the Certificate Request Payload is thirty eight 3702 (38). 3704 The Certificate Encoding field has the same values as those defined 3705 in Section 3.6. The Certification Authority field contains an 3706 indicator of trusted authorities for this certificate type. The 3707 Certification Authority value is a concatenated list of SHA-1 hashes 3708 of the public keys of trusted Certification Authorities (CAs). Each 3709 is encoded as the SHA-1 hash of the Subject Public Key Info element 3710 (see section 4.1.2.7 of [PKIX]) from each Trust Anchor certificate. 3711 The twenty-octet hashes are concatenated and included with no other 3712 formatting. 3714 {{ Clarif-3.6 }} The contents of the "Certification Authority" field 3715 are defined only for X.509 certificates, which are types 4, 10, 12, 3716 and 13. Other values SHOULD NOT be used until standards-track 3717 specifications that specify their use are published. 3719 Note that the term "Certificate Request" is somewhat misleading, in 3720 that values other than certificates are defined in a "Certificate" 3721 payload and requests for those values can be present in a Certificate 3722 Request Payload. The syntax of the Certificate Request payload in 3723 such cases is not defined in this document. 3725 The Certificate Request Payload is processed by inspecting the "Cert 3726 Encoding" field to determine whether the processor has any 3727 certificates of this type. If so, the "Certification Authority" 3728 field is inspected to determine if the processor has any certificates 3729 that can be validated up to one of the specified certification 3730 authorities. This can be a chain of certificates. 3732 If an end-entity certificate exists that satisfies the criteria 3733 specified in the CERTREQ, a certificate or certificate chain SHOULD 3734 be sent back to the certificate requestor if the recipient of the 3735 CERTREQ: 3737 o is configured to use certificate authentication, 3739 o is allowed to send a CERT payload, 3741 o has matching CA trust policy governing the current negotiation, 3742 and 3744 o has at least one time-wise and usage appropriate end-entity 3745 certificate chaining to a CA provided in the CERTREQ. 3747 Certificate revocation checking must be considered during the 3748 chaining process used to select a certificate. Note that even if two 3749 peers are configured to use two different CAs, cross-certification 3750 relationships should be supported by appropriate selection logic. 3752 The intent is not to prevent communication through the strict 3753 adherence of selection of a certificate based on CERTREQ, when an 3754 alternate certificate could be selected by the sender that would 3755 still enable the recipient to successfully validate and trust it 3756 through trust conveyed by cross-certification, CRLs, or other out-of- 3757 band configured means. Thus, the processing of a CERTREQ should be 3758 seen as a suggestion for a certificate to select, not a mandated one. 3759 If no certificates exist, then the CERTREQ is ignored. This is not 3760 an error condition of the protocol. There may be cases where there 3761 is a preferred CA sent in the CERTREQ, but an alternate might be 3762 acceptable (perhaps after prompting a human operator). 3764 {{ 3.10.1-16392 }} The HTTP_CERT_LOOKUP_SUPPORTED notification MAY be 3765 included in any message that can include a CERTREQ payload and 3766 indicates that the sender is capable of looking up certificates based 3767 on an HTTP-based URL (and hence presumably would prefer to receive 3768 certificate specifications in that format). 3770 3.8. Authentication Payload 3772 The Authentication Payload, denoted AUTH in this memo, contains data 3773 used for authentication purposes. The syntax of the Authentication 3774 data varies according to the Auth Method as specified below. 3776 The Authentication Payload is defined as follows: 3778 1 2 3 3779 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 3780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3781 | Next Payload |C| RESERVED | Payload Length | 3782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3783 | Auth Method | RESERVED | 3784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3785 | | 3786 ~ Authentication Data ~ 3787 | | 3788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3790 Figure 14: Authentication Payload Format 3792 o Auth Method (1 octet) - Specifies the method of authentication 3793 used. Values defined are: 3795 * RSA Digital Signature (1) - Computed as specified in 3796 Section 2.15 using an RSA private key with RSASSA-PKCS1-v1_5 3797 signature scheme specified in [PKCS1] (implementors should note 3798 that IKEv1 used a different method for RSA signatures) {{ 3799 Clarif-3.3 }}. {{ Clarif-3.2 }} To promote interoperability, 3800 implementations that support this type SHOULD support 3801 signatures that use SHA-1 as the hash function and SHOULD use 3802 SHA-1 as the default hash function when generating signatures. 3804 * Shared Key Message Integrity Code (2) - Computed as specified 3805 in Section 2.15 using the shared key associated with the 3806 identity in the ID payload and the negotiated prf function 3808 * DSS Digital Signature (3) - Computed as specified in 3809 Section 2.15 using a DSS private key (see [DSS]) over a SHA-1 3810 hash. 3812 * The values 0 and 4-200 are reserved to IANA. The values 201- 3813 255 are available for private use. 3815 o Authentication Data (variable length) - see Section 2.15. 3817 The payload type for the Authentication Payload is thirty nine (39). 3819 3.9. Nonce Payload 3821 The Nonce Payload, denoted Ni and Nr in this memo for the initiator's 3822 and responder's nonce respectively, contains random data used to 3823 guarantee liveness during an exchange and protect against replay 3824 attacks. 3826 The Nonce Payload is defined as follows: 3828 1 2 3 3829 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 3830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3831 | Next Payload |C| RESERVED | Payload Length | 3832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3833 | | 3834 ~ Nonce Data ~ 3835 | | 3836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3838 Figure 15: Nonce Payload Format 3840 o Nonce Data (variable length) - Contains the random data generated 3841 by the transmitting entity. 3843 The payload type for the Nonce Payload is forty (40). 3845 The size of a Nonce MUST be between 16 and 256 octets inclusive. 3846 Nonce values MUST NOT be reused. 3848 3.10. Notify Payload 3850 The Notify Payload, denoted N in this document, is used to transmit 3851 informational data, such as error conditions and state transitions, 3852 to an IKE peer. A Notify Payload may appear in a response message 3853 (usually specifying why a request was rejected), in an INFORMATIONAL 3854 Exchange (to report an error not in an IKE request), or in any other 3855 message to indicate sender capabilities or to modify the meaning of 3856 the request. 3858 The Notify Payload is defined as follows: 3860 1 2 3 3861 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 3862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3863 | Next Payload |C| RESERVED | Payload Length | 3864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3865 | Protocol ID | SPI Size | Notify Message Type | 3866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3867 | | 3868 ~ Security Parameter Index (SPI) ~ 3869 | | 3870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3871 | | 3872 ~ Notification Data ~ 3873 | | 3874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3876 Figure 16: Notify Payload Format 3878 o Protocol ID (1 octet) - If this notification concerns an existing 3879 SA whose SPI is given the SPI field, this field indicates the type 3880 of that SA. For notifications concerning IPsec SAs this field 3881 MUST contain either (2) to indicate AH or (3) to indicate ESP. {{ 3882 Clarif-7.8 }} Of the notifications defined in this document, the 3883 SPI is included only with INVALID_SELECTORS and REKEY_SA. If the 3884 SPI field is empty, this field MUST be sent as zero and MUST be 3885 ignored on receipt. All other values for this field are reserved 3886 to IANA for future assignment. 3888 o SPI Size (1 octet) - Length in octets of the SPI as defined by the 3889 IPsec protocol ID or zero if no SPI is applicable. For a 3890 notification concerning the IKE_SA, the SPI Size MUST be zero. 3892 o Notify Message Type (2 octets) - Specifies the type of 3893 notification message. 3895 o SPI (variable length) - Security Parameter Index. 3897 o Notification Data (variable length) - Informational or error data 3898 transmitted in addition to the Notify Message Type. Values for 3899 this field are type specific (see below). 3901 The payload type for the Notify Payload is forty one (41). 3903 3.10.1. Notify Message Types 3905 Notification information can be error messages specifying why an SA 3906 could not be established. It can also be status data that a process 3907 managing an SA database wishes to communicate with a peer process. 3909 The table below lists the Notification messages and their 3910 corresponding values. The number of different error statuses was 3911 greatly reduced from IKEv1 both for simplification and to avoid 3912 giving configuration information to probers. 3914 Types in the range 0 - 16383 are intended for reporting errors. An 3915 implementation receiving a Notify payload with one of these types 3916 that it does not recognize in a response MUST assume that the 3917 corresponding request has failed entirely. {{ Demoted the SHOULD }} 3918 Unrecognized error types in a request and status types in a request 3919 or response MUST be ignored, and they should be logged. 3921 Notify payloads with status types MAY be added to any message and 3922 MUST be ignored if not recognized. They are intended to indicate 3923 capabilities, and as part of SA negotiation are used to negotiate 3924 non-cryptographic parameters. 3926 NOTIFY messages: error types Value 3927 ------------------------------------------------------------------- 3929 RESERVED 0 3931 UNSUPPORTED_CRITICAL_PAYLOAD 1 3932 See Section 2.5. 3934 INVALID_IKE_SPI 4 3935 See Section 2.21. 3937 INVALID_MAJOR_VERSION 5 3938 See Section 2.5. 3940 INVALID_SYNTAX 7 3941 Indicates the IKE message that was received was invalid because 3942 some type, length, or value was out of range or because the 3943 request was rejected for policy reasons. To avoid a denial of 3944 service attack using forged messages, this status may only be 3945 returned for and in an encrypted packet if the message ID and 3946 cryptographic checksum were valid. To avoid leaking information 3947 to someone probing a node, this status MUST be sent in response 3948 to any error not covered by one of the other status types. 3949 {{ Demoted the SHOULD }} To aid debugging, more detailed error 3950 information should be written to a console or log. 3952 INVALID_MESSAGE_ID 9 3953 See Section 2.3. 3955 INVALID_SPI 11 3956 See Section 1.5. 3958 NO_PROPOSAL_CHOSEN 14 3959 See Section 2.7. 3961 INVALID_KE_PAYLOAD 17 3962 See Section 1.3. 3964 AUTHENTICATION_FAILED 24 3965 Sent in the response to an IKE_AUTH message when for some reason 3966 the authentication failed. There is no associated data. 3968 SINGLE_PAIR_REQUIRED 34 3969 See Section 2.9. 3971 NO_ADDITIONAL_SAS 35 3972 See Section 1.3. 3974 INTERNAL_ADDRESS_FAILURE 36 3975 See Section 3.15.4. 3977 FAILED_CP_REQUIRED 37 3978 See Section 2.19. 3980 TS_UNACCEPTABLE 38 3981 See Section 2.9. 3983 INVALID_SELECTORS 39 3984 MAY be sent in an IKE INFORMATIONAL exchange when a node receives 3985 an ESP or AH packet whose selectors do not match those of the SA 3986 on which it was delivered (and that caused the packet to be 3987 dropped). The Notification Data contains the start of the 3988 offending packet (as in ICMP messages) and the SPI field of the 3989 notification is set to match the SPI of the IPsec SA. 3991 RESERVED TO IANA 40-8191 3993 PRIVATE USE 8192-16383 3994 NOTIFY messages: status types Value 3995 ------------------------------------------------------------------- 3997 INITIAL_CONTACT 16384 3998 See Section 2.4. 4000 SET_WINDOW_SIZE 16385 4001 See Section 2.3. 4003 ADDITIONAL_TS_POSSIBLE 16386 4004 See Section 2.9. 4006 IPCOMP_SUPPORTED 16387 4007 See Section 2.22. 4009 NAT_DETECTION_SOURCE_IP 16388 4010 See Section 2.23. 4012 NAT_DETECTION_DESTINATION_IP 16389 4013 See Section 2.23. 4015 COOKIE 16390 4016 See Section 2.6. 4018 USE_TRANSPORT_MODE 16391 4019 See Section 1.3.1. 4021 HTTP_CERT_LOOKUP_SUPPORTED 16392 4022 See Section 3.6. 4024 REKEY_SA 16393 4025 See Section 1.3.3. 4027 ESP_TFC_PADDING_NOT_SUPPORTED 16394 4028 See Section 1.3.1. 4030 NON_FIRST_FRAGMENTS_ALSO 16395 4031 See Section 1.3.1. 4033 RESERVED TO IANA 16396-40959 4035 PRIVATE USE 40960-65535 4037 3.11. Delete Payload 4039 The Delete Payload, denoted D in this memo, contains a protocol 4040 specific security association identifier that the sender has removed 4041 from its security association database and is, therefore, no longer 4042 valid. Figure 17 shows the format of the Delete Payload. It is 4043 possible to send multiple SPIs in a Delete payload; however, each SPI 4044 MUST be for the same protocol. Mixing of protocol identifiers MUST 4045 NOT be performed in the Delete payload. It is permitted, however, to 4046 include multiple Delete payloads in a single INFORMATIONAL exchange 4047 where each Delete payload lists SPIs for a different protocol. 4049 Deletion of the IKE_SA is indicated by a protocol ID of 1 (IKE) but 4050 no SPIs. Deletion of a CHILD_SA, such as ESP or AH, will contain the 4051 IPsec protocol ID of that protocol (2 for AH, 3 for ESP), and the SPI 4052 is the SPI the sending endpoint would expect in inbound ESP or AH 4053 packets. 4055 The Delete Payload is defined as follows: 4057 1 2 3 4058 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 4059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4060 | Next Payload |C| RESERVED | Payload Length | 4061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4062 | Protocol ID | SPI Size | # of SPIs | 4063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4064 | | 4065 ~ Security Parameter Index(es) (SPI) ~ 4066 | | 4067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4069 Figure 17: Delete Payload Format 4071 o Protocol ID (1 octet) - Must be 1 for an IKE_SA, 2 for AH, or 3 4072 for ESP. 4074 o SPI Size (1 octet) - Length in octets of the SPI as defined by the 4075 protocol ID. It MUST be zero for IKE (SPI is in message header) 4076 or four for AH and ESP. 4078 o # of SPIs (2 octets) - The number of SPIs contained in the Delete 4079 payload. The size of each SPI is defined by the SPI Size field. 4081 o Security Parameter Index(es) (variable length) - Identifies the 4082 specific security association(s) to delete. The length of this 4083 field is determined by the SPI Size and # of SPIs fields. 4085 The payload type for the Delete Payload is forty two (42). 4087 3.12. Vendor ID Payload 4089 The Vendor ID Payload, denoted V in this memo, contains a vendor 4090 defined constant. The constant is used by vendors to identify and 4091 recognize remote instances of their implementations. This mechanism 4092 allows a vendor to experiment with new features while maintaining 4093 backward compatibility. 4095 A Vendor ID payload MAY announce that the sender is capable of 4096 accepting certain extensions to the protocol, or it MAY simply 4097 identify the implementation as an aid in debugging. A Vendor ID 4098 payload MUST NOT change the interpretation of any information defined 4099 in this specification (i.e., the critical bit MUST be set to 0). 4100 Multiple Vendor ID payloads MAY be sent. An implementation is NOT 4101 REQUIRED to send any Vendor ID payload at all. 4103 A Vendor ID payload may be sent as part of any message. Reception of 4104 a familiar Vendor ID payload allows an implementation to make use of 4105 Private USE numbers described throughout this memo-- private 4106 payloads, private exchanges, private notifications, etc. Unfamiliar 4107 Vendor IDs MUST be ignored. 4109 Writers of Internet-Drafts who wish to extend this protocol MUST 4110 define a Vendor ID payload to announce the ability to implement the 4111 extension in the Internet-Draft. It is expected that Internet-Drafts 4112 that gain acceptance and are standardized will be given "magic 4113 numbers" out of the Future Use range by IANA, and the requirement to 4114 use a Vendor ID will go away. 4116 The Vendor ID Payload fields are defined as follows: 4118 1 2 3 4119 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 4120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4121 | Next Payload |C| RESERVED | Payload Length | 4122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4123 | | 4124 ~ Vendor ID (VID) ~ 4125 | | 4126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4128 Figure 18: Vendor ID Payload Format 4130 o Vendor ID (variable length) - It is the responsibility of the 4131 person choosing the Vendor ID to assure its uniqueness in spite of 4132 the absence of any central registry for IDs. Good practice is to 4133 include a company name, a person name, or some such. If you want 4134 to show off, you might include the latitude and longitude and time 4135 where you were when you chose the ID and some random input. A 4136 message digest of a long unique string is preferable to the long 4137 unique string itself. 4139 The payload type for the Vendor ID Payload is forty three (43). 4141 3.13. Traffic Selector Payload 4143 The Traffic Selector Payload, denoted TS in this memo, allows peers 4144 to identify packet flows for processing by IPsec security services. 4145 The Traffic Selector Payload consists of the IKE generic payload 4146 header followed by individual traffic selectors as follows: 4148 1 2 3 4149 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 4150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4151 | Next Payload |C| RESERVED | Payload Length | 4152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4153 | Number of TSs | RESERVED | 4154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4155 | | 4156 ~ ~ 4157 | | 4158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4160 Figure 19: Traffic Selectors Payload Format 4162 o Number of TSs (1 octet) - Number of traffic selectors being 4163 provided. 4165 o RESERVED - This field MUST be sent as zero and MUST be ignored on 4166 receipt. 4168 o Traffic Selectors (variable length) - One or more individual 4169 traffic selectors. 4171 The length of the Traffic Selector payload includes the TS header and 4172 all the traffic selectors. 4174 The payload type for the Traffic Selector payload is forty four (44) 4175 for addresses at the initiator's end of the SA and forty five (45) 4176 for addresses at the responder's end. 4178 {{ Clarif-4.7 }} There is no requirement that TSi and TSr contain the 4179 same number of individual traffic selectors. Thus, they are 4180 interpreted as follows: a packet matches a given TSi/TSr if it 4181 matches at least one of the individual selectors in TSi, and at least 4182 one of the individual selectors in TSr. 4184 For instance, the following traffic selectors: 4186 TSi = ((17, 100, 192.0.1.66-192.0.1.66), 4187 (17, 200, 192.0.1.66-192.0.1.66)) 4188 TSr = ((17, 300, 0.0.0.0-255.255.255.255), 4189 (17, 400, 0.0.0.0-255.255.255.255)) 4191 would match UDP packets from 192.0.1.66 to anywhere, with any of the 4192 four combinations of source/destination ports (100,300), (100,400), 4193 (200,300), and (200, 400). 4195 Thus, some types of policies may require several CHILD_SA pairs. For 4196 instance, a policy matching only source/destination ports (100,300) 4197 and (200,400), but not the other two combinations, cannot be 4198 negotiated as a single CHILD_SA pair. 4200 3.13.1. Traffic Selector 4202 1 2 3 4203 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 4204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4205 | TS Type |IP Protocol ID*| Selector Length | 4206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4207 | Start Port* | End Port* | 4208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4209 | | 4210 ~ Starting Address* ~ 4211 | | 4212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4213 | | 4214 ~ Ending Address* ~ 4215 | | 4216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4218 Figure 20: Traffic Selector 4220 *Note: All fields other than TS Type and Selector Length depend on 4221 the TS Type. The fields shown are for TS Types 7 and 8, the only two 4222 values currently defined. 4224 o TS Type (one octet) - Specifies the type of traffic selector. 4226 o IP protocol ID (1 octet) - Value specifying an associated IP 4227 protocol ID (e.g., UDP/TCP/ICMP). A value of zero means that the 4228 protocol ID is not relevant to this traffic selector-- the SA can 4229 carry all protocols. 4231 o Selector Length - Specifies the length of this Traffic Selector 4232 Substructure including the header. 4234 o Start Port (2 octets) - Value specifying the smallest port number 4235 allowed by this Traffic Selector. For protocols for which port is 4236 undefined, or if all ports are allowed, this field MUST be zero. 4237 For the ICMP protocol, the two one-octet fields Type and Code are 4238 treated as a single 16-bit integer (with Type in the most 4239 significant eight bits and Code in the least significant eight 4240 bits) port number for the purposes of filtering based on this 4241 field. 4243 o End Port (2 octets) - Value specifying the largest port number 4244 allowed by this Traffic Selector. For protocols for which port is 4245 undefined, or if all ports are allowed, this field MUST be 65535. 4246 For the ICMP protocol, the two one-octet fields Type and Code are 4247 treated as a single 16-bit integer (with Type in the most 4248 significant eight bits and Code in the least significant eight 4249 bits) port number for the purposed of filtering based on this 4250 field. 4252 o Starting Address - The smallest address included in this Traffic 4253 Selector (length determined by TS type). 4255 o Ending Address - The largest address included in this Traffic 4256 Selector (length determined by TS type). 4258 Systems that are complying with [IPSECARCH] that wish to indicate 4259 "ANY" ports MUST set the start port to 0 and the end port to 65535; 4260 note that according to [IPSECARCH], "ANY" includes "OPAQUE". Systems 4261 working with [IPSECARCH] that wish to indicate "OPAQUE" ports, but 4262 not "ANY" ports, MUST set the start port to 65535 and the end port to 4263 0. 4265 {{ Added from Clarif-4.8 }} The traffic selector types 7 and 8 can 4266 also refer to ICMP type and code fields. Note, however, that ICMP 4267 packets do not have separate source and destination port fields. The 4268 method for specifying the traffic selectors for ICMP is shown by 4269 example in Section 4.4.1.3 of [IPSECARCH]. 4271 {{ Added from Clarif-4.9 }} Traffic selectors can use IP Protocol ID 4272 135 to match the IPv6 mobility header [MIPV6]. This document does 4273 not specify how to represent the "MH Type" field in traffic 4274 selectors, although it is likely that a different document will 4275 specify this in the future. Note that [IPSECARCH] says that the IPv6 4276 mobility header (MH) message type is placed in the most significant 4277 eight bits of the 16-bit local port selector. The direction 4278 semantics of TSi/TSr port fields are the same as for ICMP. 4280 The following table lists the assigned values for the Traffic 4281 Selector Type field and the corresponding Address Selector Data. 4283 TS Type Value 4284 ------------------------------------------------------------------- 4285 RESERVED 0-6 4287 TS_IPV4_ADDR_RANGE 7 4289 A range of IPv4 addresses, represented by two four-octet 4290 values. The first value is the beginning IPv4 address 4291 (inclusive) and the second value is the ending IPv4 address 4292 (inclusive). All addresses falling between the two specified 4293 addresses are considered to be within the list. 4295 TS_IPV6_ADDR_RANGE 8 4297 A range of IPv6 addresses, represented by two sixteen-octet 4298 values. The first value is the beginning IPv6 address 4299 (inclusive) and the second value is the ending IPv6 address 4300 (inclusive). All addresses falling between the two specified 4301 addresses are considered to be within the list. 4303 RESERVED TO IANA 9-240 4304 PRIVATE USE 241-255 4306 3.14. Encrypted Payload 4308 The Encrypted Payload, denoted SK{...} or E in this memo, contains 4309 other payloads in encrypted form. The Encrypted Payload, if present 4310 in a message, MUST be the last payload in the message. Often, it is 4311 the only payload in the message. 4313 The algorithms for encryption and integrity protection are negotiated 4314 during IKE_SA setup, and the keys are computed as specified in 4315 Section 2.14 and Section 2.18. 4317 This document specifies the cryptographic processing of Encrypted 4318 payloads using a block cipher in CBC mode and an integrity check 4319 algorithm that computes a fixed-length checksum over a variable size 4320 message. The design is modeled after the ESP algorithms described in 4321 RFCs 2104 [HMAC], 4303 [ESP], and 2451 [ESPCBC]. This document 4322 completely specifies the cryptographic processing of IKE data, but 4323 those documents should be consulted for design rationale. Future 4324 documents may specify the processing of Encrypted payloads for other 4325 types of transforms, such as counter mode encryption and 4326 authenticated encryption algorithms. Peers MUST NOT negotiate 4327 transforms for which no such specification exists. 4329 The payload type for an Encrypted payload is forty six (46). The 4330 Encrypted Payload consists of the IKE generic payload header followed 4331 by individual fields as follows: 4333 1 2 3 4334 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 4335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4336 | Next Payload |C| RESERVED | Payload Length | 4337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4338 | Initialization Vector | 4339 | (length is block size for encryption algorithm) | 4340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4341 ~ Encrypted IKE Payloads ~ 4342 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4343 | | Padding (0-255 octets) | 4344 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 4345 | | Pad Length | 4346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4347 ~ Integrity Checksum Data ~ 4348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4350 Figure 21: Encrypted Payload Format 4352 o Next Payload - The payload type of the first embedded payload. 4353 Note that this is an exception in the standard header format, 4354 since the Encrypted payload is the last payload in the message and 4355 therefore the Next Payload field would normally be zero. But 4356 because the content of this payload is embedded payloads and there 4357 was no natural place to put the type of the first one, that type 4358 is placed here. 4360 o Payload Length - Includes the lengths of the header, IV, Encrypted 4361 IKE Payloads, Padding, Pad Length, and Integrity Checksum Data. 4363 o Initialization Vector - The length of the initialization vector 4364 (IV) is equal to the block length of the underlying encryption 4365 algorithm. Senders MUST select a new unpredictable IV for every 4366 message; recipients MUST accept any value. The reader is 4367 encouraged to consult [MODES] for advice on IV generation. In 4368 particular, using the final ciphertext block of the previous 4369 message is not considered unpredictable. 4371 o IKE Payloads are as specified earlier in this section. This field 4372 is encrypted with the negotiated cipher. 4374 o Padding MAY contain any value chosen by the sender, and MUST have 4375 a length that makes the combination of the Payloads, the Padding, 4376 and the Pad Length to be a multiple of the encryption block size. 4378 This field is encrypted with the negotiated cipher. 4380 o Pad Length is the length of the Padding field. The sender SHOULD 4381 set the Pad Length to the minimum value that makes the combination 4382 of the Payloads, the Padding, and the Pad Length a multiple of the 4383 block size, but the recipient MUST accept any length that results 4384 in proper alignment. This field is encrypted with the negotiated 4385 cipher. 4387 o Integrity Checksum Data is the cryptographic checksum of the 4388 entire message starting with the Fixed IKE Header through the Pad 4389 Length. The checksum MUST be computed over the encrypted message. 4390 Its length is determined by the integrity algorithm negotiated. 4392 3.15. Configuration Payload 4394 The Configuration payload, denoted CP in this document, is used to 4395 exchange configuration information between IKE peers. The exchange 4396 is for an IRAC to request an internal IP address from an IRAS and to 4397 exchange other information of the sort that one would acquire with 4398 Dynamic Host Configuration Protocol (DHCP) if the IRAC were directly 4399 connected to a LAN. 4401 The Configuration Payload is defined as follows: 4403 1 2 3 4404 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 4405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4406 | Next Payload |C| RESERVED | Payload Length | 4407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4408 | CFG Type | RESERVED | 4409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4410 | | 4411 ~ Configuration Attributes ~ 4412 | | 4413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4415 Figure 22: Configuration Payload Format 4417 The payload type for the Configuration Payload is forty seven (47). 4419 o CFG Type (1 octet) - The type of exchange represented by the 4420 Configuration Attributes. 4422 CFG Type Value 4423 -------------------------- 4424 RESERVED 0 4425 CFG_REQUEST 1 4426 CFG_REPLY 2 4427 CFG_SET 3 4428 CFG_ACK 4 4429 RESERVED TO IANA 5-127 4430 PRIVATE USE 128-255 4432 o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on 4433 receipt. 4435 o Configuration Attributes (variable length) - These are type length 4436 values specific to the Configuration Payload and are defined 4437 below. There may be zero or more Configuration Attributes in this 4438 payload. 4440 3.15.1. Configuration Attributes 4442 1 2 3 4443 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 4444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4445 |R| Attribute Type | Length | 4446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4447 | | 4448 ~ Value ~ 4449 | | 4450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4452 Figure 23: Configuration Attribute Format 4454 o Reserved (1 bit) - This bit MUST be set to zero and MUST be 4455 ignored on receipt. 4457 o Attribute Type (15 bits) - A unique identifier for each of the 4458 Configuration Attribute Types. 4460 o Length (2 octets) - Length in octets of Value. 4462 o Value (0 or more octets) - The variable-length value of this 4463 Configuration Attribute. The following attribute types have been 4464 defined: 4466 Multi- 4467 Attribute Type Value Valued Length 4468 ------------------------------------------------------- 4469 RESERVED 0 4470 INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets 4471 INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets 4472 INTERNAL_IP4_DNS 3 YES 0 or 4 octets 4473 INTERNAL_IP4_NBNS 4 YES 0 or 4 octets 4474 RESERVED 5 4475 INTERNAL_IP4_DHCP 6 YES 0 or 4 octets 4476 APPLICATION_VERSION 7 NO 0 or more 4477 INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets 4478 RESERVED 9 4479 INTERNAL_IP6_DNS 10 YES 0 or 16 octets 4480 INTERNAL_IP6_NBNS 11 YES 0 or 16 octets 4481 INTERNAL_IP6_DHCP 12 YES 0 or 16 octets 4482 INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets 4483 SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 4484 INTERNAL_IP6_SUBNET 15 YES 17 octets 4485 RESERVED TO IANA 16-16383 4486 PRIVATE USE 16384-32767 4488 * These attributes may be multi-valued on return only if 4489 multiple values were requested. 4491 o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the 4492 internal network, sometimes called a red node address or private 4493 address and MAY be a private address on the Internet. {{ 4494 Clarif-6.2}} In a request message, the address specified is a 4495 requested address (or a zero-length address if no specific address 4496 is requested). If a specific address is requested, it likely 4497 indicates that a previous connection existed with this address and 4498 the requestor would like to reuse that address. With IPv6, a 4499 requestor MAY supply the low-order address octets it wants to use. 4500 Multiple internal addresses MAY be requested by requesting 4501 multiple internal address attributes. The responder MAY only send 4502 up to the number of addresses requested. The INTERNAL_IP6_ADDRESS 4503 is made up of two fields: the first is a 16-octet IPv6 address, 4504 and the second is a one-octet prefix-length as defined in 4505 [ADDRIPV6]. The requested address is valid until there are no 4506 IKE_SAs between the peers. 4508 o INTERNAL_IP4_NETMASK - The internal network's netmask. Only one 4509 netmask is allowed in the request and reply messages (e.g., 4510 255.255.255.0), and it MUST be used only with an 4511 INTERNAL_IP4_ADDRESS attribute. {{ Clarif-6.4 }} 4512 INTERNAL_IP4_NETMASK in a CFG_REPLY means roughly the same thing 4513 as INTERNAL_IP4_SUBNET containing the same information ("send 4514 traffic to these addresses through me"), but also implies a link 4515 boundary. For instance, the client could use its own address and 4516 the netmask to calculate the broadcast address of the link. An 4517 empty INTERNAL_IP4_NETMASK attribute can be included in a 4518 CFG_REQUEST to request this information (although the gateway can 4519 send the information even when not requested). Non-empty values 4520 for this attribute in a CFG_REQUEST do not make sense and thus 4521 MUST NOT be included. 4523 o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a DNS 4524 server within the network. Multiple DNS servers MAY be requested. 4525 The responder MAY respond with zero or more DNS server attributes. 4527 o INTERNAL_IP4_NBNS - Specifies an address of a NetBios Name Server 4528 (WINS) within the network. Multiple NBNS servers MAY be 4529 requested. The responder MAY respond with zero or more NBNS 4530 server attributes. 4532 o INTERNAL_IP6_NBNS - {{ Clarif-6.6 }} NetBIOS is not defined for 4533 IPv6; therefore, INTERNAL_IP6_NBNS is also unspecified and is only 4534 retained for compatibility with RFC 4306. 4536 o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to send 4537 any internal DHCP requests to the address contained within the 4538 attribute. Multiple DHCP servers MAY be requested. The responder 4539 MAY respond with zero or more DHCP server attributes. 4541 o APPLICATION_VERSION - The version or application information of 4542 the IPsec host. This is a string of printable ASCII characters 4543 that is NOT null terminated. 4545 o INTERNAL_IP4_SUBNET - The protected sub-networks that this edge- 4546 device protects. This attribute is made up of two fields: the 4547 first being an IP address and the second being a netmask. 4548 Multiple sub-networks MAY be requested. The responder MAY respond 4549 with zero or more sub-network attributes. 4551 o SUPPORTED_ATTRIBUTES - When used within a Request, this attribute 4552 MUST be zero-length and specifies a query to the responder to 4553 reply back with all of the attributes that it supports. The 4554 response contains an attribute that contains a set of attribute 4555 identifiers each in 2 octets. The length divided by 2 (octets) 4556 would state the number of supported attributes contained in the 4557 response. 4559 o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge- 4560 device protects. This attribute is made up of two fields: the 4561 first is a 16-octet IPv6 address, and the second is a one-octet 4562 prefix-length as defined in [ADDRIPV6]. Multiple sub-networks MAY 4563 be requested. The responder MAY respond with zero or more sub- 4564 network attributes. 4566 Note that no recommendations are made in this document as to how an 4567 implementation actually figures out what information to send in a 4568 reply. That is, we do not recommend any specific method of an IRAS 4569 determining which DNS server should be returned to a requesting IRAC. 4571 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET 4573 {{ Section added based on Clarif-6.3 }} 4575 INTERNAL_IP4/6_SUBNET attributes can indicate additional subnets, 4576 ones that need one or more separate SAs, that can be reached through 4577 the gateway that announces the attributes. INTERNAL_IP4/6_SUBNET 4578 attributes may also express the gateway's policy about what traffic 4579 should be sent through the gateway; the client can choose whether 4580 other traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is 4581 sent through the gateway or directly to the destination. Thus, 4582 traffic to the addresses listed in the INTERNAL_IP4/6_SUBNET 4583 attributes should be sent through the gateway that announces the 4584 attributes. If there are no existing IPsec SAs whose traffic 4585 selectors cover the address in question, new SAs need to be created. 4587 For instance, if there are two subnets, 192.0.1.0/26 and 4588 192.0.2.0/24, and the client's request contains the following: 4590 CP(CFG_REQUEST) = 4591 INTERNAL_IP4_ADDRESS() 4592 TSi = (0, 0-65535, 0.0.0.0-255.255.255.255) 4593 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) 4595 then a valid response could be the following (in which TSr and 4596 INTERNAL_IP4_SUBNET contain the same information): 4598 CP(CFG_REPLY) = 4599 INTERNAL_IP4_ADDRESS(192.0.1.234) 4600 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 4601 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 4602 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) 4603 TSr = ((0, 0-65535, 192.0.1.0-192.0.1.63), 4604 (0, 0-65535, 192.0.2.0-192.0.2.255)) 4606 In these cases, the INTERNAL_IP4_SUBNET does not really carry any 4607 useful information. 4609 A different possible reply would have been this: 4611 CP(CFG_REPLY) = 4612 INTERNAL_IP4_ADDRESS(192.0.1.234) 4613 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 4614 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 4615 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) 4616 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) 4618 That reply would mean that the client can send all its traffic 4619 through the gateway, but the gateway does not mind if the client 4620 sends traffic not included by INTERNAL_IP4_SUBNET directly to the 4621 destination (without going through the gateway). 4623 A different situation arises if the gateway has a policy that 4624 requires the traffic for the two subnets to be carried in separate 4625 SAs. Then a response like this would indicate to the client that if 4626 it wants access to the second subnet, it needs to create a separate 4627 SA: 4629 CP(CFG_REPLY) = 4630 INTERNAL_IP4_ADDRESS(192.0.1.234) 4631 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 4632 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 4633 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) 4634 TSr = (0, 0-65535, 192.0.1.0-192.0.1.63) 4636 INTERNAL_IP4_SUBNET can also be useful if the client's TSr included 4637 only part of the address space. For instance, if the client requests 4638 the following: 4640 CP(CFG_REQUEST) = 4641 INTERNAL_IP4_ADDRESS() 4642 TSi = (0, 0-65535, 0.0.0.0-255.255.255.255) 4643 TSr = (0, 0-65535, 192.0.2.155-192.0.2.155) 4645 then the gateway's reply might be: 4647 CP(CFG_REPLY) = 4648 INTERNAL_IP4_ADDRESS(192.0.1.234) 4649 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 4650 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 4651 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) 4652 TSr = (0, 0-65535, 192.0.2.155-192.0.2.155) 4654 Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET is in 4655 CFG_REQUESTs is unclear, they cannot be used reliably in 4656 CFG_REQUESTs. 4658 3.15.3. Configuration payloads for IPv6 4660 {{ Added this section from Clarif-6.5 }} 4662 The configuration payloads for IPv6 are based on the corresponding 4663 IPv4 payloads, and do not fully follow the "normal IPv6 way of doing 4664 things". In particular, IPv6 stateless autoconfiguration or router 4665 advertisement messages are not used; neither is neighbor discovery. 4667 A client can be assigned an IPv6 address using the 4668 INTERNAL_IP6_ADDRESS configuration payload. A minimal exchange might 4669 look like this: 4671 CP(CFG_REQUEST) = 4672 INTERNAL_IP6_ADDRESS() 4673 INTERNAL_IP6_DNS() 4674 TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 4675 TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 4677 CP(CFG_REPLY) = 4678 INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) 4679 INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44) 4680 TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5) 4681 TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 4683 The client MAY send a non-empty INTERNAL_IP6_ADDRESS attribute in the 4684 CFG_REQUEST to request a specific address or interface identifier. 4685 The gateway first checks if the specified address is acceptable, and 4686 if it is, returns that one. If the address was not acceptable, the 4687 gateway attempts to use the interface identifier with some other 4688 prefix; if even that fails, the gateway selects another interface 4689 identifier. 4691 The INTERNAL_IP6_ADDRESS attribute also contains a prefix length 4692 field. When used in a CFG_REPLY, this corresponds to the 4693 INTERNAL_IP4_NETMASK attribute in the IPv4 case. 4695 Although this approach to configuring IPv6 addresses is reasonably 4696 simple, it has some limitations. IPsec tunnels configured using 4697 IKEv2 are not fully-featured "interfaces" in the IPv6 addressing 4698 architecture sense [IPV6ADDR]. In particular, they do not 4699 necessarily have link-local addresses, and this may complicate the 4700 use of protocols that assume them, such as [MLDV2]. 4702 3.15.4. Address Assignment Failures 4704 {{ Added this section from Clarif-6.8 }} 4705 If the responder encounters an error while attempting to assign an IP 4706 address to the initiator during the processing of a Configuration 4707 Payload, it responds with an INTERNAL_ADDRESS_FAILURE notification. 4708 {{ 3.10.1-36 }} If this error is generated within an IKE_AUTH 4709 exchange, no CHILD_SA will be created. However, there are some more 4710 complex error cases. 4712 If the responder does not support configuration payloads at all, it 4713 can simply ignore all configuration payloads. This type of 4714 implementation never sends INTERNAL_ADDRESS_FAILURE notifications. 4715 If the initiator requires the assignment of an IP address, it will 4716 treat a response without CFG_REPLY as an error. 4718 The initiator may request a particular type of address (IPv4 or IPv6) 4719 that the responder does not support, even though the responder 4720 supports configuration payloads. In this case, the responder simply 4721 ignores the type of address it does not support and processes the 4722 rest of the request as usual. 4724 If the initiator requests multiple addresses of a type that the 4725 responder supports, and some (but not all) of the requests fail, the 4726 responder replies with the successful addresses only. The responder 4727 sends INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned. 4729 3.16. Extensible Authentication Protocol (EAP) Payload 4731 The Extensible Authentication Protocol Payload, denoted EAP in this 4732 memo, allows IKE_SAs to be authenticated using the protocol defined 4733 in RFC 3748 [EAP] and subsequent extensions to that protocol. The 4734 full set of acceptable values for the payload is defined elsewhere, 4735 but a short summary of RFC 3748 is included here to make this 4736 document stand alone in the common cases. 4738 1 2 3 4739 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 4740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4741 | Next Payload |C| RESERVED | Payload Length | 4742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4743 | | 4744 ~ EAP Message ~ 4745 | | 4746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4748 Figure 24: EAP Payload Format 4750 The payload type for an EAP Payload is forty eight (48). 4752 1 2 3 4753 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 4754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4755 | Code | Identifier | Length | 4756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4757 | Type | Type_Data... 4758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 4760 Figure 25: EAP Message Format 4762 o Code (1 octet) indicates whether this message is a Request (1), 4763 Response (2), Success (3), or Failure (4). 4765 o Identifier (1 octet) is used in PPP to distinguish replayed 4766 messages from repeated ones. Since in IKE, EAP runs over a 4767 reliable protocol, it serves no function here. In a response 4768 message, this octet MUST be set to match the identifier in the 4769 corresponding request. In other messages, this field MAY be set 4770 to any value. 4772 o Length (2 octets) is the length of the EAP message and MUST be 4773 four less than the Payload Length of the encapsulating payload. 4775 o Type (1 octet) is present only if the Code field is Request (1) or 4776 Response (2). For other codes, the EAP message length MUST be 4777 four octets and the Type and Type_Data fields MUST NOT be present. 4778 In a Request (1) message, Type indicates the data being requested. 4779 In a Response (2) message, Type MUST either be Nak or match the 4780 type of the data requested. The following types are defined in 4781 RFC 3748: 4783 1 Identity 4784 2 Notification 4785 3 Nak (Response Only) 4786 4 MD5-Challenge 4787 5 One-Time Password (OTP) 4788 6 Generic Token Card 4790 o Type_Data (Variable Length) varies with the Type of Request and 4791 the associated Response. For the documentation of the EAP 4792 methods, see [EAP]. 4794 {{ Demoted the SHOULD NOT and SHOULD }} Note that since IKE passes an 4795 indication of initiator identity in message 3 of the protocol, the 4796 responder should not send EAP Identity requests. The initiator may, 4797 however, respond to such requests if it receives them. 4799 4. Conformance Requirements 4801 In order to assure that all implementations of IKEv2 can 4802 interoperate, there are "MUST support" requirements in addition to 4803 those listed elsewhere. Of course, IKEv2 is a security protocol, and 4804 one of its major functions is to allow only authorized parties to 4805 successfully complete establishment of SAs. So a particular 4806 implementation may be configured with any of a number of restrictions 4807 concerning algorithms and trusted authorities that will prevent 4808 universal interoperability. 4810 IKEv2 is designed to permit minimal implementations that can 4811 interoperate with all compliant implementations. There are a series 4812 of optional features that can easily be ignored by a particular 4813 implementation if it does not support that feature. Those features 4814 include: 4816 o Ability to negotiate SAs through a NAT and tunnel the resulting 4817 ESP SA over UDP. 4819 o Ability to request (and respond to a request for) a temporary IP 4820 address on the remote end of a tunnel. 4822 o Ability to support various types of legacy authentication. 4824 o Ability to support window sizes greater than one. 4826 o Ability to establish multiple ESP and/or AH SAs within a single 4827 IKE_SA. 4829 o Ability to rekey SAs. 4831 To assure interoperability, all implementations MUST be capable of 4832 parsing all payload types (if only to skip over them) and to ignore 4833 payload types that it does not support unless the critical bit is set 4834 in the payload header. If the critical bit is set in an unsupported 4835 payload header, all implementations MUST reject the messages 4836 containing those payloads. 4838 Every implementation MUST be capable of doing four-message 4839 IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, 4840 one for ESP and/or AH). Implementations MAY be initiate-only or 4841 respond-only if appropriate for their platform. Every implementation 4842 MUST be capable of responding to an INFORMATIONAL exchange, but a 4843 minimal implementation MAY respond to any INFORMATIONAL message with 4844 an empty INFORMATIONAL reply (note that within the context of an 4845 IKE_SA, an "empty" message consists of an IKE header followed by an 4846 Encrypted payload with no payloads contained in it). A minimal 4847 implementation MAY support the CREATE_CHILD_SA exchange only in so 4848 far as to recognize requests and reject them with a Notify payload of 4849 type NO_ADDITIONAL_SAS. A minimal implementation need not be able to 4850 initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA 4851 expires (based on locally configured values of either lifetime or 4852 octets passed), and implementation MAY either try to renew it with a 4853 CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and 4854 create a new one. If the responder rejects the CREATE_CHILD_SA 4855 request with a NO_ADDITIONAL_SAS notification, the implementation 4856 MUST be capable of instead deleting the old SA and creating a new 4857 one. 4859 Implementations are not required to support requesting temporary IP 4860 addresses or responding to such requests. If an implementation does 4861 support issuing such requests, it MUST include a CP payload in 4862 message 3 containing at least a field of type INTERNAL_IP4_ADDRESS or 4863 INTERNAL_IP6_ADDRESS. All other fields are optional. If an 4864 implementation supports responding to such requests, it MUST parse 4865 the CP payload of type CFG_REQUEST in message 3 and recognize a field 4866 of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports 4867 leasing an address of the appropriate type, it MUST return a CP 4868 payload of type CFG_REPLY containing an address of the requested 4869 type. {{ Demoted the SHOULD }} The responder may include any other 4870 related attributes. 4872 A minimal IPv4 responder implementation will ignore the contents of 4873 the CP payload except to determine that it includes an 4874 INTERNAL_IP4_ADDRESS attribute and will respond with the address and 4875 other related attributes regardless of whether the initiator 4876 requested them. 4878 A minimal IPv4 initiator will generate a CP payload containing only 4879 an INTERNAL_IP4_ADDRESS attribute and will parse the response 4880 ignoring attributes it does not know how to use. 4882 For an implementation to be called conforming to this specification, 4883 it MUST be possible to configure it to accept the following: 4885 o PKIX Certificates containing and signed by RSA keys of size 1024 4886 or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, 4887 ID_RFC822_ADDR, or ID_DER_ASN1_DN. 4889 o Shared key authentication where the ID passed is any of ID_KEY_ID, 4890 ID_FQDN, or ID_RFC822_ADDR. 4892 o Authentication where the responder is authenticated using PKIX 4893 Certificates and the initiator is authenticated using shared key 4894 authentication. 4896 5. Security Considerations 4898 While this protocol is designed to minimize disclosure of 4899 configuration information to unauthenticated peers, some such 4900 disclosure is unavoidable. One peer or the other must identify 4901 itself first and prove its identity first. To avoid probing, the 4902 initiator of an exchange is required to identify itself first, and 4903 usually is required to authenticate itself first. The initiator can, 4904 however, learn that the responder supports IKE and what cryptographic 4905 protocols it supports. The responder (or someone impersonating the 4906 responder) can probe the initiator not only for its identity, but 4907 using CERTREQ payloads may be able to determine what certificates the 4908 initiator is willing to use. 4910 Use of EAP authentication changes the probing possibilities somewhat. 4911 When EAP authentication is used, the responder proves its identity 4912 before the initiator does, so an initiator that knew the name of a 4913 valid initiator could probe the responder for both its name and 4914 certificates. 4916 Repeated rekeying using CREATE_CHILD_SA without additional Diffie- 4917 Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a 4918 single key or overrun of either endpoint. Implementers should take 4919 note of this fact and set a limit on CREATE_CHILD_SA exchanges 4920 between exponentiations. This memo does not prescribe such a limit. 4922 The strength of a key derived from a Diffie-Hellman exchange using 4923 any of the groups defined here depends on the inherent strength of 4924 the group, the size of the exponent used, and the entropy provided by 4925 the random number generator used. Due to these inputs, it is 4926 difficult to determine the strength of a key for any of the defined 4927 groups. Diffie-Hellman group number two, when used with a strong 4928 random number generator and an exponent no less than 200 bits, is 4929 common for use with 3DES. Group five provides greater security than 4930 group two. Group one is for historic purposes only and does not 4931 provide sufficient strength except for use with DES, which is also 4932 for historic use only. Implementations should make note of these 4933 estimates when establishing policy and negotiating security 4934 parameters. 4936 Note that these limitations are on the Diffie-Hellman groups 4937 themselves. There is nothing in IKE that prohibits using stronger 4938 groups nor is there anything that will dilute the strength obtained 4939 from stronger groups (limited by the strength of the other algorithms 4940 negotiated including the prf function). In fact, the extensible 4941 framework of IKE encourages the definition of more groups; use of 4942 elliptical curve groups may greatly increase strength using much 4943 smaller numbers. 4945 It is assumed that all Diffie-Hellman exponents are erased from 4946 memory after use. In particular, these exponents MUST NOT be derived 4947 from long-lived secrets like the seed to a pseudo-random generator 4948 that is not erased after use. 4950 The strength of all keys is limited by the size of the output of the 4951 negotiated prf function. For this reason, a prf function whose 4952 output is less than 128 bits (e.g., 3DES-CBC) MUST NOT be used with 4953 this protocol. 4955 The security of this protocol is critically dependent on the 4956 randomness of the randomly chosen parameters. These should be 4957 generated by a strong random or properly seeded pseudo-random source 4958 (see [RANDOMNESS]). Implementers should take care to ensure that use 4959 of random numbers for both keys and nonces is engineered in a fashion 4960 that does not undermine the security of the keys. 4962 For information on the rationale of many of the cryptographic design 4963 choices in this protocol, see [SIGMA] and [SKEME]. Though the 4964 security of negotiated CHILD_SAs does not depend on the strength of 4965 the encryption and integrity protection negotiated in the IKE_SA, 4966 implementations MUST NOT negotiate NONE as the IKE integrity 4967 protection algorithm or ENCR_NULL as the IKE encryption algorithm. 4969 When using pre-shared keys, a critical consideration is how to assure 4970 the randomness of these secrets. The strongest practice is to ensure 4971 that any pre-shared key contain as much randomness as the strongest 4972 key being negotiated. Deriving a shared secret from a password, 4973 name, or other low-entropy source is not secure. These sources are 4974 subject to dictionary and social engineering attacks, among others. 4976 The NAT_DETECTION_*_IP notifications contain a hash of the addresses 4977 and ports in an attempt to hide internal IP addresses behind a NAT. 4978 Since the IPv4 address space is only 32 bits, and it is usually very 4979 sparse, it would be possible for an attacker to find out the internal 4980 address used behind the NAT box by trying all possible IP addresses 4981 and trying to find the matching hash. The port numbers are normally 4982 fixed to 500, and the SPIs can be extracted from the packet. This 4983 reduces the number of hash calculations to 2^32. With an educated 4984 guess of the use of private address space, the number of hash 4985 calculations is much smaller. Designers should therefore not assume 4986 that use of IKE will not leak internal address information. 4988 When using an EAP authentication method that does not generate a 4989 shared key for protecting a subsequent AUTH payload, certain man-in- 4990 the-middle and server impersonation attacks are possible [EAPMITM]. 4991 These vulnerabilities occur when EAP is also used in protocols that 4992 are not protected with a secure tunnel. Since EAP is a general- 4993 purpose authentication protocol, which is often used to provide 4994 single-signon facilities, a deployed IPsec solution that relies on an 4995 EAP authentication method that does not generate a shared key (also 4996 known as a non-key-generating EAP method) can become compromised due 4997 to the deployment of an entirely unrelated application that also 4998 happens to use the same non-key-generating EAP method, but in an 4999 unprotected fashion. Note that this vulnerability is not limited to 5000 just EAP, but can occur in other scenarios where an authentication 5001 infrastructure is reused. For example, if the EAP mechanism used by 5002 IKEv2 utilizes a token authenticator, a man-in-the-middle attacker 5003 could impersonate the web server, intercept the token authentication 5004 exchange, and use it to initiate an IKEv2 connection. For this 5005 reason, use of non-key-generating EAP methods SHOULD be avoided where 5006 possible. Where they are used, it is extremely important that all 5007 usages of these EAP methods SHOULD utilize a protected tunnel, where 5008 the initiator validates the responder's certificate before initiating 5009 the EAP exchange. {{ Demoted the SHOULD }} Implementers should 5010 describe the vulnerabilities of using non-key-generating EAP methods 5011 in the documentation of their implementations so that the 5012 administrators deploying IPsec solutions are aware of these dangers. 5014 An implementation using EAP MUST also use strong authentication of 5015 the server to the client before the EAP exchange begins, even if the 5016 EAP method offers mutual authentication. This avoids having 5017 additional IKEv2 protocol variations and protects the EAP data from 5018 active attackers. 5020 If the messages of IKEv2 are long enough that IP-level fragmentation 5021 is necessary, it is possible that attackers could prevent the 5022 exchange from completing by exhausting the reassembly buffers. The 5023 chances of this can be minimized by using the Hash and URL encodings 5024 instead of sending certificates (see Section 3.6). Additional 5025 mitigations are discussed in [DOSUDPPROT]. 5027 5.1. Traffic selector authorization 5029 {{ Added this section from Clarif-4.13 }} 5031 IKEv2 relies on information in the Peer Authorization Database (PAD) 5032 when determining what kind of IPsec SAs a peer is allowed to create. 5033 This process is described in [IPSECARCH] Section 4.4.3. When a peer 5034 requests the creation of an IPsec SA with some traffic selectors, the 5035 PAD must contain "Child SA Authorization Data" linking the identity 5036 authenticated by IKEv2 and the addresses permitted for traffic 5037 selectors. 5039 For example, the PAD might be configured so that authenticated 5040 identity "sgw23.example.com" is allowed to create IPsec SAs for 5041 192.0.2.0/24, meaning this security gateway is a valid 5042 "representative" for these addresses. Host-to-host IPsec requires 5043 similar entries, linking, for example, "fooserver4.example.com" with 5044 192.0.1.66/32, meaning this identity a valid "owner" or 5045 "representative" of the address in question. 5047 As noted in [IPSECARCH], "It is necessary to impose these constraints 5048 on creation of child SAs to prevent an authenticated peer from 5049 spoofing IDs associated with other, legitimate peers." In the 5050 example given above, a correct configuration of the PAD prevents 5051 sgw23 from creating IPsec SAs with address 192.0.1.66, and prevents 5052 fooserver4 from creating IPsec SAs with addresses from 192.0.2.0/24. 5054 It is important to note that simply sending IKEv2 packets using some 5055 particular address does not imply a permission to create IPsec SAs 5056 with that address in the traffic selectors. For example, even if 5057 sgw23 would be able to spoof its IP address as 192.0.1.66, it could 5058 not create IPsec SAs matching fooserver4's traffic. 5060 The IKEv2 specification does not specify how exactly IP address 5061 assignment using configuration payloads interacts with the PAD. Our 5062 interpretation is that when a security gateway assigns an address 5063 using configuration payloads, it also creates a temporary PAD entry 5064 linking the authenticated peer identity and the newly allocated inner 5065 address. 5067 It has been recognized that configuring the PAD correctly may be 5068 difficult in some environments. For instance, if IPsec is used 5069 between a pair of hosts whose addresses are allocated dynamically 5070 using DHCP, it is extremely difficult to ensure that the PAD 5071 specifies the correct "owner" for each IP address. This would 5072 require a mechanism to securely convey address assignments from the 5073 DHCP server, and link them to identities authenticated using IKEv2. 5075 Due to this limitation, some vendors have been known to configure 5076 their PADs to allow an authenticated peer to create IPsec SAs with 5077 traffic selectors containing the same address that was used for the 5078 IKEv2 packets. In environments where IP spoofing is possible (i.e., 5079 almost everywhere) this essentially allows any peer to create IPsec 5080 SAs with any traffic selectors. This is not an appropriate or secure 5081 configuration in most circumstances. See [H2HIPSEC] for an extensive 5082 discussion about this issue, and the limitations of host-to-host 5083 IPsec in general. 5085 6. IANA Considerations 5087 {{ This section was changed to not re-define any new IANA registries. 5089 }} 5091 [IKEV2] defined many field types and values. IANA has already 5092 registered those types and values, so the are not listed here again. 5093 No new types or values are registered in this document. However, 5094 IANA should update all references to RFC 4306 to point to this 5095 document. 5097 7. Acknowledgements 5099 The individuals on the IPsec mailing list was very helpful in both 5100 pointing out where clarifications and changes were needed, as well as 5101 in reviewing the clarifications suggested by others. 5103 The acknowledgements from the IKEv2 document were: 5105 This document is a collaborative effort of the entire IPsec WG. If 5106 there were no limit to the number of authors that could appear on an 5107 RFC, the following, in alphabetical order, would have been listed: 5108 Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt 5109 Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, John 5110 Ioannidis, Charlie Kaufman, Steve Kent, Angelos Keromytis, Tero 5111 Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer 5112 Reingold, and Michael Richardson. Many other people contributed to 5113 the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI, 5114 each of which has its own list of authors. Hugh Daniel suggested the 5115 feature of having the initiator, in message 3, specify a name for the 5116 responder, and gave the feature the cute name "You Tarzan, Me Jane". 5117 David Faucher and Valery Smyzlov helped refine the design of the 5118 traffic selector negotiation. 5120 This paragraph lists references that appear only in figures. The 5121 section is only here to keep the 'xml2rfc' program happy, and needs 5122 to be removed when the document is published. Feel free to ignore 5123 it. [DES] [IDEA] [MD5] [X.501] [X.509] 5125 8. References 5127 8.1. Normative References 5129 [ADDGROUP] 5130 Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 5131 Diffie-Hellman groups for Internet Key Exchange (IKE)", 5132 RFC 3526, May 2003. 5134 [ADDRIPV6] 5135 Hinden, R. and S. Deering, "Internet Protocol Version 6 5136 (IPv6) Addressing Architecture", RFC 4291, February 2006. 5138 [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 5139 Levkowetz, "Extensible Authentication Protocol (EAP)", 5140 RFC 3748, June 2004. 5142 [ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 5143 of Explicit Congestion Notification (ECN) to IP", 5144 RFC 3168, September 2001. 5146 [ESPCBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 5147 Algorithms", RFC 2451, November 1998. 5149 [IPSECARCH] 5150 Kent, S. and K. Seo, "Security Architecture for the 5151 Internet Protocol", RFC 4301, December 2005. 5153 [MUSTSHOULD] 5154 Bradner, S., "Key Words for use in RFCs to indicate 5155 Requirement Levels", BCP 14, RFC 2119, March 1997. 5157 [PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 5158 Standards (PKCS) #1: RSA Cryptography Specifications 5159 Version 2.1", RFC 3447, February 2003. 5161 [PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 5162 X.509 Public Key Infrastructure Certificate and 5163 Certificate Revocation List (CRL) Profile", RFC 3280, 5164 April 2002. 5166 [RFC4434] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the 5167 Internet Key Exchange Protocol (IKE)", RFC 4434, 5168 February 2006. 5170 [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The 5171 Advanced Encryption Standard-Cipher-based Message 5172 Authentication Code-Pseudo-Random Function-128 (AES-CMAC- 5173 PRF-128) Algorithm for the Internet Key Exchange Protocol 5174 (IKE)", RFC 4615, August 2006. 5176 [UDPENCAPS] 5177 Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 5178 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 5179 RFC 3948, January 2005. 5181 8.2. Informative References 5183 [AH] Kent, S., "IP Authentication Header", RFC 4302, 5184 December 2005. 5186 [ARCHGUIDEPHIL] 5187 Bush, R. and D. Meyer, "Some Internet Architectural 5188 Guidelines and Philosophy", RFC 3439, December 2002. 5190 [ARCHPRINC] 5191 Carpenter, B., "Architectural Principles of the Internet", 5192 RFC 1958, June 1996. 5194 [Clarif] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 5195 Implementation Guidelines", RFC 4718, October 2006. 5197 [DES] American National Standards Institute, "American National 5198 Standard for Information Systems-Data Link Encryption", 5199 ANSI X3.106, 1983. 5201 [DH] Diffie, W. and M. Hellman, "New Directions in 5202 Cryptography", IEEE Transactions on Information Theory, 5203 V.IT-22 n. 6, June 1977. 5205 [DHCP] Droms, R., "Dynamic Host Configuration Protocol", 5206 RFC 2131, March 1997. 5208 [DIFFSERVARCH] 5209 Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 5210 and W. Weiss, "An Architecture for Differentiated 5211 Services", RFC 2475. 5213 [DIFFSERVFIELD] 5214 Nichols, K., Blake, S., Baker, F., and D. Black, 5215 "Definition of the Differentiated Services Field (DS 5216 Field) in the IPv4 and IPv6 Headers", RFC 2474, 5217 December 1998. 5219 [DIFFTUNNEL] 5220 Black, D., "Differentiated Services and Tunnels", 5221 RFC 2983, October 2000. 5223 [DOI] Piper, D., "The Internet IP Security Domain of 5224 Interpretation for ISAKMP", RFC 2407, November 1998. 5226 [DOSUDPPROT] 5227 C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection 5228 for UDP-based protocols", ACM Conference on Computer and 5229 Communications Security , October 2003. 5231 [DSS] National Institute of Standards and Technology, U.S. 5232 Department of Commerce, "Digital Signature Standard", 5233 FIPS 186, May 1994. 5235 [EAPMITM] N. Asokan, V. Nierni, and K. Nyberg, "Man-in-the-Middle in 5236 Tunneled Authentication Protocols", November 2002, 5237 . 5239 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", 5240 RFC 4303, December 2005. 5242 [EXCHANGEANALYSIS] 5243 R. Perlman and C. Kaufman, "Analysis of the IPsec key 5244 exchange Standard", WET-ICE Security Conference, MIT , 5245 2001, 5246 . 5248 [H2HIPSEC] 5249 Aura, T., Roe, M., and A. Mohammed, "Experiences with 5250 Host-to-Host IPsec", 13th International Workshop on 5251 Security Protocols, Cambridge, UK, April 2005. 5253 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 5254 Hashing for Message Authentication", RFC 2104, 5255 February 1997. 5257 [IDEA] X. Lai, "On the Design and Security of Block Ciphers", ETH 5258 Series in Information Processing, v. 1, Konstanz: Hartung- 5259 Gorre Verlag, 1992. 5261 [IDNA] Faltstrom, P., Hoffman, P., and A. Costello, 5262 "Internationalizing Domain Names in Applications (IDNA)", 5263 RFC 3490, March 2003. 5265 [IKEV1] Harkins, D. and D. Carrel, "The Internet Key Exchange 5266 (IKE)", RFC 2409, November 1998. 5268 [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 5269 RFC 4306, December 2005. 5271 [IPCOMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP 5272 Payload Compression Protocol (IPComp)", RFC 3173, 5273 September 2001. 5275 [IPSECARCH-OLD] 5276 Kent, S. and R. Atkinson, "Security Architecture for the 5277 Internet Protocol", RFC 2401, November 1998. 5279 [IPV6ADDR] 5280 Hinden, R. and S. Deering, "Internet Protocol Version 6 5281 (IPv6) Addressing Architecture", RFC 3513, April 2003. 5283 [ISAKMP] Maughan, D., Schneider, M., and M. Schertler, "Internet 5284 Security Association and Key Management Protocol 5285 (ISAKMP)", RFC 2408, November 1998. 5287 [LDAP] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory 5288 Access Protocol (v3)", RFC 2251, December 1997. 5290 [MAILFORMAT] 5291 Resnick, P., "Internet Message Format", RFC 2822, 5292 April 2001. 5294 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 5295 April 1992. 5297 [MIPV6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 5298 in IPv6", RFC 3775, June 2004. 5300 [MLDV2] Vida, R. and L. Costa, "Multicast Listener Discovery 5301 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 5303 [MODES] National Institute of Standards and Technology, U.S. 5304 Department of Commerce, "Recommendation for Block Cipher 5305 Modes of Operation", SP 800-38A, 2001. 5307 [NAI] Aboba, B. and M. Beadles, "The Network Access Identifier", 5308 RFC 2486, January 1999. 5310 [NATREQ] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 5311 (NAT) Compatibility Requirements", RFC 3715, March 2004. 5313 [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", 5314 RFC 2412, November 1998. 5316 [PFKEY] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 5317 Management API, Version 2", RFC 2367, July 1998. 5319 [PHOTURIS] 5320 Karn, P. and W. Simpson, "Photuris: Session-Key Management 5321 Protocol", RFC 2522, March 1999. 5323 [RADIUS] Rigney, C., Rubens, A., Simpson, W., and S. Willens, 5324 "Remote Authentication Dial In User Service (RADIUS)", 5325 RFC 2138, April 1997. 5327 [RANDOMNESS] 5328 Eastlake, D., Schiller, J., and S. Crocker, "Randomness 5329 Requirements for Security", BCP 106, RFC 4086, June 2005. 5331 [REAUTH] Nir, Y., "Repeated Authentication in Internet Key Exchange 5332 (IKEv2) Protocol", RFC 4478, April 2006. 5334 [RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for 5335 Obtaining Digital Signatures and Public-Key 5336 Cryptosystems", February 1978. 5338 [SHA] National Institute of Standards and Technology, U.S. 5339 Department of Commerce, "Secure Hash Standard", 5340 FIPS 180-1, May 1994. 5342 [SIGMA] H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to 5343 Authenticated Diffie-Hellman and its Use in the IKE 5344 Protocols", Advances in Cryptography - CRYPTO 2003 5345 Proceedings LNCS 2729, 2003, . 5349 [SKEME] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange 5350 Mechanism for Internet", IEEE Proceedings of the 1996 5351 Symposium on Network and Distributed Systems Security , 5352 1996. 5354 [TRANSPARENCY] 5355 Carpenter, B., "Internet Transparency", RFC 2775, 5356 February 2000. 5358 [X.501] ITU-T, "Recommendation X.501: Information Technology - 5359 Open Systems Interconnection - The Directory: Models", 5360 1993. 5362 [X.509] ITU-T, "Recommendation X.509 (1997 E): Information 5363 Technology - Open Systems Interconnection - The Directory: 5364 Authentication Framework", 1997. 5366 Appendix A. Summary of changes from IKEv1 5368 The goals of this revision to IKE are: 5370 1. To define the entire IKE protocol in a single document, 5371 replacing RFCs 2407, 2408, and 2409 and incorporating subsequent 5372 changes to support NAT Traversal, Extensible Authentication, and 5373 Remote Address acquisition; 5375 2. To simplify IKE by replacing the eight different initial 5376 exchanges with a single four-message exchange (with changes in 5377 authentication mechanisms affecting only a single AUTH payload 5378 rather than restructuring the entire exchange) see 5379 [EXCHANGEANALYSIS]; 5381 3. To remove the Domain of Interpretation (DOI), Situation (SIT), 5382 and Labeled Domain Identifier fields, and the Commit and 5383 Authentication only bits; 5385 4. To decrease IKE's latency in the common case by making the 5386 initial exchange be 2 round trips (4 messages), and allowing the 5387 ability to piggyback setup of a CHILD_SA on that exchange; 5389 5. To replace the cryptographic syntax for protecting the IKE 5390 messages themselves with one based closely on ESP to simplify 5391 implementation and security analysis; 5393 6. To reduce the number of possible error states by making the 5394 protocol reliable (all messages are acknowledged) and sequenced. 5395 This allows shortening CREATE_CHILD_SA exchanges from 3 messages 5396 to 2; 5398 7. To increase robustness by allowing the responder to not do 5399 significant processing until it receives a message proving that 5400 the initiator can receive messages at its claimed IP address; 5402 8. To fix cryptographic weaknesses such as the problem with 5403 symmetries in hashes used for authentication documented by Tero 5404 Kivinen; 5406 9. To specify Traffic Selectors in their own payloads type rather 5407 than overloading ID payloads, and making more flexible the 5408 Traffic Selectors that may be specified; 5410 10. To specify required behavior under certain error conditions or 5411 when data that is not understood is received in order to make it 5412 easier to make future revisions in a way that does not break 5413 backwards compatibility; 5415 11. To simplify and clarify how shared state is maintained in the 5416 presence of network failures and Denial of Service attacks; and 5418 12. To maintain existing syntax and magic numbers to the extent 5419 possible to make it likely that implementations of IKEv1 can be 5420 enhanced to support IKEv2 with minimum effort. 5422 Appendix B. Diffie-Hellman Groups 5424 There are two Diffie-Hellman groups defined here for use in IKE. 5425 These groups were generated by Richard Schroeppel at the University 5426 of Arizona. Properties of these primes are described in [OAKLEY]. 5428 The strength supplied by group one may not be sufficient for the 5429 mandatory-to-implement encryption algorithm and is here for historic 5430 reasons. 5432 Additional Diffie-Hellman groups have been defined in [ADDGROUP]. 5434 B.1. Group 1 - 768 Bit MODP 5436 This group is assigned id 1 (one). 5438 The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } 5439 Its hexadecimal value is: 5441 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 5442 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 5443 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 5444 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF 5446 The generator is 2. 5448 B.2. Group 2 - 1024 Bit MODP 5450 This group is assigned id 2 (two). 5452 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. 5453 Its hexadecimal value is: 5455 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 5456 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 5457 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 5458 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 5459 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 5460 FFFFFFFF FFFFFFFF 5462 The generator is 2. 5464 Appendix C. Exchanges and Payloads 5466 {{ Clarif-AppA }} 5468 This appendix contains a short summary of the IKEv2 exchanges, and 5469 what payloads can appear in which message. This appendix is purely 5470 informative; if it disagrees with the body of this document, the 5471 other text is considered correct. 5473 Vendor-ID (V) payloads may be included in any place in any message. 5474 This sequence here shows what are the most logical places for them. 5476 C.1. IKE_SA_INIT Exchange 5478 request --> [N(COOKIE)], 5479 SA, KE, Ni, 5480 [N(NAT_DETECTION_SOURCE_IP)+, 5481 N(NAT_DETECTION_DESTINATION_IP)], 5482 [V+] 5484 normal response <-- SA, KE, Nr, 5485 (no cookie) [N(NAT_DETECTION_SOURCE_IP), 5486 N(NAT_DETECTION_DESTINATION_IP)], 5487 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 5488 [V+] 5490 C.2. IKE_AUTH Exchange without EAP 5492 request --> IDi, [CERT+], 5493 [N(INITIAL_CONTACT)], 5494 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 5495 [IDr], 5496 AUTH, 5497 [CP(CFG_REQUEST)], 5498 [N(IPCOMP_SUPPORTED)+], 5499 [N(USE_TRANSPORT_MODE)], 5500 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5501 [N(NON_FIRST_FRAGMENTS_ALSO)], 5502 SA, TSi, TSr, 5503 [V+] 5505 response <-- IDr, [CERT+], 5506 AUTH, 5507 [CP(CFG_REPLY)], 5508 [N(IPCOMP_SUPPORTED)], 5509 [N(USE_TRANSPORT_MODE)], 5510 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5511 [N(NON_FIRST_FRAGMENTS_ALSO)], 5512 SA, TSi, TSr, 5513 [N(ADDITIONAL_TS_POSSIBLE)], 5514 [V+] 5516 C.3. IKE_AUTH Exchange with EAP 5518 first request --> IDi, 5519 [N(INITIAL_CONTACT)], 5520 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 5521 [IDr], 5522 [CP(CFG_REQUEST)], 5523 [N(IPCOMP_SUPPORTED)+], 5524 [N(USE_TRANSPORT_MODE)], 5525 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5526 [N(NON_FIRST_FRAGMENTS_ALSO)], 5527 SA, TSi, TSr, 5528 [V+] 5530 first response <-- IDr, [CERT+], AUTH, 5531 EAP, 5532 [V+] 5534 / --> EAP 5535 repeat 1..N times | 5536 \ <-- EAP 5538 last request --> AUTH 5540 last response <-- AUTH, 5541 [CP(CFG_REPLY)], 5542 [N(IPCOMP_SUPPORTED)], 5543 [N(USE_TRANSPORT_MODE)], 5544 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5545 [N(NON_FIRST_FRAGMENTS_ALSO)], 5546 SA, TSi, TSr, 5547 [N(ADDITIONAL_TS_POSSIBLE)], 5548 [V+] 5550 C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying CHILD_SAs 5552 request --> [N(REKEY_SA)], 5553 [CP(CFG_REQUEST)], 5554 [N(IPCOMP_SUPPORTED)+], 5555 [N(USE_TRANSPORT_MODE)], 5556 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5557 [N(NON_FIRST_FRAGMENTS_ALSO)], 5558 SA, Ni, [KEi], TSi, TSr 5560 response <-- [CP(CFG_REPLY)], 5561 [N(IPCOMP_SUPPORTED)], 5562 [N(USE_TRANSPORT_MODE)], 5563 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5564 [N(NON_FIRST_FRAGMENTS_ALSO)], 5565 SA, Nr, [KEr], TSi, TSr, 5566 [N(ADDITIONAL_TS_POSSIBLE)] 5568 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA 5570 request --> SA, Ni, [KEi] 5572 response <-- SA, Nr, [KEr] 5574 C.6. INFORMATIONAL Exchange 5576 request --> [N+], 5577 [D+], 5578 [CP(CFG_REQUEST)] 5580 response <-- [N+], 5581 [D+], 5582 [CP(CFG_REPLY)] 5584 Appendix D. Changes Between Internet Draft Versions 5586 This section will be removed before publication as an RFC, but should 5587 be left intact until then so that reviewers can follow what has 5588 changed. 5590 D.1. Changes from IKEv2 to draft -00 5592 There were a zillion additions from RFC 4718. These are noted with 5593 "{{ Clarif-nn }}". 5595 Cleaned up many of the figures. Made the table headings consistent. 5596 Made some tables easier to read by removing blank spaces. Removed 5597 the "reserved to IANA" and "private use" text wording and moved it 5598 into the tables. 5600 Changed many SHOULD requirements to better match RFC 2119. These are 5601 also marked with comments such as "{{ Demoted the SHOULD }}". 5603 In Section 2.16, changed the MUST requirement of authenticating the 5604 responder from "public key signature based" to "strong" because that 5605 is what most current IKEv2 implementations do, and it better matches 5606 the actual security requirement. 5608 D.2. Changes from draft -00 to draft -01 5610 The most significant technical change was to make KE optional but 5611 strongly recommended in Section 1.3.2. 5613 Updated all references to the IKEv2 Clarifications document to RFC 5614 4718. 5616 Moved a lot of the protocol description out of the long tables in 5617 Section 3.10.1 into the body of the document. These are noted with 5618 "{{ 3.10.1-nnnn }}", where "nnnn" is the notification type number. 5620 Made some table changes based on suggestions from Alfred Hoenes. 5622 Changed "byte" to "octet" in many places. 5624 Removed discussion of ESP+AH bundles in many places, and added a 5625 paragraph about it in Section 1.7. 5627 Removed the discussion of INTERNAL_ADDRESS_EXPIRY in many places, and 5628 added a paragraph about it in Section 1.7. 5630 Moved Clarif-7.10 from Section 1.2 to Section 3.2. 5632 In the figure in Section 1.3.2, made KEi optional, and added text 5633 saying "The KEi payload SHOULD be included." 5635 In the figure in Section 1.3.2, maked KEr optional, and removed text 5636 saying "KEi and KEr are required for rekeying an IKE_SA." 5638 In Section 1.4, clarified that the half-closed connections being 5639 discussed are AH and ESP. 5641 Rearranged the end of Section 1.7, and added the new notation for 5642 moving text out of 3.10.1. 5644 Clarified the wording in the second paragraph of Section 2.2. This 5645 allowd the removal of the fourth paragraph, which previously had 5646 Clarif-2.2 in it. 5648 In section 2.5, removed "or later" from "version 2.0". 5650 Added the question for implementers about payload order at the end of 5651 Section 2.5. 5653 Corrected Section 2.7 based on Clarif-7-13 to say that you can't do 5654 ESP and AH at one time. 5656 In Section 2.8, clarified the wording about how to replace an IKE_SA. 5658 Clarified the text in the last many paragraphs in Section 2.9. Also 5659 moved some text from near the beginning of 2.9 to the beginning of 5660 2.9.1. 5662 Removed some redundant text in Section 2.9 concerning creating a 5663 CHILD_SA pair not in response to an arriving packet. 5665 Added the following to the end of the first paragraph of Section 5666 2.14: "The lengths of SK_d, SK_pi, and SK_pr are the key length of 5667 the agreed-to PRF." 5669 Added the restriction in Section 2.15 that all PRFs used with IKEv2 5670 MUST take variable-sized keys. 5672 In Section 2.17, removed "If multiple IPsec protocols are negotiated, 5673 keying material is taken in the order in which the protocol headers 5674 will appear in the encapsulated packet" because multiple IPsec 5675 protocols cannot be negotiated at one time. 5677 Added the material from Clarif-5.12 to Section 2.18. 5679 Changed "hash of" to "expected value of" in Section 2.23. 5681 In the bulleted list in Section 2.23, replaced "this end" with a 5682 clearer description of which system is being discussed. 5684 Added the paragraph at the beginning of Section 3 about 5685 interoperability and UNSPECIFIED values ("In the tables in this 5686 section..."). 5688 Fixed Section 3.3 to not include proposal that include both AH and 5689 ESP. Ditto for the "Proposal #" bullet in Section 3.3.1. 5691 In the description of ID_FQDN in Section 3.5, added "All characters 5692 in the ID_FQDN are ASCII; this follows that for an "internationalized 5693 domain name" as defined in [IDNA]." 5695 In Section 3.8, shortened and clarified the description of "RSA 5696 Digital Signature". 5698 In Section 3.10, shortened and clarified the description of "Protocol 5699 ID". 5701 In Section 3.15, "The requested address is valid until the expiry 5702 time defined with the INTERNAL_ADDRESS_EXPIRY attribute or there are 5703 no IKE_SAs between the peers" is shortened to just "The requested 5704 address is valid until there are no IKE_SAs between the peers." 5706 In Section 3.15.1, changed "INTERNAL_IP6_NBNS" to unspecified. 5708 Made [ADDRIPV6] an informative reference instead of a normative 5709 reference and updated it. 5711 Made [PKCS1] a normative reference instead of an informative 5712 reference and changed the pointer to RFC 3447. 5714 D.3. Changes from draft -00 to draft -01 5716 In Section 1.5, added "request" to first sentence to make it "If an 5717 encrypted IKE request packet arrives on port 500 or 4500 with an 5718 unrecognized SPI...". 5720 In Section 3.3, fifth paragraph, upped the number of transforms for 5721 AH and ESP by one each to account for ESN, which is now mandatory. 5723 In Section 2.1, added "or equal to" in "The responder MUST remember 5724 each response until it receives a request whose sequence number is 5725 larger than or equal to the sequence number in the response plus its 5726 window size." 5728 In Section 2.18, removed " Note that this may not work if the new 5729 IKE_SA's PRF has a fixed key size because the output of the PRF may 5730 not be of the correct size." because it is no longer relevant. 5732 D.4. Changes from draft -01 to draft -02 5734 Many grammatical fixes. 5736 In Section 1.2, reworded Clarif-4.3 to be clearer. 5738 In Section 1.3.3, reworded 3.10.1-16393 and Clarif-5.4 to remove 5739 redundant text. 5741 In Section 2.13, replaced text about variable length keys with 5742 clearer explanation and requirement on non-HMAC PRFs. Also added 5743 "preferred" to Section 2.14 for the key length, and removed redundant 5744 text. 5746 In Section 2.14, removed the "half and half" description and replaced 5747 it with exceptions for RFC4434 and RFC4615. 5749 Removed the now-redundant "All PRFs used with IKEv2 MUST take 5750 variable-sized keys" from Section 2.15. 5752 In Section 2.15, added "(IKE_SA_INIT response)" after "of the second 5753 message" and "(IKE_SA_INIT request)" after "the first message". 5755 In Section 2.17, simplified because there are no more bundles. "A 5756 single CHILD_SA negotiation may result in multiple security 5757 associations. ESP and AH SAs exist in pairs (one in each 5758 direction)." becomes "For ESP and AH, a single CHILD_SA negotiation 5759 results in two security associations (one in each direction)." 5761 In section 3.3, made the example of combinations of algorithms and 5762 the contents of the first proposal clearer. 5764 Added Clarif-4.4 to the ned of Section 3.3.2. 5766 Reordered Section 3.3.5 and added Clarif-7.11. 5768 Clarified Section 3.3.6 about choosing a single proposal. Also added 5769 second paragraph about transforms not understood, and clarified third 5770 paragraph about picking D-H groups. 5772 Moved 3.10.1-16392 from Section 3.6 to 3.7. 5774 In Section 3.10, clarified 3.10.1-16394. 5776 Updated Section 6 to indicate that there is nothing new for IANA in 5777 this spec. Also removed the definition of "Expert Review" from 5778 Section 1.6 for the same reason. 5780 In Appendix A, removed "and not commit any state to an exchange until 5781 the initiator can be cryptographically authenticated" because that 5782 was only true in an earlier version of IKEv2. 5784 D.5. Changes from draft -02 to draft -03 5786 In Section 1.3, changed "If the responder rejects the Diffie-Hellman 5787 group of the KEi payload, the responder MUST reject the request and 5788 indicate its preferred Diffie-Hellman group in the INVALID_KE_PAYLOAD 5789 Notification payload." to "If the responder selects a proposal using 5790 a different Diffie-Hellman group (other than NONE), the responder 5791 MUST reject the request and indicate its preferred Diffie-Hellman 5792 group in the INVALID_KE_PAYLOAD Notification payload. 5794 In Section 2.3, added the last two paragraphs covering why you 5795 initiator's SPI and/or IP to differentiate if this is a "half-open" 5796 IKE_SA or a new request. Also removed similar text from Section 2.2. 5798 In Section 2.5, added "Payloads sent in IKE response messages MUST 5799 NOT have the critical flag set. Note that the critical flag applies 5800 only to the payload type, not the contents. If the payload type is 5801 recognized, but the payload contains something which is not (such as 5802 an unknown transform inside an SA payload, or an unknown Notify 5803 Message Type inside a Notify payload), the critical flag is ignored." 5805 In Section 2.6, moved the text about {{ 3.10.1-16390 }} later in the 5806 section. Also reworded the text to make it clearer what the COOKIE 5807 is for. 5809 Moved text from {{ Clarif-2.1 }} from Section 2.6 to Section 2.7. 5811 In Section 2.13, added "(see Section 3.3.5 for the defintion of the 5812 Key Length transform attribute)". 5814 In Section 2.17, change the description of the keying material from 5815 the list with two bullets to a clearer list. 5817 In Section 2.23, added "Implementations MUST process received UDP- 5818 encapsulated ESP packets even when no NAT was detected." 5820 In Section 3.3, changed "Each proposal may contain a" to "Each 5821 proposal contains a". 5823 Added the asterisks to the tranform type table in Section 3.3.2 and 5824 the types table in 3.3.3 to foreshadow future developments. 5826 In Section 3.3.2, changed the following algorithms to (UNSPECIFIED) 5827 because the RFCs listed didn't really specify how to implement them 5828 in an interoperable fashion: 5830 Encryption Algorithms 5831 ENCR_DES_IV64 1 (RFC1827) 5832 ENCR_3IDEA 8 (RFC2451) 5833 ENCR_DES_IV32 9 5834 Pseudo-random Functions 5835 PRF_HMAC_TIGER 3 (RFC2104) 5836 Integrity Algorithms 5837 AUTH_DES_MAC 3 5838 AUTH_KPDK_MD5 4 (RFC1826) 5840 In Section 3.4, added "(other than NONE)" to the second-to-last 5841 paragraph. 5843 Rewrote the third paragraph of Section 3.14 to talk about other 5844 modes, and to clarify which encryption and integrity protection we 5845 are talking about. 5847 Changed the "Initialization Vector" bullet in Section 3.14 to specify 5848 better what is needed for the IV. Upgraded the SHOULDs to MUSTs. 5849 Also added the reference for [MODES]. 5851 In Section 5, in the second-to-last paragraph, changed "a public-key- 5852 based" to "strong" to match the wording in Section 2.16. 5854 Authors' Addresses 5856 Charlie Kaufman 5857 Microsoft 5858 1 Microsoft Way 5859 Redmond, WA 98052 5860 US 5862 Phone: 1-425-707-3335 5863 Email: charliek@microsoft.com 5865 Paul Hoffman 5866 VPN Consortium 5867 127 Segre Place 5868 Santa Cruz, CA 95060 5869 US 5871 Phone: 1-831-426-9827 5872 Email: paul.hoffman@vpnc.org 5873 Pasi Eronen 5874 Nokia Research Center 5875 P.O. Box 407 5876 FIN-00045 Nokia Group 5877 Finland 5879 Email: pasi.eronen@nokia.com 5881 Full Copyright Statement 5883 Copyright (C) The IETF Trust (2008). 5885 This document is subject to the rights, licenses and restrictions 5886 contained in BCP 78, and except as set forth therein, the authors 5887 retain all their rights. 5889 This document and the information contained herein are provided on an 5890 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 5891 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 5892 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 5893 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 5894 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 5895 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 5897 Intellectual Property 5899 The IETF takes no position regarding the validity or scope of any 5900 Intellectual Property Rights or other rights that might be claimed to 5901 pertain to the implementation or use of the technology described in 5902 this document or the extent to which any license under such rights 5903 might or might not be available; nor does it represent that it has 5904 made any independent effort to identify any such rights. Information 5905 on the procedures with respect to rights in RFC documents can be 5906 found in BCP 78 and BCP 79. 5908 Copies of IPR disclosures made to the IETF Secretariat and any 5909 assurances of licenses to be made available, or the result of an 5910 attempt made to obtain a general license or permission for the use of 5911 such proprietary rights by implementers or users of this 5912 specification can be obtained from the IETF on-line IPR repository at 5913 http://www.ietf.org/ipr. 5915 The IETF invites any interested party to bring to its attention any 5916 copyrights, patents or patent applications, or other proprietary 5917 rights that may cover technology that may be required to implement 5918 this standard. Please address the information to the IETF at 5919 ietf-ipr@ietf.org. 5921 Acknowledgment 5923 Funding for the RFC Editor function is provided by the IETF 5924 Administrative Support Activity (IASA).