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