idnits 2.17.1 draft-ietf-ipsec-ikev2-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 96 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 5 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 4231 has weird spacing: '... The equati...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The responder MUST not send a CFG_REPLY without having first received a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS to perform an unnecessary configuration lookup if the IRAC cannot process the REPLY. In the case where the IRAS's configuration requires that CP be used for a given identity IDi, but IRAC has failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and terminate the IKE exchange with a FAILED_CP_REQUIRED error. == 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: ID_RFC822_ADDR 3 A fully-qualified RFC822 email address string, An example of a ID_RFC822_ADDR is, "jsmith@example.com". The string MUST not contain any terminators. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2003) is 7645 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2406' is mentioned on line 157, but not defined ** Obsolete undefined reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) == Missing Reference: 'RFC2402' is mentioned on line 157, but not defined ** Obsolete undefined reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) == Missing Reference: 'RFC2393' is mentioned on line 162, but not defined ** Obsolete undefined reference: RFC 2393 (Obsoleted by RFC 3173) == Missing Reference: 'CERTREQ' is mentioned on line 1357, but not defined == Missing Reference: 'KEi' is mentioned on line 432, but not defined == Missing Reference: 'KEr' is mentioned on line 449, but not defined == Missing Reference: 'CP' is mentioned on line 526, but not defined == Missing Reference: 'RFC 2522' is mentioned on line 800, but not defined == Missing Reference: 'AUTH' is mentioned on line 1367, but not defined == Missing Reference: 'RFC 2401' is mentioned on line 1705, but not defined ** Obsolete undefined reference: RFC 2401 (Obsoleted by RFC 4301) == Missing Reference: 'RFC 3168' is mentioned on line 1713, but not defined == Missing Reference: 'RFC 2474' is mentioned on line 1747, but not defined == Missing Reference: 'RFC 2475' is mentioned on line 1748, but not defined == Missing Reference: 'P' is mentioned on line 2246, but not defined == Unused Reference: 'ESPCBC' is defined on line 3963, but no explicit reference was found in the text == Unused Reference: 'RFC 3280' is defined on line 3966, but no explicit reference was found in the text == Unused Reference: 'Ble98' is defined on line 3973, but no explicit reference was found in the text == Unused Reference: 'BR94' is defined on line 3978, but no explicit reference was found in the text == Unused Reference: 'DES' is defined on line 3982, but no explicit reference was found in the text == Unused Reference: 'DH' is defined on line 3986, but no explicit reference was found in the text == Unused Reference: 'DSS' is defined on line 3993, but no explicit reference was found in the text == Unused Reference: 'HC98' is defined on line 3997, but no explicit reference was found in the text == Unused Reference: 'Hutt02' is defined on line 4000, but no explicit reference was found in the text == Unused Reference: 'IDEA' is defined on line 4004, but no explicit reference was found in the text == Unused Reference: 'Ker01' is defined on line 4012, but no explicit reference was found in the text == Unused Reference: 'KBC96' is defined on line 4015, but no explicit reference was found in the text == Unused Reference: 'MD5' is defined on line 4022, but no explicit reference was found in the text == Unused Reference: 'MSST98' is defined on line 4025, but no explicit reference was found in the text == Unused Reference: 'PKCS1' is defined on line 4035, but no explicit reference was found in the text == Unused Reference: 'PK01' is defined on line 4038, but no explicit reference was found in the text == Unused Reference: 'Pip98' is defined on line 4042, but no explicit reference was found in the text == Unused Reference: 'RFC2474' is defined on line 4054, but no explicit reference was found in the text == Unused Reference: 'RFC2475' is defined on line 4059, but no explicit reference was found in the text == Unused Reference: 'RFC2522' is defined on line 4063, but no explicit reference was found in the text == Unused Reference: 'RFC3168' is defined on line 4066, but no explicit reference was found in the text == Unused Reference: 'RSA' is defined on line 4070, but no explicit reference was found in the text == Unused Reference: 'SHA' is defined on line 4075, but no explicit reference was found in the text == Unused Reference: 'SKEME' is defined on line 4085, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3513 (ref. 'ADDRIPV6') (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 2284 (ref. 'EAP') (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. 'HC98') (Obsoleted by RFC 4306) == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-udp-encaps-05 -- Obsolete informational reference (is this intentional?): RFC 2393 (ref. 'IPCOMP') (Obsoleted by RFC 3173) -- Obsolete informational reference (is this intentional?): RFC 2251 (ref. 'LDAP') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) -- Obsolete informational reference (is this intentional?): RFC 2408 (ref. 'MSST98') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2407 (ref. 'Pip98') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2138 (ref. 'RADIUS') (Obsoleted by RFC 2865) -- Obsolete informational reference (is this intentional?): RFC 1750 (Obsoleted by RFC 4086) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) Summary: 14 errors (**), 0 flaws (~~), 49 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSEC Working Group Charlie Kaufman 3 INTERNET-DRAFT editor 4 draft-ietf-ipsec-ikev2-08.txt May 2003 6 Internet Key Exchange (IKEv2) Protocol 7 9 Status of this Memo 11 This document is a submission by the IPSEC Working Group of the 12 Internet Engineering Task Force (IETF). Comments should be submitted 13 to the ipsec@lists.tislabs.com mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026 [Bra96]. Internet Drafts are 19 working documents of the Internet Engineering Task Force (IETF), its 20 areas, and working groups. Note that other groups may also distribute 21 working documents as Internet Drafts. 23 Internet Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet Drafts as reference 26 material or to cite them other than as "work in progress." 28 To learn the current status of any Internet Draft, please check the 29 "1id-abstracts.txt" listing contained in the Internet Drafts Shadow 30 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 31 munnari.oz.au (Australia), ds.internic.net (US East Coast), or 32 ftp.isi.edu (US West Coast). 34 Abstract 36 This document describes version 2 of the IKE (Internet Key Exchange) 37 protocol. IKE is a component of IPsec used for performing mutual 38 authentication and establishing and maintaining security 39 associations. 41 This version of IKE simplifies the design by removing options that 42 were rarely used and simplifying the encoding. This version of the 43 IKE specification combines the contents of what were previously 44 separate documents, including ISAKMP (RFC 2408), IKE (RFC 2409), the 45 Internet DOI (RFC 2407), NAT Traversal, Legacy authentication, and 46 remote address acquisition. 48 Version 2 of IKE does not interoperate with version 1, but it has 49 enough of the header format in common that both versions can 50 unambiguously run over the same UDP port. 52 Table of Contents 54 Abstract.....................................................1 55 Requirements Terminology.....................................3 56 1 IKE Protocol Overview......................................3 57 1.1 Usage Scenarios..........................................5 58 1.1.1 Security Gateway to Security Gateway Tunnel............5 59 1.1.2 Endpoint to Endpoint Transport.........................6 60 1.1.3 Endpoint to Security Gateway Transport.................6 61 1.1.4 Other Scenarios........................................7 62 1.2 The Initial Exchange.....................................7 63 1.3 The CREATE_CHILD_SA Exchange.............................9 64 1.4 The INFORMATIONAL Exchange..............................10 65 1.5 Informational Messages outside of an IKE_SA.............12 66 2 IKE Protocol Details and Variations.......................12 67 2.1 Use of Retransmission Timers............................12 68 2.2 Use of Sequence Numbers for Message ID..................13 69 2.3 Window Size for overlapping requests....................13 70 2.4 State Synchronization and Connection Timeouts...........14 71 2.5 Version Numbers and Forward Compatibility...............16 72 2.6 Cookies.................................................17 73 2.7 Cryptographic Algorithm Negotiation.....................19 74 2.8 Rekeying................................................20 75 2.9 Traffic Selector Negotiation............................22 76 2.10 Nonces.................................................24 77 2.11 Address and Port Agility...............................24 78 2.12 Reuse of Diffie-Hellman Exponentials...................24 79 2.13 Generating Keying Material.............................25 80 2.14 Generating Keying Material for the IKE_SA..............26 81 2.15 Authentication of the IKE_SA...........................27 82 2.16 Extended Authentication Protocol Methods...............28 83 2.17 Generating Keying Material for CHILD_SAs...............29 84 2.18 Rekeying IKE_SAs using a CREATE_CHILD_SA exchange......30 85 2.19 Requesting an internal address on a remote network.....31 86 2.20 Requesting a Peer's Version............................32 87 2.21 Error Handling.........................................33 88 2.22 IPcomp.................................................34 89 2.23 NAT Traversal..........................................34 90 2.24 ECN Notification.......................................36 91 3 Header and Payload Formats................................37 92 3.1 The IKE Header..........................................37 93 3.2 Generic Payload Header..................................40 94 3.3 Security Association Payload............................42 95 3.3.1 Proposal Substructure.................................44 96 3.3.2 Transform Substructure................................45 97 3.3.3 Mandatory Transform Types.............................48 98 3.3.4 Mandatory Transform IDs...............................48 99 3.3.5 Transform Attributes..................................49 100 3.3.6 Attribute Negotiation.................................52 101 3.4 Key Exchange Payload....................................53 102 3.5 Identification Payloads.................................53 103 3.6 Certificate Payload.....................................55 104 3.7 Certificate Request Payload.............................57 105 3.8 Authentication Payload..................................58 106 3.9 Nonce Payload...........................................59 107 3.10 Notify Payload.........................................60 108 3.10.1 Notify Message Types.................................62 109 3.11 Delete Payload.........................................67 110 3.12 Vendor ID Payload......................................68 111 3.13 Traffic Selector Payload...............................69 112 3.13.1 Traffic Selector.....................................70 113 3.14 Encrypted Payload......................................72 114 3.15 Configuration Payload..................................73 115 3.15.1 Configuration Attributes.............................76 116 3.16 Extended Authentication Protocol (EAP) Payload.........78 117 4 Conformance Requirements..................................80 118 5 Security Considerations...................................82 119 6 IANA Considerations.......................................83 120 7 Intellectual property rights..............................84 121 8 Acknowledgements..........................................84 122 9 References................................................84 123 9.1 Normative References....................................84 124 9.2 Non-normative References................................85 125 Appendix A: Summary of Changes from IKEv1...................88 126 Appendix B: Diffie-Hellman Groups...........................90 127 Change History..............................................93 128 Editor's Address............................................97 129 Full Copyright Statement....................................97 131 Requirements Terminology 133 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 134 "MAY" that appear in this document are to be interpreted as described 135 in [Bra97]. 137 1 IKE Protocol Overview 139 IP Security (IPsec) provides confidentiality, data integrity, access 140 control, and data source authentication to IP datagrams. These 141 services are provided by maintaining shared state between the source 142 and the sink of an IP datagram. This state defines, among other 143 things, the specific services provided to the datagram, which 144 cryptographic algorithms will be used to provide the services, and 145 the keys used as input to the cryptographic algorithms. 147 Establishing this shared state in a manual fashion does not scale 148 well. Therefore a protocol to establish this state dynamically is 149 needed. This memo describes such a protocol-- the Internet Key 150 Exchange (IKE). This is version 2 of IKE. Version 1 of IKE was 151 defined in RFCs 2407, 2408, and 2409. This single document is 152 intended to replace all three of those RFCs. 154 IKE performs mutual authentication between two parties and 155 establishes an IKE security association that includes shared secret 156 information that can be used to efficiently establish SAs for ESP 157 [RFC2406] and/or AH [RFC2402] and a set of cryptographic algorithms 158 to be used to protect the SAs. In this document, the term "suite" or 159 "cryptographic suite" refers to a complete set of algorithms used to 160 protect an SA. An initiator proposes one or more suites by listing 161 supported algorithms that can be combined into suites in a mix and 162 match fashion. IKE can also negotiate use of IPcomp [RFC2393] in 163 connection with an ESP and/or AH SA. We call the IKE SA an "IKE_SA". 164 The SAs for ESP and/or AH that get set up through that IKE_SA we call 165 "CHILD_SA"s. 167 All IKE communications consist of pairs of messages: a request and a 168 response. The pair is called an "exchange". We call the first 169 messages establishing an IKE_SA IKE_SA_INIT and IKE_AUTH exchanges 170 and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL 171 exchanges. In the common case, there is a single IKE_SA_INIT exchange 172 and a single IKE_AUTH exchange (a total of four messages) to 173 establish the IKE_SA and the first CHILD_SA. In exceptional cases, 174 there may be more than one of each of these exchanges. In all cases, 175 all IKE_SA_INIT exchanges MUST complete before any other exchange 176 type, then all IKE_AUTH exchanges MUST complete, and following that 177 any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur 178 in any order. In some scenarios, only a single CHILD_SA is needed 179 between the IPsec endpoints and therefore there would be no 180 additional exchanges. Subsequent exchanges MAY be used to establish 181 additional CHILD_SAs between the same authenticated pair of endpoints 182 and to perform housekeeping functions. 184 IKE message flow always consists of a request followed by a response. 185 It is the responsibility of the requester to ensure reliability. If 186 the response is not received within a timeout interval, the requester 187 needs to retransmit the request (or abandon the connection). 189 The first request/response of an IKE session negotiates security 190 parameters for the IKE_SA, sends nonces, and sends Diffie-Hellman 191 values. We call the initial exchange IKE_SA_INIT (request and 192 response). 194 The second request/response, which we'll call IKE_AUTH transmits 195 identities, proves knowledge of the secrets corresponding to the two 196 identities, and sets up an SA for the first (and often only) AH 197 and/or ESP CHILD_SA. 199 The types of subsequent exchanges are CREATE_CHILD_SA (which creates 200 a CHILD_SA), and INFORMATIONAL (which deletes an SA, reports error 201 conditions, or does other housekeeping). Every request requires a 202 response. An INFORMATIONAL request with no payloads is commonly used 203 as a check for liveness. These subsequent exchanges cannot be used 204 until the initial exchanges have completed. 206 In the description that follows, we assume that no errors occur. 207 Modifications to the flow should errors occur are described in 208 section 2.21. 210 1.1 Usage Scenarios 212 IKE is expected to be used to negotiate ESP and/or AH SAs in a number 213 of different scenarios, each with its own special requirements. 215 1.1.1 Security Gateway to Security Gateway Tunnel 217 +-+-+-+-+-+ +-+-+-+-+-+ 218 ! ! IPsec ! ! 219 Protected !Tunnel ! Tunnel !Tunnel ! Protected 220 Subnet <-->!Endpoint !<---------->!Endpoint !<--> Subnet 221 ! ! ! ! 222 +-+-+-+-+-+ +-+-+-+-+-+ 224 Figure 1: Security Gateway to Security Gateway Tunnel 226 In this scenario, neither endpoint of the IP connection implements 227 IPsec, but network nodes between them protect traffic for part of the 228 way. Protection is transparent to the endpoints, and depends on 229 ordinary routing sending packets through the tunnel endpoints for 230 processing. Each endpoint would announce the set of addresses 231 "behind" it, and packets would be sent in Tunnel Mode where the inner 232 IP header would contain the IP addresses of the actual endpoints. 234 1.1.2 Endpoint to Endpoint Transport 236 +-+-+-+-+-+ +-+-+-+-+-+ 237 ! ! IPsec ! ! 238 !Protected! Tunnel !Protected! 239 !Endpoint !<---------------------------------------->!Endpoint ! 240 ! ! ! ! 241 +-+-+-+-+-+ +-+-+-+-+-+ 243 Figure 2: Endpoint to Endpoint 245 In this scenario, both endpoints of the IP connection implement 246 IPsec. These endpoints may implement application layer access 247 controls based on the authenticated identities of the participants. 248 Transport mode will commonly be used with no inner IP header. If 249 there is an inner IP header, the inner addresses will be the same as 250 the outer addresses. A single pair of addresses will be negotiated 251 for packets to be sent over this SA. 253 It is possible in this scenario that one or both of the protected 254 endpoints will be behind a network address translation (NAT) node, in 255 which case the tunnelled packets will have to be UDP encapsulated so 256 that port numbers in the UDP headers can be used to identify 257 individual endpoints "behind" the NAT. 259 1.1.3 Endpoint to Security Gateway Transport 261 +-+-+-+-+-+ +-+-+-+-+-+ 262 ! ! IPsec ! ! Protected 263 !Protected! Tunnel !Tunnel ! Subnet 264 !Endpoint !<------------------------>!Endpoint !<--- and/or 265 ! ! ! ! Internet 266 +-+-+-+-+-+ +-+-+-+-+-+ 268 Figure 3: Endpoint to Security Gateway Tunnel 270 In this scenario, a protected endpoint (typically a portable roaming 271 computer) connects back to its corporate network through an IPsec 272 protected tunnel. It might use this tunnel only to access information 273 on the corporate network or it might tunnel all of its traffic back 274 through the corporate network in order to take advantage of 275 protection provided by a corporate firewall against Internet based 276 attacks. In either case, the protected endpoint will want an IP 277 address associated with the security gateway so that packets returned 278 to it will go to the security gateway and be tunnelled back. This IP 279 address may be static or may be dynamically allocated by the security 280 gateway. In support of the latter case, IKEv2 includes a mechanism 281 for the initiator to request an IP address owned by the security 282 gateway for use for the duration of its SA. 284 In this scenario, packets will use tunnel mode. On each packet from 285 the protected endpoint, the outer IP header will contain the source 286 IP address associated with its current location (i.e., the address 287 that will get traffic routed to the endpoint directly) while the 288 inner IP header will contain the source IP address assigned by the 289 security gateway (i.e., the address that will get traffic routed to 290 the security gateway for forwarding to the endpoint). The outer 291 destination address will always be that of the security gateway, 292 while the inner destination address will be the ultimate destination 293 for the packet. 295 In this scenario, it is possible that the protected endpoint will be 296 behind a NAT. In that case, the IP address as seen by the security 297 gateway will not be the same as the IP address sent by the protected 298 endpoint, and packets will have to be UDP encapsulated in order to be 299 routed properly. 301 1.1.4 Other Scenarios 303 Other scenarios are possible, as are nested combinations of the 304 above. One notable example combines aspects of 1.1.1 and 1.1.3. A 305 subnet may make all external accesses through a remote security 306 gateway using an IPsec tunnel, where the addresses on the subnet are 307 routed to the security gateway by the rest of the Internet. An 308 example would be someone's home network being virtually on the 309 Internet with static IP addresses even though connectivity is 310 provided by an ISP that assigns a single dynamically assigned IP 311 address to the user's security gateway (where the static IP addresses 312 and an IPsec relay is provided by a third party located elsewhere). 314 1.2 The Initial Exchanges 316 Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH 317 exchanges (known in IKEv1 as Phase 1). These initial exchanges 318 normally consist of four messages, though in some scenarios that 319 number can grow. All communications using IKE consist of 320 request/response pairs. We'll describe the base exchange first, 321 followed by variations. The first pair of messages (IKE_SA_INIT) 322 negotiate cryptographic algorithms, exchange nonces, and do a Diffie- 323 Hellman exchange. 325 The second pair of messages (IKE_AUTH) authenticate the previous 326 messages, exchange identities and certificates, and establish the 327 first CHILD_SA. Parts of these messages are encrypted and integrity 328 protected with keys established through the IKE_SA_INIT exchange, so 329 the identities are hidden from eavesdroppers and all fields in all 330 the messages are authenticated. 332 In the following description, the payloads contained in the message 333 are indicated by names such as SA. The details of the contents of 334 each payload are described later. Payloads which may optionally 335 appear will be shown in brackets, such as [CERTREQ], would indicate 336 that optionally a certificate request payload can be included. 338 The initial exchanges are as follows: 340 Initiator Responder 341 ----------- ----------- 342 HDR, SAi1, KEi, Ni --> 344 HDR contains the SPIs, version numbers, and flags of various sorts. 345 The SAi1 payload states the cryptographic algorithms the Initiator 346 supports for the IKE_SA. The KE payload sends the Initiator's 347 Diffie-Hellman value. Ni is the Initiator's nonce. 349 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 351 The Responder chooses a cryptographic suite from the Initiator's 352 offered choices and expresses that choice in the SAr1 payload, 353 completes the Diffie-Hellman exchange with the KEr payload, and sends 354 its nonce in the Nr payload. 356 At this point in the negotiation each party can generate SKEYSEED, 357 from which all keys are derived for that IKE_SA. All but the headers 358 of all the messages that follow are encrypted and integrity 359 protected. The keys used for the encryption and integrity protection 360 are derived from SKEYSEED and are known as SK_e (encryption) and SK_a 361 (authentication, a.k.a. integrity protection). A separate SK_e and 362 SK_a is computed for each direction. In addition to the keys SK_e 363 and SK_a derived from the DH value for protection of the IKE_SA, 364 another quantity SK_d is derived and used for derivation of further 365 keying material for CHILD_SAs. The notation SK { ... } indicates 366 that these payloads are encrypted and integrity protected using that 367 direction's SK_e and SK_a. 369 HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] 370 AUTH, SAi2, TSi, TSr} --> 372 The Initiator asserts her identity with the IDi payload, proves 373 knowledge of the secret corresponding to IDi and integrity protects 374 the contents of the first two messages using the AUTH payload (see 375 section 2.15). She might also send her certificate(s) in CERT 376 payload(s) and a list of her trust anchors in CERTREQ payload(s). If 377 any CERT payloads are included, the first certificate provided MUST 378 contain the public key used to verify the AUTH field. The optional 379 payload IDr enables Alice to specify which of Bob's identities she 380 wants to talk to. This is useful when Bob is hosting multiple 381 identities at the same IP address. She begins negotiation of a 382 CHILD_SA using the SAi2 payload. The final fields (starting with 383 SAi2) are described in the description of the CREATE_CHILD_SA 384 exchange. 386 <-- HDR, SK {IDr, [CERT,] AUTH, 387 SAr2, TSi, TSr} 389 The Responder asserts his identity with the IDr payload, optionally 390 sends one or more certificates (again with the certificate containing 391 the public key used to verify AUTH listed first), authenticates his 392 identity with the AUTH payload, and completes negotiation of a 393 CHILD_SA with the additional fields described below in the 394 CREATE_CHILD_SA exchange. 396 The recipients of messages 3 and 4 MUST verify that all signatures 397 and MACs are computed correctly and that the names in the ID payloads 398 correspond to the keys used to generate the AUTH payload. 400 1.3 The CREATE_CHILD_SA Exchange 402 This exchange consists of a single request/response pair, and was 403 referred to as a phase 2 exchange in IKEv1. It MAY be initiated by 404 either end of the IKE_SA after the initial exchanges are completed. 406 All messages following the initial exchange are cryptographically 407 protected using the cryptographic algorithms and keys negotiated in 408 the first two messages of the IKE exchange using a syntax described 409 in section 3.14. 411 Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this 412 section the term Initiator refers to the endpoint initiating this 413 exchange. 415 A CHILD_SA is created by sending a CREATE_CHILD_SA request. The 416 CREATE_CHILD_SA request MAY optionally contain a KE payload for an 417 additional Diffie-Hellman exchange to enable stronger guarantees of 418 forward secrecy for the CHILD_SA. The keying material for the 419 CHILD_SA is a function of SK_d established during the establishment 420 of the IKE_SA, the nonces exchanged during the CREATE_CHILD_SA 421 exchange, and the Diffie-Hellman value (if KE payloads are included 422 in the CREATE_CHILD_SA exchange). 424 In the CHILD_SA created as part of the initial exchange, a second KE 425 payload and nonce MUST NOT be sent. The nonces from the initial 426 exchange are used in computing the keys for the CHILD_SA. 428 The CREATE_CHILD_SA request contains: 430 Initiator Responder 431 ----------- ----------- 432 HDR, SK {SA, Ni, [KEi], 433 [TSi, TSr]} --> 435 The Initiator sends SA offer(s) in the SA payload, a nonce in the Ni 436 payload, optionally a Diffie-Hellman value in the KEi payload, and 437 the proposed traffic selectors in the TSi and TSr payloads. If the SA 438 offers include different Diffie-Hellman groups, KEi MUST be an 439 element of the group the Initiator expects the responder to accept. 440 If she guesses wrong, the CREATE_CHILD_SA exchange will fail and she 441 will have to retry with a different KEi. 443 The message following the header is encrypted and the message 444 including the header is integrity protected using the cryptographic 445 algorithms negotiated for the IKE_SA. 447 The CREATE_CHILD_SA response contains: 449 <-- HDR, SK {SA, Nr, [KEr], 450 [TSi, TSr]} 452 The Responder replies (using the same Message ID to respond) with the 453 accepted offer in an SA payload, and a Diffie-Hellman value in the 454 KEr payload if KEi was included in the request and the selected 455 cryptographic suite includes that group. If the responder chooses a 456 cryptographic suite with a different group, it MUST reject the 457 request. The initiator SHOULD repeat the request, but now with a KEi 458 payload from the group the responder selected. 460 The traffic selectors for traffic to be sent on that SA are specified 461 in the TS payloads, which may be a subset of what the Initiator of 462 the CHILD_SA proposed. Traffic selectors are omitted if this 463 CREATE_CHILD_SA request is being used to change the key of the 464 IKE_SA. 466 1.4 The INFORMATIONAL Exchange 468 At various points during the operation of an IKE_SA, peers may desire 469 to convey control messages to each other regarding errors or 470 notifications of certain events. To accomplish this IKE defines an 471 INFORMATIONAL exchange. INFORMATIONAL exchanges MAY ONLY occur after 472 the initial exchanges and are cryptographically protected with the 473 negotiated keys. 475 Control messages that pertain to an IKE_SA MUST be sent under that 476 IKE_SA. Control messages that pertain to CHILD_SAs MUST be sent under 477 the protection of the IKE_SA which generated them (or its successor 478 if the IKE_SA was replaced for the purpose of rekeying). 480 Messages in an INFORMATIONAL Exchange contain zero or more 481 Notification, Delete, and Configuration payloads. The Recipient of an 482 INFORMATIONAL Exchange request MUST send some response (else the 483 Sender will assume the message was lost in the network and will 484 retransmit it). That response MAY be a message with no payloads. The 485 request message in an INFORMATIONAL Exchange MAY also contain no 486 payloads. This is the expected way an endpoint can ask the other 487 endpoint to verify that it is alive. 489 ESP and AH SAs always exist in pairs, with one SA in each direction. 490 When an SA is closed, both members of the pair MUST be closed. When 491 SAs are nested, as when data (and IP headers if in tunnel mode) are 492 encapsulated first with IPcomp, then with ESP, and finally with AH 493 between the same pair of endpoints, all of the SAs MUST be deleted 494 together. Each endpoint MUST close its incoming SAs and allow the 495 other endpoint to close the other SA in each pair. To delete an SA, 496 an INFORMATIONAL Exchange with one or more delete payloads is sent 497 listing the SPIs (as they would be expected in the headers of inbound 498 packets) of the SAs to be deleted. The recipient MUST close the 499 designated SAs. Normally, the reply in the INFORMATIONAL Exchange 500 will contain delete payloads for the paired SAs going in the other 501 direction. There is one exception. If by chance both ends of a set 502 of SAs independently decide to close them, each may send a delete 503 payload and the two requests may cross in the network. If a node 504 receives a delete request for SAs for which it has already issued a 505 delete request, it MUST delete the outgoing SAs while processing the 506 request and the incoming SAs while processing the response. In that 507 case, the responses MUST NOT include delete payloads for the deleted 508 SAs, since that would result in duplicate deletion and could in 509 theory delete the wrong SA. 511 A node SHOULD regard half closed connections as anomalous and audit 512 their existence should they persist. Note that this specification 513 nowhere specifies time periods, so it is up to individual endpoints 514 to decide how long to wait. A node MAY refuse to accept incoming data 515 on half closed connections but MUST NOT unilaterally close them and 516 reuse the SPIs. If connection state becomes sufficiently messed up, a 517 node MAY close the IKE_SA which will implicitly close all SAs 518 negotiated under it. It can then rebuild the SAs it needs on a clean 519 base under a new IKE_SA. 521 The INFORMATIONAL Exchange is defined as: 523 Initiator Responder 524 ----------- ----------- 525 HDR, SK {[N,] [D,] [CP,] ...} --> 526 <-- HDR, SK {[N,] [D,] [CP], ...} 528 The processing of an INFORMATIONAL Exchange is determined by its 529 component payloads. 531 1.5 Informational Messages outside of an IKE_SA 533 If a packet arrives with an unrecognized SPI, it could be because the 534 receiving node has recently crashed and lost state or because of some 535 other system malfunction or attack. If the receiving node has an 536 active IKE_SA to the IP address from whence the packet came, it MAY 537 send a notification of the wayward packet over that IKE_SA. If it 538 does not, it MAY send an Informational message without cryptographic 539 protection to the source IP address and port to alert it to a 540 possible problem. 542 2 IKE Protocol Details and Variations 544 IKE normally listens and sends on UDP port 500, though IKE messages 545 may also be received on UDP port 4500 with a slightly different 546 format (see section 2.23). Since UDP is a datagram (unreliable) 547 protocol, IKE includes in its definition recovery from transmission 548 errors, including packet loss, packet replay, and packet forgery. IKE 549 is designed to function so long as (1) at least one of a series of 550 retransmitted packets reaches its destination before timing out; and 551 (2) the channel is not so full of forged and replayed packets so as 552 to exhaust the network or CPU capacities of either endpoint. Even in 553 the absence of those minimum performance requirements, IKE is 554 designed to fail cleanly (as though the network were broken). 556 2.1 Use of Retransmission Timers 558 All messages in IKE exist in pairs: a request and a response. The 559 setup of an IKE_SA normally consists of two request/response pairs. 560 Once the IKE_SA is set up, either end of the security association may 561 initiate requests at any time, and there can be many requests and 562 responses "in flight" at any given moment. But each message is 563 labelled as either a request or a response and for each 564 request/response pair one end of the security association is the 565 Initiator and the other is the Responder. 567 For every pair of messages, the Initiator is responsible for 568 retransmission in the event of a timeout. The Responder MUST never 569 retransmit a response unless it receives a retransmission of the 570 request. In that event, the Responder MUST ignore the retransmitted 571 request except insofar as it triggers a retransmission of the 572 response. The Initiator MUST remember each request until it receives 573 the corresponding response. The Responder MUST remember each response 574 until it receives a request whose sequence number is larger than the 575 sequence number in the response plus his window size (see section 576 2.3). 578 IKE is a reliable protocol, in the sense that the Initiator MUST 579 retransmit a request until either it receives a corresponding reply 580 OR it deems the IKE security association to have failed and it 581 discards all state associated with the IKE_SA and any CHILD_SAs 582 negotiated using that IKE_SA. 584 2.2 Use of Sequence Numbers for Message ID 586 Every IKE message contains a Message ID as part of its fixed header. 587 This Message ID is used to match up requests and responses, and to 588 identify retransmissions of messages. 590 The Message ID is a 32 bit quantity, which is zero for the first IKE 591 request in each direction. The IKE_SA initial setup messages will 592 always be numbered 0 and 1. Each endpoint in the IKE Security 593 Association maintains two "current" Message IDs: the next one to be 594 used for a request it initiates and the next one it expects to see in 595 a request from the other end. These counters increment as requests 596 are generated and received. Responses always contain the same message 597 ID as the corresponding request. That means that after the initial 598 exchange, each integer n may appear as the message ID in four 599 distinct messages: The nth request from the original IKE Initiator, 600 the corresponding response, the nth request from the original IKE 601 Responder, and the corresponding response. If the two ends make very 602 different numbers of requests, the Message IDs in the two directions 603 can be very different. There is no ambiguity in the messages, 604 however, because the (I)nitiator and (R)esponse bits in the message 605 header specify which of the four messages a particular one is. 607 Note that Message IDs are cryptographically protected and provide 608 protection against message replays. In the unlikely event that 609 Message IDs grow too large to fit in 32 bits, the IKE_SA MUST be 610 closed. Rekeying an IKE_SA resets the sequence numbers. 612 2.3 Window Size for overlapping requests 614 In order to maximize IKE throughput, an IKE endpoint MAY issue 615 multiple requests before getting a response to any of them if the 616 other endpoint has indicated its ability to handle such requests. For 617 simplicity, an IKE implementation MAY choose to process requests 618 strictly in order and/or wait for a response to one request before 619 issuing another. Certain rules must be followed to assure 620 interoperability between implementations using different strategies. 622 After an IKE_SA is set up, either end can initiate one or more 623 requests. These requests may pass one another over the network. An 624 IKE endpoint MUST be prepared to accept and process a request while 625 it has a request outstanding in order to avoid a deadlock in this 626 situation. An IKE endpoint SHOULD be prepared to accept and process 627 multiple requests while it has a request outstanding. 629 An IKE endpoint MUST wait for a response to each of its messages 630 before sending a subsequent message unless it has received a 631 SET_WINDOW_SIZE Notify message from its peer informing it that the 632 peer is prepared to maintain state for multiple outstanding messages 633 in order to allow greater throughput. 635 An IKE endpoint MUST NOT exceed the peer's stated window size for 636 transmitted IKE requests. In other words, if Bob stated his window 637 size is N, then when Alice needs to make a request X, she MUST wait 638 until she has received responses to all requests up through request 639 X-N. An IKE endpoint MUST keep a copy of (or be able to regenerate 640 exactly) each request it has sent until it receives the corresponding 641 response. An IKE endpoint MUST keep a copy of (or be able to 642 regenerate exactly) the number of previous responses equal to its 643 declared window size in case its response was lost and the Initiator 644 requests its retransmission by retransmitting the request. 646 An IKE endpoint supporting a window size greater than one SHOULD be 647 capable of processing incoming requests out of order to maximize 648 performance in the event of network failures or packet reordering. 650 2.4 State Synchronization and Connection Timeouts 652 An IKE endpoint is allowed to forget all of its state associated with 653 an IKE_SA and the collection of corresponding CHILD_SAs at any time. 654 This is the anticipated behavior in the event of an endpoint crash 655 and restart. It is important when an endpoint either fails or 656 reinitializes its state that the other endpoint detect those 657 conditions and not continue to waste network bandwidth by sending 658 packets over discarded SAs and having them fall into a black hole. 660 Since IKE is designed to operate in spite of Denial of Service (DoS) 661 attacks from the network, an endpoint MUST NOT conclude that the 662 other endpoint has failed based on any routing information (e.g., 663 ICMP messages) or IKE messages that arrive without cryptographic 664 protection (e.g., Notify messages complaining about unknown SPIs). An 665 endpoint MUST conclude that the other endpoint has failed only when 666 repeated attempts to contact it have gone unanswered for a timeout 667 period or when a cryptographically protected INITIAL_CONTACT 668 notification is received on a different IKE_SA to the same 669 authenticated identity. An endpoint SHOULD suspect that the other 670 endpoint has failed based on routing information and initiate a 671 request to see whether the other endpoint is alive. To check whether 672 the other side is alive, IKE specifies an empty INFORMATIONAL message 673 that (like all IKE requests) requires an acknowledgment. If a 674 cryptographically protected message has been received from the other 675 side recently, unprotected notifications MAY be ignored. 676 Implementations MUST limit the rate at which they take actions based 677 on unprotected messages. 679 Numbers of retries and lengths of timeouts are not covered in this 680 specification because they do not affect interoperability. It is 681 suggested that messages be retransmitted at least a dozen times over 682 a period of at least several minutes before giving up on an SA, but 683 different environments may require different rules. If there has only 684 been outgoing traffic on all of the SAs associated with an IKE_SA, it 685 is essential to confirm liveness of the other endpoint to avoid black 686 holes. If no cryptographically protected messages have been received 687 on an IKE_SA or any of its CHILD_SAs recently, the system needs to 688 perform a liveness check in order to prevent sending messages to a 689 dead peer. Receipt of a fresh cryptographically protected message on 690 an IKE_SA or any of its CHILD_SAs assures liveness of the IKE_SA and 691 all of its CHILD_SAs. Note that this places requirements on the 692 failure modes of an IKE endpoint. An implementation MUST NOT continue 693 sending on any SA if some failure prevents it from receiving on all 694 of the associated SAs. If CHILD_SAs can fail independently from one 695 another without the associated IKE_SA being able to send a delete 696 message, then they MUST be negotiated by separate IKE_SAs. 698 There is a Denial of Service attack on the Initiator of an IKE_SA 699 that can be avoided if the Initiator takes the proper care. Since the 700 first two messages of an SA setup are not cryptographically 701 protected, an attacker could respond to the Initiator's message 702 before the genuine Responder and poison the connection setup attempt. 703 To prevent this, the Initiator MAY be willing to accept multiple 704 responses to its first message, treat each as potentially legitimate, 705 respond to it, and then discard all the invalid half open connections 706 when she receives a valid cryptographically protected response to any 707 one of her requests. Once a cryptographically valid response is 708 received, all subsequent responses should be ignored whether or not 709 they are cryptographically valid. 711 Note that with these rules, there is no reason to negotiate and agree 712 upon an SA lifetime. If IKE presumes the partner is dead, based on 713 repeated lack of acknowledgment to an IKE message, then the IKE SA 714 and all CHILD_SAs set up through that IKE_SA are deleted. 716 An IKE endpoint may at any time delete inactive CHILD_SAs to recover 717 resources used to hold their state. If an IKE endpoint chooses to do 718 so, it MUST send Delete payloads to the other end notifying it of the 719 deletion. It MAY similarly time out the IKE_SA. Closing the IKE_SA 720 implicitly closes all associated CHILD_SAs. In this case, an IKE 721 endpoint SHOULD send a Delete payload indicating that it has closed 722 the IKE_SA. 724 2.5 Version Numbers and Forward Compatibility 726 This document describes version 2.0 of IKE, meaning the major version 727 number is 2 and the minor version number is zero. It is likely that 728 some implementations will want to support both version 1.0 and 729 version 2.0, and in the future, other versions. 731 The major version number should only be incremented if the packet 732 formats or required actions have changed so dramatically that an 733 older version node would not be able to interoperate with a newer 734 version node if it simply ignored the fields it did not understand 735 and took the actions specified in the older specification. The minor 736 version number indicates new capabilities, and MUST be ignored by a 737 node with a smaller minor version number, but used for informational 738 purposes by the node with the larger minor version number. For 739 example, it might indicate the ability to process a newly defined 740 notification message. The node with the larger minor version number 741 would simply note that its correspondent would not be able to 742 understand that message and therefore would not send it. 744 If an endpoint receives a message with a higher major version number, 745 it MUST drop the message and SHOULD send an unauthenticated 746 notification message containing the highest version number it 747 supports. If an endpoint supports major version n, and major version 748 m, it MUST support all versions between n and m. If it receives a 749 message with a major version that it supports, it MUST respond with 750 that version number. In order to prevent two nodes from being tricked 751 into corresponding with a lower major version number than the maximum 752 that they both support, IKE has a flag that indicates that the node 753 is capable of speaking a higher major version number. 755 Thus the major version number in the IKE header indicates the version 756 number of the message, not the highest version number that the 757 transmitter supports. If A is capable of speaking versions n, n+1, 758 and n+2, and B is capable of speaking versions n and n+1, then they 759 will negotiate speaking n+1, where A will set the flag indicating 760 ability to speak a higher version. If they mistakenly (perhaps 761 through an active attacker sending error messages) negotiate to 762 version n, then both will notice that the other side can support a 763 higher version number, and they MUST break the connection and 764 reconnect using version n+1. 766 Note that IKEv1 does not follow these rules, because there is no way 767 in v1 of noting that you are capable of speaking a higher version 768 number. So an active attacker can trick two v2-capable nodes into 769 speaking v1. When a v2-capable node negotiates down to v1, it SHOULD 770 note that fact in its logs. 772 Also for forward compatibility, all fields marked RESERVED MUST be 773 set to zero by a version 2.0 implementation and their content MUST be 774 ignored by a version 2.0 implementation ("Be conservative in what you 775 send and liberal in what you receive"). In this way, future versions 776 of the protocol can use those fields in a way that is guaranteed to 777 be ignored by implementations that do not understand them. 778 Similarly, payload types that are not defined are reserved for future 779 use and implementations of version 2.0 MUST skip over those payloads 780 and ignore their contents. 782 IKEv2 adds a "critical" flag to each payload header for further 783 flexibility for forward compatibility. If the critical flag is set 784 and the payload type is unrecognized, the message MUST be rejected 785 and the response to the IKE request containing that payload MUST 786 include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an 787 unsupported critical payload was included. If the critical flag is 788 not set and the payload type is unsupported, that payload MUST be 789 ignored. 791 While new payload types may be added in the future and may appear 792 interleaved with the fields defined in this specification, 793 implementations MUST send the payloads defined in this specification 794 in the order shown in the figures in section 2 and implementations 795 SHOULD reject as invalid a message with those payloads in any other 796 order. 798 2.6 Cookies 800 The term "cookies" originates with Karn and Simpson [RFC 2522] in 801 Photuris, an early proposal for key management with IPsec. It has 802 persisted because the IETF has never rejected a proposal involving 803 cookies. The ISAKMP fixed message header includes two eight octet 804 fields titled "cookies", and that syntax is used by both IKEv1 and 805 IKEv2 though in IKEv2 they are referred to as the IKE SPI and there 806 is a new separate field in a Notify payload holding the cookie. The 807 initial two eight octet fields in the header are used as a connection 808 identifier at the beginning of IKE packets. Each endpoint chooses one 809 of the two SPIs and SHOULD choose them so as to be unique identifiers 810 of an IKE_SA. An SPI value of zero is special and indicates that the 811 remote SPI value is not yet known by the sender. 813 Unlike ESP and AH where only the recipient's SPI appears in the 814 header of a message, in IKE the sender's SPI is also sent in every 815 message. Since the SPI chosen by the original initiator of the IKE_SA 816 is always sent first, an endpoint with multiple IKE_SAs open that 817 wants to find the appropriate IKE_SA using the SPI it assigned must 818 look at the I(nitiator) Flag bit in the header to determine whether 819 it assigned the first or the second eight octets. 821 In the first message of an initial IKE exchange, the initiator will 822 not know the responder's SPI value and will therefore set that field 823 to zero. 825 An expected attack against IKE is state and CPU exhaustion, where the 826 target is flooded with session initiation requests from forged IP 827 addresses. This attack can be made less effective if an 828 implementation of a responder uses minimal CPU and commits no state 829 to an SA until it knows the initiator can receive packets at the 830 address from which he claims to be sending them. To accomplish this, 831 a responder SHOULD - when it detects a large number of half-open 832 IKE_SAs - reject initial IKE messages unless they contain a Notify 833 payload of type COOKIE. It SHOULD instead send an unprotected IKE 834 message as a response and include COOKIE Notify payload with the 835 cookie data to be returned. Initiators who receive such responses 836 MUST retry the IKE_SA_INIT with a Notify payload of type COOKIE 837 containing the responder supplied cookie data as the first payload. 838 The initial exchange will then be as follows: 840 Initiator Responder 841 ----------- ----------- 842 HDR(A,0), SAi1, KEi, Ni --> 844 <-- HDR(A,0), N(COOKIE) 846 HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> 848 <-- HDR(A,B), SAr1, KEr, Nr, [CERTREQ] 850 HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,] 851 AUTH, SAi2, TSi, TSr} --> 853 <-- HDR(A,B), SK {IDr, [CERT,] AUTH, 854 SAr2, TSi, TSr} 856 The first two messages do not affect any initiator or responder state 857 except for communicating the cookie. In particular, the message 858 sequence numbers in the first four messages will all be zero and the 859 message sequence numbers in the last two messages will be one. 'A' is 860 the SPI assigned by the initiator, while 'B' is the SPI assigned by 861 the responder. 863 An IKE implementation SHOULD implement its responder cookie 864 generation in such a way as to not require any saved state to 865 recognize its valid cookie when the second IKE_SA_INIT message 866 arrives. The exact algorithms and syntax they use to generate 867 cookies does not affect interoperability and hence is not specified 868 here. The following is an example of how an endpoint could use 869 cookies to implement limited DOS protection. 871 A good way to do this is to set the responder cookie to be: 873 Cookie = | Hash(Ni | IPi | SPIi | ) 875 where is a randomly generated secret known only to the 876 responder and periodically changed. should be 877 changed whenever is regenerated. The cookie can be 878 recomputed when the IKE_SA_INIT arrives the second time and compared 879 to the cookie in the received message. If it matches, the responder 880 knows that SPIr was generated since the last change to and 881 that IPi must be the same as the source address it saw the first 882 time. Incorporating SPIi into the calculation assures that if 883 multiple IKE_SAs are being set up in parallel they will all get 884 different cookies (assuming the initiator chooses unique SPIi's). 885 Incorporating Ni into the hash assures that an attacker who sees only 886 message 2 can't successfully forge a message 3. 888 If a new value for is chosen while there are connections in 889 the process of being initialized, an IKE_SA_INIT might be returned 890 with other than the current . The responder in 891 that case MAY reject the message by sending another response with a 892 new cookie or it MAY keep the old value of around for a 893 short time and accept cookies computed from either one. The 894 responder SHOULD NOT accept cookies indefinitely after is 895 changed, since that would defeat part of the denial of service 896 protection. The responder SHOULD change the value of 897 frequently, especially if under attack. 899 2.7 Cryptographic Algorithm Negotiation 901 The payload type known as "SA" indicates a proposal for a set of 902 choices of protocols (IKE, ESP, and/or AH) for the SA as well as 903 cryptographic algorithms associated with each protocol. 905 An SA consists of one or more proposals. Each proposal includes one 906 or more protocols (usually one). Each protocol contains one or more 907 transforms - each specifying a cryptographic algorithm. Each 908 transform contains zero or more attributes (attributes are only 909 needed if the transform identifier does not completely specify the 910 cryptographic algorithm). 912 This hierarchical structure was designed to be able to efficiently 913 encode proposals for cryptographic suites when the number of 914 supported suites is large because multiple values are acceptable for 915 multiple transforms. The responder MUST choose a single suite, which 916 MAY be any subset of the SA proposal following the rules below: 918 Each proposal contains one or more protocols. If a proposal is 919 accepted, the SA response MUST contain the same protocols in the 920 same order as the proposal. At most one proposal MAY be accepted. 921 (Example: if a single proposal contains ESP and AH and that 922 proposal is accepted, both ESP and AH MUST be accepted. If ESP and 923 AH are included in separate proposals, only one of them MAY be 924 accepted). 926 Each protocol contains one or more transforms. Each transform 927 contains a transform type. The accepted cryptographic suite MUST 928 contain exactly one transform of each type included in the 929 proposal. (Example: if an ESP proposal includes transforms 930 ENCR_3DES, ENCR_AES128, AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the 931 accepted suite MUST contain one of the ENCR_ transforms and one of 932 the AUTH_ transforms. Thus four combinations are acceptable). 934 Since Alice sends her Diffie-Hellman value in the IKE_SA_INIT, she 935 must guess at the Diffie-Hellman group that Bob will select from her 936 list of supported groups. If she guesses wrong, Bob will respond 937 with a Notify payload of type INVALID_KE_PAYLOAD indicating the 938 selected group. In this case, Alice MUST retry the IKE_SA_INIT with 939 the corrected Diffie-Hellman group. Alice MUST again propose her full 940 set of acceptable cryptographic suites because the rejection message 941 was unauthenticated and otherwise an active attacker could trick 942 Alice and Bob into negotiating a weaker suite than a stronger one 943 that they both prefer. 945 2.8 Rekeying 947 IKE, ESP, and AH security associations use secret keys which SHOULD 948 only be used for a limited amount of time and to protect a limited 949 amount of data. This limits the lifetime of the entire security 950 association. When the lifetime of a security association expires the 951 security association must not be used. If there is demand, new 952 security associations MAY be established. Reestablishment of 953 security associations to take the place of ones which expire is 954 referred to as "rekeying". 956 To allow for minimal IPsec implementations, the ability to rekey SAs 957 without restarting the entire IKE_SA is optional. An implementation 958 MAY refuse all CREATE_CHILD_SA requests within an IKE_SA. If an SA 959 has expired or is about to expire and rekeying attempts using the 960 mechanisms described here fail, an implementation MUST close the 961 IKE_SA and any associated CHILD_SAs and them MAY start new ones. 962 Implementations SHOULD support in place rekeying of SAs, since doing 963 so offers better performance and is likely to reduce the number 964 packets lost during the transition. 966 To rekey a CHILD_SA within an existing IKE_SA, create a new, 967 equivalent SA (see section 2.17 below), and when the new one is 968 established, delete the old one. To rekey an IKE_SA, establish a new 969 equivalent IKE_SA (see section 2.18 below) with the peer to whom the 970 old IKE_SA is shared using a CREATE_CHILD_SA within the existing 971 IKE_SA. An IKE_SA so created inherits all of the original IKE_SA's 972 CHILD_SAs. Use the new IKE_SA for all control messages needed to 973 maintain the CHILD_SAs created by the old IKE_SA, and delete the old 974 IKE_SA. The Delete payload to delete itself MUST be the last request 975 sent over an IKE_SA. 977 SAs SHOULD be rekeyed proactively, i.e., the new SA should be 978 established before the old one expires and becomes unusable. Enough 979 time should elapse between the time the new SA is established and the 980 old one becomes unusable so that traffic can be switched over to the 981 new SA. 983 A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes 984 were negotiated. In IKEv2, each end of the SA is responsible for 985 enforcing its own lifetime policy on the SA and rekeying the SA when 986 necessary. If the two ends have different lifetime policies, the end 987 with the shorter lifetime will end up always being the one to request 988 the rekeying. If an SA bundle has been inactive for a long time and 989 if an endpoint would not initiate the SA in the absence of traffic, 990 the endpoint MAY choose to close the SA instead of rekeying it when 991 its lifetime expires. It SHOULD do so if there has been no traffic 992 since the last time the SA was rekeyed. 994 If the two ends have the same lifetime policies, it is possible that 995 both will initiate a rekeying at the same time (which will result in 996 redundant SAs). To reduce the probability of this happening, the 997 timing of rekeying requests SHOULD be jittered (delayed by a random 998 amount of time after the need for rekeying is noticed). 1000 This form of rekeying may temporarily result in multiple similar SAs 1001 between the same pairs of nodes. When there are two SAs eligible to 1002 receive packets, a node MUST accept incoming packets through either 1003 SA. If redundant SAs are created though such a collision, the SA 1004 created with the lowest of the four nonces used in the two exchanges 1005 SHOULD be closed by the endpoint that created it. 1007 The node that initiated the surviving rekeyed SA SHOULD delete the 1008 replaced SA after the new one is established. 1010 2.9 Traffic Selector Negotiation 1012 When an IP packet is received by an RFC2401 compliant IPsec subsystem 1013 and matches a "protect" selector in its SPD, the subsystem MUST 1014 protect that packet with IPsec. When no SA exists yet it is the task 1015 of IKE to create it. Maintenance of a system's SPD is outside the 1016 scope of IKE (see [PFKEY] for an example protocol), though some 1017 implementations might update their SPD in connection with the running 1018 of IKE (for an example scenario, see section 1.1.3). 1020 Traffic Selector (TS) payloads allow endpoints to communicate some of 1021 the information from their SPD to their peers. TS payloads specify 1022 the selection criteria for packets that will be forwarded over the 1023 newly set up SA. This can serve as a consistency check in some 1024 scenarios to assure that the SPDs are consistent. In others, it 1025 guides the dynamic update of the SPD. 1027 Two TS payloads appear in each of the messages in the exchange that 1028 creates a CHILD_SA pair. Each TS payload contains one or more Traffic 1029 Selectors. Each Traffic Selector consists of an address range (IPv4 1030 or IPv6), a port range, and a protocol ID. In support of the scenario 1031 described in section 1.1.3, an initiator may request that the 1032 responder assign an IP address and tell the initiator what it is. 1034 IKEv2 allows the responder to choose a subset of the traffic proposed 1035 by the initiator. This could happen when the configuration of the 1036 two endpoints are being updated but only one end has received the new 1037 information. Since the two endpoints may be configured by different 1038 people, the incompatibility may persist for an extended period even 1039 in the absence of errors. It also allows for intentionally different 1040 configurations, as when one end is configured to tunnel all addresses 1041 and depends on the other end to have the up to date list. 1043 The first of the two TS payloads is known as TSi (Traffic Selector- 1044 initiator). The second is known as TSr (Traffic Selector-responder). 1045 TSi specifies the source address of traffic forwarded from (or the 1046 destination address of traffic forwarded to) the initiator of the 1047 CHILD_SA pair. TSr specifies the destination address of the traffic 1048 forwarded from (or the source address of the traffic forwarded to) 1049 the responder of the CHILD_SA pair. For example, if Alice initiates 1050 the creation of the CHILD_SA pair from Alice to Bob, and wishes to 1051 tunnel all traffic from subnet 10.2.16.* on Alice's side to subnet 1052 18.16.*.* on Bob's side, Alice would include a single traffic 1053 selector in each TS payload. TSi would specify the address range 1054 (10.2.16.0 - 10.2.16.255) and TSr would specify the address range 1055 (18.16.0.0 - 18.16.255.255). Assuming that proposal was acceptable to 1056 Bob, he would send identical TS payloads back. 1058 The Responder is allowed to narrow the choices by selecting a subset 1059 of the traffic, for instance by eliminating or narrowing the range of 1060 one or more members of the set of traffic selectors, provided the set 1061 does not become the NULL set. 1063 It is possible for the Responder's policy to contain multiple smaller 1064 ranges, all encompassed by the Initiator's traffic selector, and with 1065 the Responder's policy being that each of those ranges should be sent 1066 over a different SA. Continuing the example above, Bob might have a 1067 policy of being willing to tunnel those addresses to and from Alice, 1068 but might require that each address pair be on a separately 1069 negotiated CHILD_SA. If Alice generated her request in response to an 1070 incoming packet from 10.2.16.43 to 18.16.2.123, there would be no way 1071 for Bob to determine which pair of addresses should be included in 1072 this tunnel, and he would have to make his best guess or reject the 1073 request with a status of SINGLE_PAIR_REQUIRED. 1075 To enable Bob to choose the appropriate range in this case, if Alice 1076 has initiated the SA due to a data packet, Alice SHOULD include as 1077 the first traffic selector in each of TSi and TSr a very specific 1078 traffic selector including the addresses in the packet triggering the 1079 request. In the example, Alice would include in TSi two traffic 1080 selectors: the first containing the address range (10.2.16.43 - 1081 10.2.16.43) and the source port and protocol from the packet and the 1082 second containing (10.2.16.0 - 10.2.16.255) with all ports and 1083 protocols. She would similarly include two traffic selectors in TSr. 1085 If Bob's policy does not allow him to accept the entire set of 1086 traffic selectors in Alice's request, but does allow him to accept 1087 the first selector of TSi and TSr, then Bob MUST narrow the traffic 1088 selectors to a subset that includes Alice's first choices. In this 1089 example, Bob might respond with TSi being (10.2.16.43 - 10.2.16.43) 1090 with all ports and protocols. 1092 If Alice creates the CHILD_SA pair not in response to an arriving 1093 packet, but rather - say - upon startup, then there may be no 1094 specific addresses Alice prefers for the initial tunnel over any 1095 other. In that case, the first values in TSi and TSr MAY be ranges 1096 rather than specific values, and Bob chooses a subset of Alice's TSi 1097 and TSr that are acceptable to him. If more than one subset is 1098 acceptable but their union is not, Bob MUST accept some subset and 1099 MAY include a Notify payload of type ADDITIONAL_TS_POSSIBLE to 1100 indicate that Alice might want to try again. This case will only 1101 occur when Alice and Bob are configured differently from one another. 1102 If Alice and Bob agree on the granularity of tunnels, she will never 1103 request a tunnel wider than Bob will accept. 1105 2.10 Nonces 1107 The IKE_SA_INIT messages each contain a nonce. These nonces are used 1108 as inputs to cryptographic functions. The CREATE_CHILD_SA request 1109 and the CREATE_CHILD_SA response also contain nonces. These nonces 1110 are used to add freshness to the key derivation technique used to 1111 obtain keys for CHILD_SA, and to extract strong pseudorandom bits 1112 from the Diffie-Hellman key. Nonces used in IKEv2 MUST be randomly 1113 chosen, MUST be at least 128 bits in size, and MUST be at least half 1114 the key size of the negotiated prf. If the same random number source 1115 is used for both keys and nonces, care must be taken to ensure that 1116 the latter use does not compromise the former. 1118 2.11 Address and Port Agility 1120 IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and 1121 AH associations for the same IP addresses it runs over. The IP 1122 addresses and ports in the outer header are, however, not themselves 1123 cryptographically protected, and IKE is designed to work even through 1124 Network Address Translation (NAT) boxes. An implementation MUST 1125 accept incoming connection requests even if not received from UDP 1126 port 500 or 4500, and MUST respond to the address and port from which 1127 the request was received. IKE functions identically over IPv4 or 1128 IPv6. 1130 2.12 Reuse of Diffie-Hellman Exponentials 1132 IKE generates keying material using an ephemeral Diffie-Hellman 1133 exchange in order to gain the property of "perfect forward secrecy". 1134 This means that once a connection is closed and its corresponding 1135 keys are forgotten, even someone who has recorded all of the data 1136 from the connection and gets access to all of the long term keys of 1137 the two endpoints cannot reconstruct the keys used to protect the 1138 conversation. 1140 Achieving perfect forward secrecy requires that when a connection is 1141 closed, each endpoint MUST forget not only the keys used by the 1142 connection but any information that could be used to recompute those 1143 keys. In particular, it MUST forget the secrets used in the Diffie- 1144 Hellman calculation and any state that may persist in the state of a 1145 pseudo-random number generator that could be used to recompute the 1146 Diffie-Hellman secrets. 1148 Since the computing of Diffie-Hellman exponentials is computationally 1149 expensive, an endpoint may find it advantageous to reuse those 1150 exponentials for multiple connection setups. There are several 1151 reasonable strategies for doing this. An endpoint could choose a new 1152 exponential only periodically though this could result in less-than- 1153 perfect forward secrecy if some connection lasts for less than the 1154 lifetime of the exponential. Or it could keep track of which 1155 exponential was used for each connection and delete the information 1156 associated with the exponential only when some corresponding 1157 connection was closed. This would allow the exponential to be reused 1158 without losing perfect forward secrecy at the cost of maintaining 1159 more state. 1161 Decisions as to whether and when to reuse Diffie-Hellman exponentials 1162 is a private decision in the sense that it will not affect 1163 interoperability. An implementation that reuses exponentials MAY 1164 choose to remember the exponential used by the other endpoint on past 1165 exchanges and if one is reused to avoid the second half of the 1166 calculation. 1168 2.13 Generating Keying Material 1170 In the context of the IKE_SA, four cryptographic algorithms are 1171 negotiated: an encryption algorithm, an integrity protection 1172 algorithm, a Diffie-Hellman group, and a pseudo-random function 1173 (prf). The pseudo-random function is used for the construction of 1174 keying material for all of the cryptographic algorithms used in both 1175 the IKE_SA and the CHILD_SAs. 1177 We assume that each encryption algorithm and integrity protection 1178 algorithm uses a fixed size key, and that any randomly chosen value 1179 of that fixed size can serve as an appropriate key. For algorithms 1180 that accept a variable length key, a fixed key size MUST be specified 1181 as part of the cryptographic transform negotiated. For integrity 1182 protection functions based on HMAC, the fixed key size is the size of 1183 the output of the underlying hash function. When the prf function 1184 takes a variable length key, variable length data, and produces a 1185 fixed length output (e.g., when using HMAC), the formulas in this 1186 document apply. When the key for the prf function has fixed length, 1187 the data provided as a key is truncated or padded with zeros as 1188 necessary unless exceptional processing is explained following the 1189 formula. 1191 Keying material will always be derived as the output of the 1192 negotiated prf algorithm. Since the amount of keying material needed 1193 may be greater than the size of the output of the prf algorithm, we 1194 will use the prf iteratively. We will use the terminology prf+ to 1195 describe the function that outputs a pseudo-random stream based on 1196 the inputs to a prf as follows: (where | indicates concatenation) 1198 prf+ (K,S) = T1 | T2 | T3 | T4 | ... 1200 where: 1201 T1 = prf (K, S | 0x01) 1202 T2 = prf (K, T1 | S | 0x02) 1203 T3 = prf (K, T2 | S | 0x03) 1204 T4 = prf (K, T3 | S | 0x04) 1206 continuing as needed to compute all required keys. The keys are taken 1207 from the output string without regard to boundaries (e.g., if the 1208 required keys are a 256 bit AES key and a 160 bit HMAC key, and the 1209 prf function generates 160 bits, the AES key will come from T1 and 1210 the beginning of T2, while the HMAC key will come from the rest of T2 1211 and the beginning of T3). 1213 The constant concatenated to the end of each string feeding the prf 1214 is a single octet. prf+ in this document is not defined beyond 255 1215 times the size of the prf output. 1217 2.14 Generating Keying Material for the IKE_SA 1219 The shared keys are computed as follows. A quantity called SKEYSEED 1220 is calculated from the nonces exchanged during the IKE_SA_INIT 1221 exchange and the Diffie-Hellman shared secret established during that 1222 exchange. SKEYSEED is used to calculate five other secrets: SK_d 1223 used for deriving new keys for the CHILD_SAs established with this 1224 IKE_SA; SK_ai and SK_ar used as a key to the integrity protection 1225 algorithm for authenticating the component messages of subsequent 1226 exchanges; and SK_ei and SK_er used for encrypting (and of course 1227 decrypting) all subsequent exchanges. SKEYSEED and its derivatives 1228 are computed as follows: 1230 SKEYSEED = prf(Ni | Nr, g^ir) 1232 {SK_d, SK_ai, SK_ar, SK_ei, SK_er} 1233 = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) 1235 (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, and SK_er 1236 are taken in order from the generated bits of the prf+). g^ir is the 1237 shared secret from the ephemeral Diffie-Hellman exchange. g^ir is 1238 represented as a string of octets in big endian order padded with 1239 zeros if necessary to make it the length of the modulus. Ni and Nr 1240 are the nonces, stripped of any headers. If the negotiated prf takes 1241 a fixed length key and the lengths of Ni and Nr do not add up to that 1242 length, half the bits must come from Ni and half from Nr, taking the 1243 first bits of each. 1245 The two directions of flow use different keys. The keys used to 1246 protect messages from the original initiator are SK_ai and SK_ei. The 1247 keys used to protect messages in the other direction are SK_ar and 1248 SK_er. Each algorithm takes a fixed number of bits of keying 1249 material, which is specified as part of the algorithm. For integrity 1250 algorithms based on HMAC, the key size is always equal to the length 1251 of the output of the underlying hash function. 1253 2.15 Authentication of the IKE_SA 1255 When not using extended authentication (see section 2.16), the peers 1256 are authenticated by having each sign (or MAC using a shared secret 1257 as the key) a block of data. For the responder, the octets to be 1258 signed start with the first octet of the first SPI in the header of 1259 the second message and end with the last octet of the last payload in 1260 the second message. Appended to this (for purposes of computing the 1261 signature) are the initiator's nonce Ni (just the value, not the 1262 payload containing it), and the value prf(SK_ar,IDr') where IDr' is 1263 the responder's ID payload excluding the fixed header. Note that 1264 neither the nonce Ni nor the value prf(SK_ar,IDr') are transmitted. 1265 Similarly, the initiator signs the first message, starting with the 1266 first octet of the first SPI in the header and ending with the last 1267 octet of the last payload. Appended to this (for purposes of 1268 computing the signature) are the responder's nonce Nr, and the value 1269 prf(SK_ai,IDi'). In the above calculation, IDi' and IDr' are the 1270 entire ID payloads excluding the fixed header. It is critical to the 1271 security of the exchange that each side sign the other side's nonce 1272 (see [SIGMA]). 1274 Note that all of the payloads are included under the signature, 1275 including any payload types not defined in this document. If the 1276 first message of the exchange is sent twice (the second time with a 1277 responder cookie and/or a different Diffie-Hellman group), it is the 1278 second version of the message that is signed. 1280 Optionally, messages 3 and 4 MAY include a certificate, or 1281 certificate chain providing evidence that the key used to compute a 1282 digital signature belongs to the name in the ID payload. The 1283 signature or MAC will be computed using algorithms dictated by the 1284 type of key used by the signer, and specified by the Auth Method 1285 field in the Authentication payload. There is no requirement that 1286 the Initiator and Responder sign with the same cryptographic 1287 algorithms. The choice of cryptographic algorithms depends on the 1288 type of key each has. In particular, the initiator may be using a 1289 shared key while the responder may have a public signature key and 1290 certificate. It will commonly be the case (but it is not required) 1291 that if a shared secret is used for authentication that the same key 1292 is used in both directions. Note that it is a common but typically 1293 insecure practice to have a shared key derived solely from a user 1294 chosen password without incorporating another source of randomness. 1295 This is typically insecure because user chosen passwords are unlikely 1296 to have sufficient unpredictability to resist dictionary attacks and 1297 these attacks are not prevented in this authentication method. 1298 (Applications using password-based authentication for bootstrapping 1299 and IKE_SA should use the authentication method in section 2.16, 1300 which is designed to prevent off-line dictionary attacks). The pre- 1301 shared key SHOULD contain as much unpredictability as the strongest 1302 key being negotiated. In the case of a pre-shared key, the AUTH 1303 value is computed as: 1305 AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), ) 1308 where the string "Key Pad for IKEv2" is ASCII encoded and not null 1309 terminated. The shared secret can be variable length. The pad string 1310 is added so that if the shared secret is derived from a password, the 1311 IKE implementation need not store the password in cleartext, but 1312 rather can store the value prf(Shared Secret,"Key Pad for IKEv2"), 1313 which could not be used as a password equivalent for protocols other 1314 than IKEv2. As noted above, deriving the shared secret from a 1315 password is not secure. This construction is used because it is 1316 anticipated that people will do it anyway. The management interface 1317 by which the Shared Secret is provided MUST accept ASCII strings of 1318 at least 64 octets and MUST NOT add a null terminator before using 1319 them as shared secrets. The management interface MAY accept other 1320 forms, like hex encoding. If the negotiated prf takes a fixed size 1321 key, the shared secret MUST be of that fixed size. 1323 2.16 Extended Authentication Protocol Methods 1325 In addition to authentication using public key signatures and shared 1326 secrets, IKE supports authentication using methods defined in RFC 1327 2284 [EAP]. Typically, these methods are asymmetric (designed for a 1328 user authenticating to a server), and they may not be mutual. For 1329 this reason, these protocols are typically used to authenticate the 1330 initiator to the responder and are used in addition to a public key 1331 signature based authentication of the responder to the initiator. 1332 These methods are also referred to as "Legacy Authentication" 1333 mechanisms. 1335 While this memo references [EAP] with the intent that new methods can 1336 be added in the future without updating this specification, the 1337 protocols expected to be used most commonly are fully documented here 1338 and in section 3.16. [EAP] defines an authentication protocol 1339 requiring a variable number of messages. Extended Authentication is 1340 implemented in IKE as additional IKE_AUTH exchanges that MUST be 1341 completed in order to initialize the IKE_SA. 1343 An initiator indicates a desire to use extended authentication by 1344 leaving out the AUTH payload from message 3. By including an IDi 1345 payload but not an AUTH payload, the initiator has declared an 1346 identity but has not proven it. If the responder is willing to use an 1347 extended authentication method, it will place an EAP payload in 1348 message 4 and defer sending SAr2, TSi, and TSr until initiator 1349 authentication is complete in a subsequent IKE_AUTH exchange. In the 1350 case of a minimal extended authentication, the initial SA 1351 establishment will appear as follows: 1353 Initiator Responder 1354 ----------- ----------- 1355 HDR, SAi1, KEi, Ni --> 1357 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 1359 HDR, SK {IDi, [CERTREQ,] [IDr,] 1360 SAi2, TSi, TSr} --> 1362 <-- HDR, SK {IDr, [CERT,] AUTH, 1363 EAP } 1365 HDR, SK {EAP, [AUTH] } --> 1367 <-- HDR, SK {EAP, [AUTH], 1368 SAr2, TSi, TSr } 1370 For EAP methods that create a shared key as a side effect of 1371 authentication, that shared key MUST be used by both the Initiator 1372 and Responder to generate an AUTH payload using the syntax for shared 1373 secrets specified in section 2.15. The shared key generated during an 1374 IKE exchange MUST NOT be used for any other purpose. For EAP methods 1375 that do not establish a shared key, there will be no AUTH payloads in 1376 the final messages. 1378 The Initiator of an IKE_SA using EAP SHOULD be capable of extending 1379 the initial protocol exchange to at least ten IKE_AUTH exchanges in 1380 the event the Responder sends notification messages and/or retries 1381 the authentication prompt. The protocol terminates when the Responder 1382 sends the Initiator an EAP payload containing either a success or 1383 failure type. 1385 2.17 Generating Keying Material for CHILD_SAs 1387 CHILD_SAs are created either by being piggybacked on the IKE_AUTH 1388 exchange, or in a CREATE_CHILD_SA exchange. Keying material for them 1389 is generated as follows: 1391 KEYMAT = prf+(SK_d, Ni | Nr) 1393 Where Ni and Nr are the Nonces from the IKE_SA_INIT exchange if this 1394 request is the first CHILD_SA created or the fresh Ni and Nr from the 1395 CREATE_CHILD_SA exchange if this is a subsequent creation. 1397 For CREATE_CHILD_SA exchanges with PFS the keying material is defined 1398 as: 1400 KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr ) 1402 where g^ir (new) is the shared secret from the ephemeral Diffie- 1403 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 1404 octet string in big endian order padded with zeros if necessary to 1405 make it the length of the modulus), 1407 A single CHILD_SA negotiation may result in multiple security 1408 associations. ESP and AH SAs exist in pairs (one in each direction), 1409 and four SAs could be created in a single CHILD_SA negotiation if a 1410 combination of ESP and AH is being negotiated. 1412 Keying material is taken from the expanded KEYMAT in the following 1413 order: 1415 All keys for SAs carrying data from the initiator to the responder 1416 are taken before SAs going in the reverse direction. 1418 If multiple protocols are negotiated, keying material is taken in 1419 the order in which the protocol headers will appear in the 1420 encapsulated packet. 1422 If a single protocol has both encryption and authentication keys, 1423 the encryption key is taken from the first octets of KEYMAT and 1424 the authentication key is taken from the next octets. 1426 Each cryptographic algorithm takes a fixed number of bits of keying 1427 material specified as part of the algorithm. 1429 2.18 Rekeying IKE_SAs using a CREATE_CHILD_SA exchange 1431 The CREATE_CHILD_SA exchange can be used to re-key an existing IKE_SA 1432 (see section 2.8). New Initiator and Responder SPIs are supplied in 1433 the SPI fields. The TS payloads are omitted when rekeying an IKE_SA. 1434 SKEYSEED for the new IKE_SA is computed using SK_d from the existing 1435 IKE_SA as follows: 1437 SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr) 1439 where g^ir (new) is the shared secret from the ephemeral Diffie- 1440 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 1441 octet string in big endian order padded with zeros if necessary to 1442 make it the length of the modulus) and Ni and Nr are the two nonces 1443 stripped of any headers. 1445 The new IKE_SA MUST reset its message counters to 0. 1447 SK_d, SK_ai, SK_ar, and SK_ei, and SK_er are computed from SKEYSEED 1448 as specified in section 2.14. 1450 2.19 Requesting an internal address on a remote network 1452 Most commonly occurring in the endpoint to security gateway scenario, 1453 an endpoint may need an IP address in the network protected by the 1454 security gateway, and may need to have that address dynamically 1455 assigned. A request for such a temporary address can be included in 1456 any request to create a CHILD_SA (including the implicit request in 1457 message 3) by including a CP payload. 1459 This function provides address allocation to an IRAC (IPsec Remote 1460 Access Client) trying to tunnel into a network protected by an IRAS 1461 (IPsec Remote Access Server). Since the IKE_AUTH exchange creates an 1462 IKE_SA and a CHILD_SA, the IRAC MUST request the IRAS controlled 1463 address (and optionally other information concerning the protected 1464 network) in the IKE_AUTH exchange. The IRAS may procure an address 1465 for the IRAC from any number of sources such as a DHCP/BOOTP server 1466 or its own address pool. 1468 Initiator Responder 1469 ----------------------------- --------------------------- 1470 HDR, SK {IDi, [CERT,] [CERTREQ,] 1471 [IDr,] AUTH, CP(CFG_REQUEST), 1472 SAi2, TSi, TSr} --> 1474 <-- HDR, SK {IDr, [CERT,] AUTH, 1475 CP(CFG_REPLY), SAr2, 1476 TSi, TSr} 1478 In all cases, the CP payload MUST be inserted before the SA payload. 1479 In variations of the protocol where there are multiple IKE_AUTH 1480 exchanges, the CP payloads MUST be inserted in the messages 1481 containing the SA payloads. 1483 CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute 1484 (either IPv4 or IPv6) but MAY contain any number of additional 1485 attributes the initiator wants returned in the response. 1487 For example, message from Initiator to Responder: 1488 CP(CFG_REQUEST)= 1489 INTERNAL_ADDRESS(0.0.0.0) 1490 INTERNAL_NETMASK(0.0.0.0) 1491 INTERNAL_DNS(0.0.0.0) 1492 TSi = (0, 0-65536,0.0.0.0-255.255.255.255) 1493 TSr = (0, 0-65536,0.0.0.0-255.255.255.255) 1495 NOTE: Traffic Selectors are a (protocol, port range, address range) 1497 Message from Responder to Initiator: 1499 CP(CFG_REPLY)= 1500 INTERNAL_ADDRESS(192.168.219.202) 1501 INTERNAL_NETMASK(255.255.255.0) 1502 INTERNAL_SUBNET(192.168.219.0/255.255.255.0) 1503 TSi = (0, 0-65536,192.168.219.202-192.168.219.202) 1504 TSr = (0, 0-65536,192.168.219.0-192.168.219.255) 1506 All returned values will be implementation dependent. As can be seen 1507 in the above example, the IRAS MAY also send other attributes that 1508 were not included in CP(CFG_REQUEST) and MAY ignore the non- 1509 mandatory attributes that it does not support. 1511 The responder MUST not send a CFG_REPLY without having first received 1512 a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS 1513 to perform an unnecessary configuration lookup if the IRAC cannot 1514 process the REPLY. In the case where the IRAS's configuration 1515 requires that CP be used for a given identity IDi, but IRAC has 1516 failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and 1517 terminate the IKE exchange with a FAILED_CP_REQUIRED error. 1519 2.20 Requesting the Peer's Version 1521 An IKE peer wishing to inquire about the other peer's IKE software 1522 version information MAY use the method below. This is an example of 1523 a configuration request within an INFORMATIONAL Exchange, after the 1524 IKE_SA and first CHILD_SA have been created. 1526 An IKE implementation MAY decline to give out version information 1527 prior to authentication or even after authentication to prevent 1528 trolling in case some implementation is known to have some security 1529 weakness. In that case, it MUST either return an empty string or no 1530 CP payload if CP is not supported. 1532 Initiator Responder 1534 ----------------------------- -------------------------- 1535 HDR, SK{CP(CFG_REQUEST)} --> 1536 <-- HDR, SK{CP(CFG_REPLY)} 1538 CP(CFG_REQUEST)= 1539 APPLICATION_VERSION("") 1541 CP(CFG_REPLY) 1542 APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar Inc.") 1544 2.21 Error Handling 1546 There are many kinds of errors that can occur during IKE processing. 1547 If a request is received that is badly formatted or unacceptable for 1548 reasons of policy (e.g., no matching cryptographic algorithms), the 1549 response MUST contain a Notify payload indicating the error. If an 1550 error occurs outside the context of an IKE request (e.g., the node is 1551 getting ESP messages on a nonexistent SPI), the node SHOULD initiate 1552 an INFORMATIONAL Exchange with a Notify payload describing the 1553 problem. 1555 Errors that occur before a cryptographically protected IKE_SA is 1556 established must be handled very carefully. There is a trade-off 1557 between wanting to be helpful in diagnosing a problem and responding 1558 to it and wanting to avoid being a dupe in a denial of service attack 1559 based on forged messages. 1561 If a node receives a message on UDP port 500 outside the context of 1562 an IKE_SA known to it (and not a request to start one), it may be the 1563 result of a recent crash of the node. If the message is marked as a 1564 response, the node MAY audit the suspicious event but MUST NOT 1565 respond. If the message is marked as a request, the node MAY audit 1566 the suspicious event and MAY send a response. If a response is sent, 1567 the response MUST be sent to the IP address and port from whence it 1568 came with the same IKE SPIs and the Message ID copied. The response 1569 MUST NOT be cryptographically protected and MUST contain a Notify 1570 payload indicating INVALID_IKE_SPI. 1572 A node receiving such an unprotected Notify payload MUST NOT respond 1573 and MUST NOT change the state of any existing SAs. The message might 1574 be a forgery or might be a response the genuine correspondent was 1575 tricked into sending. A node SHOULD treat such a message (and also a 1576 network message like ICMP destination unreachable) as a hint that 1577 there might be problems with SAs to that IP address and SHOULD 1578 initiate a liveness test for any such IKE_SA. An implementation 1579 SHOULD limit the frequency of such tests to avoid being tricked into 1580 participating in a denial of service attack. 1582 A node receiving a suspicious message from an IP address with which 1583 it has an IKE_SA MAY send an IKE Notify payload in an IKE 1584 INFORMATIONAL exchange over that SA. The recipient MUST NOT change 1585 the state of any SA's as a result but SHOULD audit the event to aid 1586 in diagnosing malfunctions. A node MUST limit the rate at which it 1587 will send messages in response to unprotected messages. 1589 2.22 IPcomp 1591 Use of IP compression [IPCOMP] can be negotiated as part of the setup 1592 of a CHILD_SA. While IP compression involves an extra header in each 1593 packet and a CPI (compression parameter index), the virtual 1594 "compression association" has no life outside the ESP or AH SA that 1595 contains it. Compression associations disappear when the 1596 corresponding ESP or AH SA goes away, and is not explicitly mentioned 1597 in any DELETE payload. 1599 Negotiation of IP compression is separate from the negotiation of 1600 cryptographic parameters associated with a CHILD_SA. A node 1601 requesting a CHILD_SA MAY advertise its support for one or more 1602 compression algorithms though one or more Notify payloads of type 1603 IPCOMP_SUPPORTED. The response MAY indicate acceptance of a single 1604 compression algorithm with a Notify payload of type IPCOMP_SUPPORTED. 1605 These payloads MAY ONLY occur in the same messages that contain SA 1606 payloads. 1608 While there has been discussion of allowing multiple compression 1609 algorithms to be accepted and to have different compression 1610 algorithms available for the two directions of a CHILD_SA, 1611 implementations of this specification MUST NOT accept an IPcomp 1612 algorithm that was not proposed, MUST NOT accept more than one, and 1613 MUST NOT compress using an algorithm other than one proposed and 1614 accepted in the setup of the CHILD_SA. 1616 A side effect of separating the negotiation of IPcomp from 1617 cryptographic parameters is that it is not possible to propose 1618 multiple cryptographic suites and propose IP compression with some of 1619 them but not others. 1621 2.23 NAT Traversal 1623 NAT (Network Address Translation) gateways are a controversial 1624 subject. This section briefly describes what they are and how they 1625 are likely to act on IKE traffic. Many people believe that NATs are 1626 evil and that we should not design our protocols so as to make them 1627 work better. IKEv2 does specify some unintuitive processing rules in 1628 order that NATs are more likely to work. 1630 NATs exist primarily because of the shortage of IPv4 addresses, 1631 though there are other rationales. IP nodes that are "behind" a NAT 1632 have IP addresses that are not globally unique, but rather are 1633 assigned from some space that is unique within the network behind the 1634 NAT but which are likely to be reused by nodes behind other NATs. 1635 Generally, nodes behind NATs can communicate with other nodes behind 1636 the same NAT and with nodes with globally unique addresses, but not 1637 with nodes behind other NATs. There are exceptions to that rule. 1638 When those nodes make connections to nodes on the real Internet, the 1639 NAT gateway "translates" the IP source address to an address that 1640 will be routed back to the gateway. Messages to the gateway from the 1641 Internet have their destination addresses "translated" to the 1642 internal address that will route the packet to the correct endnode. 1644 NATs are designed to be "transparent" to endnodes. Neither software 1645 on the node behind the NAT nor the node on the Internet require 1646 modification to communicate through the NAT. Achieving this 1647 transparency is more difficult with some protocols than with others. 1648 Protocols that include IP addresses of the endpoints within the 1649 payloads of the packet will fail unless the NAT gateway understands 1650 the protocol and modifies the internal references as well as those in 1651 the headers. Such knowledge is inherently unreliable, is a network 1652 layer violation, and often results in subtle problems. 1654 Opening an IPsec connection through a NAT introduces special 1655 problems. If the connection runs in transport mode, changing the IP 1656 addresses on packets will cause the checksums to fail and the NAT 1657 cannot correct the checksums because they are cryptographically 1658 protected. Even in tunnel mode, there are routing problems because 1659 transparently translating the addresses of AH and ESP packets 1660 requires special logic in the NAT and that logic is heuristic and 1661 unreliable in nature. For that reason, IKEv2 can negotiate UDP 1662 encapsulation of IKE, ESP, and AH packets. This encoding is slightly 1663 less efficient but is easier for NATs to process. In addition, 1664 firewalls may be configured to pass IPsec traffic over UDP but not 1665 ESP/AH or vice versa. 1667 It is a common practice of NATs to translate TCP and UDP port numbers 1668 as well as addresses and use the port numbers of inbound packets to 1669 decide which internal node should get a given packet. For this 1670 reason, even though IKE packets MUST be sent from and to UDP port 1671 500, they MUST be accepted coming from any port and responses MUST be 1672 sent to the port from whence they came. This is because the ports may 1673 be modified as the packets pass through NATs. Similarly, IP addresses 1674 of the IKE endpoints are generally not included in the IKE payloads 1675 because the payloads are cryptographically protected and could not be 1676 transparently modified by NATs. 1678 Port 4500 is reserved for UDP encapsulated ESP, AH, and IKE. When 1679 working through a NAT, it is generally better to pass IKE packets 1680 over port 4500 because some older NATs modify IKE traffic on port 500 1681 in an attempt to transparently establish IPsec connections. Such NATs 1682 may interfere with the straightforward NAT traversal envisioned by 1683 this document, so an IPsec endpoint that discovers a NAT between it 1684 and its correspondent MUST send all subsequent traffic to and from 1685 port 4500, which NATs should not treat specially (as they might with 1686 port 500). 1688 The specific requirements for supporting NAT traversal are listed 1689 below. Support for NAT traversal is optional. In this section only, 1690 requirements listed as MUST only apply to implementations supporting 1691 NAT traversal. 1693 IKE MUST listen on port 4500 as well as port 500. IKE MUST respond 1694 to the IP address and port from which packets arrived. 1696 The IKE responder MUST include in its IKE_SA_INIT response Notify 1697 payloads of type NAT_DETECTION_SOURCE_IP and 1698 NAT_DETECTION_DESTINATION_IP. The IKE initiator MUST check these 1699 payloads if present and if they do not match the addresses in the 1700 outer packet MUST tunnel all future IKE, ESP, and AH packets 1701 associated with this IKE_SA over UDP port 4500. 1703 2.24 ECN Notification 1705 Sections 5.1.2.1 and 5.1.2.2 of [RFC 2401] specify that the IPv4 TOS 1706 octet and IPv6 traffic class octet are to be copied from the inner 1707 header to the outer header by the encapsulator and that the outer 1708 header is to be discarded (no change to inner header) by the 1709 decapsulator. If ECN (see [RFC 3168]) is in use, ECT codepoints will 1710 be copied to the outer header, but if a router within the tunnel 1711 changes an ECT codepoint to a CE codepoint to indicate congestion, 1712 that indication will be discarded by the decapsulator. This behavior 1713 is highly undesirable, and Section 9.2 of [RFC 3168] specifies 1714 changes to IPsec to avoid it. These changes include two ECN 1715 operating modes and negotiation support to detect and cope with IPsec 1716 decapsulators that discard ECN congestion indications; use of ECN in 1717 the outer IP header of IPsec tunnels is not permitted when such 1718 discarding is a possibility. 1720 In order to avoid multiple ECN operating modes and negotiation, 1721 tunnel decapsulators for tunnel-mode Security Associations (SAs) 1722 created by IKEv2 MUST implement the following modifications to 1723 prevent discarding of ECN congestion indications. IKEv2 tunnel-mode 1724 SA negotiation is handled by the USE_TRANSPORT_MODE Notify message 1725 type (see Section 3.10.1). The following modifications *replace* 1726 Section 9.2 of RFC 3168 and *update* Sections 5.1.2.1 and 5.1.2.2 of 1727 RFC 2401. 1729 Encapsulation and Decapsulation of packets for a tunnel-mode SA 1730 created by IKEv2 MUST NOT follow the modifications specified by 1731 Section 9.2 of RFC 3168 and its subsections. Instead, the following 1732 modifications to encapsulation and decapsulation in Sections 5.1.2.1 1733 and 5.1.2.2 of RFC 2401 MUST be performed: 1735 Outer Hdr at Inner Hdr at 1736 IPv4 Encapsulator Decapsulator 1737 Header fields: -------------------- ------------ 1738 DS Field copied from inner hdr (5) no change 1739 ECN Field copied from inner hdr constructed (7) 1740 IPv6 1741 Header fields: 1742 DS Field copied from inner hdr (6) no change 1743 ECN Field copied from inner hdr constructed (7) 1745 (5)(6) If the packet will immediately enter a domain for which the 1746 DSCP value in the outer header is not appropriate, that value MUST 1747 be mapped to an appropriate value for the domain [RFC 2474]. Also 1748 see [RFC 2475] for further information. 1750 (7) If the ECN field in the inner header is set to ECT(0) or 1751 ECT(1) and the ECN field in the outer header is set to CE, then 1752 set the ECN field in the inner header to CE, otherwise make no 1753 change to the ECN field in the inner header. 1755 (5) and (6) are identical to match usage in [RFC2401], although 1756 they are different in [RFC2401]. These actions are not related to 1757 ECN, but are required for Differentiated Services support. They 1758 are carried over to this document from RFC 3168 so that all of RFC 1759 3168's changes to IPsec can be made non-applicable to SAs created 1760 by IKEv2. 1762 3 Header and Payload Formats 1764 3.1 The IKE Header 1766 IKE messages use UDP ports 500 and/or 4500, with one IKE message per 1767 UDP datagram. Information from the UDP header is largely ignored 1768 except that the IP addresses and UDP ports from the headers are 1769 reversed and used for return packets. When sent on UDP port 500, IKE 1770 messages begin immediately following the UDP header. When sent on UDP 1771 port 4500, IKE messages have prepended four octets of zero. These 1772 four octets of zero are not part of the IKE message and are not 1773 included in any of the length fields or checksums defined by IKE. 1774 Each IKE message begins with the IKE header, denoted HDR in this 1775 memo. Following the header are one or more IKE payloads each 1776 identified by a "Next Payload" field in the preceding payload. 1777 Payloads are processed in the order in which they appear in an IKE 1778 message by invoking the appropriate processing routine according to 1779 the "Next Payload" field in the IKE header and subsequently according 1780 to the "Next Payload" field in the IKE payload itself until a "Next 1781 Payload" field of zero indicates that no payloads follow. If a 1782 payload of type "Encrypted" is found, that payload is decrypted and 1783 its contents parsed as additional payloads. An Encrypted payload MUST 1784 be the last payload in a packet and an encrypted payload MUST NOT 1785 contain another encrypted payload. 1787 The Recipient SPI in the header identifies an instance of an IKE 1788 security association. It is therefore possible for a single instance 1789 of IKE to multiplex distinct sessions with multiple peers. 1791 All multi-octet fields representing integers are laid out in big 1792 endian order (aka most significant byte first, or network byte 1793 order). 1795 The format of the IKE header is shown in Figure 4. 1796 1 2 3 1797 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 1798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 ! IKE_SA Initiator's SPI ! 1800 ! ! 1801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1802 ! IKE_SA Responder's SPI ! 1803 ! ! 1804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1805 ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! 1806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1807 ! Message ID ! 1808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1809 ! Length ! 1810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1812 Figure 4: IKE Header Format 1814 o Initiator's SPI (8 octets) - A value chosen by the 1815 initiator to identify a unique IKE security association. This 1816 value MUST NOT be zero. 1818 o Responder's SPI (8 octets) - A value chosen by the 1819 responder to identify a unique IKE security association. This 1820 value MUST be zero in the first message of an IKE Initial 1821 Exchange (including repeats of that message including a 1822 cookie) and MUST NOT be zero in any other message. 1824 o Next Payload (1 octet) - Indicates the type of payload that 1825 immediately follows the header. The format and value of each 1826 payload is defined below. 1828 o Major Version (4 bits) - indicates the major version of the IKE 1829 protocol in use. Implementations based on this version of IKE 1830 MUST set the Major Version to 2. Implementations based on 1831 previous versions of IKE and ISAKMP MUST set the Major Version 1832 to 1. Implementations based on this version of IKE MUST reject 1833 or ignore messages containing a version number greater than 1834 2. 1836 o Minor Version (4 bits) - indicates the minor version of the 1837 IKE protocol in use. Implementations based on this version of 1838 IKE MUST set the Minor Version to 0. They MUST ignore the minor 1839 version number of received messages. 1841 o Exchange Type (1 octet) - indicates the type of exchange being 1842 used. This constrains the payloads sent in each message and 1843 orderings of messages in an exchange. 1845 Exchange Type Value 1847 RESERVED 0 1848 Reserved for ISAKMP 1-31 1849 Reserved for IKEv1 32-33 1850 IKE_SA_INIT 34 1851 IKE_AUTH 35 1852 CREATE_CHILD_SA 36 1853 INFORMATIONAL 37 1854 Reserved for IKEv2+ 38-239 1855 Reserved for private use 240-255 1857 o Flags (1 octet) - indicates specific options that are set 1858 for the message. Presence of options are indicated by the 1859 appropriate bit in the flags field being set. The bits are 1860 defined LSB first, so bit 0 would be the least significant 1861 bit of the Flags octet. In the description below, a bit 1862 being 'set' means its value is '1', while 'cleared' means 1863 its value is '0'. 1865 -- X(reserved) (bits 0-2) - These bits MUST be cleared 1866 when sending and MUST be ignored on receipt. 1868 -- I(nitiator) (bit 3 of Flags) - This bit MUST be set in 1869 messages sent by the original Initiator of the IKE_SA 1870 and MUST be cleared in messages sent by the original 1871 Responder. It is used by the recipient to determine 1872 which eight octets of the SPI was generated by the 1873 recipient. 1875 -- V(ersion) (bit 4 of Flags) - This bit indicates that 1876 the transmitter is capable of speaking a higher major 1877 version number of the protocol than the one indicated 1878 in the major version number field. Implementations of 1879 IKEv2 must clear this bit when sending and MUST ignore 1880 it in incoming messages. 1882 -- R(esponse) (bit 5 of Flags) - This bit indicates that 1883 this message is a response to a message containing 1884 the same message ID. This bit MUST be cleared in all 1885 request messages and MUST be set in all responses. 1886 An IKE endpoint MUST NOT generate a response to a 1887 message that is marked as being a response. 1889 -- X(reserved) (bits 6-7 of Flags) - These bits MUST be 1890 cleared when sending and MUST be ignored on receipt. 1892 o Message ID (4 octets) - Message identifier used to control 1893 retransmission of lost packets and matching of requests and 1894 responses. It is essential to the security of the protocol 1895 because it is used to prevent message replay attacks. 1896 See sections 2.1 and 2.2. 1898 o Length (4 octets) - Length of total message (header + payloads) 1899 in octets. 1901 3.2 Generic Payload Header 1903 Each IKE payload defined in sections 3.3 through 3.16 begins with a 1904 generic payload header, shown in Figure 5. Figures for each payload 1905 below will include the generic payload header but for brevity the 1906 description of each field will be omitted. 1908 1 2 3 1909 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 1910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1911 ! Next Payload !C! RESERVED ! Payload Length ! 1912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1914 Figure 5: Generic Payload Header 1916 The Generic Payload Header fields are defined as follows: 1918 o Next Payload (1 octet) - Identifier for the payload type of the 1919 next payload in the message. If the current payload is the last 1920 in the message, then this field will be 0. This field provides 1921 a "chaining" capability whereby additional payloads can be 1922 added to a message by appending it to the end of the message 1923 and setting the "Next Payload" field of the preceding payload 1924 to indicate the new payload's type. An Encrypted payload, 1925 which must always be the last payload of a message, is an 1926 exception. It contains data structures in the format of 1927 additional payloads. In the header of an Encrypted payload, 1928 the Next Payload field is set to the payload type of the first 1929 contained payload (instead of 0). 1931 Payload Type Values 1933 Next Payload Type Notation Value 1935 Security Association SA 1 1936 Key Exchange KE 4 1937 Initiator Identification IDi 5 1938 Certificate CERT 6 1939 Certificate Request CERTREQ 7 1940 Authentication AUTH 9 1941 Nonce Ni, Nr 10 1942 Notification N 11 1943 Delete D 12 1944 Vendor ID V 13 1945 Initiator Traffic Selector TSi 14 1946 Encrypted E 15 1947 Configuration CP 16 1948 Extended Authentication EAP 17 1949 Responder Identication IDr 18 1950 Responder Traffic Selector TSr 19 1952 Payload type values 20-127 are reserved to IANA for future 1953 assignment in IKEv2 (see section 6). Payload type values 128-255 1954 are for private use among mutually consenting parties. 1956 o Critical (1 bit) - MUST be set to zero if the sender wants 1957 the recipient to skip this payload if he does not 1958 understand the payload type code in the Next Payload field 1959 of the previous payload. MUST be set to one if the 1960 sender wants the recipient to reject this entire message 1961 if he does not understand the payload type. MUST be ignored 1962 by the recipient if the recipient understands the payload type 1963 code. MUST be set to zero for payload types defined in this 1964 document. Note that the critical bit applies to the current 1965 payload rather than the "next" payload whose type code 1966 appears in the first octet. The reasoning behind not setting 1967 the critical bit for payloads defined in this document is 1968 that all implementations MUST understand all payload types 1969 defined in this document and therefore must ignore the 1970 Critical bit's value. Skipped payloads are expected to 1971 have valid Next Payload and Payload Length fields. 1973 o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on 1974 receipt. 1976 o Payload Length (2 octets) - Length in octets of the current 1977 payload, including the generic payload header. 1979 3.3 Security Association Payload 1981 The Security Association Payload, denoted SA in this memo, is used to 1982 negotiate attributes of a security association. Assembly of Security 1983 Association Payloads requires great peace of mind. An SA may contain 1984 multiple proposals, ordered from most preferred to least preferred. 1985 Each proposal may contain multiple protocols (where a protocol is 1986 IKE, ESP, or AH), each protocol may contain multiple transforms, and 1987 each transform may contain multiple attributes. When parsing an SA, 1988 an implementation MUST check that the total Payload Length is 1989 consistent with the payload's internal lengths and counts. 1990 Proposals, Transforms, and Attributes each have their own variable 1991 length encodings. They are nested such that the Payload Length of an 1992 SA includes the combined contents of the SA, Proposal, Transform, and 1993 Attribute information. The length of a Proposal includes the lengths 1994 of all Transforms and Attributes it contains. The length of a 1995 Transform includes the lengths of all Attributes it contains. 1997 The syntax of Security Associations, Proposals, Transforms, and 1998 Attributes is based on ISAKMP, however the semantics are somewhat 1999 different. The reason for the complexity and the hierarchy is to 2000 allow for multiple possible combinations of algorithms to be encoded 2001 in a single SA. Sometimes there is a choice of multiple algorithms, 2002 while other times there is a combination of algorithms. For example, 2003 an Initiator might want to propose using (AH w/MD5 and ESP w/3DES) OR 2004 (ESP w/MD5 and 3DES). 2006 One of the reasons the semantics of the SA payload has changed from 2007 ISAKMP and IKEv1 is to make the encodings more compact in common 2008 cases. 2010 The Proposal structure contains within it a Proposal # and a 2011 SECURITY_PROTOCOL_ID. Each structure MUST have the same Proposal # 2012 as the previous one or be one (1) greater. The first Proposal MUST 2013 have a Proposal # of one (1). If two successive structures have the 2014 same Proposal number, it means that the proposal consists of the 2015 first structure AND the second. So a proposal of AH AND ESP would 2016 have two proposal structures, one for AH and one for ESP and both 2017 would have Proposal #1. A proposal of AH OR ESP would have two 2018 proposal structures, one for AH with proposal #1 and one for ESP with 2019 proposal #2. 2021 Each Proposal/Protocol structure is followed by one or more transform 2022 structures. The number of different transforms is generally 2023 determined by the Protocol. AH generally has a single transform: an 2024 integrity check algorithm. ESP generally has two: an encryption 2025 algorithm AND an integrity check algorithm. IKE generally has four 2026 transforms: a Diffie-Hellman group, an integrity check algorithm, a 2027 prf algorithm, and an encryption algorithm. For each Protocol, the 2028 set of permissible transforms are assigned transform ID numbers, 2029 which appear in the header of each transform. 2031 If there are multiple transforms with the same Transform Type, the 2032 proposal is an OR of those transforms. If there are multiple 2033 Transforms with different Transform Types, the proposal is an AND of 2034 the different groups. For example, to propose ESP with (3DES or IDEA) 2035 and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two 2036 Transform Type 1 candidates (one for 3DES and one for IDEA) and two 2037 Transform Type 2 candidates (one for HMAC_MD5 and one for HMAC_SHA). 2038 This effectively proposes four combinations of algorithms. If the 2039 Initiator wanted to propose only a subset of those - say (3DES and 2040 HMAC_MD5) or (IDEA and HMAC_SHA), there is no way to encode that as 2041 multiple transforms within a single Proposal. Instead, the Initiator 2042 would have to construct two different Proposals, each with two 2043 transforms. 2045 A given transform MAY have one or more Attributes. Attributes are 2046 necessary when the transform can be used in more than one way, as 2047 when an encryption algorithm has a variable key size. The transform 2048 would specify the algorithm and the attribute would specify the key 2049 size. Most transforms do not have attributes. 2051 Note that the semantics of Transforms and Attributes are quite 2052 different than in IKEv1. In IKEv1, a single Transform carried 2053 multiple algorithms for a protocol with one carried in the Transform 2054 and the others carried in the Attributes. 2056 1 2 3 2057 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 2058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2059 ! Next Payload !C! RESERVED ! Payload Length ! 2060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2061 ! ! 2062 ~ ~ 2063 ! ! 2064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2066 Figure 6: Security Association Payload 2068 o Proposals (variable) - one or more proposal substructures. 2070 The payload type for the Security Association Payload is one (1). 2072 3.3.1 Proposal Substructure 2074 1 2 3 2075 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 2076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2077 ! 0 (last) or 2 ! RESERVED ! Proposal Length ! 2078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2079 ! Proposal # ! Protocol-Id ! SPI Size !# of Transforms! 2080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2081 ~ SPI (variable) ~ 2082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2083 ! ! 2084 ~ ~ 2085 ! ! 2086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2088 Figure 7: Proposal Substructure 2090 o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the 2091 last Proposal Substructure in the SA. This syntax is inherited 2092 from ISAKMP, but is unnecessary because the last Proposal 2093 could be identified from the length of the SA. The value (2) 2094 corresponds to a Payload Type of Proposal, and the first 2095 four octets of the Proposal structure are designed to look 2096 somewhat like the header of a Payload. 2098 o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on 2099 receipt. 2101 o Proposal Length (2 octets) - Length of this proposal, 2102 including all transforms and attributes that follow. 2104 o Proposal # (1 octet) - When a proposal is made, the first 2105 proposal in an SA MUST be #1, and subsequent proposals 2106 MUST either be the same as the previous proposal (indicating 2107 an AND of the two proposals) or one more than the previous 2108 proposal (indicating an OR of the two proposals). When a 2109 proposal is accepted, all of the proposal numbers in the 2110 SA MUST be the same and MUST match the number on the 2111 proposal sent that was accepted. 2113 o Protocol-Id (1 octet) - Specifies the protocol identifier 2114 for the current negotiation. Zero (0) indicates IKE, 2115 one (1) indicated ESP, and two (2) indicates AH. 2117 o SPI Size (1 octet) - For an initial IKE_SA negotiation, 2118 this field MUST be zero; the SPI is obtained from the 2119 outer header. During subsequent negotiations, 2120 it is equal to the size, in octets, of the SPI of the 2121 corresponding protocol (8 for IKE, 4 for ESP and AH). 2123 o # of Transforms (1 octet) - Specifies the number of 2124 transforms in this proposal. 2126 o SPI (variable) - The sending entity's SPI. Even if the SPI 2127 Size is not a multiple of 4 octets, there is no padding 2128 applied to the payload. When the SPI Size field is zero, 2129 this field is not present in the Security Association 2130 payload. 2132 o Transforms (variable) - one or more transform substructures. 2134 3.3.2 Transform Substructure 2136 1 2 3 2137 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 2138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2139 ! 0 (last) or 3 ! RESERVED ! Transform Length ! 2140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2141 !Transform Type ! RESERVED ! Transform ID ! 2142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2143 ! ! 2144 ~ Transform Attributes ~ 2145 ! ! 2146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2148 Figure 8: Transform Substructure 2150 o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the 2151 last Transform Substructure in the Proposal. This syntax is 2152 inherited from ISAKMP, but is unnecessary because the last 2153 Proposal could be identified from the length of the SA. The 2154 value (3) corresponds to a Payload Type of Transform, and 2155 the first four octets of the Transform structure are designed 2156 to look somewhat like the header of a Payload. 2158 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 2160 o Transform Length - The length (in octets) of the Transform 2161 Substructure including Header and Attributes. 2163 o Transform Type (1 octet) - The type of transform being specified 2164 in this transform. Different protocols support different 2165 transform types. For some protocols, some of the transforms 2166 may be optional. If a transform is optional and the initiator 2167 wishes to propose that the transform be omitted, no transform 2168 of the given type is included in the proposal. If the 2169 initiator wishes to make use of the transform optional to 2170 the responder, she includes a transform substructure with 2171 transform ID = 0 as one of the options. 2173 o Transform ID (1 octet) - The specific instance of the transform 2174 type being proposed. 2176 Transform Type Values 2178 Transform Used In 2179 Type 2180 Encryption Algorithm 1 (IKE and ESP) 2181 Pseudo-random Function 2 (IKE) 2182 Integrity Algorithm 3 (IKE, AH, and optional in ESP) 2183 Diffie-Hellman Group 4 (IKE and optional in AH and ESP) 2184 Extended Sequence Numbers 5 (Optional in AH and ESP) 2186 values 6-240 are reserved to IANA. Values 241-255 are for 2187 private use among mutually consenting parties. 2189 For Transform Type 1 (Encryption Algorithm), defined Transform IDs 2190 are: 2192 Name Number Defined In 2193 RESERVED 0 2194 ENCR_DES_IV64 1 (RFC1827) 2195 ENCR_DES 2 (RFC2405) 2196 ENCR_3DES 3 (RFC2451) 2197 ENCR_RC5 4 (RFC2451) 2198 ENCR_IDEA 5 (RFC2451) 2199 ENCR_CAST 6 (RFC2451) 2200 ENCR_BLOWFISH 7 (RFC2451) 2201 ENCR_3IDEA 8 (RFC2451) 2202 ENCR_DES_IV32 9 2203 ENCR_RC4 10 2204 ENCR_NULL 11 (RFC2410) 2205 ENCR_AES_128_CBC 12 2206 ENCR_AES_128_CTR 13 2208 values 14-240 are reserved to IANA. Values 241-255 are for 2209 private use among mutually consenting parties. 2211 For Transform Type 2 (Pseudo-random Function), defined Transform IDs 2212 are: 2214 Name Number Defined In 2215 RESERVED 0 2216 PRF_HMAC_MD5 1 (RFC2104) 2217 PRF_HMAC_SHA1 2 (RFC2104) 2218 PRF_HMAC_TIGER 3 (RFC2104) 2219 PRF_AES128_CBC 4 2221 values 5-240 are reserved to IANA. Values 241-255 are for 2222 private use among mutually consenting parties. 2224 For Transform Type 3 (Integrity Algorithm), defined Transform IDs 2225 are: 2227 Name Number Defined In 2228 NONE 0 2229 AUTH_HMAC_MD5_96 1 (RFC2403) 2230 AUTH_HMAC_SHA1_96 2 (RFC2404) 2231 AUTH_DES_MAC 3 2232 AUTH_KPDK_MD5 4 (RFC1826) 2233 AUTH_AES_XCBC_96 5 2235 values 6-240 are reserved to IANA. Values 241-255 are for 2236 private use among mutually consenting parties. 2238 For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs 2239 are: 2241 Name Number 2242 NONE 0 2243 Defined in Appendix B 1 - 5 2244 Defined in [ADDGROUP] 14 - 18 2245 MODP (exponentiation) 201 (w/attributes) 2246 ECP (elliptic curve over GF[P] 202 (w/attributes) 2247 EC2N (elliptic curve over GF[2^N]) 203 (w/attributes) 2249 values 6-13 and 19-200 are reserved to IANA for new MODP, ECP 2250 or EC2N groups. Values 204-255 are for private use among 2251 mutually consenting parties. Specification of values 201, 202 2252 or 203 allow peers to define a new Diffie-Hellman group in- 2253 line as part of the exchange. Private use of values 204-255 2254 may entail complete definition of a group or may require 2255 attributes to accompany them. 2257 For Transform Type 5 (Extended Sequence Numbers), defined Transform 2258 IDs are: 2260 Name Number 2261 No Extended Sequence Numbers 0 2262 Extended Sequence Numbers 1 2263 RESERVED 2 - 255 2265 If Transform Type 5 is not included in a proposal, use of 2266 Extended Sequence Numbers is assumed. 2268 3.3.3 Mandatory Transform Types 2270 The number and type of transforms that accompany an SA payload are 2271 dependent on the protocol in the SA itself. An SA payload proposing 2272 the establishment of an SA has the following mandatory and optional 2273 transform types. A compliant implementation MUST understand all 2274 mandatory and optional types for each protocol it supports (though it 2275 need not accept proposals with unacceptable suites). A proposal MAY 2276 omit the optional types if the only value for them it will accept is 2277 NONE. 2279 Protocol Mandatory Types Optional Types 2280 IKE ENCR, PRF, INTEG, D-H 2281 ESP ENCR INTEG, D-H, ESN 2282 AH INTEG D-H, ESN 2284 3.3.4 Mandatory Transform IDs 2286 The specification of suites that MUST and SHOULD be supported for 2287 interoperability has been removed from this document because they are 2288 likely to change more rapidly than this document evolves. 2290 An important lesson learned from IKEv1 is that no system should only 2291 implement the mandatory algorithms and expect them to be the best 2292 choice for all customers. For example, at the time that this document 2293 was being written, many IKEv1 implementers are starting to migrate to 2294 AES in CBC mode for VPN applications. Many IPsec systems based on 2295 IKEv2 will implement AES, longer Diffie-Hellman keys, and additional 2296 hash algorithms, and some IPsec customers already require these 2297 algorithms in addition to the ones listed above. 2299 It is likely that IANA will add additional transforms in the future, 2300 and some users may want to use private suites, especially for IKE 2301 where implementations should be capable of supporting different 2302 parameters, up to certain size limits. In support of this goal, all 2303 implementations of IKEv2 SHOULD include a management facility that 2304 allows specification (by a user or system administrator) of Diffie- 2305 Hellman parameters (the generator, modulus, and exponent lengths and 2306 values) for new DH groups. Implementations SHOULD provide a 2307 management interface via which these parameters and the associated 2308 transform IDs may be entered (by a user or system administrator), to 2309 enable negotiating such groups. 2311 All implementations of IKEv2 MUST include a management facility that 2312 enables a user or system administrator to specify the suites that are 2313 acceptable for use with IKE. Upon receipt of a payload with a set of 2314 transform IDs, the implementation MUST compare the transmitted 2315 transform IDs against those locally configured via the management 2316 controls, to verify that the proposed suite is acceptable based on 2317 local policy. The implementation MUST reject SA proposals that are 2318 not authorized by these IKE suite controls. 2320 3.3.5 Transform Attributes 2322 Each transform in a Security Association payload may include 2323 attributes that modify or complete the specification of the 2324 transform. These attributes are type/value pairs and are defined 2325 below. For example, if an encryption algorithm has a variable length 2326 key, the key length to be used may be specified as an attribute. 2327 Attributes can have a value with a fixed two octet length or a 2328 variable length value. For the latter, the attribute is encoded as 2329 type/length/value. 2331 1 2 3 2332 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 2333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2334 !A! Attribute Type ! AF=0 Attribute Length ! 2335 !F! ! AF=1 Attribute Value ! 2336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2337 ! AF=0 Attribute Value ! 2338 ! AF=1 Not Transmitted ! 2339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2341 Figure 9: Data Attributes 2343 o Attribute Type (2 octets) - Unique identifier for each type of 2344 attribute (see below). 2346 The most significant bit of this field is the Attribute Format 2347 bit (AF). It indicates whether the data attributes follow the 2348 Type/Length/Value (TLV) format or a shortened Type/Value (TV) 2349 format. If the AF bit is zero (0), then the Data Attributes 2350 are of the Type/Length/Value (TLV) form. If the AF bit is a 2351 one (1), then the Data Attributes are of the Type/Value form. 2353 o Attribute Length (2 octets) - Length in octets of the Attribute 2354 Value. When the AF bit is a one (1), the Attribute Value is 2355 only 2 octets and the Attribute Length field is not present. 2357 o Attribute Value (variable length) - Value of the Attribute 2358 associated with the Attribute Type. If the AF bit is a 2359 zero (0), this field has a variable length defined by the 2360 Attribute Length field. If the AF bit is a one (1), the 2361 Attribute Value has a length of 2 octets. 2363 Note that while quite a few attribute types are defined, the only 2364 algorithms defined in this document that accept attributes are the 2365 defined on the fly Diffie-Hellman groups, whose use is optional and 2366 likely unusual. An IKEv2 implementation MAY ignore attributes if it 2367 does not support any algorithms that use them. 2369 Attributes described as basic MUST NOT be encoded using the variable 2370 length encoding. Variable length attributes MUST NOT be encoded as 2371 basic even if their value can fit into two octets. NOTE: This is a 2372 change from IKEv1, where increased flexibility may have simplified 2373 the composer of messages but certainly complicated the parser. 2375 Attribute Type value Attribute Format 2376 -------------------------------------------------------------- 2377 RESERVED 0-5 2378 Group Prime/Irreducible Polynomial 6 TLV 2379 Group Generator One 7 TLV 2380 Group Generator Two 8 TLV 2381 Group Curve A 9 TLV 2382 Group Curve B 10 TLV 2383 RESERVED 11-13 2384 Key Length 14 TV 2385 Field Size 15 TV 2386 Group Order 16 TLV 2387 Block Size 17 TV 2389 values 0-5, 11-13, and 18-16383 are reserved to IANA. Values 2390 16384-32767 are for private use among mutually consenting parties. 2392 - Group Prime/Irreducible Polynomial 2394 The prime number of a MODP Diffie-Hellman group or the irreducible 2395 polynomial of an elliptic curve when specifying a private Diffie- 2396 Hellman group. 2398 - Generator One, Generator Two 2400 The X- and Y-coordinate of a point on an elliptic curve. When the 2401 Y-coordinate (generator two) is not given it can be computed with 2402 the X-coordinate and the definition of the curve. 2404 - Curve A, Curve B 2406 Coefficients from the definition of an elliptic curve: 2408 y^2 + xy = x^3 + (curve A)x^2 + (curve B) 2410 - Key Length 2412 When using an Encryption Algorithm that has a variable length key, 2413 this attribute specifies the key length in bits. (MUST use network 2414 byte order). This attribute MUST NOT be used when the specified 2415 Encryption Algorithm uses a fixed length key. 2417 - Field Size 2419 The field size, in bits, of a Diffie-Hellman group. 2421 - Group Order 2423 The group order of an elliptic curve group. Note the length of 2424 this attribute depends on the field size. 2426 - Block Size 2427 The number of bits per block of a cipher with a variable block 2428 length. 2430 3.3.6 Attribute Negotiation 2432 During security association negotiation Initiators present offers to 2433 Responders. Responders MUST select a single complete set of 2434 parameters from the offers (or reject all offers if none are 2435 acceptable). If there are multiple proposals, the Responder MUST 2436 choose a single proposal number and return all of the Proposal 2437 substructures with that Proposal number. If there are multiple 2438 Transforms with the same type the Responder MUST choose a single one. 2439 Any attributes of a selected transform MUST be returned unmodified. 2440 The Initiator of an exchange MUST check that the accepted offer is 2441 consistent with one of its proposals, and if not that response MUST 2442 be rejected. 2444 Negotiating Diffie-Hellman groups presents some special challenges. 2445 Diffie-Hellman groups are specified either using a defined group 2446 description (see Appendix B) or by defining all attributes of a group 2447 in an IKE proposal. Group attributes, such as group type or prime 2448 number MUST NOT be provided in conjunction with groups that have 2449 assigned codes. SA offers include proposed attributes and a Diffie- 2450 Hellman public number (KE) in the same message. If the Initiator 2451 offers to use one of several Diffie-Hellman groups, it SHOULD pick 2452 the one the Responder is most likely to accept and include a KE 2453 corresponding to that group. If the guess turns out to be wrong, the 2454 Responder will indicate the correct group in the response and the 2455 Initiator SHOULD pick an element of that group for its KE value in 2456 the third message. If the Initiator guesses wrong in a 2457 CREATE_CHILD_SA negotiation, no SA is created and the Initiator 2458 SHOULD retry with the correct group. 2460 Implementation Note: 2462 Certain negotiable attributes can have ranges or could have 2463 multiple acceptable values. These are the Diffie-Hellman group and 2464 the key length of a variable key length symmetric cipher. To 2465 further interoperability and to support upgrading endpoints 2466 independently, implementers of this protocol SHOULD accept values 2467 which they deem to supply greater security. For instance if a peer 2468 is configured to accept a variable lengthed cipher with a key 2469 length of X bits and is offered that cipher with a larger key 2470 length an implementation SHOULD accept the offer. 2472 Support of this capability allows an implementation to express a 2473 concept of "at least" a certain level of security-- "a key length of 2474 _at least_ X bits for cipher foo". 2476 3.4 Key Exchange Payload 2478 The Key Exchange Payload, denoted KE in this memo, is used to 2479 exchange Diffie-Hellman public numbers as part of a Diffie-Hellman 2480 key exchange. The Key Exchange Payload consists of the IKE generic 2481 payload header followed by the Diffie-Hellman public value itself. 2483 1 2 3 2484 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 2485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2486 ! Next Payload !C! RESERVED ! Payload Length ! 2487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2488 ! DH Group # ! RESERVED ! 2489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2490 ! ! 2491 ~ Key Exchange Data ~ 2492 ! ! 2493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2495 Figure 10: Key Exchange Payload Format 2497 A key exchange payload is constructed by copying one's Diffie-Hellman 2498 public value into the "Key Exchange Data" portion of the payload. 2499 The length of the Diffie-Hellman public value MUST be equal to the 2500 length of the prime modulus over which the exponentiation was 2501 performed, prepending zero bits to the value if necessary. 2503 The DH Group # identifies the Diffie-Hellman group in which the Key 2504 Exchange Data was computed (see Appendix B). If the selected 2505 proposal uses a different Diffie-Hellman group, the message MUST be 2506 rejected with a Notify payload of type INVALID_KE_PAYLOAD. 2508 The payload type for the Key Exchange payload is four (4). 2510 3.5 Identification Payloads 2512 The Identification Payloads, denoted IDi and IDr in this memo, allow 2513 peers to assert an identity to one another. This identity may be used 2514 for policy lookup, but does not necessarily have to match anything in 2515 the CERT payload; both fields may be used by an implementation to 2516 perform access control decisions. 2518 NOTE: In IKEv1, two ID payloads were used in each direction to hold 2519 Traffic Selector information for data passing over the SA. In IKEv2, 2520 this information is carried in Traffic Selector (TS) payloads (see 2521 section 3.13). 2523 The Identification Payload consists of the IKE generic payload header 2524 followed by identification fields as follows: 2526 1 2 3 2527 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 2528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2529 ! Next Payload !C! RESERVED ! Payload Length ! 2530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2531 ! ID Type ! RESERVED | 2532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2533 ! ! 2534 ~ Identification Data ~ 2535 ! ! 2536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2538 Figure 11: Identification Payload Format 2540 o ID Type (1 octet) - Specifies the type of Identification being 2541 used. 2543 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 2545 o Identification Data (variable length) - Value, as indicated by 2546 the Identification Type. The length of the Identification Data 2547 is computed from the size in the ID payload header. 2549 The payload types for the Identification Payload are five (5) for IDi 2550 and eighteen (18) for IDr. 2552 The following table lists the assigned values for the Identification 2553 Type field, followed by a description of the Identification Data 2554 which follows: 2556 ID Type Value 2557 ------- ----- 2558 RESERVED 0 2560 ID_IPV4_ADDR 1 2562 A single four (4) octet IPv4 address. 2564 ID_FQDN 2 2566 A fully-qualified domain name string. An example of a 2567 ID_FQDN is, "example.com". The string MUST not contain any 2568 terminators (e.g., NULL, CR, etc.). 2570 ID_RFC822_ADDR 3 2571 A fully-qualified RFC822 email address string, An example of 2572 a ID_RFC822_ADDR is, "jsmith@example.com". The string MUST 2573 not contain any terminators. 2575 ID_IPV6_ADDR 5 2577 A single sixteen (16) octet IPv6 address. 2579 ID_DER_ASN1_DN 9 2581 The binary DER encoding of an ASN.1 X.500 Distinguished Name 2582 [X.501]. 2584 ID_DER_ASN1_GN 10 2586 The binary DER encoding of an ASN.1 X.500 GeneralName 2587 [X.509]. 2589 ID_KEY_ID 11 2591 An opaque octet stream which may be used to pass an account 2592 name or to pass vendor-specific information necessary to do 2593 certain proprietary types of identification. 2595 Two implementations will interoperate only if each can generate a 2596 type of ID acceptable to the other. To assure maximum 2597 interoperability, implementations MUST be configurable to send at 2598 least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and 2599 MUST be configurable to accept all of these types. Implementations 2600 SHOULD be capable of generating and accepting all of these types. 2602 3.6 Certificate Payload 2604 The Certificate Payload, denoted CERT in this memo, provides a means 2605 to transport certificates or other authentication related information 2606 via IKE. Certificate payloads SHOULD be included in an exchange if 2607 certificates are available to the sender unless the peer has 2608 indicated an ability to retrieve this information from elsewhere 2609 using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note that the 2610 term "Certificate Payload" is somewhat misleading, because not all 2611 authentication mechanisms use certificates and data other than 2612 certificates may be passed in this payload. 2614 The Certificate Payload is defined as follows: 2616 1 2 3 2617 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 2618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2619 ! Next Payload !C! RESERVED ! Payload Length ! 2620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2621 ! Cert Encoding ! ! 2622 +-+-+-+-+-+-+-+-+ ! 2623 ~ Certificate Data ~ 2624 ! ! 2625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2627 Figure 12: Certificate Payload Format 2629 o Certificate Encoding (1 octet) - This field indicates the type 2630 of certificate or certificate-related information contained 2631 in the Certificate Data field. 2633 Certificate Encoding Value 2634 -------------------- ----- 2635 RESERVED 0 2636 PKCS #7 wrapped X.509 certificate 1 2637 PGP Certificate 2 2638 DNS Signed Key 3 2639 X.509 Certificate - Signature 4 2640 Kerberos Token 6 2641 Certificate Revocation List (CRL) 7 2642 Authority Revocation List (ARL) 8 2643 SPKI Certificate 9 2644 X.509 Certificate - Attribute 10 2645 Raw RSA Key 11 2646 Hash and URL of PKIX certificate 12 2647 Hash and URL of PKIX bundle 13 2648 RESERVED 14 - 200 2649 PRIVATE USE 201 - 255 2651 o Certificate Data (variable length) - Actual encoding of 2652 certificate data. The type of certificate is indicated 2653 by the Certificate Encoding field. 2655 The payload type for the Certificate Payload is six (6). 2657 Specific syntax is for some of the certificate type codes above is 2658 not defined in this document. The types whose syntax is defined in 2659 this document are: 2661 X.509 Certificate - Signature (4) contains a BER encoded X.509 2662 certificate. 2664 Certificate Revocation List (7) contains a BER encoded X.509 2665 certificate revocation list. 2667 Raw RSA Key (11) contains a PKCS #1 encoded RSA key. 2669 Hash and URL of PKIX certificate (12) contains a 20 octet SHA-1 2670 hash of a PKIX certificate followed by a variable length URL that 2671 resolves to the BER encoded certificate itself. 2673 Hash and URL of PKIX bundle (13) contains a 20 octet SHA-1 hash of 2674 a PKIX certificate bundle followed by a variable length URL the 2675 resolves to the BER encoded certificate bundle itself. The bundle 2676 is a BER encoded SEQUENCE of certificates and CRLs. 2678 Implementations MUST be capable of being configured to send and 2679 accept up to four X.509 certificates in support of authentication. 2680 Implementations SHOULD be capable of being configured to send and 2681 accept Raw RSA keys and the two Hash and URL formats. If multiple 2682 certificates are sent, the first certificate MUST contain the public 2683 key used to sign the AUTH payload. The other certificates may be sent 2684 in any order. 2686 3.7 Certificate Request Payload 2688 The Certificate Request Payload, denoted CERTREQ in this memo, 2689 provides a means to request preferred certificates via IKE and can 2690 appear in the IKE_INIT_SA response and/or the IKE_AUTH request. 2691 Certificate Request payloads MAY be included in an exchange when the 2692 sender needs to get the certificate of the receiver. If multiple CAs 2693 are trusted and the cert encoding does not allow a list, then 2694 multiple Certificate Request payloads SHOULD be transmitted. 2696 The Certificate Request Payload is defined as follows: 2698 1 2 3 2699 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 2700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2701 ! Next Payload !C! RESERVED ! Payload Length ! 2702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2703 ! Cert Encoding ! ! 2704 +-+-+-+-+-+-+-+-+ ! 2705 ~ Certification Authority ~ 2706 ! ! 2707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2709 Figure 13: Certificate Request Payload Format 2711 o Certificate Encoding (1 octet) - Contains an encoding of the type 2712 or format of certificate requested. Values are listed in section 2713 3.6. 2715 o Certification Authority (variable length) - Contains an encoding 2716 of an acceptable certification authority for the type of 2717 certificate requested. 2719 The payload type for the Certificate Request Payload is seven (7). 2721 The Certificate Encoding field has the same values as those defined 2722 in section 3.6. The Certification Authority field contains an 2723 indicator of trusted authorities for this certificate type. The 2724 Certification Authority value is a concatenated list of SHA-1 hashes 2725 of the public keys of trusted CAs. Each is encoded as the SHA-1 hash 2726 of the Subject Public Key Info element (see section 4.1.2.7 of [RFC 2727 3280]) from each Trust Anchor certificate. The twenty-octet hashes 2728 are concatenated and included with no other formatting. 2730 Note that the term "Certificate Request" is somewhat misleading, in 2731 that values other than certificates are defined in a "Certificate" 2732 payload and requests for those values can be present in a Certificate 2733 Request Payload. The syntax of the Certificate Request payload in 2734 such cases is not defined in this document. 2736 The Certificate Request Payload is processed by inspecting the "Cert 2737 Encoding" field to determine whether the processor has any 2738 certificates of this type. If so the "Certification Authority" field 2739 is inspected to determine if the processor has any certificates which 2740 can be validated up to one of the specified certification 2741 authorities. This can be a chain of certificates. If a certificate 2742 exists which satisfies the criteria specified in the Certificate 2743 Request Payload, the certificate MUST be sent back to the certificate 2744 requestor; if a certificate chain exists which goes back to the 2745 certification authority specified in the request the entire chain 2746 SHOULD be sent back to the certificate requestor. If multiple 2747 certificates or chains exist that satisfy the request, the sender 2748 MUST pick one. If no certificates exist then the Certificate Request 2749 Payload is ignored. This is not an error condition of the protocol. 2750 There may be cases where there is a preferred CA, but an alternate 2751 might be acceptable (perhaps after prompting a human operator). 2753 3.8 Authentication Payload 2755 The Authentication Payload, denoted AUTH in this memo, contains data 2756 used for authentication purposes. The syntax of the Authentication 2757 data varies according to the Auth Method as specified below. 2759 The Authentication Payload is defined as follows: 2761 1 2 3 2762 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2764 ! Next Payload !C! RESERVED ! Payload Length ! 2765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2766 ! Auth Method ! RESERVED ! 2767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2768 ! ! 2769 ~ Authentication Data ~ 2770 ! ! 2771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2773 Figure 14: Authentication Payload Format 2775 o Auth Method (1 octet) - Specifies the method of authentication 2776 used. Values defined are: 2778 RSA Digital Signature (1) - Computed as specified in section 2779 2.15 using an RSA private key over a PKCS#1 padded hash. 2781 Shared Key Message Integrity Code (2) - Computed as specified in 2782 section 2.15 using the shared key associated with the identity 2783 in the ID payload and the negotiated prf function 2785 DSS Digital Signature (3) - Computed as specified in section 2786 2.15 using a DSS private key over a SHA-1 hash. 2788 The values 0 and 4-200 are reserved to IANA. The values 201-255 2789 are available for private use. 2791 o Authentication Data (variable length) - see section 2.15. 2793 The payload type for the Authentication Payload is nine (9). 2795 3.9 Nonce Payload 2797 The Nonce Payload, denoted Ni and Nr in this memo for the Initiator's 2798 and Responder's nonce respectively, contains random data used to 2799 guarantee liveness during an exchange and protect against replay 2800 attacks. 2802 The Nonce Payload is defined as follows: 2804 1 2 3 2805 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 2806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2807 ! Next Payload !C! RESERVED ! Payload Length ! 2808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2809 ! ! 2810 ~ Nonce Data ~ 2811 ! ! 2812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2814 Figure 15: Nonce Payload Format 2816 o Nonce Data (variable length) - Contains the random data generated 2817 by the transmitting entity. 2819 The payload type for the Nonce Payload is ten (10). 2821 The size of a Nonce MUST be between 8 and 256 octets inclusive. Nonce 2822 values MUST NOT be reused. 2824 3.10 Notify Payload 2826 The Notify Payload, denoted N in this document, is used to transmit 2827 informational data, such as error conditions and state transitions, 2828 to an IKE peer. A Notify Payload may appear in a response message 2829 (usually specifying why a request was rejected), in an INFORMATIONAL 2830 Exchange (to report an error not in an IKE request), or in any other 2831 message to indicate sender capabilities or to modify the meaning of 2832 the request. 2834 The Notify Payload is defined as follows: 2836 1 2 3 2837 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 2838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2839 ! Next Payload !C! RESERVED ! Payload Length ! 2840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2841 ! S_Protocol_ID ! SPI Size ! Notify Message Type ! 2842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2843 ! ! 2844 ~ Security Parameter Index (SPI) ~ 2845 ! ! 2846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2847 ! ! 2848 ~ Notification Data ~ 2849 ! ! 2850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2852 Figure 16: Notification Payload Format 2854 o SECURITY_PROTOCOL_ID (1 octet) - If this notification concerns 2855 an existing SA, this field indicates the type of that SA. 2856 For IKE_SA notifications, this field MUST be one (1). For 2857 notifications concerning IPsec SAs this field MUST contain 2858 either (2) to indicate AH or (3) to indicate ESP. For 2859 notifications which do not relate to an existing SA, this 2860 field MUST be sent as zero and MUST be ignored on receipt. 2861 All other values for this field are reserved to IANA for future 2862 assignment. 2864 o SPI Size (1 octet) - Length in octets of the SPI as defined by 2865 the SECURITY_PROTOCOL_ID or zero if no SPI is applicable. For a 2866 notification concerning the IKE_SA, the SPI Size MUST be zero. 2868 o Notify Message Type (2 octets) - Specifies the type of 2869 notification message. 2871 o SPI (variable length) - Security Parameter Index. 2873 o Notification Data (variable length) - Informational or error data 2874 transmitted in addition to the Notify Message Type. Values for 2875 this field are type specific (see below). 2877 The payload type for the Notification Payload is eleven (11). 2879 3.10.1 Notify Message Types 2881 Notification information can be error messages specifying why an SA 2882 could not be established. It can also be status data that a process 2883 managing an SA database wishes to communicate with a peer process. 2884 The table below lists the Notification messages and their 2885 corresponding values. The number of different error statuses was 2886 greatly reduced from IKE V1 both for simplification and to avoid giving 2887 configuration information to probers. 2889 Types in the range 0 - 16383 are intended for reporting errors. An 2890 implementation receiving a Notify payload with one of these types 2891 that it does not recognize in a response MUST assume that the 2892 corresponding request has failed entirely. Unrecognized error types 2893 in a request and status types in a request or response MUST be 2894 ignored except that they SHOULD be logged. 2896 Notify payloads with status types MAY be added to any message and 2897 MUST be ignored if not recognized. They are intended to indicate 2898 capabilities, and as part of SA negotiation are used to negotiate 2899 non-cryptographic parameters. 2901 NOTIFY MESSAGES - ERROR TYPES Value 2902 ----------------------------- ----- 2903 UNSUPPORTED_CRITICAL_PAYLOAD 1 2905 Sent if the payload has the "critical" bit set and the 2906 payload type is not recognized. Notification Data contains 2907 the one octet payload type. 2909 INVALID_IKE_SPI 4 2911 Indicates an IKE message was received with an unrecognized 2912 destination SPI. This usually indicates that the recipient 2913 has rebooted and forgotten the existence of an IKE_SA. 2915 INVALID_MAJOR_VERSION 5 2917 Indicates the recipient cannot handle the version of IKE 2918 specified in the header. The closest version number that the 2919 recipient can support will be in the reply header. 2921 INVALID_SYNTAX 7 2923 Indicates the IKE message was received was invalid because 2924 some type, length, or value was out of range or because the 2925 request was rejected for policy reasons. To avoid a denial 2926 of service attack using forged messages, this status may 2927 only be returned for and in an encrypted packet if the 2928 MESSAGE_ID and cryptographic checksum were valid. To avoid 2929 leaking information to someone probing a node, this status 2930 MUST be sent in response to any error not covered by one of 2931 the other status types. To aid debugging, more detailed 2932 error information SHOULD be written to a console or log. 2934 INVALID_MESSAGE_ID 9 2936 Sent when an IKE MESSAGE_ID outside the supported window is 2937 received. This Notify MUST NOT be sent in a response; the 2938 invalid request MUST NOT be acknowledged. Instead, inform 2939 the other side by initiating an INFORMATIONAL exchange with 2940 Notification data containing the four octet invalid 2941 MESSAGE_ID. Sending this notification is optional and 2942 notifications of this type MUST be rate limited. 2944 INVALID_SPI 11 2946 MAY be sent in an IKE INFORMATIONAL Exchange when a node 2947 receives an ESP or AH packet with an invalid SPI. The 2948 Notification Data contains the SPI of the invalid packet. 2949 This usually indicates a node has rebooted and forgotten an 2950 SA. If this Informational Message is sent outside the 2951 context of an IKE_SA, it should only be used by the 2952 recipient as a "hint" that something might be wrong (because 2953 it could easily be forged). 2955 NO_PROPOSAL_CHOSEN 14 2957 None of the proposed crypto suites was acceptable. 2959 INVALID_KE_PAYLOAD 17 2961 The D-H Group # field in the KE payload is not the group # 2962 selected by the responder for this exchange. There is one 2963 octet of data associated with this notification: the 2964 accepted D-H Group #. 2966 AUTHENTICATION_FAILED 24 2968 Sent in the response to an IKE_AUTH message when for some 2969 reason the authentication failed. There is no associated 2970 data. 2972 SINGLE_PAIR_REQUIRED 34 2974 This error indicates that a CREATE_CHILD_SA request is 2975 unacceptable because its sender is only willing to accept 2976 traffic selectors specifying a single pair of addresses. 2977 The requestor is expected to respond by requesting an SA for 2978 only the specific traffic he is trying to forward. 2980 NO_ADDITIONAL_SAS 35 2982 This error indicates that a CREATE_CHILD_SA request is 2983 unacceptable because the Responder is unwilling to accept 2984 any more CHILD_SAs on this IKE_SA. Some minimal 2985 implementations may only accept a single CHILD_SA setup in 2986 the context of an initial IKE exchange and reject any 2987 subsequent attempts to add more. 2989 INTERNAL_ADDRESS_FAILURE 36 2990 Indicates an error assigning an internal address (i.e., 2991 INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS) during the 2992 processing of a Configuration Payload by a Responder. If 2993 this error is generated within an IKE_AUTH exchange no 2994 CHILD_SA will be created. 2996 FAILED_CP_REQUIRED 37 2997 Sent by responder in the case where CP(CFG_REQUEST) was 2998 expected but not received, and so is a conflict with locally 2999 configured policy. There is no associated data. 3001 TS_UNACCEPTABLE 38 3002 Indicates that none of the addresses/protocols/ports in the 3003 supplied traffic selectors is acceptable. 3005 RESERVED TO IANA - Errors 39 - 8191 3007 Private Use - Errors 8192 - 16383 3009 NOTIFY MESSAGES - STATUS TYPES Value 3010 ------------------------------ ----- 3012 RESERVED TO IANA - STATUS 16384 - 24577 3014 INITIAL_CONTACT 24578 3016 This notification asserts that this IKE_SA is the only 3017 IKE_SA currently active between the authenticated 3018 identities. It MAY be sent when an IKE_SA is established 3019 after a crash, and the recipient MAY use this information to 3020 delete any other IKE_SAs it has to the same authenticated 3021 identity without waiting for a timeout. This notification 3022 MUST NOT be sent by an entity that may be replicated (e.g., 3023 a roaming user's credentials where the user is allowed to 3024 connect to the corporate firewall from two remote systems at 3025 the same time). 3027 SET_WINDOW_SIZE 24579 3029 This notification asserts that the sending endpoint is 3030 capable of keeping state for multiple outstanding exchanges, 3031 permitting the recipient to send multiple requests before 3032 getting a response to the first. The data associated with a 3033 SET_WINDOW_SIZE notification MUST be 4 octets long and 3034 contain the big endian representation of the number of 3035 messages the sender promises to keep. Window size is always 3036 one until the initial exchanges complete. 3038 ADDITIONAL_TS_POSSIBLE 24580 3040 This notification asserts that the sending endpoint narrowed 3041 the proposed traffic selectors but that other traffic 3042 selectors would also have been acceptable, though only in a 3043 separate SA (see section 2.9). There is no data associated 3044 with this Notify type. It may only be sent as an additional 3045 payload in a message including accepted TSs. 3047 IPCOMP_SUPPORTED 24581 3049 This notification may only be included in a message 3050 containing an SA payload negotiating a CHILD_SA and 3051 indicates a willingness by its sender to use IPcomp on this 3052 SA. The data associated with this notification includes a 3053 two octet IPcomp CPI followed by a one octet transform ID 3054 optionally followed by attributes whose length and format is 3055 defined by that transform ID. A message proposing an SA may 3056 contain multiple IPCOMP_SUPPORTED notifications to indicate 3057 multiple supported algorithms. A message accepting an SA may 3058 contain at most one. 3060 The transform IDs currently defined are: 3062 NAME NUMBER DEFINED IN 3063 ----------- ------ ----------- 3064 RESERVED 0 3065 IPCOMP_OUI 1 3066 IPCOMP_DEFLATE 2 RFC 2394 3067 IPCOMP_LZS 3 RFC 2395 3068 values 4-240 are reserved to IANA. Values 241-255 are 3069 for private use among mutually consenting parties. 3071 NAT_DETECTION_SOURCE_IP 24582 3073 This notification is used to by its recipient to determine 3074 whether the source is behind a NAT box. The data associated 3075 with this notification is a SHA-1 digest of the SPIs (in the 3076 order they appear in the header), IP address and port on 3077 which this packet was sent. There MAY be multiple Notify 3078 payloads of this type in a message if the sender does not 3079 know which of several network attachments will be used to 3080 send the packet. The recipient of this notification MAY 3081 compare the supplied value to a SHA-1 hash of the SPIs, 3082 source IP address and port and if they don't match it SHOULD 3083 enable NAT traversal (see section 2.23). Alternately, it 3084 MAY reject the connection attempt if NAT traversal is not 3085 supported. 3087 NAT_DETECTION_DESTINATION_IP 24583 3089 This notification is used to by its recipient to determine 3090 whether it is behind a NAT box. The data associated with 3091 this notification is a SHA-1 digest of the SPIs (in the 3092 order they appear in the header), IP address and port to 3093 which this packet was sent. The recipient of this 3094 notification MAY compare the supplied value to a hash of the 3095 SPIs, destination IP address and port and if they don't 3096 match it SHOULD invoke NAT traversal (see section 2.23). If 3097 they don't match, it means that this end is behind a NAT. 3098 Alternately, it MAY reject the connection attempt if NAT 3099 traversal is not supported. 3101 COOKIE 24584 3103 This notification MAY be included in an IKE_SA_INIT 3104 response. It indicates that the request should be retried 3105 with a copy of this notification as the first payload. This 3106 notification MUST be included in an IKE_SA_INIT request 3107 retry if a COOKIE notification was included in the initial 3108 response. The data associated with this notification MUST 3109 be between 1 and 64 octets in length (inclusive). 3111 USE_TRANSPORT_MODE 24585 3113 This notification MAY be included in a request message that 3114 also includes an SA requesting a CHILD_SA. It requests that 3115 the CHILD_SA use transport mode rather than tunnel mode for 3116 the SA created. If the request is accepted, the response 3117 MUST also include a notification of type USE_TRANSPORT_MODE. 3118 If the responder declines the request, the CHILD_SA will be 3119 established in tunnel mode. If this is unacceptable to the 3120 initiator, the initiator MUST delete the SA. Note: except 3121 when using this option to negotiate transport mode, all 3122 CHILD_SAs will use tunnel mode. 3124 HTTP_CERT_LOOKUP_SUPPORTED 24586 3126 This notification MAY be included any message that can 3127 include a CERTREQ payload and indicates that the sender is 3128 capable of looking up certificates based on an HTTP-based 3129 URL (and hence presumably would prefer to receive 3130 certificate specifications in that format). 3132 RESERVED TO IANA - STATUS 24587 - 40959 3134 Private Use - STATUS 40960 - 65535 3136 3.11 Delete Payload 3138 The Delete Payload, denoted D in this memo, contains a protocol 3139 specific security association identifier that the sender has removed 3140 from its security association database and is, therefore, no longer 3141 valid. Figure 17 shows the format of the Delete Payload. It is 3142 possible to send multiple SPIs in a Delete payload, however, each SPI 3143 MUST be for the same protocol. Mixing of Protocol Identifiers MUST 3144 NOT be performed in a the Delete payload. It is permitted, however, 3145 to include multiple Delete payloads in a single INFORMATIONAL 3146 Exchange where each Delete payload lists SPIs for a different 3147 protocol. 3149 Deletion of the IKE_SA is indicated by a SECURITY_PROTOCOL_ID of 1 3150 (IKE) but no SPIs. Deletion of a CHILD_SA, such as ESP or AH, will 3151 contain the SECURITY_PROTOCOL_ID of that protocol (2 for AH, 3 for 3152 ESP) and the SPI is the SPI the sending endpoint would expect in 3153 inbound ESP or AH packets. 3155 The Delete Payload is defined as follows: 3157 1 2 3 3158 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 3159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3160 ! Next Payload !C! RESERVED ! Payload Length ! 3161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3162 ! S_PROTOCOL_ID ! SPI Size ! # of SPIs ! 3163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3164 ! ! 3165 ~ Security Parameter Index(es) (SPI) ~ 3166 ! ! 3167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3169 Figure 17: Delete Payload Format 3171 o SECURITY_PROTOCOL_ID (1 octet) - Must be 1 for an IKE_SA, 2 3172 for AH, or 3 for ESP. 3174 o SPI Size (1 octet) - Length in octets of the SPI as defined by 3175 the SECURITY_PROTOCOL_ID. Zero for IKE (SPI is in message 3176 header) or four for AH and ESP. 3178 o # of SPIs (2 octets) - The number of SPIs contained in the Delete 3179 payload. The size of each SPI is defined by the SPI Size field. 3181 o Security Parameter Index(es) (variable length) - Identifies the 3182 specific security association(s) to delete. The length of this 3183 field is determined by the SPI Size and # of SPIs fields. 3185 The payload type for the Delete Payload is twelve (12). 3187 3.12 Vendor ID Payload 3189 The Vendor ID Payload contains a vendor defined constant. The 3190 constant is used by vendors to identify and recognize remote 3191 instances of their implementations. This mechanism allows a vendor 3192 to experiment with new features while maintaining backwards 3193 compatibility. 3195 A Vendor ID payload MAY announce that the sender is capable to 3196 accepting certain extensions to the protocol, or it MAY simply 3197 identify the implementation as an aid in debugging. A Vendor ID 3198 payload MUST NOT change the interpretation of any information defined 3199 in this specification (i.e., it MUST be non-critical). Multiple 3200 Vendor ID payloads MAY be sent. An implementation is NOT REQUIRED to 3201 send any Vendor ID payload at all. 3203 A Vendor ID payload may be sent as part of any message. Reception of 3204 a familiar Vendor ID payload allows an implementation to make use of 3205 Private USE numbers described throughout this memo-- private 3206 payloads, private exchanges, private notifications, etc. Unfamiliar 3207 Vendor IDs MUST be ignored. 3209 Writers of Internet-Drafts who wish to extend this protocol MUST 3210 define a Vendor ID payload to announce the ability to implement the 3211 extension in the Internet-Draft. It is expected that Internet-Drafts 3212 which gain acceptance and are standardized will be given "magic 3213 numbers" out of the Future Use range by IANA and the requirement to 3214 use a Vendor ID will go away. 3216 The Vendor ID Payload fields are defined as follows: 3218 1 2 3 3219 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 3220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3221 ! Next Payload !C! RESERVED ! Payload Length ! 3222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3223 ! ! 3224 ~ Vendor ID (VID) ~ 3225 ! ! 3226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3228 Figure 18: Vendor ID Payload Format 3230 o Vendor ID (variable length) - It is the responsibility of 3231 the person choosing the Vendor ID to assure its uniqueness 3232 in spite of the absence of any central registry for IDs. 3233 Good practice is to include a company name, a person name 3234 or some such. If you want to show off, you might include 3235 the latitude and longitude and time where you were when 3236 you chose the ID and some random input. A message digest 3237 of a long unique string is preferable to the long unique 3238 string itself. 3240 The payload type for the Vendor ID Payload is thirteen (13). 3242 3.13 Traffic Selector Payload 3244 The Traffic Selector Payload, denoted TS in this memo, allows peers 3245 to identify packet flows for processing by IPsec security services. 3246 The Traffic Selector Payload consists of the IKE generic payload 3247 header followed by individual traffic selectors as follows: 3249 1 2 3 3250 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 3251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3252 ! Next Payload !C! RESERVED ! Payload Length ! 3253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3254 ! Number of TSs ! RESERVED ! 3255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3256 ! ! 3257 ~ ~ 3258 ! ! 3259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3261 Figure 19: Traffic Selectors Payload Format 3263 o Number of TSs (1 octet) - Number of traffic selectors 3264 being provided. 3266 o RESERVED - This field MUST be sent as zero and MUST be ignored 3267 on receipt. 3269 o Traffic Selectors (variable length) - one or more individual 3270 traffic selectors. 3272 The length of the Traffic Selector payload includes the TS header and 3273 all the traffic selectors. 3275 The payload type for the Traffic Selector payload is fourteen (14) 3276 for TSi and nineteen (19) for TSr. 3278 3.13.1 Traffic Selector 3280 1 2 3 3281 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 3282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3283 ! TS Type ! Protocol_ID | Selector Length | 3284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3285 | Start_Port | End_Port | 3286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3287 ! ! 3288 ~ Starting Address ~ 3289 ! ! 3290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3291 ! ! 3292 ~ Ending Address ~ 3293 ! ! 3294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3296 Figure 20: Traffic Selector 3298 o TS Type (one octet) - Specifies the type of traffic selector. 3300 o Protocol ID (1 octet) - Value specifying an associated IP 3301 protocol ID (e.g., UDP/TCP). A value of zero means that the 3302 Protocol ID is not relevant to this traffic selector-- 3303 the SA can carry all protocols. 3305 o Selector Length - Specifies the length of this Traffic 3306 Selector Substructure including the header. 3308 o Start_Port (2 octets) - Value specifying the smallest port 3309 number allowed by this Traffic Selector. For protocols for 3310 which port is undefined, or if all ports are allowed by 3311 this Traffic Selector, this field MUST be zero. 3313 o End_Port (2 octets) - Value specifying the largest port 3314 number allowed by this Traffic Selector. For protocols for 3315 which port is undefined, or it all ports are allowed by 3316 this Traffic Selector, this field MUST be 65535. 3318 o Starting Address - The smallest address included in this 3319 Traffic Selector (length determined by TS type). 3321 o Ending Address - The largest address included in this 3322 Traffic Selector (length determined by TS type). 3324 The following table lists the assigned values for the Traffic 3325 Selector Type field and the corresponding Address Selector Data. 3327 TS Type Value 3328 ------- ----- 3329 RESERVED 0 3331 TS_IPV4_ADDR_RANGE 7 3333 A range of IPv4 addresses, represented by two four (4) octet 3334 values. The first value is the beginning IPv4 address 3335 (inclusive) and the second value is the ending IPv4 address 3336 (inclusive). All addresses falling between the two specified 3337 addresses are considered to be within the list. 3339 TS_IPV6_ADDR_RANGE 8 3341 A range of IPv6 addresses, represented by two sixteen (16) 3342 octet values. The first value is the beginning IPv6 address 3343 (inclusive) and the second value is the ending IPv6 address 3344 (inclusive). All addresses falling between the two specified 3345 addresses are considered to be within the list. 3347 3.14 Encrypted Payload 3349 The Encrypted Payload, denoted SK{...} in this memo, contains other 3350 payloads in encrypted form. The Encrypted Payload, if present in a 3351 message, MUST be the last payload in the message. Often, it is the 3352 only payload in the message. 3354 The algorithms for encryption and integrity protection are negotiated 3355 during IKE_SA setup, and the keys are computed as specified in 3356 sections 2.14 and 2.18. 3358 The encryption and integrity protection algorithms are modelled after 3359 the ESP algorithms described in RFCs 2104, 2406, 2451. This document 3360 completely specifies the cryptographic processing of IKE data, but 3361 those documents should be consulted for design rationale. We assume a 3362 block cipher with a fixed block size and an integrity check algorithm 3363 that computes a fixed length checksum over a variable size message. 3365 The Payload Type for an Encrypted payload is fifteen (15). The 3366 Encrypted Payload consists of the IKE generic payload header followed 3367 by individual fields as follows: 3369 1 2 3 3370 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 3371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3372 ! Next Payload !C! RESERVED ! Payload Length ! 3373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3374 ! Initialization Vector ! 3375 ! (length is block size for encryption algorithm) ! 3376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3377 ! Encrypted IKE Payloads ! 3378 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3379 ! ! Padding (0-255 octets) ! 3380 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 3381 ! ! Pad Length ! 3382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3383 ~ Integrity Checksum Data ~ 3384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3386 Figure 21: Encrypted Payload Format 3388 o Next Payload - The payload type of the first embedded payload. 3389 Note that this is an exception in the standard header format, 3390 since the Encrypted payload is the last payload in the 3391 message and therefore the Next Payload field would normally 3392 be zero. But because the content of this payload is embedded 3393 payloads and there was no natural place to put the type of 3394 the first one, that type is placed here. 3396 o Payload Length - Includes the lengths of the header, IV, 3397 Encrypted IKE Payloads, Padding, Pad Length and Integrity 3398 Checksum Data. 3400 o Initialization Vector - A randomly chosen value whose length 3401 is equal to the block length of the underlying encryption 3402 algorithm. Recipients MUST accept any value. Senders SHOULD 3403 either pick this value pseudo-randomly and independently for 3404 each message or use the final ciphertext block of the previous 3405 message sent. Senders MUST NOT use the same value for each 3406 message, use a sequence of values with low hamming distance 3407 (e.g., a sequence number), or use ciphertext from a received 3408 message. 3410 o IKE Payloads are as specified earlier in this section. This 3411 field is encrypted with the negotiated cipher. 3413 o Padding MAY contain any value chosen by the sender, and MUST 3414 have a length that makes the combination of the Payloads, the 3415 Padding, and the Pad Length to be a multiple of the encryption 3416 block size. This field is encrypted with the negotiated 3417 cipher. 3419 o Pad Length is the length of the Padding field. The sender 3420 SHOULD set the Pad Length to the minimum value that makes 3421 the combination of the Payloads, the Padding, and the Pad 3422 Length a multiple of the block size, but the recipient MUST 3423 accept any length that results in proper alignment. This 3424 field is encrypted with the negotiated cipher. 3426 o Integrity Checksum Data is the cryptographic checksum of 3427 the entire message starting with the Fixed IKE Header 3428 through the Pad Length. The checksum MUST be computed over 3429 the encrypted message. 3431 3.15 Configuration Payload 3433 The Configuration payload, denoted CP in this document, is used to 3434 exchange configuration information between IKE peers. Currently, the 3435 only defined uses for this exchange is for an IRAC to request an 3436 internal IP address from an IRAS or for either party to request 3437 version information from the other, but this payload is intended as a 3438 likely place for future extensions. 3440 Configuration payloads are of type CFG_REQUEST/CFG_REPLY or 3441 CFG_SET/CFG_ACK (see CFG Type in the payload description below). 3442 CFG_REQUEST and CFG_SET payloads may optionally be added to any IKE 3443 request. The IKE response MUST include either a corresponding 3444 CFG_REPLY or CFG_ACK or a Notify payload with an error type 3445 indicating why the request could not be honored. An exception is that 3446 a minimal implementation MAY ignore all CFG_REQUEST and CFG_SET 3447 payloads, so a response message without a corresponding CFG_REPLY or 3448 CFG_ACK MUST be accepted as an indication that the request was not 3449 supported. 3451 "CFG_REQUEST/CFG_REPLY" allows an IKE endpoint to request information 3452 from its peer. If an attribute in the CFG_REQUEST Configuration 3453 Payload is not zero length it is taken as a suggestion for that 3454 attribute. The CFG_REPLY Configuration Payload MAY return that 3455 value, or a new one. It MAY also add new attributes and not include 3456 some requested ones. Requestors MUST ignore returned attributes that 3457 they do not recognize. 3459 Some attributes MAY be multi-valued, in which case multiple attribute 3460 values of the same type are sent and/or returned. Generally, all 3461 values of an attribute are returned when the attribute is requested. 3462 For some attributes (in this version of the specification only 3463 internal addresses), multiple requests indicates a request that 3464 multiple values be assigned. For these attributes, the number of 3465 values returned SHOULD NOT exceed the number requested. 3467 If the data type requested in a CFG_REQUEST is not recognized or not 3468 supported, the responder MUST NOT return an error type but rather 3469 MUST either send a CFG_REPLY which MAY be empty or a reply not 3470 containing a CFG_REPLY payload at all. Error returns are reserved for 3471 cases where the request is recognized but cannot be performed as 3472 requested or the request is badly formatted. 3474 "CFG_SET/CFG_ACK" allows an IKE endpoint to push configuration data 3475 to its peer. In this case the CFG_SET Configuration Payload contains 3476 attributes the initiator wants its peer to alter. The responder MUST 3477 return a Configuration Payload if it accepted any of the 3478 configuration data and it MUST contain the attributes that the 3479 responder accepted with zero length data. Those attributes that it 3480 did not accept MUST NOT be in the CFG_ACK Configuration Payload. If 3481 no attributes were accepted, the responder MUST return either an 3482 empty CFG_ACK payload or a response message without a CFG_ACK 3483 payload. There are currently no defined uses for the CFG_SET/CFG_ACK 3484 exchange, though they may be used in connection with extensions based 3485 on Vendor IDs. An minimal implementation of this specification MAY 3486 ignore CFG_SET payloads. 3488 Extensions via the CP payload SHOULD NOT be used for general purpose 3489 management. Its main intent is to provide a bootstrap mechanism to 3490 exchange information within IPsec from IRAS to IRAC. While it MAY be 3491 useful to use such a method to exchange information between some 3492 Security Gateways (SGW) or small networks, existing management 3493 protocols such as DHCP [DHCP], RADIUS [RADIUS], SNMP or LDAP [LDAP] 3494 should be preferred for enterprise management as well as subsequent 3495 information exchanges. 3497 The Configuration Payload is defined as follows: 3499 1 2 3 3500 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 3501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3502 ! Next Payload !C! RESERVED ! Payload Length ! 3503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3504 ! CFG Type ! RESERVED ! 3505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3506 ! ! 3507 ~ Configuration Attributes ~ 3508 ! ! 3509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3511 Figure 22: Configuration Payload Format 3513 The payload type for the Configuration Payload is 16. 3515 o CFG Type (1 octet) - The type of exchange represented by the 3516 Configuration Attributes. 3518 CFG Type Value 3519 =========== ===== 3520 RESERVED 0 3521 CFG_REQUEST 1 3522 CFG_REPLY 2 3523 CFG_SET 3 3524 CFG_ACK 4 3526 values 5-127 are reserved to IANA. Values 128-255 are for private 3527 use among mutually consenting parties. 3529 o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on 3530 receipt. 3532 o Configuration Attributes (variable length) - These are type 3533 length values specific to the Configuration Payload and are 3534 defined below. There may be zero or more Configuration 3535 Attributes in this payload. 3537 3.15.1 Configuration Attributes 3539 1 2 3 3540 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 3541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3542 !R| Attribute Type ! Length | 3543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3544 | | 3545 ~ Value ~ 3546 | | 3547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3549 Figure 23: Configuration Attribute Format 3551 o Reserved (1 bit) - This bit MUST be set to zero and MUST be 3552 ignored on receipt. 3554 o Attribute Type (7 bits) - A unique identifier for each of the 3555 Configuration Attribute Types. 3557 o Length (2 octets) - Length in octets of Value. 3559 o Value (0 or more octets) - The variable length value of this 3560 Configuration Attribute. 3562 The following attribute types have been defined: 3564 Multi- 3565 Attribute Type Value Valued Length 3566 ======================= ===== ====== ================== 3567 RESERVED 0 3568 INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets 3569 INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets 3570 INTERNAL_IP4_DNS 3 YES 0 or 4 octets 3571 INTERNAL_IP4_NBNS 4 YES 0 or 4 octets 3572 INTERNAL_ADDRESS_EXPIRY 5 NO 0 or 4 octets 3573 INTERNAL_IP4_DHCP 6 YES 0 or 4 octets 3574 APPLICATION_VERSION 7 NO 0 or more 3575 INTERNAL_IP6_ADDRESS 8 YES* 0 or 16 octets 3576 INTERNAL_IP6_NETMASK 9 NO 0 or 16 octets 3577 INTERNAL_IP6_DNS 10 YES 0 or 16 octets 3578 INTERNAL_IP6_NBNS 11 YES 0 or 16 octets 3579 INTERNAL_IP6_DHCP 12 YES 0 or 16 octets 3580 INTERNAL_IP4_SUBNET 13 NO 0 or 8 octets 3581 SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 3582 INTERNAL_IP6_SUBNET 15 NO 17 octets 3584 * These attributes may be multi-valued on return only if 3585 multiple values were requested. 3587 Types 16-16383 are reserved to IANA. Values 16384-32767 are for 3588 private use among mutually consenting parties. 3590 o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the 3591 internal network, sometimes called a red node address or 3592 private address and MAY be a private address on the Internet. 3593 Multiple internal addresses MAY be requested by requesting 3594 multiple internal address attributes. The responder MAY only 3595 send up to the number of addresses requested. 3597 The requested address is valid until the expiry time defined 3598 with the INTERNAL_ADDRESS EXPIRY attribute or there are no 3599 IKE_SAs between the peers. 3601 o INTERNAL_IP4_NETMASK, INTERNAL_IP6_NETMASK - The internal 3602 network's netmask. Only one netmask is allowed in the request 3603 and reply messages (e.g., 255.255.255.0) and it MUST be used 3604 only with an INTERNAL_ADDRESS attribute. 3606 o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a 3607 DNS server within the network. Multiple DNS servers MAY be 3608 requested. The responder MAY respond with zero or more DNS 3609 server attributes. 3611 o INTERNAL_IP4_NBNS, INTERNAL_IP6_NBNS - Specifies an address of 3612 a NetBios Name Server (WINS) within the network. Multiple NBNS 3613 servers MAY be requested. The responder MAY respond with zero 3614 or more NBNS server attributes. 3616 o INTERNAL_ADDRESS_EXPIRY - Specifies the number of seconds that 3617 the host can use the internal IP address. The host MUST renew 3618 the IP address before this expiry time. Only one of these 3619 attributes MAY be present in the reply. 3621 o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to 3622 send any internal DHCP requests to the address contained within 3623 the attribute. Multiple DHCP servers MAY be requested. The 3624 responder MAY respond with zero or more DHCP server attributes. 3626 o APPLICATION_VERSION - The version or application information of 3627 the IPsec host. This is a string of printable ASCII characters 3628 that is NOT null terminated. 3630 o INTERNAL_IP4_SUBNET - The protected sub-networks that this 3631 edge-device protects. This attribute is made up of two fields; 3632 the first being an IP address and the second being a netmask. 3634 Multiple sub-networks MAY be requested. The responder MAY 3635 respond with zero or more sub-network attributes. 3637 o SUPPORTED_ATTRIBUTES - When used within a Request, this 3638 attribute MUST be zero length and specifies a query to the 3639 responder to reply back with all of the attributes that it 3640 supports. The response contains an attribute that contains a 3641 set of attribute identifiers each in 2 octets. The length 3642 divided by 2 (octets) would state the number of supported 3643 attributes contained in the response. 3645 o INTERNAL_IP6_SUBNET - The protected sub-networks that this 3646 edge-device protects. This attribute is made up of two fields; 3647 the first being a 16 octet IPv6 address the second being a one 3648 octet prefix-length as defined in [ADDRIPV6]. Multiple 3649 sub-networks MAY be requested. The responder MAY respond with 3650 zero or more sub-network attributes. 3652 Note that no recommendations are made in this document how an 3653 implementation actually figures out what information to send in a 3654 reply. i.e., we do not recommend any specific method of an IRAS 3655 determining which DNS server should be returned to a requesting 3656 IRAC. 3658 3.16 Extended Authentication Protocol (EAP) Payload 3660 The Extended Authentication Protocol Payload, denoted EAP in this 3661 memo, allows IKE_SAs to be authenticated using the protocol defined 3662 in RFC 2284 [EAP] and subsequent extensions to that protocol. The 3663 full set of acceptable values for the payload are defined elsewhere, 3664 but a short summary of RFC 2284 is included here to make this 3665 document stand alone in the common cases. 3667 1 2 3 3668 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 3669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3670 ! Next Payload !C! RESERVED ! Payload Length ! 3671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3672 ! ! 3673 ~ EAP Message ~ 3674 ! ! 3675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3677 Figure 24: EAP Payload Format 3679 The payload type for an EAP Payload is 17. 3681 1 2 3 3682 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 3683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3684 ! Code ! Identifier ! Length ! 3685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3686 ! Type ! Type_Data... 3687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 3689 Figure 25: EAP Message Format 3691 o Code (one octet) indicates whether this message is a 3692 Request (1), Response (2), Success (3), or Failure (4). 3694 o Identifier (one octet) is used in PPP to distinguish replayed 3695 messages from repeated ones. Since in IKE, EAP runs over a 3696 reliable protocol, it serves no function here. In a response 3697 message this octet MUST be set to match the identifier in the 3698 corresponding request. In other messages, this field MAY 3699 be set to any value. 3701 o Length (two octets) is the length of the EAP message and MUST 3702 be four less than the Payload Length of the encapsulating 3703 payload. 3705 o Type (one octet) is present only if the Code field is Request 3706 (1) or Response (2). For other types, the EAP message length 3707 MUST be four octets and the Type and Type_Data fields MUST NOT 3708 be present. In a Request (1) message, Type indicates the 3709 data being requested. In a Response (2) message, Type MUST 3710 either be NAC or match the type of the data requested. The 3711 following types are defined in RFC 2284: 3713 1 Identity 3714 2 Notification 3715 3 NAK (Response Only) 3716 4 MD5-Challenge 3717 5 One-Time Password (OTP) 3718 6 Generic Token Card 3720 o Type_Data (Variable Length) contains data depending on the Code 3721 and Type. In Requests other than MD5-Challenge, this field 3722 contains a prompt to be displayed to a human user. For NAK, it 3723 contains one octet suggesting the type of authentication the 3724 Initiator would prefer to use. For most other responses, it 3725 contains the authentication code typed by the human user. 3727 Note that since IKE passes an indication of initiator identity in 3728 message 3 of the protocol, EAP based prompts for Identity SHOULD NOT 3729 be used. 3731 4 Conformance Requirements 3733 In order to assure that all implementations of IKEv2 can 3734 interoperate, there are MUST support requirements in addition to 3735 those listed elsewhere. Of course, IKEv2 is a security protocol, and 3736 one of its major functions is preventing the bad guys from 3737 interoperating with one's systems. So a particular implementation may 3738 be configured with any of a number of restrictions concerning 3739 algorithms and trusted authorities that will prevent universal 3740 interoperability. 3742 IKEv2 is designed to permit minimal implementations that can 3743 interoperate with all compliant implementations. There are a series 3744 of optional features that can easily be ignored by a particular 3745 implementation if it does not support that feature. Those features 3746 include: 3748 Ability to negotiate SAs through a NAT and tunnel the resulting ESP 3749 SA over UDP. 3751 Ability to request (and respond to a request for) a temporary IP 3752 address on the remote end of a tunnel. 3754 Ability to support various types of legacy authentication. 3756 Ability to support window sizes greater than one. 3758 Ability to establish multiple ESP and/or AH SAs within a single 3759 IKE_SA. 3761 Ability to rekey SAs. 3763 To assure interoperability, all implementations MUST be capable of 3764 parsing all payload types (if only to skip over them) and to ignore 3765 payload types that it does not support unless the critical bit is set 3766 in the payload header. If the critical bit is set in an unsupported 3767 payload header, all implementations MUST reject the messages 3768 containing those payloads. 3770 Every implementation MUST be capable of doing four message 3771 IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, 3772 one for ESP and/or AH). Implementations MAY be initiate-only or 3773 respond-only if appropriate for their platform. Every implementation 3774 MUST be capable of responding to an INFORMATIONAL exchange, but a 3775 minimal implementation MAY respond to any INFORMATIONAL message with 3776 an empty INFORMATIONAL reply. A minimal implementation MAY support 3777 the CREATE_CHILD_SA exchange only in so far as to recognize requests 3778 and reject them with a Notify payload of type NO_ADDITIONAL_SAS. A 3779 minimal implementation need not be able to initiate CREATE_CHILD_SA 3780 or INFORMATIONAL exchanges. When an SA expires (based on locally 3781 configured values of either lifetime or octets passed), and 3782 implementation MAY either try to renew it with a CREATE_CHILD_SA 3783 exchange or it MAY delete (close) the old SA and create a new one. If 3784 the responder rejects the CREATE_CHILD_SA request with a 3785 NO_ADDITIONAL_SAS notification, the implementation MUST be capable of 3786 instead closing the old SA and creating a new one. 3788 Implementations are not required to support requesting temporary IP 3789 addresses or responding to such requests. If an implementation does 3790 support issuing such requests, it MUST include a CP payload in 3791 message 3 containing at least a field of type INTERNAL_IP4_ADDRESS or 3792 INTERNAL_IP6_ADDRESS. All other fields are optional. If an 3793 implementation supports responding to such requests, it MUST parse 3794 the CP payload of type CFG_REQUEST in message 3 and recognize a field 3795 of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports 3796 leasing an address of the appropriate type, it MUST return a CP 3797 payload of type CFG_REPLY containing an address of the requested 3798 type. The responder SHOULD include all of the other related 3799 attributes if it has them. 3801 A minimal IPv4 responder implementation will ignore the contents of 3802 the CP payload except to determine that it includes an 3803 INTERNAL_IP4_ADDRESS attribute and will respond with the address and 3804 other related attributes regardless of whether the initiator 3805 requested them. 3807 A minimal IPv4 initiator will generate a CP payload containing only 3808 an INTERNAL_IP4_ADDRESS attribute and will parse the response 3809 ignoring attributes it does not know how to use. The only attribute 3810 it MUST be able to process is INTERNAL_ADDRESS_EXPIRY, which it must 3811 use to bound the lifetime of the SA unless it successfully renews the 3812 lease before it expires. Minimal initiators need not be able to 3813 request lease renewals and minimal responders need not respond to 3814 them. 3816 For an implementation to be called conforming to this specification, 3817 it MUST be possible to configure it to accept the following: 3819 PKIX Certificates containing and signed by RSA keys of size 1024 or 3820 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, 3821 ID_RFC822_ADDR, or ID_DER_ASN1_DN. 3823 Shared key authentication where the ID passes is any of ID_KEY_ID, 3824 ID_FQDN, or ID_RFC822_ADDR. 3826 Authentication where the responder is authenticated using PKIX 3827 Certificates and the initiator is authenticated using shared key 3828 authentication. 3830 5 Security Considerations 3832 Repeated re-keying using CREATE_CHILD_SA without PFS leaves all SAs 3833 vulnerable to cryptanalysis of a single key or overrun of either 3834 endpoint. Implementers should take note of this fact and set a limit 3835 on CREATE_CHILD_SA exchanges between exponentiations. This memo does 3836 not prescribe such a limit. 3838 The strength of a key derived from a Diffie-Hellman exchange using 3839 any of the groups defined here depends on the inherent strength of 3840 the group, the size of the exponent used, and the entropy provided by 3841 the random number generator used. Due to these inputs it is difficult 3842 to determine the strength of a key for any of the defined groups. 3843 Diffie-Hellman group number two, when used with a strong random 3844 number generator and an exponent no less than 200 bits, is sufficient 3845 for use with 3DES. Groups three through five provide greater 3846 security. Group one is for historic purposes only and does not 3847 provide sufficient strength except for use with DES, which is also 3848 for historic use only. Implementations should make note of these 3849 conservative estimates when establishing policy and negotiating 3850 security parameters. 3852 Note that these limitations are on the Diffie-Hellman groups 3853 themselves. There is nothing in IKE which prohibits using stronger 3854 groups nor is there anything which will dilute the strength obtained 3855 from stronger groups (limited by the strength of the other algorithms 3856 negotiated including the prf function). In fact, the extensible 3857 framework of IKE encourages the definition of more groups; use of 3858 elliptical curve groups may greatly increase strength using much 3859 smaller numbers. 3861 It is assumed that all Diffie-Hellman exponents are erased from 3862 memory after use. In particular, these exponents MUST NOT be derived 3863 from long-lived secrets like the seed to a pseudo-random generator 3864 that is not erased after use. 3866 The strength of all keys are limited by the size of the output of the 3867 negotiated prf function. For this reason, a prf function whose output 3868 is less than 128 bits (e.g., 3DES-CBC) MUST never be used with this 3869 protocol. 3871 The security of this protocol is critically dependent on the 3872 randomness of the randomly chosen parameters. These should be 3873 generated by a strong random or properly seeded pseudo-random source 3874 (see [RFC1750]). Implementers should take care to ensure that use of 3875 random numbers for both keys and nonces is engineered in a fashion 3876 that does not undermine the security of the keys. 3878 For information on the rationale of many of the cryptographic design 3879 choices in this protocol, see [SIGMA]. 3881 When using pre-shared keys, a critical consideration is how to assure 3882 the randomness of these secrets. The strongest practice is to ensure 3883 that any pre-shared key contain as much randomness as the strongest 3884 key being negotiated. Deriving a shared secret from a password, name, 3885 or other low entropy source is not secure. These sources are subject 3886 to dictionary and social engineering attacks, among others. 3888 The NAT_DETECTION_*_IP notifications contain a hash of the addresses 3889 and ports in an attempt to hide internal IP addresses behind a NAT 3890 from the IKE peer. As the IPv4 address space is only 32 bits, and it 3891 is usually very sparse, it might be possible for the attacker to find 3892 out the internal address used behind the NAT box by trying all 3893 possible IP-addresses and trying to find the matching hash. The port 3894 numbers are normally fixed to 500, and the SPIs can be extracted from 3895 the packet. This limits the hash calculations down to 2^32. If 3896 educated guess of use of private address space is done, then the 3897 number of hash calculations needed to find out the internal IP 3898 address goes down to the 2^24 + 2 * (2^16). 3900 6 IANA Considerations 3902 This document contains many "magic numbers" to be maintained by the 3903 Internet Assigned Numbers Authority (IANA). While in many cases the 3904 values were chosen so as to avoid collisions with other 3905 specifications, these should be considered a new IANA registry for 3906 IKEv2. The tables to be maintained are: 3908 Payload Types 3909 Transform Types 3910 For each Transform Type defined, the assigned Transform values 3911 Authentication Method 3912 Security Protocol ID 3913 Error codes 3914 Status codes 3915 IPcomp Transform IDs 3916 Configuration request types 3917 Configuration attribute types 3919 7 Intellectual Property Rights 3921 The IETF has been notified of intellectual property rights claimed in 3922 regard to some or all of the specification contained in this 3923 document. For more information consult the online list of claimed 3924 rights. 3926 8 Acknowledgements 3928 This document is a collaborative effort of the entire IPsec WG. If 3929 there were no limit to the number of authors that could appear on an 3930 RFC, the following, in alphabetical order, would have been listed: 3931 Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt 3932 Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, J. 3933 Ioannidis, Steve Kent, Angelos Keromytis, Tero Kivinen, Hugo 3934 Krawczyk, Andrew Krywaniuk, Radia Perlman, O. Reingold. Many other 3935 people contributed to the design. It is an evolution of IKEv1, 3936 ISAKMP, and the IPsec DOI, each of which has its own list of authors. 3937 Hugh Daniel suggested the feature of having the initiator, in message 3938 3, specify a name for the responder, and gave the feature the cute 3939 name "You Tarzan, Me Jane". David Faucher and Valery Smyzlov helped 3940 refine the design of the traffic selector negotiation. 3942 9 References 3944 9.1 Normative References 3946 [ADDGROUP] Kivinen, T., and Kojo, M., "More Modular Exponential 3947 (MODP) Diffie-Hellman groups for Internet Key 3948 Exchange (IKE)", RFC 3526, May 2003. 3950 [ADDRIPV6] Hinden, R., and Deering, S., 3951 "Internet Protocol Version 6 (IPv6) Addressing 3952 Architecture", RFC 3513, April 2003. 3954 [Bra96] Bradner, S., "The Internet Standards Process -- 3955 Revision 3", BCP 9, RFC 2026, October 1996. 3957 [Bra97] Bradner, S., "Key Words for use in RFCs to indicate 3958 Requirement Levels", BCP 14, RFC 2119, March 1997. 3960 [EAP] Blunk, L. and Vollbrecht, J., "PPP Extensible 3961 Authentication Protocol (EAP), RFC 2284, March 1998. 3963 [ESPCBC] Pereira, R., Adams, R., "The ESP CBC-Mode Cipher 3964 Algorithms", RFC 2451, November 1998. 3966 [RFC 3280] Housley, R., Polk, W., Ford, W., Solo, D., "Internet 3967 X.509 Public Key Infrastructure Certificate and 3968 Certificate Revocation List (CRL) Profile", RFC 3280, 3969 April 2002. 3971 9.2 Non-normative References 3973 [Ble98] Bleichenbacher, D., "Chosen Ciphertext Attacks against 3974 Protocols Based on RSA Encryption Standard PKCS#1", 3975 Advances in Cryptology Eurocrypt '98, Springer-Verlag, 3976 1998. 3978 [BR94] Bellare, M., and Rogaway P., "Optimal Asymmetric 3979 Encryption", Advances in Cryptology Eurocrypt '94, 3980 Springer-Verlag, 1994. 3982 [DES] ANSI X3.106, "American National Standard for Information 3983 Systems-Data Link Encryption", American National Standards 3984 Institute, 1983. 3986 [DH] Diffie, W., and Hellman M., "New Directions in 3987 Cryptography", IEEE Transactions on Information Theory, V. 3988 IT-22, n. 6, June 1977. 3990 [DHCP] R. Droms, "Dynamic Host Configuration Protocol", 3991 RFC2131 3993 [DSS] NIST, "Digital Signature Standard", FIPS 186, National 3994 Institute of Standards and Technology, U.S. Department of 3995 Commerce, May, 1994. 3997 [HC98] Harkins, D., Carrel, D., "The Internet Key Exchange 3998 (IKE)", RFC 2409, November 1998. 4000 [Hutt02] Huttunen, A. et. al., "UDP Encapsulation of IPsec 4001 Packets", draft-ietf-ipsec-udp-encaps-05.txt, December 4002 2002. 4004 [IDEA] Lai, X., "On the Design and Security of Block Ciphers," 4005 ETH Series in Information Processing, v. 1, Konstanz: 4006 Hartung-Gorre Verlag, 1992 4008 [IPCOMP] Shacham, A., Monsour, R., Pereira, R., and Thomas, M., "IP 4009 Payload Compression Protocol (IPComp)", RFC 2393, 4010 August 1998. 4012 [Ker01] Keromytis, A., Sommerfeld, B., "The 'Suggested ID' 4013 Extension for IKE", draft-keromytis-ike-id-00.txt, 2001 4015 [KBC96] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 4016 Hashing for Message Authentication", RFC 2104, February 4017 1997. 4019 [LDAP] M. Wahl, T. Howes, S. Kille., "Lightweight Directory 4020 Access Protocol (v3)", RFC2251 4022 [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, 4023 April 1992. 4025 [MSST98] Maughhan, D., Schertler, M., Schneider, M., and Turner, J. 4026 "Internet Security Association and Key Management Protocol 4027 (ISAKMP)", RFC 2408, November 1998. 4029 [Orm96] Orman, H., "The Oakley Key Determination Protocol", RFC 4030 2412, November 1998. 4032 [PFKEY] McDonald, D., Metz, C., and Phan, B., "PFKEY Key 4033 Management API, Version 2", RFC2367, July 1998. 4035 [PKCS1] Kaliski, B., and J. Staddon, "PKCS #1: RSA Cryptography 4036 Specifications Version 2", September 1998. 4038 [PK01] Perlman, R., and Kaufman, C., "Analysis of the IPsec key 4039 exchange Standard", WET-ICE Security Conference, MIT,2001, 4040 http://sec.femto.org/wetice-2001/papers/radia-paper.pdf. 4042 [Pip98] Piper, D., "The Internet IP Security Domain Of 4043 Interpretation for ISAKMP", RFC 2407, November 1998. 4045 [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote 4046 Authentication Dial In User Service (RADIUS)", RFC2138 4048 [RFC1750] Eastlake, D., Crocker, S., and Schiller, J., "Randomness 4049 Recommendations for Security", RFC 1750, December 1994. 4051 [RFC2401] Kent, S., and Atkinson, R., "Security Architecture for 4052 the Internet Protocol", RFC 2401, November 1998. 4054 [RFC2474] Nichols, K., Blake, S., Baker, F. and Black, D., 4055 "Definition of the Differentiated Services Field (DS 4056 Field) in the IPv4 and IPv6 Headers", RFC 2474, 4057 December 1998. 4059 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. 4060 and Weiss, W., "An Architecture for Differentiated 4061 Services", RFC 2475, December 1998. 4063 [RFC2522] Karn, P., and Simpson, W., "Photuris: Session-Key 4064 Management Protocol", RFC 2522, March 1999. 4066 [RFC3168] Ramakrishnan, K., Floyd, S., and Black, D., 4067 "The Addition of Explicit Congestion Notification (ECN) 4068 to IP", RFC 3168, September 2001. 4070 [RSA] Rivest, R., Shamir, A., and Adleman, L., "A Method for 4071 Obtaining Digital Signatures and Public-Key 4072 Cryptosystems", Communications of the ACM, v. 21, n. 2, 4073 February 1978. 4075 [SHA] NIST, "Secure Hash Standard", FIPS 180-1, National 4076 Institute of Standards and Technology, U.S. Department 4077 of Commerce, May 1994. 4079 [SIGMA] Krawczyk, H., "SIGMA: the `SIGn-and-MAc' Approach to 4080 Authenticated Diffie-Hellman and its Use in the IKE 4081 Protocols", in Advances in Cryptography - CRYPTO 2003 4082 Proceedings, LNCS 2729, Springer, 2003. Available at: 4083 http://www.ee.technion.ac.il/~hugo/sigma.html 4085 [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange 4086 Mechanism for Internet", from IEEE Proceedings of the 4087 1996 Symposium on Network and Distributed Systems 4088 Security. 4090 [X.501] ITU-T Recommendation X.501: Information Technology - 4091 Open Systems Interconnection - The Directory: Models, 4092 1993. 4094 [X.509] ITU-T Recommendation X.509 (1997 E): Information 4095 Technology - Open Systems Interconnection - The 4096 Directory: Authentication Framework, June 1997. 4098 Appendix A: Summary of changes from IKEv1 4100 The goals of this revision to IKE are: 4102 1) To define the entire IKE protocol in a single document, replacing 4103 RFCs 2407, 2408, and 2409 and incorporating subsequent changes to 4104 support NAT Traversal, Extended Authentication, and Remote Address 4105 acquisition. 4107 2) To simplify IKE by replacing the eight different initial exchanges 4108 with a single four message exchange (with changes in authentication 4109 mechanisms affecting only a single AUTH payload rather than 4110 restructuring the entire exchange); 4112 3) To remove the Domain of Interpretation (DOI), Situation (SIT), and 4113 Labeled Domain Identifier fields, and the Commit and Authentication 4114 only bits; 4116 4) To decrease IKE's latency in the common case by making the initial 4117 exchange be 2 round trips (4 messages), and allowing the ability to 4118 piggyback setup of a CHILD-SA on that exchange; 4120 5) To replace the cryptographic syntax for protecting the IKE 4121 messages themselves with one based closely on ESP to simplify 4122 implementation and security analysis; 4124 6) To reduce the number of possible error states by making the 4125 protocol reliable (all messages are acknowledged) and sequenced. This 4126 allows shortening CREATE_CHILD_SA exchanges from 3 messages to 2; 4128 7) To increase robustness by allowing the responder to not do 4129 significant processing until it receives a message proving that the 4130 initiator can receive messages at its claimed IP address, and not 4131 commit any state to an exchange until the initiator can be 4132 cryptographically authenticated; 4134 8) To fix bugs such as the hash problem documented in [draft-ietf- 4135 ipsec-ike-hash-revised-02.txt]; 4137 9) To specify Traffic Selectors in their own payloads type rather 4138 than overloading ID payloads, and making more flexible the Traffic 4139 Selectors that may be specified; 4141 10) To specify required behavior under certain error conditions or 4142 when data that is not understood is received in order to make it 4143 easier to make future revisions in a way that does not break 4144 backwards compatibility; 4145 11) To incorporate ideas from draft-ietf-ipsec-nat-reqts-04.txt to 4146 allow IKE to negotiate through NAT gateways; 4148 12) To simplify and clarify how shared state is maintained in the 4149 presence of network failures and Denial of Service attacks; and 4151 13) To maintain existing syntax and magic numbers to the extent 4152 possible to make it likely that implementations of IKEv1 can be 4153 enhanced to support IKEv2 with minimum effort. 4155 Appendix B: Diffie-Hellman Groups 4157 There are 5 different Diffie-Hellman groups defined for use in IKE. 4158 These groups were generated by Richard Schroeppel at the University 4159 of Arizona. Properties of these primes are described in [Orm96]. 4161 The strength supplied by group one may not be sufficient for the 4162 mandatory-to-implement encryption algorithm and is here for historic 4163 reasons. 4165 Additional Diffie-Hellman groups have been defined in [ADDGROUP]. 4167 B.1 Group 1 - 768 Bit MODP 4169 This group is assigned id 1 (one). 4171 The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } 4172 Its hexadecimal value is: 4174 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 4175 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 4176 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 4177 A63A3620 FFFFFFFF FFFFFFFF 4179 The generator is 2. 4181 B.2 Group 2 - 1024 Bit MODP 4183 This group is assigned id 2 (two). 4185 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. 4186 Its hexadecimal value is: 4188 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 4189 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 4190 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 4191 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 4192 49286651 ECE65381 FFFFFFFF FFFFFFFF 4194 The generator is 2. 4196 B.3 Group 3 - 155 Bit EC2N 4198 This group is assigned id 3 (three). The curve is based on the Galois 4199 Field GF[2^155]. The field size is 155. The irreducible polynomial 4200 for the field is: 4201 u^155 + u^62 + 1. 4202 The equation for the elliptic curve is: 4203 y^2 + xy = x^3 + ax^2 + b. 4205 Field Size: 155 4206 Group Prime/Irreducible Polynomial: 4207 0x0800000000000000000000004000000000000001 4208 Group Generator One: 0x7b 4209 Group Curve A: 0x0 4210 Group Curve B: 0x07338f 4211 Group Order: 0x0800000000000000000057db5698537193aef944 4213 The data in the KE payload when using this group is the value x from 4214 the solution (x,y), the point on the curve chosen by taking the 4215 randomly chosen secret Ka and computing Ka*P, where * is the 4216 repetition of the group addition and double operations, P is the 4217 curve point with x coordinate equal to generator 1 and the y 4218 coordinate determined from the defining equation. The equation of 4219 curve is implicitly known by the Group Type and the A and B 4220 coefficients. There are two possible values for the y coordinate; 4221 either one can be used successfully (the two parties need not agree 4222 on the selection). 4224 B.4 Group 4 - 185 Bit EC2N 4226 This group is assigned id 4 (four). The curve is based on the Galois 4227 Field GF[2^185]. The field size is 185. The irreducible polynomial 4228 for the field is: 4229 u^185 + u^69 + 1. 4231 The equation for the elliptic curve is: 4232 y^2 + xy = x^3 + ax^2 + b. 4234 Field Size: 185 4235 Group Prime/Irreducible Polynomial: 4236 0x020000000000000000000000000000200000000000000001 4237 Group Generator One: 0x18 4238 Group Curve A: 0x0 4239 Group Curve B: 0x1ee9 4240 Group Order: 0x01ffffffffffffffffffffffdbf2f889b73e484175f94ebc 4242 The data in the KE payload when using this group will be identical to 4243 that as when using Oakley Group 3 (three). 4245 B.5 Group 5 - 1536 Bit MODP 4247 This group is assigned id 5 (five). 4249 The prime is 2^1536 - 2^1472 - 1 + 2^64 * {[2^1406 pi] + 741804}. 4250 Its hexadecimal value is 4252 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 4253 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 4254 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 4255 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 4256 49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 4257 FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 4258 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF 4260 The generator is 2. 4262 Change History 4264 H.1 Changes from IKEv2-00 to IKEv2-01 February 2002 4266 1) Changed Appendix B to specify the encryption and authentication 4267 processing for IKE rather than referencing ESP. Simplified the format 4268 by removing idiosyncrasies not needed for IKE. 4270 2) Added option for authentication via a shared secret key. 4272 3) Specified different keys in the two directions of IKE messages. 4273 Removed requirement of different cookies in the two directions since 4274 now no longer required. 4276 4) Change the quantities signed by the two ends in AUTH fields to 4277 assure the two parties sign different quantities. 4279 5) Changed reference to AES to AES_128. 4281 6) Removed requirement that Diffie-Hellman be repeated when rekeying 4282 IKE_SA. 4284 7) Fixed typos. 4286 8) Clarified requirements around use of port 500 at the remote end in 4287 support of NAT. 4289 9) Clarified required ordering for payloads. 4291 10) Suggested mechanisms for avoiding DoS attacks. 4293 11) Removed claims in some places that the first phase 2 piggybacked 4294 on phase 1 was optional. 4296 H.2 Changes from IKEv2-01 to IKEv2-02 April 2002 4298 1) Moved the Initiator CERTREQ payload from message 1 to message 3. 4300 2) Added a second optional ID payload in message 3 for the Initiator 4301 to name a desired Responder to support the case where multiple named 4302 identities are served by a single IP address. 4304 3) Deleted the optimization whereby the Diffie-Hellman group did not 4305 need to be specified in phase 2 if it was the same as in phase 1 (it 4306 complicated the design with no meaningful benefit). 4308 4) Added a section on the implications of reusing Diffie-Hellman 4309 expontentials 4310 5) Changed the specification of sequence numbers to being at 0 in 4311 both directions. 4313 6) Many editorial changes and corrections, the most significant being 4314 a global replace of "byte" with "octet". 4316 H.3 Changes from IKEv2-02 to IKEv2-03 October 2002 4318 1) Reorganized the document moving introductory material to the 4319 front. 4321 2) Simplified the specification of Traffic Selectors to allow only 4322 IPv4 and IPv6 address ranges, as was done in the JFK spec. 4324 3) Fixed the problem brought up by David Faucher with the fix 4325 suggested by Valery Smyslov. If Bob needs to narrow the selector 4326 range, but has more than one matching narrower range, then if Alice's 4327 first selector is a single address pair, Bob chooses the range that 4328 encompasses that. 4330 4) To harmonize with the JFK spec, changed the exchange so that the 4331 initial exchange can be completed in four messages even if the 4332 responder must invoke an anti-clogging defense and the initiator 4333 incorrectly anticipates the responder's choice of Diffie-Hellman 4334 group. 4336 5) Replaced the hierarchical SA payload with a simplified version 4337 that only negotiates suites of cryptographic algorithms. 4339 H.4 Changes from IKEv2-03 to IKEv2-04 January 2003 4341 1) Integrated NAT traversal changes (including Appendix A). 4343 2) Moved the anti-clogging token (cookie) from the SPI to a NOTIFY 4344 payload; changed negotiation back to 6 messages when a cookie is 4345 needed. 4347 3) Made capitalization of IKE_SA and CHILD_SA consistent. 4349 4) Changed how IPcomp was negotiated. 4351 5) Added usage scenarios. 4353 6) Added configuration payload for acquiring internal addresses on 4354 remote networks. 4356 7) Added negotiation of tunnel vs transport mode. 4358 H.5 Changes from IKEv2-04 to IKEv2-05 February 2003 4360 1) Shortened Abstract 4362 2) Moved NAT Traversal from Appendix to section 2. Moved changes from 4363 IKEv2 to Appendix A. Renumbered sections. 4365 3) Made language more consistent. Removed most references to Phase 1 4366 and Phase 2. 4368 4) Made explicit the requirements for support of NAT Traversal. 4370 5) Added support for Extended Authentication Protocol methods. 4372 6) Added Response bit to message header. 4374 7) Made more explicit the encoding of Diffie-Hellman numbers in key 4375 expansion algorithms. 4377 8) Added ID payloads to AUTH payload computation. 4379 9) Expanded set of defined cryptographic suites. 4381 10) Added text for MUST/SHOULD support for ID payloads. 4383 11) Added new certificate formats and added MUST/SHOULD text. 4385 12) Clarified use of CERTREQ. 4387 13) Deleted "MUST SUPPORT" column in CP payload specification (it was 4388 inconsistent with surrounding text). 4390 14) Extended and clarified Conformance Requirements section, 4391 including specification of a minimal implementation. 4393 15) Added text to specify ECN handling. 4395 H.6 Changes from IKEv2-05 to IKEv2-06 March 2003 4397 1) Changed the suite based crypto negotiation back to ala carte. 4399 2) Eliminated some awkward page breaks, typographical errors, and 4400 other formatting issues. 4402 3) Tightened language describing cryptographic strength. 4404 4) Added references. 4406 5) Added more specific error codes. 4408 6) Added rationale for unintuitive key generation hash with shared 4409 secret based authentication. 4411 7) Changed the computation of the authenticating AUTH payload as 4412 proposed by Hugo Krawczyk. 4414 8) Changed the dashes (-) to underscores (_) in the names of fields 4415 and constants. 4417 H.7 Changes from IKEv2-06 to IKEv2-07 April 2003 4419 1) Added a list of payload types to section 3.2. 4421 2) Clarified use of SET_WINDOW_SIZE Notify payload. 4423 3) Removed references to COOKIE_REQUIRED Notify payload. 4425 4) Specified how to use a prf with a fixed key size. 4427 5) Removed g^ir from data processed by prf+. 4429 6) Strengthened cautions against using passwords as shared keys. 4431 7) Renamed Protocol_id field SECURITY_PROTOCOL_ID when it is not the 4432 Protocol ID from IP, and changed its values for consistency with 4433 IKEv1. 4435 8) Clarified use of ID payload in access control decisions. 4437 9) Gave IDr and TSr their own payload type numbers. 4439 10) Added Intellectual Property rights section. 4441 11) Clarified some issues in NAT Traversal. 4443 H.8 Changes from IKEv2-07 to IKEv2-08 May 2003 4445 1) Numerous editorial corrections and clarifications. 4447 2) Renamed Gateway to Security Gateway. 4449 3) Made explicit that the ability to rekey SAs without restarting IKE 4450 was optional. 4452 4) Removed last references to MUST and SHOULD ciphersuites. 4454 5) Changed examples to "example.com". 4456 6) Changed references to status codes to status types. 4458 7) Simplified IANA Considerations section 4460 8) Updated References 4462 Editor's Address 4464 Charlie Kaufman 4465 charlie_kaufman@notesdev.ibm.com 4466 IBM 4468 Full Copyright Statement 4470 "Copyright (C) The Internet Society (2003). All Rights Reserved. 4472 This document and translations of it may be copied and furnished to 4473 others, and derivative works that comment on or otherwise explain it 4474 or assist in its implementation may be prepared, copied, published 4475 and distributed, in whole or in part, without restriction of any 4476 kind, provided that the above copyright notice and this paragraph are 4477 included on all such copies and derivative works. However, this 4478 document itself may not be modified in any way, such as by removing 4479 the copyright notice or references to the Internet Society or other 4480 Internet organizations, except as needed for the purpose of 4481 developing Internet standards in which case the procedures for 4482 copyrights defined in the Internet Standards process must be 4483 followed, or as required to translate it into languages other than 4484 English. 4486 The limited permissions granted above are perpetual and will not be 4487 revoked by the Internet Society or its successors or assigns. 4489 This document and the information contained herein is provided on an 4490 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 4491 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 4492 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 4493 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 4494 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."