idnits 2.17.1 draft-hoffman-ikev2-1-00.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 5506. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 5517. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 5524. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 5530. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 20 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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.). == 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 (January 2006) is 6677 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CERTREQ' is mentioned on line 2005, but not defined == Missing Reference: 'KEi' is mentioned on line 5451, but not defined == Missing Reference: 'KEr' is mentioned on line 5453, but not defined == Missing Reference: 'CP' is mentioned on line 684, but not defined -- Looks like a reference, but probably isn't: '1' on line 3385 -- Looks like a reference, but probably isn't: '0' on line 3384 == Missing Reference: 'IDr' is mentioned on line 5404, but not defined ** Obsolete normative reference: RFC 3513 (ref. 'ADDRIPV6') (Obsoleted by RFC 4291) ** Downref: Normative reference to an Informational draft: draft-eronen-ipsec-ikev2-clarifications (ref. 'Clarif') ** Obsolete normative reference: RFC 2434 (ref. 'IANACONS') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 4306 (ref. 'IKEV2') (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 3280 (ref. 'PKIX') (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 2407 (ref. 'DOI') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. 'IKEV1') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. 'IPSECARCH-OLD') (Obsoleted by RFC 4301) -- Duplicate reference: RFC3513, mentioned in 'IPV6ADDR', was also mentioned in 'ADDRIPV6'. -- 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 3664 (ref. 'PRFAES128CBC') (Obsoleted by RFC 4434) -- Obsolete informational reference (is this intentional?): RFC 2138 (ref. 'RADIUS') (Obsoleted by RFC 2865) Summary: 8 errors (**), 0 flaws (~~), 12 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft VPN Consortium 4 Expires: July 5, 2006 January 2006 6 Internet Key Exchange Protocol: IKEv2.1 7 draft-hoffman-ikev2-1-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on July 5, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document describes version 2.1 of the Internet Key Exchange 41 (IKE) protocol. IKEv2.1 is heavily based on IKEv2 from RFC 4306 42 (edited by Charlie Kaufman), and includes all of the clarifications 43 from the "IKEv2 Clarifications" document (edited by Pasi Eronen and 44 Paul Hoffman). IKEv2.1 makes additional changes to those two 45 documents in places where IKEv2 was unclear and the clarifications 46 document did not commit to a particular protocol interpretation. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 51 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 6 52 1.1.1. Security Gateway to Security Gateway Tunnel . . . . . 7 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 . . . . . . . . . . . . . . . . . . . 9 56 1.2. The Initial Exchanges . . . . . . . . . . . . . . . . . . 9 57 1.3. The CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 12 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 . 13 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 . . . . . . . 16 65 1.6. Requirements Terminology . . . . . . . . . . . . . . . . 17 66 1.7. Introduction to IKEv2.1 . . . . . . . . . . . . . . . . . 17 67 2. IKE Protocol Details and Variations . . . . . . . . . . . . . 18 68 2.1. Use of Retransmission Timers . . . . . . . . . . . . . . 19 69 2.2. Use of Sequence Numbers for Message ID . . . . . . . . . 19 70 2.3. Window Size for Overlapping Requests . . . . . . . . . . 20 71 2.4. State Synchronization and Connection Timeouts . . . . . . 21 72 2.5. Version Numbers and Forward Compatibility . . . . . . . . 23 73 2.6. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 25 74 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . 27 75 2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 28 76 2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 29 77 2.8.1. Simultaneous CHILD_SA rekeying . . . . . . . . . . . 31 78 2.8.2. Rekeying the IKE_SA Versus Reauthentication . . . . . 33 79 2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 34 80 2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 37 81 2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 38 82 2.11. Address and Port Agility . . . . . . . . . . . . . . . . 38 83 2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 38 84 2.13. Generating Keying Material . . . . . . . . . . . . . . . 39 85 2.14. Generating Keying Material for the IKE_SA . . . . . . . . 40 86 2.15. Authentication of the IKE_SA . . . . . . . . . . . . . . 41 87 2.16. Extensible Authentication Protocol Methods . . . . . . . 43 88 2.17. Generating Keying Material for CHILD_SAs . . . . . . . . 45 89 2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA Exchange . . . . 46 90 2.19. Requesting an Internal Address on a Remote Network . . . 47 91 2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 48 92 2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 49 93 2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 50 94 2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 50 95 2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 53 97 3. Header and Payload Formats . . . . . . . . . . . . . . . . . 53 98 3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 53 99 3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 56 100 3.3. Security Association Payload . . . . . . . . . . . . . . 58 101 3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 60 102 3.3.2. Transform Substructure . . . . . . . . . . . . . . . 62 103 3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 64 104 3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 65 105 3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 66 106 3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 67 107 3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 68 108 3.5. Identification Payloads . . . . . . . . . . . . . . . . . 69 109 3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 71 110 3.7. Certificate Request Payload . . . . . . . . . . . . . . . 74 111 3.8. Authentication Payload . . . . . . . . . . . . . . . . . 76 112 3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 77 113 3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 77 114 3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 78 115 3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 84 116 3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 85 117 3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 86 118 3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 88 119 3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 90 120 3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 92 121 3.15.1. Configuration Attributes . . . . . . . . . . . . . . 94 122 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 97 123 3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 99 124 3.15.4. Address Assignment Failures . . . . . . . . . . . . . 100 125 3.16. Extensible Authentication Protocol (EAP) Payload . . . . 100 126 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 102 127 5. Security Considerations . . . . . . . . . . . . . . . . . . . 104 128 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 107 129 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 107 130 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 108 131 8.1. Normative References . . . . . . . . . . . . . . . . . . 108 132 8.2. Informative References . . . . . . . . . . . . . . . . . 109 133 Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 112 134 Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 114 135 B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 114 136 B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 114 137 Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 115 138 C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 115 139 C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 116 140 C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 117 141 C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying 142 CHILD_SAs . . . . . . . . . . . . . . . . . . . . . . . . 118 143 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA . . . . 118 144 C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 118 146 Appendix D. Changes Between Internet Draft Versions . . . . . . 118 147 D.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 118 148 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 119 149 Intellectual Property and Copyright Statements . . . . . . . . . 119 151 1. Introduction 153 {{ An introduction to IKEv2.1 is given at the end of Section 1. It 154 is put there (instead of here) to preserve the section numbering of 155 the original IKEv2 document. }} 157 IP Security (IPsec) provides confidentiality, data integrity, access 158 control, and data source authentication to IP datagrams. These 159 services are provided by maintaining shared state between the source 160 and the sink of an IP datagram. This state defines, among other 161 things, the specific services provided to the datagram, which 162 cryptographic algorithms will be used to provide the services, and 163 the keys used as input to the cryptographic algorithms. 165 Establishing this shared state in a manual fashion does not scale 166 well. Therefore, a protocol to establish this state dynamically is 167 needed. This memo describes such a protocol -- the Internet Key 168 Exchange (IKE). This is version 2.1 of IKE. Version 1 of IKE was 169 defined in RFCs 2407 [DOI], 2408 [ISAKMP], and 2409 [IKEV1]. IKEv2 170 was defined in [IKEV2]. This single document is intended to replace 171 all three of those RFCs. 173 Definitions of the primitive terms in this document (such as Security 174 Association or SA) can be found in [IPSECARCH]. {{ Clarif-7.2 }} It 175 should be noted that parts of IKEv2 and IKEv2.1 rely on some of the 176 processing rules in [IPSECARCH], as described in various sections of 177 this document. 179 IKE performs mutual authentication between two parties and 180 establishes an IKE security association (SA) that includes shared 181 secret information that can be used to efficiently establish SAs for 182 Encapsulating Security Payload (ESP) [ESP] and/or Authentication 183 Header (AH) [AH] and a set of cryptographic algorithms to be used by 184 the SAs to protect the traffic that they carry. In this document, 185 the term "suite" or "cryptographic suite" refers to a complete set of 186 algorithms used to protect an SA. An initiator proposes one or more 187 suites by listing supported algorithms that can be combined into 188 suites in a mix-and-match fashion. IKE can also negotiate use of IP 189 Compression (IPComp) [IPCOMP] in connection with an ESP and/or AH SA. 190 We call the IKE SA an "IKE_SA". The SAs for ESP and/or AH that get 191 set up through that IKE_SA we call "CHILD_SAs". 193 All IKE communications consist of pairs of messages: a request and a 194 response. The pair is called an "exchange". We call the first 195 messages establishing an IKE_SA IKE_SA_INIT and IKE_AUTH exchanges 196 and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL 197 exchanges. In the common case, there is a single IKE_SA_INIT 198 exchange and a single IKE_AUTH exchange (a total of four messages) to 199 establish the IKE_SA and the first CHILD_SA. In exceptional cases, 200 there may be more than one of each of these exchanges. In all cases, 201 all IKE_SA_INIT exchanges MUST complete before any other exchange 202 type, then all IKE_AUTH exchanges MUST complete, and following that 203 any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur 204 in any order. In some scenarios, only a single CHILD_SA is needed 205 between the IPsec endpoints, and therefore there would be no 206 additional exchanges. Subsequent exchanges MAY be used to establish 207 additional CHILD_SAs between the same authenticated pair of endpoints 208 and to perform housekeeping functions. 210 IKE message flow always consists of a request followed by a response. 211 It is the responsibility of the requester to ensure reliability. If 212 the response is not received within a timeout interval, the requester 213 needs to retransmit the request (or abandon the connection). 215 The first request/response of an IKE session (IKE_SA_INIT) negotiates 216 security parameters for the IKE_SA, sends nonces, and sends Diffie- 217 Hellman values. 219 The second request/response (IKE_AUTH) transmits identities, proves 220 knowledge of the secrets corresponding to the two identities, and 221 sets up an SA for the first (and often only) AH and/or ESP CHILD_SA. 223 The types of subsequent exchanges are CREATE_CHILD_SA (which creates 224 a CHILD_SA) and INFORMATIONAL (which deletes an SA, reports error 225 conditions, or does other housekeeping). Every request requires a 226 response. An INFORMATIONAL request with no payloads (other than the 227 empty Encrypted payload required by the syntax) is commonly used as a 228 check for liveness. These subsequent exchanges cannot be used until 229 the initial exchanges have completed. 231 In the description that follows, we assume that no errors occur. 232 Modifications to the flow should errors occur are described in 233 Section 2.21. 235 1.1. Usage Scenarios 237 IKE is expected to be used to negotiate ESP and/or AH SAs in a number 238 of different scenarios, each with its own special requirements. 240 1.1.1. Security Gateway to Security Gateway Tunnel 242 +-+-+-+-+-+ +-+-+-+-+-+ 243 ! ! IPsec ! ! 244 Protected !Tunnel ! tunnel !Tunnel ! Protected 245 Subnet <-->!Endpoint !<---------->!Endpoint !<--> Subnet 246 ! ! ! ! 247 +-+-+-+-+-+ +-+-+-+-+-+ 249 Figure 1: Security Gateway to Security Gateway Tunnel 251 In this scenario, neither endpoint of the IP connection implements 252 IPsec, but network nodes between them protect traffic for part of the 253 way. Protection is transparent to the endpoints, and depends on 254 ordinary routing to send packets through the tunnel endpoints for 255 processing. Each endpoint would announce the set of addresses 256 "behind" it, and packets would be sent in tunnel mode where the inner 257 IP header would contain the IP addresses of the actual endpoints. 259 1.1.2. Endpoint-to-Endpoint Transport 261 +-+-+-+-+-+ +-+-+-+-+-+ 262 ! ! IPsec transport ! ! 263 !Protected! or tunnel mode SA !Protected! 264 !Endpoint !<---------------------------------------->!Endpoint ! 265 ! ! ! ! 266 +-+-+-+-+-+ +-+-+-+-+-+ 268 Figure 2: Endpoint to Endpoint 270 In this scenario, both endpoints of the IP connection implement 271 IPsec, as required of hosts in [IPSECARCH]. Transport mode will 272 commonly be used with no inner IP header. If there is an inner IP 273 header, the inner addresses will be the same as the outer addresses. 274 A single pair of addresses will be negotiated for packets to be 275 protected by this SA. These endpoints MAY implement application 276 layer access controls based on the IPsec authenticated identities of 277 the participants. This scenario enables the end-to-end security that 278 has been a guiding principle for the Internet since [ARCHPRINC], 279 [TRANSPARENCY], and a method of limiting the inherent problems with 280 complexity in networks noted by [ARCHGUIDEPHIL]. Although this 281 scenario may not be fully applicable to the IPv4 Internet, it has 282 been deployed successfully in specific scenarios within intranets 283 using IKEv1. It should be more broadly enabled during the transition 284 to IPv6 and with the adoption of IKEv2. 286 It is possible in this scenario that one or both of the protected 287 endpoints will be behind a network address translation (NAT) node, in 288 which case the tunneled packets will have to be UDP encapsulated so 289 that port numbers in the UDP headers can be used to identify 290 individual endpoints "behind" the NAT (see Section 2.23). 292 1.1.3. Endpoint to Security Gateway Tunnel 294 +-+-+-+-+-+ +-+-+-+-+-+ 295 ! ! IPsec ! ! Protected 296 !Protected! tunnel !Tunnel ! Subnet 297 !Endpoint !<------------------------>!Endpoint !<--- and/or 298 ! ! ! ! Internet 299 +-+-+-+-+-+ +-+-+-+-+-+ 301 Figure 3: Endpoint to Security Gateway Tunnel 303 In this scenario, a protected endpoint (typically a portable roaming 304 computer) connects back to its corporate network through an IPsec- 305 protected tunnel. It might use this tunnel only to access 306 information on the corporate network, or it might tunnel all of its 307 traffic back through the corporate network in order to take advantage 308 of protection provided by a corporate firewall against Internet-based 309 attacks. In either case, the protected endpoint will want an IP 310 address associated with the security gateway so that packets returned 311 to it will go to the security gateway and be tunneled back. This IP 312 address may be static or may be dynamically allocated by the security 313 gateway. {{ Clarif-6.1 }} In support of the latter case, IKEv2 314 includes a mechanism (namely, configuration payloads) for the 315 initiator to request an IP address owned by the security gateway for 316 use for the duration of its SA. 318 In this scenario, packets will use tunnel mode. On each packet from 319 the protected endpoint, the outer IP header will contain the source 320 IP address associated with its current location (i.e., the address 321 that will get traffic routed to the endpoint directly), while the 322 inner IP header will contain the source IP address assigned by the 323 security gateway (i.e., the address that will get traffic routed to 324 the security gateway for forwarding to the endpoint). The outer 325 destination address will always be that of the security gateway, 326 while the inner destination address will be the ultimate destination 327 for the packet. 329 In this scenario, it is possible that the protected endpoint will be 330 behind a NAT. In that case, the IP address as seen by the security 331 gateway will not be the same as the IP address sent by the protected 332 endpoint, and packets will have to be UDP encapsulated in order to be 333 routed properly. 335 1.1.4. Other Scenarios 337 Other scenarios are possible, as are nested combinations of the 338 above. One notable example combines aspects of 1.1.1 and 1.1.3. A 339 subnet may make all external accesses through a remote security 340 gateway using an IPsec tunnel, where the addresses on the subnet are 341 routed to the security gateway by the rest of the Internet. An 342 example would be someone's home network being virtually on the 343 Internet with static IP addresses even though connectivity is 344 provided by an ISP that assigns a single dynamically assigned IP 345 address to the user's security gateway (where the static IP addresses 346 and an IPsec relay are provided by a third party located elsewhere). 348 1.2. The Initial Exchanges 350 Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH 351 exchanges (known in IKEv1 as Phase 1). These initial exchanges 352 normally consist of four messages, though in some scenarios that 353 number can grow. All communications using IKE consist of request/ 354 response pairs. We'll describe the base exchange first, followed by 355 variations. The first pair of messages (IKE_SA_INIT) negotiate 356 cryptographic algorithms, exchange nonces, and do a Diffie-Hellman 357 exchange [DH]. 359 The second pair of messages (IKE_AUTH) authenticate the previous 360 messages, exchange identities and certificates, and establish the 361 first CHILD_SA. Parts of these messages are encrypted and integrity 362 protected with keys established through the IKE_SA_INIT exchange, so 363 the identities are hidden from eavesdroppers and all fields in all 364 the messages are authenticated. 366 In the following descriptions, the payloads contained in the message 367 are indicated by names as listed below. 369 Notation Payload 370 ----------------------------------------- 371 AUTH Authentication 372 CERT Certificate 373 CERTREQ Certificate Request 374 CP Configuration 375 D Delete 376 E Encrypted 377 EAP Extensible Authentication 378 HDR IKE Header 379 IDi Identification - Initiator 380 IDr Identification - Responder 381 KE Key Exchange 382 Ni, Nr Nonce 383 N Notify 384 SA Security Association 385 TSi Traffic Selector - Initiator 386 TSr Traffic Selector - Responder 387 V Vendor ID 389 The details of the contents of each payload are described in section 390 3. Payloads that may optionally appear will be shown in brackets, 391 such as [CERTREQ], indicate that optionally a certificate request 392 payload can be included. 394 {{ Clarif-7.10 }} Many payloads contain fields marked as "RESERVED" 395 Some payloads in IKEv2 (and historically in IKEv1) are not aligned to 396 4-byte boundaries. 398 The initial exchanges are as follows: 400 Initiator Responder 401 ------------------------------------------------------------------- 402 HDR, SAi1, KEi, Ni --> 404 HDR contains the Security Parameter Indexes (SPIs), version numbers, 405 and flags of various sorts. The SAi1 payload states the 406 cryptographic algorithms the initiator supports for the IKE_SA. The 407 KE payload sends the initiator's Diffie-Hellman value. Ni is the 408 initiator's nonce. 410 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 412 The responder chooses a cryptographic suite from the initiator's 413 offered choices and expresses that choice in the SAr1 payload, 414 completes the Diffie-Hellman exchange with the KEr payload, and sends 415 its nonce in the Nr payload. 417 At this point in the negotiation, each party can generate SKEYSEED, 418 from which all keys are derived for that IKE_SA. All but the headers 419 of all the messages that follow are encrypted and integrity 420 protected. The keys used for the encryption and integrity protection 421 are derived from SKEYSEED and are known as SK_e (encryption) and SK_a 422 (authentication, a.k.a. integrity protection). A separate SK_e and 423 SK_a is computed for each direction. In addition to the keys SK_e 424 and SK_a derived from the DH value for protection of the IKE_SA, 425 another quantity SK_d is derived and used for derivation of further 426 keying material for CHILD_SAs. The notation SK { ... } indicates 427 that these payloads are encrypted and integrity protected using that 428 direction's SK_e and SK_a. 430 HDR, SK {IDi, [CERT,] [CERTREQ,] 431 [IDr,] AUTH, SAi2, 432 TSi, TSr} --> 434 The initiator asserts its identity with the IDi payload, proves 435 knowledge of the secret corresponding to IDi and integrity protects 436 the contents of the first message using the AUTH payload (see 437 Section 2.15). It might also send its certificate(s) in CERT 438 payload(s) and a list of its trust anchors in CERTREQ payload(s). If 439 any CERT payloads are included, the first certificate provided MUST 440 contain the public key used to verify the AUTH field. The optional 441 payload IDr enables the initiator to specify which of the responder's 442 identities it wants to talk to. This is useful when the machine on 443 which the responder is running is hosting multiple identities at the 444 same IP address. The initiator begins negotiation of a CHILD_SA 445 using the SAi2 payload. The final fields (starting with SAi2) are 446 described in the description of the CREATE_CHILD_SA exchange. 448 <-- HDR, SK {IDr, [CERT,] AUTH, 449 SAr2, TSi, TSr} 451 The responder asserts its identity with the IDr payload, optionally 452 sends one or more certificates (again with the certificate containing 453 the public key used to verify AUTH listed first), authenticates its 454 identity and protects the integrity of the second message with the 455 AUTH payload, and completes negotiation of a CHILD_SA with the 456 additional fields described below in the CREATE_CHILD_SA exchange. 458 The recipients of messages 3 and 4 MUST verify that all signatures 459 and MACs are computed correctly and that the names in the ID payloads 460 correspond to the keys used to generate the AUTH payload. 462 {{ Clarif-4.2}} If creating the CHILD_SA during the IKE_AUTH exchange 463 fails for some reason, the IKE_SA is still created as usual. The 464 list of responses in the IKE_AUTH exchange that do not prevent an 465 IKE_SA from being set up include at least the following: 466 NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, 467 INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED. 469 {{ Clarif-4.3 }} Note that IKE_AUTH messages do not contain KEi/KEr 470 or Ni/Nr payloads. Thus, the SA payload in IKE_AUTH exchange cannot 471 contain Transform Type 4 (Diffie-Hellman Group) with any other value 472 than NONE. Implementations MUST leave the transform out entirely in 473 this case. 475 1.3. The CREATE_CHILD_SA Exchange 477 {{ This is a heavy rewrite of most of this section. The major 478 organization changes are described in Clarif-4.1 and Clarif-5.1. }} 480 The CREATE_CHILD_SA exchange is used to create new CHILD_SAs and to 481 rekey both IKE_SAs and CHILD_SAs. This exchange consists of a single 482 request/response pair, and some of its function was referred to as a 483 phase 2 exchange in IKEv1. It MAY be initiated by either end of the 484 IKE_SA after the initial exchanges are completed. 486 All messages following the initial exchange are cryptographically 487 protected using the cryptographic algorithms and keys negotiated in 488 the first two messages of the IKE exchange. These subsequent 489 messages use the syntax of the Encrypted Payload described in 490 Section 3.14. All subsequent messages included an Encrypted Payload, 491 even if they are referred to in the text as "empty". For both 492 messages in the CREATE_CHILD_SA, the message following the header is 493 encrypted and the message including the header is integrity protected 494 using the cryptographic algorithms negotiated for the IKE_SA. 496 The CREATE_CHILD_SA is used for rekeying IKE_SAs and CHILD_SAs. This 497 section describes the first part of rekeying, the creation of new 498 SAs; Section 2.8 covers the mechanics of rekeying, including moving 499 traffic from old to new SAs and the deletion of the old SAs. The two 500 sections must be read together to understand the entire process of 501 rekeying. 503 Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this 504 section the term initiator refers to the endpoint initiating this 505 exchange. An implementation MAY refuse all CREATE_CHILD_SA requests 506 within an IKE_SA. 508 The CREATE_CHILD_SA request MAY optionally contain a KE payload for 509 an additional Diffie-Hellman exchange to enable stronger guarantees 510 of forward secrecy for the CHILD_SA. The keying material for the 511 CHILD_SA is a function of SK_d established during the establishment 512 of the IKE_SA, the nonces exchanged during the CREATE_CHILD_SA 513 exchange, and the Diffie-Hellman value (if KE payloads are included 514 in the CREATE_CHILD_SA exchange). 516 If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of 517 the SA offers MUST include the Diffie-Hellman group of the KEi. The 518 Diffie-Hellman group of the KEi MUST be an element of the group the 519 initiator expects the responder to accept (additional Diffie-Hellman 520 groups can be proposed). If the responder rejects the Diffie-Hellman 521 group of the KEi payload, the responder MUST reject the request and 522 indicate its preferred Diffie-Hellman group in the INVALID_KE_PAYLOAD 523 Notification payload. In the case of such a rejection, the 524 CREATE_CHILD_SA exchange fails, and the initiator will probably retry 525 the exchange with a Diffie-Hellman proposal and KEi in the group that 526 the responder gave in the INVALID_KE_PAYLOAD. 528 1.3.1. Creating New CHILD_SAs with the CREATE_CHILD_SA Exchange 530 A CHILD_SA may be created by sending a CREATE_CHILD_SA request. The 531 CREATE_CHILD_SA request for creating a new CHILD_SA is: 533 Initiator Responder 534 ------------------------------------------------------------------- 535 HDR, SK {SA, Ni, [KEi], 536 TSi, TSr} --> 538 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni 539 payload, optionally a Diffie-Hellman value in the KEi payload, and 540 the proposed traffic selectors for the proposed CHILD_SA in the TSi 541 and TSr payloads. 543 The CREATE_CHILD_SA response for creating a new CHILD_SA is: 545 <-- HDR, SK {SA, Nr, [KEr], 546 TSi, TSr} 548 The responder replies (using the same Message ID to respond) with the 549 accepted offer in an SA payload, and a Diffie-Hellman value in the 550 KEr payload if KEi was included in the request and the selected 551 cryptographic suite includes that group. 553 The traffic selectors for traffic to be sent on that SA are specified 554 in the TS payloads in the response, which may be a subset of what the 555 initiator of the CHILD_SA proposed. 557 1.3.2. Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange 559 The CREATE_CHILD_SA request for rekeying an IKE_SA is: 561 Initiator Responder 562 ------------------------------------------------------------------- 563 HDR, SK {SA, Ni, KEi} --> 565 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni 566 payload, and a Diffie-Hellman value in the KEi payload. New 567 initiator and responder SPIs are supplied in the SPI fields. 569 The CREATE_CHILD_SA response for rekeying an IKE_SA is: 571 <-- HDR, SK {SA, Nr, KEr} 573 The responder replies (using the same Message ID to respond) with the 574 accepted offer in an SA payload, and a Diffie-Hellman value in the 575 KEr payload if the selected cryptographic suite includes that group. 577 The new IKE_SA has its message counters set to 0, regardless of what 578 they were in the earlier IKE_SA. The window size starts at 1 for any 579 new IKE_SA. 581 KEi and KEr are required for rekeying an IKE_SA. 583 1.3.3. Rekeying CHILD_SAs with the CREATE_CHILD_SA Exchange 585 The CREATE_CHILD_SA request for rekeying a CHILD_SA is: 587 Initiator Responder 588 ------------------------------------------------------------------- 589 HDR, SK {N, SA, Ni, [KEi], 590 TSi, TSr} --> 592 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni 593 payload, optionally a Diffie-Hellman value in the KEi payload, and 594 the proposed traffic selectors for the proposed CHILD_SA in the TSi 595 and TSr payloads. When rekeying an existing CHILD_SA, the leading N 596 payload of type REKEY_SA MUST be included and MUST give the SPI (as 597 they would be expected in the headers of inbound packets) of the SAs 598 being rekeyed. 600 The CREATE_CHILD_SA response for rekeying a CHILD_SA is: 602 <-- HDR, SK {SA, Nr, [KEr], 603 Si, TSr} 605 The responder replies (using the same Message ID to respond) with the 606 accepted offer in an SA payload, and a Diffie-Hellman value in the 607 KEr payload if KEi was included in the request and the selected 608 cryptographic suite includes that group. 610 The traffic selectors for traffic to be sent on that SA are specified 611 in the TS payloads in the response, which may be a subset of what the 612 initiator of the CHILD_SA proposed. 614 1.4. The INFORMATIONAL Exchange 616 At various points during the operation of an IKE_SA, peers may desire 617 to convey control messages to each other regarding errors or 618 notifications of certain events. To accomplish this, IKE defines an 619 INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur 620 after the initial exchanges and are cryptographically protected with 621 the negotiated keys. 623 Control messages that pertain to an IKE_SA MUST be sent under that 624 IKE_SA. Control messages that pertain to CHILD_SAs MUST be sent 625 under the protection of the IKE_SA which generated them (or its 626 successor if the IKE_SA was replaced for the purpose of rekeying). 628 Messages in an INFORMATIONAL exchange contain zero or more 629 Notification, Delete, and Configuration payloads. The Recipient of 630 an INFORMATIONAL exchange request MUST send some response (else the 631 Sender will assume the message was lost in the network and will 632 retransmit it). That response MAY be a message with no payloads. 633 The request message in an INFORMATIONAL exchange MAY also contain no 634 payloads. This is the expected way an endpoint can ask the other 635 endpoint to verify that it is alive. 637 {{ Clarif-5.6 }} ESP and AH SAs always exist in pairs, with one SA in 638 each direction. When an SA is closed, both members of the pair MUST 639 be closed (that is, deleted). When SAs are nested, as when data (and 640 IP headers if in tunnel mode) are encapsulated first with IPComp, 641 then with ESP, and finally with AH between the same pair of 642 endpoints, all of the SAs MUST be deleted together. Each endpoint 643 MUST close its incoming SAs and allow the other endpoint to close the 644 other SA in each pair. To delete an SA, an INFORMATIONAL exchange 645 with one or more delete payloads is sent listing the SPIs (as they 646 would be expected in the headers of inbound packets) of the SAs to be 647 deleted. The recipient MUST close the designated SAs. {{ Clarif-5.7 648 }} Note that you never send delete payloads for the two sides of an 649 SA in a single message. If you have many SAs to delete at the same 650 time (such as for nested SAs), you include delete payloads for in 651 inbound half of each SA in your Informational exchange. 653 Normally, the reply in the INFORMATIONAL exchange will contain delete 654 payloads for the paired SAs going in the other direction. There is 655 one exception. If by chance both ends of a set of SAs independently 656 decide to close them, each may send a delete payload and the two 657 requests may cross in the network. If a node receives a delete 658 request for SAs for which it has already issued a delete request, it 659 MUST delete the outgoing SAs while processing the request and the 660 incoming SAs while processing the response. In that case, the 661 responses MUST NOT include delete payloads for the deleted SAs, since 662 that would result in duplicate deletion and could in theory delete 663 the wrong SA. 665 {{ Demoted the SHOULD }} Half-closed connections are anomalous and, 666 and a node with auditing capability will probably audit their 667 existence if they persist. Note that this specification nowhere 668 specifies time periods, so it is up to individual endpoints to decide 669 how long to wait. A node MAY refuse to accept incoming data on half- 670 closed connections but MUST NOT unilaterally close them and reuse the 671 SPIs. If connection state becomes sufficiently messed up, a node MAY 672 close the IKE_SA; doing so will implicitly close all SAs negotiated 673 under it. It can then rebuild the SAs it needs on a clean base under 674 a new IKE_SA. {{ Clarif-5.8 }} The response to a request that deletes 675 the IKE_SA is an empty Informational response. 677 The INFORMATIONAL exchange is defined as: 679 Initiator Responder 680 ------------------------------------------------------------------- 681 HDR, SK {[N,] [D,] 682 [CP,] ...} --> 683 <-- HDR, SK {[N,] [D,] 684 [CP], ...} 686 The processing of an INFORMATIONAL exchange is determined by its 687 component payloads. 689 1.5. Informational Messages outside of an IKE_SA 691 If an encrypted IKE packet arrives on port 500 or 4500 with an 692 unrecognized SPI, it could be because the receiving node has recently 693 crashed and lost state or because of some other system malfunction or 694 attack. If the receiving node has an active IKE_SA to the IP address 695 from whence the packet came, it MAY send a notification of the 696 wayward packet over that IKE_SA in an INFORMATIONAL exchange. If it 697 does not have such an IKE_SA, it MAY send an Informational message 698 without cryptographic protection to the source IP address. Such a 699 message is not part of an informational exchange, and the receiving 700 node MUST NOT respond to it. Doing so could cause a message loop. 702 {{ Clarif-7.7 }} There are two cases when such a one-way notification 703 is sent: INVALID_IKE_SPI and INVALID_SPI. These notifications are 704 sent outside of an IKE_SA. Note that such notifications are 705 explicitly not Informational exchanges; these are one-way messages 706 that must not be responded to. In case of INVALID_IKE_SPI, the 707 message sent is a response message, and thus it is sent to the IP 708 address and port from whence it came with the same IKE SPIs and the 709 Message ID copied. In case of INVALID_SPI, however, there are no IKE 710 SPI values that would be meaningful to the recipient of such a 711 notification. Using zero values or random values are both 712 acceptable. 714 1.6. Requirements Terminology 716 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 717 "MAY" that appear in this document are to be interpreted as described 718 in [MUSTSHOULD]. 720 The term "Expert Review" is to be interpreted as defined in 721 [IANACONS]. 723 1.7. Introduction to IKEv2.1 725 IKEv2.1 is very similar to IKEv2. Most of the differences between 726 this document at [IKEV2] are clarifications, mostly based on 727 [Clarif]. The changes listed in that document were discussed in the 728 IPsec Working Group and, after the Working Group was disbanded, on 729 the IPsec mailing list. That document contains detailed explanations 730 of areas that were unclear in IKEv2, and is thus useful to 731 implementers of IKEv2 and IKEv2.1. 733 In the body of this document, notes that are enclosed in double curly 734 braces {{ such as this }} point out changes from IKEv2. Changes that 735 come from [Clarif] are marked with the section from that document, 736 such as "{{ Clarif-2.10 }}". 738 This document also make the figures and references a bit more regular 739 than in IKEv2. 741 IKEv2 developers have noted that the SHOULD-level requirements are 742 often unclear in that they don't say when it is OK to not obey the 743 requirements. They also have noted that there are MUST-level 744 requirements that are not related to interoperability. This document 745 has more explanation of some of these SHOULD-level requirements, and 746 some SHOULD-level and MUST-level requirements have been changed to 747 better match the definitions in [MUSTSHOULD]. All non-capitalized 748 uses of the words SHOULD and MUST now mean their normal English 749 sense, not the interoperability sense of [MUSTSHOULD]. 751 IKEv2 (and IKEv1) developers have noted that there is a great deal of 752 material in the tables of codes in Section 3.10. This leads to 753 implementers not having all the needed information in the main body 754 of the docment. A later version of this document may move much of 755 the material from those tables into the associated parts of the main 756 body of the document. 758 A later version of this document will probably have all the {{ }} 759 comments removed from the body of the document and instead appear in 760 an appendix. 762 2. IKE Protocol Details and Variations 764 IKE normally listens and sends on UDP port 500, though IKE messages 765 may also be received on UDP port 4500 with a slightly different 766 format (see Section 2.23). Since UDP is a datagram (unreliable) 767 protocol, IKE includes in its definition recovery from transmission 768 errors, including packet loss, packet replay, and packet forgery. 769 IKE is designed to function so long as (1) at least one of a series 770 of retransmitted packets reaches its destination before timing out; 771 and (2) the channel is not so full of forged and replayed packets so 772 as to exhaust the network or CPU capacities of either endpoint. Even 773 in the absence of those minimum performance requirements, IKE is 774 designed to fail cleanly (as though the network were broken). 776 Although IKEv2 messages are intended to be short, they contain 777 structures with no hard upper bound on size (in particular, X.509 778 certificates), and IKEv2 itself does not have a mechanism for 779 fragmenting large messages. IP defines a mechanism for fragmentation 780 of oversize UDP messages, but implementations vary in the maximum 781 message size supported. Furthermore, use of IP fragmentation opens 782 an implementation to denial of service attacks [DOSUDPPROT]. 783 Finally, some NAT and/or firewall implementations may block IP 784 fragments. 786 All IKEv2 implementations MUST be able to send, receive, and process 787 IKE messages that are up to 1280 bytes long, and they SHOULD be able 788 to send, receive, and process messages that are up to 3000 bytes 789 long. {{ Demoted the SHOULD }} IKEv2 implementations need to be aware 790 of the maximum UDP message size supported and MAY shorten messages by 791 leaving out some certificates or cryptographic suite proposals if 792 that will keep messages below the maximum. Use of the "Hash and URL" 793 formats rather than including certificates in exchanges where 794 possible can avoid most problems. {{ Demoted the SHOULD }} 795 Implementations and configuration need to keep in mind, however, that 796 if the URL lookups are possible only after the IPsec SA is 797 established, recursion issues could prevent this technique from 798 working. 800 2.1. Use of Retransmission Timers 802 All messages in IKE exist in pairs: a request and a response. The 803 setup of an IKE_SA normally consists of two request/response pairs. 804 Once the IKE_SA is set up, either end of the security association may 805 initiate requests at any time, and there can be many requests and 806 responses "in flight" at any given moment. But each message is 807 labeled as either a request or a response, and for each request/ 808 response pair one end of the security association is the initiator 809 and the other is the responder. 811 For every pair of IKE messages, the initiator is responsible for 812 retransmission in the event of a timeout. The responder MUST never 813 retransmit a response unless it receives a retransmission of the 814 request. In that event, the responder MUST ignore the retransmitted 815 request except insofar as it triggers a retransmission of the 816 response. The initiator MUST remember each request until it receives 817 the corresponding response. The responder MUST remember each 818 response until it receives a request whose sequence number is larger 819 than the sequence number in the response plus its window size (see 820 Section 2.3). 822 IKE is a reliable protocol, in the sense that the initiator MUST 823 retransmit a request until either it receives a corresponding reply 824 OR it deems the IKE security association to have failed and it 825 discards all state associated with the IKE_SA and any CHILD_SAs 826 negotiated using that IKE_SA. 828 {{ Clarif-7.5 }} All packets sent on port 4500 MUST begin with the 829 prefix of four zeros; otherwise, the receiver won't know how to 830 handle them. 832 2.2. Use of Sequence Numbers for Message ID 834 Every IKE message contains a Message ID as part of its fixed header. 835 This Message ID is used to match up requests and responses, and to 836 identify retransmissions of messages. 838 The Message ID is a 32-bit quantity, which is zero for the first IKE 839 request in each direction. {{ Clarif-3.11 }} When the IKE_AUTH 840 exchange does not use EAP, the IKE_SA initial setup messages will 841 always be numbered 0 and 1. When EAP is used, each pair of messages 842 have their message numbers incremented; the first pair of AUTH 843 messages will have an ID of 1, the second will be 2, and so on. 845 Each endpoint in the IKE Security Association maintains two "current" 846 Message IDs: the next one to be used for a request it initiates and 847 the next one it expects to see in a request from the other end. 849 These counters increment as requests are generated and received. 850 Responses always contain the same message ID as the corresponding 851 request. That means that after the initial exchange, each integer n 852 may appear as the message ID in four distinct messages: the nth 853 request from the original IKE initiator, the corresponding response, 854 the nth request from the original IKE responder, and the 855 corresponding response. If the two ends make very different numbers 856 of requests, the Message IDs in the two directions can be very 857 different. There is no ambiguity in the messages, however, because 858 the (I)nitiator and (R)esponse bits in the message header specify 859 which of the four messages a particular one is. 861 {{ Clarif-2.2 }} The Message ID for IKE_SA_INIT messages is always 862 zero, including for retries of the message due to responses such as 863 COOKIE and INVALID_KE_PAYLOAD. 865 Note that Message IDs are cryptographically protected and provide 866 protection against message replays. In the unlikely event that 867 Message IDs grow too large to fit in 32 bits, the IKE_SA MUST be 868 closed. Rekeying an IKE_SA resets the sequence numbers. 870 {{ Clarif-2.3 }} When a responder receives an IKE_SA_INIT request, it 871 has to determine whether the packet is a retransmission belonging to 872 an existing "half-open" IKE_SA (in which case the responder 873 retransmits the same response), or a new request (in which case the 874 responder creates a new IKE_SA and sends a fresh response). It is 875 not sufficient to use the initiator's SPI and/or IP address to 876 differentiate between the two cases because two different peers 877 behind a single NAT could choose the same initiator SPI. Instead, a 878 robust responder will do the IKE_SA lookup using the whole packet, 879 its hash, or the Ni payload. 881 2.3. Window Size for Overlapping Requests 883 In order to maximize IKE throughput, an IKE endpoint MAY issue 884 multiple requests before getting a response to any of them if the 885 other endpoint has indicated its ability to handle such requests. 886 For simplicity, an IKE implementation MAY choose to process requests 887 strictly in order and/or wait for a response to one request before 888 issuing another. Certain rules must be followed to ensure 889 interoperability between implementations using different strategies. 891 After an IKE_SA is set up, either end can initiate one or more 892 requests. These requests may pass one another over the network. An 893 IKE endpoint MUST be prepared to accept and process a request while 894 it has a request outstanding in order to avoid a deadlock in this 895 situation. {{ Changed the SHOULD to MUST }} An IKE endpoint MUST be 896 prepared to accept and process multiple requests while it has a 897 request outstanding. 899 An IKE endpoint MUST wait for a response to each of its messages 900 before sending a subsequent message unless it has received a 901 SET_WINDOW_SIZE Notify message from its peer informing it that the 902 peer is prepared to maintain state for multiple outstanding messages 903 in order to allow greater throughput. 905 An IKE endpoint MUST NOT exceed the peer's stated window size for 906 transmitted IKE requests. In other words, if the responder stated 907 its window size is N, then when the initiator needs to make a request 908 X, it MUST wait until it has received responses to all requests up 909 through request X-N. An IKE endpoint MUST keep a copy of (or be able 910 to regenerate exactly) each request it has sent until it receives the 911 corresponding response. An IKE endpoint MUST keep a copy of (or be 912 able to regenerate exactly) the number of previous responses equal to 913 its declared window size in case its response was lost and the 914 initiator requests its retransmission by retransmitting the request. 916 An IKE endpoint supporting a window size greater than one should be 917 capable of processing incoming requests out of order to maximize 918 performance in the event of network failures or packet reordering. 920 {{ Clarif-7.3 }} The window size is assumed to be a (possibly 921 configurable) property of a particular implementation, and is not 922 related to congestion control (unlike the window size in TCP, for 923 example). In particular, it is not defined what the responder should 924 do when it receives a SET_WINDOW_SIZE notification containing a 925 smaller value than is currently in effect. Thus, there is currently 926 no way to reduce the window size of an existing IKE_SA; you can only 927 increase it. When rekeying an IKE_SA, the new IKE_SA starts with 928 window size 1 until it is explicitly increased by sending a new 929 SET_WINDOW_SIZE notification. 931 2.4. State Synchronization and Connection Timeouts 933 An IKE endpoint is allowed to forget all of its state associated with 934 an IKE_SA and the collection of corresponding CHILD_SAs at any time. 935 This is the anticipated behavior in the event of an endpoint crash 936 and restart. It is important when an endpoint either fails or 937 reinitializes its state that the other endpoint detect those 938 conditions and not continue to waste network bandwidth by sending 939 packets over discarded SAs and having them fall into a black hole. 941 Since IKE is designed to operate in spite of Denial of Service (DoS) 942 attacks from the network, an endpoint MUST NOT conclude that the 943 other endpoint has failed based on any routing information (e.g., 944 ICMP messages) or IKE messages that arrive without cryptographic 945 protection (e.g., Notify messages complaining about unknown SPIs). 946 An endpoint MUST conclude that the other endpoint has failed only 947 when repeated attempts to contact it have gone unanswered for a 948 timeout period or when a cryptographically protected INITIAL_CONTACT 949 notification is received on a different IKE_SA to the same 950 authenticated identity. {{ Demoted the SHOULD }} An endpoint should 951 suspect that the other endpoint has failed based on routing 952 information and initiate a request to see whether the other endpoint 953 is alive. To check whether the other side is alive, IKE specifies an 954 empty INFORMATIONAL message that (like all IKE requests) requires an 955 acknowledgement (note that within the context of an IKE_SA, an 956 "empty" message consists of an IKE header followed by an Encrypted 957 payload that contains no payloads). If a cryptographically protected 958 message has been received from the other side recently, unprotected 959 notifications MAY be ignored. Implementations MUST limit the rate at 960 which they take actions based on unprotected messages. 962 Numbers of retries and lengths of timeouts are not covered in this 963 specification because they do not affect interoperability. It is 964 suggested that messages be retransmitted at least a dozen times over 965 a period of at least several minutes before giving up on an SA, but 966 different environments may require different rules. To be a good 967 network citizen, retranmission times MUST increase exponentially to 968 avoid flooding the network and making an existing congestion 969 situation worse. If there has only been outgoing traffic on all of 970 the SAs associated with an IKE_SA, it is essential to confirm 971 liveness of the other endpoint to avoid black holes. If no 972 cryptographically protected messages have been received on an IKE_SA 973 or any of its CHILD_SAs recently, the system needs to perform a 974 liveness check in order to prevent sending messages to a dead peer. 975 Receipt of a fresh cryptographically protected message on an IKE_SA 976 or any of its CHILD_SAs ensures liveness of the IKE_SA and all of its 977 CHILD_SAs. Note that this places requirements on the failure modes 978 of an IKE endpoint. An implementation MUST NOT continue sending on 979 any SA if some failure prevents it from receiving on all of the 980 associated SAs. If CHILD_SAs can fail independently from one another 981 without the associated IKE_SA being able to send a delete message, 982 then they MUST be negotiated by separate IKE_SAs. 984 There is a Denial of Service attack on the initiator of an IKE_SA 985 that can be avoided if the initiator takes the proper care. Since 986 the first two messages of an SA setup are not cryptographically 987 protected, an attacker could respond to the initiator's message 988 before the genuine responder and poison the connection setup attempt. 989 To prevent this, the initiator MAY be willing to accept multiple 990 responses to its first message, treat each as potentially legitimate, 991 respond to it, and then discard all the invalid half-open connections 992 when it receives a valid cryptographically protected response to any 993 one of its requests. Once a cryptographically valid response is 994 received, all subsequent responses should be ignored whether or not 995 they are cryptographically valid. 997 Note that with these rules, there is no reason to negotiate and agree 998 upon an SA lifetime. If IKE presumes the partner is dead, based on 999 repeated lack of acknowledgement to an IKE message, then the IKE SA 1000 and all CHILD_SAs set up through that IKE_SA are deleted. 1002 An IKE endpoint may at any time delete inactive CHILD_SAs to recover 1003 resources used to hold their state. If an IKE endpoint chooses to 1004 delete CHILD_SAs, it MUST send Delete payloads to the other end 1005 notifying it of the deletion. It MAY similarly time out the IKE_SA. 1006 {{ Clarified the SHOULD }} Closing the IKE_SA implicitly closes all 1007 associated CHILD_SAs. In this case, an IKE endpoint SHOULD send a 1008 Delete payload indicating that it has closed the IKE_SA unless the 1009 other endpoint is no longer responding. 1011 2.5. Version Numbers and Forward Compatibility 1013 {{ The version number is changed in the following paragraph, and the 1014 discussion of handling of multiple versions is also changed 1015 throughout the section. }} 1017 This document describes version 2.1 of IKE, meaning the major version 1018 number is 2 and the minor version number is 1. It is likely that 1019 some implementations will want to support version 1.0 and version 2.0 1020 and version 2.1, and in the future, other versions. 1022 The major version number should be incremented only if the packet 1023 formats or required actions have changed so dramatically that an 1024 older version node would not be able to interoperate with a newer 1025 version node if it simply ignored the fields it did not understand 1026 and took the actions specified in the older specification. The minor 1027 version number indicates new capabilities, and MUST be ignored by a 1028 node with a smaller minor version number, but used for informational 1029 purposes by the node with the larger minor version number. For 1030 example, it might indicate the ability to process a newly defined 1031 notification message. The node with the larger minor version number 1032 would simply note that its correspondent would not be able to 1033 understand that message and therefore would not send it. 1035 In the discussion of clarifications to IKEv2, it became clear that 1036 there was a need for additional "MUST" and "SHOULD" requirements. 1037 Some of those changes are reflected in IKEv2.1. Thus, the node with 1038 the higher version number may also need to note that its 1039 correspondent may not be following the same required actions, which 1040 could affect interoperability. 1042 {{ Promoted the SHOULD }} If an endpoint receives a message with a 1043 higher major version number, it MUST drop the message and MUST send 1044 an unauthenticated notification message containing the highest 1045 version number it supports. If an endpoint supports major version n, 1046 and major version m, it MUST support all versions between n and m. 1047 If it receives a message with a major version that it supports, it 1048 MUST respond with that version number. In order to prevent two nodes 1049 from being tricked into corresponding with a lower major version 1050 number than the maximum that they both support, IKE has a flag that 1051 indicates that the node is capable of speaking a higher major version 1052 number. 1054 Thus, the major version number in the IKE header indicates the 1055 version number of the message, not the highest version number that 1056 the transmitter supports. If the initiator is capable of speaking 1057 versions n, n+1, and n+2, and the responder is capable of speaking 1058 versions n and n+1, then they will negotiate speaking n+1, where the 1059 initiator will set the flag indicating its ability to speak a higher 1060 version. If they mistakenly (perhaps through an active attacker 1061 sending error messages) negotiate to version n, then both will notice 1062 that the other side can support a higher version number, and they 1063 MUST break the connection and reconnect using version n+1. 1065 Note that IKEv1 does not follow these rules, because there is no way 1066 in v1 of noting that you are capable of speaking a higher version 1067 number. So an active attacker can trick two v2-capable nodes into 1068 speaking v1. {{ Demoted the SHOULD }} When a v2-capable node 1069 negotiates down to v1, it should note that fact in its logs. 1071 Also for forward compatibility, all fields marked RESERVED MUST be 1072 set to zero by an implementation running version 2.0 or later, and 1073 their content MUST be ignored by an implementation running version 1074 2.0 or later ("Be conservative in what you send and liberal in what 1075 you receive"). In this way, future versions of the protocol can use 1076 those fields in a way that is guaranteed to be ignored by 1077 implementations that do not understand them. Similarly, payload 1078 types that are not defined are reserved for future use; 1079 implementations of a version where they are undefined MUST skip over 1080 those payloads and ignore their contents. 1082 IKEv2 adds a "critical" flag to each payload header for further 1083 flexibility for forward compatibility. If the critical flag is set 1084 and the payload type is unrecognized, the message MUST be rejected 1085 and the response to the IKE request containing that payload MUST 1086 include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an 1087 unsupported critical payload was included. If the critical flag is 1088 not set and the payload type is unsupported, that payload MUST be 1089 ignored. 1091 {{ Demoted the SHOULD }}Although new payload types may be added in 1092 the future and may appear interleaved with the fields defined in this 1093 specification, implementations MUST send the payloads defined in this 1094 specification in the order shown in the figures in Section 2 and 1095 implementations MAY reject as invalid a message with those payloads 1096 in any other order. 1098 2.6. Cookies 1100 The term "cookies" originates with Karn and Simpson [PHOTURIS] in 1101 Photuris, an early proposal for key management with IPsec, and it has 1102 persisted. The Internet Security Association and Key Management 1103 Protocol (ISAKMP) [ISAKMP] fixed message header includes two eight- 1104 octet fields titled "cookies", and that syntax is used by both IKEv1 1105 and IKEv2 though in IKEv2 they are referred to as the IKE SPI and 1106 there is a new separate field in a Notify payload holding the cookie. 1107 The initial two eight-octet fields in the header are used as a 1108 connection identifier at the beginning of IKE packets. {{ Promoted 1109 the SHOULD }} Each endpoint chooses one of the two SPIs and MUST 1110 choose them so as to be unique identifiers of an IKE_SA. An SPI 1111 value of zero is special and indicates that the remote SPI value is 1112 not yet known by the sender. 1114 Unlike ESP and AH where only the recipient's SPI appears in the 1115 header of a message, in IKE the sender's SPI is also sent in every 1116 message. Since the SPI chosen by the original initiator of the 1117 IKE_SA is always sent first, an endpoint with multiple IKE_SAs open 1118 that wants to find the appropriate IKE_SA using the SPI it assigned 1119 must look at the I(nitiator) Flag bit in the header to determine 1120 whether it assigned the first or the second eight octets. 1122 In the first message of an initial IKE exchange, the initiator will 1123 not know the responder's SPI value and will therefore set that field 1124 to zero. 1126 An expected attack against IKE is state and CPU exhaustion, where the 1127 target is flooded with session initiation requests from forged IP 1128 addresses. This attack can be made less effective if an 1129 implementation of a responder uses minimal CPU and commits no state 1130 to an SA until it knows the initiator can receive packets at the 1131 address from which it claims to be sending them. To accomplish this, 1132 a responder SHOULD -- when it detects a large number of half-open 1133 IKE_SAs -- reject initial IKE messages unless they contain a Notify 1134 payload of type COOKIE. {{ Clarified the SHOULD }} If the responder 1135 wants to set up an SA, it SHOULD instead send an unprotected IKE 1136 message as a response and include COOKIE Notify payload with the 1137 cookie data to be returned. Initiators who receive such responses 1138 MUST retry the IKE_SA_INIT with a Notify payload of type COOKIE 1139 containing the responder supplied cookie data as the first payload 1140 and all other payloads unchanged. The initial exchange will then be 1141 as follows: 1143 Initiator Responder 1144 ------------------------------------------------------------------- 1145 HDR(A,0), SAi1, KEi, Ni --> 1146 <-- HDR(A,0), N(COOKIE) 1147 HDR(A,0), N(COOKIE), SAi1, 1148 KEi, Ni --> 1149 <-- HDR(A,B), SAr1, KEr, 1150 Nr, [CERTREQ] 1151 HDR(A,B), SK {IDi, [CERT,] 1152 [CERTREQ,] [IDr,] AUTH, 1153 SAi2, TSi, TSr} --> 1154 <-- HDR(A,B), SK {IDr, [CERT,] 1155 AUTH, SAr2, TSi, TSr} 1157 The first two messages do not affect any initiator or responder state 1158 except for communicating the cookie. In particular, the message 1159 sequence numbers in the first four messages will all be zero and the 1160 message sequence numbers in the last two messages will be one. 'A' 1161 is the SPI assigned by the initiator, while 'B' is the SPI assigned 1162 by the responder. 1164 {{ Clarif-2.1 }} Because the responder's SPI identifies security- 1165 related state held by the responder, and in this case no state is 1166 created, the responder sends a zero value for the responder's SPI. 1168 {{ Demoted the SHOULD }} An IKE implementation should implement its 1169 responder cookie generation in such a way as to not require any saved 1170 state to recognize its valid cookie when the second IKE_SA_INIT 1171 message arrives. The exact algorithms and syntax they use to 1172 generate cookies do not affect interoperability and hence are not 1173 specified here. The following is an example of how an endpoint could 1174 use cookies to implement limited DOS protection. 1176 A good way to do this is to set the responder cookie to be: 1178 Cookie = | Hash(Ni | IPi | SPIi | ) 1180 where is a randomly generated secret known only to the 1181 responder and periodically changed and | indicates concatenation. 1182 should be changed whenever is 1183 regenerated. The cookie can be recomputed when the IKE_SA_INIT 1184 arrives the second time and compared to the cookie in the received 1185 message. If it matches, the responder knows that the cookie was 1186 generated since the last change to and that IPi must be the 1187 same as the source address it saw the first time. Incorporating SPIi 1188 into the calculation ensures that if multiple IKE_SAs are being set 1189 up in parallel they will all get different cookies (assuming the 1190 initiator chooses unique SPIi's). Incorporating Ni into the hash 1191 ensures that an attacker who sees only message 2 can't successfully 1192 forge a message 3. 1194 If a new value for is chosen while there are connections in 1195 the process of being initialized, an IKE_SA_INIT might be returned 1196 with other than the current . The responder in 1197 that case MAY reject the message by sending another response with a 1198 new cookie or it MAY keep the old value of around for a 1199 short time and accept cookies computed from either one. {{ Demoted 1200 the SHOULD NOT }} The responder should not accept cookies 1201 indefinitely after is changed, since that would defeat part 1202 of the denial of service protection. {{ Demoted the SHOULD }} The 1203 responder should change the value of frequently, especially 1204 if under attack. 1206 {{ Clarif-2.1 }} In addition to cookies, there are several cases 1207 where the IKE_SA_INIT exchange does not result in the creation of an 1208 IKE_SA (such as INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). In such a 1209 case, sending a zero value for the Responder's SPI is correct. If 1210 the responder sends a non-zero responder SPI, the initiator should 1211 not reject the response for only that reason. 1213 {{ Clarif-2.5 }} When one party receives an IKE_SA_INIT request 1214 containing a cookie whose contents do not match the value expected, 1215 that party MUST ignore the cookie and process the message as if no 1216 cookie had been included; usually this means sending a response 1217 containing a new cookie. 1219 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD 1221 {{ This section added by Clarif-2.4 }} 1223 There are two common reasons why the initiator may have to retry the 1224 IKE_SA_INIT exchange: the responder requests a cookie or wants a 1225 different Diffie-Hellman group than was included in the KEi payload. 1226 If the initiator receives a cookie from the responder, the initiator 1227 needs to decide whether or not tp include the cookie in only the next 1228 retry of the IKE_SA_INIT request, or in all subsequent retries as 1229 well. 1231 If the initiator includes the cookie only in the next retry, one 1232 additional roundtrip may be needed in some cases. An additional 1233 roundtrip is needed also if the initiator includes the cookie in all 1234 retries, but the responder does not support this. For instance, if 1235 the responder includes the SAi1 and KEi payloads in cookie 1236 calculation, it will reject the request by sending a new cookie. 1238 If both peers support including the cookie in all retries, a slightly 1239 shorter exchange can happen. Implementations MUST support this 1240 shorter exchange, but MUST NOT assume other implementations also 1241 supports this shorter exchange. 1243 2.7. Cryptographic Algorithm Negotiation 1245 The payload type known as "SA" indicates a proposal for a set of 1246 choices of IPsec protocols (IKE, ESP, and/or AH) for the SA as well 1247 as cryptographic algorithms associated with each protocol. 1249 An SA payload consists of one or more proposals. Each proposal 1250 includes one or more protocols (usually one). Each protocol contains 1251 one or more transforms -- each specifying a cryptographic algorithm. 1252 Each transform contains zero or more attributes (attributes are 1253 needed only if the transform identifier does not completely specify 1254 the cryptographic algorithm). 1256 This hierarchical structure was designed to efficiently encode 1257 proposals for cryptographic suites when the number of supported 1258 suites is large because multiple values are acceptable for multiple 1259 transforms. The responder MUST choose a single suite, which MAY be 1260 any subset of the SA proposal following the rules below: 1262 Each proposal contains one or more protocols. If a proposal is 1263 accepted, the SA response MUST contain the same protocols in the same 1264 order as the proposal. The responder MUST accept a single proposal 1265 or reject them all and return an error. (Example: if a single 1266 proposal contains ESP and AH and that proposal is accepted, both ESP 1267 and AH MUST be accepted. If ESP and AH are included in separate 1268 proposals, the responder MUST accept only one of them). 1270 Each IPsec protocol proposal contains one or more transforms. Each 1271 transform contains a transform type. The accepted cryptographic 1272 suite MUST contain exactly one transform of each type included in the 1273 proposal. For example: if an ESP proposal includes transforms 1274 ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256, 1275 AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one 1276 of the ENCR_ transforms and one of the AUTH_ transforms. Thus, six 1277 combinations are acceptable. 1279 Since the initiator sends its Diffie-Hellman value in the 1280 IKE_SA_INIT, it must guess the Diffie-Hellman group that the 1281 responder will select from its list of supported groups. If the 1282 initiator guesses wrong, the responder will respond with a Notify 1283 payload of type INVALID_KE_PAYLOAD indicating the selected group. In 1284 this case, the initiator MUST retry the IKE_SA_INIT with the 1285 corrected Diffie-Hellman group. The initiator MUST again propose its 1286 full set of acceptable cryptographic suites because the rejection 1287 message was unauthenticated and otherwise an active attacker could 1288 trick the endpoints into negotiating a weaker suite than a stronger 1289 one that they both prefer. 1291 2.8. Rekeying 1293 {{ Demoted the SHOULD }} IKE, ESP, and AH security associations use 1294 secret keys that should be used only for a limited amount of time and 1295 to protect a limited amount of data. This limits the lifetime of the 1296 entire security association. When the lifetime of a security 1297 association expires, the security association MUST NOT be used. If 1298 there is demand, new security associations MAY be established. 1299 Reestablishment of security associations to take the place of ones 1300 that expire is referred to as "rekeying". 1302 To allow for minimal IPsec implementations, the ability to rekey SAs 1303 without restarting the entire IKE_SA is optional. An implementation 1304 MAY refuse all CREATE_CHILD_SA requests within an IKE_SA. If an SA 1305 has expired or is about to expire and rekeying attempts using the 1306 mechanisms described here fail, an implementation MUST close the 1307 IKE_SA and any associated CHILD_SAs and then MAY start new ones. {{ 1308 Demoted the SHOULD }} Implementations should support in-place 1309 rekeying of SAs, since doing so offers better performance and is 1310 likely to reduce the number of packets lost during the transition. 1312 To rekey a CHILD_SA within an existing IKE_SA, create a new, 1313 equivalent SA (see Section 2.17 below), and when the new one is 1314 established, delete the old one. To rekey an IKE_SA, establish a new 1315 equivalent IKE_SA (see Section 2.18 below) with the peer to whom the 1316 old IKE_SA is shared using a CREATE_CHILD_SA within the existing 1317 IKE_SA. An IKE_SA so created inherits all of the original IKE_SA's 1318 CHILD_SAs. Use the new IKE_SA for all control messages needed to 1319 maintain the CHILD_SAs created by the old IKE_SA, and delete the old 1320 IKE_SA. The Delete payload to delete itself MUST be the last request 1321 sent over an IKE_SA. 1323 {{ Demoted the SHOULD }} SAs should be rekeyed proactively, i.e., the 1324 new SA should be established before the old one expires and becomes 1325 unusable. Enough time should elapse between the time the new SA is 1326 established and the old one becomes unusable so that traffic can be 1327 switched over to the new SA. 1329 A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes 1330 were negotiated. In IKEv2, each end of the SA is responsible for 1331 enforcing its own lifetime policy on the SA and rekeying the SA when 1332 necessary. If the two ends have different lifetime policies, the end 1333 with the shorter lifetime will end up always being the one to request 1334 the rekeying. If an SA bundle has been inactive for a long time and 1335 if an endpoint would not initiate the SA in the absence of traffic, 1336 the endpoint MAY choose to close the SA instead of rekeying it when 1337 its lifetime expires. {{ Demoted the SHOULD }} It should do so if 1338 there has been no traffic since the last time the SA was rekeyed. 1340 Note that IKEv2 deliberately allows parallel SAs with the same 1341 traffic selectors between common endpoints. One of the purposes of 1342 this is to support traffic quality of service (QoS) differences among 1343 the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and section 4.1 of 1344 [DIFFTUNNEL]). Hence unlike IKEv1, the combination of the endpoints 1345 and the traffic selectors may not uniquely identify an SA between 1346 those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on 1347 the basis of duplicate traffic selectors SHOULD NOT be used. 1349 {{ Demoted the SHOULD }} The node that initiated the surviving 1350 rekeyed SA should delete the replaced SA after the new one is 1351 established. 1353 There are timing windows -- particularly in the presence of lost 1354 packets -- where endpoints may not agree on the state of an SA. The 1355 responder to a CREATE_CHILD_SA MUST be prepared to accept messages on 1356 an SA before sending its response to the creation request, so there 1357 is no ambiguity for the initiator. The initiator MAY begin sending 1358 on an SA as soon as it processes the response. The initiator, 1359 however, cannot receive on a newly created SA until it receives and 1360 processes the response to its CREATE_CHILD_SA request. How, then, is 1361 the responder to know when it is OK to send on the newly created SA? 1363 From a technical correctness and interoperability perspective, the 1364 responder MAY begin sending on an SA as soon as it sends its response 1365 to the CREATE_CHILD_SA request. In some situations, however, this 1366 could result in packets unnecessarily being dropped, so an 1367 implementation MAY want to defer such sending. 1369 The responder can be assured that the initiator is prepared to 1370 receive messages on an SA if either (1) it has received a 1371 cryptographically valid message on the new SA, or (2) the new SA 1372 rekeys an existing SA and it receives an IKE request to close the 1373 replaced SA. {{ Clarif-5.10 }} When rekeying an SA, the responder 1374 SHOULD continue to send traffic on the old SA until one of those 1375 events occurs. When establishing a new SA, the responder MAY defer 1376 sending messages on a new SA until either it receives one or a 1377 timeout has occurred. {{ Demoted the SHOULD }} If an initiator 1378 receives a message on an SA for which it has not received a response 1379 to its CREATE_CHILD_SA request, it should interpret that as a likely 1380 packet loss and retransmit the CREATE_CHILD_SA request. An initiator 1381 MAY send a dummy message on a newly created SA if it has no messages 1382 queued in order to assure the responder that the initiator is ready 1383 to receive messages. 1385 {{ Clarif-5.9 }} Throughout this document, "initiator" refers to the 1386 party who initiated the exchange being described, and "original 1387 initiator" refers to the party who initiated the whole IKE_SA. The 1388 "original initiator" always refers to the party who initiated the 1389 exchange which resulted in the current IKE_SA. In other words, if 1390 the the "original responder" starts rekeying the IKE_SA, that party 1391 becomes the "original initiator" of the new IKE_SA. 1393 2.8.1. Simultaneous CHILD_SA rekeying 1395 {{ The first two paragraphs were moved, and the rest was added, based 1396 on Clarif-5.12 }} 1398 If the two ends have the same lifetime policies, it is possible that 1399 both will initiate a rekeying at the same time (which will result in 1400 redundant SAs). To reduce the probability of this happening, the 1401 timing of rekeying requests SHOULD be jittered (delayed by a random 1402 amount of time after the need for rekeying is noticed). 1404 This form of rekeying may temporarily result in multiple similar SAs 1405 between the same pairs of nodes. When there are two SAs eligible to 1406 receive packets, a node MUST accept incoming packets through either 1407 SA. If redundant SAs are created though such a collision, the SA 1408 created with the lowest of the four nonces used in the two exchanges 1409 SHOULD be closed by the endpoint that created it. {{ Clarif-5.11 }} 1410 "Lowest" means an octet-by-octet, lexicographical comparison (instead 1411 of, for instance, comparing the nonces as large integers). In other 1412 words, start by comparing the first octet; if they're equal, move to 1413 the next octet, and so on. If you reach the end of one nonce, that 1414 nonce is the lower one. 1416 The following is an explanation on the impact this has on 1417 implementations. Assume that hosts A and B have an existing IPsec SA 1418 pair with SPIs (SPIa1,SPIb1), and both start rekeying it at the same 1419 time: 1421 Host A Host B 1422 ------------------------------------------------------------------- 1423 send req1: N(REKEY_SA,SPIa1), 1424 SA(..,SPIa2,..),Ni1,.. --> 1425 <-- send req2: N(REKEY_SA,SPIb1), 1426 SA(..,SPIb2,..),Ni2 1428 recv req2 <-- 1430 At this point, A knows there is a simultaneous rekeying going on. 1431 However, it cannot yet know which of the exchanges will have the 1432 lowest nonce, so it will just note the situation and respond as 1433 usual. 1435 send resp2: SA(..,SPIa3,..), 1436 Nr1,.. --> 1437 --> recv req1 1439 Now B also knows that simultaneous rekeying is going on. It responds 1440 as usual. 1442 <-- send resp1: SA(..,SPIb3,..), 1443 Nr2,.. 1444 recv resp1 <-- 1445 --> recv resp2 1447 At this point, there are three CHILD_SA pairs between A and B (the 1448 old one and two new ones). A and B can now compare the nonces. 1449 Suppose that the lowest nonce was Nr1 in message resp2; in this case, 1450 B (the sender of req2) deletes the redundant new SA, and A (the node 1451 that initiated the surviving rekeyed SA), deletes the old one. 1453 send req3: D(SPIa1) --> 1454 <-- send req4: D(SPIb2) 1455 --> recv req3 1456 <-- send resp4: D(SPIb1) 1457 recv req4 <-- 1458 send resp4: D(SPIa3) --> 1460 The rekeying is now finished. 1462 However, there is a second possible sequence of events that can 1463 happen if some packets are lost in the network, resulting in 1464 retransmissions. The rekeying begins as usual, but A's first packet 1465 (req1) is lost. 1467 Host A Host B 1468 ------------------------------------------------------------------- 1469 send req1: N(REKEY_SA,SPIa1), 1470 SA(..,SPIa2,..), 1471 Ni1,.. --> (lost) 1472 <-- send req2: N(REKEY_SA,SPIb1), 1473 SA(..,SPIb2,..),Ni2 1474 recv req2 <-- 1475 send resp2: SA(..,SPIa3,..), 1476 Nr1,.. --> 1477 --> recv resp2 1478 <-- send req3: D(SPIb1) 1479 recv req3 <-- 1480 send resp3: D(SPIa1) --> 1481 --> recv resp3 1483 From B's point of view, the rekeying is now completed, and since it 1484 has not yet received A's req1, it does not even know that these was 1485 simultaneous rekeying. However, A will continue retransmitting the 1486 message, and eventually it will reach B. 1488 resend req1 --> 1489 --> recv req1 1491 To B, it looks like A is trying to rekey an SA that no longer exists; 1492 thus, B responds to the request with something non-fatal such as 1493 NO_PROPOSAL_CHOSEN. 1495 <-- send resp1: N(NO_PROPOSAL_CHOSEN) 1496 recv resp1 <-- 1498 When A receives this error, it already knows there was simultaneous 1499 rekeying, so it can ignore the error message. 1501 2.8.2. Rekeying the IKE_SA Versus Reauthentication 1503 {{ Added this section from Clarif-5.2 }} 1505 Rekeying the IKE_SA and reauthentication are different concepts in 1506 IKEv2. Rekeying the IKE_SA establishes new keys for the IKE_SA and 1507 resets the Message ID counters, but it does not authenticate the 1508 parties again (no AUTH or EAP payloads are involved). 1510 Although rekeying the IKE_SA may be important in some environments, 1511 reauthentication (the verification that the parties still have access 1512 to the long-term credentials) is often more important. 1514 IKEv2 does not have any special support for reauthentication. 1516 Reauthentication is done by creating a new IKE_SA from scratch (using 1517 IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify 1518 payloads), creating new CHILD_SAs within the new IKE_SA (without 1519 REKEY_SA notify payloads), and finally deleting the old IKE_SA (which 1520 deletes the old CHILD_SAs as well). 1522 This means that reauthentication also establishes new keys for the 1523 IKE_SA and CHILD_SAs. Therefore, while rekeying can be performed 1524 more often than reauthentication, the situation where "authentication 1525 lifetime" is shorter than "key lifetime" does not make sense. 1527 While creation of a new IKE_SA can be initiated by either party 1528 (initiator or responder in the original IKE_SA), the use of EAP 1529 authentication and/or configuration payloads means in practice that 1530 reauthentication has to be initiated by the same party as the 1531 original IKE_SA. IKEv2 does not currently allow the responder to 1532 request reauthentication in this case; however, there is ongoing work 1533 to add this functionality [REAUTH]. 1535 2.9. Traffic Selector Negotiation 1537 {{ Clarif-7.2 }} When an RFC4301-compliant IPsec subsystem receives 1538 an IP packet and matches a "protect" selector in its Security Policy 1539 Database (SPD), the subsystem protects that packet with IPsec. When 1540 no SA exists yet, it is the task of IKE to create it. Maintenance of 1541 a system's SPD is outside the scope of IKE (see [PFKEY] for an 1542 example protocol), though some implementations might update their SPD 1543 in connection with the running of IKE (for an example scenario, see 1544 Section 1.1.3). 1546 Traffic Selector (TS) payloads allow endpoints to communicate some of 1547 the information from their SPD to their peers. TS payloads specify 1548 the selection criteria for packets that will be forwarded over the 1549 newly set up SA. This can serve as a consistency check in some 1550 scenarios to assure that the SPDs are consistent. In others, it 1551 guides the dynamic update of the SPD. 1553 Two TS payloads appear in each of the messages in the exchange that 1554 creates a CHILD_SA pair. Each TS payload contains one or more 1555 Traffic Selectors. Each Traffic Selector consists of an address 1556 range (IPv4 or IPv6), a port range, and an IP protocol ID. In 1557 support of the scenario described in Section 1.1.3, an initiator may 1558 request that the responder assign an IP address and tell the 1559 initiator what it is. {{ Clarif-6.1 }} That request is done using 1560 configuration payloads, not traffic selectors. An address in a TSi 1561 payload in a response does not mean that the responder has assigned 1562 that address to the initiator: it only means that if packets matching 1563 these traffic selectors are sent by the initiator, IPsec processing 1564 can be performed as agreed for this SA. 1566 IKEv2 allows the responder to choose a subset of the traffic proposed 1567 by the initiator. This could happen when the configurations of the 1568 two endpoints are being updated but only one end has received the new 1569 information. Since the two endpoints may be configured by different 1570 people, the incompatibility may persist for an extended period even 1571 in the absence of errors. It also allows for intentionally different 1572 configurations, as when one end is configured to tunnel all addresses 1573 and depends on the other end to have the up-to-date list. 1575 The first of the two TS payloads is known as TSi (Traffic Selector- 1576 initiator). The second is known as TSr (Traffic Selector-responder). 1577 TSi specifies the source address of traffic forwarded from (or the 1578 destination address of traffic forwarded to) the initiator of the 1579 CHILD_SA pair. TSr specifies the destination address of the traffic 1580 forwarded to (or the source address of the traffic forwarded from) 1581 the responder of the CHILD_SA pair. For example, if the original 1582 initiator request the creation of a CHILD_SA pair, and wishes to 1583 tunnel all traffic from subnet 192.0.1.* on the initiator's side to 1584 subnet 192.0.2.* on the responder's side, the initiator would include 1585 a single traffic selector in each TS payload. TSi would specify the 1586 address range (192.0.1.0 - 192.0.1.255) and TSr would specify the 1587 address range (192.0.2.0 - 192.0.2.255). Assuming that proposal was 1588 acceptable to the responder, it would send identical TS payloads 1589 back. (Note: The IP address range 192.0.2.* has been reserved for 1590 use in examples in RFCs and similar documents. This document needed 1591 two such ranges, and so also used 192.0.1.*. This should not be 1592 confused with any actual address.) 1594 The responder is allowed to narrow the choices by selecting a subset 1595 of the traffic, for instance by eliminating or narrowing the range of 1596 one or more members of the set of traffic selectors, provided the set 1597 does not become the NULL set. 1599 It is possible for the responder's policy to contain multiple smaller 1600 ranges, all encompassed by the initiator's traffic selector, and with 1601 the responder's policy being that each of those ranges should be sent 1602 over a different SA. Continuing the example above, the responder 1603 might have a policy of being willing to tunnel those addresses to and 1604 from the initiator, but might require that each address pair be on a 1605 separately negotiated CHILD_SA. If the initiator generated its 1606 request in response to an incoming packet from 192.0.1.43 to 1607 192.0.2.123, there would be no way for the responder to determine 1608 which pair of addresses should be included in this tunnel, and it 1609 would have to make a guess or reject the request with a status of 1610 SINGLE_PAIR_REQUIRED. 1612 {{ Clarif-4.11 }} Few implementations will have policies that require 1613 separate SAs for each address pair. Because of this, if only some 1614 part (or parts) of the TSi/TSr proposed by the initiator is (are) 1615 acceptable to the responder, responders SHOULD narrow TSi/TSr to an 1616 acceptable subset rather than use SINGLE_PAIR_REQUIRED. 1618 To enable the responder to choose the appropriate range in this case, 1619 if the initiator has requested the SA due to a data packet, the 1620 initiator SHOULD include as the first traffic selector in each of TSi 1621 and TSr a very specific traffic selector including the addresses in 1622 the packet triggering the request. In the example, the initiator 1623 would include in TSi two traffic selectors: the first containing the 1624 address range (192.0.1.43 - 192.0.1.43) and the source port and IP 1625 protocol from the packet and the second containing (192.0.1.0 - 1626 192.0.1.255) with all ports and IP protocols. The initiator would 1627 similarly include two traffic selectors in TSr. 1629 If the responder's policy does not allow it to accept the entire set 1630 of traffic selectors in the initiator's request, but does allow him 1631 to accept the first selector of TSi and TSr, then the responder MUST 1632 narrow the traffic selectors to a subset that includes the 1633 initiator's first choices. In this example, the responder might 1634 respond with TSi being (192.0.1.43 - 192.0.1.43) with all ports and 1635 IP protocols. 1637 If the initiator creates the CHILD_SA pair not in response to an 1638 arriving packet, but rather, say, upon startup, then there may be no 1639 specific addresses the initiator prefers for the initial tunnel over 1640 any other. In that case, the first values in TSi and TSr MAY be 1641 ranges rather than specific values, and the responder chooses a 1642 subset of the initiator's TSi and TSr that are acceptable. If more 1643 than one subset is acceptable but their union is not, the responder 1644 MUST accept some subset and MAY include a Notify payload of type 1645 ADDITIONAL_TS_POSSIBLE to indicate that the initiator might want to 1646 try again. This case will occur only when the initiator and 1647 responder are configured differently from one another. If the 1648 initiator and responder agree on the granularity of tunnels, the 1649 initiator will never request a tunnel wider than the responder will 1650 accept. {{ Demoted the SHOULD }} Such misconfigurations should be 1651 recorded in error logs. 1653 {{ Clarif-4.10 }} A concise summary of the narrowing process is: 1655 o If the responder's policy does not allow any part of the traffic 1656 covered by TSi/TSr, it responds with TS_UNACCEPTABLE. 1658 o If the responder's policy allows the entire set of traffic covered 1659 by TSi/TSr, no narrowing is necessary, and the responder can 1660 return the same TSi/TSr values. 1662 o Otherwise, narrowing is needed. If the responder's policy allows 1663 all traffic covered by TSi[1]/TSr[1] (the first traffic selectors 1664 in TSi/TSr) but not entire TSi/TSr, the responder narrows to an 1665 acceptable subset of TSi/TSr that includes TSi[1]/TSr[1]. 1667 o If the responder's policy does not allow all traffic covered by 1668 TSi[1]/TSr[1], but does allow some parts of TSi/TSr, it narrows to 1669 an acceptable subset of TSi/TSr. 1671 In the last two cases, there may be several subsets that are 1672 acceptable (but their union is not); in this case, the responder 1673 arbitrarily chooses one of them, and includes ADDITIONAL_TS_POSSIBLE 1674 notification in the response. 1676 2.9.1. Traffic Selectors Violating Own Policy 1678 {{ Clarif-4.12 }} 1680 When creating a new SA, the initiator should not propose traffic 1681 selectors that violate its own policy. If this rule is not followed, 1682 valid traffic may be dropped. 1684 This is best illustrated by an example. Suppose that host A has a 1685 policy whose effect is that traffic to 192.0.1.66 is sent via host B 1686 encrypted using AES, and traffic to all other hosts in 192.0.1.0/24 1687 is also sent via B, but must use 3DES. Suppose also that host B 1688 accepts any combination of AES and 3DES. 1690 If host A now proposes an SA that uses 3DES, and includes TSr 1691 containing (192.0.1.0-192.0.1.0.255), this will be accepted by host 1692 B. Now, host B can also use this SA to send traffic from 192.0.1.66, 1693 but those packets will be dropped by A since it requires the use of 1694 AES for those traffic. Even if host A creates a new SA only for 1695 192.0.1.66 that uses AES, host B may freely continue to use the first 1696 SA for the traffic. In this situation, when proposing the SA, host A 1697 should have followed its own policy, and included a TSr containing 1698 ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead. 1700 In general, if (1) the initiator makes a proposal "for traffic X 1701 (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator 1702 does not actually accept traffic X' with SA, and (3) the initiator 1703 would be willing to accept traffic X' with some SA' (!=SA), valid 1704 traffic can be unnecessarily dropped since the responder can apply 1705 either SA or SA' to traffic X'. 1707 2.10. Nonces 1709 The IKE_SA_INIT messages each contain a nonce. These nonces are used 1710 as inputs to cryptographic functions. The CREATE_CHILD_SA request 1711 and the CREATE_CHILD_SA response also contain nonces. These nonces 1712 are used to add freshness to the key derivation technique used to 1713 obtain keys for CHILD_SA, and to ensure creation of strong pseudo- 1714 random bits from the Diffie-Hellman key. Nonces used in IKEv2 MUST 1715 be randomly chosen, MUST be at least 128 bits in size, and MUST be at 1716 least half the key size of the negotiated prf. ("prf" refers to 1717 "pseudo-random function", one of the cryptographic algorithms 1718 negotiated in the IKE exchange.) {{ Clarif-7.4 }} However, the 1719 initiator chooses the nonce before the outcome of the negotiation is 1720 known. Because of that, the nonce has to be long enough for all the 1721 PRFs being proposed. If the same random number source is used for 1722 both keys and nonces, care must be taken to ensure that the latter 1723 use does not compromise the former. 1725 2.11. Address and Port Agility 1727 IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and 1728 AH associations for the same IP addresses it runs over. The IP 1729 addresses and ports in the outer header are, however, not themselves 1730 cryptographically protected, and IKE is designed to work even through 1731 Network Address Translation (NAT) boxes. An implementation MUST 1732 accept incoming requests even if the source port is not 500 or 4500, 1733 and MUST respond to the address and port from which the request was 1734 received. It MUST specify the address and port at which the request 1735 was received as the source address and port in the response. IKE 1736 functions identically over IPv4 or IPv6. 1738 2.12. Reuse of Diffie-Hellman Exponentials 1740 IKE generates keying material using an ephemeral Diffie-Hellman 1741 exchange in order to gain the property of "perfect forward secrecy". 1742 This means that once a connection is closed and its corresponding 1743 keys are forgotten, even someone who has recorded all of the data 1744 from the connection and gets access to all of the long-term keys of 1745 the two endpoints cannot reconstruct the keys used to protect the 1746 conversation without doing a brute force search of the session key 1747 space. 1749 Achieving perfect forward secrecy requires that when a connection is 1750 closed, each endpoint MUST forget not only the keys used by the 1751 connection but also any information that could be used to recompute 1752 those keys. In particular, it MUST forget the secrets used in the 1753 Diffie-Hellman calculation and any state that may persist in the 1754 state of a pseudo-random number generator that could be used to 1755 recompute the Diffie-Hellman secrets. 1757 Since the computing of Diffie-Hellman exponentials is computationally 1758 expensive, an endpoint may find it advantageous to reuse those 1759 exponentials for multiple connection setups. There are several 1760 reasonable strategies for doing this. An endpoint could choose a new 1761 exponential only periodically though this could result in less-than- 1762 perfect forward secrecy if some connection lasts for less than the 1763 lifetime of the exponential. Or it could keep track of which 1764 exponential was used for each connection and delete the information 1765 associated with the exponential only when some corresponding 1766 connection was closed. This would allow the exponential to be reused 1767 without losing perfect forward secrecy at the cost of maintaining 1768 more state. 1770 Decisions as to whether and when to reuse Diffie-Hellman exponentials 1771 is a private decision in the sense that it will not affect 1772 interoperability. An implementation that reuses exponentials MAY 1773 choose to remember the exponential used by the other endpoint on past 1774 exchanges and if one is reused to avoid the second half of the 1775 calculation. 1777 2.13. Generating Keying Material 1779 In the context of the IKE_SA, four cryptographic algorithms are 1780 negotiated: an encryption algorithm, an integrity protection 1781 algorithm, a Diffie-Hellman group, and a pseudo-random function 1782 (prf). The pseudo-random function is used for the construction of 1783 keying material for all of the cryptographic algorithms used in both 1784 the IKE_SA and the CHILD_SAs. 1786 We assume that each encryption algorithm and integrity protection 1787 algorithm uses a fixed-size key and that any randomly chosen value of 1788 that fixed size can serve as an appropriate key. For algorithms that 1789 accept a variable length key, a fixed key size MUST be specified as 1790 part of the cryptographic transform negotiated. For algorithms for 1791 which not all values are valid keys (such as DES or 3DES with key 1792 parity), the algorithm by which keys are derived from arbitrary 1793 values MUST be specified by the cryptographic transform. For 1794 integrity protection functions based on Hashed Message Authentication 1795 Code (HMAC), the fixed key size is the size of the output of the 1796 underlying hash function. When the prf function takes a variable 1797 length key, variable length data, and produces a fixed-length output 1798 (e.g., when using HMAC), the formulas in this document apply. When 1799 the key for the prf function has fixed length, the data provided as a 1800 key is truncated or padded with zeros as necessary unless exceptional 1801 processing is explained following the formula. 1803 Keying material will always be derived as the output of the 1804 negotiated prf algorithm. Since the amount of keying material needed 1805 may be greater than the size of the output of the prf algorithm, we 1806 will use the prf iteratively. We will use the terminology prf+ to 1807 describe the function that outputs a pseudo-random stream based on 1808 the inputs to a prf as follows: (where | indicates concatenation) 1810 prf+ (K,S) = T1 | T2 | T3 | T4 | ... 1812 where: 1813 T1 = prf (K, S | 0x01) 1814 T2 = prf (K, T1 | S | 0x02) 1815 T3 = prf (K, T2 | S | 0x03) 1816 T4 = prf (K, T3 | S | 0x04) 1818 continuing as needed to compute all required keys. The keys are 1819 taken from the output string without regard to boundaries (e.g., if 1820 the required keys are a 256-bit Advanced Encryption Standard (AES) 1821 key and a 160-bit HMAC key, and the prf function generates 160 bits, 1822 the AES key will come from T1 and the beginning of T2, while the HMAC 1823 key will come from the rest of T2 and the beginning of T3). 1825 The constant concatenated to the end of each string feeding the prf 1826 is a single octet. prf+ in this document is not defined beyond 255 1827 times the size of the prf output. 1829 2.14. Generating Keying Material for the IKE_SA 1831 The shared keys are computed as follows. A quantity called SKEYSEED 1832 is calculated from the nonces exchanged during the IKE_SA_INIT 1833 exchange and the Diffie-Hellman shared secret established during that 1834 exchange. SKEYSEED is used to calculate seven other secrets: SK_d 1835 used for deriving new keys for the CHILD_SAs established with this 1836 IKE_SA; SK_ai and SK_ar used as a key to the integrity protection 1837 algorithm for authenticating the component messages of subsequent 1838 exchanges; SK_ei and SK_er used for encrypting (and of course 1839 decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are 1840 used when generating an AUTH payload. 1842 SKEYSEED and its derivatives are computed as follows: 1844 SKEYSEED = prf(Ni | Nr, g^ir) 1846 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } 1847 = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) 1849 (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, 1850 SK_pi, and SK_pr are taken in order from the generated bits of the 1851 prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman 1852 exchange. g^ir is represented as a string of octets in big endian 1853 order padded with zeros if necessary to make it the length of the 1854 modulus. Ni and Nr are the nonces, stripped of any headers. If the 1855 negotiated prf takes a fixed-length key and the lengths of Ni and Nr 1856 do not add up to that length, half the bits must come from Ni and 1857 half from Nr, taking the first bits of each. 1859 The two directions of traffic flow use different keys. The keys used 1860 to protect messages from the original initiator are SK_ai and SK_ei. 1861 The keys used to protect messages in the other direction are SK_ar 1862 and SK_er. Each algorithm takes a fixed number of bits of keying 1863 material, which is specified as part of the algorithm. For integrity 1864 algorithms based on a keyed hash, the key size is always equal to the 1865 length of the output of the underlying hash function. 1867 2.15. Authentication of the IKE_SA 1869 When not using extensible authentication (see Section 2.16), the 1870 peers are authenticated by having each sign (or MAC using a shared 1871 secret as the key) a block of data. For the responder, the octets to 1872 be signed start with the first octet of the first SPI in the header 1873 of the second message and end with the last octet of the last payload 1874 in the second message. Appended to this (for purposes of computing 1875 the signature) are the initiator's nonce Ni (just the value, not the 1876 payload containing it), and the value prf(SK_pr,IDr') where IDr' is 1877 the responder's ID payload excluding the fixed header. Note that 1878 neither the nonce Ni nor the value prf(SK_pr,IDr') are transmitted. 1879 Similarly, the initiator signs the first message, starting with the 1880 first octet of the first SPI in the header and ending with the last 1881 octet of the last payload. Appended to this (for purposes of 1882 computing the signature) are the responder's nonce Nr, and the value 1883 prf(SK_pi,IDi'). In the above calculation, IDi' and IDr' are the 1884 entire ID payloads excluding the fixed header. It is critical to the 1885 security of the exchange that each side sign the other side's nonce. 1887 {{ Clarif-3.1 }} 1889 The initiator's signed octets can be described as: 1891 InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI 1892 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR 1893 RealIKEHDR = SPIi | SPIr | . . . | Length 1894 RealMessage1 = RealIKEHDR | RestOfMessage1 1895 NonceRPayload = PayloadHeader | NonceRData 1896 InitiatorIDPayload = PayloadHeader | RestOfIDPayload 1897 RestOfInitIDPayload = IDType | RESERVED | InitIDData 1898 MACedIDForI = prf(SK_pi, RestOfInitIDPayload) 1899 The responder's signed octets can be described as: 1901 ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR 1902 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR 1903 RealIKEHDR = SPIi | SPIr | . . . | Length 1904 RealMessage2 = RealIKEHDR | RestOfMessage2 1905 NonceIPayload = PayloadHeader | NonceIData 1906 ResponderIDPayload = PayloadHeader | RestOfIDPayload 1907 RestOfRespIDPayload = IDType | RESERVED | InitIDData 1908 MACedIDForR = prf(SK_pr, RestOfRespIDPayload) 1910 Note that all of the payloads are included under the signature, 1911 including any payload types not defined in this document. If the 1912 first message of the exchange is sent twice (the second time with a 1913 responder cookie and/or a different Diffie-Hellman group), it is the 1914 second version of the message that is signed. 1916 Optionally, messages 3 and 4 MAY include a certificate, or 1917 certificate chain providing evidence that the key used to compute a 1918 digital signature belongs to the name in the ID payload. The 1919 signature or MAC will be computed using algorithms dictated by the 1920 type of key used by the signer, and specified by the Auth Method 1921 field in the Authentication payload. There is no requirement that 1922 the initiator and responder sign with the same cryptographic 1923 algorithms. The choice of cryptographic algorithms depends on the 1924 type of key each has. In particular, the initiator may be using a 1925 shared key while the responder may have a public signature key and 1926 certificate. It will commonly be the case (but it is not required) 1927 that if a shared secret is used for authentication that the same key 1928 is used in both directions. Note that it is a common but typically 1929 insecure practice to have a shared key derived solely from a user- 1930 chosen password without incorporating another source of randomness. 1932 This is typically insecure because user-chosen passwords are unlikely 1933 to have sufficient unpredictability to resist dictionary attacks and 1934 these attacks are not prevented in this authentication method. 1935 (Applications using password-based authentication for bootstrapping 1936 and IKE_SA should use the authentication method in Section 2.16, 1937 which is designed to prevent off-line dictionary attacks.) {{ Demoted 1938 the SHOULD }} The pre-shared key needs to contain as much 1939 unpredictability as the strongest key being negotiated. In the case 1940 of a pre-shared key, the AUTH value is computed as: 1942 AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), ) 1944 where the string "Key Pad for IKEv2" is 17 ASCII characters without 1945 null termination. The shared secret can be variable length. The pad 1946 string is added so that if the shared secret is derived from a 1947 password, the IKE implementation need not store the password in 1948 cleartext, but rather can store the value prf(Shared Secret,"Key Pad 1949 for IKEv2"), which could not be used as a password equivalent for 1950 protocols other than IKEv2. As noted above, deriving the shared 1951 secret from a password is not secure. This construction is used 1952 because it is anticipated that people will do it anyway. The 1953 management interface by which the Shared Secret is provided MUST 1954 accept ASCII strings of at least 64 octets and MUST NOT add a null 1955 terminator before using them as shared secrets. It MUST also accept 1956 a HEX encoding of the Shared Secret. The management interface MAY 1957 accept other encodings if the algorithm for translating the encoding 1958 to a binary string is specified. 1960 {{ Clarif-3.8 }} If the negotiated prf takes a fixed-size key, the 1961 shared secret MUST be of that fixed size. This requirement means 1962 that it is difficult to use these PRFs with shared key authentication 1963 because it limits the shared secrets that can be used. Thus, PRFs 1964 that require a fixed-size key SHOULD NOT be used with shared key 1965 authentication. For example, PRF_AES128_CBC [PRFAES128CBC] 1966 originally used fixed key sizes; that RFC has been updated to handle 1967 variable key sizes in [PRFAES128CBC-bis]. Note that Section 2.13 1968 also contains text that is related to PRFs with fixed key size. 1969 However, the text in that section applies only to the prf+ 1970 construction. 1972 2.16. Extensible Authentication Protocol Methods 1974 In addition to authentication using public key signatures and shared 1975 secrets, IKE supports authentication using methods defined in RFC 1976 3748 [EAP]. Typically, these methods are asymmetric (designed for a 1977 user authenticating to a server), and they may not be mutual. For 1978 this reason, these protocols are typically used to authenticate the 1979 initiator to the responder and MUST be used in conjunction with a 1980 public key signature based authentication of the responder to the 1981 initiator. These methods are often associated with mechanisms 1982 referred to as "Legacy Authentication" mechanisms. 1984 While this memo references [EAP] with the intent that new methods can 1985 be added in the future without updating this specification, some 1986 simpler variations are documented here and in Section 3.16. [EAP] 1987 defines an authentication protocol requiring a variable number of 1988 messages. Extensible Authentication is implemented in IKE as 1989 additional IKE_AUTH exchanges that MUST be completed in order to 1990 initialize the IKE_SA. 1992 An initiator indicates a desire to use extensible authentication by 1993 leaving out the AUTH payload from message 3. By including an IDi 1994 payload but not an AUTH payload, the initiator has declared an 1995 identity but has not proven it. If the responder is willing to use 1996 an extensible authentication method, it will place an Extensible 1997 Authentication Protocol (EAP) payload in message 4 and defer sending 1998 SAr2, TSi, and TSr until initiator authentication is complete in a 1999 subsequent IKE_AUTH exchange. In the case of a minimal extensible 2000 authentication, the initial SA establishment will appear as follows: 2002 Initiator Responder 2003 ------------------------------------------------------------------- 2004 HDR, SAi1, KEi, Ni --> 2005 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 2006 HDR, SK {IDi, [CERTREQ,] 2007 [IDr,] SAi2, 2008 TSi, TSr} --> 2009 <-- HDR, SK {IDr, [CERT,] AUTH, 2010 EAP } 2011 HDR, SK {EAP} --> 2012 <-- HDR, SK {EAP (success)} 2013 HDR, SK {AUTH} --> 2014 <-- HDR, SK {AUTH, SAr2, TSi, TSr } 2016 {{ Clarif-3.11 }} As described in Section 2.2, when EAP is used, each 2017 pair of IKE_SA initial setup messages will have their message numbers 2018 incremented; the first pair of AUTH messages will have an ID of 1, 2019 the second will be 2, and so on. 2021 For EAP methods that create a shared key as a side effect of 2022 authentication, that shared key MUST be used by both the initiator 2023 and responder to generate AUTH payloads in messages 7 and 8 using the 2024 syntax for shared secrets specified in Section 2.15. The shared key 2025 from EAP is the field from the EAP specification named MSK. The 2026 shared key generated during an IKE exchange MUST NOT be used for any 2027 other purpose. 2029 EAP methods that do not establish a shared key SHOULD NOT be used, as 2030 they are subject to a number of man-in-the-middle attacks [EAPMITM] 2031 if these EAP methods are used in other protocols that do not use a 2032 server-authenticated tunnel. Please see the Security Considerations 2033 section for more details. If EAP methods that do not generate a 2034 shared key are used, the AUTH payloads in messages 7 and 8 MUST be 2035 generated using SK_pi and SK_pr, respectively. 2037 {{ Demoted the SHOULD }} The initiator of an IKE_SA using EAP needs 2038 to be capable of extending the initial protocol exchange to at least 2039 ten IKE_AUTH exchanges in the event the responder sends notification 2040 messages and/or retries the authentication prompt. Once the protocol 2041 exchange defined by the chosen EAP authentication method has 2042 successfully terminated, the responder MUST send an EAP payload 2043 containing the Success message. Similarly, if the authentication 2044 method has failed, the responder MUST send an EAP payload containing 2045 the Failure message. The responder MAY at any time terminate the IKE 2046 exchange by sending an EAP payload containing the Failure message. 2048 Following such an extended exchange, the EAP AUTH payloads MUST be 2049 included in the two messages following the one containing the EAP 2050 Success message. 2052 {{ Clarif-3.5 }} When the initiator authentication uses EAP, it is 2053 possible that the contents of the IDi payload is used only for AAA 2054 routing purposes and selecting which EAP method to use. This value 2055 may be different from the identity authenticated by the EAP method. 2056 It is important that policy lookups and access control decisions use 2057 the actual authenticated identity. Often the EAP server is 2058 implemented in a separate AAA server that communicates with the IKEv2 2059 responder. In this case, the authenticated identity has to be sent 2060 from the AAA server to the IKEv2 responder. 2062 {{ Clarif-3.9 }} The information in Section 2.17 about PRFs with 2063 fixed-size keys also applies to EAP authentication. For instance, a 2064 PRF that requires a 128-bit key cannot be used with EAP because 2065 specifies that the MSK is at least 512 bits long. 2067 2.17. Generating Keying Material for CHILD_SAs 2069 A single CHILD_SA is created by the IKE_AUTH exchange, and additional 2070 CHILD_SAs can optionally be created in CREATE_CHILD_SA exchanges. 2071 Keying material for them is generated as follows: 2073 KEYMAT = prf+(SK_d, Ni | Nr) 2075 Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this 2076 request is the first CHILD_SA created or the fresh Ni and Nr from the 2077 CREATE_CHILD_SA exchange if this is a subsequent creation. 2079 For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman 2080 exchange, the keying material is defined as: 2082 KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr ) 2084 where g^ir (new) is the shared secret from the ephemeral Diffie- 2085 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 2086 octet string in big endian order padded with zeros in the high-order 2087 bits if necessary to make it the length of the modulus). 2089 A single CHILD_SA negotiation may result in multiple security 2090 associations. ESP and AH SAs exist in pairs (one in each direction), 2091 and four SAs could be created in a single CHILD_SA negotiation if a 2092 combination of ESP and AH is being negotiated. 2094 Keying material MUST be taken from the expanded KEYMAT in the 2095 following order: 2097 o All keys for SAs carrying data from the initiator to the responder 2098 are taken before SAs going in the reverse direction. 2100 o If multiple IPsec protocols are negotiated, keying material is 2101 taken in the order in which the protocol headers will appear in 2102 the encapsulated packet. 2104 o If a single protocol has both encryption and authentication keys, 2105 the encryption key is taken from the first octets of KEYMAT and 2106 the authentication key is taken from the next octets. 2108 Each cryptographic algorithm takes a fixed number of bits of keying 2109 material specified as part of the algorithm. 2111 2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA Exchange 2113 The CREATE_CHILD_SA exchange can be used to rekey an existing IKE_SA 2114 (see Section 2.8). {{ Clarif-5.3 }} New initiator and responder SPIs 2115 are supplied in the SPI fields in the Proposal structures inside the 2116 Security Association (SA) payloads (not the SPI fields in the IKE 2117 header). The TS payloads are omitted when rekeying an IKE_SA. 2118 SKEYSEED for the new IKE_SA is computed using SK_d from the existing 2119 IKE_SA as follows: 2121 SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr) 2123 where g^ir (new) is the shared secret from the ephemeral Diffie- 2124 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 2125 octet string in big endian order padded with zeros if necessary to 2126 make it the length of the modulus) and Ni and Nr are the two nonces 2127 stripped of any headers. 2129 {{ Clarif-5.5 }} The old and new IKE_SA may have selected a different 2130 PRF. Because the rekeying exchange belongs to the old IKE_SA, it is 2131 the old IKE_SA's PRF that is used. Note that this may not work if 2132 the new IKE_SA's PRF has a fixed key size because the output of the 2133 PRF may not be of the correct size. 2135 The new IKE_SA MUST reset its message counters to 0. 2137 SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as 2138 specified in Section 2.14. 2140 2.19. Requesting an Internal Address on a Remote Network 2142 Most commonly occurring in the endpoint-to-security-gateway scenario, 2143 an endpoint may need an IP address in the network protected by the 2144 security gateway and may need to have that address dynamically 2145 assigned. A request for such a temporary address can be included in 2146 any request to create a CHILD_SA (including the implicit request in 2147 message 3) by including a CP payload. 2149 This function provides address allocation to an IPsec Remote Access 2150 Client (IRAC) trying to tunnel into a network protected by an IPsec 2151 Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an 2152 IKE_SA and a CHILD_SA, the IRAC MUST request the IRAS-controlled 2153 address (and optionally other information concerning the protected 2154 network) in the IKE_AUTH exchange. The IRAS may procure an address 2155 for the IRAC from any number of sources such as a DHCP/BOOTP server 2156 or its own address pool. 2158 Initiator Responder 2159 ------------------------------------------------------------------- 2160 HDR, SK {IDi, [CERT,] 2161 [CERTREQ,] [IDr,] AUTH, 2162 CP(CFG_REQUEST), SAi2, 2163 TSi, TSr} --> 2164 <-- HDR, SK {IDr, [CERT,] AUTH, 2165 CP(CFG_REPLY), SAr2, 2166 TSi, TSr} 2168 In all cases, the CP payload MUST be inserted before the SA payload. 2169 In variations of the protocol where there are multiple IKE_AUTH 2170 exchanges, the CP payloads MUST be inserted in the messages 2171 containing the SA payloads. 2173 CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute 2174 (either IPv4 or IPv6) but MAY contain any number of additional 2175 attributes the initiator wants returned in the response. 2177 For example, message from initiator to responder: 2179 {{ Clarif-6.3 }} 2181 CP(CFG_REQUEST)= 2182 INTERNAL_ADDRESS() 2183 TSi = (0, 0-65535,0.0.0.0-255.255.255.255) 2184 TSr = (0, 0-65535,0.0.0.0-255.255.255.255) 2186 NOTE: Traffic Selectors contain (protocol, port range, address 2187 range). 2189 Message from responder to initiator: 2191 CP(CFG_REPLY)= 2192 INTERNAL_ADDRESS(192.0.2.202) 2193 INTERNAL_NETMASK(255.255.255.0) 2194 INTERNAL_SUBNET(192.0.2.0/255.255.255.0) 2195 TSi = (0, 0-65535,192.0.2.202-192.0.2.202) 2196 TSr = (0, 0-65535,192.0.2.0-192.0.2.255) 2198 All returned values will be implementation dependent. As can be seen 2199 in the above example, the IRAS MAY also send other attributes that 2200 were not included in CP(CFG_REQUEST) and MAY ignore the non- 2201 mandatory attributes that it does not support. 2203 The responder MUST NOT send a CFG_REPLY without having first received 2204 a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS 2205 to perform an unnecessary configuration lookup if the IRAC cannot 2206 process the REPLY. In the case where the IRAS's configuration 2207 requires that CP be used for a given identity IDi, but IRAC has 2208 failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and 2209 terminate the IKE exchange with a FAILED_CP_REQUIRED error. 2211 2.20. Requesting the Peer's Version 2213 An IKE peer wishing to inquire about the other peer's IKE software 2214 version information MAY use the method below. This is an example of 2215 a configuration request within an INFORMATIONAL exchange, after the 2216 IKE_SA and first CHILD_SA have been created. 2218 An IKE implementation MAY decline to give out version information 2219 prior to authentication or even after authentication to prevent 2220 trolling in case some implementation is known to have some security 2221 weakness. In that case, it MUST either return an empty string or no 2222 CP payload if CP is not supported. 2224 Initiator Responder 2225 ------------------------------------------------------------------- 2226 HDR, SK{CP(CFG_REQUEST)} --> 2227 <-- HDR, SK{CP(CFG_REPLY)} 2229 CP(CFG_REQUEST)= 2230 APPLICATION_VERSION("") 2232 CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar 2233 Inc.") 2235 2.21. Error Handling 2237 There are many kinds of errors that can occur during IKE processing. 2238 If a request is received that is badly formatted or unacceptable for 2239 reasons of policy (e.g., no matching cryptographic algorithms), the 2240 response MUST contain a Notify payload indicating the error. If an 2241 error occurs outside the context of an IKE request (e.g., the node is 2242 getting ESP messages on a nonexistent SPI), the node SHOULD initiate 2243 an INFORMATIONAL exchange with a Notify payload describing the 2244 problem. 2246 Errors that occur before a cryptographically protected IKE_SA is 2247 established must be handled very carefully. There is a trade-off 2248 between wanting to be helpful in diagnosing a problem and responding 2249 to it and wanting to avoid being a dupe in a denial of service attack 2250 based on forged messages. 2252 If a node receives a message on UDP port 500 or 4500 outside the 2253 context of an IKE_SA known to it (and not a request to start one), it 2254 may be the result of a recent crash of the node. If the message is 2255 marked as a response, the node MAY audit the suspicious event but 2256 MUST NOT respond. If the message is marked as a request, the node 2257 MAY audit the suspicious event and MAY send a response. If a 2258 response is sent, the response MUST be sent to the IP address and 2259 port from whence it came with the same IKE SPIs and the Message ID 2260 copied. The response MUST NOT be cryptographically protected and 2261 MUST contain a Notify payload indicating INVALID_IKE_SPI. 2263 A node receiving such an unprotected Notify payload MUST NOT respond 2264 and MUST NOT change the state of any existing SAs. The message might 2265 be a forgery or might be a response the genuine correspondent was 2266 tricked into sending. {{ Demoted two SHOULDs }} A node should treat 2267 such a message (and also a network message like ICMP destination 2268 unreachable) as a hint that there might be problems with SAs to that 2269 IP address and should initiate a liveness test for any such IKE_SA. 2270 An implementation SHOULD limit the frequency of such tests to avoid 2271 being tricked into participating in a denial of service attack. 2273 A node receiving a suspicious message from an IP address with which 2274 it has an IKE_SA MAY send an IKE Notify payload in an IKE 2275 INFORMATIONAL exchange over that SA. {{ Demoted the SHOULD }} The 2276 recipient MUST NOT change the state of any SAs as a result but may 2277 wish to audit the event to aid in diagnosing malfunctions. A node 2278 MUST limit the rate at which it will send messages in response to 2279 unprotected messages. 2281 2.22. IPComp 2283 Use of IP compression [IPCOMP] can be negotiated as part of the setup 2284 of a CHILD_SA. While IP compression involves an extra header in each 2285 packet and a compression parameter index (CPI), the virtual 2286 "compression association" has no life outside the ESP or AH SA that 2287 contains it. Compression associations disappear when the 2288 corresponding ESP or AH SA goes away. It is not explicitly mentioned 2289 in any DELETE payload. 2291 Negotiation of IP compression is separate from the negotiation of 2292 cryptographic parameters associated with a CHILD_SA. A node 2293 requesting a CHILD_SA MAY advertise its support for one or more 2294 compression algorithms through one or more Notify payloads of type 2295 IPCOMP_SUPPORTED. The response MAY indicate acceptance of a single 2296 compression algorithm with a Notify payload of type IPCOMP_SUPPORTED. 2297 These payloads MUST NOT occur in messages that do not contain SA 2298 payloads. 2300 Although there has been discussion of allowing multiple compression 2301 algorithms to be accepted and to have different compression 2302 algorithms available for the two directions of a CHILD_SA, 2303 implementations of this specification MUST NOT accept an IPComp 2304 algorithm that was not proposed, MUST NOT accept more than one, and 2305 MUST NOT compress using an algorithm other than one proposed and 2306 accepted in the setup of the CHILD_SA. 2308 A side effect of separating the negotiation of IPComp from 2309 cryptographic parameters is that it is not possible to propose 2310 multiple cryptographic suites and propose IP compression with some of 2311 them but not others. 2313 2.23. NAT Traversal 2315 Network Address Translation (NAT) gateways are a controversial 2316 subject. This section briefly describes what they are and how they 2317 are likely to act on IKE traffic. Many people believe that NATs are 2318 evil and that we should not design our protocols so as to make them 2319 work better. IKEv2 does specify some unintuitive processing rules in 2320 order that NATs are more likely to work. 2322 NATs exist primarily because of the shortage of IPv4 addresses, 2323 though there are other rationales. IP nodes that are "behind" a NAT 2324 have IP addresses that are not globally unique, but rather are 2325 assigned from some space that is unique within the network behind the 2326 NAT but that are likely to be reused by nodes behind other NATs. 2327 Generally, nodes behind NATs can communicate with other nodes behind 2328 the same NAT and with nodes with globally unique addresses, but not 2329 with nodes behind other NATs. There are exceptions to that rule. 2330 When those nodes make connections to nodes on the real Internet, the 2331 NAT gateway "translates" the IP source address to an address that 2332 will be routed back to the gateway. Messages to the gateway from the 2333 Internet have their destination addresses "translated" to the 2334 internal address that will route the packet to the correct endnode. 2336 NATs are designed to be "transparent" to endnodes. Neither software 2337 on the node behind the NAT nor the node on the Internet requires 2338 modification to communicate through the NAT. Achieving this 2339 transparency is more difficult with some protocols than with others. 2340 Protocols that include IP addresses of the endpoints within the 2341 payloads of the packet will fail unless the NAT gateway understands 2342 the protocol and modifies the internal references as well as those in 2343 the headers. Such knowledge is inherently unreliable, is a network 2344 layer violation, and often results in subtle problems. 2346 Opening an IPsec connection through a NAT introduces special 2347 problems. If the connection runs in transport mode, changing the IP 2348 addresses on packets will cause the checksums to fail and the NAT 2349 cannot correct the checksums because they are cryptographically 2350 protected. Even in tunnel mode, there are routing problems because 2351 transparently translating the addresses of AH and ESP packets 2352 requires special logic in the NAT and that logic is heuristic and 2353 unreliable in nature. For that reason, IKEv2 can negotiate UDP 2354 encapsulation of IKE and ESP packets. This encoding is slightly less 2355 efficient but is easier for NATs to process. In addition, firewalls 2356 may be configured to pass IPsec traffic over UDP but not ESP/AH or 2357 vice versa. 2359 It is a common practice of NATs to translate TCP and UDP port numbers 2360 as well as addresses and use the port numbers of inbound packets to 2361 decide which internal node should get a given packet. For this 2362 reason, even though IKE packets MUST be sent from and to UDP port 2363 500, they MUST be accepted coming from any port and responses MUST be 2364 sent to the port from whence they came. This is because the ports 2365 may be modified as the packets pass through NATs. Similarly, IP 2366 addresses of the IKE endpoints are generally not included in the IKE 2367 payloads because the payloads are cryptographically protected and 2368 could not be transparently modified by NATs. 2370 Port 4500 is reserved for UDP-encapsulated ESP and IKE. When working 2371 through a NAT, it is generally better to pass IKE packets over port 2372 4500 because some older NATs handle IKE traffic on port 500 cleverly 2373 in an attempt to transparently establish IPsec connections between 2374 endpoints that don't handle NAT traversal themselves. Such NATs may 2375 interfere with the straightforward NAT traversal envisioned by this 2376 document. {{ Clarif-7.6 }} An IPsec endpoint that discovers a NAT 2377 between it and its correspondent MUST send all subsequent traffic 2378 from port 4500, which NATs should not treat specially (as they might 2379 with port 500). 2381 The specific requirements for supporting NAT traversal [NATREQ] are 2382 listed below. Support for NAT traversal is optional. In this 2383 section only, requirements listed as MUST apply only to 2384 implementations supporting NAT traversal. 2386 o IKE MUST listen on port 4500 as well as port 500. IKE MUST 2387 respond to the IP address and port from which packets arrived. 2389 o Both IKE initiator and responder MUST include in their IKE_SA_INIT 2390 packets Notify payloads of type NAT_DETECTION_SOURCE_IP and 2391 NAT_DETECTION_DESTINATION_IP. Those payloads can be used to 2392 detect if there is NAT between the hosts, and which end is behind 2393 the NAT. The location of the payloads in the IKE_SA_INIT packets 2394 are just after the Ni and Nr payloads (before the optional CERTREQ 2395 payload). 2397 o If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches 2398 the hash of the source IP and port found from the IP header of the 2399 packet containing the payload, it means that the other end is 2400 behind NAT (i.e., someone along the route changed the source 2401 address of the original packet to match the address of the NAT 2402 box). In this case, this end should allow dynamic update of the 2403 other ends IP address, as described later. 2405 o If the NAT_DETECTION_DESTINATION_IP payload received does not 2406 match the hash of the destination IP and port found from the IP 2407 header of the packet containing the payload, it means that this 2408 end is behind a NAT. In this case, this end SHOULD start sending 2409 keepalive packets as explained in [UDPENCAPS]. 2411 o The IKE initiator MUST check these payloads if present and if they 2412 do not match the addresses in the outer packet MUST tunnel all 2413 future IKE and ESP packets associated with this IKE_SA over UDP 2414 port 4500. 2416 o To tunnel IKE packets over UDP port 4500, the IKE header has four 2417 octets of zero prepended and the result immediately follows the 2418 UDP header. To tunnel ESP packets over UDP port 4500, the ESP 2419 header immediately follows the UDP header. Since the first four 2420 bytes of the ESP header contain the SPI, and the SPI cannot 2421 validly be zero, it is always possible to distinguish ESP and IKE 2422 messages. 2424 o The original source and destination IP address required for the 2425 transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) 2426 are obtained from the Traffic Selectors associated with the 2427 exchange. In the case of NAT traversal, the Traffic Selectors 2428 MUST contain exactly one IP address, which is then used as the 2429 original IP address. 2431 o There are cases where a NAT box decides to remove mappings that 2432 are still alive (for example, the keepalive interval is too long, 2433 or the NAT box is rebooted). To recover in these cases, hosts 2434 that are not behind a NAT SHOULD send all packets (including 2435 retransmission packets) to the IP address and port from the last 2436 valid authenticated packet from the other end (i.e., dynamically 2437 update the address). {{ Promoted the SHOULD }} A host behind a NAT 2438 MUST NOT do this because it opens a DoS attack possibility. Any 2439 authenticated IKE packet or any authenticated UDP-encapsulated ESP 2440 packet can be used to detect that the IP address or the port has 2441 changed. 2443 Note that similar but probably not identical actions will likely be 2444 needed to make IKE work with Mobile IP, but such processing is not 2445 addressed by this document. 2447 2.24. Explicit Congestion Notification (ECN) 2449 When IPsec tunnels behave as originally specified in [IPSECARCH-OLD], 2450 ECN usage is not appropriate for the outer IP headers because tunnel 2451 decapsulation processing discards ECN congestion indications to the 2452 detriment of the network. ECN support for IPsec tunnels for IKEv1- 2453 based IPsec requires multiple operating modes and negotiation (see 2454 [ECN]). IKEv2 simplifies this situation by requiring that ECN be 2455 usable in the outer IP headers of all tunnel-mode IPsec SAs created 2456 by IKEv2. Specifically, tunnel encapsulators and decapsulators for 2457 all tunnel-mode SAs created by IKEv2 MUST support the ECN full- 2458 functionality option for tunnels specified in [ECN] and MUST 2459 implement the tunnel encapsulation and decapsulation processing 2460 specified in [IPSECARCH] to prevent discarding of ECN congestion 2461 indications. 2463 3. Header and Payload Formats 2465 3.1. The IKE Header 2467 IKE messages use UDP ports 500 and/or 4500, with one IKE message per 2468 UDP datagram. Information from the beginning of the packet through 2469 the UDP header is largely ignored except that the IP addresses and 2470 UDP ports from the headers are reversed and used for return packets. 2472 When sent on UDP port 500, IKE messages begin immediately following 2473 the UDP header. When sent on UDP port 4500, IKE messages have 2474 prepended four octets of zero. These four octets of zero are not 2475 part of the IKE message and are not included in any of the length 2476 fields or checksums defined by IKE. Each IKE message begins with the 2477 IKE header, denoted HDR in this memo. Following the header are one 2478 or more IKE payloads each identified by a "Next Payload" field in the 2479 preceding payload. Payloads are processed in the order in which they 2480 appear in an IKE message by invoking the appropriate processing 2481 routine according to the "Next Payload" field in the IKE header and 2482 subsequently according to the "Next Payload" field in the IKE payload 2483 itself until a "Next Payload" field of zero indicates that no 2484 payloads follow. If a payload of type "Encrypted" is found, that 2485 payload is decrypted and its contents parsed as additional payloads. 2486 An Encrypted payload MUST be the last payload in a packet and an 2487 Encrypted payload MUST NOT contain another Encrypted payload. 2489 The Recipient SPI in the header identifies an instance of an IKE 2490 security association. It is therefore possible for a single instance 2491 of IKE to multiplex distinct sessions with multiple peers. 2493 All multi-octet fields representing integers are laid out in big 2494 endian order (aka most significant byte first, or network byte 2495 order). 2497 The format of the IKE header is shown in Figure 4. 2499 1 2 3 2500 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 2501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2502 ! IKE_SA Initiator's SPI ! 2503 ! ! 2504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2505 ! IKE_SA Responder's SPI ! 2506 ! ! 2507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2508 ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! 2509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2510 ! Message ID ! 2511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2512 ! Length ! 2513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2515 Figure 4: IKE Header Format 2517 o Initiator's SPI (8 octets) - A value chosen by the initiator to 2518 identify a unique IKE security association. This value MUST NOT 2519 be zero. 2521 o Responder's SPI (8 octets) - A value chosen by the responder to 2522 identify a unique IKE security association. This value MUST be 2523 zero in the first message of an IKE Initial Exchange (including 2524 repeats of that message including a cookie). {{ The phrase "and 2525 MUST NOT be zero in any other message" was removed; Clarif-2.1 }} 2527 o Next Payload (1 octet) - Indicates the type of payload that 2528 immediately follows the header. The format and value of each 2529 payload are defined below. 2531 o Major Version (4 bits) - Indicates the major version of the IKE 2532 protocol in use. Implementations based on this version of IKE 2533 MUST set the Major Version to 2. Implementations based on 2534 previous versions of IKE and ISAKMP MUST set the Major Version to 2535 1. Implementations based on this version of IKE MUST reject or 2536 ignore messages containing a version number greater than 2. 2538 o Minor Version (4 bits) - Indicates the minor version of the IKE 2539 protocol in use. Implementations based on this version of IKE 2540 MUST set the Minor Version to 0. They MUST ignore the minor 2541 version number of received messages. 2543 o Exchange Type (1 octet) - Indicates the type of exchange being 2544 used. This constrains the payloads sent in each message and 2545 orderings of messages in an exchange. 2547 Exchange Type Value 2548 ---------------------------------- 2549 RESERVED 0-33 2550 IKE_SA_INIT 34 2551 IKE_AUTH 35 2552 CREATE_CHILD_SA 36 2553 INFORMATIONAL 37 2554 RESERVED TO IANA 38-239 2555 Reserved for private use 240-255 2557 o Flags (1 octet) - Indicates specific options that are set for the 2558 message. Presence of options are indicated by the appropriate bit 2559 in the flags field being set. The bits are defined LSB first, so 2560 bit 0 would be the least significant bit of the Flags octet. In 2561 the description below, a bit being 'set' means its value is '1', 2562 while 'cleared' means its value is '0'. 2564 * X(reserved) (bits 0-2) - These bits MUST be cleared when 2565 sending and MUST be ignored on receipt. 2567 * I(nitiator) (bit 3 of Flags) - This bit MUST be set in messages 2568 sent by the original initiator of the IKE_SA and MUST be 2569 cleared in messages sent by the original responder. It is used 2570 by the recipient to determine which eight octets of the SPI 2571 were generated by the recipient. 2573 * V(ersion) (bit 4 of Flags) - This bit indicates that the 2574 transmitter is capable of speaking a higher major version 2575 number of the protocol than the one indicated in the major 2576 version number field. Implementations of IKEv2 must clear this 2577 bit when sending and MUST ignore it in incoming messages. 2579 * R(esponse) (bit 5 of Flags) - This bit indicates that this 2580 message is a response to a message containing the same message 2581 ID. This bit MUST be cleared in all request messages and MUST 2582 be set in all responses. An IKE endpoint MUST NOT generate a 2583 response to a message that is marked as being a response. 2585 * X(reserved) (bits 6-7 of Flags) - These bits MUST be cleared 2586 when sending and MUST be ignored on receipt. 2588 o Message ID (4 octets) - Message identifier used to control 2589 retransmission of lost packets and matching of requests and 2590 responses. It is essential to the security of the protocol 2591 because it is used to prevent message replay attacks. See 2592 Section 2.1 and Section 2.2. 2594 o Length (4 octets) - Length of total message (header + payloads) in 2595 octets. 2597 3.2. Generic Payload Header 2599 Each IKE payload defined in Section 3.3 through Section 3.16 begins 2600 with a generic payload header, shown in Figure 5. Figures for each 2601 payload below will include the generic payload header, but for 2602 brevity the description of each field will be omitted. 2604 1 2 3 2605 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 2606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2607 ! Next Payload !C! RESERVED ! Payload Length ! 2608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2610 Figure 5: Generic Payload Header 2612 The Generic Payload Header fields are defined as follows: 2614 o Next Payload (1 octet) - Identifier for the payload type of the 2615 next payload in the message. If the current payload is the last 2616 in the message, then this field will be 0. This field provides a 2617 "chaining" capability whereby additional payloads can be added to 2618 a message by appending it to the end of the message and setting 2619 the "Next Payload" field of the preceding payload to indicate the 2620 new payload's type. An Encrypted payload, which must always be 2621 the last payload of a message, is an exception. It contains data 2622 structures in the format of additional payloads. In the header of 2623 an Encrypted payload, the Next Payload field is set to the payload 2624 type of the first contained payload (instead of 0). The payload 2625 type values are: 2627 Next Payload Type Notation Value 2628 -------------------------------------------------- 2629 No Next Payload 0 2630 RESERVED 1-32 2631 Security Association SA 33 2632 Key Exchange KE 34 2633 Identification - Initiator IDi 35 2634 Identification - Responder IDr 36 2635 Certificate CERT 37 2636 Certificate Request CERTREQ 38 2637 Authentication AUTH 39 2638 Nonce Ni, Nr 40 2639 Notify N 41 2640 Delete D 42 2641 Vendor ID V 43 2642 Traffic Selector - Initiator TSi 44 2643 Traffic Selector - Responder TSr 45 2644 Encrypted E 46 2645 Configuration CP 47 2646 Extensible Authentication EAP 48 2647 RESERVED TO IANA 49-127 2648 PRIVATE USE 128-255 2650 (Payload type values 1-32 should not be assigned in the 2651 future so that there is no overlap with the code assignments 2652 for IKEv1.) 2654 o Critical (1 bit) - MUST be set to zero if the sender wants the 2655 recipient to skip this payload if it does not understand the 2656 payload type code in the Next Payload field of the previous 2657 payload. MUST be set to one if the sender wants the recipient to 2658 reject this entire message if it does not understand the payload 2659 type. MUST be ignored by the recipient if the recipient 2660 understands the payload type code. MUST be set to zero for 2661 payload types defined in this document. Note that the critical 2662 bit applies to the current payload rather than the "next" payload 2663 whose type code appears in the first octet. The reasoning behind 2664 not setting the critical bit for payloads defined in this document 2665 is that all implementations MUST understand all payload types 2666 defined in this document and therefore must ignore the Critical 2667 bit's value. Skipped payloads are expected to have valid Next 2668 Payload and Payload Length fields. 2670 o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on 2671 receipt. 2673 o Payload Length (2 octets) - Length in octets of the current 2674 payload, including the generic payload header. 2676 3.3. Security Association Payload 2678 The Security Association Payload, denoted SA in this memo, is used to 2679 negotiate attributes of a security association. Assembly of Security 2680 Association Payloads requires great peace of mind. An SA payload MAY 2681 contain multiple proposals. If there is more than one, they MUST be 2682 ordered from most preferred to least preferred. Each proposal may 2683 contain multiple IPsec protocols (where a protocol is IKE, ESP, or 2684 AH), each protocol MAY contain multiple transforms, and each 2685 transform MAY contain multiple attributes. When parsing an SA, an 2686 implementation MUST check that the total Payload Length is consistent 2687 with the payload's internal lengths and counts. Proposals, 2688 Transforms, and Attributes each have their own variable length 2689 encodings. They are nested such that the Payload Length of an SA 2690 includes the combined contents of the SA, Proposal, Transform, and 2691 Attribute information. The length of a Proposal includes the lengths 2692 of all Transforms and Attributes it contains. The length of a 2693 Transform includes the lengths of all Attributes it contains. 2695 The syntax of Security Associations, Proposals, Transforms, and 2696 Attributes is based on ISAKMP; however the semantics are somewhat 2697 different. The reason for the complexity and the hierarchy is to 2698 allow for multiple possible combinations of algorithms to be encoded 2699 in a single SA. Sometimes there is a choice of multiple algorithms, 2700 whereas other times there is a combination of algorithms. For 2701 example, an initiator might want to propose using (AH w/MD5 and ESP 2702 w/3DES) OR (ESP w/MD5 and 3DES). 2704 One of the reasons the semantics of the SA payload has changed from 2705 ISAKMP and IKEv1 is to make the encodings more compact in common 2706 cases. 2708 The Proposal structure contains within it a Proposal # and an IPsec 2709 protocol ID. Each structure MUST have the same Proposal # as the 2710 previous one or be one (1) greater. The first Proposal MUST have a 2711 Proposal # of one (1). If two successive structures have the same 2712 Proposal number, it means that the proposal consists of the first 2713 structure AND the second. So a proposal of AH AND ESP would have two 2714 proposal structures, one for AH and one for ESP and both would have 2715 Proposal #1. A proposal of AH OR ESP would have two proposal 2716 structures, one for AH with Proposal #1 and one for ESP with Proposal 2717 #2. 2719 Each Proposal/Protocol structure is followed by one or more transform 2720 structures. The number of different transforms is generally 2721 determined by the Protocol. AH generally has a single transform: an 2722 integrity check algorithm. ESP generally has two: an encryption 2723 algorithm and an integrity check algorithm. IKE generally has four 2724 transforms: a Diffie-Hellman group, an integrity check algorithm, a 2725 prf algorithm, and an encryption algorithm. If an algorithm that 2726 combines encryption and integrity protection is proposed, it MUST be 2727 proposed as an encryption algorithm and an integrity protection 2728 algorithm MUST NOT be proposed. For each Protocol, the set of 2729 permissible transforms is assigned transform ID numbers, which appear 2730 in the header of each transform. 2732 If there are multiple transforms with the same Transform Type, the 2733 proposal is an OR of those transforms. If there are multiple 2734 Transforms with different Transform Types, the proposal is an AND of 2735 the different groups. For example, to propose ESP with (3DES or 2736 IDEA) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two 2737 Transform Type 1 candidates (one for 3DES and one for IDEA) and two 2738 Transform Type 2 candidates (one for HMAC_MD5 and one for HMAC_SHA). 2739 This effectively proposes four combinations of algorithms. If the 2740 initiator wanted to propose only a subset of those, for example (3DES 2741 and HMAC_MD5) or (IDEA and HMAC_SHA), there is no way to encode that 2742 as multiple transforms within a single Proposal. Instead, the 2743 initiator would have to construct two different Proposals, each with 2744 two transforms. 2746 A given transform MAY have one or more Attributes. Attributes are 2747 necessary when the transform can be used in more than one way, as 2748 when an encryption algorithm has a variable key size. The transform 2749 would specify the algorithm and the attribute would specify the key 2750 size. Most transforms do not have attributes. A transform MUST NOT 2751 have multiple attributes of the same type. To propose alternate 2752 values for an attribute (for example, multiple key sizes for the AES 2753 encryption algorithm), and implementation MUST include multiple 2754 Transforms with the same Transform Type each with a single Attribute. 2756 Note that the semantics of Transforms and Attributes are quite 2757 different from those in IKEv1. In IKEv1, a single Transform carried 2758 multiple algorithms for a protocol with one carried in the Transform 2759 and the others carried in the Attributes. 2761 1 2 3 2762 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 2763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2764 ! Next Payload !C! RESERVED ! Payload Length ! 2765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2766 ! ! 2767 ~ ~ 2768 ! ! 2769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2771 Figure 6: Security Association Payload 2773 o Proposals (variable) - One or more proposal substructures. 2775 The payload type for the Security Association Payload is thirty three 2776 (33). 2778 3.3.1. Proposal Substructure 2780 1 2 3 2781 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 2782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2783 ! 0 (last) or 2 ! RESERVED ! Proposal Length ! 2784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2785 ! Proposal # ! Protocol ID ! SPI Size !# of Transforms! 2786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2787 ~ SPI (variable) ~ 2788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2789 ! ! 2790 ~ ~ 2791 ! ! 2792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2794 Figure 7: Proposal Substructure 2796 o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the 2797 last Proposal Substructure in the SA. This syntax is inherited 2798 from ISAKMP, but is unnecessary because the last Proposal could be 2799 identified from the length of the SA. The value (2) corresponds 2800 to a Payload Type of Proposal in IKEv1, and the first four octets 2801 of the Proposal structure are designed to look somewhat like the 2802 header of a Payload. 2804 o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on 2805 receipt. 2807 o Proposal Length (2 octets) - Length of this proposal, including 2808 all transforms and attributes that follow. 2810 o Proposal # (1 octet) - When a proposal is made, the first proposal 2811 in an SA payload MUST be #1, and subsequent proposals MUST either 2812 be the same as the previous proposal (indicating an AND of the two 2813 proposals) or one more than the previous proposal (indicating an 2814 OR of the two proposals). When a proposal is accepted, all of the 2815 proposal numbers in the SA payload MUST be the same and MUST match 2816 the number on the proposal sent that was accepted. 2818 o Protocol ID (1 octet) - Specifies the IPsec protocol identifier 2819 for the current negotiation. The defined values are: 2821 Protocol Protocol ID 2822 ----------------------------------- 2823 RESERVED 0 2824 IKE 1 2825 AH 2 2826 ESP 3 2827 RESERVED TO IANA 4-200 2828 PRIVATE USE 201-255 2830 o SPI Size (1 octet) - For an initial IKE_SA negotiation, this field 2831 MUST be zero; the SPI is obtained from the outer header. During 2832 subsequent negotiations, it is equal to the size, in octets, of 2833 the SPI of the corresponding protocol (8 for IKE, 4 for ESP and 2834 AH). 2836 o # of Transforms (1 octet) - Specifies the number of transforms in 2837 this proposal. 2839 o SPI (variable) - The sending entity's SPI. Even if the SPI Size 2840 is not a multiple of 4 octets, there is no padding applied to the 2841 payload. When the SPI Size field is zero, this field is not 2842 present in the Security Association payload. 2844 o Transforms (variable) - One or more transform substructures. 2846 3.3.2. Transform Substructure 2848 1 2 3 2849 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 2850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2851 ! 0 (last) or 3 ! RESERVED ! Transform Length ! 2852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2853 !Transform Type ! RESERVED ! Transform ID ! 2854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2855 ! ! 2856 ~ Transform Attributes ~ 2857 ! ! 2858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2860 Figure 8: Transform Substructure 2862 o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the 2863 last Transform Substructure in the Proposal. This syntax is 2864 inherited from ISAKMP, but is unnecessary because the last 2865 Proposal could be identified from the length of the SA. The value 2866 (3) corresponds to a Payload Type of Transform in IKEv1, and the 2867 first four octets of the Transform structure are designed to look 2868 somewhat like the header of a Payload. 2870 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 2872 o Transform Length - The length (in octets) of the Transform 2873 Substructure including Header and Attributes. 2875 o Transform Type (1 octet) - The type of transform being specified 2876 in this transform. Different protocols support different 2877 transform types. For some protocols, some of the transforms may 2878 be optional. If a transform is optional and the initiator wishes 2879 to propose that the transform be omitted, no transform of the 2880 given type is included in the proposal. If the initiator wishes 2881 to make use of the transform optional to the responder, it 2882 includes a transform substructure with transform ID = 0 as one of 2883 the options. 2885 o Transform ID (2 octets) - The specific instance of the transform 2886 type being proposed. 2888 The tranform type values are: 2890 Description Trans. Used In 2891 Type 2892 ------------------------------------------------------------------ 2893 RESERVED 0 2894 Encryption Algorithm (ENCR) 1 IKE and ESP 2895 Pseudo-random Function (PRF) 2 IKE 2896 Integrity Algorithm (INTEG) 3 IKE, AH, optional in ESP 2897 Diffie-Hellman Group (D-H) 4 IKE, optional in AH & ESP 2898 Extended Sequence Numbers (ESN) 5 AH and ESP 2899 RESERVED TO IANA 6-240 2900 PRIVATE USE 241-255 2902 For Transform Type 1 (Encryption Algorithm), defined Transform IDs 2903 are: 2905 Name Number Defined In 2906 --------------------------------------------------- 2907 RESERVED 0 2908 ENCR_DES_IV64 1 (RFC1827) 2909 ENCR_DES 2 (RFC2405), [DES] 2910 ENCR_3DES 3 (RFC2451) 2911 ENCR_RC5 4 (RFC2451) 2912 ENCR_IDEA 5 (RFC2451), [IDEA] 2913 ENCR_CAST 6 (RFC2451) 2914 ENCR_BLOWFISH 7 (RFC2451) 2915 ENCR_3IDEA 8 (RFC2451) 2916 ENCR_DES_IV32 9 2917 RESERVED 10 2918 ENCR_NULL 11 (RFC2410) 2919 ENCR_AES_CBC 12 (RFC3602) 2920 ENCR_AES_CTR 13 (RFC3664) 2921 RESERVED TO IANA 14-1023 2922 PRIVATE USE 1024-65535 2924 For Transform Type 2 (Pseudo-random Function), defined Transform IDs 2925 are: 2927 Name Number Defined In 2928 ------------------------------------------------------ 2929 RESERVED 0 2930 PRF_HMAC_MD5 1 (RFC2104), [MD5] 2931 PRF_HMAC_SHA1 2 (RFC2104), [SHA] 2932 PRF_HMAC_TIGER 3 (RFC2104) 2933 PRF_AES128_XCBC 4 (RFC3664) 2934 RESERVED TO IANA 5-1023 2935 PRIVATE USE 1024-65535 2937 For Transform Type 3 (Integrity Algorithm), defined Transform IDs 2938 are: 2940 Name Number Defined In 2941 ---------------------------------------- 2942 NONE 0 2943 AUTH_HMAC_MD5_96 1 (RFC2403) 2944 AUTH_HMAC_SHA1_96 2 (RFC2404) 2945 AUTH_DES_MAC 3 2946 AUTH_KPDK_MD5 4 (RFC1826) 2947 AUTH_AES_XCBC_96 5 (RFC3566) 2948 RESERVED TO IANA 6-1023 2949 PRIVATE USE 1024-65535 2951 For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs 2952 are: 2954 Name Number 2955 -------------------------------------- 2956 NONE 0 2957 Defined in Appendix B 1 - 2 2958 RESERVED 3 - 4 2959 Defined in [ADDGROUP] 5 2960 RESERVED TO IANA 6 - 13 2961 Defined in [ADDGROUP] 14 - 18 2962 RESERVED TO IANA 19 - 1023 2963 PRIVATE USE 1024-65535 2965 For Transform Type 5 (Extended Sequence Numbers), defined Transform 2966 IDs are: 2968 Name Number 2969 -------------------------------------------- 2970 No Extended Sequence Numbers 0 2971 Extended Sequence Numbers 1 2972 RESERVED 2 - 65535 2974 3.3.3. Valid Transform Types by Protocol 2976 The number and type of transforms that accompany an SA payload are 2977 dependent on the protocol in the SA itself. An SA payload proposing 2978 the establishment of an SA has the following mandatory and optional 2979 transform types. A compliant implementation MUST understand all 2980 mandatory and optional types for each protocol it supports (though it 2981 need not accept proposals with unacceptable suites). A proposal MAY 2982 omit the optional types if the only value for them it will accept is 2983 NONE. 2985 Protocol Mandatory Types Optional Types 2986 --------------------------------------------------- 2987 IKE ENCR, PRF, INTEG, D-H 2988 ESP ENCR, ESN INTEG, D-H 2989 AH INTEG, ESN D-H 2991 3.3.4. Mandatory Transform IDs 2993 The specification of suites that MUST and SHOULD be supported for 2994 interoperability has been removed from this document because they are 2995 likely to change more rapidly than this document evolves. 2997 An important lesson learned from IKEv1 is that no system should only 2998 implement the mandatory algorithms and expect them to be the best 2999 choice for all customers. For example, at the time that this 3000 document was written, many IKEv1 implementers were starting to 3001 migrate to AES in Cipher Block Chaining (CBC) mode for Virtual 3002 Private Network (VPN) applications. Many IPsec systems based on 3003 IKEv2 will implement AES, additional Diffie-Hellman groups, and 3004 additional hash algorithms, and some IPsec customers already require 3005 these algorithms in addition to the ones listed above. 3007 It is likely that IANA will add additional transforms in the future, 3008 and some users may want to use private suites, especially for IKE 3009 where implementations should be capable of supporting different 3010 parameters, up to certain size limits. In support of this goal, all 3011 implementations of IKEv2 SHOULD include a management facility that 3012 allows specification (by a user or system administrator) of Diffie- 3013 Hellman (DH) parameters (the generator, modulus, and exponent lengths 3014 and values) for new DH groups. Implementations SHOULD provide a 3015 management interface through which these parameters and the 3016 associated transform IDs may be entered (by a user or system 3017 administrator), to enable negotiating such groups. 3019 All implementations of IKEv2 MUST include a management facility that 3020 enables a user or system administrator to specify the suites that are 3021 acceptable for use with IKE. Upon receipt of a payload with a set of 3022 transform IDs, the implementation MUST compare the transmitted 3023 transform IDs against those locally configured via the management 3024 controls, to verify that the proposed suite is acceptable based on 3025 local policy. The implementation MUST reject SA proposals that are 3026 not authorized by these IKE suite controls. Note that cryptographic 3027 suites that MUST be implemented need not be configured as acceptable 3028 to local policy. 3030 3.3.5. Transform Attributes 3032 Each transform in a Security Association payload may include 3033 attributes that modify or complete the specification of the 3034 transform. These attributes are type/value pairs and are defined 3035 below. For example, if an encryption algorithm has a variable-length 3036 key, the key length to be used may be specified as an attribute. 3037 Attributes can have a value with a fixed two octet length or a 3038 variable-length value. For the latter, the attribute is encoded as 3039 type/length/value. 3041 1 2 3 3042 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 3043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3044 !A! Attribute Type ! AF=0 Attribute Length ! 3045 !F! ! AF=1 Attribute Value ! 3046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3047 ! AF=0 Attribute Value ! 3048 ! AF=1 Not Transmitted ! 3049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3051 Figure 9: Data Attributes 3053 o Attribute Type (2 octets) - Unique identifier for each type of 3054 attribute (see below). The most significant bit of this field is 3055 the Attribute Format bit (AF). It indicates whether the data 3056 attributes follow the Type/Length/Value (TLV) format or a 3057 shortened Type/Value (TV) format. If the AF bit is zero (0), then 3058 the Data Attributes are of the Type/Length/Value (TLV) form. If 3059 the AF bit is a one (1), then the Data Attributes are of the Type/ 3060 Value form. 3062 o Attribute Length (2 octets) - Length in octets of the Attribute 3063 Value. When the AF bit is a one (1), the Attribute Value is only 3064 2 octets and the Attribute Length field is not present. 3066 o Attribute Value (variable length) - Value of the Attribute 3067 associated with the Attribute Type. If the AF bit is a zero (0), 3068 this field has a variable length defined by the Attribute Length 3069 field. If the AF bit is a one (1), the Attribute Value has a 3070 length of 2 octets. 3072 o Key Length - When using an Encryption Algorithm that has a 3073 variable-length key, this attribute specifies the key length in 3074 bits (MUST use network byte order). This attribute MUST NOT be 3075 used when the specified Encryption Algorithm uses a fixed-length 3076 key. 3078 Note that only a single attribute type (Key Length) is defined, and 3079 it is fixed length. The variable-length encoding specification is 3080 included only for future extensions. {{ Clarif-7.11 removed the 3081 sentence that listed, incorrectly, the algorithms defined in the 3082 document that accept attributes. }} 3084 Attributes described as basic MUST NOT be encoded using the variable- 3085 length encoding. Variable-length attributes MUST NOT be encoded as 3086 basic even if their value can fit into two octets. NOTE: This is a 3087 change from IKEv1, where increased flexibility may have simplified 3088 the composer of messages but certainly complicated the parser. 3090 Attribute Type Value Attribute Format 3091 ------------------------------------------------------------ 3092 RESERVED 0-13 3093 Key Length (in bits) 14 TV 3094 RESERVED 15-17 3095 RESERVED TO IANA 18-16383 3096 PRIVATE USE 16384-32767 3097 Values 0-13 and 15-17 were used in a similar context in 3098 IKEv1, and should not be assigned except to matching values. 3100 3.3.6. Attribute Negotiation 3102 During security association negotiation initiators present offers to 3103 responders. Responders MUST select a single complete set of 3104 parameters from the offers (or reject all offers if none are 3105 acceptable). If there are multiple proposals, the responder MUST 3106 choose a single proposal number and return all of the Proposal 3107 substructures with that Proposal number. If there are multiple 3108 Transforms with the same type, the responder MUST choose a single 3109 one. Any attributes of a selected transform MUST be returned 3110 unmodified. The initiator of an exchange MUST check that the 3111 accepted offer is consistent with one of its proposals, and if not 3112 that response MUST be rejected. 3114 Negotiating Diffie-Hellman groups presents some special challenges. 3115 SA offers include proposed attributes and a Diffie-Hellman public 3116 number (KE) in the same message. If in the initial exchange the 3117 initiator offers to use one of several Diffie-Hellman groups, it 3118 SHOULD pick the one the responder is most likely to accept and 3119 include a KE corresponding to that group. If the guess turns out to 3120 be wrong, the responder will indicate the correct group in the 3121 response and the initiator SHOULD pick an element of that group for 3122 its KE value when retrying the first message. It SHOULD, however, 3123 continue to propose its full supported set of groups in order to 3124 prevent a man-in-the-middle downgrade attack. 3126 Implementation Note: 3128 Certain negotiable attributes can have ranges or could have multiple 3129 acceptable values. These include the key length of a variable key 3130 length symmetric cipher. To further interoperability and to support 3131 upgrading endpoints independently, implementers of this protocol 3132 SHOULD accept values that they deem to supply greater security. For 3133 instance, if a peer is configured to accept a variable-length cipher 3134 with a key length of X bits and is offered that cipher with a larger 3135 key length, the implementation SHOULD accept the offer if it supports 3136 use of the longer key. 3138 Support of this capability allows an implementation to express a 3139 concept of "at least" a certain level of security-- "a key length of 3140 _at least_ X bits for cipher Y". 3142 3.4. Key Exchange Payload 3144 The Key Exchange Payload, denoted KE in this memo, is used to 3145 exchange Diffie-Hellman public numbers as part of a Diffie-Hellman 3146 key exchange. The Key Exchange Payload consists of the IKE generic 3147 payload header followed by the Diffie-Hellman public value itself. 3149 1 2 3 3150 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 3151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3152 ! Next Payload !C! RESERVED ! Payload Length ! 3153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3154 ! DH Group # ! RESERVED ! 3155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3156 ! ! 3157 ~ Key Exchange Data ~ 3158 ! ! 3159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3161 Figure 10: Key Exchange Payload Format 3163 A key exchange payload is constructed by copying one's Diffie-Hellman 3164 public value into the "Key Exchange Data" portion of the payload. 3165 The length of the Diffie-Hellman public value MUST be equal to the 3166 length of the prime modulus over which the exponentiation was 3167 performed, prepending zero bits to the value if necessary. 3169 The DH Group # identifies the Diffie-Hellman group in which the Key 3170 Exchange Data was computed (see Section 3.3.2). If the selected 3171 proposal uses a different Diffie-Hellman group, the message MUST be 3172 rejected with a Notify payload of type INVALID_KE_PAYLOAD. 3174 The payload type for the Key Exchange payload is thirty four (34). 3176 3.5. Identification Payloads 3178 The Identification Payloads, denoted IDi and IDr in this memo, allow 3179 peers to assert an identity to one another. This identity may be 3180 used for policy lookup, but does not necessarily have to match 3181 anything in the CERT payload; both fields may be used by an 3182 implementation to perform access control decisions. {{ Clarif-7.1 }} 3183 When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr 3184 payloads, IKEv2 does not require this address to match the address in 3185 the IP header of IKEv2 packets, or anything in the TSi/TSr payloads. 3186 The contents of IDi/IDr is used purely to fetch the policy and 3187 authentication data related to the other party. 3189 NOTE: In IKEv1, two ID payloads were used in each direction to hold 3190 Traffic Selector (TS) information for data passing over the SA. In 3191 IKEv2, this information is carried in TS payloads (see Section 3.13). 3193 The Identification Payload consists of the IKE generic payload header 3194 followed by identification fields as follows: 3196 1 2 3 3197 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 3198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3199 ! Next Payload !C! RESERVED ! Payload Length ! 3200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3201 ! ID Type ! RESERVED | 3202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3203 ! ! 3204 ~ Identification Data ~ 3205 ! ! 3206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3208 Figure 11: Identification Payload Format 3210 o ID Type (1 octet) - Specifies the type of Identification being 3211 used. 3213 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 3215 o Identification Data (variable length) - Value, as indicated by the 3216 Identification Type. The length of the Identification Data is 3217 computed from the size in the ID payload header. 3219 The payload types for the Identification Payload are thirty five (35) 3220 for IDi and thirty six (36) for IDr. 3222 The following table lists the assigned values for the Identification 3223 Type field: 3225 ID Type Value 3226 ------------------------------------------------------------------- 3227 RESERVED 0 3229 ID_IPV4_ADDR 1 3230 A single four (4) octet IPv4 address. 3232 ID_FQDN 2 3233 A fully-qualified domain name string. An example of a ID_FQDN 3234 is, "example.com". The string MUST not contain any terminators 3235 (e.g., NULL, CR, etc.). 3237 ID_RFC822_ADDR 3 3238 A fully-qualified RFC822 email address string, An example of a 3239 ID_RFC822_ADDR is, "jsmith@example.com". The string MUST not 3240 contain any terminators. 3242 RESERVED TO IANA 4 3244 ID_IPV6_ADDR 5 3245 A single sixteen (16) octet IPv6 address. 3247 RESERVED TO IANA 6 - 8 3249 ID_DER_ASN1_DN 9 3250 The binary Distinguished Encoding Rules (DER) encoding of an 3251 ASN.1 X.500 Distinguished Name [X.501]. 3253 ID_DER_ASN1_GN 10 3254 The binary DER encoding of an ASN.1 X.500 GeneralName [X.509]. 3256 ID_KEY_ID 11 3257 An opaque octet stream which may be used to pass vendor- 3258 specific information necessary to do certain proprietary 3259 types of identification. 3261 RESERVED TO IANA 12-200 3263 PRIVATE USE 201-255 3265 Two implementations will interoperate only if each can generate a 3266 type of ID acceptable to the other. To assure maximum 3267 interoperability, implementations MUST be configurable to send at 3268 least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and 3269 MUST be configurable to accept all of these types. Implementations 3270 SHOULD be capable of generating and accepting all of these types. 3271 IPv6-capable implementations MUST additionally be configurable to 3272 accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable 3273 to send only ID_IPV6_ADDR. 3275 {{ Clarif-3.4 }} EAP [EAP] does not mandate the use of any particular 3276 type of identifier, but often EAP is used with Network Access 3277 Identifiers (NAIs) defined in [NAI]. Although NAIs look a bit like 3278 email addresses (e.g., "joe@example.com"), the syntax is not exactly 3279 the same as the syntax of email address in [MAILFORMAT]. For those 3280 NAIs that include the realm component, the ID_RFC822_ADDR 3281 identification type SHOULD be used. Responder implementations should 3282 not attempt to verify that the contents actually conform to the exact 3283 syntax given in [MAILFORMAT], but instead should accept any 3284 reasonable-looking NAI. For NAIs that do not include the realm 3285 component,the ID_KEY_ID identification type SHOULD be used. 3287 3.6. Certificate Payload 3289 The Certificate Payload, denoted CERT in this memo, provides a means 3290 to transport certificates or other authentication-related information 3291 via IKE. Certificate payloads SHOULD be included in an exchange if 3292 certificates are available to the sender unless the peer has 3293 indicated an ability to retrieve this information from elsewhere 3294 using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note that the 3295 term "Certificate Payload" is somewhat misleading, because not all 3296 authentication mechanisms use certificates and data other than 3297 certificates may be passed in this payload. 3299 The Certificate Payload is defined as follows: 3301 1 2 3 3302 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 3303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3304 ! Next Payload !C! RESERVED ! Payload Length ! 3305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3306 ! Cert Encoding ! ! 3307 +-+-+-+-+-+-+-+-+ ! 3308 ~ Certificate Data ~ 3309 ! ! 3310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3312 Figure 12: Certificate Payload Format 3314 o Certificate Encoding (1 octet) - This field indicates the type of 3315 certificate or certificate-related information contained in the 3316 Certificate Data field. 3318 Certificate Encoding Value 3319 ------------------------------------------------- 3320 RESERVED 0 3321 PKCS #7 wrapped X.509 certificate 1 3322 PGP Certificate 2 3323 DNS Signed Key 3 3324 X.509 Certificate - Signature 4 3325 Kerberos Token 6 3326 Certificate Revocation List (CRL) 7 3327 Authority Revocation List (ARL) 8 3328 SPKI Certificate 9 3329 X.509 Certificate - Attribute 10 3330 Raw RSA Key 11 3331 Hash and URL of X.509 certificate 12 3332 Hash and URL of X.509 bundle 13 3333 RESERVED to IANA 14 - 200 3334 PRIVATE USE 201 - 255 3336 o Certificate Data (variable length) - Actual encoding of 3337 certificate data. The type of certificate is indicated by the 3338 Certificate Encoding field. 3340 The payload type for the Certificate Payload is thirty seven (37). 3342 Specific syntax is for some of the certificate type codes above is 3343 not defined in this document. The types whose syntax is defined in 3344 this document are: 3346 o X.509 Certificate - Signature (4) contains a DER encoded X.509 3347 certificate whose public key is used to validate the sender's AUTH 3348 payload. 3350 o Certificate Revocation List (7) contains a DER encoded X.509 3351 certificate revocation list. 3353 o {{ Added "DER-encoded RSAPublicKey structure" from Clarif-3.7 }} 3354 Raw RSA Key (11) contains a PKCS #1 encoded RSA key, that is, a 3355 DER-encoded RSAPublicKey structure (see [RSA] and [PKCS1]). 3357 o Hash and URL encodings (12-13) allow IKE messages to remain short 3358 by replacing long data structures with a 20 octet SHA-1 hash (see 3359 [SHA]) of the replaced value followed by a variable-length URL 3360 that resolves to the DER encoded data structure itself. This 3361 improves efficiency when the endpoints have certificate data 3362 cached and makes IKE less subject to denial of service attacks 3363 that become easier to mount when IKE messages are large enough to 3364 require IP fragmentation [DOSUDPPROT]. 3366 Use the following ASN.1 definition for an X.509 bundle: 3368 CertBundle 3369 { iso(1) identified-organization(3) dod(6) internet(1) 3370 security(5) mechanisms(5) pkix(7) id-mod(0) 3371 id-mod-cert-bundle(34) } 3373 DEFINITIONS EXPLICIT TAGS ::= 3374 BEGIN 3376 IMPORTS 3377 Certificate, CertificateList 3378 FROM PKIX1Explicit88 3379 { iso(1) identified-organization(3) dod(6) 3380 internet(1) security(5) mechanisms(5) pkix(7) 3381 id-mod(0) id-pkix1-explicit(18) } ; 3383 CertificateOrCRL ::= CHOICE { 3384 cert [0] Certificate, 3385 crl [1] CertificateList } 3387 CertificateBundle ::= SEQUENCE OF CertificateOrCRL 3389 END 3391 Implementations MUST be capable of being configured to send and 3392 accept up to four X.509 certificates in support of authentication, 3393 and also MUST be capable of being configured to send and accept the 3394 first two Hash and URL formats (with HTTP URLs). Implementations 3395 SHOULD be capable of being configured to send and accept Raw RSA 3396 keys. If multiple certificates are sent, the first certificate MUST 3397 contain the public key used to sign the AUTH payload. The other 3398 certificates may be sent in any order. 3400 {{ Clarif-3.7 }} Because the contents and use of some of the 3401 certificate types are not defined, they SHOULD NOT be used. In 3402 specific, implementations SHOULD NOT use the following types unless 3403 they are later defined in a standards-track document: 3405 PKCS #7 wrapped X.509 certificate 1 3406 PGP Certificate 2 3407 DNS Signed Key 3 3408 Kerberos Token 6 3409 SPKI Certificate 9 3411 3.7. Certificate Request Payload 3413 The Certificate Request Payload, denoted CERTREQ in this memo, 3414 provides a means to request preferred certificates via IKE and can 3415 appear in the IKE_INIT_SA response and/or the IKE_AUTH request. 3416 Certificate Request payloads MAY be included in an exchange when the 3417 sender needs to get the certificate of the receiver. If multiple CAs 3418 are trusted and the cert encoding does not allow a list, then 3419 multiple Certificate Request payloads SHOULD be transmitted. 3421 The Certificate Request Payload is defined as follows: 3423 1 2 3 3424 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 3425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3426 ! Next Payload !C! RESERVED ! Payload Length ! 3427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3428 ! Cert Encoding ! ! 3429 +-+-+-+-+-+-+-+-+ ! 3430 ~ Certification Authority ~ 3431 ! ! 3432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3434 Figure 13: Certificate Request Payload Format 3436 o Certificate Encoding (1 octet) - Contains an encoding of the type 3437 or format of certificate requested. Values are listed in 3438 Section 3.6. 3440 o Certification Authority (variable length) - Contains an encoding 3441 of an acceptable certification authority for the type of 3442 certificate requested. 3444 The payload type for the Certificate Request Payload is thirty eight 3445 (38). 3447 The Certificate Encoding field has the same values as those defined 3448 in Section 3.6. The Certification Authority field contains an 3449 indicator of trusted authorities for this certificate type. The 3450 Certification Authority value is a concatenated list of SHA-1 hashes 3451 of the public keys of trusted Certification Authorities (CAs). Each 3452 is encoded as the SHA-1 hash of the Subject Public Key Info element 3453 (see section 4.1.2.7 of [PKIX]) from each Trust Anchor certificate. 3454 The twenty-octet hashes are concatenated and included with no other 3455 formatting. 3457 {{ Clarif-3.7 }} The contents of the "Certification Authority" field 3458 are defined only for X.509 certificates, which are types 4, 10, 12, 3459 and 13. Other values SHOULD NOT be used until standards-track 3460 specifications that specify their use are published. 3462 Note that the term "Certificate Request" is somewhat misleading, in 3463 that values other than certificates are defined in a "Certificate" 3464 payload and requests for those values can be present in a Certificate 3465 Request Payload. The syntax of the Certificate Request payload in 3466 such cases is not defined in this document. 3468 The Certificate Request Payload is processed by inspecting the "Cert 3469 Encoding" field to determine whether the processor has any 3470 certificates of this type. If so, the "Certification Authority" 3471 field is inspected to determine if the processor has any certificates 3472 that can be validated up to one of the specified certification 3473 authorities. This can be a chain of certificates. 3475 If an end-entity certificate exists that satisfies the criteria 3476 specified in the CERTREQ, a certificate or certificate chain SHOULD 3477 be sent back to the certificate requestor if the recipient of the 3478 CERTREQ: 3480 o is configured to use certificate authentication, 3482 o is allowed to send a CERT payload, 3484 o has matching CA trust policy governing the current negotiation, 3485 and 3487 o has at least one time-wise and usage appropriate end-entity 3488 certificate chaining to a CA provided in the CERTREQ. 3490 Certificate revocation checking must be considered during the 3491 chaining process used to select a certificate. Note that even if two 3492 peers are configured to use two different CAs, cross-certification 3493 relationships should be supported by appropriate selection logic. 3495 The intent is not to prevent communication through the strict 3496 adherence of selection of a certificate based on CERTREQ, when an 3497 alternate certificate could be selected by the sender that would 3498 still enable the recipient to successfully validate and trust it 3499 through trust conveyed by cross-certification, CRLs, or other out-of- 3500 band configured means. Thus, the processing of a CERTREQ should be 3501 seen as a suggestion for a certificate to select, not a mandated one. 3502 If no certificates exist, then the CERTREQ is ignored. This is not 3503 an error condition of the protocol. There may be cases where there 3504 is a preferred CA sent in the CERTREQ, but an alternate might be 3505 acceptable (perhaps after prompting a human operator). 3507 3.8. Authentication Payload 3509 The Authentication Payload, denoted AUTH in this memo, contains data 3510 used for authentication purposes. The syntax of the Authentication 3511 data varies according to the Auth Method as specified below. 3513 The Authentication Payload is defined as follows: 3515 1 2 3 3516 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 3517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3518 ! Next Payload !C! RESERVED ! Payload Length ! 3519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3520 ! Auth Method ! RESERVED ! 3521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3522 ! ! 3523 ~ Authentication Data ~ 3524 ! ! 3525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3527 Figure 14: Authentication Payload Format 3529 o Auth Method (1 octet) - Specifies the method of authentication 3530 used. Values defined are: 3532 * RSA Digital Signature (1) - Computed as specified in 3533 Section 2.15 using an RSA private key over a PKCS#1 padded hash 3534 (see [RSA] and [PKCS1]). {{ Clarif-3.2 }} To promote 3535 interoperability, implementations that support this type SHOULD 3536 support signatures that use SHA-1 as the hash function and 3537 SHOULD use SHA-1 as the default hash function when generating 3538 signatures. {{ Clarif-3.3 }} A newer version of PKCS#1 (v2.1) 3539 defines two different encoding methods (ways of "padding the 3540 hash") for signatures. However, IKEv2 and this document point 3541 specifically to the PKCS#1 v2.0 which has only one encoding 3542 method for signatures (EMSA-PKCS1- v1_5). 3544 * Shared Key Message Integrity Code (2) - Computed as specified 3545 in Section 2.15 using the shared key associated with the 3546 identity in the ID payload and the negotiated prf function 3548 * DSS Digital Signature (3) - Computed as specified in 3549 Section 2.15 using a DSS private key (see [DSS]) over a SHA-1 3550 hash. 3552 * The values 0 and 4-200 are reserved to IANA. The values 201- 3553 255 are available for private use. 3555 o Authentication Data (variable length) - see Section 2.15. 3557 The payload type for the Authentication Payload is thirty nine (39). 3559 3.9. Nonce Payload 3561 The Nonce Payload, denoted Ni and Nr in this memo for the initiator's 3562 and responder's nonce respectively, contains random data used to 3563 guarantee liveness during an exchange and protect against replay 3564 attacks. 3566 The Nonce Payload is defined as follows: 3568 1 2 3 3569 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 3570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3571 ! Next Payload !C! RESERVED ! Payload Length ! 3572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3573 ! ! 3574 ~ Nonce Data ~ 3575 ! ! 3576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3578 Figure 15: Nonce Payload Format 3580 o Nonce Data (variable length) - Contains the random data generated 3581 by the transmitting entity. 3583 The payload type for the Nonce Payload is forty (40). 3585 The size of a Nonce MUST be between 16 and 256 octets inclusive. 3586 Nonce values MUST NOT be reused. 3588 3.10. Notify Payload 3590 The Notify Payload, denoted N in this document, is used to transmit 3591 informational data, such as error conditions and state transitions, 3592 to an IKE peer. A Notify Payload may appear in a response message 3593 (usually specifying why a request was rejected), in an INFORMATIONAL 3594 Exchange (to report an error not in an IKE request), or in any other 3595 message to indicate sender capabilities or to modify the meaning of 3596 the request. 3598 The Notify Payload is defined as follows: 3600 1 2 3 3601 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 3602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3603 ! Next Payload !C! RESERVED ! Payload Length ! 3604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3605 ! Protocol ID ! SPI Size ! Notify Message Type ! 3606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3607 ! ! 3608 ~ Security Parameter Index (SPI) ~ 3609 ! ! 3610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3611 ! ! 3612 ~ Notification Data ~ 3613 ! ! 3614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3616 Figure 16: Notify Payload Format 3618 o Protocol ID (1 octet) - If this notification concerns an existing 3619 SA, this field indicates the type of that SA. For IKE_SA 3620 notifications, this field MUST be one (1). For notifications 3621 concerning IPsec SAs this field MUST contain either (2) to 3622 indicate AH or (3) to indicate ESP. {{ Clarif-7.8 }} For 3623 notifications that do not relate to an existing SA, this field 3624 MUST be sent as zero and MUST be ignored on receipt; this is only 3625 true for the INVALID_SELECTORS and REKEY_SA notifications. . All 3626 other values for this field are reserved to IANA for future 3627 assignment. 3629 o SPI Size (1 octet) - Length in octets of the SPI as defined by the 3630 IPsec protocol ID or zero if no SPI is applicable. For a 3631 notification concerning the IKE_SA, the SPI Size MUST be zero. 3633 o Notify Message Type (2 octets) - Specifies the type of 3634 notification message. 3636 o SPI (variable length) - Security Parameter Index. 3638 o Notification Data (variable length) - Informational or error data 3639 transmitted in addition to the Notify Message Type. Values for 3640 this field are type specific (see below). 3642 The payload type for the Notify Payload is forty one (41). 3644 3.10.1. Notify Message Types 3646 Notification information can be error messages specifying why an SA 3647 could not be established. It can also be status data that a process 3648 managing an SA database wishes to communicate with a peer process. 3649 The table below lists the Notification messages and their 3650 corresponding values. The number of different error statuses was 3651 greatly reduced from IKEv1 both for simplification and to avoid 3652 giving configuration information to probers. 3654 Types in the range 0 - 16383 are intended for reporting errors. An 3655 implementation receiving a Notify payload with one of these types 3656 that it does not recognize in a response MUST assume that the 3657 corresponding request has failed entirely. {{ Demoted the SHOULD }} 3658 Unrecognized error types in a request and status types in a request 3659 or response MUST be ignored, and they should be logged. 3661 Notify payloads with status types MAY be added to any message and 3662 MUST be ignored if not recognized. They are intended to indicate 3663 capabilities, and as part of SA negotiation are used to negotiate 3664 non-cryptographic parameters. 3666 NOTIFY messages: error types Value 3667 ------------------------------------------------------------------- 3669 RESERVED 0 3671 UNSUPPORTED_CRITICAL_PAYLOAD 1 3672 Sent if the payload has the "critical" bit set and the payload 3673 type is not recognized. Notification Data contains the one-octet 3674 payload type. 3676 INVALID_IKE_SPI 4 3677 Indicates an IKE message was received with an unrecognized 3678 destination SPI. This usually indicates that the recipient has 3679 rebooted and forgotten the existence of an IKE_SA. 3681 INVALID_MAJOR_VERSION 5 3682 Indicates the recipient cannot handle the version of IKE 3683 specified in the header. The closest version number that the 3684 recipient can support will be in the reply header. 3686 INVALID_SYNTAX 7 3687 Indicates the IKE message that was received was invalid because 3688 some type, length, or value was out of range or because the 3689 request was rejected for policy reasons. To avoid a denial of 3690 service attack using forged messages, this status may only be 3691 returned for and in an encrypted packet if the message ID and 3692 cryptographic checksum were valid. To avoid leaking information 3693 to someone probing a node, this status MUST be sent in response 3694 to any error not covered by one of the other status types. 3695 {{ Demoted the SHOULD }} To aid debugging, more detailed error 3696 information should be written to a console or log. 3698 INVALID_MESSAGE_ID 9 3699 Sent when an IKE message ID outside the supported window is 3700 received. This Notify MUST NOT be sent in a response; the invalid 3701 request MUST NOT be acknowledged. Instead, inform the other side 3702 by initiating an INFORMATIONAL exchange with Notification data 3703 containing the four octet invalid message ID. Sending this 3704 notification is optional, and notifications of this type MUST be 3705 rate limited. 3707 INVALID_SPI 11 3708 MAY be sent in an IKE INFORMATIONAL exchange when a node receives 3709 an ESP or AH packet with an invalid SPI. The Notification Data 3710 contains the SPI of the invalid packet. This usually indicates a 3711 node has rebooted and forgotten an SA. If this Informational 3712 Message is sent outside the context of an IKE_SA, it should only 3713 be used by the recipient as a "hint" that something might be 3714 wrong (because it could easily be forged). 3716 NO_PROPOSAL_CHOSEN 14 3717 None of the proposed crypto suites was acceptable. 3719 INVALID_KE_PAYLOAD 17 3720 The D-H Group # field in the KE payload is not the group # 3721 selected by the responder for this exchange. There are two octets 3722 of data associated with this notification: the accepted D-H Group 3723 # in big endian order. 3725 AUTHENTICATION_FAILED 24 3726 Sent in the response to an IKE_AUTH message when for some reason 3727 the authentication failed. There is no associated data. 3729 SINGLE_PAIR_REQUIRED 34 3730 This error indicates that a CREATE_CHILD_SA request is 3731 unacceptable because its sender is only willing to accept traffic 3732 selectors specifying a single pair of addresses. The requestor is 3733 expected to respond by requesting an SA for only the specific 3734 traffic it is trying to forward. 3736 NO_ADDITIONAL_SAS 35 3737 This error indicates that a CREATE_CHILD_SA request is 3738 unacceptable because the responder is unwilling to accept any 3739 more CHILD_SAs on this IKE_SA. Some minimal implementations may 3740 only accept a single CHILD_SA setup in the context of an initial 3741 IKE exchange and reject any subsequent attempts to add more. 3743 INTERNAL_ADDRESS_FAILURE 36 3744 Indicates an error assigning an internal address (i.e., 3745 INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS) during the 3746 processing of a Configuration Payload by a responder. If this 3747 error is generated within an IKE_AUTH exchange, no CHILD_SA will 3748 be created. 3750 FAILED_CP_REQUIRED 37 3751 Sent by responder in the case where CP(CFG_REQUEST) was expected 3752 but not received, and so is a conflict with locally configured 3753 policy. There is no associated data. 3755 TS_UNACCEPTABLE 38 3756 Indicates that none of the addresses/protocols/ports in the 3757 supplied traffic selectors is acceptable. 3759 INVALID_SELECTORS 39 3760 MAY be sent in an IKE INFORMATIONAL exchange when a node receives 3761 an ESP or AH packet whose selectors do not match those of the SA 3762 on which it was delivered (and that caused the packet to be 3763 dropped). The Notification Data contains the start of the 3764 offending packet (as in ICMP messages) and the SPI field of the 3765 notification is set to match the SPI of the IPsec SA. 3767 RESERVED TO IANA 40-8191 3769 PRIVATE USE 8192-16383 3771 NOTIFY messages: status types Value 3772 ------------------------------------------------------------------- 3774 INITIAL_CONTACT 16384 3775 This notification asserts that this IKE_SA is the only IKE_SA 3776 currently active between the authenticated identities. It MAY be 3777 sent when an IKE_SA is established after a crash, and the 3778 recipient MAY use this information to delete any other IKE_SAs it 3779 has to the same authenticated identity without waiting for a 3780 timeout. This notification MUST NOT be sent by an entity that may 3781 be replicated (e.g., a roaming user's credentials where the user 3782 is allowed to connect to the corporate firewall from two remote 3783 systems at the same time). {{ Clarif-7.9 }} The INITIAL_CONTACT 3784 notification, if sent, MUST be in the first IKE_AUTH request, 3785 not as a separate exchange afterwards. 3787 SET_WINDOW_SIZE 16385 3788 This notification asserts that the sending endpoint is capable of 3789 keeping state for multiple outstanding exchanges, permitting the 3790 recipient to send multiple requests before getting a response to 3791 the first. The data associated with a SET_WINDOW_SIZE 3792 notification MUST be 4 octets long and contain the big endian 3793 representation of the number of messages the sender promises to 3794 keep. Window size is always one until the initial exchanges 3795 complete. 3797 ADDITIONAL_TS_POSSIBLE 16386 3798 This notification asserts that the sending endpoint narrowed the 3799 proposed traffic selectors but that other traffic selectors would 3800 also have been acceptable, though only in a separate SA (see 3801 section 2.9). There is no data associated with this Notify type. 3802 It may be sent only as an additional payload in a message 3803 including accepted TSs. 3805 IPCOMP_SUPPORTED 16387 3806 This notification may be included only in a message containing an 3807 SA payload negotiating a CHILD_SA and indicates a willingness by 3808 its sender to use IPComp on this SA. The data associated with 3809 this notification includes a two-octet IPComp CPI followed by a 3810 one-octet transform ID optionally followed by attributes whose 3811 length and format are defined by that transform ID. A message 3812 proposing an SA may contain multiple IPCOMP_SUPPORTED 3813 notifications to indicate multiple supported algorithms. A 3814 message accepting an SA may contain at most one. 3816 The transform IDs currently defined are: 3818 Name Number Defined In 3819 ------------------------------------- 3820 RESERVED 0 3821 IPCOMP_OUI 1 3822 IPCOMP_DEFLATE 2 RFC 2394 3823 IPCOMP_LZS 3 RFC 2395 3824 IPCOMP_LZJH 4 RFC 3051 3825 RESERVED TO IANA 5-240 3826 PRIVATE USE 241-255 3828 NAT_DETECTION_SOURCE_IP 16388 3829 This notification is used by its recipient to determine whether 3830 the source is behind a NAT box. The data associated with this 3831 notification is a SHA-1 digest of the SPIs (in the order they 3832 appear in the header), IP address, and port on which this packet 3833 was sent. There MAY be multiple Notify payloads of this type in a 3834 message if the sender does not know which of several network 3835 attachments will be used to send the packet. The recipient of 3836 this notification MAY compare the supplied value to a SHA-1 hash 3837 of the SPIs, source IP address, and port, and if they don't match 3838 it SHOULD enable NAT traversal (see section 2.23). Alternately, 3839 it MAY reject the connection attempt if NAT traversal is not 3840 supported. 3842 NAT_DETECTION_DESTINATION_IP 16389 3843 This notification is used by its recipient to determine whether 3844 it is behind a NAT box. The data associated with this 3845 notification is a SHA-1 digest of the SPIs (in the order they 3846 appear in the header), IP address, and port to which this packet 3847 was sent. The recipient of this notification MAY compare the 3848 supplied value to a hash of the SPIs, destination IP address, and 3849 port, and if they don't match it SHOULD invoke NAT traversal (see 3850 section 2.23). If they don't match, it means that this end is 3851 behind a NAT and this end SHOULD start sending keepalive packets 3852 as defined in [UDPENCAPS]. Alternately, it MAY reject the 3853 connection attempt if NAT traversal is not supported. 3855 COOKIE 16390 3856 This notification MAY be included in an IKE_SA_INIT response. It 3857 indicates that the request should be retried with a copy of this 3858 notification as the first payload. This notification MUST be 3859 included in an IKE_SA_INIT request retry if a COOKIE notification 3860 was included in the initial response. The data associated with 3861 this notification MUST be between 1 and 64 octets in length 3862 (inclusive). 3864 USE_TRANSPORT_MODE 16391 3865 This notification MAY be included in a request message that also 3866 includes an SA payload requesting a CHILD_SA. It requests that 3867 the CHILD_SA use transport mode rather than tunnel mode for the 3868 SA created. If the request is accepted, the response MUST also 3869 include a notification of type USE_TRANSPORT_MODE. If the 3870 responder declines the request, the CHILD_SA will be established 3871 in tunnel mode. If this is unacceptable to the initiator, the 3872 initiator MUST delete the SA. Note: Except when using this option 3873 to negotiate transport mode, all CHILD_SAs will use tunnel mode. 3875 Note: The ECN decapsulation modifications specified in 3876 [IPSECARCH] MUST be performed for every tunnel mode SA created 3877 by IKEv2. 3879 HTTP_CERT_LOOKUP_SUPPORTED 16392 3880 This notification MAY be included in any message that can include 3881 a CERTREQ payload and indicates that the sender is capable of 3882 looking up certificates based on an HTTP-based URL (and hence 3883 presumably would prefer to receive certificate specifications in 3884 that format). 3886 REKEY_SA 16393 3887 This notification MUST be included in a CREATE_CHILD_SA exchange 3888 if the purpose of the exchange is to replace an existing ESP or 3889 AH SA. The SPI field identifies the SA being rekeyed. 3890 {{ Clarif-5.4 }} The SPI placed in the REKEY_SA 3891 notification is the SPI the exchange initiator would expect in 3892 inbound ESP or AH packets. There is no data. 3894 ESP_TFC_PADDING_NOT_SUPPORTED 16394 3895 This notification asserts that the sending endpoint will NOT 3896 accept packets that contain Flow Confidentiality (TFC) padding. 3897 {{ Clarif-4.5 }} The scope of this message is a single 3898 CHILD_SA, and thus this notification is included in messages 3899 containing an SA payload negotiating a CHILD_SA. If neither 3900 endpoint accepts TFC padding, this notification SHOULD be 3901 included in both the request proposing an SA and the response 3902 accepting it. If this notification is included in only one of 3903 the messages, TFC padding can still be sent in the other 3904 direction. 3906 NON_FIRST_FRAGMENTS_ALSO 16395 3907 Used for fragmentation control. See [IPSECARCH] for explanation. 3908 {{ Clarif-4.6 }} Sending non-first fragments is 3909 enabled only if NON_FIRST_FRAGMENTS_ALSO notification is 3910 included in both the request proposing an SA and the response 3911 accepting it. If the peer rejects this proposal, the peer only 3912 omits NON_FIRST_FRAGMENTS_ALSO notification from the response, 3913 but does not reject the whole CHILD_SA creation. 3915 RESERVED TO IANA 16396-40959 3917 PRIVATE USE 40960-65535 3919 3.11. Delete Payload 3921 The Delete Payload, denoted D in this memo, contains a protocol 3922 specific security association identifier that the sender has removed 3923 from its security association database and is, therefore, no longer 3924 valid. Figure 17 shows the format of the Delete Payload. It is 3925 possible to send multiple SPIs in a Delete payload; however, each SPI 3926 MUST be for the same protocol. Mixing of protocol identifiers MUST 3927 NOT be performed in the Delete payload. It is permitted, however, to 3928 include multiple Delete payloads in a single INFORMATIONAL exchange 3929 where each Delete payload lists SPIs for a different protocol. 3931 Deletion of the IKE_SA is indicated by a protocol ID of 1 (IKE) but 3932 no SPIs. Deletion of a CHILD_SA, such as ESP or AH, will contain the 3933 IPsec protocol ID of that protocol (2 for AH, 3 for ESP), and the SPI 3934 is the SPI the sending endpoint would expect in inbound ESP or AH 3935 packets. 3937 The Delete Payload is defined as follows: 3939 1 2 3 3940 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 3941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3942 ! Next Payload !C! RESERVED ! Payload Length ! 3943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3944 ! Protocol ID ! SPI Size ! # of SPIs ! 3945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3946 ! ! 3947 ~ Security Parameter Index(es) (SPI) ~ 3948 ! ! 3949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3951 Figure 17: Delete Payload Format 3953 o Protocol ID (1 octet) - Must be 1 for an IKE_SA, 2 for AH, or 3 3954 for ESP. 3956 o SPI Size (1 octet) - Length in octets of the SPI as defined by the 3957 protocol ID. It MUST be zero for IKE (SPI is in message header) 3958 or four for AH and ESP. 3960 o # of SPIs (2 octets) - The number of SPIs contained in the Delete 3961 payload. The size of each SPI is defined by the SPI Size field. 3963 o Security Parameter Index(es) (variable length) - Identifies the 3964 specific security association(s) to delete. The length of this 3965 field is determined by the SPI Size and # of SPIs fields. 3967 The payload type for the Delete Payload is forty two (42). 3969 3.12. Vendor ID Payload 3971 The Vendor ID Payload, denoted V in this memo, contains a vendor 3972 defined constant. The constant is used by vendors to identify and 3973 recognize remote instances of their implementations. This mechanism 3974 allows a vendor to experiment with new features while maintaining 3975 backward compatibility. 3977 A Vendor ID payload MAY announce that the sender is capable to 3978 accepting certain extensions to the protocol, or it MAY simply 3979 identify the implementation as an aid in debugging. A Vendor ID 3980 payload MUST NOT change the interpretation of any information defined 3981 in this specification (i.e., the critical bit MUST be set to 0). 3982 Multiple Vendor ID payloads MAY be sent. An implementation is NOT 3983 REQUIRED to send any Vendor ID payload at all. 3985 A Vendor ID payload may be sent as part of any message. Reception of 3986 a familiar Vendor ID payload allows an implementation to make use of 3987 Private USE numbers described throughout this memo-- private 3988 payloads, private exchanges, private notifications, etc. Unfamiliar 3989 Vendor IDs MUST be ignored. 3991 Writers of Internet-Drafts who wish to extend this protocol MUST 3992 define a Vendor ID payload to announce the ability to implement the 3993 extension in the Internet-Draft. It is expected that Internet-Drafts 3994 that gain acceptance and are standardized will be given "magic 3995 numbers" out of the Future Use range by IANA, and the requirement to 3996 use a Vendor ID will go away. 3998 The Vendor ID Payload fields are defined as follows: 4000 1 2 3 4001 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 4002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4003 ! Next Payload !C! RESERVED ! Payload Length ! 4004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4005 ! ! 4006 ~ Vendor ID (VID) ~ 4007 ! ! 4008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4010 Figure 18: Vendor ID Payload Format 4012 o Vendor ID (variable length) - It is the responsibility of the 4013 person choosing the Vendor ID to assure its uniqueness in spite of 4014 the absence of any central registry for IDs. Good practice is to 4015 include a company name, a person name, or some such. If you want 4016 to show off, you might include the latitude and longitude and time 4017 where you were when you chose the ID and some random input. A 4018 message digest of a long unique string is preferable to the long 4019 unique string itself. 4021 The payload type for the Vendor ID Payload is forty three (43). 4023 3.13. Traffic Selector Payload 4025 The Traffic Selector Payload, denoted TS in this memo, allows peers 4026 to identify packet flows for processing by IPsec security services. 4027 The Traffic Selector Payload consists of the IKE generic payload 4028 header followed by individual traffic selectors as follows: 4030 1 2 3 4031 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 4032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4033 ! Next Payload !C! RESERVED ! Payload Length ! 4034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4035 ! Number of TSs ! RESERVED ! 4036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4037 ! ! 4038 ~ ~ 4039 ! ! 4040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4042 Figure 19: Traffic Selectors Payload Format 4044 o Number of TSs (1 octet) - Number of traffic selectors being 4045 provided. 4047 o RESERVED - This field MUST be sent as zero and MUST be ignored on 4048 receipt. 4050 o Traffic Selectors (variable length) - One or more individual 4051 traffic selectors. 4053 The length of the Traffic Selector payload includes the TS header and 4054 all the traffic selectors. 4056 The payload type for the Traffic Selector payload is forty four (44) 4057 for addresses at the initiator's end of the SA and forty five (45) 4058 for addresses at the responder's end. 4060 {{ Clarif-4.7 }} There is no requirement that TSi and TSr contain the 4061 same number of individual traffic selectors. Thus, they are 4062 interpreted as follows: a packet matches a given TSi/TSr if it 4063 matches at least one of the individual selectors in TSi, and at least 4064 one of the individual selectors in TSr. 4066 For instance, the following traffic selectors: 4068 TSi = ((17, 100, 192.0.1.66-192.0.1.66), 4069 (17, 200, 192.0.1.66-192.0.1.66)) 4070 TSr = ((17, 300, 0.0.0.0-255.255.255.255), 4071 (17, 400, 0.0.0.0-255.255.255.255)) 4073 would match UDP packets from 192.0.1.66 to anywhere, with any of the 4074 four combinations of source/destination ports (100,300), (100,400), 4075 (200,300), and (200, 400). 4077 Thus, some types of policies may require several CHILD_SA pairs. For 4078 instance, a policy matching only source/destination ports (100,300) 4079 and (200,400), but not the other two combinations, cannot be 4080 negotiated as a single CHILD_SA pair. 4082 3.13.1. Traffic Selector 4084 1 2 3 4085 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 4086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4087 ! TS Type !IP Protocol ID*| Selector Length | 4088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4089 | Start Port* | End Port* | 4090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4091 ! ! 4092 ~ Starting Address* ~ 4093 ! ! 4094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4095 ! ! 4096 ~ Ending Address* ~ 4097 ! ! 4098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4100 Figure 20: Traffic Selector 4102 *Note: All fields other than TS Type and Selector Length depend on 4103 the TS Type. The fields shown are for TS Types 7 and 8, the only two 4104 values currently defined. 4106 o TS Type (one octet) - Specifies the type of traffic selector. 4108 o IP protocol ID (1 octet) - Value specifying an associated IP 4109 protocol ID (e.g., UDP/TCP/ICMP). A value of zero means that the 4110 protocol ID is not relevant to this traffic selector-- the SA can 4111 carry all protocols. 4113 o Selector Length - Specifies the length of this Traffic Selector 4114 Substructure including the header. 4116 o Start Port (2 octets) - Value specifying the smallest port number 4117 allowed by this Traffic Selector. For protocols for which port is 4118 undefined, or if all ports are allowed, this field MUST be zero. 4119 For the ICMP protocol, the two one-octet fields Type and Code are 4120 treated as a single 16-bit integer (with Type in the most 4121 significant eight bits and Code in the least significant eight 4122 bits) port number for the purposes of filtering based on this 4123 field. 4125 o End Port (2 octets) - Value specifying the largest port number 4126 allowed by this Traffic Selector. For protocols for which port is 4127 undefined, or if all ports are allowed, this field MUST be 65535. 4128 For the ICMP protocol, the two one-octet fields Type and Code are 4129 treated as a single 16-bit integer (with Type in the most 4130 significant eight bits and Code in the least significant eight 4131 bits) port number for the purposed of filtering based on this 4132 field. 4134 o Starting Address - The smallest address included in this Traffic 4135 Selector (length determined by TS type). 4137 o Ending Address - The largest address included in this Traffic 4138 Selector (length determined by TS type). 4140 Systems that are complying with [IPSECARCH] that wish to indicate 4141 "ANY" ports MUST set the start port to 0 and the end port to 65535; 4142 note that according to [IPSECARCH], "ANY" includes "OPAQUE". Systems 4143 working with [IPSECARCH] that wish to indicate "OPAQUE" ports, but 4144 not "ANY" ports, MUST set the start port to 65535 and the end port to 4145 0. 4147 {{ Added from Clarif-4.8 }} The traffic selector types 7 and 8 can 4148 also refer to ICMP type and code fields. Note, however, that ICMP 4149 packets do not have separate source and destination port fields. The 4150 method for specifying the traffic selectors for ICMP is shown by 4151 example in Section 4.4.1.3 of [IPSECARCH]. 4153 {{ Added from Clarif-4.9 }} Traffic selectors can use IP Protocol ID 4154 135 to match the IPv6 mobility header [MIPV6]. This document does 4155 not specify how to represent the "MH Type" field in traffic 4156 selectors, although it is likely that a different document will 4157 specify this in the future. Note that [IPSECARCH] says that the IPv6 4158 mobility header (MH) message type is placed in the most significant 4159 eight bits of the 16-bit local port selector. The direction 4160 semantics of TSi/TSr port fields are the same as for ICMP. 4162 The following table lists the assigned values for the Traffic 4163 Selector Type field and the corresponding Address Selector Data. 4165 TS Type Value 4166 ------------------------------------------------------------------- 4167 RESERVED 0-6 4169 TS_IPV4_ADDR_RANGE 7 4171 A range of IPv4 addresses, represented by two four-octet 4172 values. The first value is the beginning IPv4 address 4173 (inclusive) and the second value is the ending IPv4 address 4174 (inclusive). All addresses falling between the two specified 4175 addresses are considered to be within the list. 4177 TS_IPV6_ADDR_RANGE 8 4179 A range of IPv6 addresses, represented by two sixteen-octet 4180 values. The first value is the beginning IPv6 address 4181 (inclusive) and the second value is the ending IPv6 address 4182 (inclusive). All addresses falling between the two specified 4183 addresses are considered to be within the list. 4185 RESERVED TO IANA 9-240 4186 PRIVATE USE 241-255 4188 3.14. Encrypted Payload 4190 The Encrypted Payload, denoted SK{...} or E in this memo, contains 4191 other payloads in encrypted form. The Encrypted Payload, if present 4192 in a message, MUST be the last payload in the message. Often, it is 4193 the only payload in the message. 4195 The algorithms for encryption and integrity protection are negotiated 4196 during IKE_SA setup, and the keys are computed as specified in 4197 Section 2.14 and Section 2.18. 4199 The encryption and integrity protection algorithms are modeled after 4200 the ESP algorithms described in RFCs 2104 [HMAC], 4303 [ESP], and 4201 2451 [ESPCBC]. This document completely specifies the cryptographic 4202 processing of IKE data, but those documents should be consulted for 4203 design rationale. We require a block cipher with a fixed block size 4204 and an integrity check algorithm that computes a fixed-length 4205 checksum over a variable size message. 4207 The payload type for an Encrypted payload is forty six (46). The 4208 Encrypted Payload consists of the IKE generic payload header followed 4209 by individual fields as follows: 4211 1 2 3 4212 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 4213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4214 ! Next Payload !C! RESERVED ! Payload Length ! 4215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4216 ! Initialization Vector ! 4217 ! (length is block size for encryption algorithm) ! 4218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4219 ~ Encrypted IKE Payloads ~ 4220 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4221 ! ! Padding (0-255 octets) ! 4222 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 4223 ! ! Pad Length ! 4224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4225 ~ Integrity Checksum Data ~ 4226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4228 Figure 21: Encrypted Payload Format 4230 o Next Payload - The payload type of the first embedded payload. 4231 Note that this is an exception in the standard header format, 4232 since the Encrypted payload is the last payload in the message and 4233 therefore the Next Payload field would normally be zero. But 4234 because the content of this payload is embedded payloads and there 4235 was no natural place to put the type of the first one, that type 4236 is placed here. 4238 o Payload Length - Includes the lengths of the header, IV, Encrypted 4239 IKE Payloads, Padding, Pad Length, and Integrity Checksum Data. 4241 o Initialization Vector - A randomly chosen value whose length is 4242 equal to the block length of the underlying encryption algorithm. 4243 Recipients MUST accept any value. Senders SHOULD either pick this 4244 value pseudo-randomly and independently for each message or use 4245 the final ciphertext block of the previous message sent. Senders 4246 MUST NOT use the same value for each message, use a sequence of 4247 values with low hamming distance (e.g., a sequence number), or use 4248 ciphertext from a received message. 4250 o IKE Payloads are as specified earlier in this section. This field 4251 is encrypted with the negotiated cipher. 4253 o Padding MAY contain any value chosen by the sender, and MUST have 4254 a length that makes the combination of the Payloads, the Padding, 4255 and the Pad Length to be a multiple of the encryption block size. 4256 This field is encrypted with the negotiated cipher. 4258 o Pad Length is the length of the Padding field. The sender SHOULD 4259 set the Pad Length to the minimum value that makes the combination 4260 of the Payloads, the Padding, and the Pad Length a multiple of the 4261 block size, but the recipient MUST accept any length that results 4262 in proper alignment. This field is encrypted with the negotiated 4263 cipher. 4265 o Integrity Checksum Data is the cryptographic checksum of the 4266 entire message starting with the Fixed IKE Header through the Pad 4267 Length. The checksum MUST be computed over the encrypted message. 4268 Its length is determined by the integrity algorithm negotiated. 4270 3.15. Configuration Payload 4272 The Configuration payload, denoted CP in this document, is used to 4273 exchange configuration information between IKE peers. The exchange 4274 is for an IRAC to request an internal IP address from an IRAS and to 4275 exchange other information of the sort that one would acquire with 4276 Dynamic Host Configuration Protocol (DHCP) if the IRAC were directly 4277 connected to a LAN. 4279 Configuration payloads are of type CFG_REQUEST/CFG_REPLY or CFG_SET/ 4280 CFG_ACK (see CFG Type in the payload description below). CFG_REQUEST 4281 and CFG_SET payloads may optionally be added to any IKE request. The 4282 IKE response MUST include either a corresponding CFG_REPLY or CFG_ACK 4283 or a Notify payload with an error type indicating why the request 4284 could not be honored. An exception is that a minimal implementation 4285 MAY ignore all CFG_REQUEST and CFG_SET payloads, so a response 4286 message without a corresponding CFG_REPLY or CFG_ACK MUST be accepted 4287 as an indication that the request was not supported. 4289 "CFG_REQUEST/CFG_REPLY" allows an IKE endpoint to request information 4290 from its peer. If an attribute in the CFG_REQUEST Configuration 4291 Payload is not zero-length, it is taken as a suggestion for that 4292 attribute. The CFG_REPLY Configuration Payload MAY return that 4293 value, or a new one. It MAY also add new attributes and not include 4294 some requested ones. Requestors MUST ignore returned attributes that 4295 they do not recognize. 4297 Some attributes MAY be multi-valued, in which case multiple attribute 4298 values of the same type are sent and/or returned. Generally, all 4299 values of an attribute are returned when the attribute is requested. 4300 For some attributes (in this version of the specification only 4301 internal addresses), multiple requests indicates a request that 4302 multiple values be assigned. For these attributes, the number of 4303 values returned SHOULD NOT exceed the number requested. 4305 If the data type requested in a CFG_REQUEST is not recognized or not 4306 supported, the responder MUST NOT return an error type but rather 4307 MUST either send a CFG_REPLY that MAY be empty or a reply not 4308 containing a CFG_REPLY payload at all. Error returns are reserved 4309 for cases where the request is recognized but cannot be performed as 4310 requested or the request is badly formatted. 4312 "CFG_SET/CFG_ACK" allows an IKE endpoint to push configuration data 4313 to its peer. In this case, the CFG_SET Configuration Payload 4314 contains attributes the initiator wants its peer to alter. The 4315 responder MUST return a Configuration Payload if it accepted any of 4316 the configuration data and it MUST contain the attributes that the 4317 responder accepted with zero-length data. Those attributes that it 4318 did not accept MUST NOT be in the CFG_ACK Configuration Payload. If 4319 no attributes were accepted, the responder MUST return either an 4320 empty CFG_ACK payload or a response message without a CFG_ACK 4321 payload. There are currently no defined uses for the CFG_SET/CFG_ACK 4322 exchange, though they may be used in connection with extensions based 4323 on Vendor IDs. An minimal implementation of this specification MAY 4324 ignore CFG_SET payloads. 4326 {{ Demoted the SHOULD }} Extensions via the CP payload should not be 4327 used for general purpose management. Its main intent is to provide a 4328 bootstrap mechanism to exchange information within IPsec from IRAS to 4329 IRAC. While it MAY be useful to use such a method to exchange 4330 information between some Security Gateways (SGW) or small networks, 4331 existing management protocols such as DHCP [DHCP], RADIUS [RADIUS], 4332 SNMP, or LDAP [LDAP] should be preferred for enterprise management as 4333 well as subsequent information exchanges. 4335 The Configuration Payload is defined as follows: 4337 1 2 3 4338 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 4339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4340 ! Next Payload !C! RESERVED ! Payload Length ! 4341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4342 ! CFG Type ! RESERVED ! 4343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4344 ! ! 4345 ~ Configuration Attributes ~ 4346 ! ! 4347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4349 Figure 22: Configuration Payload Format 4351 The payload type for the Configuration Payload is forty seven (47). 4353 o CFG Type (1 octet) - The type of exchange represented by the 4354 Configuration Attributes. 4356 CFG Type Value 4357 -------------------------- 4358 RESERVED 0 4359 CFG_REQUEST 1 4360 CFG_REPLY 2 4361 CFG_SET 3 4362 CFG_ACK 4 4363 RESERVED TO IANA 5-127 4364 PRIVATE USE 128-255 4366 o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on 4367 receipt. 4369 o Configuration Attributes (variable length) - These are type length 4370 values specific to the Configuration Payload and are defined 4371 below. There may be zero or more Configuration Attributes in this 4372 payload. 4374 3.15.1. Configuration Attributes 4376 1 2 3 4377 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 4378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4379 !R| Attribute Type ! Length | 4380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4381 | | 4382 ~ Value ~ 4383 | | 4384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4386 Figure 23: Configuration Attribute Format 4388 o Reserved (1 bit) - This bit MUST be set to zero and MUST be 4389 ignored on receipt. 4391 o Attribute Type (15 bits) - A unique identifier for each of the 4392 Configuration Attribute Types. 4394 o Length (2 octets) - Length in octets of Value. 4396 o Value (0 or more octets) - The variable-length value of this 4397 Configuration Attribute. The following attribute types have been 4398 defined: 4400 Multi- 4401 Attribute Type Value Valued Length 4402 ------------------------------------------------------- 4403 RESERVED 0 4404 INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets 4405 INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets 4406 INTERNAL_IP4_DNS 3 YES 0 or 4 octets 4407 INTERNAL_IP4_NBNS 4 YES 0 or 4 octets 4408 INTERNAL_ADDRESS_EXPIRY 5 NO 0 or 4 octets 4409 INTERNAL_IP4_DHCP 6 YES 0 or 4 octets 4410 APPLICATION_VERSION 7 NO 0 or more 4411 INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets 4412 RESERVED 9 4413 INTERNAL_IP6_DNS 10 YES 0 or 16 octets 4414 INTERNAL_IP6_NBNS 11 YES 0 or 16 octets 4415 INTERNAL_IP6_DHCP 12 YES 0 or 16 octets 4416 INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets 4417 SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 4418 INTERNAL_IP6_SUBNET 15 YES 17 octets 4419 RESERVED TO IANA 16-16383 4420 PRIVATE USE 16384-32767 4422 * These attributes may be multi-valued on return only if 4423 multiple values were requested. 4425 o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the 4426 internal network, sometimes called a red node address or private 4427 address and MAY be a private address on the Internet. {{ 4428 Clarif-6.3}} In a request message, the address specified is a 4429 requested address (or a zero-length address if no specific address 4430 is requested). If a specific address is requested, it likely 4431 indicates that a previous connection existed with this address and 4432 the requestor would like to reuse that address. With IPv6, a 4433 requestor MAY supply the low-order address bytes it wants to use. 4434 Multiple internal addresses MAY be requested by requesting 4435 multiple internal address attributes. The responder MAY only send 4436 up to the number of addresses requested. The INTERNAL_IP6_ADDRESS 4437 is made up of two fields: the first is a 16-octet IPv6 address, 4438 and the second is a one-octet prefix-length as defined in 4439 [ADDRIPV6]. 4441 The requested address is valid until the expiry time defined with 4442 the INTERNAL_ADDRESS_EXPIRY attribute or there are no IKE_SAs 4443 between the peers. 4445 o INTERNAL_IP4_NETMASK - The internal network's netmask. Only one 4446 netmask is allowed in the request and reply messages (e.g., 4447 255.255.255.0), and it MUST be used only with an 4448 INTERNAL_IP4_ADDRESS attribute. {{ Clarif-6.5 }} 4449 INTERNAL_IP4_NETMASK in a CFG_REPLY means roughly the same thing 4450 as INTERNAL_IP4_SUBNET containing the same information ("send 4451 traffic to these addresses through me"), but also implies a link 4452 boundary. For instance, the client could use its own address and 4453 the netmask to calculate the broadcast address of the link. An 4454 empty INTERNAL_IP4_NETMASK attribute can be included in a 4455 CFG_REQUEST to request this information (although the gateway can 4456 send the information even when not requested). Non-empty values 4457 for this attribute in a CFG_REQUEST do not make sense and thus 4458 MUST NOT be included. 4460 o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a DNS 4461 server within the network. Multiple DNS servers MAY be requested. 4462 The responder MAY respond with zero or more DNS server attributes. 4464 o INTERNAL_IP4_NBNS, INTERNAL_IP6_NBNS - Specifies an address of a 4465 NetBios Name Server (WINS) within the network. Multiple NBNS 4466 servers MAY be requested. The responder MAY respond with zero or 4467 more NBNS server attributes. {{ Clarif-6.7 }} NetBIOS is not 4468 defined for IPv6; therefore, INTERNAL_IP6_NBNS SHOULD NOT be used. 4470 o INTERNAL_ADDRESS_EXPIRY - Specifies the number of seconds that the 4471 host can use the internal IP address. The host MUST renew the IP 4472 address before this expiry time. Only one of these attributes MAY 4473 be present in the reply. {{ Clarif-6.8 }} Expiry times and 4474 explicit renewals are primarily useful in environments like DHCP, 4475 where the server cannot reliably know when the client has gone 4476 away. However, in IKEv2, this is known, and the gateway can 4477 simply free the address when the IKE_SA is deleted. Further, 4478 supporting renewals is not mandatory. Thus 4479 INTERNAL_ADDRESS_EXPIRY attribute MUST NOT be used. 4481 o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to send 4482 any internal DHCP requests to the address contained within the 4483 attribute. Multiple DHCP servers MAY be requested. The responder 4484 MAY respond with zero or more DHCP server attributes. 4486 o APPLICATION_VERSION - The version or application information of 4487 the IPsec host. This is a string of printable ASCII characters 4488 that is NOT null terminated. 4490 o INTERNAL_IP4_SUBNET - The protected sub-networks that this edge- 4491 device protects. This attribute is made up of two fields: the 4492 first being an IP address and the second being a netmask. 4493 Multiple sub-networks MAY be requested. The responder MAY respond 4494 with zero or more sub-network attributes. 4496 o SUPPORTED_ATTRIBUTES - When used within a Request, this attribute 4497 MUST be zero-length and specifies a query to the responder to 4498 reply back with all of the attributes that it supports. The 4499 response contains an attribute that contains a set of attribute 4500 identifiers each in 2 octets. The length divided by 2 (octets) 4501 would state the number of supported attributes contained in the 4502 response. 4504 o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge- 4505 device protects. This attribute is made up of two fields: the 4506 first is a 16-octet IPv6 address, and the second is a one-octet 4507 prefix-length as defined in [ADDRIPV6]. Multiple sub-networks MAY 4508 be requested. The responder MAY respond with zero or more sub- 4509 network attributes. 4511 Note that no recommendations are made in this document as to how an 4512 implementation actually figures out what information to send in a 4513 reply. That is, we do not recommend any specific method of an IRAS 4514 determining which DNS server should be returned to a requesting IRAC. 4516 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET 4518 {{ Section added based on Clarif-6.4 }} 4520 INTERNAL_IP4/6_SUBNET attributes can indicate additional subnets, 4521 ones that need one or more separate SAs, that can be reached through 4522 the gateway that announces the attributes. INTERNAL_IP4/6_SUBNET 4523 attributes may also express the gateway's policy about what traffic 4524 should be sent through the gateway; the client can choose whether 4525 other traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is 4526 sent through the gateway or directly to the destination. Thus, 4527 traffic to the addresses listed in the INTERNAL_IP4/6_SUBNET 4528 attributes should be sent through the gateway that announces the 4529 attributes. If there are no existing IPsec SAs whose traffic 4530 selectors cover the address in question, new SAs need to be created. 4532 For instance, if there are two subnets, 192.0.1.0/26 and 4533 192.0.2.0/24, and the client's request contains the following: 4535 CP(CFG_REQUEST) = 4536 INTERNAL_IP4_ADDRESS() 4537 TSi = (0, 0-65535, 0.0.0.0-255.255.255.255) 4538 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) 4540 then a valid response could be the following (in which TSr and 4541 INTERNAL_IP4_SUBNET contain the same information): 4543 CP(CFG_REPLY) = 4544 INTERNAL_IP4_ADDRESS(192.0.1.234) 4545 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 4546 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 4547 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) 4548 TSr = ((0, 0-65535, 192.0.1.0-192.0.1.63), 4549 (0, 0-65535, 192.0.2.0-192.0.2.255)) 4551 In these cases, the INTERNAL_IP4_SUBNET does not really carry any 4552 useful information. 4554 A different possible reply would have been this: 4556 CP(CFG_REPLY) = 4557 INTERNAL_IP4_ADDRESS(192.0.1.234) 4558 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 4559 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 4560 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) 4561 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) 4563 That reply would mean that the client can send all its traffic 4564 through the gateway, but the gateway does not mind if the client 4565 sends traffic not included by INTERNAL_IP4_SUBNET directly to the 4566 destination (without going through the gateway). 4568 A different situation arises if the gateway has a policy that 4569 requires the traffic for the two subnets to be carried in separate 4570 SAs. Then a response like this would indicate to the client that if 4571 it wants access to the second subnet, it needs to create a separate 4572 SA: 4574 CP(CFG_REPLY) = 4575 INTERNAL_IP4_ADDRESS(192.0.1.234) 4576 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 4577 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 4578 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) 4579 TSr = (0, 0-65535, 192.0.1.0-192.0.1.63) 4581 INTERNAL_IP4_SUBNET can also be useful if the client's TSr included 4582 only part of the address space. For instance, if the client requests 4583 the following: 4585 CP(CFG_REQUEST) = 4586 INTERNAL_IP4_ADDRESS() 4587 TSi = (0, 0-65535, 0.0.0.0-255.255.255.255) 4588 TSr = (0, 0-65535, 192.0.2.155-192.0.2.155) 4590 then the gateway's reply might be: 4592 CP(CFG_REPLY) = 4593 INTERNAL_IP4_ADDRESS(192.0.1.234) 4594 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 4595 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 4596 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) 4597 TSr = (0, 0-65535, 192.0.2.155-192.0.2.155) 4599 Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET is in 4600 CFG_REQUESTs is unclear, they MUST NOT be used in CFG_REQUESTs. 4602 3.15.3. Configuration payloads for IPv6 4604 {{ Added this section from Clarif-6.6 }} 4606 The configuration payloads for IPv6 are based on the corresponding 4607 IPv4 payloads, and do not fully follow the "normal IPv6 way of doing 4608 things". In particular, IPv6 stateless autoconfiguration or router 4609 advertisement messages are not used; neither is neighbor discovery. 4611 A client can be assigned an IPv6 address using the 4612 INTERNAL_IP6_ADDRESS configuration payload. A minimal exchange might 4613 look like this: 4615 CP(CFG_REQUEST) = 4616 INTERNAL_IP6_ADDRESS() 4617 INTERNAL_IP6_DNS() 4618 TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 4619 TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 4621 CP(CFG_REPLY) = 4622 INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) 4623 INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44) 4624 TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5) 4625 TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 4627 The client MAY send a non-empty INTERNAL_IP6_ADDRESS attribute in the 4628 CFG_REQUEST to request a specific address or interface identifier. 4629 The gateway first checks if the specified address is acceptable, and 4630 if it is, returns that one. If the address was not acceptable, the 4631 gateway attempts to use the interface identifier with some other 4632 prefix; if even that fails, the gateway selects another interface 4633 identifier. 4635 The INTERNAL_IP6_ADDRESS attribute also contains a prefix length 4636 field. When used in a CFG_REPLY, this corresponds to the 4637 INTERNAL_IP4_NETMASK attribute in the IPv4 case. 4639 Although this approach to configuring IPv6 addresses is reasonably 4640 simple, it has some limitations. IPsec tunnels configured using 4641 IKEv2 are not fully-featured "interfaces" in the IPv6 addressing 4642 architecture sense [IPV6ADDR]. In particular, they do not 4643 necessarily have link-local addresses, and this may complicate the 4644 use of protocols that assume them, such as [MLDV2]. 4646 3.15.4. Address Assignment Failures 4648 {{ Added this section from Clarif-6.9 }} 4650 If the responder encounters an error while attempting to assign an IP 4651 address to the initiator, it responds with an 4652 INTERNAL_ADDRESS_FAILURE notification. However, there are some more 4653 complex error cases. 4655 If the responder does not support configuration payloads at all, it 4656 can simply ignore all configuration payloads. This type of 4657 implementation never sends INTERNAL_ADDRESS_FAILURE notifications. 4658 If the initiator requires the assignment of an IP address, it will 4659 treat a response without CFG_REPLY as an error. 4661 The initiator may request a particular type of address (IPv4 or IPv6) 4662 that the responder does not support, even though the responder 4663 supports configuration payloads. In this case, the responder simply 4664 ignores the type of address it does not support and processes the 4665 rest of the request as usual. 4667 If the initiator requests multiple addresses of a type that the 4668 responder supports, and some (but not all) of the requests fail, the 4669 responder replies with the successful addresses only. The responder 4670 sends INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned. 4672 3.16. Extensible Authentication Protocol (EAP) Payload 4674 The Extensible Authentication Protocol Payload, denoted EAP in this 4675 memo, allows IKE_SAs to be authenticated using the protocol defined 4676 in RFC 3748 [EAP] and subsequent extensions to that protocol. The 4677 full set of acceptable values for the payload is defined elsewhere, 4678 but a short summary of RFC 3748 is included here to make this 4679 document stand alone in the common cases. 4681 1 2 3 4682 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 4683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4684 ! Next Payload !C! RESERVED ! Payload Length ! 4685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4686 ! ! 4687 ~ EAP Message ~ 4688 ! ! 4689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4691 Figure 24: EAP Payload Format 4693 The payload type for an EAP Payload is forty eight (48). 4695 1 2 3 4696 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 4697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4698 ! Code ! Identifier ! Length ! 4699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4700 ! Type ! Type_Data... 4701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 4703 Figure 25: EAP Message Format 4705 o Code (1 octet) indicates whether this message is a Request (1), 4706 Response (2), Success (3), or Failure (4). 4708 o Identifier (1 octet) is used in PPP to distinguish replayed 4709 messages from repeated ones. Since in IKE, EAP runs over a 4710 reliable protocol, it serves no function here. In a response 4711 message, this octet MUST be set to match the identifier in the 4712 corresponding request. In other messages, this field MAY be set 4713 to any value. 4715 o Length (2 octets) is the length of the EAP message and MUST be 4716 four less than the Payload Length of the encapsulating payload. 4718 o Type (1 octet) is present only if the Code field is Request (1) or 4719 Response (2). For other codes, the EAP message length MUST be 4720 four octets and the Type and Type_Data fields MUST NOT be present. 4721 In a Request (1) message, Type indicates the data being requested. 4722 In a Response (2) message, Type MUST either be Nak or match the 4723 type of the data requested. The following types are defined in 4724 RFC 3748: 4726 1 Identity 4727 2 Notification 4728 3 Nak (Response Only) 4729 4 MD5-Challenge 4730 5 One-Time Password (OTP) 4731 6 Generic Token Card 4733 o Type_Data (Variable Length) varies with the Type of Request and 4734 the associated Response. For the documentation of the EAP 4735 methods, see [EAP]. 4737 {{ Demoted the SHOULD NOT and SHOULD }} Note that since IKE passes an 4738 indication of initiator identity in message 3 of the protocol, the 4739 responder should not send EAP Identity requests. The initiator may, 4740 however, respond to such requests if it receives them. 4742 4. Conformance Requirements 4744 In order to assure that all implementations of IKEv2 can 4745 interoperate, there are "MUST support" requirements in addition to 4746 those listed elsewhere. Of course, IKEv2 is a security protocol, and 4747 one of its major functions is to allow only authorized parties to 4748 successfully complete establishment of SAs. So a particular 4749 implementation may be configured with any of a number of restrictions 4750 concerning algorithms and trusted authorities that will prevent 4751 universal interoperability. 4753 IKEv2 is designed to permit minimal implementations that can 4754 interoperate with all compliant implementations. There are a series 4755 of optional features that can easily be ignored by a particular 4756 implementation if it does not support that feature. Those features 4757 include: 4759 o Ability to negotiate SAs through a NAT and tunnel the resulting 4760 ESP SA over UDP. 4762 o Ability to request (and respond to a request for) a temporary IP 4763 address on the remote end of a tunnel. 4765 o Ability to support various types of legacy authentication. 4767 o Ability to support window sizes greater than one. 4769 o Ability to establish multiple ESP and/or AH SAs within a single 4770 IKE_SA. 4772 o Ability to rekey SAs. 4774 To assure interoperability, all implementations MUST be capable of 4775 parsing all payload types (if only to skip over them) and to ignore 4776 payload types that it does not support unless the critical bit is set 4777 in the payload header. If the critical bit is set in an unsupported 4778 payload header, all implementations MUST reject the messages 4779 containing those payloads. 4781 Every implementation MUST be capable of doing four-message 4782 IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, 4783 one for ESP and/or AH). Implementations MAY be initiate-only or 4784 respond-only if appropriate for their platform. Every implementation 4785 MUST be capable of responding to an INFORMATIONAL exchange, but a 4786 minimal implementation MAY respond to any INFORMATIONAL message with 4787 an empty INFORMATIONAL reply (note that within the context of an 4788 IKE_SA, an "empty" message consists of an IKE header followed by an 4789 Encrypted payload with no payloads contained in it). A minimal 4790 implementation MAY support the CREATE_CHILD_SA exchange only in so 4791 far as to recognize requests and reject them with a Notify payload of 4792 type NO_ADDITIONAL_SAS. A minimal implementation need not be able to 4793 initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA 4794 expires (based on locally configured values of either lifetime or 4795 octets passed), and implementation MAY either try to renew it with a 4796 CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and 4797 create a new one. If the responder rejects the CREATE_CHILD_SA 4798 request with a NO_ADDITIONAL_SAS notification, the implementation 4799 MUST be capable of instead deleting the old SA and creating a new 4800 one. 4802 Implementations are not required to support requesting temporary IP 4803 addresses or responding to such requests. If an implementation does 4804 support issuing such requests, it MUST include a CP payload in 4805 message 3 containing at least a field of type INTERNAL_IP4_ADDRESS or 4806 INTERNAL_IP6_ADDRESS. All other fields are optional. If an 4807 implementation supports responding to such requests, it MUST parse 4808 the CP payload of type CFG_REQUEST in message 3 and recognize a field 4809 of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports 4810 leasing an address of the appropriate type, it MUST return a CP 4811 payload of type CFG_REPLY containing an address of the requested 4812 type. {{ Demoted the SHOULD }} The responder may include any other 4813 related attributes. 4815 A minimal IPv4 responder implementation will ignore the contents of 4816 the CP payload except to determine that it includes an 4817 INTERNAL_IP4_ADDRESS attribute and will respond with the address and 4818 other related attributes regardless of whether the initiator 4819 requested them. 4821 A minimal IPv4 initiator will generate a CP payload containing only 4822 an INTERNAL_IP4_ADDRESS attribute and will parse the response 4823 ignoring attributes it does not know how to use. {{ Clarif-6.8 4824 removes the sentence about processing INTERNAL_ADDRESS_EXPIRY. }} 4825 Minimal initiators need not be able to request lease renewals and 4826 minimal responders need not respond to them. 4828 For an implementation to be called conforming to this specification, 4829 it MUST be possible to configure it to accept the following: 4831 o PKIX Certificates containing and signed by RSA keys of size 1024 4832 or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, 4833 ID_RFC822_ADDR, or ID_DER_ASN1_DN. 4835 o Shared key authentication where the ID passes is any of ID_KEY_ID, 4836 ID_FQDN, or ID_RFC822_ADDR. 4838 o Authentication where the responder is authenticated using PKIX 4839 Certificates and the initiator is authenticated using shared key 4840 authentication. 4842 5. Security Considerations 4844 While this protocol is designed to minimize disclosure of 4845 configuration information to unauthenticated peers, some such 4846 disclosure is unavoidable. One peer or the other must identify 4847 itself first and prove its identity first. To avoid probing, the 4848 initiator of an exchange is required to identify itself first, and 4849 usually is required to authenticate itself first. The initiator can, 4850 however, learn that the responder supports IKE and what cryptographic 4851 protocols it supports. The responder (or someone impersonating the 4852 responder) can probe the initiator not only for its identity, but 4853 using CERTREQ payloads may be able to determine what certificates the 4854 initiator is willing to use. 4856 Use of EAP authentication changes the probing possibilities somewhat. 4857 When EAP authentication is used, the responder proves its identity 4858 before the initiator does, so an initiator that knew the name of a 4859 valid initiator could probe the responder for both its name and 4860 certificates. 4862 Repeated rekeying using CREATE_CHILD_SA without additional Diffie- 4863 Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a 4864 single key or overrun of either endpoint. Implementers should take 4865 note of this fact and set a limit on CREATE_CHILD_SA exchanges 4866 between exponentiations. This memo does not prescribe such a limit. 4868 The strength of a key derived from a Diffie-Hellman exchange using 4869 any of the groups defined here depends on the inherent strength of 4870 the group, the size of the exponent used, and the entropy provided by 4871 the random number generator used. Due to these inputs, it is 4872 difficult to determine the strength of a key for any of the defined 4873 groups. Diffie-Hellman group number two, when used with a strong 4874 random number generator and an exponent no less than 200 bits, is 4875 common for use with 3DES. Group five provides greater security than 4876 group two. Group one is for historic purposes only and does not 4877 provide sufficient strength except for use with DES, which is also 4878 for historic use only. Implementations should make note of these 4879 estimates when establishing policy and negotiating security 4880 parameters. 4882 Note that these limitations are on the Diffie-Hellman groups 4883 themselves. There is nothing in IKE that prohibits using stronger 4884 groups nor is there anything that will dilute the strength obtained 4885 from stronger groups (limited by the strength of the other algorithms 4886 negotiated including the prf function). In fact, the extensible 4887 framework of IKE encourages the definition of more groups; use of 4888 elliptical curve groups may greatly increase strength using much 4889 smaller numbers. 4891 It is assumed that all Diffie-Hellman exponents are erased from 4892 memory after use. In particular, these exponents MUST NOT be derived 4893 from long-lived secrets like the seed to a pseudo-random generator 4894 that is not erased after use. 4896 The strength of all keys is limited by the size of the output of the 4897 negotiated prf function. For this reason, a prf function whose 4898 output is less than 128 bits (e.g., 3DES-CBC) MUST NOT be used with 4899 this protocol. 4901 The security of this protocol is critically dependent on the 4902 randomness of the randomly chosen parameters. These should be 4903 generated by a strong random or properly seeded pseudo-random source 4904 (see [RANDOMNESS]). Implementers should take care to ensure that use 4905 of random numbers for both keys and nonces is engineered in a fashion 4906 that does not undermine the security of the keys. 4908 For information on the rationale of many of the cryptographic design 4909 choices in this protocol, see [SIGMA] and [SKEME]. Though the 4910 security of negotiated CHILD_SAs does not depend on the strength of 4911 the encryption and integrity protection negotiated in the IKE_SA, 4912 implementations MUST NOT negotiate NONE as the IKE integrity 4913 protection algorithm or ENCR_NULL as the IKE encryption algorithm. 4915 When using pre-shared keys, a critical consideration is how to assure 4916 the randomness of these secrets. The strongest practice is to ensure 4917 that any pre-shared key contain as much randomness as the strongest 4918 key being negotiated. Deriving a shared secret from a password, 4919 name, or other low-entropy source is not secure. These sources are 4920 subject to dictionary and social engineering attacks, among others. 4922 The NAT_DETECTION_*_IP notifications contain a hash of the addresses 4923 and ports in an attempt to hide internal IP addresses behind a NAT. 4924 Since the IPv4 address space is only 32 bits, and it is usually very 4925 sparse, it would be possible for an attacker to find out the internal 4926 address used behind the NAT box by trying all possible IP addresses 4927 and trying to find the matching hash. The port numbers are normally 4928 fixed to 500, and the SPIs can be extracted from the packet. This 4929 reduces the number of hash calculations to 2^32. With an educated 4930 guess of the use of private address space, the number of hash 4931 calculations is much smaller. Designers should therefore not assume 4932 that use of IKE will not leak internal address information. 4934 When using an EAP authentication method that does not generate a 4935 shared key for protecting a subsequent AUTH payload, certain man-in- 4936 the-middle and server impersonation attacks are possible [EAPMITM]. 4937 These vulnerabilities occur when EAP is also used in protocols that 4938 are not protected with a secure tunnel. Since EAP is a general- 4939 purpose authentication protocol, which is often used to provide 4940 single-signon facilities, a deployed IPsec solution that relies on an 4941 EAP authentication method that does not generate a shared key (also 4942 known as a non-key-generating EAP method) can become compromised due 4943 to the deployment of an entirely unrelated application that also 4944 happens to use the same non-key-generating EAP method, but in an 4945 unprotected fashion. Note that this vulnerability is not limited to 4946 just EAP, but can occur in other scenarios where an authentication 4947 infrastructure is reused. For example, if the EAP mechanism used by 4948 IKEv2 utilizes a token authenticator, a man-in-the-middle attacker 4949 could impersonate the web server, intercept the token authentication 4950 exchange, and use it to initiate an IKEv2 connection. For this 4951 reason, use of non-key-generating EAP methods SHOULD be avoided where 4952 possible. Where they are used, it is extremely important that all 4953 usages of these EAP methods SHOULD utilize a protected tunnel, where 4954 the initiator validates the responder's certificate before initiating 4955 the EAP exchange. {{ Demoted the SHOULD }} Implementers should 4956 describe the vulnerabilities of using non-key-generating EAP methods 4957 in the documentation of their implementations so that the 4958 administrators deploying IPsec solutions are aware of these dangers. 4960 An implementation using EAP MUST also use a public-key-based 4961 authentication of the server to the client before the EAP exchange 4962 begins, even if the EAP method offers mutual authentication. This 4963 avoids having additional IKEv2 protocol variations and protects the 4964 EAP data from active attackers. 4966 If the messages of IKEv2 are long enough that IP-level fragmentation 4967 is necessary, it is possible that attackers could prevent the 4968 exchange from completing by exhausting the reassembly buffers. The 4969 chances of this can be minimized by using the Hash and URL encodings 4970 instead of sending certificates (see Section 3.6). Additional 4971 mitigations are discussed in [DOSUDPPROT]. 4973 6. IANA Considerations 4975 {{ This section was changed to not re-define any new IANA registries. 4976 }} 4978 [IKEV2] defined many field types and values. IANA has already 4979 registered those types and values, so the are not listed here again. 4980 No new types or values are registered in IKEv2.1. 4982 7. Acknowledgements 4984 {{ Added new acknowledgements. }} 4986 Charlie Kaufman did a huge amount of work on the original IKEv2 4987 document, on which this document is primarily based. Pasi Eronen 4988 worked hard on the clarifications document, which is the basis for 4989 the differences between IKEv2 and IKEv2.1. The individuals on the 4990 IPsec mailing list was very helpful in both pointing out where 4991 clarifications and changes were needed, as well as in reviewing the 4992 clarifications suggested by others. 4994 The acknowledgements from the IKEv2 document were: 4996 This document is a collaborative effort of the entire IPsec WG. If 4997 there were no limit to the number of authors that could appear on an 4998 RFC, the following, in alphabetical order, would have been listed: 4999 Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt 5000 Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, John 5001 Ioannidis, Charlie Kaufman, Steve Kent, Angelos Keromytis, Tero 5002 Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer 5003 Reingold, and Michael Richardson. Many other people contributed to 5004 the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI, 5005 each of which has its own list of authors. Hugh Daniel suggested the 5006 feature of having the initiator, in message 3, specify a name for the 5007 responder, and gave the feature the cute name "You Tarzan, Me Jane". 5008 David Faucher and Valery Smyzlov helped refine the design of the 5009 traffic selector negotiation. 5011 This paragraph lists references that appear only in figures. The 5012 section is only here to keep the 'xml2rfc' program happy, and will be 5013 removed when the document is published. Feel free to ignore it. 5014 [DES] [IDEA] [MD5] [X.501] [X.509] 5016 8. References 5018 8.1. Normative References 5020 [ADDGROUP] 5021 Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 5022 Diffie-Hellman groups for Internet Key Exchange (IKE)", 5023 RFC 3526, May 2003. 5025 [ADDRIPV6] 5026 Hinden, R. and S. Deering, "Internet Protocol Version 6 5027 (IPv6) Addressing Architecture", RFC 3513, April 2003. 5029 [Clarif] "IKEv2 Clarifications and Implementation Guidelines", 5030 draft-eronen-ipsec-ikev2-clarifications (work in 5031 progress). 5033 [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 5034 Levkowetz, "Extensible Authentication Protocol (EAP)", 5035 RFC 3748, June 2004. 5037 [ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 5038 of Explicit Congestion Notification (ECN) to IP", 5039 RFC 3168, September 2001. 5041 [ESPCBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 5042 Algorithms", RFC 2451, November 1998. 5044 [IANACONS] 5045 Narten, T. and H. Alvestrand, "Guidelines for Writing an 5046 IANA Considerations Section in RFCs", BCP 26, RFC 2434. 5048 [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 5049 RFC 4306, December 2005. 5051 [IPSECARCH] 5052 Kent, S. and K. Seo, "Security Architecture for the 5053 Internet Protocol", RFC 4301, December 2005. 5055 [MUSTSHOULD] 5056 Bradner, S., "Key Words for use in RFCs to indicate 5057 Requirement Levels", BCP 14, RFC 2119, March 1997. 5059 [PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 5060 X.509 Public Key Infrastructure Certificate and 5061 Certificate Revocation List (CRL) Profile", RFC 3280, 5062 April 2002. 5064 [UDPENCAPS] 5065 Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 5066 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 5067 RFC 3948, January 2005. 5069 8.2. Informative References 5071 [AH] Kent, S., "IP Authentication Header", RFC 4302, 5072 December 2005. 5074 [ARCHGUIDEPHIL] 5075 Bush, R. and D. Meyer, "Some Internet Architectural 5076 Guidelines and Philosophy", RFC 3439, December 2002. 5078 [ARCHPRINC] 5079 Carpenter, B., "Architectural Principles of the Internet", 5080 RFC 1958, June 1996. 5082 [DES] American National Standards Institute, "American National 5083 Standard for Information Systems-Data Link Encryption", 5084 ANSI X3.106, 1983. 5086 [DH] Diffie, W. and M. Hellman, "New Directions in 5087 Cryptography", IEEE Transactions on Information Theory, 5088 V.IT-22 n. 6, June 1977. 5090 [DHCP] Droms, R., "Dynamic Host Configuration Protocol", 5091 RFC 2131, March 1997. 5093 [DIFFSERVARCH] 5094 Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 5095 and W. Weiss, "An Architecture for Differentiated 5096 Services", RFC 2475. 5098 [DIFFSERVFIELD] 5099 Nichols, K., Blake, S., Baker, F., and D. Black, 5100 "Definition of the Differentiated Services Field (DS 5101 Field) in the IPv4 and IPv6 Headers", RFC 2474, 5102 December 1998. 5104 [DIFFTUNNEL] 5105 Black, D., "Differentiated Services and Tunnels", 5106 RFC 2983, October 2000. 5108 [DOI] Piper, D., "The Internet IP Security Domain of 5109 Interpretation for ISAKMP", RFC 2407, November 1998. 5111 [DOSUDPPROT] 5112 C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection 5113 for UDP-based protocols", ACM Conference on Computer and 5114 Communications Security , October 2003. 5116 [DSS] National Institute of Standards and Technology, U.S. 5117 Department of Commerce, "Digital Signature Standard", 5118 FIPS 186, May 1994. 5120 [EAPMITM] N. Asokan, V. Nierni, and K. Nyberg, "Man-in-the-Middle in 5121 Tunneled Authentication Protocols", November 2002, 5122 . 5124 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", 5125 RFC 4303, December 2005. 5127 [EXCHANGEANALYSIS] 5128 R. Perlman and C. Kaufman, "Analysis of the IPsec key 5129 exchange Standard", WET-ICE Security Conference, MIT , 5130 2001, 5131 . 5133 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 5134 Hashing for Message Authentication", RFC 2104, 5135 February 1997. 5137 [IDEA] X. Lai, "On the Design and Security of Block Ciphers", ETH 5138 Series in Information Processing, v. 1, Konstanz: Hartung- 5139 Gorre Verlag, 1992. 5141 [IKEV1] Harkins, D. and D. Carrel, "The Internet Key Exchange 5142 (IKE)", RFC 2409, November 1998. 5144 [IPCOMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP 5145 Payload Compression Protocol (IPComp)", RFC 3173, 5146 September 2001. 5148 [IPSECARCH-OLD] 5149 Kent, S. and R. Atkinson, "Security Architecture for the 5150 Internet Protocol", RFC 2401, November 1998. 5152 [IPV6ADDR] 5153 Hinden, R. and S. Deering, "Internet Protocol Version 6 5154 (IPv6) Addressing Architecture", RFC 3513, April 2003. 5156 [ISAKMP] Maughan, D., Schneider, M., and M. Schertler, "Internet 5157 Security Association and Key Management Protocol 5158 (ISAKMP)", RFC 2408, November 1998. 5160 [LDAP] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory 5161 Access Protocol (v3)", RFC 2251, December 1997. 5163 [MAILFORMAT] 5164 Resnick, P., "Internet Message Format", RFC 2822, 5165 April 2001. 5167 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 5168 April 1992. 5170 [MIPV6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 5171 in IPv6", RFC 3775, June 2004. 5173 [MLDV2] Vida, R. and L. Costa, "Multicast Listener Discovery 5174 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 5176 [NAI] Aboba, B. and M. Beadles, "The Network Access Identifier", 5177 RFC 2486, January 1999. 5179 [NATREQ] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 5180 (NAT) Compatibility Requirements", RFC 3715, March 2004. 5182 [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", 5183 RFC 2412, November 1998. 5185 [PFKEY] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 5186 Management API, Version 2", RFC 2367, July 1998. 5188 [PHOTURIS] 5189 Karn, P. and W. Simpson, "Photuris: Session-Key Management 5190 Protocol", RFC 2522, March 1999. 5192 [PKCS1] B. Kaliski and J. Staddon, "PKCS #1: RSA Cryptography 5193 Specifications Version 2", September 1998. 5195 [PRFAES128CBC] 5196 Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the 5197 Internet Key Exchange Protocol (IKE)", RFC 3664, 5198 January 2004. 5200 [PRFAES128CBC-bis] 5201 Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the 5202 Internet Key Exchange Protocol (IKE)", 5203 draft-hoffman-rfc3664bis (work in progress), October 2005. 5205 [RADIUS] Rigney, C., Rubens, A., Simpson, W., and S. Willens, 5206 "Remote Authentication Dial In User Service (RADIUS)", 5207 RFC 2138, April 1997. 5209 [RANDOMNESS] 5210 Eastlake, D., Schiller, J., and S. Crocker, "Randomness 5211 Requirements for Security", BCP 106, RFC 4086, June 2005. 5213 [REAUTH] Nir, Y., ""Repeated Authentication in IKEv2", 5214 draft-nir-ikev2-auth-lt (work in progress), May 2005. 5216 [RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for 5217 Obtaining Digital Signatures and Public-Key 5218 Cryptosystems", February 1978. 5220 [SHA] National Institute of Standards and Technology, U.S. 5221 Department of Commerce, "Secure Hash Standard", 5222 FIPS 180-1, May 1994. 5224 [SIGMA] H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to 5225 Authenticated Diffie-Hellman and its Use in the IKE 5226 Protocols", Advances in Cryptography - CRYPTO 2003 5227 Proceedings LNCS 2729, 2003, . 5231 [SKEME] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange 5232 Mechanism for Internet", IEEE Proceedings of the 1996 5233 Symposium on Network and Distributed Systems Security , 5234 1996. 5236 [TRANSPARENCY] 5237 Carpenter, B., "Internet Transparency", RFC 2775, 5238 February 2000. 5240 [X.501] ITU-T, "Recommendation X.501: Information Technology - 5241 Open Systems Interconnection - The Directory: Models", 5242 1993. 5244 [X.509] ITU-T, "Recommendation X.509 (1997 E): Information 5245 Technology - Open Systems Interconnection - The Directory: 5246 Authentication Framework", 1997. 5248 Appendix A. Summary of changes from IKEv1 5250 The goals of this revision to IKE are: 5252 1. To define the entire IKE protocol in a single document, 5253 replacing RFCs 2407, 2408, and 2409 and incorporating subsequent 5254 changes to support NAT Traversal, Extensible Authentication, and 5255 Remote Address acquisition; 5257 2. To simplify IKE by replacing the eight different initial 5258 exchanges with a single four-message exchange (with changes in 5259 authentication mechanisms affecting only a single AUTH payload 5260 rather than restructuring the entire exchange) see 5261 [EXCHANGEANALYSIS]; 5263 3. To remove the Domain of Interpretation (DOI), Situation (SIT), 5264 and Labeled Domain Identifier fields, and the Commit and 5265 Authentication only bits; 5267 4. To decrease IKE's latency in the common case by making the 5268 initial exchange be 2 round trips (4 messages), and allowing the 5269 ability to piggyback setup of a CHILD_SA on that exchange; 5271 5. To replace the cryptographic syntax for protecting the IKE 5272 messages themselves with one based closely on ESP to simplify 5273 implementation and security analysis; 5275 6. To reduce the number of possible error states by making the 5276 protocol reliable (all messages are acknowledged) and sequenced. 5277 This allows shortening CREATE_CHILD_SA exchanges from 3 messages 5278 to 2; 5280 7. To increase robustness by allowing the responder to not do 5281 significant processing until it receives a message proving that 5282 the initiator can receive messages at its claimed IP address, 5283 and not commit any state to an exchange until the initiator can 5284 be cryptographically authenticated; 5286 8. To fix cryptographic weaknesses such as the problem with 5287 symmetries in hashes used for authentication documented by Tero 5288 Kivinen; 5290 9. To specify Traffic Selectors in their own payloads type rather 5291 than overloading ID payloads, and making more flexible the 5292 Traffic Selectors that may be specified; 5294 10. To specify required behavior under certain error conditions or 5295 when data that is not understood is received in order to make it 5296 easier to make future revisions in a way that does not break 5297 backwards compatibility; 5299 11. To simplify and clarify how shared state is maintained in the 5300 presence of network failures and Denial of Service attacks; and 5302 12. To maintain existing syntax and magic numbers to the extent 5303 possible to make it likely that implementations of IKEv1 can be 5304 enhanced to support IKEv2 with minimum effort. 5306 Appendix B. Diffie-Hellman Groups 5308 There are two Diffie-Hellman groups defined here for use in IKE. 5309 These groups were generated by Richard Schroeppel at the University 5310 of Arizona. Properties of these primes are described in [OAKLEY]. 5312 The strength supplied by group one may not be sufficient for the 5313 mandatory-to-implement encryption algorithm and is here for historic 5314 reasons. 5316 Additional Diffie-Hellman groups have been defined in [ADDGROUP]. 5318 B.1. Group 1 - 768 Bit MODP 5320 This group is assigned id 1 (one). 5322 The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } 5323 Its hexadecimal value is: 5325 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 5326 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 5327 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 5328 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF 5330 The generator is 2. 5332 B.2. Group 2 - 1024 Bit MODP 5334 This group is assigned id 2 (two). 5336 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. 5337 Its hexadecimal value is: 5339 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 5340 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 5341 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 5342 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 5343 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 5344 FFFFFFFF FFFFFFFF 5345 The generator is 2. 5347 Appendix C. Exchanges and Payloads 5349 {{ Clarif-AppA }} 5351 This appendix contains a short summary of the IKEv2 exchanges, and 5352 what payloads can appear in which message. This appendix is purely 5353 informative; if it disagrees with the body of this document, the 5354 other text is considered correct. 5356 Vendor-ID (V) payloads may be included in any place in any message. 5357 This sequence here shows what are the most logical places for them. 5359 C.1. IKE_SA_INIT Exchange 5361 request --> [N(COOKIE)], 5362 SA, KE, Ni, 5363 [N(NAT_DETECTION_SOURCE_IP)+, 5364 N(NAT_DETECTION_DESTINATION_IP)], 5365 [V+] 5367 normal response <-- SA, KE, Nr, 5368 (no cookie) [N(NAT_DETECTION_SOURCE_IP), 5369 N(NAT_DETECTION_DESTINATION_IP)], 5370 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 5371 [V+] 5373 C.2. IKE_AUTH Exchange without EAP 5375 request --> IDi, [CERT+], 5376 [N(INITIAL_CONTACT)], 5377 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 5378 [IDr], 5379 AUTH, 5380 [CP(CFG_REQUEST)], 5381 [N(IPCOMP_SUPPORTED)+], 5382 [N(USE_TRANSPORT_MODE)], 5383 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5384 [N(NON_FIRST_FRAGMENTS_ALSO)], 5385 SA, TSi, TSr, 5386 [V+] 5388 response <-- IDr, [CERT+], 5389 AUTH, 5390 [CP(CFG_REPLY)], 5391 [N(IPCOMP_SUPPORTED)], 5392 [N(USE_TRANSPORT_MODE)], 5393 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5394 [N(NON_FIRST_FRAGMENTS_ALSO)], 5395 SA, TSi, TSr, 5396 [N(ADDITIONAL_TS_POSSIBLE)], 5397 [V+] 5399 C.3. IKE_AUTH Exchange with EAP 5401 first request --> IDi, 5402 [N(INITIAL_CONTACT)], 5403 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 5404 [IDr], 5405 [CP(CFG_REQUEST)], 5406 [N(IPCOMP_SUPPORTED)+], 5407 [N(USE_TRANSPORT_MODE)], 5408 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5409 [N(NON_FIRST_FRAGMENTS_ALSO)], 5410 SA, TSi, TSr, 5411 [V+] 5413 first response <-- IDr, [CERT+], AUTH, 5414 EAP, 5415 [V+] 5417 / --> EAP 5418 repeat 1..N times | 5419 \ <-- EAP 5421 last request --> AUTH 5423 last response <-- AUTH, 5424 [CP(CFG_REPLY)], 5425 [N(IPCOMP_SUPPORTED)], 5426 [N(USE_TRANSPORT_MODE)], 5427 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5428 [N(NON_FIRST_FRAGMENTS_ALSO)], 5429 SA, TSi, TSr, 5430 [N(ADDITIONAL_TS_POSSIBLE)], 5431 [V+] 5433 C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying CHILD_SAs 5435 request --> [N(REKEY_SA)], 5436 [N(IPCOMP_SUPPORTED)+], 5437 [N(USE_TRANSPORT_MODE)], 5438 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5439 [N(NON_FIRST_FRAGMENTS_ALSO)], 5440 SA, Ni, [KEi], TSi, TSr 5442 response <-- [N(IPCOMP_SUPPORTED)], 5443 [N(USE_TRANSPORT_MODE)], 5444 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5445 [N(NON_FIRST_FRAGMENTS_ALSO)], 5446 SA, Nr, [KEr], TSi, TSr, 5447 [N(ADDITIONAL_TS_POSSIBLE)] 5449 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA 5451 request --> SA, Ni, [KEi] 5453 response <-- SA, Nr, [KEr] 5455 C.6. INFORMATIONAL Exchange 5457 request --> [N+], 5458 [D+], 5459 [CP(CFG_REQUEST)] 5461 response <-- [N+], 5462 [D+], 5463 [CP(CFG_REPLY)] 5465 Appendix D. Changes Between Internet Draft Versions 5467 This section will be removed before publication as an RFC. 5469 D.1. Changes from IKEv2 to draft -00 5471 There were a zillion additions from the Clarifications document. 5472 These are noted with "{{ Clarif-nn }}". 5474 Cleaned up many of the figures. Made the table headings consistent. 5475 Made some tables easier to read by removing blank spaces. Removed 5476 the "reserved to IANA" and "private use" text wording and moved it 5477 into the tables. 5479 Changed many SHOULD and MUST requirements to better match RFC 2119. 5481 Author's Address 5483 Paul Hoffman 5484 VPN Consortium 5485 127 Segre Place 5486 Santa Cruz, CA 95060 5487 US 5489 Phone: 1-831-426-9827 5490 Email: paul.hoffman@vpnc.org 5492 Full Copyright Statement 5494 Copyright (C) The Internet Society (2006). 5496 This document is subject to the rights, licenses and restrictions 5497 contained in BCP 78, and except as set forth therein, the authors 5498 retain all their rights. 5500 This document and the information contained herein are provided on an 5501 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 5502 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 5503 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 5504 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 5505 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 5506 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 5508 Intellectual Property 5510 The IETF takes no position regarding the validity or scope of any 5511 Intellectual Property Rights or other rights that might be claimed to 5512 pertain to the implementation or use of the technology described in 5513 this document or the extent to which any license under such rights 5514 might or might not be available; nor does it represent that it has 5515 made any independent effort to identify any such rights. Information 5516 on the procedures with respect to rights in RFC documents can be 5517 found in BCP 78 and BCP 79. 5519 Copies of IPR disclosures made to the IETF Secretariat and any 5520 assurances of licenses to be made available, or the result of an 5521 attempt made to obtain a general license or permission for the use of 5522 such proprietary rights by implementers or users of this 5523 specification can be obtained from the IETF on-line IPR repository at 5524 http://www.ietf.org/ipr. 5526 The IETF invites any interested party to bring to its attention any 5527 copyrights, patents or patent applications, or other proprietary 5528 rights that may cover technology that may be required to implement 5529 this standard. Please address the information to the IETF at 5530 ietf-ipr@ietf.org. 5532 Acknowledgment 5534 Funding for the RFC Editor function is currently provided by the 5535 Internet Society.