idnits 2.17.1 draft-ietf-ipsec-ikev2-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 101 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 102 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 5 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- 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 == Line 4379 has weird spacing: '... The equati...' == 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). -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == 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 (January 6, 2004) is 7409 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: 'RFC2406' is mentioned on line 146, but not defined ** Obsolete undefined reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) == Missing Reference: 'RFC2402' is mentioned on line 146, but not defined ** Obsolete undefined reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) == Missing Reference: 'CERTREQ' is mentioned on line 1405, but not defined == Missing Reference: 'N' is mentioned on line 426, but not defined == Missing Reference: 'KEi' is mentioned on line 426, but not defined == Missing Reference: 'KEr' is mentioned on line 447, but not defined == Missing Reference: 'CP' is mentioned on line 524, but not defined == Missing Reference: 'RFC 2522' is mentioned on line 798, but not defined == Missing Reference: 'RFC 2983' is mentioned on line 1010, but not defined == Missing Reference: 'RFC 2401' is mentioned on line 1814, but not defined ** Obsolete undefined reference: RFC 2401 (Obsoleted by RFC 4301) -- Looks like a reference, but probably isn't: '0' on line 2737 -- Looks like a reference, but probably isn't: '1' on line 2738 == Missing Reference: 'IKEv2IANA' is mentioned on line 4037, but not defined == Missing Reference: 'RFC 3168' is mentioned on line 4649, but not defined == Unused Reference: 'ESPCBC' is defined on line 4101, but no explicit reference was found in the text == Unused Reference: 'RFC3280' is defined on line 4112, but no explicit reference was found in the text == Unused Reference: 'DES' is defined on line 4119, but no explicit reference was found in the text == Unused Reference: 'DH' is defined on line 4123, but no explicit reference was found in the text == Unused Reference: 'DSS' is defined on line 4130, but no explicit reference was found in the text == Unused Reference: 'HC98' is defined on line 4138, but no explicit reference was found in the text == Unused Reference: 'IDEA' is defined on line 4145, but no explicit reference was found in the text == Unused Reference: 'Ker01' is defined on line 4160, but no explicit reference was found in the text == Unused Reference: 'KBC96' is defined on line 4163, but no explicit reference was found in the text == Unused Reference: 'MD5' is defined on line 4170, but no explicit reference was found in the text == Unused Reference: 'MSST98' is defined on line 4173, but no explicit reference was found in the text == Unused Reference: 'PKCS1' is defined on line 4183, but no explicit reference was found in the text == Unused Reference: 'PK01' is defined on line 4186, but no explicit reference was found in the text == Unused Reference: 'Pip98' is defined on line 4190, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 4199, but no explicit reference was found in the text == Unused Reference: 'RFC2474' is defined on line 4202, but no explicit reference was found in the text == Unused Reference: 'RFC2475' is defined on line 4207, but no explicit reference was found in the text == Unused Reference: 'RFC2522' is defined on line 4211, but no explicit reference was found in the text == Unused Reference: 'RFC2983' is defined on line 4214, but no explicit reference was found in the text == Unused Reference: 'RSA' is defined on line 4217, but no explicit reference was found in the text == Unused Reference: 'SHA' is defined on line 4222, but no explicit reference was found in the text == Unused Reference: 'SKEME' is defined on line 4232, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3513 (ref. 'ADDRIPV6') (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 2284 (ref. 'EAP') (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. 'HC98') (Obsoleted by RFC 4306) == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-udp-encaps-05 -- 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) -- Duplicate reference: RFC2401, mentioned in 'RFC2401', was also mentioned in 'RFC2401bis'. -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) Summary: 9 errors (**), 0 flaws (~~), 45 warnings (==), 17 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-12.txt 4 Obsoletes: 2407, 2408, 2409 January 6, 2004 5 Expires: July 2004 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 July 2004. 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 45 associations. 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 Exchange.....................................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............................12 66 2.2 Use of Sequence Numbers for Message ID..................13 67 2.3 Window Size for overlapping requests....................13 68 2.4 State Synchronization and Connection Timeouts...........14 69 2.5 Version Numbers and Forward Compatibility...............16 70 2.6 Cookies.................................................17 71 2.7 Cryptographic Algorithm Negotiation.....................19 72 2.8 Rekeying................................................20 73 2.9 Traffic Selector Negotiation............................22 74 2.10 Nonces.................................................24 75 2.11 Address and Port Agility...............................25 76 2.12 Reuse of Diffie-Hellman Exponentials...................25 77 2.13 Generating Keying Material.............................26 78 2.14 Generating Keying Material for the IKE_SA..............27 79 2.15 Authentication of the IKE_SA...........................28 80 2.16 Extended Authentication Protocol Methods...............29 81 2.17 Generating Keying Material for CHILD_SAs...............31 82 2.18 Rekeying IKE_SAs using a CREATE_CHILD_SA exchange......32 83 2.19 Requesting an internal address on a remote network.....32 84 2.20 Requesting a Peer's Version............................33 85 2.21 Error Handling.........................................34 86 2.22 IPComp.................................................35 87 2.23 NAT Traversal..........................................36 88 2.24 ECN (Explicit Congestion Notification).................38 89 3 Header and Payload Formats................................39 90 3.1 The IKE Header..........................................39 91 3.2 Generic Payload Header..................................42 92 3.3 Security Association Payload............................43 93 3.4 Key Exchange Payload....................................53 94 3.5 Identification Payloads.................................54 95 3.6 Certificate Payload.....................................56 96 3.7 Certificate Request Payload.............................58 97 3.8 Authentication Payload..................................60 98 3.9 Nonce Payload...........................................61 99 3.10 Notify Payload.........................................61 100 3.11 Delete Payload.........................................68 101 3.12 Vendor ID Payload......................................70 102 3.13 Traffic Selector Payload...............................71 103 3.14 Encrypted Payload......................................73 104 3.15 Configuration Payload..................................75 105 3.16 Extended Authentication Protocol (EAP) Payload.........80 106 4 Conformance Requirements..................................82 107 5 Security Considerations...................................84 108 6 IANA Considerations.......................................86 109 7 Intellectual property rights..............................86 110 8 Acknowledgements..........................................86 111 9 References................................................87 112 9.1 Normative References....................................87 113 9.2 Informative References..................................88 114 Appendix A: Summary of Changes from IKEv1...................91 115 Appendix B: Diffie-Hellman Groups...........................93 116 Change History (To be removed from RFC).....................95 117 Editor's Address...........................................102 118 Full Copyright Statement...................................102 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 1 Introduction 128 IP Security (IPsec) provides confidentiality, data integrity, access 129 control, and data source authentication to IP datagrams. These 130 services are provided by maintaining shared state between the source 131 and the sink of an IP datagram. This state defines, among other 132 things, the specific services provided to the datagram, which 133 cryptographic algorithms will be used to provide the services, and 134 the keys used as input to the cryptographic algorithms. 136 Establishing this shared state in a manual fashion does not scale 137 well. Therefore a protocol to establish this state dynamically is 138 needed. This memo describes such a protocol-- the Internet Key 139 Exchange (IKE). This is version 2 of IKE. Version 1 of IKE was 140 defined in RFCs 2407, 2408, and 2409. This single document is 141 intended to replace all three of those RFCs. 143 IKE performs mutual authentication between two parties and 144 establishes an IKE security association that includes shared secret 145 information that can be used to efficiently establish SAs for ESP 146 [RFC2406] and/or AH [RFC2402] and a set of cryptographic algorithms 147 to be used by the SAs to protect the traffic that they carry. In 148 this document, the term "suite" or "cryptographic suite" refers to a 149 complete set of algorithms used to protect an SA. An initiator 150 proposes one or more suites by listing supported algorithms that can 151 be combined into suites in a mix and match fashion. IKE can also 152 negotiate use of IPComp [IPCOMP] in connection with an ESP and/or AH 153 SA. We call the IKE SA an "IKE_SA". The SAs for ESP and/or AH that 154 get set up through that IKE_SA we call "CHILD_SA"s. 156 All IKE communications consist of pairs of messages: a request and a 157 response. The pair is called an "exchange". We call the first 158 messages establishing an IKE_SA IKE_SA_INIT and IKE_AUTH exchanges 159 and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL 160 exchanges. In the common case, there is a single IKE_SA_INIT exchange 161 and a single IKE_AUTH exchange (a total of four messages) to 162 establish the IKE_SA and the first CHILD_SA. In exceptional cases, 163 there may be more than one of each of these exchanges. In all cases, 164 all IKE_SA_INIT exchanges MUST complete before any other exchange 165 type, then all IKE_AUTH exchanges MUST complete, and following that 166 any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur 167 in any order. In some scenarios, only a single CHILD_SA is needed 168 between the IPsec endpoints and therefore there would be no 169 additional exchanges. Subsequent exchanges MAY be used to establish 170 additional CHILD_SAs between the same authenticated pair of endpoints 171 and to perform housekeeping functions. 173 IKE message flow always consists of a request followed by a response. 174 It is the responsibility of the requester to ensure reliability. If 175 the response is not received within a timeout interval, the requester 176 needs to retransmit the request (or abandon the connection). 178 The first request/response of an IKE session negotiates security 179 parameters for the IKE_SA, sends nonces, and sends Diffie-Hellman 180 values. We call the initial exchange IKE_SA_INIT (request and 181 response). 183 The second request/response, which we'll call IKE_AUTH transmits 184 identities, proves knowledge of the secrets corresponding to the two 185 identities, and sets up an SA for the first (and often only) AH 186 and/or ESP CHILD_SA. 188 The types of subsequent exchanges are CREATE_CHILD_SA (which creates 189 a CHILD_SA), and INFORMATIONAL (which deletes an SA, reports error 190 conditions, or does other housekeeping). Every request requires a 191 response. An INFORMATIONAL request with no payloads is commonly used 192 as a check for liveness. These subsequent exchanges cannot be used 193 until the initial exchanges have completed. 195 In the description that follows, we assume that no errors occur. 196 Modifications to the flow should errors occur are described in 197 section 2.21. 199 1.1 Usage Scenarios 201 IKE is expected to be used to negotiate ESP and/or AH SAs in a number 202 of different scenarios, each with its own special requirements. 204 1.1.1 Security Gateway to Security Gateway Tunnel 206 +-+-+-+-+-+ +-+-+-+-+-+ 207 ! ! IPsec ! ! 208 Protected !Tunnel ! Tunnel !Tunnel ! Protected 209 Subnet <-->!Endpoint !<---------->!Endpoint !<--> Subnet 210 ! ! ! ! 211 +-+-+-+-+-+ +-+-+-+-+-+ 213 Figure 1: Security Gateway to Security Gateway Tunnel 215 In this scenario, neither endpoint of the IP connection implements 216 IPsec, but network nodes between them protect traffic for part of the 217 way. Protection is transparent to the endpoints, and depends on 218 ordinary routing to send packets through the tunnel endpoints for 219 processing. Each endpoint would announce the set of addresses 220 "behind" it, and packets would be sent in Tunnel Mode where the inner 221 IP header would contain the IP addresses of the actual endpoints. 223 1.1.2 Endpoint to Endpoint Transport 225 +-+-+-+-+-+ +-+-+-+-+-+ 226 ! ! IPsec ! ! 227 !Protected! Tunnel !Protected! 228 !Endpoint !<---------------------------------------->!Endpoint ! 229 ! ! ! ! 230 +-+-+-+-+-+ +-+-+-+-+-+ 232 Figure 2: Endpoint to Endpoint 234 In this scenario, both endpoints of the IP connection implement 235 IPsec. These endpoints may implement application layer access 236 controls based on the authenticated identities of the participants. 237 Transport mode will commonly be used with no inner IP header. If 238 there is an inner IP header, the inner addresses will be the same as 239 the outer addresses. A single pair of addresses will be negotiated 240 for packets to be protected by this SA. 242 It is possible in this scenario that one or both of the protected 243 endpoints will be behind a network address translation (NAT) node, in 244 which case the tunnelled packets will have to be UDP encapsulated so 245 that port numbers in the UDP headers can be used to identify 246 individual endpoints "behind" the NAT (see section 2.23). 248 1.1.3 Endpoint to Security Gateway Transport 250 +-+-+-+-+-+ +-+-+-+-+-+ 251 ! ! IPsec ! ! Protected 252 !Protected! Tunnel !Tunnel ! Subnet 253 !Endpoint !<------------------------>!Endpoint !<--- and/or 254 ! ! ! ! Internet 255 +-+-+-+-+-+ +-+-+-+-+-+ 257 Figure 3: Endpoint to Security Gateway Tunnel 259 In this scenario, a protected endpoint (typically a portable roaming 260 computer) connects back to its corporate network through an IPsec 261 protected tunnel. It might use this tunnel only to access information 262 on the corporate network or it might tunnel all of its traffic back 263 through the corporate network in order to take advantage of 264 protection provided by a corporate firewall against Internet based 265 attacks. In either case, the protected endpoint will want an IP 266 address associated with the security gateway so that packets returned 267 to it will go to the security gateway and be tunnelled back. This IP 268 address may be static or may be dynamically allocated by the security 269 gateway. In support of the latter case, IKEv2 includes a mechanism 270 for the initiator to request an IP address owned by the security 271 gateway for use for the duration of its SA. 273 In this scenario, packets will use tunnel mode. On each packet from 274 the protected endpoint, the outer IP header will contain the source 275 IP address associated with its current location (i.e., the address 276 that will get traffic routed to the endpoint directly) while the 277 inner IP header will contain the source IP address assigned by the 278 security gateway (i.e., the address that will get traffic routed to 279 the security gateway for forwarding to the endpoint). The outer 280 destination address will always be that of the security gateway, 281 while the inner destination address will be the ultimate destination 282 for the packet. 284 In this scenario, it is possible that the protected endpoint will be 285 behind a NAT. In that case, the IP address as seen by the security 286 gateway will not be the same as the IP address sent by the protected 287 endpoint, and packets will have to be UDP encapsulated in order to be 288 routed properly. 290 1.1.4 Other Scenarios 292 Other scenarios are possible, as are nested combinations of the 293 above. One notable example combines aspects of 1.1.1 and 1.1.3. A 294 subnet may make all external accesses through a remote security 295 gateway using an IPsec tunnel, where the addresses on the subnet are 296 routed to the security gateway by the rest of the Internet. An 297 example would be someone's home network being virtually on the 298 Internet with static IP addresses even though connectivity is 299 provided by an ISP that assigns a single dynamically assigned IP 300 address to the user's security gateway (where the static IP addresses 301 and an IPsec relay is provided by a third party located elsewhere). 303 1.2 The Initial Exchanges 305 Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH 306 exchanges (known in IKEv1 as Phase 1). These initial exchanges 307 normally consist of four messages, though in some scenarios that 308 number can grow. All communications using IKE consist of 309 request/response pairs. We'll describe the base exchange first, 310 followed by variations. The first pair of messages (IKE_SA_INIT) 311 negotiate cryptographic algorithms, exchange nonces, and do a Diffie- 312 Hellman exchange. 314 The second pair of messages (IKE_AUTH) authenticate the previous 315 messages, exchange identities and certificates, and establish the 316 first CHILD_SA. Parts of these messages are encrypted and integrity 317 protected with keys established through the IKE_SA_INIT exchange, so 318 the identities are hidden from eavesdroppers and all fields in all 319 the messages are authenticated. 321 In the following description, the payloads contained in the message 322 are indicated by names such as SA. The details of the contents of 323 each payload are described later. Payloads which may optionally 324 appear will be shown in brackets, such as [CERTREQ], would indicate 325 that optionally a certificate request payload can be included. 327 To simplify the descriptions that follow by allowing the use of 328 gender specific personal pronouns, the initiator is assumed to be 329 named "Alice" and the responder "Bob". 331 The initial exchanges are as follows: 333 Initiator Responder 334 ----------- ----------- 335 HDR, SAi1, KEi, Ni --> 337 HDR contains the SPIs, version numbers, and flags of various sorts. 338 The SAi1 payload states the cryptographic algorithms the Initiator 339 supports for the IKE_SA. The KE payload sends the Initiator's 340 Diffie-Hellman value. Ni is the Initiator's nonce. 342 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 344 The Responder chooses a cryptographic suite from the Initiator's 345 offered choices and expresses that choice in the SAr1 payload, 346 completes the Diffie-Hellman exchange with the KEr payload, and sends 347 its nonce in the Nr payload. 349 At this point in the negotiation each party can generate SKEYSEED, 350 from which all keys are derived for that IKE_SA. All but the headers 351 of all the messages that follow are encrypted and integrity 352 protected. The keys used for the encryption and integrity protection 353 are derived from SKEYSEED and are known as SK_e (encryption) and SK_a 354 (authentication, a.k.a. integrity protection). A separate SK_e and 355 SK_a is computed for each direction. In addition to the keys SK_e 356 and SK_a derived from the DH value for protection of the IKE_SA, 357 another quantity SK_d is derived and used for derivation of further 358 keying material for CHILD_SAs. The notation SK { ... } indicates 359 that these payloads are encrypted and integrity protected using that 360 direction's SK_e and SK_a. 362 HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] 363 AUTH, SAi2, TSi, TSr} --> 365 The Initiator asserts her identity with the IDi payload, proves 366 knowledge of the secret corresponding to IDi and integrity protects 367 the contents of the first message using the AUTH payload (see section 368 2.15). She might also send her certificate(s) in CERT payload(s) and 369 a list of her trust anchors in CERTREQ payload(s). If any CERT 370 payloads are included, the first certificate provided MUST contain 371 the public key used to verify the AUTH field. The optional payload 372 IDr enables Alice to specify which of Bob's identities she wants to 373 talk to. This is useful when Bob is hosting multiple identities at 374 the same IP address. She begins negotiation of a CHILD_SA using the 375 SAi2 payload. The final fields (starting with SAi2) are described in 376 the description of the CREATE_CHILD_SA exchange. 378 <-- HDR, SK {IDr, [CERT,] AUTH, 379 SAr2, TSi, TSr} 381 The Responder asserts his identity with the IDr payload, optionally 382 sends one or more certificates (again with the certificate containing 383 the public key used to verify AUTH listed first), authenticates his 384 identity and protects the integrity of the second message with the 385 AUTH payload, and completes negotiation of a CHILD_SA with the 386 additional fields described below in the CREATE_CHILD_SA exchange. 388 The recipients of messages 3 and 4 MUST verify that all signatures 389 and MACs are computed correctly and that the names in the ID payloads 390 correspond to the keys used to generate the AUTH payload. 392 1.3 The CREATE_CHILD_SA Exchange 394 This exchange consists of a single request/response pair, and was 395 referred to as a phase 2 exchange in IKEv1. It MAY be initiated by 396 either end of the IKE_SA after the initial exchanges are completed. 398 All messages following the initial exchange are cryptographically 399 protected using the cryptographic algorithms and keys negotiated in 400 the first two messages of the IKE exchange. These subsequent 401 messages use the syntax of the Encrypted Payload described in section 402 3.14. 404 Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this 405 section the term initiator refers to the endpoint initiating this 406 exchange. The term "Alice" will always refer to the initiator of the 407 outer IKE_SA. 409 A CHILD_SA is created by sending a CREATE_CHILD_SA request. The 410 CREATE_CHILD_SA request MAY optionally contain a KE payload for an 411 additional Diffie-Hellman exchange to enable stronger guarantees of 412 forward secrecy for the CHILD_SA. The keying material for the 413 CHILD_SA is a function of SK_d established during the establishment 414 of the IKE_SA, the nonces exchanged during the CREATE_CHILD_SA 415 exchange, and the Diffie-Hellman value (if KE payloads are included 416 in the CREATE_CHILD_SA exchange). 418 In the CHILD_SA created as part of the initial exchange, a second KE 419 payload and nonce MUST NOT be sent. The nonces from the initial 420 exchange are used in computing the keys for the CHILD_SA. 422 The CREATE_CHILD_SA request contains: 424 Initiator Responder 425 ----------- ----------- 426 HDR, SK {[N], SA, Ni, [KEi], 427 [TSi, TSr]} --> 429 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni 430 payload, optionally a Diffie-Hellman value in the KEi payload, and 431 the proposed traffic selectors in the TSi and TSr payloads. If this 432 CREATE_CHILD_SA exchange is rekeying an existing SA other than the 433 IKE_SA, the leading N payload of type REKEY_SA MUST identify the SA 434 being rekeyed. If this CREATE_CHILD_SA exchange is not rekeying and 435 existing SA, the N payload MUST be omitted. If the SA offers include 436 different Diffie-Hellman groups, KEi MUST be an element of the group 437 the initiator expects the responder to accept. If it guesses wrong, 438 the CREATE_CHILD_SA exchange will fail and it will have to retry with 439 a different KEi. 441 The message following the header is encrypted and the message 442 including the header is integrity protected using the cryptographic 443 algorithms negotiated for the IKE_SA. 445 The CREATE_CHILD_SA response contains: 447 <-- HDR, SK {SA, Nr, [KEr], 448 [TSi, TSr]} 450 The responder replies (using the same Message ID to respond) with the 451 accepted offer in an SA payload, and a Diffie-Hellman value in the 452 KEr payload if KEi was included in the request and the selected 453 cryptographic suite includes that group. If the responder chooses a 454 cryptographic suite with a different group, it MUST reject the 455 request. The initiator SHOULD repeat the request, but now with a KEi 456 payload from the group the responder selected. 458 The traffic selectors for traffic to be sent on that SA are specified 459 in the TS payloads, which may be a subset of what the initiator of 460 the CHILD_SA proposed. Traffic selectors are omitted if this 461 CREATE_CHILD_SA request is being used to change the key of the 462 IKE_SA. 464 1.4 The INFORMATIONAL Exchange 466 At various points during the operation of an IKE_SA, peers may desire 467 to convey control messages to each other regarding errors or 468 notifications of certain events. To accomplish this IKE defines an 469 INFORMATIONAL exchange. INFORMATIONAL exchanges MAY ONLY occur after 470 the initial exchanges and are cryptographically protected with the 471 negotiated keys. 473 Control messages that pertain to an IKE_SA MUST be sent under that 474 IKE_SA. Control messages that pertain to CHILD_SAs MUST be sent under 475 the protection of the IKE_SA which generated them (or its successor 476 if the IKE_SA was replaced for the purpose of rekeying). 478 Messages in an INFORMATIONAL Exchange contain zero or more 479 Notification, Delete, and Configuration payloads. The Recipient of an 480 INFORMATIONAL Exchange request MUST send some response (else the 481 Sender will assume the message was lost in the network and will 482 retransmit it). That response MAY be a message with no payloads. The 483 request message in an INFORMATIONAL Exchange MAY also contain no 484 payloads. This is the expected way an endpoint can ask the other 485 endpoint to verify that it is alive. 487 ESP and AH SAs always exist in pairs, with one SA in each direction. 488 When an SA is closed, both members of the pair MUST be closed. When 489 SAs are nested, as when data (and IP headers if in tunnel mode) are 490 encapsulated first with IPComp, then with ESP, and finally with AH 491 between the same pair of endpoints, all of the SAs MUST be deleted 492 together. Each endpoint MUST close its incoming SAs and allow the 493 other endpoint to close the other SA in each pair. To delete an SA, 494 an INFORMATIONAL Exchange with one or more delete payloads is sent 495 listing the SPIs (as they would be expected in the headers of inbound 496 packets) of the SAs to be deleted. The recipient MUST close the 497 designated SAs. Normally, the reply in the INFORMATIONAL Exchange 498 will contain delete payloads for the paired SAs going in the other 499 direction. There is one exception. If by chance both ends of a set 500 of SAs independently decide to close them, each may send a delete 501 payload and the two requests may cross in the network. If a node 502 receives a delete request for SAs for which it has already issued a 503 delete request, it MUST delete the outgoing SAs while processing the 504 request and the incoming SAs while processing the response. In that 505 case, the responses MUST NOT include delete payloads for the deleted 506 SAs, since that would result in duplicate deletion and could in 507 theory delete the wrong SA. 509 A node SHOULD regard half closed connections as anomalous and audit 510 their existence should they persist. Note that this specification 511 nowhere specifies time periods, so it is up to individual endpoints 512 to decide how long to wait. A node MAY refuse to accept incoming data 513 on half closed connections but MUST NOT unilaterally close them and 514 reuse the SPIs. If connection state becomes sufficiently messed up, a 515 node MAY close the IKE_SA which will implicitly close all SAs 516 negotiated under it. It can then rebuild the SAs it needs on a clean 517 base under a new IKE_SA. 519 The INFORMATIONAL Exchange is defined as: 521 Initiator Responder 522 ----------- ----------- 523 HDR, SK {[N,] [D,] [CP,] ...} --> 524 <-- HDR, SK {[N,] [D,] [CP], ...} 526 The processing of an INFORMATIONAL Exchange is determined by its 527 component payloads. 529 1.5 Informational Messages outside of an IKE_SA 531 If a packet arrives with an unrecognized SPI, it could be because the 532 receiving node has recently crashed and lost state or because of some 533 other system malfunction or attack. If the receiving node has an 534 active IKE_SA to the IP address from whence the packet came, it MAY 535 send a notification of the wayward packet over that IKE_SA. If it 536 does not, it MAY send an Informational message without cryptographic 537 protection to the source IP address and port to alert it to a 538 possible problem. 540 2 IKE Protocol Details and Variations 542 IKE normally listens and sends on UDP port 500, though IKE messages 543 may also be received on UDP port 4500 with a slightly different 544 format (see section 2.23). Since UDP is a datagram (unreliable) 545 protocol, IKE includes in its definition recovery from transmission 546 errors, including packet loss, packet replay, and packet forgery. IKE 547 is designed to function so long as (1) at least one of a series of 548 retransmitted packets reaches its destination before timing out; and 549 (2) the channel is not so full of forged and replayed packets so as 550 to exhaust the network or CPU capacities of either endpoint. Even in 551 the absence of those minimum performance requirements, IKE is 552 designed to fail cleanly (as though the network were broken). 554 2.1 Use of Retransmission Timers 556 All messages in IKE exist in pairs: a request and a response. The 557 setup of an IKE_SA normally consists of two request/response pairs. 558 Once the IKE_SA is set up, either end of the security association may 559 initiate requests at any time, and there can be many requests and 560 responses "in flight" at any given moment. But each message is 561 labelled as either a request or a response and for each 562 request/response pair one end of the security association is the 563 Initiator and the other is the Responder. 565 For every pair of IKE messages, the Initiator is responsible for 566 retransmission in the event of a timeout. The Responder MUST never 567 retransmit a response unless it receives a retransmission of the 568 request. In that event, the Responder MUST ignore the retransmitted 569 request except insofar as it triggers a retransmission of the 570 response. The Initiator MUST remember each request until it receives 571 the corresponding response. The Responder MUST remember each response 572 until it receives a request whose sequence number is larger than the 573 sequence number in the response plus his window size (see section 574 2.3). 576 IKE is a reliable protocol, in the sense that the Initiator MUST 577 retransmit a request until either it receives a corresponding reply 578 OR it deems the IKE security association to have failed and it 579 discards all state associated with the IKE_SA and any CHILD_SAs 580 negotiated using that IKE_SA. 582 2.2 Use of Sequence Numbers for Message ID 584 Every IKE message contains a Message ID as part of its fixed header. 585 This Message ID is used to match up requests and responses, and to 586 identify retransmissions of messages. 588 The Message ID is a 32 bit quantity, which is zero for the first IKE 589 request in each direction. The IKE_SA initial setup messages will 590 always be numbered 0 and 1. Each endpoint in the IKE Security 591 Association maintains two "current" Message IDs: the next one to be 592 used for a request it initiates and the next one it expects to see in 593 a request from the other end. These counters increment as requests 594 are generated and received. Responses always contain the same message 595 ID as the corresponding request. That means that after the initial 596 exchange, each integer n may appear as the message ID in four 597 distinct messages: The nth request from the original IKE Initiator, 598 the corresponding response, the nth request from the original IKE 599 Responder, and the corresponding response. If the two ends make very 600 different numbers of requests, the Message IDs in the two directions 601 can be very different. There is no ambiguity in the messages, 602 however, because the (I)nitiator and (R)esponse bits in the message 603 header specify which of the four messages a particular one is. 605 Note that Message IDs are cryptographically protected and provide 606 protection against message replays. In the unlikely event that 607 Message IDs grow too large to fit in 32 bits, the IKE_SA MUST be 608 closed. Rekeying an IKE_SA resets the sequence numbers. 610 2.3 Window Size for overlapping requests 612 In order to maximize IKE throughput, an IKE endpoint MAY issue 613 multiple requests before getting a response to any of them if the 614 other endpoint has indicated its ability to handle such requests. For 615 simplicity, an IKE implementation MAY choose to process requests 616 strictly in order and/or wait for a response to one request before 617 issuing another. Certain rules must be followed to assure 618 interoperability between implementations using different strategies. 620 After an IKE_SA is set up, either end can initiate one or more 621 requests. These requests may pass one another over the network. An 622 IKE endpoint MUST be prepared to accept and process a request while 623 it has a request outstanding in order to avoid a deadlock in this 624 situation. An IKE endpoint SHOULD be prepared to accept and process 625 multiple requests while it has a request outstanding. 627 An IKE endpoint MUST wait for a response to each of its messages 628 before sending a subsequent message unless it has received a 629 SET_WINDOW_SIZE Notify message from its peer informing it that the 630 peer is prepared to maintain state for multiple outstanding messages 631 in order to allow greater throughput. 633 An IKE endpoint MUST NOT exceed the peer's stated window size for 634 transmitted IKE requests. In other words, if Bob stated his window 635 size is N, then when Alice needs to make a request X, she MUST wait 636 until she has received responses to all requests up through request 637 X-N. An IKE endpoint MUST keep a copy of (or be able to regenerate 638 exactly) each request it has sent until it receives the corresponding 639 response. An IKE endpoint MUST keep a copy of (or be able to 640 regenerate exactly) the number of previous responses equal to its 641 declared window size in case its response was lost and the Initiator 642 requests its retransmission by retransmitting the request. 644 An IKE endpoint supporting a window size greater than one SHOULD be 645 capable of processing incoming requests out of order to maximize 646 performance in the event of network failures or packet reordering. 648 2.4 State Synchronization and Connection Timeouts 650 An IKE endpoint is allowed to forget all of its state associated with 651 an IKE_SA and the collection of corresponding CHILD_SAs at any time. 652 This is the anticipated behavior in the event of an endpoint crash 653 and restart. It is important when an endpoint either fails or 654 reinitializes its state that the other endpoint detect those 655 conditions and not continue to waste network bandwidth by sending 656 packets over discarded SAs and having them fall into a black hole. 658 Since IKE is designed to operate in spite of Denial of Service (DoS) 659 attacks from the network, an endpoint MUST NOT conclude that the 660 other endpoint has failed based on any routing information (e.g., 661 ICMP messages) or IKE messages that arrive without cryptographic 662 protection (e.g., Notify messages complaining about unknown SPIs). An 663 endpoint MUST conclude that the other endpoint has failed only when 664 repeated attempts to contact it have gone unanswered for a timeout 665 period or when a cryptographically protected INITIAL_CONTACT 666 notification is received on a different IKE_SA to the same 667 authenticated identity. An endpoint SHOULD suspect that the other 668 endpoint has failed based on routing information and initiate a 669 request to see whether the other endpoint is alive. To check whether 670 the other side is alive, IKE specifies an empty INFORMATIONAL message 671 that (like all IKE requests) requires an acknowledgment. If a 672 cryptographically protected message has been received from the other 673 side recently, unprotected notifications MAY be ignored. 674 Implementations MUST limit the rate at which they take actions based 675 on unprotected messages. 677 Numbers of retries and lengths of timeouts are not covered in this 678 specification because they do not affect interoperability. It is 679 suggested that messages be retransmitted at least a dozen times over 680 a period of at least several minutes before giving up on an SA, but 681 different environments may require different rules. If there has only 682 been outgoing traffic on all of the SAs associated with an IKE_SA, it 683 is essential to confirm liveness of the other endpoint to avoid black 684 holes. If no cryptographically protected messages have been received 685 on an IKE_SA or any of its CHILD_SAs recently, the system needs to 686 perform a liveness check in order to prevent sending messages to a 687 dead peer. Receipt of a fresh cryptographically protected message on 688 an IKE_SA or any of its CHILD_SAs assures liveness of the IKE_SA and 689 all of its CHILD_SAs. Note that this places requirements on the 690 failure modes of an IKE endpoint. An implementation MUST NOT continue 691 sending on any SA if some failure prevents it from receiving on all 692 of the associated SAs. If CHILD_SAs can fail independently from one 693 another without the associated IKE_SA being able to send a delete 694 message, then they MUST be negotiated by separate IKE_SAs. 696 There is a Denial of Service attack on the Initiator of an IKE_SA 697 that can be avoided if the Initiator takes the proper care. Since the 698 first two messages of an SA setup are not cryptographically 699 protected, an attacker could respond to the Initiator's message 700 before the genuine Responder and poison the connection setup attempt. 701 To prevent this, the Initiator MAY be willing to accept multiple 702 responses to its first message, treat each as potentially legitimate, 703 respond to it, and then discard all the invalid half open connections 704 when she receives a valid cryptographically protected response to any 705 one of her requests. Once a cryptographically valid response is 706 received, all subsequent responses should be ignored whether or not 707 they are cryptographically valid. 709 Note that with these rules, there is no reason to negotiate and agree 710 upon an SA lifetime. If IKE presumes the partner is dead, based on 711 repeated lack of acknowledgment to an IKE message, then the IKE SA 712 and all CHILD_SAs set up through that IKE_SA are deleted. 714 An IKE endpoint may at any time delete inactive CHILD_SAs to recover 715 resources used to hold their state. If an IKE endpoint chooses to do 716 so, it MUST send Delete payloads to the other end notifying it of the 717 deletion. It MAY similarly time out the IKE_SA. Closing the IKE_SA 718 implicitly closes all associated CHILD_SAs. In this case, an IKE 719 endpoint SHOULD send a Delete payload indicating that it has closed 720 the IKE_SA. 722 2.5 Version Numbers and Forward Compatibility 724 This document describes version 2.0 of IKE, meaning the major version 725 number is 2 and the minor version number is zero. It is likely that 726 some implementations will want to support both version 1.0 and 727 version 2.0, and in the future, other versions. 729 The major version number should only be incremented if the packet 730 formats or required actions have changed so dramatically that an 731 older version node would not be able to interoperate with a newer 732 version node if it simply ignored the fields it did not understand 733 and took the actions specified in the older specification. The minor 734 version number indicates new capabilities, and MUST be ignored by a 735 node with a smaller minor version number, but used for informational 736 purposes by the node with the larger minor version number. For 737 example, it might indicate the ability to process a newly defined 738 notification message. The node with the larger minor version number 739 would simply note that its correspondent would not be able to 740 understand that message and therefore would not send it. 742 If an endpoint receives a message with a higher major version number, 743 it MUST drop the message and SHOULD send an unauthenticated 744 notification message containing the highest version number it 745 supports. If an endpoint supports major version n, and major version 746 m, it MUST support all versions between n and m. If it receives a 747 message with a major version that it supports, it MUST respond with 748 that version number. In order to prevent two nodes from being tricked 749 into corresponding with a lower major version number than the maximum 750 that they both support, IKE has a flag that indicates that the node 751 is capable of speaking a higher major version number. 753 Thus the major version number in the IKE header indicates the version 754 number of the message, not the highest version number that the 755 transmitter supports. If Alice is capable of speaking versions n, 756 n+1, and n+2, and Bob is capable of speaking versions n and n+1, then 757 they will negotiate speaking n+1, where Alice will set the flag 758 indicating ability to speak a higher version. If they mistakenly 759 (perhaps through an active attacker sending error messages) negotiate 760 to version n, then both will notice that the other side can support a 761 higher version number, and they MUST break the connection and 762 reconnect using version n+1. 764 Note that IKEv1 does not follow these rules, because there is no way 765 in v1 of noting that you are capable of speaking a higher version 766 number. So an active attacker can trick two v2-capable nodes into 767 speaking v1. When a v2-capable node negotiates down to v1, it SHOULD 768 note that fact in its logs. 770 Also for forward compatibility, all fields marked RESERVED MUST be 771 set to zero by a version 2.0 implementation and their content MUST be 772 ignored by a version 2.0 implementation ("Be conservative in what you 773 send and liberal in what you receive"). In this way, future versions 774 of the protocol can use those fields in a way that is guaranteed to 775 be ignored by implementations that do not understand them. 776 Similarly, payload types that are not defined are reserved for future 777 use and implementations of version 2.0 MUST skip over those payloads 778 and ignore their contents. 780 IKEv2 adds a "critical" flag to each payload header for further 781 flexibility for forward compatibility. If the critical flag is set 782 and the payload type is unrecognized, the message MUST be rejected 783 and the response to the IKE request containing that payload MUST 784 include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an 785 unsupported critical payload was included. If the critical flag is 786 not set and the payload type is unsupported, that payload MUST be 787 ignored. 789 While new payload types may be added in the future and may appear 790 interleaved with the fields defined in this specification, 791 implementations MUST send the payloads defined in this specification 792 in the order shown in the figures in section 2 and implementations 793 SHOULD reject as invalid a message with those payloads in any other 794 order. 796 2.6 Cookies 798 The term "cookies" originates with Karn and Simpson [RFC 2522] in 799 Photuris, an early proposal for key management with IPsec, and it has 800 persisted. The ISAKMP fixed message header includes two eight octet 801 fields titled "cookies", and that syntax is used by both IKEv1 and 802 IKEv2 though in IKEv2 they are referred to as the IKE SPI and there 803 is a new separate field in a Notify payload holding the cookie. The 804 initial two eight octet fields in the header are used as a connection 805 identifier at the beginning of IKE packets. Each endpoint chooses one 806 of the two SPIs and SHOULD choose them so as to be unique identifiers 807 of an IKE_SA. An SPI value of zero is special and indicates that the 808 remote SPI value is not yet known by the sender. 810 Unlike ESP and AH where only the recipient's SPI appears in the 811 header of a message, in IKE the sender's SPI is also sent in every 812 message. Since the SPI chosen by the original initiator of the IKE_SA 813 is always sent first, an endpoint with multiple IKE_SAs open that 814 wants to find the appropriate IKE_SA using the SPI it assigned must 815 look at the I(nitiator) Flag bit in the header to determine whether 816 it assigned the first or the second eight octets. 818 In the first message of an initial IKE exchange, the initiator will 819 not know the responder's SPI value and will therefore set that field 820 to zero. 822 An expected attack against IKE is state and CPU exhaustion, where the 823 target is flooded with session initiation requests from forged IP 824 addresses. This attack can be made less effective if an 825 implementation of a responder uses minimal CPU and commits no state 826 to an SA until it knows the initiator can receive packets at the 827 address from which he claims to be sending them. To accomplish this, 828 a responder SHOULD - when it detects a large number of half-open 829 IKE_SAs - reject initial IKE messages unless they contain a Notify 830 payload of type COOKIE. It SHOULD instead send an unprotected IKE 831 message as a response and include COOKIE Notify payload with the 832 cookie data to be returned. Initiators who receive such responses 833 MUST retry the IKE_SA_INIT with a Notify payload of type COOKIE 834 containing the responder supplied cookie data as the first payload 835 and all other payloads unchanged. The initial exchange will then be 836 as follows: 838 Initiator Responder 839 ----------- ----------- 840 HDR(A,0), SAi1, KEi, Ni --> 842 <-- HDR(A,0), N(COOKIE) 844 HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> 846 <-- HDR(A,B), SAr1, KEr, Nr, [CERTREQ] 848 HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,] 849 AUTH, SAi2, TSi, TSr} --> 851 <-- HDR(A,B), SK {IDr, [CERT,] AUTH, 852 SAr2, TSi, TSr} 854 The first two messages do not affect any initiator or responder state 855 except for communicating the cookie. In particular, the message 856 sequence numbers in the first four messages will all be zero and the 857 message sequence numbers in the last two messages will be one. 'A' is 858 the SPI assigned by the initiator, while 'B' is the SPI assigned by 859 the responder. 861 An IKE implementation SHOULD implement its responder cookie 862 generation in such a way as to not require any saved state to 863 recognize its valid cookie when the second IKE_SA_INIT message 864 arrives. The exact algorithms and syntax they use to generate 865 cookies does not affect interoperability and hence is not specified 866 here. The following is an example of how an endpoint could use 867 cookies to implement limited DOS protection. 869 A good way to do this is to set the responder cookie to be: 871 Cookie = | Hash(Ni | IPi | SPIi | ) 873 where is a randomly generated secret known only to the 874 responder and periodically changed and | indicates concatenation. 875 should be changed whenever is 876 regenerated. The cookie can be recomputed when the IKE_SA_INIT 877 arrives the second time and compared to the cookie in the received 878 message. If it matches, the responder knows that SPIr was generated 879 since the last change to and that IPi must be the same as 880 the source address it saw the first time. Incorporating SPIi into the 881 calculation assures that if multiple IKE_SAs are being set up in 882 parallel they will all get different cookies (assuming the initiator 883 chooses unique SPIi's). Incorporating Ni into the hash assures that 884 an attacker who sees only message 2 can't successfully forge a 885 message 3. 887 If a new value for is chosen while there are connections in 888 the process of being initialized, an IKE_SA_INIT might be returned 889 with other than the current . The responder in 890 that case MAY reject the message by sending another response with a 891 new cookie or it MAY keep the old value of around for a 892 short time and accept cookies computed from either one. The 893 responder SHOULD NOT accept cookies indefinitely after is 894 changed, since that would defeat part of the denial of service 895 protection. The responder SHOULD change the value of 896 frequently, especially if under attack. 898 2.7 Cryptographic Algorithm Negotiation 900 The payload type known as "SA" indicates a proposal for a set of 901 choices of IPsec protocols (IKE, ESP, and/or AH) for the SA as well 902 as cryptographic algorithms associated with each protocol. 904 An SA consists of one or more proposals. Each proposal includes one 905 or more protocols (usually one). Each protocol contains one or more 906 transforms - each specifying a cryptographic algorithm. Each 907 transform contains zero or more attributes (attributes are only 908 needed if the transform identifier does not completely specify the 909 cryptographic algorithm). 911 This hierarchical structure was designed to efficiently encode 912 proposals for cryptographic suites when the number of supported 913 suites is large because multiple values are acceptable for multiple 914 transforms. The responder MUST choose a single suite, which MAY be 915 any subset of the SA proposal following the rules below: 917 Each proposal contains one or more protocols. If a proposal is 918 accepted, the SA response MUST contain the same protocols in the 919 same order as the proposal. The responder MUST accept a single 920 proposal or reject them all and return an error. (Example: if a 921 single proposal contains ESP and AH and that proposal is accepted, 922 both ESP and AH MUST be accepted. If ESP and AH are included in 923 separate proposals, the responder MUST accept only one of them). 925 Each IPsec protocol proposal contains one or more transforms. Each 926 transform contains a transform type. The accepted cryptographic 927 suite MUST contain exactly one transform of each type included in 928 the proposal. For example: if an ESP proposal includes transforms 929 ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256, 930 AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain 931 one of the ENCR_ transforms and one of the AUTH_ transforms. Thus 932 six combinations are acceptable. 934 Since Alice sends her Diffie-Hellman value in the IKE_SA_INIT, she 935 must guess at the Diffie-Hellman group that Bob will select from her 936 list of supported groups. If she guesses wrong, Bob will respond 937 with a Notify payload of type INVALID_KE_PAYLOAD indicating the 938 selected group. In this case, Alice MUST retry the IKE_SA_INIT with 939 the corrected Diffie-Hellman group. Alice MUST again propose her full 940 set of acceptable cryptographic suites because the rejection message 941 was unauthenticated and otherwise an active attacker could trick 942 Alice and Bob into negotiating a weaker suite than a stronger one 943 that they both prefer. 945 2.8 Rekeying 947 IKE, ESP, and AH security associations use secret keys which SHOULD 948 only be used for a limited amount of time and to protect a limited 949 amount of data. This limits the lifetime of the entire security 950 association. When the lifetime of a security association expires the 951 security association MUST NOT be used. If there is demand, new 952 security associations MAY be established. Reestablishment of 953 security associations to take the place of ones which expire is 954 referred to as "rekeying". 956 To allow for minimal IPsec implementations, the ability to rekey SAs 957 without restarting the entire IKE_SA is optional. An implementation 958 MAY refuse all CREATE_CHILD_SA requests within an IKE_SA. If an SA 959 has expired or is about to expire and rekeying attempts using the 960 mechanisms described here fail, an implementation MUST close the 961 IKE_SA and any associated CHILD_SAs and then MAY start new ones. 962 Implementations SHOULD support in place rekeying of SAs, since doing 963 so offers better performance and is likely to reduce the number of 964 packets lost during the transition. 966 To rekey a CHILD_SA within an existing IKE_SA, create a new, 967 equivalent SA (see section 2.17 below), and when the new one is 968 established, delete the old one. To rekey an IKE_SA, establish a new 969 equivalent IKE_SA (see section 2.18 below) with the peer to whom the 970 old IKE_SA is shared using a CREATE_CHILD_SA within the existing 971 IKE_SA. An IKE_SA so created inherits all of the original IKE_SA's 972 CHILD_SAs. Use the new IKE_SA for all control messages needed to 973 maintain the CHILD_SAs created by the old IKE_SA, and delete the old 974 IKE_SA. The Delete payload to delete itself MUST be the last request 975 sent over an IKE_SA. 977 SAs SHOULD be rekeyed proactively, i.e., the new SA should be 978 established before the old one expires and becomes unusable. Enough 979 time should elapse between the time the new SA is established and the 980 old one becomes unusable so that traffic can be switched over to the 981 new SA. 983 A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes 984 were negotiated. In IKEv2, each end of the SA is responsible for 985 enforcing its own lifetime policy on the SA and rekeying the SA when 986 necessary. If the two ends have different lifetime policies, the end 987 with the shorter lifetime will end up always being the one to request 988 the rekeying. If an SA bundle has been inactive for a long time and 989 if an endpoint would not initiate the SA in the absence of traffic, 990 the endpoint MAY choose to close the SA instead of rekeying it when 991 its lifetime expires. It SHOULD do so if there has been no traffic 992 since the last time the SA was rekeyed. 994 If the two ends have the same lifetime policies, it is possible that 995 both will initiate a rekeying at the same time (which will result in 996 redundant SAs). To reduce the probability of this happening, the 997 timing of rekeying requests SHOULD be jittered (delayed by a random 998 amount of time after the need for rekeying is noticed). 1000 This form of rekeying may temporarily result in multiple similar SAs 1001 between the same pairs of nodes. When there are two SAs eligible to 1002 receive packets, a node MUST accept incoming packets through either 1003 SA. If redundant SAs are created though such a collision, the SA 1004 created with the lowest of the four nonces used in the two exchanges 1005 SHOULD be closed by the endpoint that created it. 1007 Note that IKEv2 deliberately allows parallel SAs with the same 1008 traffic selectors between common endpoints. One of the purposes of 1009 this is to support traffic QoS differences among the SAs (see section 1010 4.1 of [RFC 2983]). Hence unlike IKEv1, the combination of the 1011 endpoints and the traffic selectors may not uniquely identify an SA 1012 between those endpoints, so the IKEv1 rekeying heuristic of deleting 1013 SAs on the basis of duplicate traffic selectors SHOULD NOT be used. 1015 The node that initiated the surviving rekeyed SA SHOULD delete the 1016 replaced SA after the new one is established. 1018 There are timing windows - particularly in the presence of lost 1019 packets - where endpoints may not agree on the state of an SA. The 1020 responder to a CREATE_CHILD_SA MUST be prepared to accept messages on 1021 an SA before sending its response to the creation request, so there 1022 is no ambiguity for the initiator. The initiator MAY begin sending on 1023 an SA as soon as it processes the response. The initiator, however, 1024 cannot receive on a newly created SA until it receives and processes 1025 the response to its CREATE_CHILD_SA request. How, then, is the 1026 responder to know when it is OK to send on the newly created SA? 1028 From a technical correctness and interoperability perspective, the 1029 responder MAY begin sending on an SA as soon as it sends its response 1030 to the CREATE_CHILD_SA request. In some situations, however, this 1031 could result in packets unnecessarily being dropped, so an 1032 implementation MAY want to defer such sending. 1034 The responder can be assured that the initiator is prepared to 1035 receive messages on an SA if either (1) it has received a 1036 cryptographically valid message on the new SA, or (2) the new SA 1037 rekeys an existing SA and it receives an IKE request to close the 1038 replaced SA. When rekeying an SA, the responder SHOULD continue to 1039 send requests on the old SA until it one of those events occurs. When 1040 establishing a new SA, the responder MAY defer sending messages on a 1041 new SA until either it receives one or a timeout has occurred. If an 1042 initiator receives a message on an SA for which it has not received a 1043 response to its CREATE_CHILD_SA request, it SHOULD interpret that as 1044 a likely packet loss and retransmit the CREATE_CHILD_SA request. An 1045 initiator MAY send a dummy message on a newly created SA if it has no 1046 messages queued in order to assure the responder that the initiator 1047 is ready to receive messages. 1049 2.9 Traffic Selector Negotiation 1051 When an IP packet is received by an RFC2401 compliant IPsec subsystem 1052 and matches a "protect" selector in its SPD, the subsystem MUST 1053 protect that packet with IPsec. When no SA exists yet it is the task 1054 of IKE to create it. Maintenance of a system's SPD is outside the 1055 scope of IKE (see [PFKEY] for an example protocol), though some 1056 implementations might update their SPD in connection with the running 1057 of IKE (for an example scenario, see section 1.1.3). 1059 Traffic Selector (TS) payloads allow endpoints to communicate some of 1060 the information from their SPD to their peers. TS payloads specify 1061 the selection criteria for packets that will be forwarded over the 1062 newly set up SA. This can serve as a consistency check in some 1063 scenarios to assure that the SPDs are consistent. In others, it 1064 guides the dynamic update of the SPD. 1066 Two TS payloads appear in each of the messages in the exchange that 1067 creates a CHILD_SA pair. Each TS payload contains one or more Traffic 1068 Selectors. Each Traffic Selector consists of an address range (IPv4 1069 or IPv6), a port range, and an IP protocol ID. In support of the 1070 scenario described in section 1.1.3, an initiator may request that 1071 the responder assign an IP address and tell the initiator what it is. 1073 IKEv2 allows the responder to choose a subset of the traffic proposed 1074 by the initiator. This could happen when the configuration of the 1075 two endpoints are being updated but only one end has received the new 1076 information. Since the two endpoints may be configured by different 1077 people, the incompatibility may persist for an extended period even 1078 in the absence of errors. It also allows for intentionally different 1079 configurations, as when one end is configured to tunnel all addresses 1080 and depends on the other end to have the up to date list. 1082 The first of the two TS payloads is known as TSi (Traffic Selector- 1083 initiator). The second is known as TSr (Traffic Selector-responder). 1084 TSi specifies the source address of traffic forwarded from (or the 1085 destination address of traffic forwarded to) the initiator of the 1086 CHILD_SA pair. TSr specifies the destination address of the traffic 1087 forwarded from (or the source address of the traffic forwarded to) 1088 the responder of the CHILD_SA pair. For example, if Alice initiates 1089 the creation of the CHILD_SA pair from Alice to Bob, and wishes to 1090 tunnel all traffic from subnet 10.2.16.* on Alice's side to subnet 1091 10.16.*.* on Bob's side, Alice would include a single traffic 1092 selector in each TS payload. TSi would specify the address range 1093 (10.2.16.0 - 10.2.16.255) and TSr would specify the address range 1094 (10.16.0.0 - 10.16.255.255). Assuming that proposal was acceptable to 1095 Bob, he would send identical TS payloads back. 1097 The Responder is allowed to narrow the choices by selecting a subset 1098 of the traffic, for instance by eliminating or narrowing the range of 1099 one or more members of the set of traffic selectors, provided the set 1100 does not become the NULL set. 1102 It is possible for the Responder's policy to contain multiple smaller 1103 ranges, all encompassed by the Initiator's traffic selector, and with 1104 the Responder's policy being that each of those ranges should be sent 1105 over a different SA. Continuing the example above, Bob might have a 1106 policy of being willing to tunnel those addresses to and from Alice, 1107 but might require that each address pair be on a separately 1108 negotiated CHILD_SA. If Alice generated her request in response to an 1109 incoming packet from 10.2.16.43 to 10.16.2.123, there would be no way 1110 for Bob to determine which pair of addresses should be included in 1111 this tunnel, and he would have to make his best guess or reject the 1112 request with a status of SINGLE_PAIR_REQUIRED. 1114 To enable Bob to choose the appropriate range in this case, if Alice 1115 has initiated the SA due to a data packet, Alice SHOULD include as 1116 the first traffic selector in each of TSi and TSr a very specific 1117 traffic selector including the addresses in the packet triggering the 1118 request. In the example, Alice would include in TSi two traffic 1119 selectors: the first containing the address range (10.2.16.43 - 1120 10.2.16.43) and the source port and IP protocol from the packet and 1121 the second containing (10.2.16.0 - 10.2.16.255) with all ports and IP 1122 protocols. She would similarly include two traffic selectors in TSr. 1124 If Bob's policy does not allow him to accept the entire set of 1125 traffic selectors in Alice's request, but does allow him to accept 1126 the first selector of TSi and TSr, then Bob MUST narrow the traffic 1127 selectors to a subset that includes Alice's first choices. In this 1128 example, Bob might respond with TSi being (10.2.16.43 - 10.2.16.43) 1129 with all ports and IP protocols. 1131 If Alice creates the CHILD_SA pair not in response to an arriving 1132 packet, but rather - say - upon startup, then there may be no 1133 specific addresses Alice prefers for the initial tunnel over any 1134 other. In that case, the first values in TSi and TSr MAY be ranges 1135 rather than specific values, and Bob chooses a subset of Alice's TSi 1136 and TSr that are acceptable to him. If more than one subset is 1137 acceptable but their union is not, Bob MUST accept some subset and 1138 MAY include a Notify payload of type ADDITIONAL_TS_POSSIBLE to 1139 indicate that Alice might want to try again. This case will only 1140 occur when Alice and Bob are configured differently from one another. 1141 If Alice and Bob agree on the granularity of tunnels, she will never 1142 request a tunnel wider than Bob will accept. 1144 2.10 Nonces 1146 The IKE_SA_INIT messages each contain a nonce. These nonces are used 1147 as inputs to cryptographic functions. The CREATE_CHILD_SA request 1148 and the CREATE_CHILD_SA response also contain nonces. These nonces 1149 are used to add freshness to the key derivation technique used to 1150 obtain keys for CHILD_SA, and to ensure creation of strong 1151 pseudorandom bits from the Diffie-Hellman key. Nonces used in IKEv2 1152 MUST be randomly chosen, MUST be at least 128 bits in size, and MUST 1153 be at least half the key size of the negotiated prf. ("prf" refers to 1154 "pseudo-random function", one of the cryptographic algorithms 1155 negotiated in the IKE exchange). If the same random number source is 1156 used for both keys and nonces, care must be taken to ensure that the 1157 latter use does not compromise the former. 1159 2.11 Address and Port Agility 1161 IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and 1162 AH associations for the same IP addresses it runs over. The IP 1163 addresses and ports in the outer header are, however, not themselves 1164 cryptographically protected, and IKE is designed to work even through 1165 Network Address Translation (NAT) boxes. An implementation MUST 1166 accept incoming requests even if the source port is not 500 or 4500, 1167 and MUST respond to the address and port from which the request was 1168 received. It MUST specify the address and port at which the request 1169 was received as the source address and port in the response. IKE 1170 functions identically over IPv4 or IPv6. 1172 2.12 Reuse of Diffie-Hellman Exponentials 1174 IKE generates keying material using an ephemeral Diffie-Hellman 1175 exchange in order to gain the property of "perfect forward secrecy". 1176 This means that once a connection is closed and its corresponding 1177 keys are forgotten, even someone who has recorded all of the data 1178 from the connection and gets access to all of the long-term keys of 1179 the two endpoints cannot reconstruct the keys used to protect the 1180 conversation without doing a brute force search of the session key 1181 space. 1183 Achieving perfect forward secrecy requires that when a connection is 1184 closed, each endpoint MUST forget not only the keys used by the 1185 connection but any information that could be used to recompute those 1186 keys. In particular, it MUST forget the secrets used in the Diffie- 1187 Hellman calculation and any state that may persist in the state of a 1188 pseudo-random number generator that could be used to recompute the 1189 Diffie-Hellman secrets. 1191 Since the computing of Diffie-Hellman exponentials is computationally 1192 expensive, an endpoint may find it advantageous to reuse those 1193 exponentials for multiple connection setups. There are several 1194 reasonable strategies for doing this. An endpoint could choose a new 1195 exponential only periodically though this could result in less-than- 1196 perfect forward secrecy if some connection lasts for less than the 1197 lifetime of the exponential. Or it could keep track of which 1198 exponential was used for each connection and delete the information 1199 associated with the exponential only when some corresponding 1200 connection was closed. This would allow the exponential to be reused 1201 without losing perfect forward secrecy at the cost of maintaining 1202 more state. 1204 Decisions as to whether and when to reuse Diffie-Hellman exponentials 1205 is a private decision in the sense that it will not affect 1206 interoperability. An implementation that reuses exponentials MAY 1207 choose to remember the exponential used by the other endpoint on past 1208 exchanges and if one is reused to avoid the second half of the 1209 calculation. 1211 2.13 Generating Keying Material 1213 In the context of the IKE_SA, four cryptographic algorithms are 1214 negotiated: an encryption algorithm, an integrity protection 1215 algorithm, a Diffie-Hellman group, and a pseudo-random function 1216 (prf). The pseudo-random function is used for the construction of 1217 keying material for all of the cryptographic algorithms used in both 1218 the IKE_SA and the CHILD_SAs. 1220 We assume that each encryption algorithm and integrity protection 1221 algorithm uses a fixed size key, and that any randomly chosen value 1222 of that fixed size can serve as an appropriate key. For algorithms 1223 that accept a variable length key, a fixed key size MUST be specified 1224 as part of the cryptographic transform negotiated. For algorithms 1225 for which not all values are valid keys (such as DES or 3DES with key 1226 parity), they algorithm by which keys are derived from arbitrary 1227 values MUST be specified by the cryptographic transform. For 1228 integrity protection functions based on HMAC, the fixed key size is 1229 the size of the output of the underlying hash function. When the prf 1230 function takes a variable length key, variable length data, and 1231 produces a fixed length output (e.g., when using HMAC), the formulas 1232 in this document apply. When the key for the prf function has fixed 1233 length, the data provided as a key is truncated or padded with zeros 1234 as necessary unless exceptional processing is explained following the 1235 formula. 1237 Keying material will always be derived as the output of the 1238 negotiated prf algorithm. Since the amount of keying material needed 1239 may be greater than the size of the output of the prf algorithm, we 1240 will use the prf iteratively. We will use the terminology prf+ to 1241 describe the function that outputs a pseudo-random stream based on 1242 the inputs to a prf as follows: (where | indicates concatenation) 1244 prf+ (K,S) = T1 | T2 | T3 | T4 | ... 1246 where: 1248 T1 = prf (K, S | 0x01) 1249 T2 = prf (K, T1 | S | 0x02) 1250 T3 = prf (K, T2 | S | 0x03) 1251 T4 = prf (K, T3 | S | 0x04) 1253 continuing as needed to compute all required keys. The keys are taken 1254 from the output string without regard to boundaries (e.g., if the 1255 required keys are a 256 bit AES key and a 160 bit HMAC key, and the 1256 prf function generates 160 bits, the AES key will come from T1 and 1257 the beginning of T2, while the HMAC key will come from the rest of T2 1258 and the beginning of T3). 1260 The constant concatenated to the end of each string feeding the prf 1261 is a single octet. prf+ in this document is not defined beyond 255 1262 times the size of the prf output. 1264 2.14 Generating Keying Material for the IKE_SA 1266 The shared keys are computed as follows. A quantity called SKEYSEED 1267 is calculated from the nonces exchanged during the IKE_SA_INIT 1268 exchange and the Diffie-Hellman shared secret established during that 1269 exchange. SKEYSEED is used to calculate five other secrets: SK_d 1270 used for deriving new keys for the CHILD_SAs established with this 1271 IKE_SA; SK_ai and SK_ar used as a key to the integrity protection 1272 algorithm for authenticating the component messages of subsequent 1273 exchanges; and SK_ei and SK_er used for encrypting (and of course 1274 decrypting) all subsequent exchanges. SKEYSEED and its derivatives 1275 are computed as follows: 1277 SKEYSEED = prf(Ni | Nr, g^ir) 1279 {SK_d | SK_ai | SK_ar | SK_ei | SK_er} 1280 = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) 1282 (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, and SK_er 1283 are taken in order from the generated bits of the prf+). g^ir is the 1284 shared secret from the ephemeral Diffie-Hellman exchange. g^ir is 1285 represented as a string of octets in big endian order padded with 1286 zeros if necessary to make it the length of the modulus. Ni and Nr 1287 are the nonces, stripped of any headers. If the negotiated prf takes 1288 a fixed length key and the lengths of Ni and Nr do not add up to that 1289 length, half the bits must come from Ni and half from Nr, taking the 1290 first bits of each. 1292 The two directions of traffic flow use different keys. The keys used 1293 to protect messages from the original initiator are SK_ai and SK_ei. 1294 The keys used to protect messages in the other direction are SK_ar 1295 and SK_er. Each algorithm takes a fixed number of bits of keying 1296 material, which is specified as part of the algorithm. For integrity 1297 algorithms based on HMAC, the key size is always equal to the length 1298 of the output of the underlying hash function. 1300 2.15 Authentication of the IKE_SA 1302 When not using extended authentication (see section 2.16), the peers 1303 are authenticated by having each sign (or MAC using a shared secret 1304 as the key) a block of data. For the responder, the octets to be 1305 signed start with the first octet of the first SPI in the header of 1306 the second message and end with the last octet of the last payload in 1307 the second message. Appended to this (for purposes of computing the 1308 signature) are the initiator's nonce Ni (just the value, not the 1309 payload containing it), and the value prf(SK_ar,IDr') where IDr' is 1310 the responder's ID payload excluding the fixed header. Note that 1311 neither the nonce Ni nor the value prf(SK_ar,IDr') are transmitted. 1312 Similarly, the initiator signs the first message, starting with the 1313 first octet of the first SPI in the header and ending with the last 1314 octet of the last payload. Appended to this (for purposes of 1315 computing the signature) are the responder's nonce Nr, and the value 1316 prf(SK_ai,IDi'). In the above calculation, IDi' and IDr' are the 1317 entire ID payloads excluding the fixed header. It is critical to the 1318 security of the exchange that each side sign the other side's nonce. 1320 Note that all of the payloads are included under the signature, 1321 including any payload types not defined in this document. If the 1322 first message of the exchange is sent twice (the second time with a 1323 responder cookie and/or a different Diffie-Hellman group), it is the 1324 second version of the message that is signed. 1326 Optionally, messages 3 and 4 MAY include a certificate, or 1327 certificate chain providing evidence that the key used to compute a 1328 digital signature belongs to the name in the ID payload. The 1329 signature or MAC will be computed using algorithms dictated by the 1330 type of key used by the signer, and specified by the Auth Method 1331 field in the Authentication payload. There is no requirement that 1332 the Initiator and Responder sign with the same cryptographic 1333 algorithms. The choice of cryptographic algorithms depends on the 1334 type of key each has. In particular, the initiator may be using a 1335 shared key while the responder may have a public signature key and 1336 certificate. It will commonly be the case (but it is not required) 1337 that if a shared secret is used for authentication that the same key 1338 is used in both directions. Note that it is a common but typically 1339 insecure practice to have a shared key derived solely from a user 1340 chosen password without incorporating another source of randomness. 1341 This is typically insecure because user chosen passwords are unlikely 1342 to have sufficient unpredictability to resist dictionary attacks and 1343 these attacks are not prevented in this authentication method. 1345 (Applications using password-based authentication for bootstrapping 1346 and IKE_SA should use the authentication method in section 2.16, 1347 which is designed to prevent off-line dictionary attacks). The pre- 1348 shared key SHOULD contain as much unpredictability as the strongest 1349 key being negotiated. In the case of a pre-shared key, the AUTH 1350 value is computed as: 1352 AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), ) 1355 where the string "Key Pad for IKEv2" is 17 ASCII characters without 1356 null termination. The shared secret can be variable length. The pad 1357 string is added so that if the shared secret is derived from a 1358 password, the IKE implementation need not store the password in 1359 cleartext, but rather can store the value prf(Shared Secret,"Key Pad 1360 for IKEv2"), which could not be used as a password equivalent for 1361 protocols other than IKEv2. As noted above, deriving the shared 1362 secret from a password is not secure. This construction is used 1363 because it is anticipated that people will do it anyway. The 1364 management interface by which the Shared Secret is provided MUST 1365 accept ASCII strings of at least 64 octets and MUST NOT add a null 1366 terminator before using them as shared secrets. The management 1367 interface MAY accept other forms, like hex encoding. If the 1368 negotiated prf takes a fixed size key, the shared secret MUST be of 1369 that fixed size. 1371 2.16 Extended Authentication Protocol Methods 1373 In addition to authentication using public key signatures and shared 1374 secrets, IKE supports authentication using methods defined in RFC 1375 2284 [EAP]. Typically, these methods are asymmetric (designed for a 1376 user authenticating to a server), and they may not be mutual. For 1377 this reason, these protocols are typically used to authenticate the 1378 initiator to the responder and MUST be used in conjunction with a 1379 public key signature based authentication of the responder to the 1380 initiator. These methods are often associated with mechanisms 1381 referred to as "Legacy Authentication" mechanisms. 1383 While this memo references [EAP] with the intent that new methods can 1384 be added in the future without updating this specification, the 1385 protocols expected to be used most commonly are documented here and 1386 in section 3.16. [EAP] defines an authentication protocol requiring 1387 a variable number of messages. Extended Authentication is implemented 1388 in IKE as additional IKE_AUTH exchanges that MUST be completed in 1389 order to initialize the IKE_SA. 1391 An initiator indicates a desire to use extended authentication by 1392 leaving out the AUTH payload from message 3. By including an IDi 1393 payload but not an AUTH payload, the initiator has declared an 1394 identity but has not proven it. If the responder is willing to use an 1395 extended authentication method, it will place an EAP payload in 1396 message 4 and defer sending SAr2, TSi, and TSr until initiator 1397 authentication is complete in a subsequent IKE_AUTH exchange. In the 1398 case of a minimal extended authentication, the initial SA 1399 establishment will appear as follows: 1401 Initiator Responder 1402 ----------- ----------- 1403 HDR, SAi1, KEi, Ni --> 1405 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 1407 HDR, SK {IDi, [CERTREQ,] [IDr,] 1408 SAi2, TSi, TSr} --> 1410 <-- HDR, SK {IDr, [CERT,] AUTH, 1411 EAP } 1413 HDR, SK {EAP, AUTH} --> 1415 <-- HDR, SK {EAP, AUTH, 1416 SAr2, TSi, TSr } 1418 For EAP methods that create a shared key as a side effect of 1419 authentication, that shared key MUST be used by both the Initiator 1420 and Responder to generate AUTH payloads in messages 5 and 6 using the 1421 syntax for shared secrets specified in section 2.15. The shared key 1422 generated during an IKE exchange MUST NOT be used for any other 1423 purpose. 1425 EAP methods that do not establish a shared key SHOULD NOT be used, as 1426 they are subject to a number of man-in-the-middle attacks [EAPMITM] 1427 if these EAP methods are used in other protocols that do not use a 1428 server-authenticated tunnel. Please see the Security Considerations 1429 section for more details. If EAP methods that do not generate a 1430 shared key are used, the AUTH payloads in messages 5 and 6 MUST be 1431 generated using SK_ai and SK_ar respectively. 1433 The Initiator of an IKE_SA using EAP SHOULD be capable of extending 1434 the initial protocol exchange to at least ten IKE_AUTH exchanges in 1435 the event the Responder sends notification messages and/or retries 1436 the authentication prompt. The protocol terminates when the Responder 1437 sends the Initiator an EAP payload containing either a success or 1438 failure type. In such an extended exchange, the EAP AUTH payloads 1439 MUST be included in the first message each end sends after having 1440 sufficient information to compute the key. This will usually be in 1441 the last two messages of the exchange. 1443 2.17 Generating Keying Material for CHILD_SAs 1445 CHILD_SAs are created either by being piggybacked on the IKE_AUTH 1446 exchange, or in a CREATE_CHILD_SA exchange. Keying material for them 1447 is generated as follows: 1449 KEYMAT = prf+(SK_d, Ni | Nr) 1451 Where Ni and Nr are the Nonces from the IKE_SA_INIT exchange if this 1452 request is the first CHILD_SA created or the fresh Ni and Nr from the 1453 CREATE_CHILD_SA exchange if this is a subsequent creation. 1455 For CREATE_CHILD_SA exchanges with PFS the keying material is defined 1456 as: 1458 KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr ) 1460 where g^ir (new) is the shared secret from the ephemeral Diffie- 1461 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 1462 octet string in big endian order padded with zeros in the high order 1463 bits if necessary to make it the length of the modulus). 1465 A single CHILD_SA negotiation may result in multiple security 1466 associations. ESP and AH SAs exist in pairs (one in each direction), 1467 and four SAs could be created in a single CHILD_SA negotiation if a 1468 combination of ESP and AH is being negotiated. 1470 Keying material MUST be taken from the expanded KEYMAT in the 1471 following order: 1473 All keys for SAs carrying data from the initiator to the responder 1474 are taken before SAs going in the reverse direction. 1476 If multiple IPsec protocols are negotiated, keying material is 1477 taken in the order in which the protocol headers will appear in 1478 the encapsulated packet. 1480 If a single protocol has both encryption and authentication keys, 1481 the encryption key is taken from the first octets of KEYMAT and 1482 the authentication key is taken from the next octets. 1484 Each cryptographic algorithm takes a fixed number of bits of keying 1485 material specified as part of the algorithm. 1487 2.18 Rekeying IKE_SAs using a CREATE_CHILD_SA exchange 1489 The CREATE_CHILD_SA exchange can be used to rekey an existing IKE_SA 1490 (see section 2.8). New Initiator and Responder SPIs are supplied in 1491 the SPI fields. The TS payloads are omitted when rekeying an IKE_SA. 1492 SKEYSEED for the new IKE_SA is computed using SK_d from the existing 1493 IKE_SA as follows: 1495 SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr) 1497 where g^ir (new) is the shared secret from the ephemeral Diffie- 1498 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 1499 octet string in big endian order padded with zeros if necessary to 1500 make it the length of the modulus) and Ni and Nr are the two nonces 1501 stripped of any headers. 1503 The new IKE_SA MUST reset its message counters to 0. 1505 SK_d, SK_ai, SK_ar, and SK_ei, and SK_er are computed from SKEYSEED 1506 as specified in section 2.14. 1508 2.19 Requesting an internal address on a remote network 1510 Most commonly occurring in the endpoint to security gateway scenario, 1511 an endpoint may need an IP address in the network protected by the 1512 security gateway, and may need to have that address dynamically 1513 assigned. A request for such a temporary address can be included in 1514 any request to create a CHILD_SA (including the implicit request in 1515 message 3) by including a CP payload. 1517 This function provides address allocation to an IRAC (IPsec Remote 1518 Access Client) trying to tunnel into a network protected by an IRAS 1519 (IPsec Remote Access Server). Since the IKE_AUTH exchange creates an 1520 IKE_SA and a CHILD_SA, the IRAC MUST request the IRAS controlled 1521 address (and optionally other information concerning the protected 1522 network) in the IKE_AUTH exchange. The IRAS may procure an address 1523 for the IRAC from any number of sources such as a DHCP/BOOTP server 1524 or its own address pool. 1526 Initiator Responder 1527 ----------------------------- --------------------------- 1528 HDR, SK {IDi, [CERT,] [CERTREQ,] 1529 [IDr,] AUTH, CP(CFG_REQUEST), 1530 SAi2, TSi, TSr} --> 1532 <-- HDR, SK {IDr, [CERT,] AUTH, 1533 CP(CFG_REPLY), SAr2, 1534 TSi, TSr} 1536 In all cases, the CP payload MUST be inserted before the SA payload. 1537 In variations of the protocol where there are multiple IKE_AUTH 1538 exchanges, the CP payloads MUST be inserted in the messages 1539 containing the SA payloads. 1541 CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute 1542 (either IPv4 or IPv6) but MAY contain any number of additional 1543 attributes the initiator wants returned in the response. 1545 For example, message from Initiator to Responder: 1546 CP(CFG_REQUEST)= 1547 INTERNAL_ADDRESS(0.0.0.0) 1548 INTERNAL_NETMASK(0.0.0.0) 1549 INTERNAL_DNS(0.0.0.0) 1550 TSi = (0, 0-65536,0.0.0.0-255.255.255.255) 1551 TSr = (0, 0-65536,0.0.0.0-255.255.255.255) 1553 NOTE: Traffic Selectors contain (protocol, port range, address range) 1555 Message from Responder to Initiator: 1557 CP(CFG_REPLY)= 1558 INTERNAL_ADDRESS(10.168.219.202) 1559 INTERNAL_NETMASK(255.255.255.0) 1560 INTERNAL_SUBNET(10.168.219.0/255.255.255.0) 1561 TSi = (0, 0-65536,10.168.219.202-10.168.219.202) 1562 TSr = (0, 0-65536,10.168.219.0-10.168.219.255) 1564 All returned values will be implementation dependent. As can be seen 1565 in the above example, the IRAS MAY also send other attributes that 1566 were not included in CP(CFG_REQUEST) and MAY ignore the non- 1567 mandatory attributes that it does not support. 1569 The responder MUST NOT send a CFG_REPLY without having first received 1570 a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS 1571 to perform an unnecessary configuration lookup if the IRAC cannot 1572 process the REPLY. In the case where the IRAS's configuration 1573 requires that CP be used for a given identity IDi, but IRAC has 1574 failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and 1575 terminate the IKE exchange with a FAILED_CP_REQUIRED error. 1577 2.20 Requesting the Peer's Version 1579 An IKE peer wishing to inquire about the other peer's IKE software 1580 version information MAY use the method below. This is an example of 1581 a configuration request within an INFORMATIONAL Exchange, after the 1582 IKE_SA and first CHILD_SA have been created. 1584 An IKE implementation MAY decline to give out version information 1585 prior to authentication or even after authentication to prevent 1586 trolling in case some implementation is known to have some security 1587 weakness. In that case, it MUST either return an empty string or no 1588 CP payload if CP is not supported. 1590 Initiator Responder 1591 ----------------------------- -------------------------- 1592 HDR, SK{CP(CFG_REQUEST)} --> 1593 <-- HDR, SK{CP(CFG_REPLY)} 1595 CP(CFG_REQUEST)= 1596 APPLICATION_VERSION("") 1598 CP(CFG_REPLY) 1599 APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar Inc.") 1601 2.21 Error Handling 1603 There are many kinds of errors that can occur during IKE processing. 1604 If a request is received that is badly formatted or unacceptable for 1605 reasons of policy (e.g., no matching cryptographic algorithms), the 1606 response MUST contain a Notify payload indicating the error. If an 1607 error occurs outside the context of an IKE request (e.g., the node is 1608 getting ESP messages on a nonexistent SPI), the node SHOULD initiate 1609 an INFORMATIONAL Exchange with a Notify payload describing the 1610 problem. 1612 Errors that occur before a cryptographically protected IKE_SA is 1613 established must be handled very carefully. There is a trade-off 1614 between wanting to be helpful in diagnosing a problem and responding 1615 to it and wanting to avoid being a dupe in a denial of service attack 1616 based on forged messages. 1618 If a node receives a message on UDP port 500 outside the context of 1619 an IKE_SA known to it (and not a request to start one), it may be the 1620 result of a recent crash of the node. If the message is marked as a 1621 response, the node MAY audit the suspicious event but MUST NOT 1622 respond. If the message is marked as a request, the node MAY audit 1623 the suspicious event and MAY send a response. If a response is sent, 1624 the response MUST be sent to the IP address and port from whence it 1625 came with the same IKE SPIs and the Message ID copied. The response 1626 MUST NOT be cryptographically protected and MUST contain a Notify 1627 payload indicating INVALID_IKE_SPI. 1629 A node receiving such an unprotected Notify payload MUST NOT respond 1630 and MUST NOT change the state of any existing SAs. The message might 1631 be a forgery or might be a response the genuine correspondent was 1632 tricked into sending. A node SHOULD treat such a message (and also a 1633 network message like ICMP destination unreachable) as a hint that 1634 there might be problems with SAs to that IP address and SHOULD 1635 initiate a liveness test for any such IKE_SA. An implementation 1636 SHOULD limit the frequency of such tests to avoid being tricked into 1637 participating in a denial of service attack. 1639 A node receiving a suspicious message from an IP address with which 1640 it has an IKE_SA MAY send an IKE Notify payload in an IKE 1641 INFORMATIONAL exchange over that SA. The recipient MUST NOT change 1642 the state of any SA's as a result but SHOULD audit the event to aid 1643 in diagnosing malfunctions. A node MUST limit the rate at which it 1644 will send messages in response to unprotected messages. 1646 2.22 IPComp 1648 Use of IP compression [IPCOMP] can be negotiated as part of the setup 1649 of a CHILD_SA. While IP compression involves an extra header in each 1650 packet and a CPI (compression parameter index), the virtual 1651 "compression association" has no life outside the ESP or AH SA that 1652 contains it. Compression associations disappear when the 1653 corresponding ESP or AH SA goes away, and is not explicitly mentioned 1654 in any DELETE payload. 1656 Negotiation of IP compression is separate from the negotiation of 1657 cryptographic parameters associated with a CHILD_SA. A node 1658 requesting a CHILD_SA MAY advertise its support for one or more 1659 compression algorithms though one or more Notify payloads of type 1660 IPCOMP_SUPPORTED. The response MAY indicate acceptance of a single 1661 compression algorithm with a Notify payload of type IPCOMP_SUPPORTED. 1662 These payloads MUST NOT occur messages that do not contain SA 1663 payloads. 1665 While there has been discussion of allowing multiple compression 1666 algorithms to be accepted and to have different compression 1667 algorithms available for the two directions of a CHILD_SA, 1668 implementations of this specification MUST NOT accept an IPComp 1669 algorithm that was not proposed, MUST NOT accept more than one, and 1670 MUST NOT compress using an algorithm other than one proposed and 1671 accepted in the setup of the CHILD_SA. 1673 A side effect of separating the negotiation of IPComp from 1674 cryptographic parameters is that it is not possible to propose 1675 multiple cryptographic suites and propose IP compression with some of 1676 them but not others. 1678 2.23 NAT Traversal 1680 NAT (Network Address Translation) gateways are a controversial 1681 subject. This section briefly describes what they are and how they 1682 are likely to act on IKE traffic. Many people believe that NATs are 1683 evil and that we should not design our protocols so as to make them 1684 work better. IKEv2 does specify some unintuitive processing rules in 1685 order that NATs are more likely to work. 1687 NATs exist primarily because of the shortage of IPv4 addresses, 1688 though there are other rationales. IP nodes that are "behind" a NAT 1689 have IP addresses that are not globally unique, but rather are 1690 assigned from some space that is unique within the network behind the 1691 NAT but which are likely to be reused by nodes behind other NATs. 1692 Generally, nodes behind NATs can communicate with other nodes behind 1693 the same NAT and with nodes with globally unique addresses, but not 1694 with nodes behind other NATs. There are exceptions to that rule. 1695 When those nodes make connections to nodes on the real Internet, the 1696 NAT gateway "translates" the IP source address to an address that 1697 will be routed back to the gateway. Messages to the gateway from the 1698 Internet have their destination addresses "translated" to the 1699 internal address that will route the packet to the correct endnode. 1701 NATs are designed to be "transparent" to endnodes. Neither software 1702 on the node behind the NAT nor the node on the Internet require 1703 modification to communicate through the NAT. Achieving this 1704 transparency is more difficult with some protocols than with others. 1705 Protocols that include IP addresses of the endpoints within the 1706 payloads of the packet will fail unless the NAT gateway understands 1707 the protocol and modifies the internal references as well as those in 1708 the headers. Such knowledge is inherently unreliable, is a network 1709 layer violation, and often results in subtle problems. 1711 Opening an IPsec connection through a NAT introduces special 1712 problems. If the connection runs in transport mode, changing the IP 1713 addresses on packets will cause the checksums to fail and the NAT 1714 cannot correct the checksums because they are cryptographically 1715 protected. Even in tunnel mode, there are routing problems because 1716 transparently translating the addresses of AH and ESP packets 1717 requires special logic in the NAT and that logic is heuristic and 1718 unreliable in nature. For that reason, IKEv2 can negotiate UDP 1719 encapsulation of IKE, ESP, and AH packets. This encoding is slightly 1720 less efficient but is easier for NATs to process. In addition, 1721 firewalls may be configured to pass IPsec traffic over UDP but not 1722 ESP/AH or vice versa. 1724 It is a common practice of NATs to translate TCP and UDP port numbers 1725 as well as addresses and use the port numbers of inbound packets to 1726 decide which internal node should get a given packet. For this 1727 reason, even though IKE packets MUST be sent from and to UDP port 1728 500, they MUST be accepted coming from any port and responses MUST be 1729 sent to the port from whence they came. This is because the ports may 1730 be modified as the packets pass through NATs. Similarly, IP addresses 1731 of the IKE endpoints are generally not included in the IKE payloads 1732 because the payloads are cryptographically protected and could not be 1733 transparently modified by NATs. 1735 Port 4500 is reserved for UDP encapsulated ESP, AH, and IKE. When 1736 working through a NAT, it is generally better to pass IKE packets 1737 over port 4500 because some older NATs modify IKE traffic on port 500 1738 in an attempt to transparently establish IPsec connections. Such NATs 1739 may interfere with the straightforward NAT traversal envisioned by 1740 this document, so an IPsec endpoint that discovers a NAT between it 1741 and its correspondent MUST send all subsequent traffic to and from 1742 port 4500, which NATs should not treat specially (as they might with 1743 port 500). 1745 The specific requirements for supporting NAT traversal are listed 1746 below. Support for NAT traversal is optional. In this section only, 1747 requirements listed as MUST only apply to implementations supporting 1748 NAT traversal. 1750 IKE MUST listen on port 4500 as well as port 500. IKE MUST respond 1751 to the IP address and port from which packets arrived. 1753 Both IKE initiator and responder MUST include in their IKE_SA_INIT 1754 packets Notify payloads of type NAT_DETECTION_SOURCE_IP and 1755 NAT_DETECTION_DESTINATION_IP. Those payloads can be used to detect 1756 if there is NAT between the hosts, and which end is behind the 1757 NAT. The location of the payloads in the IKE_SA_INIT packets are 1758 just after the Ni and Nr payloads (before the optional CERTREQ 1759 payload). 1761 If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches 1762 the hash of the source IP and port found from the IP header of the 1763 packet containing the payload, it means that the the other end is 1764 behind NAT (i.e someone along the route changed the source address 1765 of the original packet to match the address of the NAT box). In 1766 this case this end should allow dynamic update of the other ends 1767 IP address, as described later. 1769 If the NAT_DETECTION_DESTINATION_IP payload received does not 1770 match the hash of the destination IP and port found from the IP 1771 header of the packet containing the payload, it means that this 1772 end is behind NAT (i.e the original sender sent the packet to 1773 address of the NAT box, which then changed the destination address 1774 to this host). In this case the this end should start sending 1775 keepalive packets as explaind in [Hutt02]. 1777 The IKE initiator MUST check these payloads if present and if they 1778 do not match the addresses in the outer packet MUST tunnel all 1779 future IKE, ESP, and AH packets associated with this IKE_SA over 1780 UDP port 4500. 1782 To tunnel IKE packets over UDP port 4500, the IKE header has four 1783 octets of zero prepended and the result immediately follows the 1784 UDP header. To tunnel ESP packets over UDP port 4500, the ESP 1785 header immediately follows the UDP header. Since the first four 1786 bytes of the ESP header contain the SPI, and the SPI cannot 1787 validly be zero, it is always possible to distinguish ESP and IKE 1788 messages. 1790 The original source and destination IP address required for the 1791 transport mode TCP and UDP packet checksum fixup (see [Hutt02]) 1792 are obtained from the Traffic Selectors associated with the 1793 exchange. In the case of NAT-T, the Traffic Selectors MUST contain 1794 exactly one IP address which is then used as the original IP 1795 address. 1797 There are cases where a NAT box decides to remove mappings that 1798 are still alive (for example, the keepalive interval is too long, 1799 or the NAT box is rebooted). To recover in these cases, hosts that 1800 are not behind a NAT SHOULD send all packets (including 1801 retranmission packets) to the IP address and port from the last 1802 valid authenticated packet from the other end (i.e dynamically 1803 update the address). A host behind a NAT SHOULD NOT do this 1804 because it opens a DoS attack possibility. Any authenticated IKE 1805 packet or any authenticated UDP encapsulated ESP packet can be 1806 used to detect that the IP address or the port has changed. 1808 Note that similar but probably not identical actions will likely 1809 be needed to make IKE work with Mobile IP, but such processing is 1810 not addressed by this document. 1812 2.24 ECN (Explicit Congestion Notification) 1814 When IPsec tunnels behave as originally specified in [RFC 2401], ECN 1815 usage is not appropriate for the outer IP headers because tunnel 1816 decapsulation processing discards ECN congestion indications to the 1817 detriment of the network. ECN support for IPsec tunnels for 1818 IKEv1-based IPsec requires multiple operating modes and negotiation 1819 (see RFC 3168]). IKEv2 simplifies this situation by requiring that 1820 ECN be usable in the outer IP headers of all tunnel-mode IPsec SAs 1821 created by IKEv2. Specifically, tunnel encapsulators and 1822 decapsulators for all tunnel-mode Security Associations (SAs) created 1823 by IKEv2 MUST support the ECN full-functionality option for tunnels 1824 specified in [RFC3168] and MUST implement the tunnel encapsulation 1825 and decapsulation processing specified in [RFC2401bis] to prevent 1826 discarding of ECN congestion indications. 1828 3 Header and Payload Formats 1830 3.1 The IKE Header 1832 IKE messages use UDP ports 500 and/or 4500, with one IKE message per 1833 UDP datagram. Information from the UDP header is largely ignored 1834 except that the IP addresses and UDP ports from the headers are 1835 reversed and used for return packets. When sent on UDP port 500, IKE 1836 messages begin immediately following the UDP header. When sent on UDP 1837 port 4500, IKE messages have prepended four octets of zero. These 1838 four octets of zero are not part of the IKE message and are not 1839 included in any of the length fields or checksums defined by IKE. 1840 Each IKE message begins with the IKE header, denoted HDR in this 1841 memo. Following the header are one or more IKE payloads each 1842 identified by a "Next Payload" field in the preceding payload. 1843 Payloads are processed in the order in which they appear in an IKE 1844 message by invoking the appropriate processing routine according to 1845 the "Next Payload" field in the IKE header and subsequently according 1846 to the "Next Payload" field in the IKE payload itself until a "Next 1847 Payload" field of zero indicates that no payloads follow. If a 1848 payload of type "Encrypted" is found, that payload is decrypted and 1849 its contents parsed as additional payloads. An Encrypted payload MUST 1850 be the last payload in a packet and an encrypted payload MUST NOT 1851 contain another encrypted payload. 1853 The Recipient SPI in the header identifies an instance of an IKE 1854 security association. It is therefore possible for a single instance 1855 of IKE to multiplex distinct sessions with multiple peers. 1857 All multi-octet fields representing integers are laid out in big 1858 endian order (aka most significant byte first, or network byte 1859 order). 1861 The format of the IKE header is shown in Figure 4. 1862 1 2 3 1863 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 1864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1865 ! IKE_SA Initiator's SPI ! 1866 ! ! 1867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1868 ! IKE_SA Responder's SPI ! 1869 ! ! 1870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1871 ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! 1872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1873 ! Message ID ! 1874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1875 ! Length ! 1876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1878 Figure 4: IKE Header Format 1880 o Initiator's SPI (8 octets) - A value chosen by the 1881 initiator to identify a unique IKE security association. This 1882 value MUST NOT be zero. 1884 o Responder's SPI (8 octets) - A value chosen by the 1885 responder to identify a unique IKE security association. This 1886 value MUST be zero in the first message of an IKE Initial 1887 Exchange (including repeats of that message including a 1888 cookie) and MUST NOT be zero in any other message. 1890 o Next Payload (1 octet) - Indicates the type of payload that 1891 immediately follows the header. The format and value of each 1892 payload is defined below. 1894 o Major Version (4 bits) - indicates the major version of the IKE 1895 protocol in use. Implementations based on this version of IKE 1896 MUST set the Major Version to 2. Implementations based on 1897 previous versions of IKE and ISAKMP MUST set the Major Version 1898 to 1. Implementations based on this version of IKE MUST reject 1899 or ignore messages containing a version number greater than 1900 2. 1902 o Minor Version (4 bits) - indicates the minor version of the 1903 IKE protocol in use. Implementations based on this version of 1904 IKE MUST set the Minor Version to 0. They MUST ignore the minor 1905 version number of received messages. 1907 o Exchange Type (1 octet) - indicates the type of exchange being 1908 used. This constrains the payloads sent in each message and 1909 orderings of messages in an exchange. 1911 Exchange Type Value 1913 RESERVED 0-33 1914 IKE_SA_INIT 34 1915 IKE_AUTH 35 1916 CREATE_CHILD_SA 36 1917 INFORMATIONAL 37 1918 Reserved for IKEv2+ 38-239 1919 Reserved for private use 240-255 1921 o Flags (1 octet) - indicates specific options that are set 1922 for the message. Presence of options are indicated by the 1923 appropriate bit in the flags field being set. The bits are 1924 defined LSB first, so bit 0 would be the least significant 1925 bit of the Flags octet. In the description below, a bit 1926 being 'set' means its value is '1', while 'cleared' means 1927 its value is '0'. 1929 -- X(reserved) (bits 0-2) - These bits MUST be cleared 1930 when sending and MUST be ignored on receipt. 1932 -- I(nitiator) (bit 3 of Flags) - This bit MUST be set in 1933 messages sent by the original Initiator of the IKE_SA 1934 and MUST be cleared in messages sent by the original 1935 Responder. It is used by the recipient to determine 1936 which eight octets of the SPI was generated by the 1937 recipient. 1939 -- V(ersion) (bit 4 of Flags) - This bit indicates that 1940 the transmitter is capable of speaking a higher major 1941 version number of the protocol than the one indicated 1942 in the major version number field. Implementations of 1943 IKEv2 must clear this bit when sending and MUST ignore 1944 it in incoming messages. 1946 -- R(esponse) (bit 5 of Flags) - This bit indicates that 1947 this message is a response to a message containing 1948 the same message ID. This bit MUST be cleared in all 1949 request messages and MUST be set in all responses. 1950 An IKE endpoint MUST NOT generate a response to a 1951 message that is marked as being a response. 1953 -- X(reserved) (bits 6-7 of Flags) - These bits MUST be 1954 cleared when sending and MUST be ignored on receipt. 1956 o Message ID (4 octets) - Message identifier used to control 1957 retransmission of lost packets and matching of requests and 1958 responses. It is essential to the security of the protocol 1959 because it is used to prevent message replay attacks. 1960 See sections 2.1 and 2.2. 1962 o Length (4 octets) - Length of total message (header + payloads) 1963 in octets. 1965 3.2 Generic Payload Header 1967 Each IKE payload defined in sections 3.3 through 3.16 begins with a 1968 generic payload header, shown in Figure 5. Figures for each payload 1969 below will include the generic payload header but for brevity the 1970 description of each field will be omitted. 1972 1 2 3 1973 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 1974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1975 ! Next Payload !C! RESERVED ! Payload Length ! 1976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1978 Figure 5: Generic Payload Header 1980 The Generic Payload Header fields are defined as follows: 1982 o Next Payload (1 octet) - Identifier for the payload type of the 1983 next payload in the message. If the current payload is the last 1984 in the message, then this field will be 0. This field provides 1985 a "chaining" capability whereby additional payloads can be 1986 added to a message by appending it to the end of the message 1987 and setting the "Next Payload" field of the preceding payload 1988 to indicate the new payload's type. An Encrypted payload, 1989 which must always be the last payload of a message, is an 1990 exception. It contains data structures in the format of 1991 additional payloads. In the header of an Encrypted payload, 1992 the Next Payload field is set to the payload type of the first 1993 contained payload (instead of 0). 1995 Payload Type Values 1997 Next Payload Type Notation Value 1999 No Next Payload 0 2001 RESERVED 1-32 2002 Security Association SA 33 2003 Key Exchange KE 34 2004 Identification - Initiator IDi 35 2005 Identification - Responder IDr 36 2006 Certificate CERT 37 2007 Certificate Request CERTREQ 38 2008 Authentication AUTH 39 2009 Nonce Ni, Nr 40 2010 Notify N 41 2011 Delete D 42 2012 Vendor ID V 43 2013 Traffic Selector - Initiator TSi 44 2014 Traffic Selector - Responder TSr 45 2015 Encrypted E 46 2016 Configuration CP 47 2017 Extended Authentication EAP 48 2018 RESERVED TO IANA 49-127 2019 PRIVATE USE 128-255 2021 Payload type values 1-32 should not be used so that there is no 2022 overlap with the code assignments for IKEv1. Payload type values 2023 49-127 are reserved to IANA for future assignment in IKEv2 (see 2024 section 6). Payload type values 128-255 are for private use among 2025 mutually consenting parties. 2027 o Critical (1 bit) - MUST be set to zero if the sender wants 2028 the recipient to skip this payload if he does not 2029 understand the payload type code in the Next Payload field 2030 of the previous payload. MUST be set to one if the 2031 sender wants the recipient to reject this entire message 2032 if he does not understand the payload type. MUST be ignored 2033 by the recipient if the recipient understands the payload type 2034 code. MUST be set to zero for payload types defined in this 2035 document. Note that the critical bit applies to the current 2036 payload rather than the "next" payload whose type code 2037 appears in the first octet. The reasoning behind not setting 2038 the critical bit for payloads defined in this document is 2039 that all implementations MUST understand all payload types 2040 defined in this document and therefore must ignore the 2041 Critical bit's value. Skipped payloads are expected to 2042 have valid Next Payload and Payload Length fields. 2044 o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on 2045 receipt. 2047 o Payload Length (2 octets) - Length in octets of the current 2048 payload, including the generic payload header. 2050 3.3 Security Association Payload 2052 The Security Association Payload, denoted SA in this memo, is used to 2053 negotiate attributes of a security association. Assembly of Security 2054 Association Payloads requires great peace of mind. An SA payload MAY 2055 contain multiple proposals. If there is more than one, they MUST be 2056 ordered from most preferred to least preferred. Each proposal may 2057 contain multiple IPsec protocols (where a protocol is IKE, ESP, or 2058 AH), each protocol MAY contain multiple transforms, and each 2059 transform MAY contain multiple attributes. When parsing an SA, an 2060 implementation MUST check that the total Payload Length is consistent 2061 with the payload's internal lengths and counts. Proposals, 2062 Transforms, and Attributes each have their own variable length 2063 encodings. They are nested such that the Payload Length of an SA 2064 includes the combined contents of the SA, Proposal, Transform, and 2065 Attribute information. The length of a Proposal includes the lengths 2066 of all Transforms and Attributes it contains. The length of a 2067 Transform includes the lengths of all Attributes it contains. 2069 The syntax of Security Associations, Proposals, Transforms, and 2070 Attributes is based on ISAKMP, however the semantics are somewhat 2071 different. The reason for the complexity and the hierarchy is to 2072 allow for multiple possible combinations of algorithms to be encoded 2073 in a single SA. Sometimes there is a choice of multiple algorithms, 2074 while other times there is a combination of algorithms. For example, 2075 an Initiator might want to propose using (AH w/MD5 and ESP w/3DES) OR 2076 (ESP w/MD5 and 3DES). 2078 One of the reasons the semantics of the SA payload has changed from 2079 ISAKMP and IKEv1 is to make the encodings more compact in common 2080 cases. 2082 The Proposal structure contains within it a Proposal # and an IPsec 2083 protocol ID. Each structure MUST have the same Proposal # as the 2084 previous one or be one (1) greater. The first Proposal MUST have a 2085 Proposal # of one (1). If two successive structures have the same 2086 Proposal number, it means that the proposal consists of the first 2087 structure AND the second. So a proposal of AH AND ESP would have two 2088 proposal structures, one for AH and one for ESP and both would have 2089 Proposal #1. A proposal of AH OR ESP would have two proposal 2090 structures, one for AH with proposal #1 and one for ESP with proposal 2091 #2. 2093 Each Proposal/Protocol structure is followed by one or more transform 2094 structures. The number of different transforms is generally 2095 determined by the Protocol. AH generally has a single transform: an 2096 integrity check algorithm. ESP generally has two: an encryption 2097 algorithm and an integrity check algorithm. IKE generally has four 2098 transforms: a Diffie-Hellman group, an integrity check algorithm, a 2099 prf algorithm, and an encryption algorithm. If an algorithm that 2100 combines encryption and integrity protection is proposed, it MUST be 2101 proposed as an encryption algorithm and an integrity protection 2102 algorithm MUST NOT be proposed. For each Protocol, the set of 2103 permissible transforms are assigned transform ID numbers, which 2104 appear in the header of each transform. 2106 If there are multiple transforms with the same Transform Type, the 2107 proposal is an OR of those transforms. If there are multiple 2108 Transforms with different Transform Types, the proposal is an AND of 2109 the different groups. For example, to propose ESP with (3DES or IDEA) 2110 and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two 2111 Transform Type 1 candidates (one for 3DES and one for IDEA) and two 2112 Transform Type 2 candidates (one for HMAC_MD5 and one for HMAC_SHA). 2113 This effectively proposes four combinations of algorithms. If the 2114 Initiator wanted to propose only a subset of those - say (3DES and 2115 HMAC_MD5) or (IDEA and HMAC_SHA), there is no way to encode that as 2116 multiple transforms within a single Proposal. Instead, the Initiator 2117 would have to construct two different Proposals, each with two 2118 transforms. 2120 A given transform MAY have one or more Attributes. Attributes are 2121 necessary when the transform can be used in more than one way, as 2122 when an encryption algorithm has a variable key size. The transform 2123 would specify the algorithm and the attribute would specify the key 2124 size. Most transforms do not have attributes. A transform MUST NOT 2125 have multiple attributes of the same type. To propose alternate 2126 values for an attribute (for example, multiple key sizes for the AES 2127 encryption algorithm), and implementation MUST include multiple 2128 Transorms with the same Transform Type each with a single Attribute. 2130 Note that the semantics of Transforms and Attributes are quite 2131 different than in IKEv1. In IKEv1, a single Transform carried 2132 multiple algorithms for a protocol with one carried in the Transform 2133 and the others carried in the Attributes. 2135 1 2 3 2136 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 2137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2138 ! Next Payload !C! RESERVED ! Payload Length ! 2139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2140 ! ! 2141 ~ ~ 2142 ! ! 2143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2145 Figure 6: Security Association Payload 2147 o Proposals (variable) - one or more proposal substructures. 2149 The payload type for the Security Association Payload is thirty 2150 three (33). 2152 3.3.1 Proposal Substructure 2154 1 2 3 2155 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 2156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2157 ! 0 (last) or 2 ! RESERVED ! Proposal Length ! 2158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2159 ! Proposal # ! Protocol ID ! SPI Size !# of Transforms! 2160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2161 ~ SPI (variable) ~ 2162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2163 ! ! 2164 ~ ~ 2165 ! ! 2166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2168 Figure 7: Proposal Substructure 2170 o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the 2171 last Proposal Substructure in the SA. This syntax is inherited 2172 from ISAKMP, but is unnecessary because the last Proposal 2173 could be identified from the length of the SA. The value (2) 2174 corresponds to a Payload Type of Proposal in IKEv1, and the 2175 first four octets of the Proposal structure are designed to 2176 look somewhat like the header of a Payload. 2178 o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on 2179 receipt. 2181 o Proposal Length (2 octets) - Length of this proposal, 2182 including all transforms and attributes that follow. 2184 o Proposal # (1 octet) - When a proposal is made, the first 2185 proposal in an SA MUST be #1, and subsequent proposals 2186 MUST either be the same as the previous proposal (indicating 2187 an AND of the two proposals) or one more than the previous 2188 proposal (indicating an OR of the two proposals). When a 2189 proposal is accepted, all of the proposal numbers in the 2190 SA MUST be the same and MUST match the number on the 2191 proposal sent that was accepted. 2193 o Protocol ID (1 octet) - Specifies the IPsec protocol 2194 identifier for the current negotiation. One (1) indicates 2195 IKE, two (2) indicates AH, and three (3) indicates ESP. 2197 o SPI Size (1 octet) - For an initial IKE_SA negotiation, 2198 this field MUST be zero; the SPI is obtained from the 2199 outer header. During subsequent negotiations, 2200 it is equal to the size, in octets, of the SPI of the 2201 corresponding protocol (8 for IKE, 4 for ESP and AH). 2203 o # of Transforms (1 octet) - Specifies the number of 2204 transforms in this proposal. 2206 o SPI (variable) - The sending entity's SPI. Even if the SPI 2207 Size is not a multiple of 4 octets, there is no padding 2208 applied to the payload. When the SPI Size field is zero, 2209 this field is not present in the Security Association 2210 payload. 2212 o Transforms (variable) - one or more transform substructures. 2214 3.3.2 Transform Substructure 2216 1 2 3 2217 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 2218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2219 ! 0 (last) or 3 ! RESERVED ! Transform Length ! 2220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2221 !Transform Type ! RESERVED ! Transform ID ! 2222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2223 ! ! 2224 ~ Transform Attributes ~ 2225 ! ! 2226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2228 Figure 8: Transform Substructure 2230 o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the 2231 last Transform Substructure in the Proposal. This syntax is 2232 inherited from ISAKMP, but is unnecessary because the last 2233 Proposal could be identified from the length of the SA. The 2234 value (3) corresponds to a Payload Type of Transform in IKEv1, 2235 and the first four octets of the Transform structure are 2236 designed to look somewhat like the header of a Payload. 2238 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 2240 o Transform Length - The length (in octets) of the Transform 2241 Substructure including Header and Attributes. 2243 o Transform Type (1 octet) - The type of transform being specified 2244 in this transform. Different protocols support different 2245 transform types. For some protocols, some of the transforms 2246 may be optional. If a transform is optional and the initiator 2247 wishes to propose that the transform be omitted, no transform 2248 of the given type is included in the proposal. If the 2249 initiator wishes to make use of the transform optional to 2250 the responder, she includes a transform substructure with 2251 transform ID = 0 as one of the options. 2253 o Transform ID (2 octets) - The specific instance of the transform 2254 type being proposed. 2256 Transform Type Values 2258 Transform Used In 2259 Type 2260 Encryption Algorithm 1 (IKE and ESP) 2261 Pseudo-random Function 2 (IKE) 2262 Integrity Algorithm 3 (IKE, AH, and optional in ESP) 2263 Diffie-Hellman Group 4 (IKE and optional in AH and ESP) 2264 Extended Sequence Numbers 5 (Optional in AH and ESP) 2266 values 6-240 are reserved to IANA. Values 241-255 are for 2267 private use among mutually consenting parties. 2269 For Transform Type 1 (Encryption Algorithm), defined Transform IDs 2270 are: 2272 Name Number Defined In 2273 RESERVED 0 2274 ENCR_DES_IV64 1 (RFC1827) 2275 ENCR_DES 2 (RFC2405) 2276 ENCR_3DES 3 (RFC2451) 2277 ENCR_RC5 4 (RFC2451) 2278 ENCR_IDEA 5 (RFC2451) 2279 ENCR_CAST 6 (RFC2451) 2280 ENCR_BLOWFISH 7 (RFC2451) 2281 ENCR_3IDEA 8 (RFC2451) 2282 ENCR_DES_IV32 9 2283 ENCR_RC4 10 2284 ENCR_NULL 11 (RFC2410) 2285 ENCR_AES_CBC 12 2286 ENCR_AES_CTR 13 2288 values 14-1023 are reserved to IANA. Values 1024-65535 are for 2289 private use among mutually consenting parties. 2291 For Transform Type 2 (Pseudo-random Function), defined Transform IDs 2292 are: 2294 Name Number Defined In 2295 RESERVED 0 2296 PRF_HMAC_MD5 1 (RFC2104) 2297 PRF_HMAC_SHA1 2 (RFC2104) 2298 PRF_HMAC_TIGER 3 (RFC2104) 2299 PRF_AES_CBC 4 2301 values 5-1023 are reserved to IANA. Values 1024-65535 are for 2302 private use among mutually consenting parties. 2304 For Transform Type 3 (Integrity Algorithm), defined Transform IDs 2305 are: 2307 Name Number Defined In 2308 NONE 0 2309 AUTH_HMAC_MD5_96 1 (RFC2403) 2310 AUTH_HMAC_SHA1_96 2 (RFC2404) 2311 AUTH_DES_MAC 3 2312 AUTH_KPDK_MD5 4 (RFC1826) 2313 AUTH_AES_XCBC_96 5 2315 values 6-1023 are reserved to IANA. Values 1024-65535 are for 2316 private use among mutually consenting parties. 2318 For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs 2319 are: 2321 Name Number 2322 NONE 0 2323 Defined in Appendix B 1 - 4 2324 Defined in [ADDGROUP] 5, 14 - 18 2325 values 6-13 and 19-1023 are reserved to IANA for new MODP, ECP 2326 or EC2N groups. Values 1024-65535 are for private use among 2327 mutually consenting parties. 2329 For Transform Type 5 (Extended Sequence Numbers), defined Transform 2330 IDs are: 2332 Name Number 2333 No Extended Sequence Numbers 0 2334 Extended Sequence Numbers 1 2335 RESERVED 2 - 65535 2337 If Transform Type 5 is not included in a proposal, use of 2338 Extended Sequence Numbers is assumed. 2340 3.3.3 Valid Transform Types by Protocol 2342 The number and type of transforms that accompany an SA payload are 2343 dependent on the protocol in the SA itself. An SA payload proposing 2344 the establishment of an SA has the following mandatory and optional 2345 transform types. A compliant implementation MUST understand all 2346 mandatory and optional types for each protocol it supports (though it 2347 need not accept proposals with unacceptable suites). A proposal MAY 2348 omit the optional types if the only value for them it will accept is 2349 NONE. 2351 Protocol Mandatory Types Optional Types 2352 IKE ENCR, PRF, INTEG, D-H 2353 ESP ENCR INTEG, D-H, ESN 2354 AH INTEG D-H, ESN 2356 3.3.4 Mandatory Transform IDs 2358 The specification of suites that MUST and SHOULD be supported for 2359 interoperability has been removed from this document because they are 2360 likely to change more rapidly than this document evolves. 2362 An important lesson learned from IKEv1 is that no system should only 2363 implement the mandatory algorithms and expect them to be the best 2364 choice for all customers. For example, at the time that this document 2365 was being written, many IKEv1 implementers are starting to migrate to 2366 AES in CBC mode for VPN applications. Many IPsec systems based on 2367 IKEv2 will implement AES, longer Diffie-Hellman keys, and additional 2368 hash algorithms, and some IPsec customers already require these 2369 algorithms in addition to the ones listed above. 2371 It is likely that IANA will add additional transforms in the future, 2372 and some users may want to use private suites, especially for IKE 2373 where implementations should be capable of supporting different 2374 parameters, up to certain size limits. In support of this goal, all 2375 implementations of IKEv2 SHOULD include a management facility that 2376 allows specification (by a user or system administrator) of Diffie- 2377 Hellman parameters (the generator, modulus, and exponent lengths and 2378 values) for new DH groups. Implementations SHOULD provide a 2379 management interface via which these parameters and the associated 2380 transform IDs may be entered (by a user or system administrator), to 2381 enable negotiating such groups. 2383 All implementations of IKEv2 MUST include a management facility that 2384 enables a user or system administrator to specify the suites that are 2385 acceptable for use with IKE. Upon receipt of a payload with a set of 2386 transform IDs, the implementation MUST compare the transmitted 2387 transform IDs against those locally configured via the management 2388 controls, to verify that the proposed suite is acceptable based on 2389 local policy. The implementation MUST reject SA proposals that are 2390 not authorized by these IKE suite controls. 2392 3.3.5 Transform Attributes 2394 Each transform in a Security Association payload may include 2395 attributes that modify or complete the specification of the 2396 transform. These attributes are type/value pairs and are defined 2397 below. For example, if an encryption algorithm has a variable length 2398 key, the key length to be used may be specified as an attribute. 2399 Attributes can have a value with a fixed two octet length or a 2400 variable length value. For the latter, the attribute is encoded as 2401 type/length/value. 2403 1 2 3 2404 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 2405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2406 !A! Attribute Type ! AF=0 Attribute Length ! 2407 !F! ! AF=1 Attribute Value ! 2408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2409 ! AF=0 Attribute Value ! 2410 ! AF=1 Not Transmitted ! 2411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2413 Figure 9: Data Attributes 2415 o Attribute Type (2 octets) - Unique identifier for each type of 2416 attribute (see below). 2418 The most significant bit of this field is the Attribute Format 2419 bit (AF). It indicates whether the data attributes follow the 2420 Type/Length/Value (TLV) format or a shortened Type/Value (TV) 2421 format. If the AF bit is zero (0), then the Data Attributes 2422 are of the Type/Length/Value (TLV) form. If the AF bit is a 2423 one (1), then the Data Attributes are of the Type/Value form. 2425 o Attribute Length (2 octets) - Length in octets of the Attribute 2426 Value. When the AF bit is a one (1), the Attribute Value is 2427 only 2 octets and the Attribute Length field is not present. 2429 o Attribute Value (variable length) - Value of the Attribute 2430 associated with the Attribute Type. If the AF bit is a 2431 zero (0), this field has a variable length defined by the 2432 Attribute Length field. If the AF bit is a one (1), the 2433 Attribute Value has a length of 2 octets. 2435 Note that only a single attribute type (Key Length) is defined, and 2436 it is fixed length. The variable length encoding specification is 2437 included only for future extensions. The only algorithms defined in 2438 this document that accept attributes are the AES based encryption, 2439 integrity, and pseudo-random functions, which require a single 2440 attribute specifying key width. 2442 Attributes described as basic MUST NOT be encoded using the variable 2443 length encoding. Variable length attributes MUST NOT be encoded as 2444 basic even if their value can fit into two octets. NOTE: This is a 2445 change from IKEv1, where increased flexibility may have simplified 2446 the composer of messages but certainly complicated the parser. 2448 Attribute Type value Attribute Format 2449 -------------------------------------------------------------- 2450 RESERVED 0-13 2451 Key Length (in bits) 14 TV 2452 RESERVED 15-17 2453 RESERVED TO IANA 18-16383 2454 PRIVATE USE 16384-32767 2456 Values 0-13 and 15-17 were used in a similar context in IKEv1, and 2457 should not be assigned except to matching values. Values 18-16383 are 2458 reserved to IANA. Values 16384-32767 are for private use among 2459 mutually consenting parties. 2461 - Key Length 2463 When using an Encryption Algorithm that has a variable length key, 2464 this attribute specifies the key length in bits. (MUST use network 2465 byte order). This attribute MUST NOT be used when the specified 2466 Encryption Algorithm uses a fixed length key. 2468 3.3.6 Attribute Negotiation 2470 During security association negotiation Initiators present offers to 2471 Responders. Responders MUST select a single complete set of 2472 parameters from the offers (or reject all offers if none are 2473 acceptable). If there are multiple proposals, the Responder MUST 2474 choose a single proposal number and return all of the Proposal 2475 substructures with that Proposal number. If there are multiple 2476 Transforms with the same type the Responder MUST choose a single one. 2477 Any attributes of a selected transform MUST be returned unmodified. 2478 The Initiator of an exchange MUST check that the accepted offer is 2479 consistent with one of its proposals, and if not that response MUST 2480 be rejected. 2482 Negotiating Diffie-Hellman groups presents some special challenges. 2484 SA offers include proposed attributes and a Diffie-Hellman public 2485 number (KE) in the same message. If in the initial exchange the 2486 Initiator offers to use one of several Diffie-Hellman groups, it 2487 SHOULD pick the one the Responder is most likely to accept and 2488 include a KE corresponding to that group. If the guess turns out to 2489 be wrong, the Responder will indicate the correct group in the 2490 response and the Initiator SHOULD pick an element of that group for 2491 its KE value when retrying the first message. It SHOULD, however, 2492 continue to propose its full supported set of groups in order to 2493 prevent a man in the middle downgrade attack. 2495 Implementation Note: 2497 Certain negotiable attributes can have ranges or could have 2498 multiple acceptable values. These include the key length of a 2499 variable key length symmetric cipher. To further interoperability 2500 and to support upgrading endpoints independently, implementers of 2501 this protocol SHOULD accept values which they deem to supply 2502 greater security. For instance if a peer is configured to accept a 2503 variable lengthed cipher with a key length of X bits and is 2504 offered that cipher with a larger key length, the implementation 2505 SHOULD accept the offer if it supports use of the longer key. 2507 Support of this capability allows an implementation to express a 2508 concept of "at least" a certain level of security-- "a key length of 2509 _at least_ X bits for cipher Y". 2511 3.4 Key Exchange Payload 2513 The Key Exchange Payload, denoted KE in this memo, is used to 2514 exchange Diffie-Hellman public numbers as part of a Diffie-Hellman 2515 key exchange. The Key Exchange Payload consists of the IKE generic 2516 payload header followed by the Diffie-Hellman public value itself. 2518 1 2 3 2519 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 2520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2521 ! Next Payload !C! RESERVED ! Payload Length ! 2522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2523 ! DH Group # ! RESERVED ! 2524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2525 ! ! 2526 ~ Key Exchange Data ~ 2527 ! ! 2528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2530 Figure 10: Key Exchange Payload Format 2532 A key exchange payload is constructed by copying one's Diffie-Hellman 2533 public value into the "Key Exchange Data" portion of the payload. 2534 The length of the Diffie-Hellman public value MUST be equal to the 2535 length of the prime modulus over which the exponentiation was 2536 performed, prepending zero bits to the value if necessary. 2538 The DH Group # identifies the Diffie-Hellman group in which the Key 2539 Exchange Data was computed (see section 3.3.2). If the selected 2540 proposal uses a different Diffie-Hellman group, the message MUST be 2541 rejected with a Notify payload of type INVALID_KE_PAYLOAD. 2543 The payload type for the Key Exchange payload is thirty four (34). 2545 3.5 Identification Payloads 2547 The Identification Payloads, denoted IDi and IDr in this memo, allow 2548 peers to assert an identity to one another. This identity may be used 2549 for policy lookup, but does not necessarily have to match anything in 2550 the CERT payload; both fields may be used by an implementation to 2551 perform access control decisions. 2553 NOTE: In IKEv1, two ID payloads were used in each direction to hold 2554 Traffic Selector information for data passing over the SA. In IKEv2, 2555 this information is carried in Traffic Selector (TS) payloads (see 2556 section 3.13). 2558 The Identification Payload consists of the IKE generic payload header 2559 followed by identification fields as follows: 2561 1 2 3 2562 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 2563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2564 ! Next Payload !C! RESERVED ! Payload Length ! 2565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2566 ! ID Type ! RESERVED | 2567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2568 ! ! 2569 ~ Identification Data ~ 2570 ! ! 2571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2573 Figure 11: Identification Payload Format 2575 o ID Type (1 octet) - Specifies the type of Identification being 2576 used. 2578 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 2580 o Identification Data (variable length) - Value, as indicated by 2581 the Identification Type. The length of the Identification Data 2582 is computed from the size in the ID payload header. 2584 The payload types for the Identification Payload are thirty five (35) 2585 for IDi and thirty six (36) for IDr. 2587 The following table lists the assigned values for the Identification 2588 Type field, followed by a description of the Identification Data 2589 which follows: 2591 ID Type Value 2592 ------- ----- 2593 RESERVED 0 2595 ID_IPV4_ADDR 1 2597 A single four (4) octet IPv4 address. 2599 ID_FQDN 2 2601 A fully-qualified domain name string. An example of a 2602 ID_FQDN is, "example.com". The string MUST not contain any 2603 terminators (e.g., NULL, CR, etc.). 2605 ID_RFC822_ADDR 3 2607 A fully-qualified RFC822 email address string, An example of 2608 a ID_RFC822_ADDR is, "jsmith@example.com". The string MUST 2609 not contain any terminators. 2611 ID_IPV6_ADDR 5 2613 A single sixteen (16) octet IPv6 address. 2615 ID_DER_ASN1_DN 9 2617 The binary DER encoding of an ASN.1 X.500 Distinguished Name 2618 [X.501]. 2620 ID_DER_ASN1_GN 10 2622 The binary DER encoding of an ASN.1 X.500 GeneralName 2623 [X.509]. 2625 ID_KEY_ID 11 2627 An opaque octet stream which may be used to pass an account 2628 name or to pass vendor-specific information necessary to do 2629 certain proprietary types of identification. 2631 Reserved to IANA 12-200 2633 Reserved for private use 201-255 2635 Two implementations will interoperate only if each can generate a 2636 type of ID acceptable to the other. To assure maximum 2637 interoperability, implementations MUST be configurable to send at 2638 least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and 2639 MUST be configurable to accept all of these types. Implementations 2640 SHOULD be capable of generating and accepting all of these types. 2642 3.6 Certificate Payload 2644 The Certificate Payload, denoted CERT in this memo, provides a means 2645 to transport certificates or other authentication related information 2646 via IKE. Certificate payloads SHOULD be included in an exchange if 2647 certificates are available to the sender unless the peer has 2648 indicated an ability to retrieve this information from elsewhere 2649 using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note that the 2650 term "Certificate Payload" is somewhat misleading, because not all 2651 authentication mechanisms use certificates and data other than 2652 certificates may be passed in this payload. 2654 The Certificate Payload is defined as follows: 2656 1 2 3 2657 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 2658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2659 ! Next Payload !C! RESERVED ! Payload Length ! 2660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2661 ! Cert Encoding ! ! 2662 +-+-+-+-+-+-+-+-+ ! 2663 ~ Certificate Data ~ 2664 ! ! 2665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2667 Figure 12: Certificate Payload Format 2669 o Certificate Encoding (1 octet) - This field indicates the type 2670 of certificate or certificate-related information contained 2671 in the Certificate Data field. 2673 Certificate Encoding Value 2674 -------------------- ----- 2675 RESERVED 0 2676 PKCS #7 wrapped X.509 certificate 1 2677 PGP Certificate 2 2678 DNS Signed Key 3 2679 X.509 Certificate - Signature 4 2680 Kerberos Token 6 2681 Certificate Revocation List (CRL) 7 2682 Authority Revocation List (ARL) 8 2683 SPKI Certificate 9 2684 X.509 Certificate - Attribute 10 2685 Raw RSA Key 11 2686 Hash and URL of X.509 certificate 12 2687 Hash and URL of X.509 bundle 13 2688 RESERVED to IANA 14 - 200 2689 PRIVATE USE 201 - 255 2691 o Certificate Data (variable length) - Actual encoding of 2692 certificate data. The type of certificate is indicated 2693 by the Certificate Encoding field. 2695 The payload type for the Certificate Payload is thirty seven (37). 2697 Specific syntax is for some of the certificate type codes above is 2698 not defined in this document. The types whose syntax is defined in 2699 this document are: 2701 X.509 Certificate - Signature (4) contains a BER encoded X.509 2702 certificate whose public key is used to validate the sender's AUTH 2703 payload. 2705 Certificate Revocation List (7) contains a BER encoded X.509 2706 certificate revocation list. 2708 Raw RSA Key (11) contains a PKCS #1 encoded RSA key. 2710 Hash and URL encodings (12-13) allow IKE messages to remain short 2711 by replacing long data structures with a 20 octet SHA-1 hash of 2712 the replaced value followed by a variable length URL that resolves 2713 to the BER encoded data structure itself. This improves efficiency 2714 when the endpoints have certificate data cached and makes IKE less 2715 subject to denial of service attacks that become easier to mount 2716 when IKE messages are large enough to require IP fragmentation 2717 [KPS03]. 2719 Use the following ASN.1 definition for an X.509 bundle: 2721 CertBundle 2722 { iso(1) identified-organization(3) dod(6) internet(1) 2723 security(5) mechanisms(5) pkix(7) id-mod(0) 2724 id-mod-cert-bundle(TBD) } 2726 DEFINITIONS EXPLICIT TAGS ::= 2727 BEGIN 2729 IMPORTS 2730 Certificate, CertificateList 2731 FROM PKIX1Explicit88 2732 { iso(1) identified-organization(3) dod(6) 2733 internet(1) security(5) mechanisms(5) pkix(7) 2734 id-mod(0) id-pkix1-explicit(18) } ; 2736 CertificateOrCRL ::= CHOICE { 2737 cert [0] Certificate, 2738 crl [1] CertificateList } 2740 CertificateBundle ::= SEQUENCE OF CertificateOrCRL 2742 END 2744 Implementations MUST be capable of being configured to send and 2745 accept up to four X.509 certificates in support of authentication. 2746 Implementations SHOULD be capable of being configured to send and 2747 accept Raw RSA keys and the first two Hash and URL formats. If 2748 multiple certificates are sent, the first certificate MUST contain 2749 the public key used to sign the AUTH payload. The other certificates 2750 may be sent in any order. 2752 3.7 Certificate Request Payload 2754 The Certificate Request Payload, denoted CERTREQ in this memo, 2755 provides a means to request preferred certificates via IKE and can 2756 appear in the IKE_INIT_SA response and/or the IKE_AUTH request. 2757 Certificate Request payloads MAY be included in an exchange when the 2758 sender needs to get the certificate of the receiver. If multiple CAs 2759 are trusted and the cert encoding does not allow a list, then 2760 multiple Certificate Request payloads SHOULD be transmitted. 2762 The Certificate Request Payload is defined as follows: 2764 1 2 3 2765 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 2766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2767 ! Next Payload !C! RESERVED ! Payload Length ! 2768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2769 ! Cert Encoding ! ! 2770 +-+-+-+-+-+-+-+-+ ! 2771 ~ Certification Authority ~ 2772 ! ! 2773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2775 Figure 13: Certificate Request Payload Format 2777 o Certificate Encoding (1 octet) - Contains an encoding of the type 2778 or format of certificate requested. Values are listed in section 2779 3.6. 2781 o Certification Authority (variable length) - Contains an encoding 2782 of an acceptable certification authority for the type of 2783 certificate requested. 2785 The payload type for the Certificate Request Payload is thirty eight 2786 (38). 2788 The Certificate Encoding field has the same values as those defined 2789 in section 3.6. The Certification Authority field contains an 2790 indicator of trusted authorities for this certificate type. The 2791 Certification Authority value is a concatenated list of SHA-1 hashes 2792 of the public keys of trusted CAs. Each is encoded as the SHA-1 hash 2793 of the Subject Public Key Info element (see section 4.1.2.7 of [RFC 2794 3280]) from each Trust Anchor certificate. The twenty-octet hashes 2795 are concatenated and included with no other formatting. 2797 Note that the term "Certificate Request" is somewhat misleading, in 2798 that values other than certificates are defined in a "Certificate" 2799 payload and requests for those values can be present in a Certificate 2800 Request Payload. The syntax of the Certificate Request payload in 2801 such cases is not defined in this document. 2803 The Certificate Request Payload is processed by inspecting the "Cert 2804 Encoding" field to determine whether the processor has any 2805 certificates of this type. If so the "Certification Authority" field 2806 is inspected to determine if the processor has any certificates which 2807 can be validated up to one of the specified certification 2808 authorities. This can be a chain of certificates. If a certificate 2809 exists which satisfies the criteria specified in the Certificate 2810 Request Payload, the certificate MUST be sent back to the certificate 2811 requestor; if a certificate chain exists which goes back to the 2812 certification authority specified in the request the entire chain 2813 SHOULD be sent back to the certificate requestor. If multiple 2814 certificates or chains exist that satisfy the request, the sender 2815 MUST pick one. If no certificates exist then the Certificate Request 2816 Payload is ignored. This is not an error condition of the protocol. 2817 There may be cases where there is a preferred CA, but an alternate 2818 might be acceptable (perhaps after prompting a human operator). 2820 3.8 Authentication Payload 2822 The Authentication Payload, denoted AUTH in this memo, contains data 2823 used for authentication purposes. The syntax of the Authentication 2824 data varies according to the Auth Method as specified below. 2826 The Authentication Payload is defined as follows: 2828 1 2 3 2829 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 2830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2831 ! Next Payload !C! RESERVED ! Payload Length ! 2832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2833 ! Auth Method ! RESERVED ! 2834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2835 ! ! 2836 ~ Authentication Data ~ 2837 ! ! 2838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2840 Figure 14: Authentication Payload Format 2842 o Auth Method (1 octet) - Specifies the method of authentication 2843 used. Values defined are: 2845 RSA Digital Signature (1) - Computed as specified in section 2846 2.15 using an RSA private key over a PKCS#1 padded hash. 2848 Shared Key Message Integrity Code (2) - Computed as specified in 2849 section 2.15 using the shared key associated with the identity 2850 in the ID payload and the negotiated prf function 2852 DSS Digital Signature (3) - Computed as specified in section 2853 2.15 using a DSS private key over a SHA-1 hash. 2855 The values 0 and 4-200 are reserved to IANA. The values 201-255 2856 are available for private use. 2858 o Authentication Data (variable length) - see section 2.15. 2860 The payload type for the Authentication Payload is thirty nine (39). 2862 3.9 Nonce Payload 2864 The Nonce Payload, denoted Ni and Nr in this memo for the Initiator's 2865 and Responder's nonce respectively, contains random data used to 2866 guarantee liveness during an exchange and protect against replay 2867 attacks. 2869 The Nonce Payload is defined as follows: 2871 1 2 3 2872 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 2873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2874 ! Next Payload !C! RESERVED ! Payload Length ! 2875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2876 ! ! 2877 ~ Nonce Data ~ 2878 ! ! 2879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2881 Figure 15: Nonce Payload Format 2883 o Nonce Data (variable length) - Contains the random data generated 2884 by the transmitting entity. 2886 The payload type for the Nonce Payload is forty (40). 2888 The size of a Nonce MUST be between 16 and 256 octets inclusive. 2889 Nonce values MUST NOT be reused. 2891 3.10 Notify Payload 2893 The Notify Payload, denoted N in this document, is used to transmit 2894 informational data, such as error conditions and state transitions, 2895 to an IKE peer. A Notify Payload may appear in a response message 2896 (usually specifying why a request was rejected), in an INFORMATIONAL 2897 Exchange (to report an error not in an IKE request), or in any other 2898 message to indicate sender capabilities or to modify the meaning of 2899 the request. 2901 The Notify Payload is defined as follows: 2903 1 2 3 2904 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 2905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2906 ! Next Payload !C! RESERVED ! Payload Length ! 2907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2908 ! Protocol ID ! SPI Size ! Notify Message Type ! 2909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2910 ! ! 2911 ~ Security Parameter Index (SPI) ~ 2912 ! ! 2913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2914 ! ! 2915 ~ Notification Data ~ 2916 ! ! 2917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2919 Figure 16: Notification Payload Format 2921 o Protocol ID (1 octet) - If this notification concerns 2922 an existing SA, this field indicates the type of that SA. 2923 For IKE_SA notifications, this field MUST be one (1). For 2924 notifications concerning IPsec SAs this field MUST contain 2925 either (2) to indicate AH or (3) to indicate ESP. For 2926 notifications which do not relate to an existing SA, this 2927 field MUST be sent as zero and MUST be ignored on receipt. 2928 All other values for this field are reserved to IANA for future 2929 assignment. 2931 o SPI Size (1 octet) - Length in octets of the SPI as defined by 2932 the IPsec protocol ID or zero if no SPI is applicable. For a 2933 notification concerning the IKE_SA, the SPI Size MUST be zero. 2935 o Notify Message Type (2 octets) - Specifies the type of 2936 notification message. 2938 o SPI (variable length) - Security Parameter Index. 2940 o Notification Data (variable length) - Informational or error data 2941 transmitted in addition to the Notify Message Type. Values for 2942 this field are type specific (see below). 2944 The payload type for the Notification Payload is forty one (41). 2946 3.10.1 Notify Message Types 2948 Notification information can be error messages specifying why an SA 2949 could not be established. It can also be status data that a process 2950 managing an SA database wishes to communicate with a peer process. 2951 The table below lists the Notification messages and their 2952 corresponding values. The number of different error statuses was 2953 greatly reduced from IKE V1 both for simplification and to avoid 2954 giving configuration information to probers. 2956 Types in the range 0 - 16383 are intended for reporting errors. An 2957 implementation receiving a Notify payload with one of these types 2958 that it does not recognize in a response MUST assume that the 2959 corresponding request has failed entirely. Unrecognized error types 2960 in a request and status types in a request or response MUST be 2961 ignored except that they SHOULD be logged. 2963 Notify payloads with status types MAY be added to any message and 2964 MUST be ignored if not recognized. They are intended to indicate 2965 capabilities, and as part of SA negotiation are used to negotiate 2966 non-cryptographic parameters. 2968 NOTIFY MESSAGES - ERROR TYPES Value 2969 ----------------------------- ----- 2970 UNSUPPORTED_CRITICAL_PAYLOAD 1 2972 Sent if the payload has the "critical" bit set and the 2973 payload type is not recognized. Notification Data contains 2974 the one octet payload type. 2976 INVALID_IKE_SPI 4 2978 Indicates an IKE message was received with an unrecognized 2979 destination SPI. This usually indicates that the recipient 2980 has rebooted and forgotten the existence of an IKE_SA. 2982 INVALID_MAJOR_VERSION 5 2984 Indicates the recipient cannot handle the version of IKE 2985 specified in the header. The closest version number that the 2986 recipient can support will be in the reply header. 2988 INVALID_SYNTAX 7 2990 Indicates the IKE message was received was invalid because 2991 some type, length, or value was out of range or because the 2992 request was rejected for policy reasons. To avoid a denial 2993 of service attack using forged messages, this status may 2994 only be returned for and in an encrypted packet if the 2995 message ID and cryptographic checksum were valid. To avoid 2996 leaking information to someone probing a node, this status 2997 MUST be sent in response to any error not covered by one of 2998 the other status types. To aid debugging, more detailed 2999 error information SHOULD be written to a console or log. 3001 INVALID_MESSAGE_ID 9 3003 Sent when an IKE message ID outside the supported window is 3004 received. This Notify MUST NOT be sent in a response; the 3005 invalid request MUST NOT be acknowledged. Instead, inform 3006 the other side by initiating an INFORMATIONAL exchange with 3007 Notification data containing the four octet invalid message 3008 ID. Sending this notification is optional and notifications 3009 of this type MUST be rate limited. 3011 INVALID_SPI 11 3013 MAY be sent in an IKE INFORMATIONAL Exchange when a node 3014 receives an ESP or AH packet with an invalid SPI. The 3015 Notification Data contains the SPI of the invalid packet. 3016 This usually indicates a node has rebooted and forgotten an 3017 SA. If this Informational Message is sent outside the 3018 context of an IKE_SA, it should only be used by the 3019 recipient as a "hint" that something might be wrong (because 3020 it could easily be forged). 3022 NO_PROPOSAL_CHOSEN 14 3024 None of the proposed crypto suites was acceptable. 3026 INVALID_KE_PAYLOAD 17 3028 The D-H Group # field in the KE payload is not the group # 3029 selected by the responder for this exchange. There are two 3030 octets of data associated with this notification: the 3031 accepted D-H Group # in big endian order. 3033 AUTHENTICATION_FAILED 24 3035 Sent in the response to an IKE_AUTH message when for some 3036 reason the authentication failed. There is no associated 3037 data. 3039 SINGLE_PAIR_REQUIRED 34 3041 This error indicates that a CREATE_CHILD_SA request is 3042 unacceptable because its sender is only willing to accept 3043 traffic selectors specifying a single pair of addresses. 3044 The requestor is expected to respond by requesting an SA for 3045 only the specific traffic he is trying to forward. 3047 NO_ADDITIONAL_SAS 35 3049 This error indicates that a CREATE_CHILD_SA request is 3050 unacceptable because the Responder is unwilling to accept 3051 any more CHILD_SAs on this IKE_SA. Some minimal 3052 implementations may only accept a single CHILD_SA setup in 3053 the context of an initial IKE exchange and reject any 3054 subsequent attempts to add more. 3056 INTERNAL_ADDRESS_FAILURE 36 3058 Indicates an error assigning an internal address (i.e., 3059 INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS) during the 3060 processing of a Configuration Payload by a Responder. If 3061 this error is generated within an IKE_AUTH exchange no 3062 CHILD_SA will be created. 3064 FAILED_CP_REQUIRED 37 3066 Sent by responder in the case where CP(CFG_REQUEST) was 3067 expected but not received, and so is a conflict with locally 3068 configured policy. There is no associated data. 3070 TS_UNACCEPTABLE 38 3072 Indicates that none of the addresses/protocols/ports in the 3073 supplied traffic selectors is acceptable. 3075 INVALID_SELECTORS 39 3077 MAY be sent in an IKE INFORMATIONAL Exchange when a node 3078 receives an ESP or AH packet whose selectors do not match 3079 those of the SA on which it was delivered (and which caused 3080 the packet to be dropped). The Notification Data contains 3081 the start of the offending packet (as in ICMP messages) and 3082 the SPI field of the notification is set to match the SPI of 3083 the IPsec SA. 3084 RESERVED TO IANA - Error types 39 - 8191 3086 Private Use - Errors 8192 - 16383 3087 NOTIFY MESSAGES - STATUS TYPES Value 3088 ------------------------------ ----- 3090 INITIAL_CONTACT 16384 3092 This notification asserts that this IKE_SA is the only 3093 IKE_SA currently active between the authenticated 3094 identities. It MAY be sent when an IKE_SA is established 3095 after a crash, and the recipient MAY use this information to 3096 delete any other IKE_SAs it has to the same authenticated 3097 identity without waiting for a timeout. This notification 3098 MUST NOT be sent by an entity that may be replicated (e.g., 3099 a roaming user's credentials where the user is allowed to 3100 connect to the corporate firewall from two remote systems at 3101 the same time). 3103 SET_WINDOW_SIZE 16385 3105 This notification asserts that the sending endpoint is 3106 capable of keeping state for multiple outstanding exchanges, 3107 permitting the recipient to send multiple requests before 3108 getting a response to the first. The data associated with a 3109 SET_WINDOW_SIZE notification MUST be 4 octets long and 3110 contain the big endian representation of the number of 3111 messages the sender promises to keep. Window size is always 3112 one until the initial exchanges complete. 3114 ADDITIONAL_TS_POSSIBLE 16386 3116 This notification asserts that the sending endpoint narrowed 3117 the proposed traffic selectors but that other traffic 3118 selectors would also have been acceptable, though only in a 3119 separate SA (see section 2.9). There is no data associated 3120 with this Notify type. It may only be sent as an additional 3121 payload in a message including accepted TSs. 3123 IPCOMP_SUPPORTED 16387 3125 This notification may only be included in a message 3126 containing an SA payload negotiating a CHILD_SA and 3127 indicates a willingness by its sender to use IPComp on this 3128 SA. The data associated with this notification includes a 3129 two octet IPComp CPI followed by a one octet transform ID 3130 optionally followed by attributes whose length and format is 3131 defined by that transform ID. A message proposing an SA may 3132 contain multiple IPCOMP_SUPPORTED notifications to indicate 3133 multiple supported algorithms. A message accepting an SA may 3134 contain at most one. 3136 The transform IDs currently defined are: 3138 NAME NUMBER DEFINED IN 3139 ----------- ------ ----------- 3140 RESERVED 0 3141 IPCOMP_OUI 1 3142 IPCOMP_DEFLATE 2 RFC 2394 3143 IPCOMP_LZS 3 RFC 2395 3144 IPCOMP_LZJH 4 RFC 3051 3146 values 5-240 are reserved to IANA. Values 241-255 are 3147 for private use among mutually consenting parties. 3149 NAT_DETECTION_SOURCE_IP 16388 3151 This notification is used by its recipient to determine 3152 whether the source is behind a NAT box. The data associated 3153 with this notification is a SHA-1 digest of the SPIs (in the 3154 order they appear in the header), IP address and port on 3155 which this packet was sent. There MAY be multiple Notify 3156 payloads of this type in a message if the sender does not 3157 know which of several network attachments will be used to 3158 send the packet. The recipient of this notification MAY 3159 compare the supplied value to a SHA-1 hash of the SPIs, 3160 source IP address and port and if they don't match it SHOULD 3161 enable NAT traversal (see section 2.23). Alternately, it 3162 MAY reject the connection attempt if NAT traversal is not 3163 supported. 3165 NAT_DETECTION_DESTINATION_IP 16389 3167 This notification is used by its recipient to determine 3168 whether it is behind a NAT box. The data associated with 3169 this notification is a SHA-1 digest of the SPIs (in the 3170 order they appear in the header), IP address and port to 3171 which this packet was sent. The recipient of this 3172 notification MAY compare the supplied value to a hash of the 3173 SPIs, destination IP address and port and if they don't 3174 match it SHOULD invoke NAT traversal (see section 2.23). If 3175 they don't match, it means that this end is behind a NAT and 3176 this end SHOULD start start sending keepalive packets as 3177 defined in [Hutt02]. Alternately, it MAY reject the 3178 connection attempt if NAT traversal is not supported. 3180 COOKIE 16390 3182 This notification MAY be included in an IKE_SA_INIT 3183 response. It indicates that the request should be retried 3184 with a copy of this notification as the first payload. This 3185 notification MUST be included in an IKE_SA_INIT request 3186 retry if a COOKIE notification was included in the initial 3187 response. The data associated with this notification MUST 3188 be between 1 and 64 octets in length (inclusive). 3190 USE_TRANSPORT_MODE 16391 3192 This notification MAY be included in a request message that 3193 also includes an SA requesting a CHILD_SA. It requests that 3194 the CHILD_SA use transport mode rather than tunnel mode for 3195 the SA created. If the request is accepted, the response 3196 MUST also include a notification of type USE_TRANSPORT_MODE. 3197 If the responder declines the request, the CHILD_SA will be 3198 established in tunnel mode. If this is unacceptable to the 3199 initiator, the initiator MUST delete the SA. Note: except 3200 when using this option to negotiate transport mode, all 3201 CHILD_SAs will use tunnel mode. 3203 Note: The ECN decapsulation modifications specified in 3204 [RFC2401bis] MUST be performed for every tunnel mode SA 3205 created by IKEv2. 3207 HTTP_CERT_LOOKUP_SUPPORTED 16392 3209 This notification MAY be included in any message that can 3210 include a CERTREQ payload and indicates that the sender is 3211 capable of looking up certificates based on an HTTP-based 3212 URL (and hence presumably would prefer to receive 3213 certificate specifications in that format). 3215 REKEY_SA 16393 3217 This notification MUST be included in a CREATE_CHILD_SA 3218 exchange if the purpose of the exchange is to replace an 3219 existing ESP or AH SA. The SPI field identifies the SA being 3220 rekeyed. There is no data. 3222 RESERVED TO IANA - STATUS TYPES 16394 - 40959 3224 Private Use - STATUS TYPES 40960 - 65535 3226 3.11 Delete Payload 3228 The Delete Payload, denoted D in this memo, contains a protocol 3229 specific security association identifier that the sender has removed 3230 from its security association database and is, therefore, no longer 3231 valid. Figure 17 shows the format of the Delete Payload. It is 3232 possible to send multiple SPIs in a Delete payload, however, each SPI 3233 MUST be for the same protocol. Mixing of protocol identifiers MUST 3234 NOT be performed in a the Delete payload. It is permitted, however, 3235 to include multiple Delete payloads in a single INFORMATIONAL 3236 Exchange where each Delete payload lists SPIs for a different 3237 protocol. 3239 Deletion of the IKE_SA is indicated by a protocol ID of 1 (IKE) but 3240 no SPIs. Deletion of a CHILD_SA, such as ESP or AH, will contain the 3241 IPsec protocol ID of that protocol (2 for AH, 3 for ESP) and the SPI 3242 is the SPI the sending endpoint would expect in inbound ESP or AH 3243 packets. 3245 The Delete Payload is defined as follows: 3247 1 2 3 3248 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 3249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3250 ! Next Payload !C! RESERVED ! Payload Length ! 3251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3252 ! Protocol ID ! SPI Size ! # of SPIs ! 3253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3254 ! ! 3255 ~ Security Parameter Index(es) (SPI) ~ 3256 ! ! 3257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3259 Figure 17: Delete Payload Format 3261 o Protocol ID (1 octet) - Must be 1 for an IKE_SA, 2 for AH, or 3262 3 for ESP. 3264 o SPI Size (1 octet) - Length in octets of the SPI as defined by 3265 the protocol ID. It MUST be zero for IKE (SPI is in message 3266 header) or four for AH and ESP. 3268 o # of SPIs (2 octets) - The number of SPIs contained in the Delete 3269 payload. The size of each SPI is defined by the SPI Size field. 3271 o Security Parameter Index(es) (variable length) - Identifies the 3272 specific security association(s) to delete. The length of this 3273 field is determined by the SPI Size and # of SPIs fields. 3275 The payload type for the Delete Payload is forty two (42). 3277 3.12 Vendor ID Payload 3279 The Vendor ID Payload contains a vendor defined constant. The 3280 constant is used by vendors to identify and recognize remote 3281 instances of their implementations. This mechanism allows a vendor 3282 to experiment with new features while maintaining backwards 3283 compatibility. 3285 A Vendor ID payload MAY announce that the sender is capable to 3286 accepting certain extensions to the protocol, or it MAY simply 3287 identify the implementation as an aid in debugging. A Vendor ID 3288 payload MUST NOT change the interpretation of any information defined 3289 in this specification (i.e., it MUST be non-critical). Multiple 3290 Vendor ID payloads MAY be sent. An implementation is NOT REQUIRED to 3291 send any Vendor ID payload at all. 3293 A Vendor ID payload may be sent as part of any message. Reception of 3294 a familiar Vendor ID payload allows an implementation to make use of 3295 Private USE numbers described throughout this memo-- private 3296 payloads, private exchanges, private notifications, etc. Unfamiliar 3297 Vendor IDs MUST be ignored. 3299 Writers of Internet-Drafts who wish to extend this protocol MUST 3300 define a Vendor ID payload to announce the ability to implement the 3301 extension in the Internet-Draft. It is expected that Internet-Drafts 3302 which gain acceptance and are standardized will be given "magic 3303 numbers" out of the Future Use range by IANA and the requirement to 3304 use a Vendor ID will go away. 3306 The Vendor ID Payload fields are defined as follows: 3308 1 2 3 3309 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 3310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3311 ! Next Payload !C! RESERVED ! Payload Length ! 3312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3313 ! ! 3314 ~ Vendor ID (VID) ~ 3315 ! ! 3316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3318 Figure 18: Vendor ID Payload Format 3320 o Vendor ID (variable length) - It is the responsibility of 3321 the person choosing the Vendor ID to assure its uniqueness 3322 in spite of the absence of any central registry for IDs. 3323 Good practice is to include a company name, a person name 3324 or some such. If you want to show off, you might include 3325 the latitude and longitude and time where you were when 3326 you chose the ID and some random input. A message digest 3327 of a long unique string is preferable to the long unique 3328 string itself. 3330 The payload type for the Vendor ID Payload is forty three (43). 3332 3.13 Traffic Selector Payload 3334 The Traffic Selector Payload, denoted TS in this memo, allows peers 3335 to identify packet flows for processing by IPsec security services. 3336 The Traffic Selector Payload consists of the IKE generic payload 3337 header followed by individual traffic selectors as follows: 3339 1 2 3 3340 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 3341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3342 ! Next Payload !C! RESERVED ! Payload Length ! 3343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3344 ! Number of TSs ! RESERVED ! 3345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3346 ! ! 3347 ~ ~ 3348 ! ! 3349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3351 Figure 19: Traffic Selectors Payload Format 3353 o Number of TSs (1 octet) - Number of traffic selectors 3354 being provided. 3356 o RESERVED - This field MUST be sent as zero and MUST be ignored 3357 on receipt. 3359 o Traffic Selectors (variable length) - one or more individual 3360 traffic selectors. 3362 The length of the Traffic Selector payload includes the TS header and 3363 all the traffic selectors. 3365 The payload type for the Traffic Selector payload is forty four (44) 3366 for addresses at the initiator's end of the SA and forty five (45) 3367 for addresses at the responder's end. 3369 3.13.1 Traffic Selector 3371 1 2 3 3372 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 3373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3374 ! TS Type !IP Protocol ID*| Selector Length | 3375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3376 | Start Port* | End Port* | 3377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3378 ! ! 3379 ~ Starting Address* ~ 3380 ! ! 3381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3382 ! ! 3383 ~ Ending Address* ~ 3384 ! ! 3385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3387 Figure 20: Traffic Selector 3389 *Note: all fields other than TS Type and Selector Length depend on 3390 the TS Type. The fields shown are for TS Types 7 and 8, the only two 3391 values currently defined. 3393 o TS Type (one octet) - Specifies the type of traffic selector. 3395 o IP protocol ID (1 octet) - Value specifying an associated IP 3396 protocol ID (e.g., UDP/TCP/ICMP). A value of zero means that 3397 the protocol ID is not relevant to this traffic selector-- 3398 the SA can carry all protocols. 3400 o Selector Length - Specifies the length of this Traffic 3401 Selector Substructure including the header. 3403 o Start Port (2 octets) - Value specifying the smallest port 3404 number allowed by this Traffic Selector. For protocols for 3405 which port is undefined, or if all ports are allowed by 3406 this Traffic Selector, this field MUST be zero. For the 3407 ICMP protocol, the two one octet fields Type and Code are 3408 treated as a single 16 bit integer port number for the 3409 purposes of filtering based on this field. 3411 o End Port (2 octets) - Value specifying the largest port 3412 number allowed by this Traffic Selector. For protocols for 3413 which port is undefined, or if all ports are allowed by 3414 this Traffic Selector, this field MUST be 65535. For the 3415 ICMP protocol, the two one octet fields Type and Code are 3416 treated as a single 16 bit integer port number for the 3417 purposed of filtering based on this field. 3419 o Starting Address - The smallest address included in this 3420 Traffic Selector (length determined by TS type). 3422 o Ending Address - The largest address included in this 3423 Traffic Selector (length determined by TS type). 3425 The following table lists the assigned values for the Traffic 3426 Selector Type field and the corresponding Address Selector Data. 3428 TS Type Value 3429 ------- ----- 3430 RESERVED 0-6 3432 TS_IPV4_ADDR_RANGE 7 3434 A range of IPv4 addresses, represented by two four (4) octet 3435 values. The first value is the beginning IPv4 address 3436 (inclusive) and the second value is the ending IPv4 address 3437 (inclusive). All addresses falling between the two specified 3438 addresses are considered to be within the list. 3440 TS_IPV6_ADDR_RANGE 8 3442 A range of IPv6 addresses, represented by two sixteen (16) 3443 octet values. The first value is the beginning IPv6 address 3444 (inclusive) and the second value is the ending IPv6 address 3445 (inclusive). All addresses falling between the two specified 3446 addresses are considered to be within the list. 3448 3.14 Encrypted Payload 3450 The Encrypted Payload, denoted SK{...} in this memo, contains other 3451 payloads in encrypted form. The Encrypted Payload, if present in a 3452 message, MUST be the last payload in the message. Often, it is the 3453 only payload in the message. 3455 The algorithms for encryption and integrity protection are negotiated 3456 during IKE_SA setup, and the keys are computed as specified in 3457 sections 2.14 and 2.18. 3459 The encryption and integrity protection algorithms are modelled after 3460 the ESP algorithms described in RFCs 2104, 2406, 2451. This document 3461 completely specifies the cryptographic processing of IKE data, but 3462 those documents should be consulted for design rationale. We assume a 3463 block cipher with a fixed block size and an integrity check algorithm 3464 that computes a fixed length checksum over a variable size message. 3466 The payload type for an Encrypted payload is forty six (46). The 3467 Encrypted Payload consists of the IKE generic payload header followed 3468 by individual fields as follows: 3470 1 2 3 3471 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 3472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3473 ! Next Payload !C! RESERVED ! Payload Length ! 3474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3475 ! Initialization Vector ! 3476 ! (length is block size for encryption algorithm) ! 3477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3478 ! Encrypted IKE Payloads ! 3479 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3480 ! ! Padding (0-255 octets) ! 3481 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 3482 ! ! Pad Length ! 3483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3484 ~ Integrity Checksum Data ~ 3485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3487 Figure 21: Encrypted Payload Format 3489 o Next Payload - The payload type of the first embedded payload. 3490 Note that this is an exception in the standard header format, 3491 since the Encrypted payload is the last payload in the 3492 message and therefore the Next Payload field would normally 3493 be zero. But because the content of this payload is embedded 3494 payloads and there was no natural place to put the type of 3495 the first one, that type is placed here. 3497 o Payload Length - Includes the lengths of the header, IV, 3498 Encrypted IKE Payloads, Padding, Pad Length and Integrity 3499 Checksum Data. 3501 o Initialization Vector - A randomly chosen value whose length 3502 is equal to the block length of the underlying encryption 3503 algorithm. Recipients MUST accept any value. Senders SHOULD 3504 either pick this value pseudo-randomly and independently for 3505 each message or use the final ciphertext block of the previous 3506 message sent. Senders MUST NOT use the same value for each 3507 message, use a sequence of values with low hamming distance 3508 (e.g., a sequence number), or use ciphertext from a received 3509 message. 3511 o IKE Payloads are as specified earlier in this section. This 3512 field is encrypted with the negotiated cipher. 3514 o Padding MAY contain any value chosen by the sender, and MUST 3515 have a length that makes the combination of the Payloads, the 3516 Padding, and the Pad Length to be a multiple of the encryption 3517 block size. This field is encrypted with the negotiated 3518 cipher. 3520 o Pad Length is the length of the Padding field. The sender 3521 SHOULD set the Pad Length to the minimum value that makes 3522 the combination of the Payloads, the Padding, and the Pad 3523 Length a multiple of the block size, but the recipient MUST 3524 accept any length that results in proper alignment. This 3525 field is encrypted with the negotiated cipher. 3527 o Integrity Checksum Data is the cryptographic checksum of 3528 the entire message starting with the Fixed IKE Header 3529 through the Pad Length. The checksum MUST be computed over 3530 the encrypted message. 3532 3.15 Configuration Payload 3534 The Configuration payload, denoted CP in this document, is used to 3535 exchange configuration information between IKE peers. Currently, the 3536 only defined uses for this exchange is for an IRAC to request an 3537 internal IP address from an IRAS or for either party to request 3538 version information from the other, but this payload is intended as a 3539 likely place for future extensions. 3541 Configuration payloads are of type CFG_REQUEST/CFG_REPLY or 3542 CFG_SET/CFG_ACK (see CFG Type in the payload description below). 3543 CFG_REQUEST and CFG_SET payloads may optionally be added to any IKE 3544 request. The IKE response MUST include either a corresponding 3545 CFG_REPLY or CFG_ACK or a Notify payload with an error type 3546 indicating why the request could not be honored. An exception is that 3547 a minimal implementation MAY ignore all CFG_REQUEST and CFG_SET 3548 payloads, so a response message without a corresponding CFG_REPLY or 3549 CFG_ACK MUST be accepted as an indication that the request was not 3550 supported. 3552 "CFG_REQUEST/CFG_REPLY" allows an IKE endpoint to request information 3553 from its peer. If an attribute in the CFG_REQUEST Configuration 3554 Payload is not zero length it is taken as a suggestion for that 3555 attribute. The CFG_REPLY Configuration Payload MAY return that 3556 value, or a new one. It MAY also add new attributes and not include 3557 some requested ones. Requestors MUST ignore returned attributes that 3558 they do not recognize. 3560 Some attributes MAY be multi-valued, in which case multiple attribute 3561 values of the same type are sent and/or returned. Generally, all 3562 values of an attribute are returned when the attribute is requested. 3563 For some attributes (in this version of the specification only 3564 internal addresses), multiple requests indicates a request that 3565 multiple values be assigned. For these attributes, the number of 3566 values returned SHOULD NOT exceed the number requested. 3568 If the data type requested in a CFG_REQUEST is not recognized or not 3569 supported, the responder MUST NOT return an error type but rather 3570 MUST either send a CFG_REPLY which MAY be empty or a reply not 3571 containing a CFG_REPLY payload at all. Error returns are reserved for 3572 cases where the request is recognized but cannot be performed as 3573 requested or the request is badly formatted. 3575 "CFG_SET/CFG_ACK" allows an IKE endpoint to push configuration data 3576 to its peer. In this case the CFG_SET Configuration Payload contains 3577 attributes the initiator wants its peer to alter. The responder MUST 3578 return a Configuration Payload if it accepted any of the 3579 configuration data and it MUST contain the attributes that the 3580 responder accepted with zero length data. Those attributes that it 3581 did not accept MUST NOT be in the CFG_ACK Configuration Payload. If 3582 no attributes were accepted, the responder MUST return either an 3583 empty CFG_ACK payload or a response message without a CFG_ACK 3584 payload. There are currently no defined uses for the CFG_SET/CFG_ACK 3585 exchange, though they may be used in connection with extensions based 3586 on Vendor IDs. An minimal implementation of this specification MAY 3587 ignore CFG_SET payloads. 3589 Extensions via the CP payload SHOULD NOT be used for general purpose 3590 management. Its main intent is to provide a bootstrap mechanism to 3591 exchange information within IPsec from IRAS to IRAC. While it MAY be 3592 useful to use such a method to exchange information between some 3593 Security Gateways (SGW) or small networks, existing management 3594 protocols such as DHCP [DHCP], RADIUS [RADIUS], SNMP or LDAP [LDAP] 3595 should be preferred for enterprise management as well as subsequent 3596 information exchanges. 3598 The Configuration Payload is defined as follows: 3600 1 2 3 3601 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3603 ! Next Payload !C! RESERVED ! Payload Length ! 3604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3605 ! CFG Type ! RESERVED ! 3606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3607 ! ! 3608 ~ Configuration Attributes ~ 3609 ! ! 3610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3612 Figure 22: Configuration Payload Format 3614 The payload type for the Configuration Payload is forty seven (47). 3616 o CFG Type (1 octet) - The type of exchange represented by the 3617 Configuration Attributes. 3619 CFG Type Value 3620 =========== ===== 3621 RESERVED 0 3622 CFG_REQUEST 1 3623 CFG_REPLY 2 3624 CFG_SET 3 3625 CFG_ACK 4 3627 values 5-127 are reserved to IANA. Values 128-255 are for private 3628 use among mutually consenting parties. 3630 o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on 3631 receipt. 3633 o Configuration Attributes (variable length) - These are type 3634 length values specific to the Configuration Payload and are 3635 defined below. There may be zero or more Configuration 3636 Attributes in this payload. 3638 3.15.1 Configuration Attributes 3640 1 2 3 3641 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 3642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3643 !R| Attribute Type ! Length | 3644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3645 | | 3646 ~ Value ~ 3647 | | 3648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3650 Figure 23: Configuration Attribute Format 3652 o Reserved (1 bit) - This bit MUST be set to zero and MUST be 3653 ignored on receipt. 3655 o Attribute Type (7 bits) - A unique identifier for each of the 3656 Configuration Attribute Types. 3658 o Length (2 octets) - Length in octets of Value. 3660 o Value (0 or more octets) - The variable length value of this 3661 Configuration Attribute. 3663 The following attribute types have been defined: 3665 Multi- 3666 Attribute Type Value Valued Length 3667 ======================= ===== ====== ================== 3668 RESERVED 0 3669 INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets 3670 INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets 3671 INTERNAL_IP4_DNS 3 YES 0 or 4 octets 3672 INTERNAL_IP4_NBNS 4 YES 0 or 4 octets 3673 INTERNAL_ADDRESS_EXPIRY 5 NO 0 or 4 octets 3674 INTERNAL_IP4_DHCP 6 YES 0 or 4 octets 3675 APPLICATION_VERSION 7 NO 0 or more 3676 INTERNAL_IP6_ADDRESS 8 YES* 0 or 16 octets 3677 INTERNAL_IP6_NETMASK 9 NO 0 or 16 octets 3678 INTERNAL_IP6_DNS 10 YES 0 or 16 octets 3679 INTERNAL_IP6_NBNS 11 YES 0 or 16 octets 3680 INTERNAL_IP6_DHCP 12 YES 0 or 16 octets 3681 INTERNAL_IP4_SUBNET 13 NO 0 or 8 octets 3682 SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 3683 INTERNAL_IP6_SUBNET 15 NO 17 octets 3685 * These attributes may be multi-valued on return only if 3686 multiple values were requested. 3688 Types 16-16383 are reserved to IANA. Values 16384-32767 are for 3689 private use among mutually consenting parties. 3691 o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the 3692 internal network, sometimes called a red node address or 3693 private address and MAY be a private address on the Internet. 3694 Multiple internal addresses MAY be requested by requesting 3695 multiple internal address attributes. The responder MAY only 3696 send up to the number of addresses requested. 3698 The requested address is valid until the expiry time defined 3699 with the INTERNAL_ADDRESS EXPIRY attribute or there are no 3700 IKE_SAs between the peers. 3702 o INTERNAL_IP4_NETMASK, INTERNAL_IP6_NETMASK - The internal 3703 network's netmask. Only one netmask is allowed in the request 3704 and reply messages (e.g., 255.255.255.0) and it MUST be used 3705 only with an INTERNAL_ADDRESS attribute. 3707 o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a 3708 DNS server within the network. Multiple DNS servers MAY be 3709 requested. The responder MAY respond with zero or more DNS 3710 server attributes. 3712 o INTERNAL_IP4_NBNS, INTERNAL_IP6_NBNS - Specifies an address of 3713 a NetBios Name Server (WINS) within the network. Multiple NBNS 3714 servers MAY be requested. The responder MAY respond with zero 3715 or more NBNS server attributes. 3717 o INTERNAL_ADDRESS_EXPIRY - Specifies the number of seconds that 3718 the host can use the internal IP address. The host MUST renew 3719 the IP address before this expiry time. Only one of these 3720 attributes MAY be present in the reply. 3722 o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to 3723 send any internal DHCP requests to the address contained within 3724 the attribute. Multiple DHCP servers MAY be requested. The 3725 responder MAY respond with zero or more DHCP server attributes. 3727 o APPLICATION_VERSION - The version or application information of 3728 the IPsec host. This is a string of printable ASCII characters 3729 that is NOT null terminated. 3731 o INTERNAL_IP4_SUBNET - The protected sub-networks that this 3732 edge-device protects. This attribute is made up of two fields; 3733 the first being an IP address and the second being a netmask. 3735 Multiple sub-networks MAY be requested. The responder MAY 3736 respond with zero or more sub-network attributes. 3738 o SUPPORTED_ATTRIBUTES - When used within a Request, this 3739 attribute MUST be zero length and specifies a query to the 3740 responder to reply back with all of the attributes that it 3741 supports. The response contains an attribute that contains a 3742 set of attribute identifiers each in 2 octets. The length 3743 divided by 2 (octets) would state the number of supported 3744 attributes contained in the response. 3746 o INTERNAL_IP6_SUBNET - The protected sub-networks that this 3747 edge-device protects. This attribute is made up of two fields; 3748 the first being a 16 octet IPv6 address the second being a one 3749 octet prefix-length as defined in [ADDRIPV6]. Multiple 3750 sub-networks MAY be requested. The responder MAY respond with 3751 zero or more sub-network attributes. 3753 Note that no recommendations are made in this document how an 3754 implementation actually figures out what information to send in a 3755 reply. i.e., we do not recommend any specific method of an IRAS 3756 determining which DNS server should be returned to a requesting 3757 IRAC. 3759 3.16 Extended Authentication Protocol (EAP) Payload 3761 The Extended Authentication Protocol Payload, denoted EAP in this 3762 memo, allows IKE_SAs to be authenticated using the protocol defined 3763 in RFC 2284 [EAP] and subsequent extensions to that protocol. The 3764 full set of acceptable values for the payload are defined elsewhere, 3765 but a short summary of RFC 2284 is included here to make this 3766 document stand alone in the common cases. 3768 1 2 3 3769 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 3770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3771 ! Next Payload !C! RESERVED ! Payload Length ! 3772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3773 ! ! 3774 ~ EAP Message ~ 3775 ! ! 3776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3778 Figure 24: EAP Payload Format 3780 The payload type for an EAP Payload is forty eight (48). 3782 1 2 3 3783 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 3784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3785 ! Code ! Identifier ! Length ! 3786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3787 ! Type ! Type_Data... 3788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 3790 Figure 25: EAP Message Format 3792 o Code (one octet) indicates whether this message is a 3793 Request (1), Response (2), Success (3), or Failure (4). 3795 o Identifier (one octet) is used in PPP to distinguish replayed 3796 messages from repeated ones. Since in IKE, EAP runs over a 3797 reliable protocol, it serves no function here. In a response 3798 message this octet MUST be set to match the identifier in the 3799 corresponding request. In other messages, this field MAY 3800 be set to any value. 3802 o Length (two octets) is the length of the EAP message and MUST 3803 be four less than the Payload Length of the encapsulating 3804 payload. 3806 o Type (one octet) is present only if the Code field is Request 3807 (1) or Response (2). For other codes, the EAP message length 3808 MUST be four octets and the Type and Type_Data fields MUST NOT 3809 be present. In a Request (1) message, Type indicates the 3810 data being requested. In a Response (2) message, Type MUST 3811 either be NAC or match the type of the data requested. The 3812 following types are defined in RFC 2284: 3814 1 Identity 3815 2 Notification 3816 3 NAK (Response Only) 3817 4 MD5-Challenge 3818 5 One-Time Password (OTP) 3819 6 Generic Token Card 3821 o Type_Data (Variable Length) contains data depending on the Code 3822 and Type. In Requests other than MD5-Challenge, this field 3823 contains a prompt to be displayed to a human user. For NAK, it 3824 contains one octet suggesting the type of authentication the 3825 Initiator would prefer to use. For most other responses, it 3826 contains the authentication code typed by the human user. 3828 Note that since IKE passes an indication of initiator identity in 3829 message 3 of the protocol, EAP based prompts for Identity SHOULD NOT 3830 be used. 3832 4 Conformance Requirements 3834 In order to assure that all implementations of IKEv2 can 3835 interoperate, there are MUST support requirements in addition to 3836 those listed elsewhere. Of course, IKEv2 is a security protocol, and 3837 one of its major functions is to only allow authorized parties to 3838 successfully complete establishment of SAs. So a particular 3839 implementation may be configured with any of a number of restrictions 3840 concerning algorithms and trusted authorities that will prevent 3841 universal interoperability. 3843 IKEv2 is designed to permit minimal implementations that can 3844 interoperate with all compliant implementations. There are a series 3845 of optional features that can easily be ignored by a particular 3846 implementation if it does not support that feature. Those features 3847 include: 3849 Ability to negotiate SAs through a NAT and tunnel the resulting 3850 ESP SA over UDP. 3852 Ability to request (and respond to a request for) a temporary IP 3853 address on the remote end of a tunnel. 3855 Ability to support various types of legacy authentication. 3857 Ability to support window sizes greater than one. 3859 Ability to establish multiple ESP and/or AH SAs within a single 3860 IKE_SA. 3862 Ability to rekey SAs. 3864 To assure interoperability, all implementations MUST be capable of 3865 parsing all payload types (if only to skip over them) and to ignore 3866 payload types that it does not support unless the critical bit is set 3867 in the payload header. If the critical bit is set in an unsupported 3868 payload header, all implementations MUST reject the messages 3869 containing those payloads. 3871 Every implementation MUST be capable of doing four message 3872 IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, 3873 one for ESP and/or AH). Implementations MAY be initiate-only or 3874 respond-only if appropriate for their platform. Every implementation 3875 MUST be capable of responding to an INFORMATIONAL exchange, but a 3876 minimal implementation MAY respond to any INFORMATIONAL message with 3877 an empty INFORMATIONAL reply. A minimal implementation MAY support 3878 the CREATE_CHILD_SA exchange only in so far as to recognize requests 3879 and reject them with a Notify payload of type NO_ADDITIONAL_SAS. A 3880 minimal implementation need not be able to initiate CREATE_CHILD_SA 3881 or INFORMATIONAL exchanges. When an SA expires (based on locally 3882 configured values of either lifetime or octets passed), and 3883 implementation MAY either try to renew it with a CREATE_CHILD_SA 3884 exchange or it MAY delete (close) the old SA and create a new one. If 3885 the responder rejects the CREATE_CHILD_SA request with a 3886 NO_ADDITIONAL_SAS notification, the implementation MUST be capable of 3887 instead closing the old SA and creating a new one. 3889 Implementations are not required to support requesting temporary IP 3890 addresses or responding to such requests. If an implementation does 3891 support issuing such requests, it MUST include a CP payload in 3892 message 3 containing at least a field of type INTERNAL_IP4_ADDRESS or 3893 INTERNAL_IP6_ADDRESS. All other fields are optional. If an 3894 implementation supports responding to such requests, it MUST parse 3895 the CP payload of type CFG_REQUEST in message 3 and recognize a field 3896 of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports 3897 leasing an address of the appropriate type, it MUST return a CP 3898 payload of type CFG_REPLY containing an address of the requested 3899 type. The responder SHOULD include all of the other related 3900 attributes if it has them. 3902 A minimal IPv4 responder implementation will ignore the contents of 3903 the CP payload except to determine that it includes an 3904 INTERNAL_IP4_ADDRESS attribute and will respond with the address and 3905 other related attributes regardless of whether the initiator 3906 requested them. 3908 A minimal IPv4 initiator will generate a CP payload containing only 3909 an INTERNAL_IP4_ADDRESS attribute and will parse the response 3910 ignoring attributes it does not know how to use. The only attribute 3911 it MUST be able to process is INTERNAL_ADDRESS_EXPIRY, which it must 3912 use to bound the lifetime of the SA unless it successfully renews the 3913 lease before it expires. Minimal initiators need not be able to 3914 request lease renewals and minimal responders need not respond to 3915 them. 3917 For an implementation to be called conforming to this specification, 3918 it MUST be possible to configure it to accept the following: 3920 PKIX Certificates containing and signed by RSA keys of size 1024 or 3921 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, 3922 ID_RFC822_ADDR, or ID_DER_ASN1_DN. 3924 Shared key authentication where the ID passes is any of ID_KEY_ID, 3925 ID_FQDN, or ID_RFC822_ADDR. 3927 Authentication where the responder is authenticated using PKIX 3928 Certificates and the initiator is authenticated using shared key 3929 authentication. 3931 5 Security Considerations 3933 Repeated rekeying using CREATE_CHILD_SA without PFS leaves all SAs 3934 vulnerable to cryptanalysis of a single key or overrun of either 3935 endpoint. Implementers should take note of this fact and set a limit 3936 on CREATE_CHILD_SA exchanges between exponentiations. This memo does 3937 not prescribe such a limit. 3939 The strength of a key derived from a Diffie-Hellman exchange using 3940 any of the groups defined here depends on the inherent strength of 3941 the group, the size of the exponent used, and the entropy provided by 3942 the random number generator used. Due to these inputs it is difficult 3943 to determine the strength of a key for any of the defined groups. 3944 Diffie-Hellman group number two, when used with a strong random 3945 number generator and an exponent no less than 200 bits, is sufficient 3946 for use with 3DES. Groups three through five provide greater 3947 security. Group one is for historic purposes only and does not 3948 provide sufficient strength except for use with DES, which is also 3949 for historic use only. Implementations should make note of these 3950 conservative estimates when establishing policy and negotiating 3951 security parameters. 3953 Note that these limitations are on the Diffie-Hellman groups 3954 themselves. There is nothing in IKE which prohibits using stronger 3955 groups nor is there anything which will dilute the strength obtained 3956 from stronger groups (limited by the strength of the other algorithms 3957 negotiated including the prf function). In fact, the extensible 3958 framework of IKE encourages the definition of more groups; use of 3959 elliptical curve groups may greatly increase strength using much 3960 smaller numbers. 3962 It is assumed that all Diffie-Hellman exponents are erased from 3963 memory after use. In particular, these exponents MUST NOT be derived 3964 from long-lived secrets like the seed to a pseudo-random generator 3965 that is not erased after use. 3967 The strength of all keys are limited by the size of the output of the 3968 negotiated prf function. For this reason, a prf function whose output 3969 is less than 128 bits (e.g., 3DES-CBC) MUST NOT be used with this 3970 protocol. 3972 The security of this protocol is critically dependent on the 3973 randomness of the randomly chosen parameters. These should be 3974 generated by a strong random or properly seeded pseudo-random source 3975 (see [RFC1750]). Implementers should take care to ensure that use of 3976 random numbers for both keys and nonces is engineered in a fashion 3977 that does not undermine the security of the keys. 3979 For information on the rationale of many of the cryptographic design 3980 choices in this protocol, see [SIGMA]. 3982 When using pre-shared keys, a critical consideration is how to assure 3983 the randomness of these secrets. The strongest practice is to ensure 3984 that any pre-shared key contain as much randomness as the strongest 3985 key being negotiated. Deriving a shared secret from a password, name, 3986 or other low entropy source is not secure. These sources are subject 3987 to dictionary and social engineering attacks, among others. 3989 The NAT_DETECTION_*_IP notifications contain a hash of the addresses 3990 and ports in an attempt to hide internal IP addresses behind a NAT. 3991 Since the IPv4 address space is only 32 bits, and it is usually very 3992 sparse, it would be possible for an attacker to find out the internal 3993 address used behind the NAT box by trying all possible IP-addresses 3994 and trying to find the matching hash. The port numbers are normally 3995 fixed to 500, and the SPIs can be extracted from the packet. This 3996 reduces the number of hash calculations to 2^32. With an educated 3997 guess of the use of private address space, the number of hash 3998 calculations is much smaller. Designers should therefore not assume 3999 that use of IKE will not leak internal address information. 4001 When using an EAP authentication method that does not generate a 4002 shared key for protecting a subsequent AUTH payload, certain man-in- 4003 the-middle and server impersonation attacks are possible [EAPMITM]. 4004 These vulnerabilities occur when EAP is also used in protocols which 4005 are not protected with a secure tunnel. Since EAP is a general- 4006 purpose authentication protocol, which is often used to provide 4007 single-signon facilities, a deployed IPsec solution which relies on 4008 an EAP authentication method that does not generate a shared key 4009 (also known as a non-key-generating EAP method) can become 4010 compromised due to the deployment of an entirely unrelated 4011 application that also happens to use the same non-key-generating EAP 4012 method, but in an unprotected fashion. Note that this vulnerability 4013 is not limited to just EAP, but can occur in other scenarios where an 4014 authentication infrastructure is reused. For example, if the EAP 4015 mechanism used by IKEv2 utilizes a token authenticator, a man-in-the- 4016 middle attacker could impersonate the web server, intercept the token 4017 authentication exchange, and use it to initiate an IKEv2 connection. 4018 For this reason, use of non-key-generating EAP methods SHOULD be 4019 avoided where possible. Where they are used, it is extremely 4020 important that all usages of these EAP methods SHOULD utilize a 4021 protected tunnel, where the initiator validates the responder's 4022 certificate before initiating the EAP exchange. Implementors SHOULD 4023 describe the vulnerabilities of using non-key-generating EAP methods 4024 in the documentation of their implementations so that the 4025 administrators deploying IPsec solutions are aware of these dangers. 4027 An implementation using EAP MUST also use a public key based 4028 authentication of the server to the client before the EAP exchange 4029 begins, even if the EAP method offers mutual authentication. This 4030 avoids having additional IKEv2 protocol variations and protects the 4031 EAP data from active attackers. 4033 6 IANA Considerations 4035 This document defines a number of new field types and values where 4036 future assignments will be managed by the IANA. The initial IANA 4037 registry values are documented in [IKEv2IANA]. 4039 7 Intellectual Property Rights 4041 The IETF takes no position regarding the validity or scope of any 4042 intellectual property or other rights that might be claimed to 4043 pertain to the implementation or use of the technology described in 4044 this document or the extent to which any license under such rights 4045 might or might not be available; neither does it represent that it 4046 has made any effort to identify any such rights. Information on the 4047 IETF's procedures with respect to rights in standards-track and 4048 standards-related documentation can be found in BCP-11. Copies of 4049 claims of rights made available for publication and any assurances of 4050 licenses to be made available, or the result of an attempt made to 4051 obtain a general license or permission for the use of such 4052 proprietary rights by implementors or users of this specification can 4053 be obtained from the IETF Secretariat. 4055 The IETF encourages any interested party to bring to its attention 4056 any copyrights, patents, or patent applications, or other proprietary 4057 rights which may cover technology that may be required to practice 4058 this standard. Please address the information to the IETF Executive 4059 Director. 4061 The IETF has been notified of intellectual property rights claimed in 4062 regard to some or all of the specification contained in this 4063 document. For more information consult the online list of claimed 4064 rights. 4066 8 Acknowledgements 4068 This document is a collaborative effort of the entire IPsec WG. If 4069 there were no limit to the number of authors that could appear on an 4070 RFC, the following, in alphabetical order, would have been listed: 4072 Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt 4073 Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, J. 4074 Ioannidis, Steve Kent, Angelos Keromytis, Tero Kivinen, Hugo 4075 Krawczyk, Andrew Krywaniuk, Radia Perlman, O. Reingold. Many other 4076 people contributed to the design. It is an evolution of IKEv1, 4077 ISAKMP, and the IPsec DOI, each of which has its own list of authors. 4078 Hugh Daniel suggested the feature of having the initiator, in message 4079 3, specify a name for the responder, and gave the feature the cute 4080 name "You Tarzan, Me Jane". David Faucher and Valery Smyzlov helped 4081 refine the design of the traffic selector negotiation. 4083 9 References 4085 9.1 Normative References 4087 [ADDGROUP] Kivinen, T., and Kojo, M., "More Modular Exponential 4088 (MODP) Diffie-Hellman groups for Internet Key 4089 Exchange (IKE)", RFC 3526, May 2003. 4091 [ADDRIPV6] Hinden, R., and Deering, S., 4092 "Internet Protocol Version 6 (IPv6) Addressing 4093 Architecture", RFC 3513, April 2003. 4095 [Bra97] Bradner, S., "Key Words for use in RFCs to indicate 4096 Requirement Levels", BCP 14, RFC 2119, March 1997. 4098 [EAP] Blunk, L. and Vollbrecht, J., "PPP Extensible 4099 Authentication Protocol (EAP), RFC 2284, March 1998. 4101 [ESPCBC] Pereira, R., Adams, R., "The ESP CBC-Mode Cipher 4102 Algorithms", RFC 2451, November 1998. 4104 [RFC2401bis] Kent, S. and Atkinson, R., "Security Architecture 4105 for the Internet Protocol", un-issued Internet 4106 Draft, work in progress. 4108 [RFC3168] Ramakrishnan, K., Floyd, S., and Black, D., 4109 "The Addition of Explicit Congestion Notification (ECN) 4110 to IP", RFC 3168, September 2001. 4112 [RFC3280] Housley, R., Polk, W., Ford, W., Solo, D., "Internet 4113 X.509 Public Key Infrastructure Certificate and 4114 Certificate Revocation List (CRL) Profile", RFC 3280, 4115 April 2002. 4117 9.2 Informative References 4119 [DES] ANSI X3.106, "American National Standard for Information 4120 Systems-Data Link Encryption", American National Standards 4121 Institute, 1983. 4123 [DH] Diffie, W., and Hellman M., "New Directions in 4124 Cryptography", IEEE Transactions on Information Theory, V. 4125 IT-22, n. 6, June 1977. 4127 [DHCP] R. Droms, "Dynamic Host Configuration Protocol", 4128 RFC2131 4130 [DSS] NIST, "Digital Signature Standard", FIPS 186, National 4131 Institute of Standards and Technology, U.S. Department of 4132 Commerce, May, 1994. 4134 [EAPMITM] Asokan, N., Nierni, V., and Nyberg, K., "Man-in-the-Middle 4135 in Tunneled Authentication Protocols", 4136 http://eprint.iacr.org/2002/163, November 2002. 4138 [HC98] Harkins, D., Carrel, D., "The Internet Key Exchange 4139 (IKE)", RFC 2409, November 1998. 4141 [Hutt02] Huttunen, A. et. al., "UDP Encapsulation of IPsec 4142 Packets", draft-ietf-ipsec-udp-encaps-05.txt, December 4143 2002. 4145 [IDEA] Lai, X., "On the Design and Security of Block Ciphers," 4146 ETH Series in Information Processing, v. 1, Konstanz: 4147 Hartung-Gorre Verlag, 1992 4149 [IKEv2IANA]Richardson, M., "Initial IANA registry contents", 4150 draft-ietf-ipsec-ikev2-iana-00.txt, work in progress. 4152 [IPCOMP] Shacham, A., Monsour, R., Pereira, R., and Thomas, M., "IP 4153 Payload Compression Protocol (IPComp)", RFC 3173, 4154 September 2001. 4156 [KPS03] Kaufman, C., Perlman, R., and Sommerfeld, B., "DoS 4157 protection for UDP-based protocols", ACM Conference on 4158 Computer and Communications Security, October 2003. 4160 [Ker01] Keromytis, A., Sommerfeld, B., "The 'Suggested ID' 4161 Extension for IKE", draft-keromytis-ike-id-00.txt, 2001 4163 [KBC96] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 4164 Hashing for Message Authentication", RFC 2104, February 4165 1997. 4167 [LDAP] M. Wahl, T. Howes, S. Kille., "Lightweight Directory 4168 Access Protocol (v3)", RFC2251 4170 [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, 4171 April 1992. 4173 [MSST98] Maughhan, D., Schertler, M., Schneider, M., and Turner, J. 4174 "Internet Security Association and Key Management Protocol 4175 (ISAKMP)", RFC 2408, November 1998. 4177 [Orm96] Orman, H., "The Oakley Key Determination Protocol", RFC 4178 2412, November 1998. 4180 [PFKEY] McDonald, D., Metz, C., and Phan, B., "PFKEY Key 4181 Management API, Version 2", RFC2367, July 1998. 4183 [PKCS1] Kaliski, B., and J. Staddon, "PKCS #1: RSA Cryptography 4184 Specifications Version 2", September 1998. 4186 [PK01] Perlman, R., and Kaufman, C., "Analysis of the IPsec key 4187 exchange Standard", WET-ICE Security Conference, MIT,2001, 4188 http://sec.femto.org/wetice-2001/papers/radia-paper.pdf. 4190 [Pip98] Piper, D., "The Internet IP Security Domain Of 4191 Interpretation for ISAKMP", RFC 2407, November 1998. 4193 [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote 4194 Authentication Dial In User Service (RADIUS)", RFC2138 4196 [RFC1750] Eastlake, D., Crocker, S., and Schiller, J., "Randomness 4197 Recommendations for Security", RFC 1750, December 1994. 4199 [RFC2401] Kent, S., and Atkinson, R., "Security Architecture for 4200 the Internet Protocol", RFC 2401, November 1998. 4202 [RFC2474] Nichols, K., Blake, S., Baker, F. and Black, D., 4203 "Definition of the Differentiated Services Field (DS 4204 Field) in the IPv4 and IPv6 Headers", RFC 2474, 4205 December 1998. 4207 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. 4208 and Weiss, W., "An Architecture for Differentiated 4209 Services", RFC 2475, December 1998. 4211 [RFC2522] Karn, P., and Simpson, W., "Photuris: Session-Key 4212 Management Protocol", RFC 2522, March 1999. 4214 [RFC2983] Black, D., "Differentiated Services and Tunnels", 4215 RFC 2983, October 2000. 4217 [RSA] Rivest, R., Shamir, A., and Adleman, L., "A Method for 4218 Obtaining Digital Signatures and Public-Key 4219 Cryptosystems", Communications of the ACM, v. 21, n. 2, 4220 February 1978. 4222 [SHA] NIST, "Secure Hash Standard", FIPS 180-1, National 4223 Institute of Standards and Technology, U.S. Department 4224 of Commerce, May 1994. 4226 [SIGMA] Krawczyk, H., "SIGMA: the `SIGn-and-MAc' Approach to 4227 Authenticated Diffie-Hellman and its Use in the IKE 4228 Protocols", in Advances in Cryptography - CRYPTO 2003 4229 Proceedings, LNCS 2729, Springer, 2003. Available at: 4230 http://www.ee.technion.ac.il/~hugo/sigma.html 4232 [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange 4233 Mechanism for Internet", from IEEE Proceedings of the 4234 1996 Symposium on Network and Distributed Systems 4235 Security. 4237 [X.501] ITU-T Recommendation X.501: Information Technology - 4238 Open Systems Interconnection - The Directory: Models, 4239 1993. 4241 [X.509] ITU-T Recommendation X.509 (1997 E): Information 4242 Technology - Open Systems Interconnection - The 4243 Directory: Authentication Framework, June 1997. 4245 Appendix A: Summary of changes from IKEv1 4247 The goals of this revision to IKE are: 4249 1) To define the entire IKE protocol in a single document, replacing 4250 RFCs 2407, 2408, and 2409 and incorporating subsequent changes to 4251 support NAT Traversal, Extended Authentication, and Remote Address 4252 acquisition. 4254 2) To simplify IKE by replacing the eight different initial exchanges 4255 with a single four message exchange (with changes in authentication 4256 mechanisms affecting only a single AUTH payload rather than 4257 restructuring the entire exchange); 4259 3) To remove the Domain of Interpretation (DOI), Situation (SIT), and 4260 Labeled Domain Identifier fields, and the Commit and Authentication 4261 only bits; 4263 4) To decrease IKE's latency in the common case by making the initial 4264 exchange be 2 round trips (4 messages), and allowing the ability to 4265 piggyback setup of a CHILD_SA on that exchange; 4267 5) To replace the cryptographic syntax for protecting the IKE 4268 messages themselves with one based closely on ESP to simplify 4269 implementation and security analysis; 4271 6) To reduce the number of possible error states by making the 4272 protocol reliable (all messages are acknowledged) and sequenced. This 4273 allows shortening CREATE_CHILD_SA exchanges from 3 messages to 2; 4275 7) To increase robustness by allowing the responder to not do 4276 significant processing until it receives a message proving that the 4277 initiator can receive messages at its claimed IP address, and not 4278 commit any state to an exchange until the initiator can be 4279 cryptographically authenticated; 4281 8) To fix bugs such as the hash problem documented in [draft-ietf- 4282 ipsec-ike-hash-revised-02.txt]; 4284 9) To specify Traffic Selectors in their own payloads type rather 4285 than overloading ID payloads, and making more flexible the Traffic 4286 Selectors that may be specified; 4288 10) To specify required behavior under certain error conditions or 4289 when data that is not understood is received in order to make it 4290 easier to make future revisions in a way that does not break 4291 backwards compatibility; 4292 11) To incorporate ideas from draft-ietf-ipsec-nat-reqts-04.txt to 4293 allow IKE to negotiate through NAT gateways; 4295 12) To simplify and clarify how shared state is maintained in the 4296 presence of network failures and Denial of Service attacks; and 4298 13) To maintain existing syntax and magic numbers to the extent 4299 possible to make it likely that implementations of IKEv1 can be 4300 enhanced to support IKEv2 with minimum effort. 4302 Appendix B: Diffie-Hellman Groups 4304 There are 5 different Diffie-Hellman groups defined for use in IKE. 4305 These groups were generated by Richard Schroeppel at the University 4306 of Arizona. Properties of these primes are described in [Orm96]. 4308 The strength supplied by group one may not be sufficient for the 4309 mandatory-to-implement encryption algorithm and is here for historic 4310 reasons. 4312 Additional Diffie-Hellman groups have been defined in [ADDGROUP]. 4314 B.1 Group 1 - 768 Bit MODP 4316 This group is assigned id 1 (one). 4318 The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } 4319 Its hexadecimal value is: 4321 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 4322 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 4323 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 4324 A63A3620 FFFFFFFF FFFFFFFF 4326 The generator is 2. 4328 B.2 Group 2 - 1024 Bit MODP 4330 This group is assigned id 2 (two). 4332 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. 4333 Its hexadecimal value is: 4335 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 4336 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 4337 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 4338 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 4339 49286651 ECE65381 FFFFFFFF FFFFFFFF 4341 The generator is 2. 4343 B.3 Group 3 - 155 Bit EC2N 4345 This group is assigned id 3 (three). The curve is based on the Galois 4346 Field GF[2^155]. The field size is 155. The irreducible polynomial 4347 for the field is: 4348 u^155 + u^62 + 1. 4349 The equation for the elliptic curve is: 4351 y^2 + xy = x^3 + ax^2 + b. 4353 Field Size: 155 4354 Group Prime/Irreducible Polynomial: 4355 0x0800000000000000000000004000000000000001 4356 Group Generator One: 0x7b 4357 Group Curve A: 0x0 4358 Group Curve B: 0x07338f 4359 Group Order: 0x0800000000000000000057db5698537193aef944 4361 The data in the KE payload when using this group is the value x from 4362 the solution (x,y), the point on the curve chosen by taking the 4363 randomly chosen secret Ka and computing Ka*P, where * is the 4364 repetition of the group addition and double operations, P is the 4365 curve point with x coordinate equal to generator 1 and the y 4366 coordinate determined from the defining equation. The equation of 4367 curve is implicitly known by the Group Type and the A and B 4368 coefficients. There are two possible values for the y coordinate; 4369 either one can be used successfully (the two parties need not agree 4370 on the selection). 4372 B.4 Group 4 - 185 Bit EC2N 4374 This group is assigned id 4 (four). The curve is based on the Galois 4375 Field GF[2^185]. The field size is 185. The irreducible polynomial 4376 for the field is: 4377 u^185 + u^69 + 1. 4379 The equation for the elliptic curve is: 4380 y^2 + xy = x^3 + ax^2 + b. 4382 Field Size: 185 4383 Group Prime/Irreducible Polynomial: 4384 0x020000000000000000000000000000200000000000000001 4385 Group Generator One: 0x18 4386 Group Curve A: 0x0 4387 Group Curve B: 0x1ee9 4388 Group Order: 0x01ffffffffffffffffffffffdbf2f889b73e484175f94ebc 4390 The data in the KE payload when using this group will be identical to 4391 that as when using Oakley Group 3 (three). 4393 Change History (To be removed from RFC) 4395 H.1 Changes from IKEv2-00 to IKEv2-01 February 2002 4397 1) Changed Appendix B to specify the encryption and authentication 4398 processing for IKE rather than referencing ESP. Simplified the format 4399 by removing idiosyncrasies not needed for IKE. 4401 2) Added option for authentication via a shared secret key. 4403 3) Specified different keys in the two directions of IKE messages. 4404 Removed requirement of different cookies in the two directions since 4405 now no longer required. 4407 4) Change the quantities signed by the two ends in AUTH fields to 4408 assure the two parties sign different quantities. 4410 5) Changed reference to AES to AES_128. 4412 6) Removed requirement that Diffie-Hellman be repeated when rekeying 4413 IKE_SA. 4415 7) Fixed typos. 4417 8) Clarified requirements around use of port 500 at the remote end in 4418 support of NAT. 4420 9) Clarified required ordering for payloads. 4422 10) Suggested mechanisms for avoiding DoS attacks. 4424 11) Removed claims in some places that the first phase 2 piggybacked 4425 on phase 1 was optional. 4427 H.2 Changes from IKEv2-01 to IKEv2-02 April 2002 4429 1) Moved the Initiator CERTREQ payload from message 1 to message 3. 4431 2) Added a second optional ID payload in message 3 for the Initiator 4432 to name a desired Responder to support the case where multiple named 4433 identities are served by a single IP address. 4435 3) Deleted the optimization whereby the Diffie-Hellman group did not 4436 need to be specified in phase 2 if it was the same as in phase 1 (it 4437 complicated the design with no meaningful benefit). 4439 4) Added a section on the implications of reusing Diffie-Hellman 4440 expontentials 4441 5) Changed the specification of sequence numbers to being at 0 in 4442 both directions. 4444 6) Many editorial changes and corrections, the most significant being 4445 a global replace of "byte" with "octet". 4447 H.3 Changes from IKEv2-02 to IKEv2-03 October 2002 4449 1) Reorganized the document moving introductory material to the 4450 front. 4452 2) Simplified the specification of Traffic Selectors to allow only 4453 IPv4 and IPv6 address ranges, as was done in the JFK spec. 4455 3) Fixed the problem brought up by David Faucher with the fix 4456 suggested by Valery Smyslov. If Bob needs to narrow the selector 4457 range, but has more than one matching narrower range, then if Alice's 4458 first selector is a single address pair, Bob chooses the range that 4459 encompasses that. 4461 4) To harmonize with the JFK spec, changed the exchange so that the 4462 initial exchange can be completed in four messages even if the 4463 responder must invoke an anti-clogging defense and the initiator 4464 incorrectly anticipates the responder's choice of Diffie-Hellman 4465 group. 4467 5) Replaced the hierarchical SA payload with a simplified version 4468 that only negotiates suites of cryptographic algorithms. 4470 H.4 Changes from IKEv2-03 to IKEv2-04 January 2003 4472 1) Integrated NAT traversal changes (including Appendix A). 4474 2) Moved the anti-clogging token (cookie) from the SPI to a NOTIFY 4475 payload; changed negotiation back to 6 messages when a cookie is 4476 needed. 4478 3) Made capitalization of IKE_SA and CHILD_SA consistent. 4480 4) Changed how IPComp was negotiated. 4482 5) Added usage scenarios. 4484 6) Added configuration payload for acquiring internal addresses on 4485 remote networks. 4487 7) Added negotiation of tunnel vs transport mode. 4489 H.5 Changes from IKEv2-04 to IKEv2-05 February 2003 4491 1) Shortened Abstract 4493 2) Moved NAT Traversal from Appendix to section 2. Moved changes from 4494 IKEv2 to Appendix A. Renumbered sections. 4496 3) Made language more consistent. Removed most references to Phase 1 4497 and Phase 2. 4499 4) Made explicit the requirements for support of NAT Traversal. 4501 5) Added support for Extended Authentication Protocol methods. 4503 6) Added Response bit to message header. 4505 7) Made more explicit the encoding of Diffie-Hellman numbers in key 4506 expansion algorithms. 4508 8) Added ID payloads to AUTH payload computation. 4510 9) Expanded set of defined cryptographic suites. 4512 10) Added text for MUST/SHOULD support for ID payloads. 4514 11) Added new certificate formats and added MUST/SHOULD text. 4516 12) Clarified use of CERTREQ. 4518 13) Deleted "MUST SUPPORT" column in CP payload specification (it was 4519 inconsistent with surrounding text). 4521 14) Extended and clarified Conformance Requirements section, 4522 including specification of a minimal implementation. 4524 15) Added text to specify ECN handling. 4526 H.6 Changes from IKEv2-05 to IKEv2-06 March 2003 4528 1) Changed the suite based crypto negotiation back to ala carte. 4530 2) Eliminated some awkward page breaks, typographical errors, and 4531 other formatting issues. 4533 3) Tightened language describing cryptographic strength. 4535 4) Added references. 4537 5) Added more specific error codes. 4539 6) Added rationale for unintuitive key generation hash with shared 4540 secret based authentication. 4542 7) Changed the computation of the authenticating AUTH payload as 4543 proposed by Hugo Krawczyk. 4545 8) Changed the dashes (-) to underscores (_) in the names of fields 4546 and constants. 4548 H.7 Changes from IKEv2-06 to IKEv2-07 April 2003 4550 1) Added a list of payload types to section 3.2. 4552 2) Clarified use of SET_WINDOW_SIZE Notify payload. 4554 3) Removed references to COOKIE_REQUIRED Notify payload. 4556 4) Specified how to use a prf with a fixed key size. 4558 5) Removed g^ir from data processed by prf+. 4560 6) Strengthened cautions against using passwords as shared keys. 4562 7) Renamed Protocol_id field SECURITY_PROTOCOL_ID when it is not the 4563 Protocol ID from IP, and changed its values for consistency with 4564 IKEv1. 4566 8) Clarified use of ID payload in access control decisions. 4568 9) Gave IDr and TSr their own payload type numbers. 4570 10) Added Intellectual Property rights section. 4572 11) Clarified some issues in NAT Traversal. 4574 H.8 Changes from IKEv2-07 to IKEv2-08 May 2003 4576 1) Numerous editorial corrections and clarifications. 4578 2) Renamed Gateway to Security Gateway. 4580 3) Made explicit that the ability to rekey SAs without restarting IKE 4581 was optional. 4583 4) Removed last references to MUST and SHOULD ciphersuites. 4585 5) Changed examples to "example.com". 4587 6) Changed references to status codes to status types. 4589 7) Simplified IANA Considerations section 4591 8) Updated References 4593 H.9 Changes from IKEv2-08 to IKEv2-09 August 2003 4595 1) Numerous editorial corrections and clarifications. 4597 2) Added REKEY_SA notify payload to the first message of a 4598 CREATE_CHILD_SA exchange if the new exchange was rekeying an existing 4599 SA. 4601 3) Renamed AES_ENCR128 to AES_ENCR and made it take a single 4602 parameter that is the key size (which may be 128, 192, or 256 bits). 4604 4) Clarified when a newly created SA is useable. 4606 5) Added additional text to section 2.23 specifying how to negotiate 4607 NAT Traversal. 4609 6) Replaced specification of ECN handling with a reference to 4610 [RFC2401bis]. 4612 7) Renumbered payloads so that numbers would not collide with IKEv1 4613 payload numbers in hopes of making code implementing both protocols 4614 simpler. 4616 8) Expanded the Transform ID field (also referred to as Diffie- 4617 Hellman group number) from one byte to two bytes. 4619 9) Removed ability to negotiate Diffie-Hellman groups by explicitly 4620 passing parameters. They must now be negotiated using Transform IDs. 4622 10) Renumbered status codes to be contiguous. 4624 11) Specified the meaning of the "Port" fields in Traffic Selectors 4625 when the ICMP protocol is being used. 4627 12) Removed the specification of D-H Group #5 since it is already 4628 specified in [ADDGROUP. 4630 H.10 Changes from IKEv2-09 to IKEv2-10 August 2003 4632 1) Numerous boilerplate and formatting corrections to comply with RFC 4633 Editorial Guidelines and procedures. 4635 2) Fixed five typographical errors. 4637 3) Added a sentence to the end of "Security considerations" 4638 discouraging the use of non-key-generating EAP mechanisms. 4640 H.11 Changes from IKEv2-10 to IKEv2-11 October 2003 4642 1) Added SHOULD NOT language concerning use of non-key-generating EAP 4643 authentication methods and added reference [EAPMITM]. 4645 2) Clarified use of parallel SAs with identical traffic selectors for 4646 purposes of QoS handling. 4648 3) Fixed description of ECN handling to make normative references to 4649 [RFC 2401bis] and [RFC 3168]. 4651 4) Fixed two typos in the description of NAT traversal. 4653 5) Added specific ASN.1 encoding of certificate bundles in section 4654 3.6. 4656 H.12 Changes from IKEv2-11 to IKEv2-12 January 2004 4658 1) Made the values of the one byte IPsec Protocol ID consistent 4659 between payloads and made the naming more nearly consistent. 4661 2) Changed the specification to require that AUTH payloads be 4662 provided in EAP exchanges even when a non-key generating EAP method 4663 is used. This protects against certain obscure cryptographic 4664 threats. 4666 3) Changed all example IP addresses to be within subnet 10. 4668 4) Specified that issues surrounding weak keys and DES key parity 4669 must be addressed in algorithm documents. 4671 5) Removed the unsupported (and probably untrue) claim that Photuris 4672 cookies were given that name because the IETF always supports 4673 proposals involving cookies. 4675 6) Fixed some text that specified that Transform ID was 1 octet while 4676 everywhere else said it was 2 octets. 4678 7) Corrected the ASN.1 specification of the encoding of X.509 4679 certificate bundles. 4681 8) Added an INVALID_SELECTORS error type. 4683 9) Replaced IANA considerations section with a reference to draft- 4684 ietf-ipsec-ikev2-iana-00.txt. 4686 10) Removed 2 obsolete informative references and added one to a 4687 paper on UDP fragmentation problems. 4689 11) 41 Editorial Corrections and Clarifications. 4691 12) 6 Grammatical and Spelling errors fixed. 4693 13) 4 Corrected capitalizations of MAY/MUST/etc. 4695 14) 4 Attempts to make capitalization and use of underscores more 4696 consistent. 4698 Editor's Address 4700 Charlie Kaufman 4701 Microsoft Corporation 4702 1 Microsoft Way 4703 Redmond, WA 98052 4704 1-425-707-3335 4706 charliek@microsoft.com 4708 Full Copyright Statement 4710 "Copyright (C) The Internet Society (2004). All Rights Reserved. 4712 This document and translations of it may be copied and furnished to 4713 others, and derivative works that comment on or otherwise explain it 4714 or assist in its implementation may be prepared, copied, published 4715 and distributed, in whole or in part, without restriction of any 4716 kind, provided that the above copyright notice and this paragraph are 4717 included on all such copies and derivative works. However, this 4718 document itself may not be modified in any way, such as by removing 4719 the copyright notice or references to the Internet Society or other 4720 Internet organizations, except as needed for the purpose of 4721 developing Internet standards in which case the procedures for 4722 copyrights defined in the Internet Standards process must be 4723 followed, or as required to translate it into languages other than 4724 English. 4726 The limited permissions granted above are perpetual and will not be 4727 revoked by the Internet Society or its successors or assigns. 4729 This document and the information contained herein is provided on an 4730 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 4731 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 4732 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 4733 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 4734 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 4736 Acknowledgement 4738 Funding for the RFC Editor function is currently provided by the 4739 Internet Society. 4741 Expiration 4743 This Internet-Draft (draft-ietf-ipsec-ikev2-12.txt) expires in July 4744 2004.