idnits 2.17.1 draft-ietf-ipsec-ikev2-17.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.5 on line 5040. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 5051. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 5058. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 5064. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 5032), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 108 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 109 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? -- The draft header indicates that this document obsoletes RFC2407, but the abstract doesn't seem to directly say this. It does mention RFC2407 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC2408, but the abstract doesn't seem to directly say this. It does mention RFC2408 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC2409, but the abstract doesn't seem to directly say this. It does mention RFC2409 though, so this could be OK. 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: 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: 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 (September 23, 2004) is 7127 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 1455, but not defined == Missing Reference: 'N' is mentioned on line 436, but not defined == Missing Reference: 'KEi' is mentioned on line 436, but not defined == Missing Reference: 'KEr' is mentioned on line 457, but not defined == Missing Reference: 'CP' is mentioned on line 534, but not defined -- Looks like a reference, but probably isn't: '0' on line 2813 -- Looks like a reference, but probably isn't: '1' on line 2814 == Unused Reference: 'ESPCBC' is defined on line 4261, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 4286, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 4289, but no explicit reference was found in the text == Unused Reference: 'DES' is defined on line 4294, but no explicit reference was found in the text == Unused Reference: 'DH' is defined on line 4298, but no explicit reference was found in the text == Unused Reference: 'DSS' is defined on line 4305, but no explicit reference was found in the text == Unused Reference: 'HC98' is defined on line 4313, but no explicit reference was found in the text == Unused Reference: 'IDEA' is defined on line 4316, but no explicit reference was found in the text == Unused Reference: 'KBC96' is defined on line 4328, but no explicit reference was found in the text == Unused Reference: 'MD5' is defined on line 4335, but no explicit reference was found in the text == Unused Reference: 'MSST98' is defined on line 4338, but no explicit reference was found in the text == Unused Reference: 'PKCS1' is defined on line 4348, but no explicit reference was found in the text == Unused Reference: 'PK01' is defined on line 4351, but no explicit reference was found in the text == Unused Reference: 'Pip98' is defined on line 4355, but no explicit reference was found in the text == Unused Reference: 'RFC2474' is defined on line 4376, but no explicit reference was found in the text == Unused Reference: 'RFC2475' is defined on line 4381, but no explicit reference was found in the text == Unused Reference: 'RFC3715' is defined on line 4397, but no explicit reference was found in the text == Unused Reference: 'RSA' is defined on line 4401, but no explicit reference was found in the text == Unused Reference: 'SHA' is defined on line 4406, but no explicit reference was found in the text == Unused Reference: 'SKEME' is defined on line 4416, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3513 (ref. 'ADDRIPV6') (Obsoleted by RFC 4291) == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-udp-encaps-08 == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-rfc2401bis-02 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. 'HC98') (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 2408 (ref. 'MSST98') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2407 (ref. 'Pip98') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2138 (ref. 'RADIUS') (Obsoleted by RFC 2865) -- Obsolete informational reference (is this intentional?): RFC 1750 (Obsoleted by RFC 4086) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2402 (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2406 (Obsoleted by RFC 4303, RFC 4305) Summary: 13 errors (**), 0 flaws (~~), 35 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Charlie Kaufman, Editor 3 draft-ietf-ipsec-ikev2-17.txt 4 Obsoletes: 2407, 2408, 2409 September 23, 2004 5 Expires: March 2005 7 Internet Key Exchange (IKEv2) Protocol 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 10 of RFC2026. Internet-Drafts are working documents of 13 the Internet Engineering Task Force (IETF), its areas, and its 14 working groups. Note that other groups may also distribute working 15 documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/1id-abstracts.html 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html 28 This document is a submission by the IPSEC Working Group of the 29 Internet Engineering Task Force (IETF). Comments should be submitted 30 to the ipsec@lists.tislabs.com mailing list. 32 Distribution of this memo is unlimited. 34 This Internet-Draft expires in March 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 This document describes version 2 of the Internet Key Exchange (IKE) 43 protocol. IKE is a component of IPsec used for performing mutual 44 authentication and establishing and maintaining security associations 45 (SAs). 47 This version of the IKE specification combines the contents of what 48 were previously separate documents, including ISAKMP (RFC 2408), IKE 49 (RFC 2409), the Internet DOI (RFC 2407), NAT Traversal, Legacy 50 authentication, and remote address acquisition. 52 Version 2 of IKE does not interoperate with version 1, but it has 53 enough of the header format in common that both versions can 54 unambiguously run over the same UDP port. 56 Table of Contents 58 1 Introduction...............................................3 59 1.1 Usage Scenarios..........................................5 60 1.2 The Initial Exchanges....................................7 61 1.3 The CREATE_CHILD_SA Exchange.............................9 62 1.4 The INFORMATIONAL Exchange..............................10 63 1.5 Informational Messages outside of an IKE_SA.............12 64 2 IKE Protocol Details and Variations.......................12 65 2.1 Use of Retransmission Timers............................13 66 2.2 Use of Sequence Numbers for Message ID..................13 67 2.3 Window Size for overlapping requests....................14 68 2.4 State Synchronization and Connection Timeouts...........15 69 2.5 Version Numbers and Forward Compatibility...............16 70 2.6 Cookies.................................................18 71 2.7 Cryptographic Algorithm Negotiation.....................20 72 2.8 Rekeying................................................21 73 2.9 Traffic Selector Negotiation............................23 74 2.10 Nonces.................................................25 75 2.11 Address and Port Agility...............................26 76 2.12 Reuse of Diffie-Hellman Exponentials...................26 77 2.13 Generating Keying Material.............................27 78 2.14 Generating Keying Material for the IKE_SA..............28 79 2.15 Authentication of the IKE_SA...........................29 80 2.16 Extensible Authentication Protocol Methods.............30 81 2.17 Generating Keying Material for CHILD_SAs...............32 82 2.18 Rekeying IKE_SAs using a CREATE_CHILD_SA exchange......33 83 2.19 Requesting an internal address on a remote network.....33 84 2.20 Requesting a Peer's Version............................35 85 2.21 Error Handling.........................................35 86 2.22 IPComp.................................................36 87 2.23 NAT Traversal..........................................37 88 2.24 ECN (Explicit Congestion Notification).................40 89 3 Header and Payload Formats................................40 90 3.1 The IKE Header..........................................40 91 3.2 Generic Payload Header..................................43 92 3.3 Security Association Payload............................44 93 3.4 Key Exchange Payload....................................54 94 3.5 Identification Payloads.................................55 95 3.6 Certificate Payload.....................................57 96 3.7 Certificate Request Payload.............................60 97 3.8 Authentication Payload..................................62 98 3.9 Nonce Payload...........................................62 99 3.10 Notify Payload.........................................63 100 3.11 Delete Payload.........................................71 101 3.12 Vendor ID Payload......................................72 102 3.13 Traffic Selector Payload...............................73 103 3.14 Encrypted Payload......................................76 104 3.15 Configuration Payload..................................77 105 3.16 Extensible Authentication Protocol (EAP) Payload.......82 106 4 Conformance Requirements..................................84 107 5 Security Considerations...................................86 108 6 IANA Considerations.......................................89 109 7 Acknowledgements..........................................89 110 8 References................................................90 111 8.1 Normative References....................................90 112 8.2 Informative References..................................91 113 Appendix A: Summary of Changes from IKEv1...................94 114 Appendix B: Diffie-Hellman Groups...........................96 115 Change History (To be removed from RFC).....................97 116 Editor's Address...........................................108 117 Full Copyright Statement...................................108 118 Intellectual Property Statement............................108 120 Requirements Terminology 122 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 123 "MAY" that appear in this document are to be interpreted as described 124 in [Bra97]. 126 The term "Expert Review" is to be interpreted as defined in 127 [RFC2434]. 129 1 Introduction 131 IP Security (IPsec) provides confidentiality, data integrity, access 132 control, and data source authentication to IP datagrams. These 133 services are provided by maintaining shared state between the source 134 and the sink of an IP datagram. This state defines, among other 135 things, the specific services provided to the datagram, which 136 cryptographic algorithms will be used to provide the services, and 137 the keys used as input to the cryptographic algorithms. 139 Establishing this shared state in a manual fashion does not scale 140 well. Therefore a protocol to establish this state dynamically is 141 needed. This memo describes such a protocol-- the Internet Key 142 Exchange (IKE). This is version 2 of IKE. Version 1 of IKE was 143 defined in RFCs 2407, 2408, and 2409. This single document is 144 intended to replace all three of those RFCs. 146 Definitions of the primitive terms in this document (such as Security 147 Association or SA) can be found in [RFC2401bis]. 149 IKE performs mutual authentication between two parties and 150 establishes an IKE security association (SA) that includes shared 151 secret information that can be used to efficiently establish SAs for 152 ESP [RFC2406] and/or AH [RFC2402] and a set of cryptographic 153 algorithms to be used by the SAs to protect the traffic that they 154 carry. In this document, the term "suite" or "cryptographic suite" 155 refers to a complete set of algorithms used to protect an SA. An 156 initiator proposes one or more suites by listing supported algorithms 157 that can be combined into suites in a mix and match fashion. IKE can 158 also negotiate use of IPComp [IPCOMP] in connection with an ESP 159 and/or AH SA. We call the IKE SA an "IKE_SA". The SAs for ESP and/or 160 AH that get set up through that IKE_SA we call "CHILD_SA"s. 162 All IKE communications consist of pairs of messages: a request and a 163 response. The pair is called an "exchange". We call the first 164 messages establishing an IKE_SA IKE_SA_INIT and IKE_AUTH exchanges 165 and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL 166 exchanges. In the common case, there is a single IKE_SA_INIT exchange 167 and a single IKE_AUTH exchange (a total of four messages) to 168 establish the IKE_SA and the first CHILD_SA. In exceptional cases, 169 there may be more than one of each of these exchanges. In all cases, 170 all IKE_SA_INIT exchanges MUST complete before any other exchange 171 type, then all IKE_AUTH exchanges MUST complete, and following that 172 any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur 173 in any order. In some scenarios, only a single CHILD_SA is needed 174 between the IPsec endpoints and therefore there would be no 175 additional exchanges. Subsequent exchanges MAY be used to establish 176 additional CHILD_SAs between the same authenticated pair of endpoints 177 and to perform housekeeping functions. 179 IKE message flow always consists of a request followed by a response. 180 It is the responsibility of the requester to ensure reliability. If 181 the response is not received within a timeout interval, the requester 182 needs to retransmit the request (or abandon the connection). 184 The first request/response of an IKE session (IKE_SA_INIT) negotiates 185 security parameters for the IKE_SA, sends nonces, and sends Diffie- 186 Hellman values. 188 The second request/response (IKE_AUTH) transmits identities, proves 189 knowledge of the secrets corresponding to the two identities, and 190 sets up an SA for the first (and often only) AH and/or ESP CHILD_SA. 192 The types of subsequent exchanges are CREATE_CHILD_SA (which creates 193 a CHILD_SA), and INFORMATIONAL (which deletes an SA, reports error 194 conditions, or does other housekeeping). Every request requires a 195 response. An INFORMATIONAL request with no payloads (other than the 196 empty Encrypted payload required by the syntax) is commonly used as a 197 check for liveness. These subsequent exchanges cannot be used until 198 the initial exchanges have completed. 200 In the description that follows, we assume that no errors occur. 201 Modifications to the flow should errors occur are described in 202 section 2.21. 204 1.1 Usage Scenarios 206 IKE is expected to be used to negotiate ESP and/or AH SAs in a number 207 of different scenarios, each with its own special requirements. 209 1.1.1 Security Gateway to Security Gateway Tunnel 211 +-+-+-+-+-+ +-+-+-+-+-+ 212 ! ! IPsec ! ! 213 Protected !Tunnel ! Tunnel !Tunnel ! Protected 214 Subnet <-->!Endpoint !<---------->!Endpoint !<--> Subnet 215 ! ! ! ! 216 +-+-+-+-+-+ +-+-+-+-+-+ 218 Figure 1: Security Gateway to Security Gateway Tunnel 220 In this scenario, neither endpoint of the IP connection implements 221 IPsec, but network nodes between them protect traffic for part of the 222 way. Protection is transparent to the endpoints, and depends on 223 ordinary routing to send packets through the tunnel endpoints for 224 processing. Each endpoint would announce the set of addresses 225 "behind" it, and packets would be sent in Tunnel Mode where the inner 226 IP header would contain the IP addresses of the actual endpoints. 228 1.1.2 Endpoint to Endpoint Transport 230 +-+-+-+-+-+ +-+-+-+-+-+ 231 ! ! IPsec Transport ! ! 232 !Protected! or Tunnel Mode SA !Protected! 233 !Endpoint !<---------------------------------------->!Endpoint ! 234 ! ! ! ! 235 +-+-+-+-+-+ +-+-+-+-+-+ 237 Figure 2: Endpoint to Endpoint 239 In this scenario, both endpoints of the IP connection implement 240 IPsec, as required of hosts in [RFC2401bis]. Transport mode will 241 commonly be used with no inner IP header. If there is an inner IP 242 header, the inner addresses will be the same as the outer addresses. 243 A single pair of addresses will be negotiated for packets to be 244 protected by this SA. These endpoints MAY implement application layer 245 access controls based on the IPsec authenticated identities of the 246 participants. This scenario enables the end-to-end security that has 247 been a guiding principle for the Internet since [RFC1958], [RFC2775], 248 and a method of limiting the inherent problems with complexity in 249 networks noted by [RFC3439]. While this scenario may not be fully 250 applicable to the IPv4 Internet, it has been deployed successfully in 251 specific scenarios within intranets using IKEv1. It should be more 252 broadly enabled during the transition to IPv6 and with the adoption 253 of IKEv2. 255 It is possible in this scenario that one or both of the protected 256 endpoints will be behind a network address translation (NAT) node, in 257 which case the tunneled packets will have to be UDP encapsulated so 258 that port numbers in the UDP headers can be used to identify 259 individual endpoints "behind" the NAT (see section 2.23). 261 1.1.3 Endpoint to Security Gateway Transport 263 +-+-+-+-+-+ +-+-+-+-+-+ 264 ! ! IPsec ! ! Protected 265 !Protected! Tunnel !Tunnel ! Subnet 266 !Endpoint !<------------------------>!Endpoint !<--- and/or 267 ! ! ! ! Internet 268 +-+-+-+-+-+ +-+-+-+-+-+ 270 Figure 3: Endpoint to Security Gateway Tunnel 272 In this scenario, a protected endpoint (typically a portable roaming 273 computer) connects back to its corporate network through an IPsec 274 protected tunnel. It might use this tunnel only to access information 275 on the corporate network or it might tunnel all of its traffic back 276 through the corporate network in order to take advantage of 277 protection provided by a corporate firewall against Internet based 278 attacks. In either case, the protected endpoint will want an IP 279 address associated with the security gateway so that packets returned 280 to it will go to the security gateway and be tunneled back. This IP 281 address may be static or may be dynamically allocated by the security 282 gateway. In support of the latter case, IKEv2 includes a mechanism 283 for the initiator to request an IP address owned by the security 284 gateway for use for the duration of its SA. 286 In this scenario, packets will use tunnel mode. On each packet from 287 the protected endpoint, the outer IP header will contain the source 288 IP address associated with its current location (i.e., the address 289 that will get traffic routed to the endpoint directly) while the 290 inner IP header will contain the source IP address assigned by the 291 security gateway (i.e., the address that will get traffic routed to 292 the security gateway for forwarding to the endpoint). The outer 293 destination address will always be that of the security gateway, 294 while the inner destination address will be the ultimate destination 295 for the packet. 297 In this scenario, it is possible that the protected endpoint will be 298 behind a NAT. In that case, the IP address as seen by the security 299 gateway will not be the same as the IP address sent by the protected 300 endpoint, and packets will have to be UDP encapsulated in order to be 301 routed properly. 303 1.1.4 Other Scenarios 305 Other scenarios are possible, as are nested combinations of the 306 above. One notable example combines aspects of 1.1.1 and 1.1.3. A 307 subnet may make all external accesses through a remote security 308 gateway using an IPsec tunnel, where the addresses on the subnet are 309 routed to the security gateway by the rest of the Internet. An 310 example would be someone's home network being virtually on the 311 Internet with static IP addresses even though connectivity is 312 provided by an ISP that assigns a single dynamically assigned IP 313 address to the user's security gateway (where the static IP addresses 314 and an IPsec relay is provided by a third party located elsewhere). 316 1.2 The Initial Exchanges 318 Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH 319 exchanges (known in IKEv1 as Phase 1). These initial exchanges 320 normally consist of four messages, though in some scenarios that 321 number can grow. All communications using IKE consist of 322 request/response pairs. We'll describe the base exchange first, 323 followed by variations. The first pair of messages (IKE_SA_INIT) 324 negotiate cryptographic algorithms, exchange nonces, and do a Diffie- 325 Hellman exchange. 327 The second pair of messages (IKE_AUTH) authenticate the previous 328 messages, exchange identities and certificates, and establish the 329 first CHILD_SA. Parts of these messages are encrypted and integrity 330 protected with keys established through the IKE_SA_INIT exchange, so 331 the identities are hidden from eavesdroppers and all fields in all 332 the messages are authenticated. 334 In the following description, the payloads contained in the message 335 are indicated by names such as SA. The details of the contents of 336 each payload are described later. Payloads which may optionally 337 appear will be shown in brackets, such as [CERTREQ], would indicate 338 that optionally a certificate request payload can be included. 340 The initial exchanges are as follows: 342 Initiator Responder 343 ----------- ----------- 344 HDR, SAi1, KEi, Ni --> 346 HDR contains the SPIs, version numbers, and flags of various sorts. 347 The SAi1 payload states the cryptographic algorithms the initiator 348 supports for the IKE_SA. The KE payload sends the initiator's 349 Diffie-Hellman value. Ni is the initiator's nonce. 351 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 353 The responder chooses a cryptographic suite from the initiator's 354 offered choices and expresses that choice in the SAr1 payload, 355 completes the Diffie-Hellman exchange with the KEr payload, and sends 356 its nonce in the Nr payload. 358 At this point in the negotiation each party can generate SKEYSEED, 359 from which all keys are derived for that IKE_SA. All but the headers 360 of all the messages that follow are encrypted and integrity 361 protected. The keys used for the encryption and integrity protection 362 are derived from SKEYSEED and are known as SK_e (encryption) and SK_a 363 (authentication, a.k.a. integrity protection). A separate SK_e and 364 SK_a is computed for each direction. In addition to the keys SK_e 365 and SK_a derived from the DH value for protection of the IKE_SA, 366 another quantity SK_d is derived and used for derivation of further 367 keying material for CHILD_SAs. The notation SK { ... } indicates 368 that these payloads are encrypted and integrity protected using that 369 direction's SK_e and SK_a. 371 HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] 372 AUTH, SAi2, TSi, TSr} --> 374 The initiator asserts its identity with the IDi payload, proves 375 knowledge of the secret corresponding to IDi and integrity protects 376 the contents of the first message using the AUTH payload (see section 377 2.15). It might also send its certificate(s) in CERT payload(s) and 378 a list of its trust anchors in CERTREQ payload(s). If any CERT 379 payloads are included, the first certificate provided MUST contain 380 the public key used to verify the AUTH field. The optional payload 381 IDr enables the initiator to specify which of the responder's 382 identities it wants to talk to. This is useful when the machine on 383 which the responder is running is hosting multiple identities at the 384 same IP address. The initiator begins negotiation of a CHILD_SA 385 using the SAi2 payload. The final fields (starting with SAi2) are 386 described in the description of the CREATE_CHILD_SA exchange. 388 <-- HDR, SK {IDr, [CERT,] AUTH, 389 SAr2, TSi, TSr} 391 The responder asserts its identity with the IDr payload, optionally 392 sends one or more certificates (again with the certificate containing 393 the public key used to verify AUTH listed first), authenticates its 394 identity and protects the integrity of the second message with the 395 AUTH payload, and completes negotiation of a CHILD_SA with the 396 additional fields described below in the CREATE_CHILD_SA exchange. 398 The recipients of messages 3 and 4 MUST verify that all signatures 399 and MACs are computed correctly and that the names in the ID payloads 400 correspond to the keys used to generate the AUTH payload. 402 1.3 The CREATE_CHILD_SA Exchange 404 This exchange consists of a single request/response pair, and was 405 referred to as a phase 2 exchange in IKEv1. It MAY be initiated by 406 either end of the IKE_SA after the initial exchanges are completed. 408 All messages following the initial exchange are cryptographically 409 protected using the cryptographic algorithms and keys negotiated in 410 the first two messages of the IKE exchange. These subsequent 411 messages use the syntax of the Encrypted Payload described in section 412 3.14. All subsequent messages included an Encrypted Payload, even if 413 they are referred to in the text as "empty". 415 Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this 416 section the term initiator refers to the endpoint initiating this 417 exchange. 419 A CHILD_SA is created by sending a CREATE_CHILD_SA request. The 420 CREATE_CHILD_SA request MAY optionally contain a KE payload for an 421 additional Diffie-Hellman exchange to enable stronger guarantees of 422 forward secrecy for the CHILD_SA. The keying material for the 423 CHILD_SA is a function of SK_d established during the establishment 424 of the IKE_SA, the nonces exchanged during the CREATE_CHILD_SA 425 exchange, and the Diffie-Hellman value (if KE payloads are included 426 in the CREATE_CHILD_SA exchange). 428 In the CHILD_SA created as part of the initial exchange, a second KE 429 payload and nonce MUST NOT be sent. The nonces from the initial 430 exchange are used in computing the keys for the CHILD_SA. 432 The CREATE_CHILD_SA request contains: 434 Initiator Responder 435 ----------- ----------- 436 HDR, SK {[N], SA, Ni, [KEi], 437 [TSi, TSr]} --> 439 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni 440 payload, optionally a Diffie-Hellman value in the KEi payload, and 441 the proposed traffic selectors in the TSi and TSr payloads. If this 442 CREATE_CHILD_SA exchange is rekeying an existing SA other than the 443 IKE_SA, the leading N payload of type REKEY_SA MUST identify the SA 444 being rekeyed. If this CREATE_CHILD_SA exchange is not rekeying an 445 existing SA, the N payload MUST be omitted. If the SA offers include 446 different Diffie-Hellman groups, KEi MUST be an element of the group 447 the initiator expects the responder to accept. If it guesses wrong, 448 the CREATE_CHILD_SA exchange will fail and it will have to retry with 449 a different KEi. 451 The message following the header is encrypted and the message 452 including the header is integrity protected using the cryptographic 453 algorithms negotiated for the IKE_SA. 455 The CREATE_CHILD_SA response contains: 457 <-- HDR, SK {SA, Nr, [KEr], 458 [TSi, TSr]} 460 The responder replies (using the same Message ID to respond) with the 461 accepted offer in an SA payload, and a Diffie-Hellman value in the 462 KEr payload if KEi was included in the request and the selected 463 cryptographic suite includes that group. If the responder chooses a 464 cryptographic suite with a different group, it MUST reject the 465 request. The initiator SHOULD repeat the request, but now with a KEi 466 payload from the group the responder selected. 468 The traffic selectors for traffic to be sent on that SA are specified 469 in the TS payloads, which may be a subset of what the initiator of 470 the CHILD_SA proposed. Traffic selectors are omitted if this 471 CREATE_CHILD_SA request is being used to change the key of the 472 IKE_SA. 474 1.4 The INFORMATIONAL Exchange 476 At various points during the operation of an IKE_SA, peers may desire 477 to convey control messages to each other regarding errors or 478 notifications of certain events. To accomplish this IKE defines an 479 INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur 480 after the initial exchanges and are cryptographically protected with 481 the negotiated keys. 483 Control messages that pertain to an IKE_SA MUST be sent under that 484 IKE_SA. Control messages that pertain to CHILD_SAs MUST be sent under 485 the protection of the IKE_SA which generated them (or its successor 486 if the IKE_SA was replaced for the purpose of rekeying). 488 Messages in an INFORMATIONAL Exchange contain zero or more 489 Notification, Delete, and Configuration payloads. The Recipient of an 490 INFORMATIONAL Exchange request MUST send some response (else the 491 Sender will assume the message was lost in the network and will 492 retransmit it). That response MAY be a message with no payloads. The 493 request message in an INFORMATIONAL Exchange MAY also contain no 494 payloads. This is the expected way an endpoint can ask the other 495 endpoint to verify that it is alive. 497 ESP and AH SAs always exist in pairs, with one SA in each direction. 498 When an SA is closed, both members of the pair MUST be closed. When 499 SAs are nested, as when data (and IP headers if in tunnel mode) are 500 encapsulated first with IPComp, then with ESP, and finally with AH 501 between the same pair of endpoints, all of the SAs MUST be deleted 502 together. Each endpoint MUST close its incoming SAs and allow the 503 other endpoint to close the other SA in each pair. To delete an SA, 504 an INFORMATIONAL Exchange with one or more delete payloads is sent 505 listing the SPIs (as they would be expected in the headers of inbound 506 packets) of the SAs to be deleted. The recipient MUST close the 507 designated SAs. Normally, the reply in the INFORMATIONAL Exchange 508 will contain delete payloads for the paired SAs going in the other 509 direction. There is one exception. If by chance both ends of a set 510 of SAs independently decide to close them, each may send a delete 511 payload and the two requests may cross in the network. If a node 512 receives a delete request for SAs for which it has already issued a 513 delete request, it MUST delete the outgoing SAs while processing the 514 request and the incoming SAs while processing the response. In that 515 case, the responses MUST NOT include delete payloads for the deleted 516 SAs, since that would result in duplicate deletion and could in 517 theory delete the wrong SA. 519 A node SHOULD regard half closed connections as anomalous and audit 520 their existence should they persist. Note that this specification 521 nowhere specifies time periods, so it is up to individual endpoints 522 to decide how long to wait. A node MAY refuse to accept incoming data 523 on half closed connections but MUST NOT unilaterally close them and 524 reuse the SPIs. If connection state becomes sufficiently messed up, a 525 node MAY close the IKE_SA which will implicitly close all SAs 526 negotiated under it. It can then rebuild the SAs it needs on a clean 527 base under a new IKE_SA. 529 The INFORMATIONAL Exchange is defined as: 531 Initiator Responder 532 ----------- ----------- 533 HDR, SK {[N,] [D,] [CP,] ...} --> 534 <-- HDR, SK {[N,] [D,] [CP], ...} 536 The processing of an INFORMATIONAL Exchange is determined by its 537 component payloads. 539 1.5 Informational Messages outside of an IKE_SA 541 If an encrypted IKE packet arrives on port 500 or 4500 with an 542 unrecognized SPI, it could be because the receiving node has recently 543 crashed and lost state or because of some other system malfunction or 544 attack. If the receiving node has an active IKE_SA to the IP address 545 from whence the packet came, it MAY send a notification of the 546 wayward packet over that IKE_SA in an informational exchange. If it 547 does not have such an IKE_SA, it MAY send an Informational message 548 without cryptographic protection to the source IP address. Such a 549 message is not part of an informational exchange, and the receiving 550 node MUST NOT respond to it. Doing so could cause a message loop. 552 2 IKE Protocol Details and Variations 554 IKE normally listens and sends on UDP port 500, though IKE messages 555 may also be received on UDP port 4500 with a slightly different 556 format (see section 2.23). Since UDP is a datagram (unreliable) 557 protocol, IKE includes in its definition recovery from transmission 558 errors, including packet loss, packet replay, and packet forgery. IKE 559 is designed to function so long as (1) at least one of a series of 560 retransmitted packets reaches its destination before timing out; and 561 (2) the channel is not so full of forged and replayed packets so as 562 to exhaust the network or CPU capacities of either endpoint. Even in 563 the absence of those minimum performance requirements, IKE is 564 designed to fail cleanly (as though the network were broken). 566 While IKEv2 messages are intended to be short, they contain 567 structures with no hard upper bound on size (in particular, X.509 568 certificates), and IKEv2 itself does not have a mechanism for 569 fragmenting large messages. IP defines a mechanism for fragmentation 570 of oversize UDP messages, but implementations vary in the maximum 571 message size supported. Further, use of IP fragmentation opens an 572 implementation to denial of service attacks [KPS03]. Finally, some 573 NAT and/or firewall implementations may block IP fragments. 575 All IKEv2 implementations MUST be able to send, receive, and process 576 IKE messages that are up to 1280 bytes long, and they SHOULD be able 577 to send, receive, and process messages that are up to 3000 bytes 578 long. IKEv2 implementations SHOULD be aware of the maximum UDP 579 message size supported and MAY shorten messages by leaving out some 580 certificates or cryptographic suite proposals if that will keep 581 messages below the maximum. Use of the "Hash and URL" formats rather 582 then including certificates in exchanges where possible can avoid 583 most problems. Implementations and configuration should keep in mind, 584 however, that if the URL lookups are only possible after the IPsec SA 585 is established, recursion issues could prevent this technique from 586 working. 588 2.1 Use of Retransmission Timers 590 All messages in IKE exist in pairs: a request and a response. The 591 setup of an IKE_SA normally consists of two request/response pairs. 592 Once the IKE_SA is set up, either end of the security association may 593 initiate requests at any time, and there can be many requests and 594 responses "in flight" at any given moment. But each message is 595 labeled as either a request or a response and for each 596 request/response pair one end of the security association is the 597 initiator and the other is the responder. 599 For every pair of IKE messages, the initiator is responsible for 600 retransmission in the event of a timeout. The responder MUST never 601 retransmit a response unless it receives a retransmission of the 602 request. In that event, the responder MUST ignore the retransmitted 603 request except insofar as it triggers a retransmission of the 604 response. The initiator MUST remember each request until it receives 605 the corresponding response. The responder MUST remember each response 606 until it receives a request whose sequence number is larger than the 607 sequence number in the response plus its window size (see section 608 2.3). 610 IKE is a reliable protocol, in the sense that the initiator MUST 611 retransmit a request until either it receives a corresponding reply 612 OR it deems the IKE security association to have failed and it 613 discards all state associated with the IKE_SA and any CHILD_SAs 614 negotiated using that IKE_SA. 616 2.2 Use of Sequence Numbers for Message ID 618 Every IKE message contains a Message ID as part of its fixed header. 619 This Message ID is used to match up requests and responses, and to 620 identify retransmissions of messages. 622 The Message ID is a 32 bit quantity, which is zero for the first IKE 623 request in each direction. The IKE_SA initial setup messages will 624 always be numbered 0 and 1. Each endpoint in the IKE Security 625 Association maintains two "current" Message IDs: the next one to be 626 used for a request it initiates and the next one it expects to see in 627 a request from the other end. These counters increment as requests 628 are generated and received. Responses always contain the same message 629 ID as the corresponding request. That means that after the initial 630 exchange, each integer n may appear as the message ID in four 631 distinct messages: The nth request from the original IKE initiator, 632 the corresponding response, the nth request from the original IKE 633 responder, and the corresponding response. If the two ends make very 634 different numbers of requests, the Message IDs in the two directions 635 can be very different. There is no ambiguity in the messages, 636 however, because the (I)nitiator and (R)esponse bits in the message 637 header specify which of the four messages a particular one is. 639 Note that Message IDs are cryptographically protected and provide 640 protection against message replays. In the unlikely event that 641 Message IDs grow too large to fit in 32 bits, the IKE_SA MUST be 642 closed. Rekeying an IKE_SA resets the sequence numbers. 644 2.3 Window Size for overlapping requests 646 In order to maximize IKE throughput, an IKE endpoint MAY issue 647 multiple requests before getting a response to any of them if the 648 other endpoint has indicated its ability to handle such requests. For 649 simplicity, an IKE implementation MAY choose to process requests 650 strictly in order and/or wait for a response to one request before 651 issuing another. Certain rules must be followed to assure 652 interoperability between implementations using different strategies. 654 After an IKE_SA is set up, either end can initiate one or more 655 requests. These requests may pass one another over the network. An 656 IKE endpoint MUST be prepared to accept and process a request while 657 it has a request outstanding in order to avoid a deadlock in this 658 situation. An IKE endpoint SHOULD be prepared to accept and process 659 multiple requests while it has a request outstanding. 661 An IKE endpoint MUST wait for a response to each of its messages 662 before sending a subsequent message unless it has received a 663 SET_WINDOW_SIZE Notify message from its peer informing it that the 664 peer is prepared to maintain state for multiple outstanding messages 665 in order to allow greater throughput. 667 An IKE endpoint MUST NOT exceed the peer's stated window size for 668 transmitted IKE requests. In other words, if the responder stated its 669 window size is N, then when the initiator needs to make a request X, 670 it MUST wait until it has received responses to all requests up 671 through request X-N. An IKE endpoint MUST keep a copy of (or be able 672 to regenerate exactly) each request it has sent until it receives the 673 corresponding response. An IKE endpoint MUST keep a copy of (or be 674 able to regenerate exactly) the number of previous responses equal to 675 its declared window size in case its response was lost and the 676 initiator requests its retransmission by retransmitting the request. 678 An IKE endpoint supporting a window size greater than one SHOULD be 679 capable of processing incoming requests out of order to maximize 680 performance in the event of network failures or packet reordering. 682 2.4 State Synchronization and Connection Timeouts 684 An IKE endpoint is allowed to forget all of its state associated with 685 an IKE_SA and the collection of corresponding CHILD_SAs at any time. 686 This is the anticipated behavior in the event of an endpoint crash 687 and restart. It is important when an endpoint either fails or 688 reinitializes its state that the other endpoint detect those 689 conditions and not continue to waste network bandwidth by sending 690 packets over discarded SAs and having them fall into a black hole. 692 Since IKE is designed to operate in spite of Denial of Service (DoS) 693 attacks from the network, an endpoint MUST NOT conclude that the 694 other endpoint has failed based on any routing information (e.g., 695 ICMP messages) or IKE messages that arrive without cryptographic 696 protection (e.g., Notify messages complaining about unknown SPIs). An 697 endpoint MUST conclude that the other endpoint has failed only when 698 repeated attempts to contact it have gone unanswered for a timeout 699 period or when a cryptographically protected INITIAL_CONTACT 700 notification is received on a different IKE_SA to the same 701 authenticated identity. An endpoint SHOULD suspect that the other 702 endpoint has failed based on routing information and initiate a 703 request to see whether the other endpoint is alive. To check whether 704 the other side is alive, IKE specifies an empty INFORMATIONAL message 705 that (like all IKE requests) requires an acknowledgment (note that 706 within the context of an IKE_SA, an "empty" message consists of an 707 IKE header followed by an Encrypted payload that contains no 708 payloads). If a cryptographically protected message has been received 709 from the other side recently, unprotected notifications MAY be 710 ignored. Implementations MUST limit the rate at which they take 711 actions based on unprotected messages. 713 Numbers of retries and lengths of timeouts are not covered in this 714 specification because they do not affect interoperability. It is 715 suggested that messages be retransmitted at least a dozen times over 716 a period of at least several minutes before giving up on an SA, but 717 different environments may require different rules. To be a good 718 network citizen, retranmission times MUST increase exponentially to 719 avoid flooding the network and making an existing congestion 720 situation worse. If there has only been outgoing traffic on all of 721 the SAs associated with an IKE_SA, it is essential to confirm 722 liveness of the other endpoint to avoid black holes. If no 723 cryptographically protected messages have been received on an IKE_SA 724 or any of its CHILD_SAs recently, the system needs to perform a 725 liveness check in order to prevent sending messages to a dead peer. 726 Receipt of a fresh cryptographically protected message on an IKE_SA 727 or any of its CHILD_SAs assures liveness of the IKE_SA and all of its 728 CHILD_SAs. Note that this places requirements on the failure modes of 729 an IKE endpoint. An implementation MUST NOT continue sending on any 730 SA if some failure prevents it from receiving on all of the 731 associated SAs. If CHILD_SAs can fail independently from one another 732 without the associated IKE_SA being able to send a delete message, 733 then they MUST be negotiated by separate IKE_SAs. 735 There is a Denial of Service attack on the initiator of an IKE_SA 736 that can be avoided if the initiator takes the proper care. Since the 737 first two messages of an SA setup are not cryptographically 738 protected, an attacker could respond to the initiator's message 739 before the genuine responder and poison the connection setup attempt. 740 To prevent this, the initiator MAY be willing to accept multiple 741 responses to its first message, treat each as potentially legitimate, 742 respond to it, and then discard all the invalid half open connections 743 when it receives a valid cryptographically protected response to any 744 one of its requests. Once a cryptographically valid response is 745 received, all subsequent responses should be ignored whether or not 746 they are cryptographically valid. 748 Note that with these rules, there is no reason to negotiate and agree 749 upon an SA lifetime. If IKE presumes the partner is dead, based on 750 repeated lack of acknowledgment to an IKE message, then the IKE SA 751 and all CHILD_SAs set up through that IKE_SA are deleted. 753 An IKE endpoint may at any time delete inactive CHILD_SAs to recover 754 resources used to hold their state. If an IKE endpoint chooses to 755 delete CHILD_SAs, it MUST send Delete payloads to the other end 756 notifying it of the deletion. It MAY similarly time out the IKE_SA. 757 Closing the IKE_SA implicitly closes all associated CHILD_SAs. In 758 this case, an IKE endpoint SHOULD send a Delete payload indicating 759 that it has closed the IKE_SA. 761 2.5 Version Numbers and Forward Compatibility 763 This document describes version 2.0 of IKE, meaning the major version 764 number is 2 and the minor version number is zero. It is likely that 765 some implementations will want to support both version 1.0 and 766 version 2.0, and in the future, other versions. 768 The major version number should only be incremented if the packet 769 formats or required actions have changed so dramatically that an 770 older version node would not be able to interoperate with a newer 771 version node if it simply ignored the fields it did not understand 772 and took the actions specified in the older specification. The minor 773 version number indicates new capabilities, and MUST be ignored by a 774 node with a smaller minor version number, but used for informational 775 purposes by the node with the larger minor version number. For 776 example, it might indicate the ability to process a newly defined 777 notification message. The node with the larger minor version number 778 would simply note that its correspondent would not be able to 779 understand that message and therefore would not send it. 781 If an endpoint receives a message with a higher major version number, 782 it MUST drop the message and SHOULD send an unauthenticated 783 notification message containing the highest version number it 784 supports. If an endpoint supports major version n, and major version 785 m, it MUST support all versions between n and m. If it receives a 786 message with a major version that it supports, it MUST respond with 787 that version number. In order to prevent two nodes from being tricked 788 into corresponding with a lower major version number than the maximum 789 that they both support, IKE has a flag that indicates that the node 790 is capable of speaking a higher major version number. 792 Thus the major version number in the IKE header indicates the version 793 number of the message, not the highest version number that the 794 transmitter supports. If the initiator is capable of speaking 795 versions n, n+1, and n+2, and the responder is capable of speaking 796 versions n and n+1, then they will negotiate speaking n+1, where the 797 initiator will set the flag indicating its ability to speak a higher 798 version. If they mistakenly (perhaps through an active attacker 799 sending error messages) negotiate to version n, then both will notice 800 that the other side can support a higher version number, and they 801 MUST break the connection and reconnect using version n+1. 803 Note that IKEv1 does not follow these rules, because there is no way 804 in v1 of noting that you are capable of speaking a higher version 805 number. So an active attacker can trick two v2-capable nodes into 806 speaking v1. When a v2-capable node negotiates down to v1, it SHOULD 807 note that fact in its logs. 809 Also for forward compatibility, all fields marked RESERVED MUST be 810 set to zero by a version 2.0 implementation and their content MUST be 811 ignored by a version 2.0 implementation ("Be conservative in what you 812 send and liberal in what you receive"). In this way, future versions 813 of the protocol can use those fields in a way that is guaranteed to 814 be ignored by implementations that do not understand them. 815 Similarly, payload types that are not defined are reserved for future 816 use and implementations of version 2.0 MUST skip over those payloads 817 and ignore their contents. 819 IKEv2 adds a "critical" flag to each payload header for further 820 flexibility for forward compatibility. If the critical flag is set 821 and the payload type is unrecognized, the message MUST be rejected 822 and the response to the IKE request containing that payload MUST 823 include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an 824 unsupported critical payload was included. If the critical flag is 825 not set and the payload type is unsupported, that payload MUST be 826 ignored. 828 While new payload types may be added in the future and may appear 829 interleaved with the fields defined in this specification, 830 implementations MUST send the payloads defined in this specification 831 in the order shown in the figures in section 2 and implementations 832 SHOULD reject as invalid a message with those payloads in any other 833 order. 835 2.6 Cookies 837 The term "cookies" originates with Karn and Simpson [RFC2522] in 838 Photuris, an early proposal for key management with IPsec, and it has 839 persisted. The ISAKMP fixed message header includes two eight octet 840 fields titled "cookies", and that syntax is used by both IKEv1 and 841 IKEv2 though in IKEv2 they are referred to as the IKE SPI and there 842 is a new separate field in a Notify payload holding the cookie. The 843 initial two eight octet fields in the header are used as a connection 844 identifier at the beginning of IKE packets. Each endpoint chooses one 845 of the two SPIs and SHOULD choose them so as to be unique identifiers 846 of an IKE_SA. An SPI value of zero is special and indicates that the 847 remote SPI value is not yet known by the sender. 849 Unlike ESP and AH where only the recipient's SPI appears in the 850 header of a message, in IKE the sender's SPI is also sent in every 851 message. Since the SPI chosen by the original initiator of the IKE_SA 852 is always sent first, an endpoint with multiple IKE_SAs open that 853 wants to find the appropriate IKE_SA using the SPI it assigned must 854 look at the I(nitiator) Flag bit in the header to determine whether 855 it assigned the first or the second eight octets. 857 In the first message of an initial IKE exchange, the initiator will 858 not know the responder's SPI value and will therefore set that field 859 to zero. 861 An expected attack against IKE is state and CPU exhaustion, where the 862 target is flooded with session initiation requests from forged IP 863 addresses. This attack can be made less effective if an 864 implementation of a responder uses minimal CPU and commits no state 865 to an SA until it knows the initiator can receive packets at the 866 address from which it claims to be sending them. To accomplish this, 867 a responder SHOULD - when it detects a large number of half-open 868 IKE_SAs - reject initial IKE messages unless they contain a Notify 869 payload of type COOKIE. It SHOULD instead send an unprotected IKE 870 message as a response and include COOKIE Notify payload with the 871 cookie data to be returned. Initiators who receive such responses 872 MUST retry the IKE_SA_INIT with a Notify payload of type COOKIE 873 containing the responder supplied cookie data as the first payload 874 and all other payloads unchanged. The initial exchange will then be 875 as follows: 877 Initiator Responder 878 ----------- ----------- 879 HDR(A,0), SAi1, KEi, Ni --> 881 <-- HDR(A,0), N(COOKIE) 883 HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> 885 <-- HDR(A,B), SAr1, KEr, Nr, [CERTREQ] 887 HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,] 888 AUTH, SAi2, TSi, TSr} --> 890 <-- HDR(A,B), SK {IDr, [CERT,] AUTH, 891 SAr2, TSi, TSr} 893 The first two messages do not affect any initiator or responder state 894 except for communicating the cookie. In particular, the message 895 sequence numbers in the first four messages will all be zero and the 896 message sequence numbers in the last two messages will be one. 'A' is 897 the SPI assigned by the initiator, while 'B' is the SPI assigned by 898 the responder. 900 An IKE implementation SHOULD implement its responder cookie 901 generation in such a way as to not require any saved state to 902 recognize its valid cookie when the second IKE_SA_INIT message 903 arrives. The exact algorithms and syntax they use to generate 904 cookies does not affect interoperability and hence is not specified 905 here. The following is an example of how an endpoint could use 906 cookies to implement limited DOS protection. 908 A good way to do this is to set the responder cookie to be: 910 Cookie = | Hash(Ni | IPi | SPIi | ) 912 where is a randomly generated secret known only to the 913 responder and periodically changed and | indicates concatenation. 914 should be changed whenever is 915 regenerated. The cookie can be recomputed when the IKE_SA_INIT 916 arrives the second time and compared to the cookie in the received 917 message. If it matches, the responder knows that SPIr was generated 918 since the last change to and that IPi must be the same as 919 the source address it saw the first time. Incorporating SPIi into the 920 calculation assures that if multiple IKE_SAs are being set up in 921 parallel they will all get different cookies (assuming the initiator 922 chooses unique SPIi's). Incorporating Ni into the hash assures that 923 an attacker who sees only message 2 can't successfully forge a 924 message 3. 926 If a new value for is chosen while there are connections in 927 the process of being initialized, an IKE_SA_INIT might be returned 928 with other than the current . The responder in 929 that case MAY reject the message by sending another response with a 930 new cookie or it MAY keep the old value of around for a 931 short time and accept cookies computed from either one. The 932 responder SHOULD NOT accept cookies indefinitely after is 933 changed, since that would defeat part of the denial of service 934 protection. The responder SHOULD change the value of 935 frequently, especially if under attack. 937 2.7 Cryptographic Algorithm Negotiation 939 The payload type known as "SA" indicates a proposal for a set of 940 choices of IPsec protocols (IKE, ESP, and/or AH) for the SA as well 941 as cryptographic algorithms associated with each protocol. 943 An SA payload consists of one or more proposals. Each proposal 944 includes one or more protocols (usually one). Each protocol contains 945 one or more transforms - each specifying a cryptographic algorithm. 946 Each transform contains zero or more attributes (attributes are only 947 needed if the transform identifier does not completely specify the 948 cryptographic algorithm). 950 This hierarchical structure was designed to efficiently encode 951 proposals for cryptographic suites when the number of supported 952 suites is large because multiple values are acceptable for multiple 953 transforms. The responder MUST choose a single suite, which MAY be 954 any subset of the SA proposal following the rules below: 956 Each proposal contains one or more protocols. If a proposal is 957 accepted, the SA response MUST contain the same protocols in the 958 same order as the proposal. The responder MUST accept a single 959 proposal or reject them all and return an error. (Example: if a 960 single proposal contains ESP and AH and that proposal is accepted, 961 both ESP and AH MUST be accepted. If ESP and AH are included in 962 separate proposals, the responder MUST accept only one of them). 964 Each IPsec protocol proposal contains one or more transforms. Each 965 transform contains a transform type. The accepted cryptographic 966 suite MUST contain exactly one transform of each type included in 967 the proposal. For example: if an ESP proposal includes transforms 968 ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256, 969 AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain 970 one of the ENCR_ transforms and one of the AUTH_ transforms. Thus 971 six combinations are acceptable. 973 Since the initiator sends its Diffie-Hellman value in the 974 IKE_SA_INIT, it must guess the Diffie-Hellman group that the 975 responder will select from its list of supported groups. If the 976 initiator guesses wrong, the responder will respond with a Notify 977 payload of type INVALID_KE_PAYLOAD indicating the selected group. In 978 this case, the initiator MUST retry the IKE_SA_INIT with the 979 corrected Diffie-Hellman group. The initiator MUST again propose its 980 full set of acceptable cryptographic suites because the rejection 981 message was unauthenticated and otherwise an active attacker could 982 trick the endpoints into negotiating a weaker suite than a stronger 983 one that they both prefer. 985 2.8 Rekeying 987 IKE, ESP, and AH security associations use secret keys which SHOULD 988 only be used for a limited amount of time and to protect a limited 989 amount of data. This limits the lifetime of the entire security 990 association. When the lifetime of a security association expires the 991 security association MUST NOT be used. If there is demand, new 992 security associations MAY be established. Reestablishment of 993 security associations to take the place of ones which expire is 994 referred to as "rekeying". 996 To allow for minimal IPsec implementations, the ability to rekey SAs 997 without restarting the entire IKE_SA is optional. An implementation 998 MAY refuse all CREATE_CHILD_SA requests within an IKE_SA. If an SA 999 has expired or is about to expire and rekeying attempts using the 1000 mechanisms described here fail, an implementation MUST close the 1001 IKE_SA and any associated CHILD_SAs and then MAY start new ones. 1002 Implementations SHOULD support in place rekeying of SAs, since doing 1003 so offers better performance and is likely to reduce the number of 1004 packets lost during the transition. 1006 To rekey a CHILD_SA within an existing IKE_SA, create a new, 1007 equivalent SA (see section 2.17 below), and when the new one is 1008 established, delete the old one. To rekey an IKE_SA, establish a new 1009 equivalent IKE_SA (see section 2.18 below) with the peer to whom the 1010 old IKE_SA is shared using a CREATE_CHILD_SA within the existing 1011 IKE_SA. An IKE_SA so created inherits all of the original IKE_SA's 1012 CHILD_SAs. Use the new IKE_SA for all control messages needed to 1013 maintain the CHILD_SAs created by the old IKE_SA, and delete the old 1014 IKE_SA. The Delete payload to delete itself MUST be the last request 1015 sent over an IKE_SA. 1017 SAs SHOULD be rekeyed proactively, i.e., the new SA should be 1018 established before the old one expires and becomes unusable. Enough 1019 time should elapse between the time the new SA is established and the 1020 old one becomes unusable so that traffic can be switched over to the 1021 new SA. 1023 A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes 1024 were negotiated. In IKEv2, each end of the SA is responsible for 1025 enforcing its own lifetime policy on the SA and rekeying the SA when 1026 necessary. If the two ends have different lifetime policies, the end 1027 with the shorter lifetime will end up always being the one to request 1028 the rekeying. If an SA bundle has been inactive for a long time and 1029 if an endpoint would not initiate the SA in the absence of traffic, 1030 the endpoint MAY choose to close the SA instead of rekeying it when 1031 its lifetime expires. It SHOULD do so if there has been no traffic 1032 since the last time the SA was rekeyed. 1034 If the two ends have the same lifetime policies, it is possible that 1035 both will initiate a rekeying at the same time (which will result in 1036 redundant SAs). To reduce the probability of this happening, the 1037 timing of rekeying requests SHOULD be jittered (delayed by a random 1038 amount of time after the need for rekeying is noticed). 1040 This form of rekeying may temporarily result in multiple similar SAs 1041 between the same pairs of nodes. When there are two SAs eligible to 1042 receive packets, a node MUST accept incoming packets through either 1043 SA. If redundant SAs are created though such a collision, the SA 1044 created with the lowest of the four nonces used in the two exchanges 1045 SHOULD be closed by the endpoint that created it. 1047 Note that IKEv2 deliberately allows parallel SAs with the same 1048 traffic selectors between common endpoints. One of the purposes of 1049 this is to support traffic QoS differences among the SAs (see section 1050 4.1 of [RFC2983]). Hence unlike IKEv1, the combination of the 1051 endpoints and the traffic selectors may not uniquely identify an SA 1052 between those endpoints, so the IKEv1 rekeying heuristic of deleting 1053 SAs on the basis of duplicate traffic selectors SHOULD NOT be used. 1055 The node that initiated the surviving rekeyed SA SHOULD delete the 1056 replaced SA after the new one is established. 1058 There are timing windows - particularly in the presence of lost 1059 packets - where endpoints may not agree on the state of an SA. The 1060 responder to a CREATE_CHILD_SA MUST be prepared to accept messages on 1061 an SA before sending its response to the creation request, so there 1062 is no ambiguity for the initiator. The initiator MAY begin sending on 1063 an SA as soon as it processes the response. The initiator, however, 1064 cannot receive on a newly created SA until it receives and processes 1065 the response to its CREATE_CHILD_SA request. How, then, is the 1066 responder to know when it is OK to send on the newly created SA? 1068 From a technical correctness and interoperability perspective, the 1069 responder MAY begin sending on an SA as soon as it sends its response 1070 to the CREATE_CHILD_SA request. In some situations, however, this 1071 could result in packets unnecessarily being dropped, so an 1072 implementation MAY want to defer such sending. 1074 The responder can be assured that the initiator is prepared to 1075 receive messages on an SA if either (1) it has received a 1076 cryptographically valid message on the new SA, or (2) the new SA 1077 rekeys an existing SA and it receives an IKE request to close the 1078 replaced SA. When rekeying an SA, the responder SHOULD continue to 1079 send requests on the old SA until it one of those events occurs. When 1080 establishing a new SA, the responder MAY defer sending messages on a 1081 new SA until either it receives one or a timeout has occurred. If an 1082 initiator receives a message on an SA for which it has not received a 1083 response to its CREATE_CHILD_SA request, it SHOULD interpret that as 1084 a likely packet loss and retransmit the CREATE_CHILD_SA request. An 1085 initiator MAY send a dummy message on a newly created SA if it has no 1086 messages queued in order to assure the responder that the initiator 1087 is ready to receive messages. 1089 2.9 Traffic Selector Negotiation 1091 When an IP packet is received by an RFC2401 compliant IPsec subsystem 1092 and matches a "protect" selector in its SPD, the subsystem MUST 1093 protect that packet with IPsec. When no SA exists yet it is the task 1094 of IKE to create it. Maintenance of a system's SPD is outside the 1095 scope of IKE (see [PFKEY] for an example protocol), though some 1096 implementations might update their SPD in connection with the running 1097 of IKE (for an example scenario, see section 1.1.3). 1099 Traffic Selector (TS) payloads allow endpoints to communicate some of 1100 the information from their SPD to their peers. TS payloads specify 1101 the selection criteria for packets that will be forwarded over the 1102 newly set up SA. This can serve as a consistency check in some 1103 scenarios to assure that the SPDs are consistent. In others, it 1104 guides the dynamic update of the SPD. 1106 Two TS payloads appear in each of the messages in the exchange that 1107 creates a CHILD_SA pair. Each TS payload contains one or more Traffic 1108 Selectors. Each Traffic Selector consists of an address range (IPv4 1109 or IPv6), a port range, and an IP protocol ID. In support of the 1110 scenario described in section 1.1.3, an initiator may request that 1111 the responder assign an IP address and tell the initiator what it is. 1113 IKEv2 allows the responder to choose a subset of the traffic proposed 1114 by the initiator. This could happen when the configuration of the 1115 two endpoints are being updated but only one end has received the new 1116 information. Since the two endpoints may be configured by different 1117 people, the incompatibility may persist for an extended period even 1118 in the absence of errors. It also allows for intentionally different 1119 configurations, as when one end is configured to tunnel all addresses 1120 and depends on the other end to have the up to date list. 1122 The first of the two TS payloads is known as TSi (Traffic Selector- 1123 initiator). The second is known as TSr (Traffic Selector-responder). 1124 TSi specifies the source address of traffic forwarded from (or the 1125 destination address of traffic forwarded to) the initiator of the 1126 CHILD_SA pair. TSr specifies the destination address of the traffic 1127 forwarded from (or the source address of the traffic forwarded to) 1128 the responder of the CHILD_SA pair. For example, if the original 1129 initiator request the creation of a CHILD_SA pair, and wishes to 1130 tunnel all traffic from subnet 192.0.1.* on the initiator's side to 1131 subnet 192.0.2.* on the responder's side, the initiator would include 1132 a single traffic selector in each TS payload. TSi would specify the 1133 address range (192.0.1.0 - 192.0.1.255) and TSr would specify the 1134 address range (192.0.2.0 - 192.0.2.255). Assuming that proposal was 1135 acceptable to the responder, it would send identical TS payloads 1136 back. [Note: the IP address range 192.0.1.* has been reserved for use 1137 in examples in RFCs and similar documents. This document needed two 1138 such ranges, and so also used 192.0.2.*. This should not be confused 1139 with any actual address]. 1141 The responder is allowed to narrow the choices by selecting a subset 1142 of the traffic, for instance by eliminating or narrowing the range of 1143 one or more members of the set of traffic selectors, provided the set 1144 does not become the NULL set. 1146 It is possible for the responder's policy to contain multiple smaller 1147 ranges, all encompassed by the initiator's traffic selector, and with 1148 the responder's policy being that each of those ranges should be sent 1149 over a different SA. Continuing the example above, the responder 1150 might have a policy of being willing to tunnel those addresses to and 1151 from the initiator, but might require that each address pair be on a 1152 separately negotiated CHILD_SA. If the initiator generated its 1153 request in response to an incoming packet from 192.0.1.43 to 1154 192.0.2.123, there would be no way for the responder to determine 1155 which pair of addresses should be included in this tunnel, and it 1156 would have to make a guess or reject the request with a status of 1157 SINGLE_PAIR_REQUIRED. 1159 To enable the responder to choose the appropriate range in this case, 1160 if the initiator has requested the SA due to a data packet, the 1161 initiator SHOULD include as the first traffic selector in each of TSi 1162 and TSr a very specific traffic selector including the addresses in 1163 the packet triggering the request. In the example, the initiator 1164 would include in TSi two traffic selectors: the first containing the 1165 address range (192.0.1.43 - 192.0.1.43) and the source port and IP 1166 protocol from the packet and the second containing (192.0.1.0 - 1167 192.0.1.255) with all ports and IP protocols. The initiator would 1168 similarly include two traffic selectors in TSr. 1170 If the responder's policy does not allow it to accept the entire set 1171 of traffic selectors in the initiator's request, but does allow him 1172 to accept the first selector of TSi and TSr, then the responder MUST 1173 narrow the traffic selectors to a subset that includes the 1174 initiator's first choices. In this example, the responder might 1175 respond with TSi being (192.0.1.43 - 192.0.1.43) with all ports and 1176 IP protocols. 1178 If the initiator creates the CHILD_SA pair not in response to an 1179 arriving packet, but rather - say - upon startup, then there may be 1180 no specific addresses the initiator prefers for the initial tunnel 1181 over any other. In that case, the first values in TSi and TSr MAY be 1182 ranges rather than specific values, and the responder chooses a 1183 subset of the initiator's TSi and TSr that are acceptable. If more 1184 than one subset is acceptable but their union is not, the responder 1185 MUST accept some subset and MAY include a Notify payload of type 1186 ADDITIONAL_TS_POSSIBLE to indicate that the initiator might want to 1187 try again. This case will only occur when the initiator and responder 1188 are configured differently from one another. If the initiator and 1189 responder agree on the granularity of tunnels, the initiator will 1190 never request a tunnel wider than the responder will accept. Such 1191 misconfigurations SHOULD be recorded in error logs. 1193 2.10 Nonces 1195 The IKE_SA_INIT messages each contain a nonce. These nonces are used 1196 as inputs to cryptographic functions. The CREATE_CHILD_SA request 1197 and the CREATE_CHILD_SA response also contain nonces. These nonces 1198 are used to add freshness to the key derivation technique used to 1199 obtain keys for CHILD_SA, and to ensure creation of strong 1200 pseudorandom bits from the Diffie-Hellman key. Nonces used in IKEv2 1201 MUST be randomly chosen, MUST be at least 128 bits in size, and MUST 1202 be at least half the key size of the negotiated prf. ("prf" refers to 1203 "pseudo-random function", one of the cryptographic algorithms 1204 negotiated in the IKE exchange). If the same random number source is 1205 used for both keys and nonces, care must be taken to ensure that the 1206 latter use does not compromise the former. 1208 2.11 Address and Port Agility 1210 IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and 1211 AH associations for the same IP addresses it runs over. The IP 1212 addresses and ports in the outer header are, however, not themselves 1213 cryptographically protected, and IKE is designed to work even through 1214 Network Address Translation (NAT) boxes. An implementation MUST 1215 accept incoming requests even if the source port is not 500 or 4500, 1216 and MUST respond to the address and port from which the request was 1217 received. It MUST specify the address and port at which the request 1218 was received as the source address and port in the response. IKE 1219 functions identically over IPv4 or IPv6. 1221 2.12 Reuse of Diffie-Hellman Exponentials 1223 IKE generates keying material using an ephemeral Diffie-Hellman 1224 exchange in order to gain the property of "perfect forward secrecy". 1225 This means that once a connection is closed and its corresponding 1226 keys are forgotten, even someone who has recorded all of the data 1227 from the connection and gets access to all of the long-term keys of 1228 the two endpoints cannot reconstruct the keys used to protect the 1229 conversation without doing a brute force search of the session key 1230 space. 1232 Achieving perfect forward secrecy requires that when a connection is 1233 closed, each endpoint MUST forget not only the keys used by the 1234 connection but any information that could be used to recompute those 1235 keys. In particular, it MUST forget the secrets used in the Diffie- 1236 Hellman calculation and any state that may persist in the state of a 1237 pseudo-random number generator that could be used to recompute the 1238 Diffie-Hellman secrets. 1240 Since the computing of Diffie-Hellman exponentials is computationally 1241 expensive, an endpoint may find it advantageous to reuse those 1242 exponentials for multiple connection setups. There are several 1243 reasonable strategies for doing this. An endpoint could choose a new 1244 exponential only periodically though this could result in less-than- 1245 perfect forward secrecy if some connection lasts for less than the 1246 lifetime of the exponential. Or it could keep track of which 1247 exponential was used for each connection and delete the information 1248 associated with the exponential only when some corresponding 1249 connection was closed. This would allow the exponential to be reused 1250 without losing perfect forward secrecy at the cost of maintaining 1251 more state. 1253 Decisions as to whether and when to reuse Diffie-Hellman exponentials 1254 is a private decision in the sense that it will not affect 1255 interoperability. An implementation that reuses exponentials MAY 1256 choose to remember the exponential used by the other endpoint on past 1257 exchanges and if one is reused to avoid the second half of the 1258 calculation. 1260 2.13 Generating Keying Material 1262 In the context of the IKE_SA, four cryptographic algorithms are 1263 negotiated: an encryption algorithm, an integrity protection 1264 algorithm, a Diffie-Hellman group, and a pseudo-random function 1265 (prf). The pseudo-random function is used for the construction of 1266 keying material for all of the cryptographic algorithms used in both 1267 the IKE_SA and the CHILD_SAs. 1269 We assume that each encryption algorithm and integrity protection 1270 algorithm uses a fixed size key, and that any randomly chosen value 1271 of that fixed size can serve as an appropriate key. For algorithms 1272 that accept a variable length key, a fixed key size MUST be specified 1273 as part of the cryptographic transform negotiated. For algorithms 1274 for which not all values are valid keys (such as DES or 3DES with key 1275 parity), they algorithm by which keys are derived from arbitrary 1276 values MUST be specified by the cryptographic transform. For 1277 integrity protection functions based on HMAC, the fixed key size is 1278 the size of the output of the underlying hash function. When the prf 1279 function takes a variable length key, variable length data, and 1280 produces a fixed length output (e.g., when using HMAC), the formulas 1281 in this document apply. When the key for the prf function has fixed 1282 length, the data provided as a key is truncated or padded with zeros 1283 as necessary unless exceptional processing is explained following the 1284 formula. 1286 Keying material will always be derived as the output of the 1287 negotiated prf algorithm. Since the amount of keying material needed 1288 may be greater than the size of the output of the prf algorithm, we 1289 will use the prf iteratively. We will use the terminology prf+ to 1290 describe the function that outputs a pseudo-random stream based on 1291 the inputs to a prf as follows: (where | indicates concatenation) 1293 prf+ (K,S) = T1 | T2 | T3 | T4 | ... 1295 where: 1296 T1 = prf (K, S | 0x01) 1297 T2 = prf (K, T1 | S | 0x02) 1298 T3 = prf (K, T2 | S | 0x03) 1299 T4 = prf (K, T3 | S | 0x04) 1301 continuing as needed to compute all required keys. The keys are taken 1302 from the output string without regard to boundaries (e.g., if the 1303 required keys are a 256 bit AES key and a 160 bit HMAC key, and the 1304 prf function generates 160 bits, the AES key will come from T1 and 1305 the beginning of T2, while the HMAC key will come from the rest of T2 1306 and the beginning of T3). 1308 The constant concatenated to the end of each string feeding the prf 1309 is a single octet. prf+ in this document is not defined beyond 255 1310 times the size of the prf output. 1312 2.14 Generating Keying Material for the IKE_SA 1314 The shared keys are computed as follows. A quantity called SKEYSEED 1315 is calculated from the nonces exchanged during the IKE_SA_INIT 1316 exchange and the Diffie-Hellman shared secret established during that 1317 exchange. SKEYSEED is used to calculate seven other secrets: SK_d 1318 used for deriving new keys for the CHILD_SAs established with this 1319 IKE_SA; SK_ai and SK_ar used as a key to the integrity protection 1320 algorithm for authenticating the component messages of subsequent 1321 exchanges; SK_ei and SK_er used for encrypting (and of course 1322 decrypting) all subsequent exchanges; and SK_pi and SK_pr which are 1323 used when generating an AUTH payload. 1325 SKEYSEED and its derivatives are computed as follows: 1327 SKEYSEED = prf(Ni | Nr, g^ir) 1329 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } 1330 = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) 1332 (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, 1333 SK_pi, and SK_pr are taken in order from the generated bits of the 1334 prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman 1335 exchange. g^ir is represented as a string of octets in big endian 1336 order padded with zeros if necessary to make it the length of the 1337 modulus. Ni and Nr are the nonces, stripped of any headers. If the 1338 negotiated prf takes a fixed length key and the lengths of Ni and Nr 1339 do not add up to that length, half the bits must come from Ni and 1340 half from Nr, taking the first bits of each. 1342 The two directions of traffic flow use different keys. The keys used 1343 to protect messages from the original initiator are SK_ai and SK_ei. 1344 The keys used to protect messages in the other direction are SK_ar 1345 and SK_er. Each algorithm takes a fixed number of bits of keying 1346 material, which is specified as part of the algorithm. For integrity 1347 algorithms based on a keyed hash, the key size is always equal to the 1348 length of the output of the underlying hash function. 1350 2.15 Authentication of the IKE_SA 1352 When not using extensible authentication (see section 2.16), the 1353 peers are authenticated by having each sign (or MAC using a shared 1354 secret as the key) a block of data. For the responder, the octets to 1355 be signed start with the first octet of the first SPI in the header 1356 of the second message and end with the last octet of the last payload 1357 in the second message. Appended to this (for purposes of computing 1358 the signature) are the initiator's nonce Ni (just the value, not the 1359 payload containing it), and the value prf(SK_pr,IDr') where IDr' is 1360 the responder's ID payload excluding the fixed header. Note that 1361 neither the nonce Ni nor the value prf(SK_pr,IDr') are transmitted. 1362 Similarly, the initiator signs the first message, starting with the 1363 first octet of the first SPI in the header and ending with the last 1364 octet of the last payload. Appended to this (for purposes of 1365 computing the signature) are the responder's nonce Nr, and the value 1366 prf(SK_pi,IDi'). In the above calculation, IDi' and IDr' are the 1367 entire ID payloads excluding the fixed header. It is critical to the 1368 security of the exchange that each side sign the other side's nonce. 1370 Note that all of the payloads are included under the signature, 1371 including any payload types not defined in this document. If the 1372 first message of the exchange is sent twice (the second time with a 1373 responder cookie and/or a different Diffie-Hellman group), it is the 1374 second version of the message that is signed. 1376 Optionally, messages 3 and 4 MAY include a certificate, or 1377 certificate chain providing evidence that the key used to compute a 1378 digital signature belongs to the name in the ID payload. The 1379 signature or MAC will be computed using algorithms dictated by the 1380 type of key used by the signer, and specified by the Auth Method 1381 field in the Authentication payload. There is no requirement that 1382 the initiator and responder sign with the same cryptographic 1383 algorithms. The choice of cryptographic algorithms depends on the 1384 type of key each has. In particular, the initiator may be using a 1385 shared key while the responder may have a public signature key and 1386 certificate. It will commonly be the case (but it is not required) 1387 that if a shared secret is used for authentication that the same key 1388 is used in both directions. Note that it is a common but typically 1389 insecure practice to have a shared key derived solely from a user 1390 chosen password without incorporating another source of randomness. 1392 This is typically insecure because user chosen passwords are unlikely 1393 to have sufficient unpredictability to resist dictionary attacks and 1394 these attacks are not prevented in this authentication method. 1395 (Applications using password-based authentication for bootstrapping 1396 and IKE_SA should use the authentication method in section 2.16, 1397 which is designed to prevent off-line dictionary attacks). The pre- 1398 shared key SHOULD contain as much unpredictability as the strongest 1399 key being negotiated. In the case of a pre-shared key, the AUTH 1400 value is computed as: 1402 AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), ) 1404 where the string "Key Pad for IKEv2" is 17 ASCII characters without 1405 null termination. The shared secret can be variable length. The pad 1406 string is added so that if the shared secret is derived from a 1407 password, the IKE implementation need not store the password in 1408 cleartext, but rather can store the value prf(Shared Secret,"Key Pad 1409 for IKEv2"), which could not be used as a password equivalent for 1410 protocols other than IKEv2. As noted above, deriving the shared 1411 secret from a password is not secure. This construction is used 1412 because it is anticipated that people will do it anyway. The 1413 management interface by which the Shared Secret is provided MUST 1414 accept ASCII strings of at least 64 octets and MUST NOT add a null 1415 terminator before using them as shared secrets. It MUST also accept a 1416 HEX encoding of the Shared Secret. The management interface MAY 1417 accept other encodings if the algorithm for translating the encoding 1418 to a binary string is specified. If the negotiated prf takes a fixed 1419 size key, the shared secret MUST be of that fixed size. 1421 2.16 Extensible Authentication Protocol Methods 1423 In addition to authentication using public key signatures and shared 1424 secrets, IKE supports authentication using methods defined in RFC 1425 3748 [EAP]. Typically, these methods are asymmetric (designed for a 1426 user authenticating to a server), and they may not be mutual. For 1427 this reason, these protocols are typically used to authenticate the 1428 initiator to the responder and MUST be used in conjunction with a 1429 public key signature based authentication of the responder to the 1430 initiator. These methods are often associated with mechanisms 1431 referred to as "Legacy Authentication" mechanisms. 1433 While this memo references [EAP] with the intent that new methods can 1434 be added in the future without updating this specification, some 1435 simpler variations are documented here and in section 3.16. [EAP] 1436 defines an authentication protocol requiring a variable number of 1437 messages. Extensible Authentication is implemented in IKE as 1438 additional IKE_AUTH exchanges that MUST be completed in order to 1439 initialize the IKE_SA. 1441 An initiator indicates a desire to use extensible authentication by 1442 leaving out the AUTH payload from message 3. By including an IDi 1443 payload but not an AUTH payload, the initiator has declared an 1444 identity but has not proven it. If the responder is willing to use an 1445 extensible authentication method, it will place an EAP payload in 1446 message 4 and defer sending SAr2, TSi, and TSr until initiator 1447 authentication is complete in a subsequent IKE_AUTH exchange. In the 1448 case of a minimal extensible authentication, the initial SA 1449 establishment will appear as follows: 1451 Initiator Responder 1452 ----------- ----------- 1453 HDR, SAi1, KEi, Ni --> 1455 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 1457 HDR, SK {IDi, [CERTREQ,] [IDr,] 1458 SAi2, TSi, TSr} --> 1460 <-- HDR, SK {IDr, [CERT,] AUTH, 1461 EAP } 1463 HDR, SK {EAP} --> 1465 <-- HDR, SK {EAP (success)} 1467 HDR, SK {AUTH} --> 1469 <-- HDR, SK {AUTH, SAr2, TSi, TSr } 1471 For EAP methods that create a shared key as a side effect of 1472 authentication, that shared key MUST be used by both the initiator 1473 and responder to generate AUTH payloads in messages 5 and 6 using the 1474 syntax for shared secrets specified in section 2.15. The shared key 1475 from EAP is the field from the EAP specification named MSK. The 1476 shared key generated during an IKE exchange MUST NOT be used for any 1477 other purpose. 1479 EAP methods that do not establish a shared key SHOULD NOT be used, as 1480 they are subject to a number of man-in-the-middle attacks [EAPMITM] 1481 if these EAP methods are used in other protocols that do not use a 1482 server-authenticated tunnel. Please see the Security Considerations 1483 section for more details. If EAP methods that do not generate a 1484 shared key are used, the AUTH payloads in messages 7 and 8 MUST be 1485 generated using SK_pi and SK_pr respectively. 1487 The initiator of an IKE_SA using EAP SHOULD be capable of extending 1488 the initial protocol exchange to at least ten IKE_AUTH exchanges in 1489 the event the responder sends notification messages and/or retries 1490 the authentication prompt. Once the protocol exchange defined by the 1491 chosen EAP authentication method has successfully terminated, the 1492 responder MUST send an EAP payload containing the Success message. 1493 Similarly, if the authentication method has failed, the responder 1494 MUST send an EAP payload containing the Failure message. The 1495 responder MAY at any time terminate the IKE exchange by sending an 1496 EAP payload containing the Failure message. 1498 Following such an extended exchange, the EAP AUTH payloads MUST be 1499 included in the two messages following the one containing the EAP 1500 Success message. 1502 2.17 Generating Keying Material for CHILD_SAs 1504 CHILD_SAs are created either by being piggybacked on the IKE_AUTH 1505 exchange, or in a CREATE_CHILD_SA exchange. Keying material for them 1506 is generated as follows: 1508 KEYMAT = prf+(SK_d, Ni | Nr) 1510 Where Ni and Nr are the Nonces from the IKE_SA_INIT exchange if this 1511 request is the first CHILD_SA created or the fresh Ni and Nr from the 1512 CREATE_CHILD_SA exchange if this is a subsequent creation. 1514 For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman 1515 exchange, the keying material is defined as: 1517 KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr ) 1519 where g^ir (new) is the shared secret from the ephemeral Diffie- 1520 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 1521 octet string in big endian order padded with zeros in the high order 1522 bits if necessary to make it the length of the modulus). 1524 A single CHILD_SA negotiation may result in multiple security 1525 associations. ESP and AH SAs exist in pairs (one in each direction), 1526 and four SAs could be created in a single CHILD_SA negotiation if a 1527 combination of ESP and AH is being negotiated. 1529 Keying material MUST be taken from the expanded KEYMAT in the 1530 following order: 1532 All keys for SAs carrying data from the initiator to the responder 1533 are taken before SAs going in the reverse direction. 1535 If multiple IPsec protocols are negotiated, keying material is 1536 taken in the order in which the protocol headers will appear in 1537 the encapsulated packet. 1539 If a single protocol has both encryption and authentication keys, 1540 the encryption key is taken from the first octets of KEYMAT and 1541 the authentication key is taken from the next octets. 1543 Each cryptographic algorithm takes a fixed number of bits of keying 1544 material specified as part of the algorithm. 1546 2.18 Rekeying IKE_SAs using a CREATE_CHILD_SA exchange 1548 The CREATE_CHILD_SA exchange can be used to rekey an existing IKE_SA 1549 (see section 2.8). New initiator and responder SPIs are supplied in 1550 the SPI fields. The TS payloads are omitted when rekeying an IKE_SA. 1551 SKEYSEED for the new IKE_SA is computed using SK_d from the existing 1552 IKE_SA as follows: 1554 SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr) 1556 where g^ir (new) is the shared secret from the ephemeral Diffie- 1557 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 1558 octet string in big endian order padded with zeros if necessary to 1559 make it the length of the modulus) and Ni and Nr are the two nonces 1560 stripped of any headers. 1562 The new IKE_SA MUST reset its message counters to 0. 1564 SK_d, SK_ai, SK_ar, and SK_ei, and SK_er are computed from SKEYSEED 1565 as specified in section 2.14. 1567 2.19 Requesting an internal address on a remote network 1569 Most commonly occurring in the endpoint to security gateway scenario, 1570 an endpoint may need an IP address in the network protected by the 1571 security gateway, and may need to have that address dynamically 1572 assigned. A request for such a temporary address can be included in 1573 any request to create a CHILD_SA (including the implicit request in 1574 message 3) by including a CP payload. 1576 This function provides address allocation to an IRAC (IPsec Remote 1577 Access Client) trying to tunnel into a network protected by an IRAS 1578 (IPsec Remote Access Server). Since the IKE_AUTH exchange creates an 1579 IKE_SA and a CHILD_SA, the IRAC MUST request the IRAS controlled 1580 address (and optionally other information concerning the protected 1581 network) in the IKE_AUTH exchange. The IRAS may procure an address 1582 for the IRAC from any number of sources such as a DHCP/BOOTP server 1583 or its own address pool. 1585 Initiator Responder 1586 ----------------------------- --------------------------- 1587 HDR, SK {IDi, [CERT,] [CERTREQ,] 1588 [IDr,] AUTH, CP(CFG_REQUEST), 1589 SAi2, TSi, TSr} --> 1591 <-- HDR, SK {IDr, [CERT,] AUTH, 1592 CP(CFG_REPLY), SAr2, 1593 TSi, TSr} 1595 In all cases, the CP payload MUST be inserted before the SA payload. 1596 In variations of the protocol where there are multiple IKE_AUTH 1597 exchanges, the CP payloads MUST be inserted in the messages 1598 containing the SA payloads. 1600 CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute 1601 (either IPv4 or IPv6) but MAY contain any number of additional 1602 attributes the initiator wants returned in the response. 1604 For example, message from initiator to responder: 1605 CP(CFG_REQUEST)= 1606 INTERNAL_ADDRESS(0.0.0.0) 1607 INTERNAL_NETMASK(0.0.0.0) 1608 INTERNAL_DNS(0.0.0.0) 1609 TSi = (0, 0-65536,0.0.0.0-255.255.255.255) 1610 TSr = (0, 0-65536,0.0.0.0-255.255.255.255) 1612 NOTE: Traffic Selectors contain (protocol, port range, address range) 1614 Message from responder to initiator: 1616 CP(CFG_REPLY)= 1617 INTERNAL_ADDRESS(192.0.2.202) 1618 INTERNAL_NETMASK(255.255.255.0) 1619 INTERNAL_SUBNET(192.0.2.0/255.255.255.0) 1620 TSi = (0, 0-65536,192.0.2.202-192.0.2.202) 1621 TSr = (0, 0-65536,192.0.2.0-192.0.2.255) 1623 All returned values will be implementation dependent. As can be seen 1624 in the above example, the IRAS MAY also send other attributes that 1625 were not included in CP(CFG_REQUEST) and MAY ignore the non- 1626 mandatory attributes that it does not support. 1628 The responder MUST NOT send a CFG_REPLY without having first received 1629 a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS 1630 to perform an unnecessary configuration lookup if the IRAC cannot 1631 process the REPLY. In the case where the IRAS's configuration 1632 requires that CP be used for a given identity IDi, but IRAC has 1633 failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and 1634 terminate the IKE exchange with a FAILED_CP_REQUIRED error. 1636 2.20 Requesting the Peer's Version 1638 An IKE peer wishing to inquire about the other peer's IKE software 1639 version information MAY use the method below. This is an example of 1640 a configuration request within an INFORMATIONAL Exchange, after the 1641 IKE_SA and first CHILD_SA have been created. 1643 An IKE implementation MAY decline to give out version information 1644 prior to authentication or even after authentication to prevent 1645 trolling in case some implementation is known to have some security 1646 weakness. In that case, it MUST either return an empty string or no 1647 CP payload if CP is not supported. 1649 Initiator Responder 1650 ----------------------------- -------------------------- 1651 HDR, SK{CP(CFG_REQUEST)} --> 1652 <-- HDR, SK{CP(CFG_REPLY)} 1654 CP(CFG_REQUEST)= 1655 APPLICATION_VERSION("") 1657 CP(CFG_REPLY) 1658 APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar Inc.") 1660 2.21 Error Handling 1662 There are many kinds of errors that can occur during IKE processing. 1663 If a request is received that is badly formatted or unacceptable for 1664 reasons of policy (e.g., no matching cryptographic algorithms), the 1665 response MUST contain a Notify payload indicating the error. If an 1666 error occurs outside the context of an IKE request (e.g., the node is 1667 getting ESP messages on a nonexistent SPI), the node SHOULD initiate 1668 an INFORMATIONAL Exchange with a Notify payload describing the 1669 problem. 1671 Errors that occur before a cryptographically protected IKE_SA is 1672 established must be handled very carefully. There is a trade-off 1673 between wanting to be helpful in diagnosing a problem and responding 1674 to it and wanting to avoid being a dupe in a denial of service attack 1675 based on forged messages. 1677 If a node receives a message on UDP port 500 or 4500 outside the 1678 context of an IKE_SA known to it (and not a request to start one), it 1679 may be the result of a recent crash of the node. If the message is 1680 marked as a response, the node MAY audit the suspicious event but 1681 MUST NOT respond. If the message is marked as a request, the node MAY 1682 audit the suspicious event and MAY send a response. If a response is 1683 sent, the response MUST be sent to the IP address and port from 1684 whence it came with the same IKE SPIs and the Message ID copied. The 1685 response MUST NOT be cryptographically protected and MUST contain a 1686 Notify payload indicating INVALID_IKE_SPI. 1688 A node receiving such an unprotected Notify payload MUST NOT respond 1689 and MUST NOT change the state of any existing SAs. The message might 1690 be a forgery or might be a response the genuine correspondent was 1691 tricked into sending. A node SHOULD treat such a message (and also a 1692 network message like ICMP destination unreachable) as a hint that 1693 there might be problems with SAs to that IP address and SHOULD 1694 initiate a liveness test for any such IKE_SA. An implementation 1695 SHOULD limit the frequency of such tests to avoid being tricked into 1696 participating in a denial of service attack. 1698 A node receiving a suspicious message from an IP address with which 1699 it has an IKE_SA MAY send an IKE Notify payload in an IKE 1700 INFORMATIONAL exchange over that SA. The recipient MUST NOT change 1701 the state of any SA's as a result but SHOULD audit the event to aid 1702 in diagnosing malfunctions. A node MUST limit the rate at which it 1703 will send messages in response to unprotected messages. 1705 2.22 IPComp 1707 Use of IP compression [IPCOMP] can be negotiated as part of the setup 1708 of a CHILD_SA. While IP compression involves an extra header in each 1709 packet and a CPI (compression parameter index), the virtual 1710 "compression association" has no life outside the ESP or AH SA that 1711 contains it. Compression associations disappear when the 1712 corresponding ESP or AH SA goes away, and is not explicitly mentioned 1713 in any DELETE payload. 1715 Negotiation of IP compression is separate from the negotiation of 1716 cryptographic parameters associated with a CHILD_SA. A node 1717 requesting a CHILD_SA MAY advertise its support for one or more 1718 compression algorithms though one or more Notify payloads of type 1719 IPCOMP_SUPPORTED. The response MAY indicate acceptance of a single 1720 compression algorithm with a Notify payload of type IPCOMP_SUPPORTED. 1721 These payloads MUST NOT occur messages that do not contain SA 1722 payloads. 1724 While there has been discussion of allowing multiple compression 1725 algorithms to be accepted and to have different compression 1726 algorithms available for the two directions of a CHILD_SA, 1727 implementations of this specification MUST NOT accept an IPComp 1728 algorithm that was not proposed, MUST NOT accept more than one, and 1729 MUST NOT compress using an algorithm other than one proposed and 1730 accepted in the setup of the CHILD_SA. 1732 A side effect of separating the negotiation of IPComp from 1733 cryptographic parameters is that it is not possible to propose 1734 multiple cryptographic suites and propose IP compression with some of 1735 them but not others. 1737 2.23 NAT Traversal 1739 NAT (Network Address Translation) gateways are a controversial 1740 subject. This section briefly describes what they are and how they 1741 are likely to act on IKE traffic. Many people believe that NATs are 1742 evil and that we should not design our protocols so as to make them 1743 work better. IKEv2 does specify some unintuitive processing rules in 1744 order that NATs are more likely to work. 1746 NATs exist primarily because of the shortage of IPv4 addresses, 1747 though there are other rationales. IP nodes that are "behind" a NAT 1748 have IP addresses that are not globally unique, but rather are 1749 assigned from some space that is unique within the network behind the 1750 NAT but which are likely to be reused by nodes behind other NATs. 1751 Generally, nodes behind NATs can communicate with other nodes behind 1752 the same NAT and with nodes with globally unique addresses, but not 1753 with nodes behind other NATs. There are exceptions to that rule. 1754 When those nodes make connections to nodes on the real Internet, the 1755 NAT gateway "translates" the IP source address to an address that 1756 will be routed back to the gateway. Messages to the gateway from the 1757 Internet have their destination addresses "translated" to the 1758 internal address that will route the packet to the correct endnode. 1760 NATs are designed to be "transparent" to endnodes. Neither software 1761 on the node behind the NAT nor the node on the Internet require 1762 modification to communicate through the NAT. Achieving this 1763 transparency is more difficult with some protocols than with others. 1764 Protocols that include IP addresses of the endpoints within the 1765 payloads of the packet will fail unless the NAT gateway understands 1766 the protocol and modifies the internal references as well as those in 1767 the headers. Such knowledge is inherently unreliable, is a network 1768 layer violation, and often results in subtle problems. 1770 Opening an IPsec connection through a NAT introduces special 1771 problems. If the connection runs in transport mode, changing the IP 1772 addresses on packets will cause the checksums to fail and the NAT 1773 cannot correct the checksums because they are cryptographically 1774 protected. Even in tunnel mode, there are routing problems because 1775 transparently translating the addresses of AH and ESP packets 1776 requires special logic in the NAT and that logic is heuristic and 1777 unreliable in nature. For that reason, IKEv2 can negotiate UDP 1778 encapsulation of IKE and ESP packets. This encoding is slightly less 1779 efficient but is easier for NATs to process. In addition, firewalls 1780 may be configured to pass IPsec traffic over UDP but not ESP/AH or 1781 vice versa. 1783 It is a common practice of NATs to translate TCP and UDP port numbers 1784 as well as addresses and use the port numbers of inbound packets to 1785 decide which internal node should get a given packet. For this 1786 reason, even though IKE packets MUST be sent from and to UDP port 1787 500, they MUST be accepted coming from any port and responses MUST be 1788 sent to the port from whence they came. This is because the ports may 1789 be modified as the packets pass through NATs. Similarly, IP addresses 1790 of the IKE endpoints are generally not included in the IKE payloads 1791 because the payloads are cryptographically protected and could not be 1792 transparently modified by NATs. 1794 Port 4500 is reserved for UDP encapsulated ESP and IKE. When working 1795 through a NAT, it is generally better to pass IKE packets over port 1796 4500 because some older NATs handle IKE traffic on port 500 cleverly 1797 in an attempt to transparently establish IPsec connections between 1798 endpoints that don't handle NAT traversal themselves. Such NATs may 1799 interfere with the straightforward NAT traversal envisioned by this 1800 document, so an IPsec endpoint that discovers a NAT between it and 1801 its correspondent MUST send all subsequent traffic to and from port 1802 4500, which NATs should not treat specially (as they might with port 1803 500). 1805 The specific requirements for supporting NAT traversal are listed 1806 below. Support for NAT traversal is optional. In this section only, 1807 requirements listed as MUST only apply to implementations supporting 1808 NAT traversal. 1810 IKE MUST listen on port 4500 as well as port 500. IKE MUST respond 1811 to the IP address and port from which packets arrived. 1813 Both IKE initiator and responder MUST include in their IKE_SA_INIT 1814 packets Notify payloads of type NAT_DETECTION_SOURCE_IP and 1815 NAT_DETECTION_DESTINATION_IP. Those payloads can be used to detect 1816 if there is NAT between the hosts, and which end is behind the 1817 NAT. The location of the payloads in the IKE_SA_INIT packets are 1818 just after the Ni and Nr payloads (before the optional CERTREQ 1819 payload). 1821 If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches 1822 the hash of the source IP and port found from the IP header of the 1823 packet containing the payload, it means that the other end is 1824 behind NAT (i.e., someone along the route changed the source 1825 address of the original packet to match the address of the NAT 1826 box). In this case this end should allow dynamic update of the 1827 other ends IP address, as described later. 1829 If the NAT_DETECTION_DESTINATION_IP payload received does not 1830 match the hash of the destination IP and port found from the IP 1831 header of the packet containing the payload, it means that this 1832 end is behind a NAT. In this case, this end SHOULD start sending 1833 keepalive packets as explained in [Hutt04]. 1835 The IKE initiator MUST check these payloads if present and if they 1836 do not match the addresses in the outer packet MUST tunnel all 1837 future IKE and ESP packets associated with this IKE_SA over UDP 1838 port 4500. 1840 To tunnel IKE packets over UDP port 4500, the IKE header has four 1841 octets of zero prepended and the result immediately follows the 1842 UDP header. To tunnel ESP packets over UDP port 4500, the ESP 1843 header immediately follows the UDP header. Since the first four 1844 bytes of the ESP header contain the SPI, and the SPI cannot 1845 validly be zero, it is always possible to distinguish ESP and IKE 1846 messages. 1848 The original source and destination IP address required for the 1849 transport mode TCP and UDP packet checksum fixup (see [Hutt04]) 1850 are obtained from the Traffic Selectors associated with the 1851 exchange. In the case of NAT traversal, the Traffic Selectors MUST 1852 contain exactly one IP address which is then used as the original 1853 IP address. 1855 There are cases where a NAT box decides to remove mappings that 1856 are still alive (for example, the keepalive interval is too long, 1857 or the NAT box is rebooted). To recover in these cases, hosts that 1858 are not behind a NAT SHOULD send all packets (including 1859 retransmission packets) to the IP address and port from the last 1860 valid authenticated packet from the other end (i.e., dynamically 1861 update the address). A host behind a NAT SHOULD NOT do this 1862 because it opens a DoS attack possibility. Any authenticated IKE 1863 packet or any authenticated UDP encapsulated ESP packet can be 1864 used to detect that the IP address or the port has changed. 1866 Note that similar but probably not identical actions will likely 1867 be needed to make IKE work with Mobile IP, but such processing is 1868 not addressed by this document. 1870 2.24 ECN (Explicit Congestion Notification) 1872 When IPsec tunnels behave as originally specified in [RFC2401], ECN 1873 usage is not appropriate for the outer IP headers because tunnel 1874 decapsulation processing discards ECN congestion indications to the 1875 detriment of the network. ECN support for IPsec tunnels for 1876 IKEv1-based IPsec requires multiple operating modes and negotiation 1877 (see RFC3168]). IKEv2 simplifies this situation by requiring that 1878 ECN be usable in the outer IP headers of all tunnel-mode IPsec SAs 1879 created by IKEv2. Specifically, tunnel encapsulators and 1880 decapsulators for all tunnel-mode Security Associations (SAs) created 1881 by IKEv2 MUST support the ECN full-functionality option for tunnels 1882 specified in [RFC3168] and MUST implement the tunnel encapsulation 1883 and decapsulation processing specified in [RFC2401bis] to prevent 1884 discarding of ECN congestion indications. 1886 3 Header and Payload Formats 1888 3.1 The IKE Header 1890 IKE messages use UDP ports 500 and/or 4500, with one IKE message per 1891 UDP datagram. Information from the beginning of the packet through 1892 the UDP header is largely ignored except that the IP addresses and 1893 UDP ports from the headers are reversed and used for return packets. 1894 When sent on UDP port 500, IKE messages begin immediately following 1895 the UDP header. When sent on UDP port 4500, IKE messages have 1896 prepended four octets of zero. These four octets of zero are not 1897 part of the IKE message and are not included in any of the length 1898 fields or checksums defined by IKE. Each IKE message begins with the 1899 IKE header, denoted HDR in this memo. Following the header are one or 1900 more IKE payloads each identified by a "Next Payload" field in the 1901 preceding payload. Payloads are processed in the order in which they 1902 appear in an IKE message by invoking the appropriate processing 1903 routine according to the "Next Payload" field in the IKE header and 1904 subsequently according to the "Next Payload" field in the IKE payload 1905 itself until a "Next Payload" field of zero indicates that no 1906 payloads follow. If a payload of type "Encrypted" is found, that 1907 payload is decrypted and its contents parsed as additional payloads. 1908 An Encrypted payload MUST be the last payload in a packet and an 1909 encrypted payload MUST NOT contain another encrypted payload. 1911 The Recipient SPI in the header identifies an instance of an IKE 1912 security association. It is therefore possible for a single instance 1913 of IKE to multiplex distinct sessions with multiple peers. 1915 All multi-octet fields representing integers are laid out in big 1916 endian order (aka most significant byte first, or network byte 1917 order). 1919 The format of the IKE header is shown in Figure 4. 1920 1 2 3 1921 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 1922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1923 ! IKE_SA Initiator's SPI ! 1924 ! ! 1925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1926 ! IKE_SA Responder's SPI ! 1927 ! ! 1928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1929 ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! 1930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1931 ! Message ID ! 1932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1933 ! Length ! 1934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1936 Figure 4: IKE Header Format 1938 o Initiator's SPI (8 octets) - A value chosen by the 1939 initiator to identify a unique IKE security association. This 1940 value MUST NOT be zero. 1942 o Responder's SPI (8 octets) - A value chosen by the 1943 responder to identify a unique IKE security association. This 1944 value MUST be zero in the first message of an IKE Initial 1945 Exchange (including repeats of that message including a 1946 cookie) and MUST NOT be zero in any other message. 1948 o Next Payload (1 octet) - Indicates the type of payload that 1949 immediately follows the header. The format and value of each 1950 payload is defined below. 1952 o Major Version (4 bits) - indicates the major version of the IKE 1953 protocol in use. Implementations based on this version of IKE 1954 MUST set the Major Version to 2. Implementations based on 1955 previous versions of IKE and ISAKMP MUST set the Major Version 1956 to 1. Implementations based on this version of IKE MUST reject 1957 or ignore messages containing a version number greater than 1958 2. 1960 o Minor Version (4 bits) - indicates the minor version of the 1961 IKE protocol in use. Implementations based on this version of 1962 IKE MUST set the Minor Version to 0. They MUST ignore the minor 1963 version number of received messages. 1965 o Exchange Type (1 octet) - indicates the type of exchange being 1966 used. This constrains the payloads sent in each message and 1967 orderings of messages in an exchange. 1969 Exchange Type Value 1971 RESERVED 0-33 1972 IKE_SA_INIT 34 1973 IKE_AUTH 35 1974 CREATE_CHILD_SA 36 1975 INFORMATIONAL 37 1976 RESERVED TO IANA 38-239 1977 Reserved for private use 240-255 1979 o Flags (1 octet) - indicates specific options that are set 1980 for the message. Presence of options are indicated by the 1981 appropriate bit in the flags field being set. The bits are 1982 defined LSB first, so bit 0 would be the least significant 1983 bit of the Flags octet. In the description below, a bit 1984 being 'set' means its value is '1', while 'cleared' means 1985 its value is '0'. 1987 -- X(reserved) (bits 0-2) - These bits MUST be cleared 1988 when sending and MUST be ignored on receipt. 1990 -- I(nitiator) (bit 3 of Flags) - This bit MUST be set in 1991 messages sent by the original initiator of the IKE_SA 1992 and MUST be cleared in messages sent by the original 1993 responder. It is used by the recipient to determine 1994 which eight octets of the SPI was generated by the 1995 recipient. 1997 -- V(ersion) (bit 4 of Flags) - This bit indicates that 1998 the transmitter is capable of speaking a higher major 1999 version number of the protocol than the one indicated 2000 in the major version number field. Implementations of 2001 IKEv2 must clear this bit when sending and MUST ignore 2002 it in incoming messages. 2004 -- R(esponse) (bit 5 of Flags) - This bit indicates that 2005 this message is a response to a message containing 2006 the same message ID. This bit MUST be cleared in all 2007 request messages and MUST be set in all responses. 2008 An IKE endpoint MUST NOT generate a response to a 2009 message that is marked as being a response. 2011 -- X(reserved) (bits 6-7 of Flags) - These bits MUST be 2012 cleared when sending and MUST be ignored on receipt. 2014 o Message ID (4 octets) - Message identifier used to control 2015 retransmission of lost packets and matching of requests and 2016 responses. It is essential to the security of the protocol 2017 because it is used to prevent message replay attacks. 2018 See sections 2.1 and 2.2. 2020 o Length (4 octets) - Length of total message (header + payloads) 2021 in octets. 2023 3.2 Generic Payload Header 2025 Each IKE payload defined in sections 3.3 through 3.16 begins with a 2026 generic payload header, shown in Figure 5. Figures for each payload 2027 below will include the generic payload header but for brevity the 2028 description of each field will be omitted. 2030 1 2 3 2031 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 2032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2033 ! Next Payload !C! RESERVED ! Payload Length ! 2034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2036 Figure 5: Generic Payload Header 2038 The Generic Payload Header fields are defined as follows: 2040 o Next Payload (1 octet) - Identifier for the payload type of the 2041 next payload in the message. If the current payload is the last 2042 in the message, then this field will be 0. This field provides 2043 a "chaining" capability whereby additional payloads can be 2044 added to a message by appending it to the end of the message 2045 and setting the "Next Payload" field of the preceding payload 2046 to indicate the new payload's type. An Encrypted payload, 2047 which must always be the last payload of a message, is an 2048 exception. It contains data structures in the format of 2049 additional payloads. In the header of an Encrypted payload, 2050 the Next Payload field is set to the payload type of the first 2051 contained payload (instead of 0). 2053 Payload Type Values 2055 Next Payload Type Notation Value 2057 No Next Payload 0 2059 RESERVED 1-32 2060 Security Association SA 33 2061 Key Exchange KE 34 2062 Identification - Initiator IDi 35 2063 Identification - Responder IDr 36 2064 Certificate CERT 37 2065 Certificate Request CERTREQ 38 2066 Authentication AUTH 39 2067 Nonce Ni, Nr 40 2068 Notify N 41 2069 Delete D 42 2070 Vendor ID V 43 2071 Traffic Selector - Initiator TSi 44 2072 Traffic Selector - Responder TSr 45 2073 Encrypted E 46 2074 Configuration CP 47 2075 Extensible Authentication EAP 48 2076 RESERVED TO IANA 49-127 2077 PRIVATE USE 128-255 2079 Payload type values 1-32 should not be used so that there is no 2080 overlap with the code assignments for IKEv1. Payload type values 2081 49-127 are reserved to IANA for future assignment in IKEv2 (see 2082 section 6). Payload type values 128-255 are for private use among 2083 mutually consenting parties. 2085 o Critical (1 bit) - MUST be set to zero if the sender wants 2086 the recipient to skip this payload if it does not 2087 understand the payload type code in the Next Payload field 2088 of the previous payload. MUST be set to one if the 2089 sender wants the recipient to reject this entire message 2090 if it does not understand the payload type. MUST be ignored 2091 by the recipient if the recipient understands the payload type 2092 code. MUST be set to zero for payload types defined in this 2093 document. Note that the critical bit applies to the current 2094 payload rather than the "next" payload whose type code 2095 appears in the first octet. The reasoning behind not setting 2096 the critical bit for payloads defined in this document is 2097 that all implementations MUST understand all payload types 2098 defined in this document and therefore must ignore the 2099 Critical bit's value. Skipped payloads are expected to 2100 have valid Next Payload and Payload Length fields. 2102 o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on 2103 receipt. 2105 o Payload Length (2 octets) - Length in octets of the current 2106 payload, including the generic payload header. 2108 3.3 Security Association Payload 2110 The Security Association Payload, denoted SA in this memo, is used to 2111 negotiate attributes of a security association. Assembly of Security 2112 Association Payloads requires great peace of mind. An SA payload MAY 2113 contain multiple proposals. If there is more than one, they MUST be 2114 ordered from most preferred to least preferred. Each proposal may 2115 contain multiple IPsec protocols (where a protocol is IKE, ESP, or 2116 AH), each protocol MAY contain multiple transforms, and each 2117 transform MAY contain multiple attributes. When parsing an SA, an 2118 implementation MUST check that the total Payload Length is consistent 2119 with the payload's internal lengths and counts. Proposals, 2120 Transforms, and Attributes each have their own variable length 2121 encodings. They are nested such that the Payload Length of an SA 2122 includes the combined contents of the SA, Proposal, Transform, and 2123 Attribute information. The length of a Proposal includes the lengths 2124 of all Transforms and Attributes it contains. The length of a 2125 Transform includes the lengths of all Attributes it contains. 2127 The syntax of Security Associations, Proposals, Transforms, and 2128 Attributes is based on ISAKMP, however the semantics are somewhat 2129 different. The reason for the complexity and the hierarchy is to 2130 allow for multiple possible combinations of algorithms to be encoded 2131 in a single SA. Sometimes there is a choice of multiple algorithms, 2132 while other times there is a combination of algorithms. For example, 2133 an initiator might want to propose using (AH w/MD5 and ESP w/3DES) OR 2134 (ESP w/MD5 and 3DES). 2136 One of the reasons the semantics of the SA payload has changed from 2137 ISAKMP and IKEv1 is to make the encodings more compact in common 2138 cases. 2140 The Proposal structure contains within it a Proposal # and an IPsec 2141 protocol ID. Each structure MUST have the same Proposal # as the 2142 previous one or be one (1) greater. The first Proposal MUST have a 2143 Proposal # of one (1). If two successive structures have the same 2144 Proposal number, it means that the proposal consists of the first 2145 structure AND the second. So a proposal of AH AND ESP would have two 2146 proposal structures, one for AH and one for ESP and both would have 2147 Proposal #1. A proposal of AH OR ESP would have two proposal 2148 structures, one for AH with proposal #1 and one for ESP with proposal 2149 #2. 2151 Each Proposal/Protocol structure is followed by one or more transform 2152 structures. The number of different transforms is generally 2153 determined by the Protocol. AH generally has a single transform: an 2154 integrity check algorithm. ESP generally has two: an encryption 2155 algorithm and an integrity check algorithm. IKE generally has four 2156 transforms: a Diffie-Hellman group, an integrity check algorithm, a 2157 prf algorithm, and an encryption algorithm. If an algorithm that 2158 combines encryption and integrity protection is proposed, it MUST be 2159 proposed as an encryption algorithm and an integrity protection 2160 algorithm MUST NOT be proposed. For each Protocol, the set of 2161 permissible transforms are assigned transform ID numbers, which 2162 appear in the header of each transform. 2164 If there are multiple transforms with the same Transform Type, the 2165 proposal is an OR of those transforms. If there are multiple 2166 Transforms with different Transform Types, the proposal is an AND of 2167 the different groups. For example, to propose ESP with (3DES or IDEA) 2168 and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two 2169 Transform Type 1 candidates (one for 3DES and one for IDEA) and two 2170 Transform Type 2 candidates (one for HMAC_MD5 and one for HMAC_SHA). 2171 This effectively proposes four combinations of algorithms. If the 2172 initiator wanted to propose only a subset of those - say (3DES and 2173 HMAC_MD5) or (IDEA and HMAC_SHA), there is no way to encode that as 2174 multiple transforms within a single Proposal. Instead, the initiator 2175 would have to construct two different Proposals, each with two 2176 transforms. 2178 A given transform MAY have one or more Attributes. Attributes are 2179 necessary when the transform can be used in more than one way, as 2180 when an encryption algorithm has a variable key size. The transform 2181 would specify the algorithm and the attribute would specify the key 2182 size. Most transforms do not have attributes. A transform MUST NOT 2183 have multiple attributes of the same type. To propose alternate 2184 values for an attribute (for example, multiple key sizes for the AES 2185 encryption algorithm), and implementation MUST include multiple 2186 Transforms with the same Transform Type each with a single Attribute. 2188 Note that the semantics of Transforms and Attributes are quite 2189 different than in IKEv1. In IKEv1, a single Transform carried 2190 multiple algorithms for a protocol with one carried in the Transform 2191 and the others carried in the Attributes. 2193 1 2 3 2194 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 2195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2196 ! Next Payload !C! RESERVED ! Payload Length ! 2197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2198 ! ! 2199 ~ ~ 2200 ! ! 2201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2203 Figure 6: Security Association Payload 2205 o Proposals (variable) - one or more proposal substructures. 2207 The payload type for the Security Association Payload is thirty 2208 three (33). 2210 3.3.1 Proposal Substructure 2212 1 2 3 2213 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 2214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2215 ! 0 (last) or 2 ! RESERVED ! Proposal Length ! 2216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2217 ! Proposal # ! Protocol ID ! SPI Size !# of Transforms! 2218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2219 ~ SPI (variable) ~ 2220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2221 ! ! 2222 ~ ~ 2223 ! ! 2224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2226 Figure 7: Proposal Substructure 2228 o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the 2229 last Proposal Substructure in the SA. This syntax is inherited 2230 from ISAKMP, but is unnecessary because the last Proposal 2231 could be identified from the length of the SA. The value (2) 2232 corresponds to a Payload Type of Proposal in IKEv1, and the 2233 first four octets of the Proposal structure are designed to 2234 look somewhat like the header of a Payload. 2236 o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on 2237 receipt. 2239 o Proposal Length (2 octets) - Length of this proposal, 2240 including all transforms and attributes that follow. 2242 o Proposal # (1 octet) - When a proposal is made, the first 2243 proposal in an SA payload MUST be #1, and subsequent proposals 2244 MUST either be the same as the previous proposal (indicating 2245 an AND of the two proposals) or one more than the previous 2246 proposal (indicating an OR of the two proposals). When a 2247 proposal is accepted, all of the proposal numbers in the 2248 SA payload MUST be the same and MUST match the number on the 2249 proposal sent that was accepted. 2251 o Protocol ID (1 octet) - Specifies the IPsec protocol 2252 identifier for the current negotiation. The defined values 2253 are: 2255 Protocol Protocol ID 2256 RESERVED 0 2257 IKE 1 2258 AH 2 2259 ESP 3 2260 RESERVED TO IANA 4-200 2261 PRIVATE USE 201-255 2263 o SPI Size (1 octet) - For an initial IKE_SA negotiation, 2264 this field MUST be zero; the SPI is obtained from the 2265 outer header. During subsequent negotiations, 2266 it is equal to the size, in octets, of the SPI of the 2267 corresponding protocol (8 for IKE, 4 for ESP and AH). 2269 o # of Transforms (1 octet) - Specifies the number of 2270 transforms in this proposal. 2272 o SPI (variable) - The sending entity's SPI. Even if the SPI 2273 Size is not a multiple of 4 octets, there is no padding 2274 applied to the payload. When the SPI Size field is zero, 2275 this field is not present in the Security Association 2276 payload. 2278 o Transforms (variable) - one or more transform substructures. 2280 3.3.2 Transform Substructure 2282 1 2 3 2283 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 2284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2285 ! 0 (last) or 3 ! RESERVED ! Transform Length ! 2286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2287 !Transform Type ! RESERVED ! Transform ID ! 2288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2289 ! ! 2290 ~ Transform Attributes ~ 2291 ! ! 2292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2294 Figure 8: Transform Substructure 2296 o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the 2297 last Transform Substructure in the Proposal. This syntax is 2298 inherited from ISAKMP, but is unnecessary because the last 2299 Proposal could be identified from the length of the SA. The 2300 value (3) corresponds to a Payload Type of Transform in IKEv1, 2301 and the first four octets of the Transform structure are 2302 designed to look somewhat like the header of a Payload. 2304 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 2306 o Transform Length - The length (in octets) of the Transform 2307 Substructure including Header and Attributes. 2309 o Transform Type (1 octet) - The type of transform being specified 2310 in this transform. Different protocols support different 2311 transform types. For some protocols, some of the transforms 2312 may be optional. If a transform is optional and the initiator 2313 wishes to propose that the transform be omitted, no transform 2314 of the given type is included in the proposal. If the 2315 initiator wishes to make use of the transform optional to 2316 the responder, it includes a transform substructure with 2317 transform ID = 0 as one of the options. 2319 o Transform ID (2 octets) - The specific instance of the transform 2320 type being proposed. 2322 Transform Type Values 2324 Transform Used In 2325 Type 2326 RESERVED 0 2327 Encryption Algorithm (ENCR) 1 (IKE and ESP) 2328 Pseudo-random Function (PRF) 2 (IKE) 2329 Integrity Algorithm (INTEG) 3 (IKE, AH, optional in ESP) 2330 Diffie-Hellman Group (D-H) 4 (IKE, optional in AH & ESP) 2331 Extended Sequence Numbers (ESN) 5 (Optional in AH and ESP) 2332 RESERVED TO IANA 6-240 2333 PRIVATE USE 241-255 2335 For Transform Type 1 (Encryption Algorithm), defined Transform IDs 2336 are: 2338 Name Number Defined In 2339 RESERVED 0 2340 ENCR_DES_IV64 1 (RFC1827) 2341 ENCR_DES 2 (RFC2405) 2342 ENCR_3DES 3 (RFC2451) 2343 ENCR_RC5 4 (RFC2451) 2344 ENCR_IDEA 5 (RFC2451) 2345 ENCR_CAST 6 (RFC2451) 2346 ENCR_BLOWFISH 7 (RFC2451) 2347 ENCR_3IDEA 8 (RFC2451) 2348 ENCR_DES_IV32 9 2349 RESERVED 10 2350 ENCR_NULL 11 (RFC2410) 2351 ENCR_AES_CBC 12 (RFC3602) 2352 ENCR_AES_CTR 13 (RFC3664) 2354 values 14-1023 are reserved to IANA. Values 1024-65535 are for 2355 private use among mutually consenting parties. 2357 For Transform Type 2 (Pseudo-random Function), defined Transform IDs 2358 are: 2360 Name Number Defined In 2361 RESERVED 0 2362 PRF_HMAC_MD5 1 (RFC2104) 2363 PRF_HMAC_SHA1 2 (RFC2104) 2364 PRF_HMAC_TIGER 3 (RFC2104) 2365 PRF_AES128_CBC 4 (RFC3664) 2367 values 5-1023 are reserved to IANA. Values 1024-65535 are for 2368 private use among mutually consenting parties. 2370 For Transform Type 3 (Integrity Algorithm), defined Transform IDs 2371 are: 2373 Name Number Defined In 2374 NONE 0 2375 AUTH_HMAC_MD5_96 1 (RFC2403) 2376 AUTH_HMAC_SHA1_96 2 (RFC2404) 2377 AUTH_DES_MAC 3 2378 AUTH_KPDK_MD5 4 (RFC1826) 2379 AUTH_AES_XCBC_96 5 (RFC3566) 2381 values 6-1023 are reserved to IANA. Values 1024-65535 are for 2382 private use among mutually consenting parties. 2384 For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs 2385 are: 2387 Name Number 2388 NONE 0 2389 Defined in Appendix B 1 - 2 2390 RESERVED 3 - 4 2391 Defined in [ADDGROUP] 5 2392 RESERVED TO IANA 6 - 13 2393 Defined in [ADDGROUP] 14 - 18 2394 RESERVED TO IANA 19 - 1023 2395 PRIVATE USE 1024-65535 2397 For Transform Type 5 (Extended Sequence Numbers), defined Transform 2398 IDs are: 2400 Name Number 2401 No Extended Sequence Numbers 0 2402 Extended Sequence Numbers 1 2403 RESERVED 2 - 65535 2405 If Transform Type 5 is not included in a proposal, use of 2406 Extended Sequence Numbers is assumed. 2408 3.3.3 Valid Transform Types by Protocol 2410 The number and type of transforms that accompany an SA payload are 2411 dependent on the protocol in the SA itself. An SA payload proposing 2412 the establishment of an SA has the following mandatory and optional 2413 transform types. A compliant implementation MUST understand all 2414 mandatory and optional types for each protocol it supports (though it 2415 need not accept proposals with unacceptable suites). A proposal MAY 2416 omit the optional types if the only value for them it will accept is 2417 NONE. 2419 Protocol Mandatory Types Optional Types 2420 IKE ENCR, PRF, INTEG, D-H 2421 ESP ENCR INTEG, D-H, ESN 2422 AH INTEG D-H, ESN 2424 3.3.4 Mandatory Transform IDs 2426 The specification of suites that MUST and SHOULD be supported for 2427 interoperability has been removed from this document because they are 2428 likely to change more rapidly than this document evolves. 2430 An important lesson learned from IKEv1 is that no system should only 2431 implement the mandatory algorithms and expect them to be the best 2432 choice for all customers. For example, at the time that this document 2433 was being written, many IKEv1 implementers are starting to migrate to 2434 AES in CBC mode for VPN applications. Many IPsec systems based on 2435 IKEv2 will implement AES, additional Diffie-Hellman groups, and 2436 additional hash algorithms, and some IPsec customers already require 2437 these algorithms in addition to the ones listed above. 2439 It is likely that IANA will add additional transforms in the future, 2440 and some users may want to use private suites, especially for IKE 2441 where implementations should be capable of supporting different 2442 parameters, up to certain size limits. In support of this goal, all 2443 implementations of IKEv2 SHOULD include a management facility that 2444 allows specification (by a user or system administrator) of Diffie- 2445 Hellman parameters (the generator, modulus, and exponent lengths and 2446 values) for new DH groups. Implementations SHOULD provide a 2447 management interface via which these parameters and the associated 2448 transform IDs may be entered (by a user or system administrator), to 2449 enable negotiating such groups. 2451 All implementations of IKEv2 MUST include a management facility that 2452 enables a user or system administrator to specify the suites that are 2453 acceptable for use with IKE. Upon receipt of a payload with a set of 2454 transform IDs, the implementation MUST compare the transmitted 2455 transform IDs against those locally configured via the management 2456 controls, to verify that the proposed suite is acceptable based on 2457 local policy. The implementation MUST reject SA proposals that are 2458 not authorized by these IKE suite controls. Note that cryptographic 2459 suites that MUST be implemented need not be configured as acceptable 2460 to local policy. 2462 3.3.5 Transform Attributes 2464 Each transform in a Security Association payload may include 2465 attributes that modify or complete the specification of the 2466 transform. These attributes are type/value pairs and are defined 2467 below. For example, if an encryption algorithm has a variable length 2468 key, the key length to be used may be specified as an attribute. 2469 Attributes can have a value with a fixed two octet length or a 2470 variable length value. For the latter, the attribute is encoded as 2471 type/length/value. 2473 1 2 3 2474 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 2475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2476 !A! Attribute Type ! AF=0 Attribute Length ! 2477 !F! ! AF=1 Attribute Value ! 2478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2479 ! AF=0 Attribute Value ! 2480 ! AF=1 Not Transmitted ! 2481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2483 Figure 9: Data Attributes 2485 o Attribute Type (2 octets) - Unique identifier for each type of 2486 attribute (see below). 2488 The most significant bit of this field is the Attribute Format 2489 bit (AF). It indicates whether the data attributes follow the 2490 Type/Length/Value (TLV) format or a shortened Type/Value (TV) 2491 format. If the AF bit is zero (0), then the Data Attributes 2492 are of the Type/Length/Value (TLV) form. If the AF bit is a 2493 one (1), then the Data Attributes are of the Type/Value form. 2495 o Attribute Length (2 octets) - Length in octets of the Attribute 2496 Value. When the AF bit is a one (1), the Attribute Value is 2497 only 2 octets and the Attribute Length field is not present. 2499 o Attribute Value (variable length) - Value of the Attribute 2500 associated with the Attribute Type. If the AF bit is a 2501 zero (0), this field has a variable length defined by the 2502 Attribute Length field. If the AF bit is a one (1), the 2503 Attribute Value has a length of 2 octets. 2505 Note that only a single attribute type (Key Length) is defined, and 2506 it is fixed length. The variable length encoding specification is 2507 included only for future extensions. The only algorithms defined in 2508 this document that accept attributes are the AES based encryption, 2509 integrity, and pseudo-random functions, which require a single 2510 attribute specifying key width. 2512 Attributes described as basic MUST NOT be encoded using the variable 2513 length encoding. Variable length attributes MUST NOT be encoded as 2514 basic even if their value can fit into two octets. NOTE: This is a 2515 change from IKEv1, where increased flexibility may have simplified 2516 the composer of messages but certainly complicated the parser. 2518 Attribute Type value Attribute Format 2519 -------------------------------------------------------------- 2520 RESERVED 0-13 2521 Key Length (in bits) 14 TV 2522 RESERVED 15-17 2523 RESERVED TO IANA 18-16383 2524 PRIVATE USE 16384-32767 2526 Values 0-13 and 15-17 were used in a similar context in IKEv1, and 2527 should not be assigned except to matching values. Values 18-16383 are 2528 reserved to IANA. Values 16384-32767 are for private use among 2529 mutually consenting parties. 2531 - Key Length 2533 When using an Encryption Algorithm that has a variable length key, 2534 this attribute specifies the key length in bits. (MUST use network 2535 byte order). This attribute MUST NOT be used when the specified 2536 Encryption Algorithm uses a fixed length key. 2538 3.3.6 Attribute Negotiation 2540 During security association negotiation initiators present offers to 2541 responders. Responders MUST select a single complete set of 2542 parameters from the offers (or reject all offers if none are 2543 acceptable). If there are multiple proposals, the responder MUST 2544 choose a single proposal number and return all of the Proposal 2545 substructures with that Proposal number. If there are multiple 2546 Transforms with the same type the responder MUST choose a single one. 2547 Any attributes of a selected transform MUST be returned unmodified. 2548 The initiator of an exchange MUST check that the accepted offer is 2549 consistent with one of its proposals, and if not that response MUST 2550 be rejected. 2552 Negotiating Diffie-Hellman groups presents some special challenges. 2553 SA offers include proposed attributes and a Diffie-Hellman public 2554 number (KE) in the same message. If in the initial exchange the 2555 initiator offers to use one of several Diffie-Hellman groups, it 2556 SHOULD pick the one the responder is most likely to accept and 2557 include a KE corresponding to that group. If the guess turns out to 2558 be wrong, the responder will indicate the correct group in the 2559 response and the initiator SHOULD pick an element of that group for 2560 its KE value when retrying the first message. It SHOULD, however, 2561 continue to propose its full supported set of groups in order to 2562 prevent a man in the middle downgrade attack. 2564 Implementation Note: 2566 Certain negotiable attributes can have ranges or could have 2567 multiple acceptable values. These include the key length of a 2568 variable key length symmetric cipher. To further interoperability 2569 and to support upgrading endpoints independently, implementers of 2570 this protocol SHOULD accept values which they deem to supply 2571 greater security. For instance if a peer is configured to accept a 2572 variable lengthed cipher with a key length of X bits and is 2573 offered that cipher with a larger key length, the implementation 2574 SHOULD accept the offer if it supports use of the longer key. 2576 Support of this capability allows an implementation to express a 2577 concept of "at least" a certain level of security-- "a key length of 2578 _at least_ X bits for cipher Y". 2580 3.4 Key Exchange Payload 2582 The Key Exchange Payload, denoted KE in this memo, is used to 2583 exchange Diffie-Hellman public numbers as part of a Diffie-Hellman 2584 key exchange. The Key Exchange Payload consists of the IKE generic 2585 payload header followed by the Diffie-Hellman public value itself. 2587 1 2 3 2588 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 2589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2590 ! Next Payload !C! RESERVED ! Payload Length ! 2591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2592 ! DH Group # ! RESERVED ! 2593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2594 ! ! 2595 ~ Key Exchange Data ~ 2596 ! ! 2597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2599 Figure 10: Key Exchange Payload Format 2601 A key exchange payload is constructed by copying one's Diffie-Hellman 2602 public value into the "Key Exchange Data" portion of the payload. 2603 The length of the Diffie-Hellman public value MUST be equal to the 2604 length of the prime modulus over which the exponentiation was 2605 performed, prepending zero bits to the value if necessary. 2607 The DH Group # identifies the Diffie-Hellman group in which the Key 2608 Exchange Data was computed (see section 3.3.2). If the selected 2609 proposal uses a different Diffie-Hellman group, the message MUST be 2610 rejected with a Notify payload of type INVALID_KE_PAYLOAD. 2612 The payload type for the Key Exchange payload is thirty four (34). 2614 3.5 Identification Payloads 2616 The Identification Payloads, denoted IDi and IDr in this memo, allow 2617 peers to assert an identity to one another. This identity may be used 2618 for policy lookup, but does not necessarily have to match anything in 2619 the CERT payload; both fields may be used by an implementation to 2620 perform access control decisions. 2622 NOTE: In IKEv1, two ID payloads were used in each direction to hold 2623 Traffic Selector information for data passing over the SA. In IKEv2, 2624 this information is carried in Traffic Selector (TS) payloads (see 2625 section 3.13). 2627 The Identification Payload consists of the IKE generic payload header 2628 followed by identification fields as follows: 2630 1 2 3 2631 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 2632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2633 ! Next Payload !C! RESERVED ! Payload Length ! 2634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2635 ! ID Type ! RESERVED | 2636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2637 ! ! 2638 ~ Identification Data ~ 2639 ! ! 2640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2642 Figure 11: Identification Payload Format 2644 o ID Type (1 octet) - Specifies the type of Identification being 2645 used. 2647 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 2649 o Identification Data (variable length) - Value, as indicated by 2650 the Identification Type. The length of the Identification Data 2651 is computed from the size in the ID payload header. 2653 The payload types for the Identification Payload are thirty five (35) 2654 for IDi and thirty six (36) for IDr. 2656 The following table lists the assigned values for the Identification 2657 Type field, followed by a description of the Identification Data 2658 which follows: 2660 ID Type Value 2661 ------- ----- 2662 RESERVED 0 2664 ID_IPV4_ADDR 1 2666 A single four (4) octet IPv4 address. 2668 ID_FQDN 2 2670 A fully-qualified domain name string. An example of a 2671 ID_FQDN is, "example.com". The string MUST not contain any 2672 terminators (e.g., NULL, CR, etc.). 2674 ID_RFC822_ADDR 3 2676 A fully-qualified RFC822 email address string, An example of 2677 a ID_RFC822_ADDR is, "jsmith@example.com". The string MUST 2678 not contain any terminators. 2680 Reserved to IANA 4 2682 ID_IPV6_ADDR 5 2684 A single sixteen (16) octet IPv6 address. 2686 Reserved to IANA 6 - 8 2688 ID_DER_ASN1_DN 9 2690 The binary DER encoding of an ASN.1 X.500 Distinguished Name 2691 [X.501]. 2693 ID_DER_ASN1_GN 10 2695 The binary DER encoding of an ASN.1 X.500 GeneralName 2696 [X.509]. 2698 ID_KEY_ID 11 2700 An opaque octet stream which may be used to pass vendor- 2701 specific information necessary to do certain proprietary 2702 types of identification. 2704 Reserved to IANA 12-200 2706 Reserved for private use 201-255 2708 Two implementations will interoperate only if each can generate a 2709 type of ID acceptable to the other. To assure maximum 2710 interoperability, implementations MUST be configurable to send at 2711 least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and 2712 MUST be configurable to accept all of these types. Implementations 2713 SHOULD be capable of generating and accepting all of these types. 2714 IPv6 capable implementations MUST additionally be configurable to 2715 accept ID_IPV6_ADDR. IPv6 only implementations MAY be configurable 2716 to send only ID_IPV6_ADDR. 2718 3.6 Certificate Payload 2720 The Certificate Payload, denoted CERT in this memo, provides a means 2721 to transport certificates or other authentication related information 2722 via IKE. Certificate payloads SHOULD be included in an exchange if 2723 certificates are available to the sender unless the peer has 2724 indicated an ability to retrieve this information from elsewhere 2725 using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note that the 2726 term "Certificate Payload" is somewhat misleading, because not all 2727 authentication mechanisms use certificates and data other than 2728 certificates may be passed in this payload. 2730 The Certificate Payload is defined as follows: 2732 1 2 3 2733 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 2734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2735 ! Next Payload !C! RESERVED ! Payload Length ! 2736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2737 ! Cert Encoding ! ! 2738 +-+-+-+-+-+-+-+-+ ! 2739 ~ Certificate Data ~ 2740 ! ! 2741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2743 Figure 12: Certificate Payload Format 2745 o Certificate Encoding (1 octet) - This field indicates the type 2746 of certificate or certificate-related information contained 2747 in the Certificate Data field. 2749 Certificate Encoding Value 2750 -------------------- ----- 2751 RESERVED 0 2752 PKCS #7 wrapped X.509 certificate 1 2753 PGP Certificate 2 2754 DNS Signed Key 3 2755 X.509 Certificate - Signature 4 2756 Kerberos Token 6 2757 Certificate Revocation List (CRL) 7 2758 Authority Revocation List (ARL) 8 2759 SPKI Certificate 9 2760 X.509 Certificate - Attribute 10 2761 Raw RSA Key 11 2762 Hash and URL of X.509 certificate 12 2763 Hash and URL of X.509 bundle 13 2764 RESERVED to IANA 14 - 200 2765 PRIVATE USE 201 - 255 2767 o Certificate Data (variable length) - Actual encoding of 2768 certificate data. The type of certificate is indicated 2769 by the Certificate Encoding field. 2771 The payload type for the Certificate Payload is thirty seven (37). 2773 Specific syntax is for some of the certificate type codes above is 2774 not defined in this document. The types whose syntax is defined in 2775 this document are: 2777 X.509 Certificate - Signature (4) contains a DER encoded X.509 2778 certificate whose public key is used to validate the sender's AUTH 2779 payload. 2781 Certificate Revocation List (7) contains a DER encoded X.509 2782 certificate revocation list. 2784 Raw RSA Key (11) contains a PKCS #1 encoded RSA key. 2786 Hash and URL encodings (12-13) allow IKE messages to remain short 2787 by replacing long data structures with a 20 octet SHA-1 hash of 2788 the replaced value followed by a variable length URL that resolves 2789 to the DER encoded data structure itself. This improves efficiency 2790 when the endpoints have certificate data cached and makes IKE less 2791 subject to denial of service attacks that become easier to mount 2792 when IKE messages are large enough to require IP fragmentation 2793 [KPS03]. 2795 Use the following ASN.1 definition for an X.509 bundle: 2797 CertBundle 2798 { iso(1) identified-organization(3) dod(6) internet(1) 2799 security(5) mechanisms(5) pkix(7) id-mod(0) 2800 id-mod-cert-bundle(34) } 2802 DEFINITIONS EXPLICIT TAGS ::= 2803 BEGIN 2805 IMPORTS 2806 Certificate, CertificateList 2807 FROM PKIX1Explicit88 2808 { iso(1) identified-organization(3) dod(6) 2809 internet(1) security(5) mechanisms(5) pkix(7) 2810 id-mod(0) id-pkix1-explicit(18) } ; 2812 CertificateOrCRL ::= CHOICE { 2813 cert [0] Certificate, 2814 crl [1] CertificateList } 2816 CertificateBundle ::= SEQUENCE OF CertificateOrCRL 2818 END 2820 Implementations MUST be capable of being configured to send and 2821 accept up to four X.509 certificates in support of authentication, 2822 and also MUST be capable of being configured to send and accept the 2823 first two Hash and URL formats (with HTTP URLs). Implementations 2824 SHOULD be capable of being configured to send and accept Raw RSA 2825 keys. If multiple certificates are sent, the first certificate MUST 2826 contain the public key used to sign the AUTH payload. The other 2827 certificates may be sent in any order. 2829 3.7 Certificate Request Payload 2831 The Certificate Request Payload, denoted CERTREQ in this memo, 2832 provides a means to request preferred certificates via IKE and can 2833 appear in the IKE_INIT_SA response and/or the IKE_AUTH request. 2834 Certificate Request payloads MAY be included in an exchange when the 2835 sender needs to get the certificate of the receiver. If multiple CAs 2836 are trusted and the cert encoding does not allow a list, then 2837 multiple Certificate Request payloads SHOULD be transmitted. 2839 The Certificate Request Payload is defined as follows: 2841 1 2 3 2842 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 2843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2844 ! Next Payload !C! RESERVED ! Payload Length ! 2845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2846 ! Cert Encoding ! ! 2847 +-+-+-+-+-+-+-+-+ ! 2848 ~ Certification Authority ~ 2849 ! ! 2850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2852 Figure 13: Certificate Request Payload Format 2854 o Certificate Encoding (1 octet) - Contains an encoding of the type 2855 or format of certificate requested. Values are listed in section 2856 3.6. 2858 o Certification Authority (variable length) - Contains an encoding 2859 of an acceptable certification authority for the type of 2860 certificate requested. 2862 The payload type for the Certificate Request Payload is thirty eight 2863 (38). 2865 The Certificate Encoding field has the same values as those defined 2866 in section 3.6. The Certification Authority field contains an 2867 indicator of trusted authorities for this certificate type. The 2868 Certification Authority value is a concatenated list of SHA-1 hashes 2869 of the public keys of trusted CAs. Each is encoded as the SHA-1 hash 2870 of the Subject Public Key Info element (see section 4.1.2.7 of 2871 [RFC3280]) from each Trust Anchor certificate. The twenty-octet 2872 hashes are concatenated and included with no other formatting. 2874 Note that the term "Certificate Request" is somewhat misleading, in 2875 that values other than certificates are defined in a "Certificate" 2876 payload and requests for those values can be present in a Certificate 2877 Request Payload. The syntax of the Certificate Request payload in 2878 such cases is not defined in this document. 2880 The Certificate Request Payload is processed by inspecting the "Cert 2881 Encoding" field to determine whether the processor has any 2882 certificates of this type. If so the "Certification Authority" field 2883 is inspected to determine if the processor has any certificates which 2884 can be validated up to one of the specified certification 2885 authorities. This can be a chain of certificates. 2887 If an end-entity certificate exists which satisfies the criteria 2888 specified in the CERTREQ, a certificate or certificate chain SHOULD 2889 be sent back to the certificate requestor if: 2891 - the recipient of the CERTREQ is configured to use certificate 2892 authentication, 2894 - is allowed to send a CERT payload, 2896 - has matching CA trust policy governing the current negotiation, 2897 and 2899 - has at least one time-wise and usage appropriate end-entity 2900 certificate chaining to a CA provided in the CERTREQ. 2902 Certificate revocation checking must be considered during the 2903 chaining process used to select a certificate. Note that even if two 2904 peers are configured to use two different CAs, cross-certification 2905 relationships should be supported by appropriate selection logic. The 2906 intent is not to prevent communication through the strict adherence 2907 of selection of a certificate based on CERTREQ, when an alternate 2908 certificate could be selected by the sender which would still enable 2909 the recipient to successfully validate and trust it through trust 2910 conveyed by cross-certification, CRLs or other out-of-band configured 2911 means. Thus the processing of a CERTREQ should be seen as a 2912 suggestion for a certificate to select, not a mandated one. If no 2913 certificates exist then the CERTREQ is ignored. This is not an error 2914 condition of the protocol. There may be cases where there is a 2915 preferred CA sent in the CERTREQ, but an alternate might be 2916 acceptable (perhaps after prompting a human operator). 2918 3.8 Authentication Payload 2920 The Authentication Payload, denoted AUTH in this memo, contains data 2921 used for authentication purposes. The syntax of the Authentication 2922 data varies according to the Auth Method as specified below. 2924 The Authentication Payload is defined as follows: 2926 1 2 3 2927 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 2928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2929 ! Next Payload !C! RESERVED ! Payload Length ! 2930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2931 ! Auth Method ! RESERVED ! 2932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2933 ! ! 2934 ~ Authentication Data ~ 2935 ! ! 2936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2938 Figure 14: Authentication Payload Format 2940 o Auth Method (1 octet) - Specifies the method of authentication 2941 used. Values defined are: 2943 RSA Digital Signature (1) - Computed as specified in section 2944 2.15 using an RSA private key over a PKCS#1 padded hash. 2946 Shared Key Message Integrity Code (2) - Computed as specified in 2947 section 2.15 using the shared key associated with the identity 2948 in the ID payload and the negotiated prf function 2950 DSS Digital Signature (3) - Computed as specified in section 2951 2.15 using a DSS private key over a SHA-1 hash. 2953 The values 0 and 4-200 are reserved to IANA. The values 201-255 2954 are available for private use. 2956 o Authentication Data (variable length) - see section 2.15. 2958 The payload type for the Authentication Payload is thirty nine (39). 2960 3.9 Nonce Payload 2962 The Nonce Payload, denoted Ni and Nr in this memo for the initiator's 2963 and responder's nonce respectively, contains random data used to 2964 guarantee liveness during an exchange and protect against replay 2965 attacks. 2967 The Nonce Payload is defined as follows: 2969 1 2 3 2970 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 2971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2972 ! Next Payload !C! RESERVED ! Payload Length ! 2973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2974 ! ! 2975 ~ Nonce Data ~ 2976 ! ! 2977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2979 Figure 15: Nonce Payload Format 2981 o Nonce Data (variable length) - Contains the random data generated 2982 by the transmitting entity. 2984 The payload type for the Nonce Payload is forty (40). 2986 The size of a Nonce MUST be between 16 and 256 octets inclusive. 2987 Nonce values MUST NOT be reused. 2989 3.10 Notify Payload 2991 The Notify Payload, denoted N in this document, is used to transmit 2992 informational data, such as error conditions and state transitions, 2993 to an IKE peer. A Notify Payload may appear in a response message 2994 (usually specifying why a request was rejected), in an INFORMATIONAL 2995 Exchange (to report an error not in an IKE request), or in any other 2996 message to indicate sender capabilities or to modify the meaning of 2997 the request. 2999 The Notify Payload is defined as follows: 3001 1 2 3 3002 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 3003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3004 ! Next Payload !C! RESERVED ! Payload Length ! 3005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3006 ! Protocol ID ! SPI Size ! Notify Message Type ! 3007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3008 ! ! 3009 ~ Security Parameter Index (SPI) ~ 3010 ! ! 3011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3012 ! ! 3013 ~ Notification Data ~ 3014 ! ! 3015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3017 Figure 16: Notification Payload Format 3019 o Protocol ID (1 octet) - If this notification concerns 3020 an existing SA, this field indicates the type of that SA. 3021 For IKE_SA notifications, this field MUST be one (1). For 3022 notifications concerning IPsec SAs this field MUST contain 3023 either (2) to indicate AH or (3) to indicate ESP. For 3024 notifications which do not relate to an existing SA, this 3025 field MUST be sent as zero and MUST be ignored on receipt. 3026 All other values for this field are reserved to IANA for future 3027 assignment. 3029 o SPI Size (1 octet) - Length in octets of the SPI as defined by 3030 the IPsec protocol ID or zero if no SPI is applicable. For a 3031 notification concerning the IKE_SA, the SPI Size MUST be zero. 3033 o Notify Message Type (2 octets) - Specifies the type of 3034 notification message. 3036 o SPI (variable length) - Security Parameter Index. 3038 o Notification Data (variable length) - Informational or error data 3039 transmitted in addition to the Notify Message Type. Values for 3040 this field are type specific (see below). 3042 The payload type for the Notification Payload is forty one (41). 3044 3.10.1 Notify Message Types 3046 Notification information can be error messages specifying why an SA 3047 could not be established. It can also be status data that a process 3048 managing an SA database wishes to communicate with a peer process. 3049 The table below lists the Notification messages and their 3050 corresponding values. The number of different error statuses was 3051 greatly reduced from IKE V1 both for simplification and to avoid 3052 giving configuration information to probers. 3054 Types in the range 0 - 16383 are intended for reporting errors. An 3055 implementation receiving a Notify payload with one of these types 3056 that it does not recognize in a response MUST assume that the 3057 corresponding request has failed entirely. Unrecognized error types 3058 in a request and status types in a request or response MUST be 3059 ignored except that they SHOULD be logged. 3061 Notify payloads with status types MAY be added to any message and 3062 MUST be ignored if not recognized. They are intended to indicate 3063 capabilities, and as part of SA negotiation are used to negotiate 3064 non-cryptographic parameters. 3066 NOTIFY MESSAGES - ERROR TYPES Value 3067 ----------------------------- ----- 3068 RESERVED 0 3070 UNSUPPORTED_CRITICAL_PAYLOAD 1 3072 Sent if the payload has the "critical" bit set and the 3073 payload type is not recognized. Notification Data contains 3074 the one octet payload type. 3076 INVALID_IKE_SPI 4 3078 Indicates an IKE message was received with an unrecognized 3079 destination SPI. This usually indicates that the recipient 3080 has rebooted and forgotten the existence of an IKE_SA. 3082 INVALID_MAJOR_VERSION 5 3084 Indicates the recipient cannot handle the version of IKE 3085 specified in the header. The closest version number that the 3086 recipient can support will be in the reply header. 3088 INVALID_SYNTAX 7 3090 Indicates the IKE message was received was invalid because 3091 some type, length, or value was out of range or because the 3092 request was rejected for policy reasons. To avoid a denial 3093 of service attack using forged messages, this status may 3094 only be returned for and in an encrypted packet if the 3095 message ID and cryptographic checksum were valid. To avoid 3096 leaking information to someone probing a node, this status 3097 MUST be sent in response to any error not covered by one of 3098 the other status types. To aid debugging, more detailed 3099 error information SHOULD be written to a console or log. 3101 INVALID_MESSAGE_ID 9 3103 Sent when an IKE message ID outside the supported window is 3104 received. This Notify MUST NOT be sent in a response; the 3105 invalid request MUST NOT be acknowledged. Instead, inform 3106 the other side by initiating an INFORMATIONAL exchange with 3107 Notification data containing the four octet invalid message 3108 ID. Sending this notification is optional and notifications 3109 of this type MUST be rate limited. 3111 INVALID_SPI 11 3113 MAY be sent in an IKE INFORMATIONAL Exchange when a node 3114 receives an ESP or AH packet with an invalid SPI. The 3115 Notification Data contains the SPI of the invalid packet. 3116 This usually indicates a node has rebooted and forgotten an 3117 SA. If this Informational Message is sent outside the 3118 context of an IKE_SA, it should only be used by the 3119 recipient as a "hint" that something might be wrong (because 3120 it could easily be forged). 3122 NO_PROPOSAL_CHOSEN 14 3124 None of the proposed crypto suites was acceptable. 3126 INVALID_KE_PAYLOAD 17 3128 The D-H Group # field in the KE payload is not the group # 3129 selected by the responder for this exchange. There are two 3130 octets of data associated with this notification: the 3131 accepted D-H Group # in big endian order. 3133 AUTHENTICATION_FAILED 24 3135 Sent in the response to an IKE_AUTH message when for some 3136 reason the authentication failed. There is no associated 3137 data. 3139 SINGLE_PAIR_REQUIRED 34 3140 This error indicates that a CREATE_CHILD_SA request is 3141 unacceptable because its sender is only willing to accept 3142 traffic selectors specifying a single pair of addresses. 3143 The requestor is expected to respond by requesting an SA for 3144 only the specific traffic it is trying to forward. 3146 NO_ADDITIONAL_SAS 35 3148 This error indicates that a CREATE_CHILD_SA request is 3149 unacceptable because the responder is unwilling to accept 3150 any more CHILD_SAs on this IKE_SA. Some minimal 3151 implementations may only accept a single CHILD_SA setup in 3152 the context of an initial IKE exchange and reject any 3153 subsequent attempts to add more. 3155 INTERNAL_ADDRESS_FAILURE 36 3157 Indicates an error assigning an internal address (i.e., 3158 INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS) during the 3159 processing of a Configuration Payload by a responder. If 3160 this error is generated within an IKE_AUTH exchange no 3161 CHILD_SA will be created. 3163 FAILED_CP_REQUIRED 37 3165 Sent by responder in the case where CP(CFG_REQUEST) was 3166 expected but not received, and so is a conflict with locally 3167 configured policy. There is no associated data. 3169 TS_UNACCEPTABLE 38 3171 Indicates that none of the addresses/protocols/ports in the 3172 supplied traffic selectors is acceptable. 3174 INVALID_SELECTORS 39 3176 MAY be sent in an IKE INFORMATIONAL Exchange when a node 3177 receives an ESP or AH packet whose selectors do not match 3178 those of the SA on which it was delivered (and which caused 3179 the packet to be dropped). The Notification Data contains 3180 the start of the offending packet (as in ICMP messages) and 3181 the SPI field of the notification is set to match the SPI of 3182 the IPsec SA. 3183 RESERVED TO IANA - Error types 40 - 8191 3185 Private Use - Errors 8192 - 16383 3186 NOTIFY MESSAGES - STATUS TYPES Value 3187 ------------------------------ ----- 3189 INITIAL_CONTACT 16384 3191 This notification asserts that this IKE_SA is the only 3192 IKE_SA currently active between the authenticated 3193 identities. It MAY be sent when an IKE_SA is established 3194 after a crash, and the recipient MAY use this information to 3195 delete any other IKE_SAs it has to the same authenticated 3196 identity without waiting for a timeout. This notification 3197 MUST NOT be sent by an entity that may be replicated (e.g., 3198 a roaming user's credentials where the user is allowed to 3199 connect to the corporate firewall from two remote systems at 3200 the same time). 3202 SET_WINDOW_SIZE 16385 3204 This notification asserts that the sending endpoint is 3205 capable of keeping state for multiple outstanding exchanges, 3206 permitting the recipient to send multiple requests before 3207 getting a response to the first. The data associated with a 3208 SET_WINDOW_SIZE notification MUST be 4 octets long and 3209 contain the big endian representation of the number of 3210 messages the sender promises to keep. Window size is always 3211 one until the initial exchanges complete. 3213 ADDITIONAL_TS_POSSIBLE 16386 3215 This notification asserts that the sending endpoint narrowed 3216 the proposed traffic selectors but that other traffic 3217 selectors would also have been acceptable, though only in a 3218 separate SA (see section 2.9). There is no data associated 3219 with this Notify type. It may only be sent as an additional 3220 payload in a message including accepted TSs. 3222 IPCOMP_SUPPORTED 16387 3224 This notification may only be included in a message 3225 containing an SA payload negotiating a CHILD_SA and 3226 indicates a willingness by its sender to use IPComp on this 3227 SA. The data associated with this notification includes a 3228 two octet IPComp CPI followed by a one octet transform ID 3229 optionally followed by attributes whose length and format is 3230 defined by that transform ID. A message proposing an SA may 3231 contain multiple IPCOMP_SUPPORTED notifications to indicate 3232 multiple supported algorithms. A message accepting an SA may 3233 contain at most one. 3235 The transform IDs currently defined are: 3237 NAME NUMBER DEFINED IN 3238 ----------- ------ ----------- 3239 RESERVED 0 3240 IPCOMP_OUI 1 3241 IPCOMP_DEFLATE 2 RFC 2394 3242 IPCOMP_LZS 3 RFC 2395 3243 IPCOMP_LZJH 4 RFC 3051 3245 values 5-240 are reserved to IANA. Values 241-255 are 3246 for private use among mutually consenting parties. 3248 NAT_DETECTION_SOURCE_IP 16388 3250 This notification is used by its recipient to determine 3251 whether the source is behind a NAT box. The data associated 3252 with this notification is a SHA-1 digest of the SPIs (in the 3253 order they appear in the header), IP address and port on 3254 which this packet was sent. There MAY be multiple Notify 3255 payloads of this type in a message if the sender does not 3256 know which of several network attachments will be used to 3257 send the packet. The recipient of this notification MAY 3258 compare the supplied value to a SHA-1 hash of the SPIs, 3259 source IP address and port and if they don't match it SHOULD 3260 enable NAT traversal (see section 2.23). Alternately, it 3261 MAY reject the connection attempt if NAT traversal is not 3262 supported. 3264 NAT_DETECTION_DESTINATION_IP 16389 3266 This notification is used by its recipient to determine 3267 whether it is behind a NAT box. The data associated with 3268 this notification is a SHA-1 digest of the SPIs (in the 3269 order they appear in the header), IP address and port to 3270 which this packet was sent. The recipient of this 3271 notification MAY compare the supplied value to a hash of the 3272 SPIs, destination IP address and port and if they don't 3273 match it SHOULD invoke NAT traversal (see section 2.23). If 3274 they don't match, it means that this end is behind a NAT and 3275 this end SHOULD start sending keepalive packets as defined 3276 in [Hutt04]. Alternately, it MAY reject the connection 3277 attempt if NAT traversal is not supported. 3279 COOKIE 16390 3281 This notification MAY be included in an IKE_SA_INIT 3282 response. It indicates that the request should be retried 3283 with a copy of this notification as the first payload. This 3284 notification MUST be included in an IKE_SA_INIT request 3285 retry if a COOKIE notification was included in the initial 3286 response. The data associated with this notification MUST 3287 be between 1 and 64 octets in length (inclusive). 3289 USE_TRANSPORT_MODE 16391 3291 This notification MAY be included in a request message that 3292 also includes an SA payload requesting a CHILD_SA. It 3293 requests that the CHILD_SA use transport mode rather than 3294 tunnel mode for the SA created. If the request is accepted, 3295 the response MUST also include a notification of type 3296 USE_TRANSPORT_MODE. If the responder declines the request, 3297 the CHILD_SA will be established in tunnel mode. If this is 3298 unacceptable to the initiator, the initiator MUST delete the 3299 SA. Note: except when using this option to negotiate 3300 transport mode, all CHILD_SAs will use tunnel mode. 3302 Note: The ECN decapsulation modifications specified in 3303 [RFC2401bis] MUST be performed for every tunnel mode SA 3304 created by IKEv2. 3306 HTTP_CERT_LOOKUP_SUPPORTED 16392 3308 This notification MAY be included in any message that can 3309 include a CERTREQ payload and indicates that the sender is 3310 capable of looking up certificates based on an HTTP-based 3311 URL (and hence presumably would prefer to receive 3312 certificate specifications in that format). 3314 REKEY_SA 16393 3316 This notification MUST be included in a CREATE_CHILD_SA 3317 exchange if the purpose of the exchange is to replace an 3318 existing ESP or AH SA. The SPI field identifies the SA being 3319 rekeyed. There is no data. 3321 ESP_TFC_PADDING_NOT_SUPPORTED 16394 3323 This notification asserts that the sending endpoint will NOT 3324 accept packets that contain Flow Confidentiality (TFC) 3325 padding. 3327 NON_FIRST_FRAGMENTS_ALSO 16395 3329 Used for fragmentation control. See [RFC2401bis] for 3330 explanation. 3332 RESERVED TO IANA - STATUS TYPES 16396 - 40959 3334 Private Use - STATUS TYPES 40960 - 65535 3336 3.11 Delete Payload 3338 The Delete Payload, denoted D in this memo, contains a protocol 3339 specific security association identifier that the sender has removed 3340 from its security association database and is, therefore, no longer 3341 valid. Figure 17 shows the format of the Delete Payload. It is 3342 possible to send multiple SPIs in a Delete payload, however, each SPI 3343 MUST be for the same protocol. Mixing of protocol identifiers MUST 3344 NOT be performed in a the Delete payload. It is permitted, however, 3345 to include multiple Delete payloads in a single INFORMATIONAL 3346 Exchange where each Delete payload lists SPIs for a different 3347 protocol. 3349 Deletion of the IKE_SA is indicated by a protocol ID of 1 (IKE) but 3350 no SPIs. Deletion of a CHILD_SA, such as ESP or AH, will contain the 3351 IPsec protocol ID of that protocol (2 for AH, 3 for ESP) and the SPI 3352 is the SPI the sending endpoint would expect in inbound ESP or AH 3353 packets. 3355 The Delete Payload is defined as follows: 3357 1 2 3 3358 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 3359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3360 ! Next Payload !C! RESERVED ! Payload Length ! 3361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3362 ! Protocol ID ! SPI Size ! # of SPIs ! 3363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3364 ! ! 3365 ~ Security Parameter Index(es) (SPI) ~ 3366 ! ! 3367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3369 Figure 17: Delete Payload Format 3371 o Protocol ID (1 octet) - Must be 1 for an IKE_SA, 2 for AH, or 3372 3 for ESP. 3374 o SPI Size (1 octet) - Length in octets of the SPI as defined by 3375 the protocol ID. It MUST be zero for IKE (SPI is in message 3376 header) or four for AH and ESP. 3378 o # of SPIs (2 octets) - The number of SPIs contained in the Delete 3379 payload. The size of each SPI is defined by the SPI Size field. 3381 o Security Parameter Index(es) (variable length) - Identifies the 3382 specific security association(s) to delete. The length of this 3383 field is determined by the SPI Size and # of SPIs fields. 3385 The payload type for the Delete Payload is forty two (42). 3387 3.12 Vendor ID Payload 3389 The Vendor ID Payload contains a vendor defined constant. The 3390 constant is used by vendors to identify and recognize remote 3391 instances of their implementations. This mechanism allows a vendor 3392 to experiment with new features while maintaining backwards 3393 compatibility. 3395 A Vendor ID payload MAY announce that the sender is capable to 3396 accepting certain extensions to the protocol, or it MAY simply 3397 identify the implementation as an aid in debugging. A Vendor ID 3398 payload MUST NOT change the interpretation of any information defined 3399 in this specification (i.e., the critical bit MUST be set to 0). 3400 Multiple Vendor ID payloads MAY be sent. An implementation is NOT 3401 REQUIRED to send any Vendor ID payload at all. 3403 A Vendor ID payload may be sent as part of any message. Reception of 3404 a familiar Vendor ID payload allows an implementation to make use of 3405 Private USE numbers described throughout this memo-- private 3406 payloads, private exchanges, private notifications, etc. Unfamiliar 3407 Vendor IDs MUST be ignored. 3409 Writers of Internet-Drafts who wish to extend this protocol MUST 3410 define a Vendor ID payload to announce the ability to implement the 3411 extension in the Internet-Draft. It is expected that Internet-Drafts 3412 which gain acceptance and are standardized will be given "magic 3413 numbers" out of the Future Use range by IANA and the requirement to 3414 use a Vendor ID will go away. 3416 The Vendor ID Payload fields are defined as follows: 3418 1 2 3 3419 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 3420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3421 ! Next Payload !C! RESERVED ! Payload Length ! 3422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3423 ! ! 3424 ~ Vendor ID (VID) ~ 3425 ! ! 3426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3428 Figure 18: Vendor ID Payload Format 3430 o Vendor ID (variable length) - It is the responsibility of 3431 the person choosing the Vendor ID to assure its uniqueness 3432 in spite of the absence of any central registry for IDs. 3433 Good practice is to include a company name, a person name 3434 or some such. If you want to show off, you might include 3435 the latitude and longitude and time where you were when 3436 you chose the ID and some random input. A message digest 3437 of a long unique string is preferable to the long unique 3438 string itself. 3440 The payload type for the Vendor ID Payload is forty three (43). 3442 3.13 Traffic Selector Payload 3444 The Traffic Selector Payload, denoted TS in this memo, allows peers 3445 to identify packet flows for processing by IPsec security services. 3446 The Traffic Selector Payload consists of the IKE generic payload 3447 header followed by individual traffic selectors as follows: 3449 1 2 3 3450 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 3451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3452 ! Next Payload !C! RESERVED ! Payload Length ! 3453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3454 ! Number of TSs ! RESERVED ! 3455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3456 ! ! 3457 ~ ~ 3458 ! ! 3459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3461 Figure 19: Traffic Selectors Payload Format 3463 o Number of TSs (1 octet) - Number of traffic selectors 3464 being provided. 3466 o RESERVED - This field MUST be sent as zero and MUST be ignored 3467 on receipt. 3469 o Traffic Selectors (variable length) - one or more individual 3470 traffic selectors. 3472 The length of the Traffic Selector payload includes the TS header and 3473 all the traffic selectors. 3475 The payload type for the Traffic Selector payload is forty four (44) 3476 for addresses at the initiator's end of the SA and forty five (45) 3477 for addresses at the responder's end. 3479 3.13.1 Traffic Selector 3481 1 2 3 3482 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 3483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3484 ! TS Type !IP Protocol ID*| Selector Length | 3485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3486 | Start Port* | End Port* | 3487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3488 ! ! 3489 ~ Starting Address* ~ 3490 ! ! 3491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3492 ! ! 3493 ~ Ending Address* ~ 3494 ! ! 3495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3497 Figure 20: Traffic Selector 3499 *Note: all fields other than TS Type and Selector Length depend on 3500 the TS Type. The fields shown are for TS Types 7 and 8, the only two 3501 values currently defined. 3503 o TS Type (one octet) - Specifies the type of traffic selector. 3505 o IP protocol ID (1 octet) - Value specifying an associated IP 3506 protocol ID (e.g., UDP/TCP/ICMP). A value of zero means that 3507 the protocol ID is not relevant to this traffic selector-- 3508 the SA can carry all protocols. 3510 o Selector Length - Specifies the length of this Traffic 3511 Selector Substructure including the header. 3513 o Start Port (2 octets) - Value specifying the smallest port 3514 number allowed by this Traffic Selector. For protocols for 3515 which port is undefined, or if all ports are allowed, 3516 this field MUST be zero. For the 3517 ICMP protocol, the two one octet fields Type and Code are 3518 treated as a single 16 bit integer (with Type in the most 3519 significant eight bits and Code in the least significant 3520 eight bits) port number for the purposes of filtering based 3521 on this field. 3523 o End Port (2 octets) - Value specifying the largest port 3524 number allowed by this Traffic Selector. For protocols for 3525 which port is undefined, or if all ports are allowed, 3526 this field MUST be 65535. For the 3527 ICMP protocol, the two one octet fields Type and Code are 3528 treated as a single 16 bit integer (with Type in the most 3529 significant eight bits and Code in the least significant 3530 eight bits) port number for the purposed of filtering based 3531 on this field. 3533 o Starting Address - The smallest address included in this 3534 Traffic Selector (length determined by TS type). 3536 o Ending Address - The largest address included in this 3537 Traffic Selector (length determined by TS type). 3539 Systems that are complying with [RFC2401bis] that wish to indicate 3540 "ANY" ports MUST set the start port to 0 and the end port to 65535; 3541 note that according to [RFC2401bis], "ANY" includes "OPAQUE". Systems 3542 working with [RFC2401bis] that wish to indicate "OPAQUE" ports, but 3543 not "ANY" ports, MUST set the start port to 65535 and the end port to 3544 0. 3546 The following table lists the assigned values for the Traffic 3547 Selector Type field and the corresponding Address Selector Data. 3549 TS Type Value 3550 ------- ----- 3551 RESERVED 0-6 3553 TS_IPV4_ADDR_RANGE 7 3555 A range of IPv4 addresses, represented by two four (4) octet 3556 values. The first value is the beginning IPv4 address 3557 (inclusive) and the second value is the ending IPv4 address 3558 (inclusive). All addresses falling between the two specified 3559 addresses are considered to be within the list. 3561 TS_IPV6_ADDR_RANGE 8 3563 A range of IPv6 addresses, represented by two sixteen (16) 3564 octet values. The first value is the beginning IPv6 address 3565 (inclusive) and the second value is the ending IPv6 address 3566 (inclusive). All addresses falling between the two specified 3567 addresses are considered to be within the list. 3569 RESERVED TO IANA 9-240 3570 PRIVATE USE 241-255 3572 3.14 Encrypted Payload 3574 The Encrypted Payload, denoted SK{...} in this memo, contains other 3575 payloads in encrypted form. The Encrypted Payload, if present in a 3576 message, MUST be the last payload in the message. Often, it is the 3577 only payload in the message. 3579 The algorithms for encryption and integrity protection are negotiated 3580 during IKE_SA setup, and the keys are computed as specified in 3581 sections 2.14 and 2.18. 3583 The encryption and integrity protection algorithms are modeled after 3584 the ESP algorithms described in RFCs 2104, 2406, 2451. This document 3585 completely specifies the cryptographic processing of IKE data, but 3586 those documents should be consulted for design rationale. We assume a 3587 block cipher with a fixed block size and an integrity check algorithm 3588 that computes a fixed length checksum over a variable size message. 3590 The payload type for an Encrypted payload is forty six (46). The 3591 Encrypted Payload consists of the IKE generic payload header followed 3592 by individual fields as follows: 3594 1 2 3 3595 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 3596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3597 ! Next Payload !C! RESERVED ! Payload Length ! 3598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3599 ! Initialization Vector ! 3600 ! (length is block size for encryption algorithm) ! 3601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3602 ! Encrypted IKE Payloads ! 3603 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3604 ! ! Padding (0-255 octets) ! 3605 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 3606 ! ! Pad Length ! 3607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3608 ~ Integrity Checksum Data ~ 3609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3611 Figure 21: Encrypted Payload Format 3613 o Next Payload - The payload type of the first embedded payload. 3614 Note that this is an exception in the standard header format, 3615 since the Encrypted payload is the last payload in the 3616 message and therefore the Next Payload field would normally 3617 be zero. But because the content of this payload is embedded 3618 payloads and there was no natural place to put the type of 3619 the first one, that type is placed here. 3621 o Payload Length - Includes the lengths of the header, IV, 3622 Encrypted IKE Payloads, Padding, Pad Length and Integrity 3623 Checksum Data. 3625 o Initialization Vector - A randomly chosen value whose length 3626 is equal to the block length of the underlying encryption 3627 algorithm. Recipients MUST accept any value. Senders SHOULD 3628 either pick this value pseudo-randomly and independently for 3629 each message or use the final ciphertext block of the previous 3630 message sent. Senders MUST NOT use the same value for each 3631 message, use a sequence of values with low hamming distance 3632 (e.g., a sequence number), or use ciphertext from a received 3633 message. 3635 o IKE Payloads are as specified earlier in this section. This 3636 field is encrypted with the negotiated cipher. 3638 o Padding MAY contain any value chosen by the sender, and MUST 3639 have a length that makes the combination of the Payloads, the 3640 Padding, and the Pad Length to be a multiple of the encryption 3641 block size. This field is encrypted with the negotiated 3642 cipher. 3644 o Pad Length is the length of the Padding field. The sender 3645 SHOULD set the Pad Length to the minimum value that makes 3646 the combination of the Payloads, the Padding, and the Pad 3647 Length a multiple of the block size, but the recipient MUST 3648 accept any length that results in proper alignment. This 3649 field is encrypted with the negotiated cipher. 3651 o Integrity Checksum Data is the cryptographic checksum of 3652 the entire message starting with the Fixed IKE Header 3653 through the Pad Length. The checksum MUST be computed over 3654 the encrypted message. Its length is determined by the 3655 integrity algorithm negotiated. 3657 3.15 Configuration Payload 3659 The Configuration payload, denoted CP in this document, is used to 3660 exchange configuration information between IKE peers. The exchange is 3661 for an IRAC to request an internal IP address from an IRAS and to 3662 exchange other information of the sort that one would acquire with 3663 DHCP if the IRAC were directly connected to a LAN. 3665 Configuration payloads are of type CFG_REQUEST/CFG_REPLY or 3666 CFG_SET/CFG_ACK (see CFG Type in the payload description below). 3667 CFG_REQUEST and CFG_SET payloads may optionally be added to any IKE 3668 request. The IKE response MUST include either a corresponding 3669 CFG_REPLY or CFG_ACK or a Notify payload with an error type 3670 indicating why the request could not be honored. An exception is that 3671 a minimal implementation MAY ignore all CFG_REQUEST and CFG_SET 3672 payloads, so a response message without a corresponding CFG_REPLY or 3673 CFG_ACK MUST be accepted as an indication that the request was not 3674 supported. 3676 "CFG_REQUEST/CFG_REPLY" allows an IKE endpoint to request information 3677 from its peer. If an attribute in the CFG_REQUEST Configuration 3678 Payload is not zero length it is taken as a suggestion for that 3679 attribute. The CFG_REPLY Configuration Payload MAY return that 3680 value, or a new one. It MAY also add new attributes and not include 3681 some requested ones. Requestors MUST ignore returned attributes that 3682 they do not recognize. 3684 Some attributes MAY be multi-valued, in which case multiple attribute 3685 values of the same type are sent and/or returned. Generally, all 3686 values of an attribute are returned when the attribute is requested. 3687 For some attributes (in this version of the specification only 3688 internal addresses), multiple requests indicates a request that 3689 multiple values be assigned. For these attributes, the number of 3690 values returned SHOULD NOT exceed the number requested. 3692 If the data type requested in a CFG_REQUEST is not recognized or not 3693 supported, the responder MUST NOT return an error type but rather 3694 MUST either send a CFG_REPLY which MAY be empty or a reply not 3695 containing a CFG_REPLY payload at all. Error returns are reserved for 3696 cases where the request is recognized but cannot be performed as 3697 requested or the request is badly formatted. 3699 "CFG_SET/CFG_ACK" allows an IKE endpoint to push configuration data 3700 to its peer. In this case the CFG_SET Configuration Payload contains 3701 attributes the initiator wants its peer to alter. The responder MUST 3702 return a Configuration Payload if it accepted any of the 3703 configuration data and it MUST contain the attributes that the 3704 responder accepted with zero length data. Those attributes that it 3705 did not accept MUST NOT be in the CFG_ACK Configuration Payload. If 3706 no attributes were accepted, the responder MUST return either an 3707 empty CFG_ACK payload or a response message without a CFG_ACK 3708 payload. There are currently no defined uses for the CFG_SET/CFG_ACK 3709 exchange, though they may be used in connection with extensions based 3710 on Vendor IDs. An minimal implementation of this specification MAY 3711 ignore CFG_SET payloads. 3713 Extensions via the CP payload SHOULD NOT be used for general purpose 3714 management. Its main intent is to provide a bootstrap mechanism to 3715 exchange information within IPsec from IRAS to IRAC. While it MAY be 3716 useful to use such a method to exchange information between some 3717 Security Gateways (SGW) or small networks, existing management 3718 protocols such as DHCP [DHCP], RADIUS [RADIUS], SNMP or LDAP [LDAP] 3719 should be preferred for enterprise management as well as subsequent 3720 information exchanges. 3722 The Configuration Payload is defined as follows: 3724 1 2 3 3725 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 3726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3727 ! Next Payload !C! RESERVED ! Payload Length ! 3728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3729 ! CFG Type ! RESERVED ! 3730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3731 ! ! 3732 ~ Configuration Attributes ~ 3733 ! ! 3734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3736 Figure 22: Configuration Payload Format 3738 The payload type for the Configuration Payload is forty seven (47). 3740 o CFG Type (1 octet) - The type of exchange represented by the 3741 Configuration Attributes. 3743 CFG Type Value 3744 =========== ===== 3745 RESERVED 0 3746 CFG_REQUEST 1 3747 CFG_REPLY 2 3748 CFG_SET 3 3749 CFG_ACK 4 3751 values 5-127 are reserved to IANA. Values 128-255 are for private 3752 use among mutually consenting parties. 3754 o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on 3755 receipt. 3757 o Configuration Attributes (variable length) - These are type 3758 length values specific to the Configuration Payload and are 3759 defined below. There may be zero or more Configuration 3760 Attributes in this payload. 3762 3.15.1 Configuration Attributes 3764 1 2 3 3765 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 3766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3767 !R| Attribute Type ! Length | 3768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3769 | | 3770 ~ Value ~ 3771 | | 3772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3774 Figure 23: Configuration Attribute Format 3776 o Reserved (1 bit) - This bit MUST be set to zero and MUST be 3777 ignored on receipt. 3779 o Attribute Type (7 bits) - A unique identifier for each of the 3780 Configuration Attribute Types. 3782 o Length (2 octets) - Length in octets of Value. 3784 o Value (0 or more octets) - The variable length value of this 3785 Configuration Attribute. 3787 The following attribute types have been defined: 3789 Multi- 3790 Attribute Type Value Valued Length 3791 ======================= ===== ====== ================== 3792 RESERVED 0 3793 INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets 3794 INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets 3795 INTERNAL_IP4_DNS 3 YES 0 or 4 octets 3796 INTERNAL_IP4_NBNS 4 YES 0 or 4 octets 3797 INTERNAL_ADDRESS_EXPIRY 5 NO 0 or 4 octets 3798 INTERNAL_IP4_DHCP 6 YES 0 or 4 octets 3799 APPLICATION_VERSION 7 NO 0 or more 3800 INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets 3801 RESERVED 9 3802 INTERNAL_IP6_DNS 10 YES 0 or 16 octets 3803 INTERNAL_IP6_NBNS 11 YES 0 or 16 octets 3804 INTERNAL_IP6_DHCP 12 YES 0 or 16 octets 3805 INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets 3806 SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 3807 INTERNAL_IP6_SUBNET 15 YES 17 octets 3809 * These attributes may be multi-valued on return only if 3810 multiple values were requested. 3812 Types 16-16383 are reserved to IANA. Values 16384-32767 are for 3813 private use among mutually consenting parties. 3815 o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the 3816 internal network, sometimes called a red node address or 3817 private address and MAY be a private address on the Internet. 3818 In a request message, the address specified is a requested 3819 address (or zero if no specific address is requested). If a 3820 specific address is requested, it likely indicates that a 3821 previous connection existed with this address and the requestor 3822 would like to reuse that address. With IPv6, a requestor 3823 MAY supply the low order address bytes it wants to use. 3824 Multiple internal addresses MAY be requested by requesting 3825 multiple internal address attributes. The responder MAY only 3826 send up to the number of addresses requested. The 3827 INTERNAL_IP6_ADDRESS is made up of two fields; the first 3828 being a 16 octet IPv6 address and the second being a one octet 3829 prefix-length as defined in [ADDRIPV6]. 3831 The requested address is valid until the expiry time defined 3832 with the INTERNAL_ADDRESS EXPIRY attribute or there are no 3833 IKE_SAs between the peers. 3835 o INTERNAL_IP4_NETMASK - The internal network's netmask. Only 3836 one netmask is allowed in the request and reply messages 3837 (e.g., 255.255.255.0) and it MUST be used only with an 3838 INTERNAL_IP4_ADDRESS attribute. 3840 o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a 3841 DNS server within the network. Multiple DNS servers MAY be 3842 requested. The responder MAY respond with zero or more DNS 3843 server attributes. 3845 o INTERNAL_IP4_NBNS, INTERNAL_IP6_NBNS - Specifies an address of 3846 a NetBios Name Server (WINS) within the network. Multiple NBNS 3847 servers MAY be requested. The responder MAY respond with zero 3848 or more NBNS server attributes. 3850 o INTERNAL_ADDRESS_EXPIRY - Specifies the number of seconds that 3851 the host can use the internal IP address. The host MUST renew 3852 the IP address before this expiry time. Only one of these 3853 attributes MAY be present in the reply. 3855 o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to 3856 send any internal DHCP requests to the address contained within 3857 the attribute. Multiple DHCP servers MAY be requested. The 3858 responder MAY respond with zero or more DHCP server attributes. 3860 o APPLICATION_VERSION - The version or application information of 3861 the IPsec host. This is a string of printable ASCII characters 3862 that is NOT null terminated. 3864 o INTERNAL_IP4_SUBNET - The protected sub-networks that this 3865 edge-device protects. This attribute is made up of two fields; 3866 the first being an IP address and the second being a netmask. 3867 Multiple sub-networks MAY be requested. The responder MAY 3868 respond with zero or more sub-network attributes. 3870 o SUPPORTED_ATTRIBUTES - When used within a Request, this 3871 attribute MUST be zero length and specifies a query to the 3872 responder to reply back with all of the attributes that it 3873 supports. The response contains an attribute that contains a 3874 set of attribute identifiers each in 2 octets. The length 3875 divided by 2 (octets) would state the number of supported 3876 attributes contained in the response. 3878 o INTERNAL_IP6_SUBNET - The protected sub-networks that this 3879 edge-device protects. This attribute is made up of two fields; 3880 the first being a 16 octet IPv6 address the second being a one 3881 octet prefix-length as defined in [ADDRIPV6]. Multiple 3882 sub-networks MAY be requested. The responder MAY respond with 3883 zero or more sub-network attributes. 3885 Note that no recommendations are made in this document how an 3886 implementation actually figures out what information to send in a 3887 reply. i.e., we do not recommend any specific method of an IRAS 3888 determining which DNS server should be returned to a requesting 3889 IRAC. 3891 3.16 Extensible Authentication Protocol (EAP) Payload 3893 The Extensible Authentication Protocol Payload, denoted EAP in this 3894 memo, allows IKE_SAs to be authenticated using the protocol defined 3895 in RFC 3748 [EAP] and subsequent extensions to that protocol. The 3896 full set of acceptable values for the payload are defined elsewhere, 3897 but a short summary of RFC 3748 is included here to make this 3898 document stand alone in the common cases. 3900 1 2 3 3901 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 3902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3903 ! Next Payload !C! RESERVED ! Payload Length ! 3904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3905 ! ! 3906 ~ EAP Message ~ 3907 ! ! 3908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3910 Figure 24: EAP Payload Format 3912 The payload type for an EAP Payload is forty eight (48). 3914 1 2 3 3915 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 3916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3917 ! Code ! Identifier ! Length ! 3918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3919 ! Type ! Type_Data... 3920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 3922 Figure 25: EAP Message Format 3924 o Code (one octet) indicates whether this message is a 3925 Request (1), Response (2), Success (3), or Failure (4). 3927 o Identifier (one octet) is used in PPP to distinguish replayed 3928 messages from repeated ones. Since in IKE, EAP runs over a 3929 reliable protocol, it serves no function here. In a response 3930 message this octet MUST be set to match the identifier in the 3931 corresponding request. In other messages, this field MAY 3932 be set to any value. 3934 o Length (two octets) is the length of the EAP message and MUST 3935 be four less than the Payload Length of the encapsulating 3936 payload. 3938 o Type (one octet) is present only if the Code field is Request 3939 (1) or Response (2). For other codes, the EAP message length 3940 MUST be four octets and the Type and Type_Data fields MUST NOT 3941 be present. In a Request (1) message, Type indicates the 3942 data being requested. In a Response (2) message, Type MUST 3943 either be Nak or match the type of the data requested. The 3944 following types are defined in RFC 3748: 3946 1 Identity 3947 2 Notification 3948 3 Nak (Response Only) 3949 4 MD5-Challenge 3950 5 One-Time Password (OTP) 3951 6 Generic Token Card 3953 o Type_Data (Variable Length) varies with the Type of Request 3954 and the associated Response. For the documentation of the 3955 EAP methods, see [EAP]. 3957 Note that since IKE passes an indication of initiator identity in 3958 message 3 of the protocol, the responder SHOULD NOT send EAP Identity 3959 requests. The initiator SHOULD, however, respond to such requests if 3960 it receives them. 3962 4 Conformance Requirements 3964 In order to assure that all implementations of IKEv2 can 3965 interoperate, there are MUST support requirements in addition to 3966 those listed elsewhere. Of course, IKEv2 is a security protocol, and 3967 one of its major functions is to only allow authorized parties to 3968 successfully complete establishment of SAs. So a particular 3969 implementation may be configured with any of a number of restrictions 3970 concerning algorithms and trusted authorities that will prevent 3971 universal interoperability. 3973 IKEv2 is designed to permit minimal implementations that can 3974 interoperate with all compliant implementations. There are a series 3975 of optional features that can easily be ignored by a particular 3976 implementation if it does not support that feature. Those features 3977 include: 3979 Ability to negotiate SAs through a NAT and tunnel the resulting 3980 ESP SA over UDP. 3982 Ability to request (and respond to a request for) a temporary IP 3983 address on the remote end of a tunnel. 3985 Ability to support various types of legacy authentication. 3987 Ability to support window sizes greater than one. 3989 Ability to establish multiple ESP and/or AH SAs within a single 3990 IKE_SA. 3992 Ability to rekey SAs. 3994 To assure interoperability, all implementations MUST be capable of 3995 parsing all payload types (if only to skip over them) and to ignore 3996 payload types that it does not support unless the critical bit is set 3997 in the payload header. If the critical bit is set in an unsupported 3998 payload header, all implementations MUST reject the messages 3999 containing those payloads. 4001 Every implementation MUST be capable of doing four message 4002 IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, 4003 one for ESP and/or AH). Implementations MAY be initiate-only or 4004 respond-only if appropriate for their platform. Every implementation 4005 MUST be capable of responding to an INFORMATIONAL exchange, but a 4006 minimal implementation MAY respond to any INFORMATIONAL message with 4007 an empty INFORMATIONAL reply (note that within the context of an 4008 IKE_SA, an "empty" message consists of an IKE header followed by an 4009 Encrypted payload with no payloads contained in it). A minimal 4010 implementation MAY support the CREATE_CHILD_SA exchange only in so 4011 far as to recognize requests and reject them with a Notify payload of 4012 type NO_ADDITIONAL_SAS. A minimal implementation need not be able to 4013 initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA 4014 expires (based on locally configured values of either lifetime or 4015 octets passed), and implementation MAY either try to renew it with a 4016 CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and 4017 create a new one. If the responder rejects the CREATE_CHILD_SA 4018 request with a NO_ADDITIONAL_SAS notification, the implementation 4019 MUST be capable of instead closing the old SA and creating a new one. 4021 Implementations are not required to support requesting temporary IP 4022 addresses or responding to such requests. If an implementation does 4023 support issuing such requests, it MUST include a CP payload in 4024 message 3 containing at least a field of type INTERNAL_IP4_ADDRESS or 4025 INTERNAL_IP6_ADDRESS. All other fields are optional. If an 4026 implementation supports responding to such requests, it MUST parse 4027 the CP payload of type CFG_REQUEST in message 3 and recognize a field 4028 of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports 4029 leasing an address of the appropriate type, it MUST return a CP 4030 payload of type CFG_REPLY containing an address of the requested 4031 type. The responder SHOULD include all of the other related 4032 attributes if it has them. 4034 A minimal IPv4 responder implementation will ignore the contents of 4035 the CP payload except to determine that it includes an 4036 INTERNAL_IP4_ADDRESS attribute and will respond with the address and 4037 other related attributes regardless of whether the initiator 4038 requested them. 4040 A minimal IPv4 initiator will generate a CP payload containing only 4041 an INTERNAL_IP4_ADDRESS attribute and will parse the response 4042 ignoring attributes it does not know how to use. The only attribute 4043 it MUST be able to process is INTERNAL_ADDRESS_EXPIRY, which it must 4044 use to bound the lifetime of the SA unless it successfully renews the 4045 lease before it expires. Minimal initiators need not be able to 4046 request lease renewals and minimal responders need not respond to 4047 them. 4049 For an implementation to be called conforming to this specification, 4050 it MUST be possible to configure it to accept the following: 4052 PKIX Certificates containing and signed by RSA keys of size 1024 or 4053 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, 4054 ID_RFC822_ADDR, or ID_DER_ASN1_DN. 4056 Shared key authentication where the ID passes is any of ID_KEY_ID, 4057 ID_FQDN, or ID_RFC822_ADDR. 4059 Authentication where the responder is authenticated using PKIX 4060 Certificates and the initiator is authenticated using shared key 4061 authentication. 4063 5 Security Considerations 4065 While this protocol is designed to minimize disclosure of 4066 configuration information to unauthenticated peers, some such 4067 disclosure is unavoidable. One peer or the other must identify 4068 itself first and prove its identity first. To avoid probing, the 4069 initiator of an exchange is required to identify itself first, and 4070 usually is required to authenticate itself first. The initiator can, 4071 however, learn that the responder supports IKE and what cryptographic 4072 protocols it supports. The responder (or someone impersonating the 4073 responder) can probe the initiator not only for its identity, but 4074 using CERTREQ payloads may be able to determine what certificates the 4075 initiator is willing to use. 4077 Use of EAP authentication changes the probing possibilities somewhat. 4078 When EAP authentication is used, the responder proves its identity 4079 before the initiator does, so an initiator that knew the name of a 4080 valid initiator could probe the responder for both its name and 4081 certificates. 4083 Repeated rekeying using CREATE_CHILD_SA without additional Diffie- 4084 Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a 4085 single key or overrun of either endpoint. Implementers should take 4086 note of this fact and set a limit on CREATE_CHILD_SA exchanges 4087 between exponentiations. This memo does not prescribe such a limit. 4089 The strength of a key derived from a Diffie-Hellman exchange using 4090 any of the groups defined here depends on the inherent strength of 4091 the group, the size of the exponent used, and the entropy provided by 4092 the random number generator used. Due to these inputs it is difficult 4093 to determine the strength of a key for any of the defined groups. 4094 Diffie-Hellman group number two, when used with a strong random 4095 number generator and an exponent no less than 200 bits, is common for 4096 use with 3DES. Group five provides greater security than group two. 4097 Group one is for historic purposes only and does not provide 4098 sufficient strength except for use with DES, which is also for 4099 historic use only. Implementations should make note of these 4100 estimates when establishing policy and negotiating security 4101 parameters. 4103 Note that these limitations are on the Diffie-Hellman groups 4104 themselves. There is nothing in IKE which prohibits using stronger 4105 groups nor is there anything which will dilute the strength obtained 4106 from stronger groups (limited by the strength of the other algorithms 4107 negotiated including the prf function). In fact, the extensible 4108 framework of IKE encourages the definition of more groups; use of 4109 elliptical curve groups may greatly increase strength using much 4110 smaller numbers. 4112 It is assumed that all Diffie-Hellman exponents are erased from 4113 memory after use. In particular, these exponents MUST NOT be derived 4114 from long-lived secrets like the seed to a pseudo-random generator 4115 that is not erased after use. 4117 The strength of all keys are limited by the size of the output of the 4118 negotiated prf function. For this reason, a prf function whose output 4119 is less than 128 bits (e.g., 3DES-CBC) MUST NOT be used with this 4120 protocol. 4122 The security of this protocol is critically dependent on the 4123 randomness of the randomly chosen parameters. These should be 4124 generated by a strong random or properly seeded pseudo-random source 4125 (see [RFC1750]). Implementers should take care to ensure that use of 4126 random numbers for both keys and nonces is engineered in a fashion 4127 that does not undermine the security of the keys. 4129 For information on the rationale of many of the cryptographic design 4130 choices in this protocol, see [SIGMA]. Though the security of 4131 negotiated CHILD_SAs does not depend on the strength of the 4132 encryption and integrity protection negotiated in the IKE_SA, 4133 implementations MUST NOT negotiate NONE as the IKE integrity 4134 protection algorithm or ENCR_NULL as the IKE encryption algorithm. 4136 When using pre-shared keys, a critical consideration is how to assure 4137 the randomness of these secrets. The strongest practice is to ensure 4138 that any pre-shared key contain as much randomness as the strongest 4139 key being negotiated. Deriving a shared secret from a password, name, 4140 or other low entropy source is not secure. These sources are subject 4141 to dictionary and social engineering attacks, among others. 4143 The NAT_DETECTION_*_IP notifications contain a hash of the addresses 4144 and ports in an attempt to hide internal IP addresses behind a NAT. 4145 Since the IPv4 address space is only 32 bits, and it is usually very 4146 sparse, it would be possible for an attacker to find out the internal 4147 address used behind the NAT box by trying all possible IP-addresses 4148 and trying to find the matching hash. The port numbers are normally 4149 fixed to 500, and the SPIs can be extracted from the packet. This 4150 reduces the number of hash calculations to 2^32. With an educated 4151 guess of the use of private address space, the number of hash 4152 calculations is much smaller. Designers should therefore not assume 4153 that use of IKE will not leak internal address information. 4155 When using an EAP authentication method that does not generate a 4156 shared key for protecting a subsequent AUTH payload, certain man-in- 4157 the-middle and server impersonation attacks are possible [EAPMITM]. 4158 These vulnerabilities occur when EAP is also used in protocols which 4159 are not protected with a secure tunnel. Since EAP is a general- 4160 purpose authentication protocol, which is often used to provide 4161 single-signon facilities, a deployed IPsec solution which relies on 4162 an EAP authentication method that does not generate a shared key 4163 (also known as a non-key-generating EAP method) can become 4164 compromised due to the deployment of an entirely unrelated 4165 application that also happens to use the same non-key-generating EAP 4166 method, but in an unprotected fashion. Note that this vulnerability 4167 is not limited to just EAP, but can occur in other scenarios where an 4168 authentication infrastructure is reused. For example, if the EAP 4169 mechanism used by IKEv2 utilizes a token authenticator, a man-in-the- 4170 middle attacker could impersonate the web server, intercept the token 4171 authentication exchange, and use it to initiate an IKEv2 connection. 4172 For this reason, use of non-key-generating EAP methods SHOULD be 4173 avoided where possible. Where they are used, it is extremely 4174 important that all usages of these EAP methods SHOULD utilize a 4175 protected tunnel, where the initiator validates the responder's 4176 certificate before initiating the EAP exchange. Implementers SHOULD 4177 describe the vulnerabilities of using non-key-generating EAP methods 4178 in the documentation of their implementations so that the 4179 administrators deploying IPsec solutions are aware of these dangers. 4181 An implementation using EAP MUST also use a public key based 4182 authentication of the server to the client before the EAP exchange 4183 begins, even if the EAP method offers mutual authentication. This 4184 avoids having additional IKEv2 protocol variations and protects the 4185 EAP data from active attackers. 4187 If the messages of IKEv2 are long enough that IP level fragmentation 4188 is necessary, it is possible that attackers could prevent the 4189 exchange from completing by exhausting the reassembly buffers. The 4190 chances of this can be minimized by using the Hash and URL encodings 4191 instead of sending certificates (see section 3.6). Additional 4192 mitigations are discussed in [KPS03]. 4194 6 IANA Considerations 4196 This document defines a number of new field types and values where 4197 future assignments will be managed by the IANA. 4199 The following registries should be created: 4201 IKEv2 Exchange Types (section 3.1) 4202 IKEv2 Payload Types (section 3.2) 4203 IKEv2 Transform Types (section 3.3.2) 4204 IKEv2 Transform Attribute Types (section 3.3.2) 4205 IKEv2 Encryption Transform IDs (section 3.3.2) 4206 IKEv2 Pseudo-random Function Transform IDs (section 3.3.2) 4207 IKEv2 Integrity Algorithm Transform IDs (section 3.3.2) 4208 IKEv2 Diffie-Hellman Transform IDs (section 3.3.2) 4209 IKEv2 Identification Payload ID Types (section 3.5) 4210 IKEv2 Certificate Encodings (section 3.6) 4211 IKEv2 Authentication Method (section 3.8) 4212 IKEv2 Notify Message Types (section 3.10.1) 4213 IKEv2 Notification IPCOMP Transform IDs (section 3.10.1) 4214 IKEv2 Security Protocol Identifiers (section 3.3.1) 4215 IKEv2 Traffic Selector Types (section 3.13.1) 4216 IKEv2 Configuration Payload CFG Types (section 3.15) 4217 IKEv2 Configuration Payload Attribute Types (section 3.15.1) 4219 Note: when creating a new Transform Type, a new registry for it must 4220 be created. 4222 Changes and additions to any of those registries are by expert 4223 review. 4225 7 Acknowledgements 4227 This document is a collaborative effort of the entire IPsec WG. If 4228 there were no limit to the number of authors that could appear on an 4229 RFC, the following, in alphabetical order, would have been listed: 4230 Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt 4231 Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, John 4232 Ioannidis, Charlie Kaufman, Steve Kent, Angelos Keromytis, Tero 4233 Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer 4234 Reingold, and Michael Richardson. Many other people contributed to 4235 the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI, 4236 each of which has its own list of authors. Hugh Daniel suggested the 4237 feature of having the initiator, in message 3, specify a name for the 4238 responder, and gave the feature the cute name "You Tarzan, Me Jane". 4239 David Faucher and Valery Smyzlov helped refine the design of the 4240 traffic selector negotiation. 4242 8 References 4244 8.1 Normative References 4246 [ADDGROUP] Kivinen, T., and Kojo, M., "More Modular Exponential 4247 (MODP) Diffie-Hellman groups for Internet Key 4248 Exchange (IKE)", RFC 3526, May 2003. 4250 [ADDRIPV6] Hinden, R., and Deering, S., 4251 "Internet Protocol Version 6 (IPv6) Addressing 4252 Architecture", RFC 3513, April 2003. 4254 [Bra97] Bradner, S., "Key Words for use in RFCs to indicate 4255 Requirement Levels", BCP 14, RFC 2119, March 1997. 4257 [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and 4258 Levkowetz, H., "Extensible Authentication Protocol 4259 (EAP)", RFC 3748, June 2004. 4261 [ESPCBC] Pereira, R., Adams, R., "The ESP CBC-Mode Cipher 4262 Algorithms", RFC 2451, November 1998. 4264 [Hutt04] Huttunen, A. et. al., "UDP Encapsulation of IPsec 4265 Packets", draft-ietf-ipsec-udp-encaps-08.txt, February 4266 2004, work in progress. 4268 [RFC2401bis] Kent, S. and Atkinson, R., "Security Architecture 4269 for the Internet Protocol", 4270 draft-ietf-ipsec-rfc2401bis-02.txt, April 2004, work 4271 in progress. 4273 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing 4274 an IANA Considerations Section in RFCs", BCP 26, RFC 2434, 4275 October 1998. 4277 [RFC3168] Ramakrishnan, K., Floyd, S., and Black, D., 4278 "The Addition of Explicit Congestion Notification (ECN) 4279 to IP", RFC 3168, September 2001. 4281 [RFC3280] Housley, R., Polk, W., Ford, W., Solo, D., "Internet 4282 X.509 Public Key Infrastructure Certificate and 4283 Certificate Revocation List (CRL) Profile", RFC 3280, 4284 April 2002. 4286 [RFC3667] Bradner, S., "IETF Rights in Submissions", BCP 78, 4287 RFC 3667, February 2004. 4289 [RFC3668] Bradner, S., "Intellectual Property Rights in IETF 4290 Technology", BCP 79, RFC 3668, February 2004. 4292 8.2 Informative References 4294 [DES] ANSI X3.106, "American National Standard for Information 4295 Systems-Data Link Encryption", American National Standards 4296 Institute, 1983. 4298 [DH] Diffie, W., and Hellman M., "New Directions in 4299 Cryptography", IEEE Transactions on Information Theory, V. 4300 IT-22, n. 6, June 1977. 4302 [DHCP] R. Droms, "Dynamic Host Configuration Protocol", 4303 RFC2131 4305 [DSS] NIST, "Digital Signature Standard", FIPS 186, National 4306 Institute of Standards and Technology, U.S. Department of 4307 Commerce, May, 1994. 4309 [EAPMITM] Asokan, N., Nierni, V., and Nyberg, K., "Man-in-the-Middle 4310 in Tunneled Authentication Protocols", 4311 http://eprint.iacr.org/2002/163, November 2002. 4313 [HC98] Harkins, D., Carrel, D., "The Internet Key Exchange 4314 (IKE)", RFC 2409, November 1998. 4316 [IDEA] Lai, X., "On the Design and Security of Block Ciphers," 4317 ETH Series in Information Processing, v. 1, Konstanz: 4318 Hartung-Gorre Verlag, 1992 4320 [IPCOMP] Shacham, A., Monsour, R., Pereira, R., and Thomas, M., "IP 4321 Payload Compression Protocol (IPComp)", RFC 3173, 4322 September 2001. 4324 [KPS03] Kaufman, C., Perlman, R., and Sommerfeld, B., "DoS 4325 protection for UDP-based protocols", ACM Conference on 4326 Computer and Communications Security, October 2003. 4328 [KBC96] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 4329 Hashing for Message Authentication", RFC 2104, February 4330 1997. 4332 [LDAP] M. Wahl, T. Howes, S. Kille., "Lightweight Directory 4333 Access Protocol (v3)", RFC 2251 4335 [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, 4336 April 1992. 4338 [MSST98] Maughhan, D., Schertler, M., Schneider, M., and Turner, J. 4339 "Internet Security Association and Key Management Protocol 4340 (ISAKMP)", RFC 2408, November 1998. 4342 [Orm96] Orman, H., "The Oakley Key Determination Protocol", RFC 4343 2412, November 1998. 4345 [PFKEY] McDonald, D., Metz, C., and Phan, B., "PFKEY Key 4346 Management API, Version 2", RFC 2367, July 1998. 4348 [PKCS1] Kaliski, B., and J. Staddon, "PKCS #1: RSA Cryptography 4349 Specifications Version 2", September 1998. 4351 [PK01] Perlman, R., and Kaufman, C., "Analysis of the IPsec key 4352 exchange Standard", WET-ICE Security Conference, MIT,2001, 4353 http://sec.femto.org/wetice-2001/papers/radia-paper.pdf. 4355 [Pip98] Piper, D., "The Internet IP Security Domain Of 4356 Interpretation for ISAKMP", RFC 2407, November 1998. 4358 [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote 4359 Authentication Dial In User Service (RADIUS)", RFC 2138 4361 [RFC1750] Eastlake, D., Crocker, S., and Schiller, J., "Randomness 4362 Recommendations for Security", RFC 1750, December 1994. 4364 [RFC1958] Carpenter, B., "Architectural Principles of the 4365 Internet", RFC 1958, June 1996. 4367 [RFC2401] Kent, S., and Atkinson, R., "Security Architecture for 4368 the Internet Protocol", RFC 2401, November 1998. 4370 [RFC2402] Kent, S., and Atkinson, R., "IP Authentication Header", 4371 RFC 2402, November 1998. 4373 [RFC2406] Kent, S., and Atkinson, R., "IP Encapsulating Security 4374 Payload (ESP)", RFC 2406, November 1998. 4376 [RFC2474] Nichols, K., Blake, S., Baker, F. and Black, D., 4377 "Definition of the Differentiated Services Field (DS 4378 Field) in the IPv4 and IPv6 Headers", RFC 2474, 4379 December 1998. 4381 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. 4382 and Weiss, W., "An Architecture for Differentiated 4383 Services", RFC 2475, December 1998. 4385 [RFC2522] Karn, P., and Simpson, W., "Photuris: Session-Key 4386 Management Protocol", RFC 2522, March 1999. 4388 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 4389 February 2000. 4391 [RFC2983] Black, D., "Differentiated Services and Tunnels", 4392 RFC 2983, October 2000. 4394 [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural 4395 Guidelines and Philosophy", RFC 3429, December 2002. 4397 [RFC3715] Aboba, B and Dixon, W., "IPsec-Network Address 4398 Translation (NAT) Compatibility Requirements", 4399 RFC 3715, March 2004. 4401 [RSA] Rivest, R., Shamir, A., and Adleman, L., "A Method for 4402 Obtaining Digital Signatures and Public-Key 4403 Cryptosystems", Communications of the ACM, v. 21, n. 2, 4404 February 1978. 4406 [SHA] NIST, "Secure Hash Standard", FIPS 180-1, National 4407 Institute of Standards and Technology, U.S. Department 4408 of Commerce, May 1994. 4410 [SIGMA] Krawczyk, H., "SIGMA: the `SIGn-and-MAc' Approach to 4411 Authenticated Diffie-Hellman and its Use in the IKE 4412 Protocols", in Advances in Cryptography - CRYPTO 2003 4413 Proceedings, LNCS 2729, Springer, 2003. Available at: 4414 http://www.ee.technion.ac.il/~hugo/sigma.html 4416 [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange 4417 Mechanism for Internet", from IEEE Proceedings of the 4418 1996 Symposium on Network and Distributed Systems 4419 Security. 4421 [X.501] ITU-T Recommendation X.501: Information Technology - 4422 Open Systems Interconnection - The Directory: Models, 4423 1993. 4425 [X.509] ITU-T Recommendation X.509 (1997 E): Information 4426 Technology - Open Systems Interconnection - The 4427 Directory: Authentication Framework, June 1997. 4429 Appendix A: Summary of changes from IKEv1 4431 The goals of this revision to IKE are: 4433 1) To define the entire IKE protocol in a single document, replacing 4434 RFCs 2407, 2408, and 2409 and incorporating subsequent changes to 4435 support NAT Traversal, Extensible Authentication, and Remote Address 4436 acquisition. 4438 2) To simplify IKE by replacing the eight different initial exchanges 4439 with a single four message exchange (with changes in authentication 4440 mechanisms affecting only a single AUTH payload rather than 4441 restructuring the entire exchange); 4443 3) To remove the Domain of Interpretation (DOI), Situation (SIT), and 4444 Labeled Domain Identifier fields, and the Commit and Authentication 4445 only bits; 4447 4) To decrease IKE's latency in the common case by making the initial 4448 exchange be 2 round trips (4 messages), and allowing the ability to 4449 piggyback setup of a CHILD_SA on that exchange; 4451 5) To replace the cryptographic syntax for protecting the IKE 4452 messages themselves with one based closely on ESP to simplify 4453 implementation and security analysis; 4455 6) To reduce the number of possible error states by making the 4456 protocol reliable (all messages are acknowledged) and sequenced. This 4457 allows shortening CREATE_CHILD_SA exchanges from 3 messages to 2; 4459 7) To increase robustness by allowing the responder to not do 4460 significant processing until it receives a message proving that the 4461 initiator can receive messages at its claimed IP address, and not 4462 commit any state to an exchange until the initiator can be 4463 cryptographically authenticated; 4465 8) To fix cryptographic weaknesses such as the problem with 4466 symmetries in hashes used for authentication documented by Tero 4467 Kivinen. 4469 9) To specify Traffic Selectors in their own payloads type rather 4470 than overloading ID payloads, and making more flexible the Traffic 4471 Selectors that may be specified; 4473 10) To specify required behavior under certain error conditions or 4474 when data that is not understood is received in order to make it 4475 easier to make future revisions in a way that does not break 4476 backwards compatibility; 4478 11) To simplify and clarify how shared state is maintained in the 4479 presence of network failures and Denial of Service attacks; and 4481 12) To maintain existing syntax and magic numbers to the extent 4482 possible to make it likely that implementations of IKEv1 can be 4483 enhanced to support IKEv2 with minimum effort. 4485 Appendix B: Diffie-Hellman Groups 4487 There are two Diffie-Hellman groups defined here for use in IKE. 4488 These groups were generated by Richard Schroeppel at the University 4489 of Arizona. Properties of these primes are described in [Orm96]. 4491 The strength supplied by group one may not be sufficient for the 4492 mandatory-to-implement encryption algorithm and is here for historic 4493 reasons. 4495 Additional Diffie-Hellman groups have been defined in [ADDGROUP]. 4497 B.1 Group 1 - 768 Bit MODP 4499 This group is assigned id 1 (one). 4501 The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } 4502 Its hexadecimal value is: 4504 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 4505 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 4506 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 4507 A63A3620 FFFFFFFF FFFFFFFF 4509 The generator is 2. 4511 B.2 Group 2 - 1024 Bit MODP 4513 This group is assigned id 2 (two). 4515 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. 4516 Its hexadecimal value is: 4518 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 4519 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 4520 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 4521 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 4522 49286651 ECE65381 FFFFFFFF FFFFFFFF 4524 The generator is 2. 4526 Change History (To be removed from RFC) 4528 H.1 Changes from IKEv2-00 to IKEv2-01 February 2002 4530 1) Changed Appendix B to specify the encryption and authentication 4531 processing for IKE rather than referencing ESP. Simplified the format 4532 by removing idiosyncrasies not needed for IKE. 4534 2) Added option for authentication via a shared secret key. 4536 3) Specified different keys in the two directions of IKE messages. 4537 Removed requirement of different cookies in the two directions since 4538 now no longer required. 4540 4) Change the quantities signed by the two ends in AUTH fields to 4541 assure the two parties sign different quantities. 4543 5) Changed reference to AES to AES_128. 4545 6) Removed requirement that Diffie-Hellman be repeated when rekeying 4546 IKE_SA. 4548 7) Fixed typos. 4550 8) Clarified requirements around use of port 500 at the remote end in 4551 support of NAT. 4553 9) Clarified required ordering for payloads. 4555 10) Suggested mechanisms for avoiding DoS attacks. 4557 11) Removed claims in some places that the first phase 2 piggybacked 4558 on phase 1 was optional. 4560 H.2 Changes from IKEv2-01 to IKEv2-02 April 2002 4562 1) Moved the Initiator CERTREQ payload from message 1 to message 3. 4564 2) Added a second optional ID payload in message 3 for the Initiator 4565 to name a desired Responder to support the case where multiple named 4566 identities are served by a single IP address. 4568 3) Deleted the optimization whereby the Diffie-Hellman group did not 4569 need to be specified in phase 2 if it was the same as in phase 1 (it 4570 complicated the design with no meaningful benefit). 4572 4) Added a section on the implications of reusing Diffie-Hellman 4573 exponentials 4574 5) Changed the specification of sequence numbers to being at 0 in 4575 both directions. 4577 6) Many editorial changes and corrections, the most significant being 4578 a global replace of "byte" with "octet". 4580 H.3 Changes from IKEv2-02 to IKEv2-03 October 2002 4582 1) Reorganized the document moving introductory material to the 4583 front. 4585 2) Simplified the specification of Traffic Selectors to allow only 4586 IPv4 and IPv6 address ranges, as was done in the JFK spec. 4588 3) Fixed the problem brought up by David Faucher with the fix 4589 suggested by Valery Smyslov. If Bob needs to narrow the selector 4590 range, but has more than one matching narrower range, then if Alice's 4591 first selector is a single address pair, Bob chooses the range that 4592 encompasses that. 4594 4) To harmonize with the JFK spec, changed the exchange so that the 4595 initial exchange can be completed in four messages even if the 4596 responder must invoke an anti-clogging defense and the initiator 4597 incorrectly anticipates the responder's choice of Diffie-Hellman 4598 group. 4600 5) Replaced the hierarchical SA payload with a simplified version 4601 that only negotiates suites of cryptographic algorithms. 4603 H.4 Changes from IKEv2-03 to IKEv2-04 January 2003 4605 1) Integrated NAT traversal changes (including Appendix A). 4607 2) Moved the anti-clogging token (cookie) from the SPI to a NOTIFY 4608 payload; changed negotiation back to 6 messages when a cookie is 4609 needed. 4611 3) Made capitalization of IKE_SA and CHILD_SA consistent. 4613 4) Changed how IPComp was negotiated. 4615 5) Added usage scenarios. 4617 6) Added configuration payload for acquiring internal addresses on 4618 remote networks. 4620 7) Added negotiation of tunnel vs. transport mode. 4622 H.5 Changes from IKEv2-04 to IKEv2-05 February 2003 4624 1) Shortened Abstract 4626 2) Moved NAT Traversal from Appendix to section 2. Moved changes from 4627 IKEv2 to Appendix A. Renumbered sections. 4629 3) Made language more consistent. Removed most references to Phase 1 4630 and Phase 2. 4632 4) Made explicit the requirements for support of NAT Traversal. 4634 5) Added support for Extended Authentication Protocol methods. 4636 6) Added Response bit to message header. 4638 7) Made more explicit the encoding of Diffie-Hellman numbers in key 4639 expansion algorithms. 4641 8) Added ID payloads to AUTH payload computation. 4643 9) Expanded set of defined cryptographic suites. 4645 10) Added text for MUST/SHOULD support for ID payloads. 4647 11) Added new certificate formats and added MUST/SHOULD text. 4649 12) Clarified use of CERTREQ. 4651 13) Deleted "MUST SUPPORT" column in CP payload specification (it was 4652 inconsistent with surrounding text). 4654 14) Extended and clarified Conformance Requirements section, 4655 including specification of a minimal implementation. 4657 15) Added text to specify ECN handling. 4659 H.6 Changes from IKEv2-05 to IKEv2-06 March 2003 4661 1) Changed the suite based crypto negotiation back to ala carte. 4663 2) Eliminated some awkward page breaks, typographical errors, and 4664 other formatting issues. 4666 3) Tightened language describing cryptographic strength. 4668 4) Added references. 4670 5) Added more specific error codes. 4672 6) Added rationale for unintuitive key generation hash with shared 4673 secret based authentication. 4675 7) Changed the computation of the authenticating AUTH payload as 4676 proposed by Hugo Krawczyk. 4678 8) Changed the dashes (-) to underscores (_) in the names of fields 4679 and constants. 4681 H.7 Changes from IKEv2-06 to IKEv2-07 April 2003 4683 1) Added a list of payload types to section 3.2. 4685 2) Clarified use of SET_WINDOW_SIZE Notify payload. 4687 3) Removed references to COOKIE_REQUIRED Notify payload. 4689 4) Specified how to use a prf with a fixed key size. 4691 5) Removed g^ir from data processed by prf+. 4693 6) Strengthened cautions against using passwords as shared keys. 4695 7) Renamed Protocol_id field SECURITY_PROTOCOL_ID when it is not the 4696 Protocol ID from IP, and changed its values for consistency with 4697 IKEv1. 4699 8) Clarified use of ID payload in access control decisions. 4701 9) Gave IDr and TSr their own payload type numbers. 4703 10) Added Intellectual Property rights section. 4705 11) Clarified some issues in NAT Traversal. 4707 H.8 Changes from IKEv2-07 to IKEv2-08 May 2003 4709 1) Numerous editorial corrections and clarifications. 4711 2) Renamed Gateway to Security Gateway. 4713 3) Made explicit that the ability to rekey SAs without restarting IKE 4714 was optional. 4716 4) Removed last references to MUST and SHOULD cipher suites. 4718 5) Changed examples to "example.com". 4720 6) Changed references to status codes to status types. 4722 7) Simplified IANA Considerations section 4724 8) Updated References 4726 H.9 Changes from IKEv2-08 to IKEv2-09 August 2003 4728 1) Numerous editorial corrections and clarifications. 4730 2) Added REKEY_SA notify payload to the first message of a 4731 CREATE_CHILD_SA exchange if the new exchange was rekeying an existing 4732 SA. 4734 3) Renamed AES_ENCR128 to AES_ENCR and made it take a single 4735 parameter that is the key size (which may be 128, 192, or 256 bits). 4737 4) Clarified when a newly created SA is useable. 4739 5) Added additional text to section 2.23 specifying how to negotiate 4740 NAT Traversal. 4742 6) Replaced specification of ECN handling with a reference to 4743 [RFC2401bis]. 4745 7) Renumbered payloads so that numbers would not collide with IKEv1 4746 payload numbers in hopes of making code implementing both protocols 4747 simpler. 4749 8) Expanded the Transform ID field (also referred to as Diffie- 4750 Hellman group number) from one byte to two bytes. 4752 9) Removed ability to negotiate Diffie-Hellman groups by explicitly 4753 passing parameters. They must now be negotiated using Transform IDs. 4755 10) Renumbered status codes to be contiguous. 4757 11) Specified the meaning of the "Port" fields in Traffic Selectors 4758 when the ICMP protocol is being used. 4760 12) Removed the specification of D-H Group #5 since it is already 4761 specified in [ADDGROUP]. 4763 H.10 Changes from IKEv2-09 to IKEv2-10 August 2003 4765 1) Numerous boilerplate and formatting corrections to comply with RFC 4766 Editorial Guidelines and procedures. 4768 2) Fixed five typographical errors. 4770 3) Added a sentence to the end of "Security considerations" 4771 discouraging the use of non-key-generating EAP mechanisms. 4773 H.11 Changes from IKEv2-10 to IKEv2-11 October 2003 4775 1) Added SHOULD NOT language concerning use of non-key-generating EAP 4776 authentication methods and added reference [EAPMITM]. 4778 2) Clarified use of parallel SAs with identical traffic selectors for 4779 purposes of QoS handling. 4781 3) Fixed description of ECN handling to make normative references to 4782 [RFC2401bis] and [RFC3168]. 4784 4) Fixed two typos in the description of NAT traversal. 4786 5) Added specific ASN.1 encoding of certificate bundles in section 4787 3.6. 4789 H.12 Changes from IKEv2-11 to IKEv2-12 January 2004 4791 1) Made the values of the one byte IPsec Protocol ID consistent 4792 between payloads and made the naming more nearly consistent. 4794 2) Changed the specification to require that AUTH payloads be 4795 provided in EAP exchanges even when a non-key generating EAP method 4796 is used. This protects against certain obscure cryptographic 4797 threats. 4799 3) Changed all example IP addresses to be within subnet 10. 4801 4) Specified that issues surrounding weak keys and DES key parity 4802 must be addressed in algorithm documents. 4804 5) Removed the unsupported (and probably untrue) claim that Photuris 4805 cookies were given that name because the IETF always supports 4806 proposals involving cookies. 4808 6) Fixed some text that specified that Transform ID was 1 octet while 4809 everywhere else said it was 2 octets. 4811 7) Corrected the ASN.1 specification of the encoding of X.509 4812 certificate bundles. 4814 8) Added an INVALID_SELECTORS error type. 4816 9) Replaced IANA considerations section with a reference to draft- 4817 ietf-ipsec-ikev2-iana-00.txt. 4819 10) Removed 2 obsolete informative references and added one to a 4820 paper on UDP fragmentation problems. 4822 11) 41 Editorial Corrections and Clarifications. 4824 12) 6 Grammatical and Spelling errors fixed. 4826 13) 4 Corrected capitalizations of MAY/MUST/etc. 4828 14) 4 Attempts to make capitalization and use of underscores more 4829 consistent. 4831 H.13 Changes from IKEv2-12 to IKEv2-13 March 2004 4833 1) Updated copyright and intellectual property right sections per RFC 4834 3667. Added normative references to RFC 3667 and RFC 3668. 4836 2) Updated IANA Considerations section and adjusted some assignment 4837 tables to be consistent with the IANA registries document. Added 4838 Michael Richardson to the acknowledgements. 4840 3) Changed the cryptographic formula for computing the AUTH payload 4841 in the case where EAP authentication is used and the EAP algorithm 4842 does not produce a shared key. Clarified the case where it does 4843 produce a shared key. 4845 4) Extended the EAP authentication protocol by two messages so that 4846 the AUTH message is always sent after the success status is received. 4848 5) Updated reference to ESP encapsulation in UDP and made it 4849 normative. 4851 6) Added notification type ESP_TFC_PADDING_NOT_SUPPORTED. 4853 7) Clarified encoding of port number fields in transport selectors in 4854 the cases of ICMP and OPAQUE. 4856 8) Clarified that the length of the integrity checksum is fixed 4857 length and determined by the negotiated integrity algorithm. 4859 9) Added an informative reference to RFC 3715 (NAT Compatibility 4860 Requirements). 4862 10) Fixed 2 typos. 4864 H.14 Changes from IKEv2-13 to IKEv2-14 May 2004 4866 1) ISSUE #99: Clarified use of tunnel mode vs. transport mode. 4868 2) Changed the cryptographic formula for computing the AUTH payload 4869 in response to a suggestion from Hugo Krawczyk. 4871 3) Fixed a wording error in the explanation of why NAT traversal 4872 works as it does related to processing by legacy NAT gateways. 4874 4) Corrected the label AUTH_AES_XCBC_96 to AUTH_AES_PRF_128. 4876 5) Deleted suggestion that ID_KEY_ID field might be used to pass an 4877 account name. 4879 6) Listed the newly allocated OID for certificate bundle. 4881 7) Added NON_FIRST_FRAGMENTS_ALSO notification for negotiating the 4882 ability to send non-initial fragments of packets on the same SA as 4883 the initial fragments. 4885 8) ISSUE #97: Removed language concerning the relative strength of 4886 Diffie-Hellman groups. 4888 9) ISSUE #100: Reduced requirements concerning sending of 4889 certificates to allow implementations to by more coy about their 4890 identities and protect themselves from probing attacks. Listed in 4891 Security Considerations some issues an implementer might consider in 4892 deciding how to deal with such attacks. 4894 10) Made the punctuation of references to RFCs more consistent. 4896 11) Fixed fourteen typos. 4898 H.15 Changes from IKEv2-14 to IKEv2-15 August 2004 4900 1) ISSUE #111, 113: Made support for "Hash and URL" as a substitute 4901 for certificates mandatory, and added explanatory text about the 4902 dangers of depending on IP fragmentation for large messages. 4904 2) ISSUE #110: Made support for configuring shared keys by means of a 4905 HEX encoded byte string mandatory. 4907 3) Clarified use of special traffic selectors with a port range from 4908 65535 - 0. 4910 4) ISSUE #110: Added reference to RFC2401bis for definitions of 4911 terms. 4913 5) ISSUE #110, 114: Made required support of ID_IPV4_ADDR and 4914 ID_IPV6_ADDR depend on support of IPv4 vs. IPv6 as a transport. 4916 6) ISSUE #114: Removed INTERNAL_IP6_NETMASK and replaced it with text 4917 describing how an endpoint should request an IP address with 4918 specified low order bytes. 4920 7) ISSUE #101, 102, 104, 105, 106, and 107: Fold in information from 4921 draft-ietf-ipsec-ikev2-iana-00.txt to make that document unnecessary 4922 for initial IANA settings. Deleted it from references. 4924 8) ISSUE #110: Removed reference to ENCR_RC4. 4926 9) ISSUE #112: Removed reference to draft-keromytis-ike-id-00.txt, 4927 which will not be published as an RFC. 4929 10) ISSUE #112: Removed text incorrectly implying that AH could be 4930 tunneled over port 4500. 4932 11) ISSUE #112: Removed reference to draft-ietf-ipsec-nat- 4933 reqts-04.txt. 4935 12) ISSUE #112: Removed reference to draft-ipsec-ike-hash- 4936 revised-02.txt, and substituted a short explanation of the problem 4937 addressed. 4939 13) ISSUE #112: Changed the label of PRF_AES_CBC to PRF_AES128_CBC 4941 14) ISSUE #110: Clarified distinction between Informational messages 4942 and Informational exchanges. 4944 15) ISSUE #110: Clarified distinction between SA payloads and SAs. 4946 16) ISSUE #109: Clarified that cryptographic algorithms that MUST be 4947 supported can still be configured as off. 4949 17) ISSUE #110: Changed example IP addresses from 10.*.*.* to 4950 192.0.*.*. 4952 18) ISSUE #108: Rephrased to avoid use of the undefined acronyms PFS 4953 and NAT-T. 4955 19) ISSUE #113: Added requirement that backoff timers on 4956 retransmissions must increase exponentially to avoid network 4957 congestion. 4959 20) Replaced dubious explanation of NON_FIRST_FRAGMENTS_ALSO with a 4960 reference to RFC2401bis. 4962 21) Fixed 16 spelling/typographical/gramatical errors. 4964 H.16 Changes from IKEv2-15 to IKEv2-16 September 2004 4966 1) Added the text: "All IKEv2 implementations MUST be able to send, 4967 receive, and process IKE messages that are up to 1280 bytes long, and 4968 they SHOULD be able to send, receive, and process messages that are 4969 up to 3000 bytes long." 4971 2) Removed the two ECC groups from Appendix B. 4973 3) Changed references to RFC 2284 to RFC 3748, references to Extended 4974 Authentication Protocol to Extensible Authentication Protocol, and 4975 made some editorial corrections related to EAP proposed by Jari 4976 Arkko. 4978 4) Added a note to security considerations saying that IKE MUST NOT 4979 negotiate NONE as its integrity protection algorithm or ENCR_NULL as 4980 its encryption algorithm. 4982 5) Added I-D boilerplate concerning IPR claim disclosure. 4984 6) Clarified that "empty" messages included a single empty Encrypted 4985 payload. 4987 7) Added (SA) after first reference to "Security Association". 4989 8) Noted that incompatible configurations of traffic selectors SHOULD 4990 be noted in error logs. 4992 9) 3 minor editorial clarifications. 4994 H.17 Changes from IKEv2-16 to IKEv2-17 September 2004 4996 1) Removed all references to Alice and Bob, replacing them with "the 4997 initiator" and "the responder". Also fixed the corresponding he/she, 4998 his/her, and the capitalization of initiator and responder. 5000 2) Changed specification of BER encoded fields to be DER encoded 5001 fields. 5003 3) Removed obsolete reference to CA names appearing in CERTREQ 5004 fields. 5006 4) Fixed the specification of INTERNAL_IPx_SUBNET Configuration 5007 Attributes to indicate that they could be multi-valued. 5009 5) Added informative references to RFC 2402 and RFC 2406. 5011 6) Fixed a formatting glitch in the computation of AUTH. 5013 Editor's Address 5015 Charlie Kaufman 5016 Microsoft Corporation 5017 1 Microsoft Way 5018 Redmond, WA 98052 5019 1-425-707-3335 5021 charliek@microsoft.com 5023 By submitting this Internet-Draft, the editor represents that any 5024 applicable patent or other IPR claims of which he is aware have been 5025 or will be disclosed, and any of which he becomes aware will be 5026 disclosed, in accordance with RFC 3668. 5028 Full Copyright Statement 5030 Copyright (C) The Internet Society (2004). This document is subject 5031 to the rights, licenses and restrictions contained in BCP 78 and 5032 except as set forth therein, the authors retain all their rights. 5034 This document and the information contained herein are provided on an 5035 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 5036 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 5037 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 5038 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 5039 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 5040 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 5042 Intellectual Property Statement 5044 The IETF takes no position regarding the validity or scope of any 5045 Intellectual Property Rights or other rights that might be claimed to 5046 pertain to the implementation or use of the technology described in 5047 this document or the extent to which any license under such rights 5048 might or might not be available; nor does it represent that it has 5049 made any independent effort to identify any such rights. Information 5050 on the procedures with respect to rights in RFC documents can be 5051 found in BCP 78 and BCP 79. 5053 Copies of IPR disclosures made to the IETF Secretariat and any 5054 assurances of licenses to be made available, or the result of an 5055 attempt made to obtain a general license or permission for the use of 5056 such proprietary rights by implementers or users of this 5057 specification can be obtained from the IETF on-line IPR repository at 5058 http://www.ietf.org/ipr. 5060 The IETF invites any interested party to bring to its attention any 5061 copyrights, patents or patent applications, or other proprietary 5062 rights that may cover technology that may be required to implement 5063 this standard. Please address the information to the IETF at ietf- 5064 ipr@ietf.org. 5066 Acknowledgement 5068 Funding for the RFC Editor function is currently provided by the 5069 Internet Society. 5071 Expiration 5073 This Internet-Draft (draft-ietf-ipsec-ikev2-17.txt) expires in March 5074 2005.