idnits 2.17.1 draft-ietf-ipsec-ikev2-07.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 94 longer pages, the longest (page 2) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 95 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 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 4160 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). == 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, "lounge.org". The string MUST not contain any terminators (e.g. NULL, CR, etc.). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A fully-qualified RFC822 email address string, An example of a ID_RFC822_ADDR is, "lizard@lounge.org". 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 (April 2003) is 7682 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CERTREQ' is mentioned on line 1334, but not defined == Missing Reference: 'KEi' is mentioned on line 425, but not defined == Missing Reference: 'KEr' is mentioned on line 443, but not defined == Missing Reference: 'CP' is mentioned on line 519, but not defined == Missing Reference: 'RFC 2522' is mentioned on line 792, but not defined == Missing Reference: 'AUTH' is mentioned on line 1343, but not defined == Missing Reference: 'IPCOMP' is mentioned on line 1563, but not defined == Missing Reference: 'RFC 2401' is mentioned on line 1676, but not defined ** Obsolete undefined reference: RFC 2401 (Obsoleted by RFC 4301) == Missing Reference: 'RFC 3168' is mentioned on line 1684, but not defined == Missing Reference: 'IKEv2' is mentioned on line 1696, but not defined == Missing Reference: 'RFC 2474' is mentioned on line 1718, but not defined == Missing Reference: 'RFC 2475' is mentioned on line 1719, but not defined == Missing Reference: 'RFC2401' is mentioned on line 1727, but not defined ** Obsolete undefined reference: RFC 2401 (Obsoleted by RFC 4301) == Missing Reference: 'P' is mentioned on line 2210, but not defined == Missing Reference: 'ADDRIPV6' is mentioned on line 3604, but not defined == Missing Reference: 'ADDGROUP' is mentioned on line 4090, but not defined == Unused Reference: 'ESPCBC' is defined on line 3925, but no explicit reference was found in the text == Unused Reference: 'Ble98' is defined on line 3931, but no explicit reference was found in the text == Unused Reference: 'BR94' is defined on line 3935, but no explicit reference was found in the text == Unused Reference: 'DES' is defined on line 3939, but no explicit reference was found in the text == Unused Reference: 'DH' is defined on line 3943, but no explicit reference was found in the text == Unused Reference: 'DSS' is defined on line 3950, but no explicit reference was found in the text == Unused Reference: 'HC98' is defined on line 3954, but no explicit reference was found in the text == Unused Reference: 'Hutt02' is defined on line 3957, but no explicit reference was found in the text == Unused Reference: 'IDEA' is defined on line 3960, but no explicit reference was found in the text == Unused Reference: 'Ker01' is defined on line 3964, but no explicit reference was found in the text == Unused Reference: 'KBC96' is defined on line 3967, but no explicit reference was found in the text == Unused Reference: 'MD5' is defined on line 3974, but no explicit reference was found in the text == Unused Reference: 'MSST98' is defined on line 3977, but no explicit reference was found in the text == Unused Reference: 'PKCS1' is defined on line 3987, but no explicit reference was found in the text == Unused Reference: 'PK01' is defined on line 3990, but no explicit reference was found in the text == Unused Reference: 'Pip98' is defined on line 3994, but no explicit reference was found in the text == Unused Reference: 'RSA' is defined on line 4002, but no explicit reference was found in the text == Unused Reference: 'SHA' is defined on line 4006, but no explicit reference was found in the text == Unused Reference: 'SKEME' is defined on line 4015, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2284 (ref. 'EAP') (Obsoleted by RFC 3748) -- 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 -- No information found for draft-keronytis-ike-id - is the name correct? -- 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) Summary: 9 errors (**), 0 flaws (~~), 47 warnings (==), 9 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-07.txt April 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 Gateway to Gateway Tunnel..............................5 59 1.1.2 Endpoint to Endpoint Transport.........................5 60 1.1.3 Endpoint to 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.............11 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...............15 72 2.6 Cookies.................................................17 73 2.7 Cryptographic Algorithm Negotiation.....................19 74 2.8 Rekeying................................................20 75 2.9 Traffic Selector Negotiation............................21 76 2.10 Nonces.................................................23 77 2.11 Address and Port Agility...............................23 78 2.12 Reuse of Diffie-Hellman Exponentials...................24 79 2.13 Generating Keying Material.............................24 80 2.14 Generating Keying Material for the IKE_SA..............25 81 2.15 Authentication of the IKE_SA...........................26 82 2.16 Extended Authentication Protocol Methods...............27 83 2.17 Generating Keying Material for CHILD_SAs...............29 84 2.18 Rekaying IKE_SAs using a CREATE_CHILD_SA exchange......29 85 2.19 Requesting an internal address on a remote network.....30 86 2.20 Requesting a Peer's Version............................31 87 2.21 Error Handling.........................................32 88 2.22 IPcomp.................................................33 89 2.23 NAT Traversal..........................................33 90 2.24 ECN Notification.......................................35 91 3 Header and Payload Formats................................36 92 3.1 The IKE Header..........................................36 93 3.2 Generic Payload Header..................................39 94 3.3 Security Association Payload............................40 95 3.3.1 Proposal Substructure.................................42 96 3.3.2 Transform Substructure................................44 97 3.3.3 Mandatory Transform Types.............................46 98 3.3.4 Mandatory Transform IDs...............................47 99 3.3.5 Transform Attributes..................................48 100 3.3.6 Attribute Negotiation.................................50 101 3.4 Key Exchange Payload....................................51 102 3.5 Identification Payload..................................52 103 3.6 Certificate Payload.....................................53 104 3.7 Certificate Request Payload.............................55 105 3.8 Authentication Payload..................................57 106 3.9 Nonce Payload...........................................58 107 3.10 Notify Payload.........................................58 108 3.10.1 Notify Message Types.................................59 109 3.11 Delete Payload.........................................64 110 3.12 Vendor ID Payload......................................66 111 3.13 Traffic Selector Payload...............................67 112 3.13.1 Traffic Selector.....................................68 113 3.14 Encrypted Payload......................................69 114 3.15 Configuration Payload..................................71 115 3.15.1 Configuration Attributes.............................74 116 3.16 Extended Authentication Protocol (EAP) Payload.........76 117 4 Conformance Requirements..................................78 118 5 Security Considerations...................................80 119 6 IANA Considerations.......................................81 120 7 Intellectual property rights..............................81 121 8 Acknowledgements..........................................81 122 9 References................................................82 123 9.1 Normative References....................................82 124 9.2 Non-normative References................................82 125 Appendix A: Summary of Changes from IKEv1...................85 126 Appendix B: Diffie-Hellman Groups...........................87 127 Change History..............................................90 128 Editor's Address............................................93 129 Full Copyright Statement....................................93 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 (RFC 2406) and/or AH (RFC 2402). It also negotiates use of IPcomp 158 (RFC 2393) in connection with an ESP and/or AH SA. We call the IKE 159 SA an "IKE_SA". The SAs for ESP and/or AH that get set up through 160 that IKE_SA we call "CHILD_SA"s. 162 All IKE communications consist of pairs of messages: a request and a 163 response. The pair is called an "exchange". We call the first 164 messages establishing an IKE_SA IKE_SA_INIT and IKE_AUTH exchanges 165 and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL 166 exchanges. In the common case, there is a single IKE_SA_INIT exchange 167 and a single IKE_AUTH exchange (a total of four messages) to 168 establish the IKE_SA and the first CHILD_SA. In exceptional cases, 169 there may be more than one of each of these exchanges. In all cases, 170 all IKE_SA_INIT exchanges MUST complete before any other exchange 171 type, then all IKE_AUTH exchanges MUST complete, and following that 172 any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur 173 in any order. In some scenarios, only a single CHILD_SA is needed 174 between the IPsec endpoints and therefore there would be no 175 additional exchanges. Subsequent exchanges MAY be used to establish 176 additional CHILD_SAs between the same authenticated pair of endpoints 177 and to perform housekeeping functions. 179 IKE message flow always consists of a request followed by a response. 180 It is the responsibility of the requester to ensure reliability. If 181 the response is not received within a timeout interval, the requester 182 MUST retransmit the request (or abandon the connection). 184 The first request/response of an IKE session negotiates security 185 parameters for the IKE_SA, sends nonces, and sends Diffie-Hellman 186 values. We call the initial exchange IKE_SA_INIT (request and 187 response). 189 The second request/response, which we'll call IKE_AUTH transmits 190 identities, proves knowledge of the secrets corresponding to the two 191 identities, and sets up an SA for the first (and often only) AH 192 and/or ESP CHILD_SA. 194 The types of subsequent exchanges are CREATE_CHILD_SA (which creates 195 a CHILD_SA), or and INFORMATIONAL (which deletes an SA, reports error 196 conditions, or does other housekeeping). Every request requires a 197 response. An INFORMATIONAL request with no payloads is commonly used 198 as a check for liveness. These subsequent exchanges cannot be used 199 until the initial exchanges have completed. 201 In the description that follows, we assume that no errors occur. 202 Modifications to the flow should errors occur are described in 203 section 2.21. 205 1.1 Usage Scenarios 207 IKE is expected to be used to negotiate ESP and/or AH SAs in a number 208 of different scenarios, each with its own special requirements. 210 1.1.1 Gateway to Gateway Tunnel 212 +-+-+-+-+-+ +-+-+-+-+-+ 213 ! ! IPsec ! ! 214 Protected !Tunnel ! Tunnel !Tunnel ! Protected 215 Subnet <-->!Endpoint !<---------->!Endpoint !<--> Subnet 216 ! ! ! ! 217 +-+-+-+-+-+ +-+-+-+-+-+ 219 Figure 1: Firewall to Firewall Tunnel 221 In this scenario, neither endpoint of the IP connection implements 222 IPsec, but network nodes between them protect traffic for part of the 223 way. Protection is transparent to the endpoints, and depends on 224 ordinary routing sending packets through the tunnel endpoints for 225 processing. Each endpoint would announce the set of addresses 226 "behind" it, and packets would be sent in Tunnel Mode where the inner 227 IP header would contain the IP addresses of the actual endpoints. 229 1.1.2 Endpoint to Endpoint Transport 231 +-+-+-+-+-+ +-+-+-+-+-+ 232 ! ! IPsec ! ! 233 !Protected! Tunnel !Protected! 234 !Endpoint !<---------------------------------------->!Endpoint ! 235 ! ! ! ! 236 +-+-+-+-+-+ +-+-+-+-+-+ 238 Figure 2: Endpoint to Endpoint 240 In this scenario, both endpoints of the IP connection implement 241 IPsec. These endpoints may implement application layer access 242 controls based on the authenticated identities of the participants. 243 Transport mode will commonly be used with no inner IP header. If 244 there is an inner IP header, the inner addresses will be the same as 245 the outer addresses. A single pair of addresses will be negotiated 246 for packets to be sent over this SA. 248 It is possible in this scenario that one or both of the protected 249 endpoints will be behind a network address translation (NAT) node, in 250 which case the tunnelled packets will have to be UDP encapsulated so 251 that port numbers in the UDP headers can be used to identify 252 individual endpoints "behind" the NAT. 254 1.1.3 Endpoint to Gateway Transport 256 +-+-+-+-+-+ +-+-+-+-+-+ 257 ! ! IPsec ! ! Protected 258 !Protected! Tunnel !Tunnel ! Subnet 259 !Endpoint !<------------------------>!Endpoint !<--- and/or 260 ! ! ! ! Internet 261 +-+-+-+-+-+ +-+-+-+-+-+ 263 Figure 3: Endpoint to Gateway 265 In this scenario, a protected endpoint (typically a portable roaming 266 computer) connects back to its corporate network through an IPsec 267 protected tunnel. It might use this tunnel only to access information 268 on the corporate network or it might tunnel all of its traffic back 269 through the corporate network in order to take advantage of 270 protection provided by a corporate firewall against Internet based 271 attacks. In either case, the protected endpoint will want an IP 272 address associated with the gateway so that packets returned to it 273 will go to the gateway and be tunnelled back. This IP address may be 274 static or may be dynamically allocated by the gateway. In support of 275 the latter case, IKEv2 includes a mechanism for the initiator to 276 request an IP address owned by the gateway for use for the duration 277 of its SA. 279 In this scenario, packets will use tunnel mode. On each packet from 280 the protected endpoint, the outer IP header will contain the source 281 IP address associated with its current location (i.e. the address 282 that will get traffic routed to the endpoint directly) while the 283 inner IP header will contain the source IP address assigned by the 284 gateway (i.e. the address that will get traffic routed to the gateway 285 for forwarding to the endpoint). The outer destination address will 286 always be that of the gateway, while the inner destination address 287 will be the ultimate destination for the packet. 289 In this scenario, it is possible that the protected endpoint will be 290 behind a NAT. In that case, the IP address as seen by the gateway 291 will not be the same as the IP address sent by the protected 292 endpoint, and packets will have to be UDP encapsulated in order to be 293 routed properly. 295 1.1.4 Other Scenarios 297 Other scenarios are possible, as are nested combinations of the 298 above. One noteable example combines aspects of 1.1.1 and 1.1.3. A 299 subnet may make all external accesses through a remote gateway using 300 an IPsec tunnel, where the addresses on the subnet are routed to the 301 gateway by the rest of the Internet. An example would be someones 302 home network being virtually on the Internet with static IP addresses 303 even though connectivity is provided by an ISP that assigns a single 304 dynamically assigned IP address (where the static IP addresses and an 305 IPsec relay is provided by a third party located elsewhere). 307 1.2 The Initial Exchanges 309 Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH 310 exchanges (known in IKEv1 as Phase 1). These initial exchanges 311 normally consist of four messages, though in some scenarios that 312 number can grow. All communications using IKE consist of 313 request/response pairs. We'll describe the base exchange first, 314 followed by variations. The first pair of messages (IKE_SA_INIT) 315 negotiate cryptographic algorithms, exchange nonces, and do a Diffie- 316 Hellman exchange. 318 The second pair of messages (IKE_AUTH) authenticate the previous 319 messages, exchange identities and certificates, and establish the 320 first CHILD_SA. Parts of these messages are encrypted and integrity 321 protected with keys established through the IKE_SA_INIT exchange, so 322 the identities are hidden from eavesdroppers and all fields in all 323 the messages are authenticated. 325 In the following description, the payloads contained in the message 326 are indicated by names such as SA. The details of the contents of 327 each payload are described later. Payloads which may optionally 328 appear will be shown in brackets, such as [CERTREQ], would indicate 329 that optionally a certificate request payload can be included. 331 The initial exchanges are as follows: 333 Initiator Responder 334 ----------- ----------- 335 HDR, SAi1, KEi, Ni --> 337 HDR contains the SPIs, version numbers, and flags of various sorts. 338 The SAi1 payload states the cryptographic algorithms the Initiator 339 supports for the IKE_SA. The KE payload sends the Initiator's 340 Diffie-Hellman value. Ni is the Initiator's nonce. 342 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 344 The Responder chooses a cryptographic suite from the Initiator's 345 offered choices and expresses that choice in the SAr1 payload, 346 completes the Diffie-Hellman exchange with the KEr payload, and sends 347 its nonce in the Nr payload. 349 At this point in the negotiation each party can generate SKEYSEED, 350 from which all keys are derived for that IKE_SA. All but the headers 351 of all the messages that follow are encrypted and integrity 352 protected. The keys used for the encryption and integrity protection 353 are derived from SKEYSEED and are known as SK_e (encryption) and SK_a 354 (authentication, a.k.a. integrity protection). A separate SK_e and 355 SK_a is computed for each direction. In addition to the keys SK_e 356 and SK_a derived from the DH value for protection of the IKE_SA, 357 another quantity SK_d is derived and used for derivation of further 358 keying material for CHILD_SAs. The notation SK { ... } indicates 359 that these payloads are encrypted and integrity protected using that 360 direction's SK_e and SK_a. 362 HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] 363 AUTH, SAi2, TSi, TSr} --> 365 The Initiator asserts her identity with the IDi payload, proves 366 knowledge of the secret corresponding to IDi and integrity protects 367 the contents of the first two messages using the AUTH payload (see 368 section 2.15). She might also send her certificate(s) in CERT 369 payload(s) and a list of her trust anchors in CERTREQ payload(s). If 370 any CERT payloads are included, the first certificate provided must 371 contain the public key used to verify the AUTH field. The optional 372 payload IDr enables Alice to specify which of Bob's identities she 373 wants to talk to. This is useful when Bob is hosting multiple 374 identities at the same IP address. She begins negotiation of a 375 CHILD_SA using the SAi2 payload. The final fields (starting with 376 SAi2) are described in the description of the CREATE_CHILD_SA 377 exchange. 379 <-- HDR, SK {IDr, [CERT,] AUTH, 380 SAr2, TSi, TSr} 382 The Responder asserts his identity with the IDr payload, optionally 383 sends one or more certificates (again with the certificate containing 384 the public key used to verify AUTH listed first), authenticates his 385 identity with the AUTH payload, and completes negotiation of a 386 CHILD_SA with the additional fields described below in the 387 CREATE_CHILD_SA exchange. 389 The recipients of messages 3 and 4 MUST verify that all signatures 390 and MACs are computed correctly and that the names in the ID payloads 391 correspond to the keys used to generate the AUTH payload. 393 1.3 The CREATE_CHILD_SA Exchange 395 This exchange consists of a single request/response pair, and was 396 referred to as a phase 2 exchange in IKEv1. It MAY be initiated by 397 either end of the IKE_SA after the initial exchanges are completed. 399 All messages following the initial exchange are cryptographically 400 protected using the cryptographic algorithms and keys negotiated in 401 the first two messages of the IKE exchange using a syntax described 402 in section 3.14. 404 Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this 405 section the term Initiator refers to the endpoint initiating this 406 exchange. 408 A CHILD_SA is created by sending a CREATE_CHILD_SA request. The 409 CREATE_CHILD_SA request MAY optionally contain a KE payload for an 410 additional Diffie-Hellman exchange to enable stronger guarantees of 411 forward secrecy for the CHILD_SA. The keying material for the 412 CHILD_SA is a function of SK_d established during the establishment 413 of the IKE_SA, the nonces exchanged during the CREATE_CHILD_SA 414 exchange, and the Diffie-Hellman value (if KE payloads are included 415 in the CREATE_CHILD_SA exchange). 417 In the CHILD_SA created as part of the initial exchange, a second KE 418 payload and nonce MUST NOT be sent. The nonces from the initial 419 exchange are used in computing the keys for the CHILD_SA. 421 The CREATE_CHILD_SA request contains: 423 Initiator Responder 424 ----------- ----------- 425 HDR, SK {SA, Ni, [KEi], 426 [TSi, TSr]} --> 428 The Initiator sends SA offer(s) in the SA payload, a nonce in the Ni 429 payload, optionally a Diffie-Hellman value in the KEi payload, and 430 the proposed traffic selectors in the TSi and TSr payloads. If the SA 431 offers include different Diffie-Hellman groups, KEi must be an 432 element of the group the Initiator expects the responder to accept. 434 If she guesses wrong, the CREATE_CHILD_SA exchange will fail and she 435 will have to retry with a different KEi. 437 The message following the header is encrypted and the message 438 including the header is integrity protected using the cryptographic 439 algorithms negotiated for the IKE_SA. 441 The CREATE_CHILD_SA response contains: 443 <-- HDR, SK {SA, Nr, [KEr], 444 [TSi, TSr]} 446 The Responder replies (using the same Message ID to respond) with the 447 accepted offer in an SA payload, and a Diffie-Hellman value in the 448 KEr payload if KEi was included in the request and the selected 449 cryptographic suite includes that group. If the responder chooses a 450 cryptographic suite with a different group, it MUST reject the 451 request and have the initiator make another one. 453 The traffic selectors for traffic to be sent on that SA are specified 454 in the TS payloads, which may be a subset of what the Initiator of 455 the CHILD_SA proposed. Traffic selectors are omitted if this 456 CREATE_CHILD_SA request is being used to change the key of the 457 IKE_SA. 459 1.4 The INFORMATIONAL Exchange 461 At various points during the operation of an IKE_SA, peers may desire 462 to convey control messages to each other regarding errors or 463 notifications of certain events. To accomplish this IKE defines an 464 INFORMATIONAL exchange. INFORMATIONAL exchanges MAY ONLY occur after 465 the initial exchanges and are cryptographically protected with the 466 negotiated keys. 468 Control messages that pertain to an IKE_SA MUST be sent under that 469 IKE_SA. Control messages that pertain to CHILD_SAs MUST be sent under 470 the protection of the IKE_SA which generated them (or its successor 471 if the IKE_SA was replaced for the purpose of rekeying). 473 Messages in an INFORMATIONAL Exchange contain zero or more 474 Notification, Delete, and Configuration payloads. The Recipient of an 475 INFORMATIONAL Exchange request MUST send some response (else the 476 Sender will assume the message was lost in the network and will 477 retransmit it). That response MAY be a message with no payloads. The 478 request message in an INFORMATIONAL Exchange MAY also contain no 479 payloads. This is the expected way an endpoint can ask the other 480 endpoint to verify that it is alive. 482 ESP and AH SAs always exist in pairs, with one SA in each direction. 483 When an SA is closed, both members of the pair MUST be closed. When 484 SAs are nested, as when data (and IP headers if in tunnel mode) are 485 encapsulated first with IPcomp, then with ESP, and finally with AH 486 between the same pair of endpoints, all of the SAs MUST be deleted 487 together. Each endpoint MUST close the SAs it receives on and allow 488 the other endpoint to close the other SA in each pair. To delete an 489 SA, an INFORMATIONAL Exchange with one or more delete payloads is 490 sent listing the SPIs (as they would be expected in the headers of 491 inbound packets) of the SAs to be deleted. The recipient MUST close 492 the designated SAs. Normally, the reply in the INFORMATIONAL Exchange 493 will contain delete payloads for the paired SAs going in the other 494 direction. There is one exception. If by chance both ends of a set 495 of SAs independently decide to close them, each may send a delete 496 payload and the two requests may cross in the network. If a node 497 receives a delete request for SAs for which it has already issued a 498 delete request, it MUST delete the outgoing SAs while processing the 499 request and the incoming SAs while processing the response. In that 500 case, the responses MUST NOT include delete payloads for the deleted 501 SAs, since that would result in duplicate deletion and could in 502 theory delete the wrong SA. 504 A node SHOULD regard half closed connections as anomalous and audit 505 their existence should they persist. Note that this specification 506 nowhere specifies time periods, so it is up to individual endpoints 507 to decide how long to wait. A node MAY refuse to accept incoming data 508 on half closed connections but MUST NOT unilaterally close them and 509 reuse the SPIs. If connection state becomes sufficiently messed up, a 510 node MAY close the IKE_SA which will implicitly close all SAs 511 negotiated under it. It can then rebuild the SAs it needs on a clean 512 base under a new IKE_SA. 514 The INFORMATIONAL Exchange is defined as: 516 Initiator Responder 517 ----------- ----------- 518 HDR, SK {[N,] [D,] [CP,] ...} --> 519 <-- HDR, SK {[N,] [D,] [CP], ...} 521 The processing of an INFORMATIONAL Exchange is determined by its 522 component payloads. 524 1.5 Informational Messages outside of an IKE_SA 526 If a packet arrives with an unrecognised SPI, it could be because the 527 receiving node has recently crashed and lost state or because of some 528 other system malfunction or attack. If the receiving node has an 529 active IKE_SA to the IP address from whence the packet came, it MAY 530 send a notification of the wayward packet over that IKE_SA. If it 531 does not, it MAY send an Informational message without cryptographic 532 protection to the source IP address and port to alert it to a 533 possible problem. 535 2 IKE Protocol Details and Variations 537 IKE normally listens and sends on UDP port 500, though IKE messages 538 may also be received on UDP port 4500 with a slightly different 539 format (see section 2.23). Since UDP is a datagram (unreliable) 540 protocol, IKE includes in its definition recovery from transmission 541 errors, including packet loss, packet replay, and packet forgery. IKE 542 is designed to function so long as (1) at least one of a series of 543 retransmitted packets reaches its destination before timing out; and 544 (2) the channel is not so full of forged and replayed packets so as 545 to exhaust the network or CPU capacities of either endpoint. Even in 546 the absence of those minimum performance requirements, IKE is 547 designed to fail cleanly (as though the network were broken). 549 2.1 Use of Retransmission Timers 551 All messages in IKE exist in pairs: a request and a response. The 552 setup of an IKE_SA normally consists of two request/response pairs. 553 Once the IKE_SA is set up, either end of the security association may 554 initiate requests at any time, and there can be many requests and 555 responses "in flight" at any given moment. But each message is 556 labelled as either a request or a response and for each 557 request/response pair one end of the security association is the 558 Initiator and the other is the Responder. 560 For every pair of messages, the Initiator is responsible for 561 retransmission in the event of a timeout. The Responder MUST never 562 retransmit a response unless it receives a retransmission of the 563 request. In that event, the Responder MUST ignore the retransmitted 564 request except insofar as it triggers a retransmission of the 565 response. The Initiator MUST remember each request until it receives 566 the corresponding response. The Responder MUST remember each response 567 until it receives a request whose sequence number is larger than the 568 sequence number in the response plus his window size (see section 569 2.3). 571 IKE is a reliable protocol, in the sense that the Initiator MUST 572 retransmit a request until either it receives a corresponding reply 573 OR it deems the IKE security association to have failed and it 574 discards all state associated with the IKE_SA and any CHILD_SAs 575 negotiated using that IKE_SA. 577 2.2 Use of Sequence Numbers for Message ID 579 Every IKE message contains a Message ID as part of its fixed header. 580 This Message ID is used to match up requests and responses, and to 581 identify retransmissions of messages. 583 The Message ID is a 32 bit quantity, which is zero for the first IKE 584 request in each direction. The IKE_SA initial setup messages will 585 always be numbered 0 and 1. Each endpoint in the IKE Security 586 Association maintains two "current" Message IDs: the next one to be 587 used for a request it initiates and the next one it expects to see in 588 a request from the other end. These counters increment as requests 589 are generated and received. Responses always contain the same message 590 ID as the corresponding request. That means that after the initial 591 exchange, each integer n may appear as the message ID in four 592 distinct messages: The nth request from the original IKE Initiator, 593 the corresponding response, the nth request from the original IKE 594 Responder, and the corresponding response. If the two ends make very 595 different numbers of requests, the Message IDs in the two directions 596 can be very different. There is no ambiguity in the messages, 597 however, because each the (I)nitiator and (R)esponse bits in the 598 message header specify which of the four messages a particular one 599 is. 601 Note that Message IDs are cryptographically protected and provide 602 protection against message replays. In the unlikely event that 603 Message IDs grow too large to fit in 32 bits, the IKE SA MUST be 604 closed. Rekeying an IKE SA resets the sequence numbers. 606 2.3 Window Size for overlapping requests 608 In order to maximize IKE throughput, an IKE endpoint MAY issue 609 multiple requests before getting a response to any of them if the 610 other endpoint has indicated its ability to handle such requests. For 611 simplicity, an IKE implementation MAY choose to process requests 612 strictly in order and/or wait for a response to one request before 613 issuing another. Certain rules must be followed to assure 614 interoperability between implementations using different strategies. 616 After an IKE_SA is set up, either end can initiate one or more 617 requests. These requests may pass one another over the network. An 618 IKE endpoint MUST be prepared to accept and process a request while 619 it has a request outstanding in order to avoid a deadlock in this 620 situation. An IKE endpoint SHOULD be prepared to accept and process 621 multiple requests while it has a request outstanding. 623 An IKE endpoint MUST wait for a response to each of its messages 624 before sending a subsequent message unless it has received a 625 SET_WINDOW_SIZE Notify message from its peer informing it that the 626 peer is prepared to maintain state for multiple outstanding messages 627 in order to allow greater throughput. 629 An IKE endpoint MUST NOT exceed the peer's stated window size for 630 transmitted IKE requests. In other words, if Bob stated his window 631 size is N, then when Alice needs to make a request X, she MUST wait 632 until she has received responses to all requests up through request 633 X-N. An IKE endpoint MUST keep a copy of (or be able to regenerate 634 exactly) each request it has sent until it receives the corresponding 635 response. An IKE endpoint MUST keep a copy of (or be able to 636 regenerate exactly) the number of previous responses equal to its 637 declared window size in case its response was lost and the Initiator 638 requests its retransmission by retransmitting the request. 640 An IKE endpoint supporting a window size greater than one SHOULD be 641 capable of processing incoming requests out of order to maximize 642 performance in the event of network failures or packet reordering. 644 2.4 State Synchronization and Connection Timeouts 646 An IKE endpoint is allowed to forget all of its state associated with 647 an IKE_SA and the collection of corresponding CHILD_SAs at any time. 648 This is the anticipated behavior in the event of an endpoint crash 649 and restart. It is important when an endpoint either fails or 650 reinitializes its state that the other endpoint detect those 651 conditions and not continue to waste network bandwidth by sending 652 packets over discarded SAs and having them fall into a black hole. 654 Since IKE is designed to operate in spite of Denial of Service (DoS) 655 attacks from the network, an endpoint MUST NOT conclude that the 656 other endpoint has failed based on any routing information (e.g. ICMP 657 messages) or IKE messages that arrive without cryptographic 658 protection (e.g., notify messages complaining about unknown SPIs). An 659 endpoint MUST conclude that the other endpoint has failed only when 660 repeated attempts to contact it have gone unanswered for a timeout 661 period or when a cryptographically protected INITIAL_CONTACT 662 notification is received on a different IKE_SA to the same 663 authenticated identity. An endpoint SHOULD suspect that the other 664 endpoint has failed based on routing information and initiate a 665 request to see whether the other endpoint is alive. To check whether 666 the other side is alive, IKE specifies an empty INFORMATIONAL message 667 that (like all IKE requests) requires an acknowledgment. If a 668 cryptographically protected message has been received from the other 669 side recently, unprotected notifications MAY be ignored. 670 Implementations MUST limit the rate at which they take actions based 671 on unprotected messages. 673 Numbers of retries and lengths of timeouts are not covered in this 674 specification because they do not affect interoperability. It is 675 suggested that messages be retransmitted at least a dozen times over 676 a period of at least several minutes before giving up on an SA, but 677 different environments may require different rules. If there has only 678 been outgoing traffic on all of the SAs associated with an IKE_SA, it 679 is essential to confirm liveness of the other endpoint to avoid black 680 holes. If no cryptographically protected messages have been received 681 on an IKE_SA or any of its CHILD_SAs recently, a liveness check MUST 682 be performed. Receipt of a fresh cryptographically protected message 683 on an IKE_SA or any of its CHILD_SAs assures liveness of the IKE_SA 684 and all of its CHILD_SAs. Note that this places requirements on the 685 failure modes of an IKE endpoint. An implementation MUST NOT continue 686 sending on any SA if some failure prevents it from receiving on all 687 of the associated SAs. If CHILD_SAs can fail independently from one 688 another without the associated IKE_SA being able to send a delete 689 message, then they MUST be negotiated by separate IKE_SAs. 691 There is a Denial of Service attack on the Initiator of an IKE_SA 692 that can be avoided if the Initiator takes the proper care. Since the 693 first two messages of an SA setup are not cryptographically 694 protected, an attacker could respond to the Initiator's message 695 before the genuine Responder and poison the connection setup attempt. 696 To prevent this, the Initiator MAY be willing to accept multiple 697 responses to its first message, treat each as potentially legitimate, 698 respond to it, and then discard all the invalid half open connections 699 when she receives a valid cryptographically protected response to any 700 one of her requests. Once a cryptographically valid response is 701 received, all subsequent responses should be ignored whether or not 702 they are cryptographically valid. 704 Note that with these rules, there is no reason to negotiate and agree 705 upon an SA lifetime. If IKE presumes the partner is dead, based on 706 repeated lack of acknowledgment to an IKE message, then the IKE SA 707 and all CHILD_SAs set up through that IKE_SA are deleted. 709 An IKE endpoint may at any time delete inactive CHILD_SAs to recover 710 resources used to hold their state. If an IKE endpoint chooses to do 711 so, it MUST send Delete payloads to the other end notifying it of the 712 deletion. It MAY similarly time out the IKE_SA. Closing the IKE_SA 713 implicitly closes all associated CHILD_SAs. In this case, an IKE 714 endpoint SHOULD send a Delete payload indicating that it has closed 715 the IKE_SA. 717 2.5 Version Numbers and Forward Compatibility 719 This document describes version 2.0 of IKE, meaning the major version 720 number is 2 and the minor version number is zero. It is likely that 721 some implementations will want to support both version 1.0 and 722 version 2.0, and in the future, other versions. 724 The major version number should only be incremented if the packet 725 formats or required actions have changed so dramatically that an 726 older version node would not be able to interoperate with a newer 727 version node if it simply ignored the fields it did not understand 728 and took the actions specified in the older specification. The minor 729 version number indicates new capabilities, and MUST be ignored by a 730 node with a smaller minor version number, but used for informational 731 purposes by the node with the larger minor version number. For 732 example, it might indicate the ability to process a newly defined 733 notification message. The node with the larger minor version number 734 would simply note that its correspondent would not be able to 735 understand that message and therefore would not send it. 737 If an endpoint receives a message with a higher major version number, 738 it MUST drop the message and SHOULD send an unauthenticated 739 notification message containing the highest version number it 740 supports. If an endpoint supports major version n, and major version 741 m, it MUST support all versions between n and m. If it receives a 742 message with a major version that it supports, it MUST respond with 743 that version number. In order to prevent two nodes from being tricked 744 into corresponding with a lower major version number than the maximum 745 that they both support, IKE has a flag that indicates that the node 746 is capable of speaking a higher major version number. 748 Thus the major version number in the IKE header indicates the version 749 number of the message, not the highest version number that the 750 transmitter supports. If A is capable of speaking versions n, n+1, 751 and n+2, and B is capable of speaking versions n and n+1, then they 752 will negotiate speaking n+1, where A will set the flag indicating 753 ability to speak a higher version. If they mistakenly (perhaps 754 through an active attacker sending error messages) negotiate to 755 version n, then both will notice that the other side can support a 756 higher version number, and they MUST break the connection and 757 reconnect using version n+1. 759 Note that IKEv1 does not follow these rules, because there is no way 760 in v1 of noting that you are capable of speaking a higher version 761 number. So an active attacker can trick two v2-capable nodes into 762 speaking v1. When a v2-capable node negotiates down to v1, it SHOULD 763 note that fact in its logs. 765 Also for forward compatibility, all fields marked RESERVED MUST be 766 set to zero by a version 2.0 implementation and their content MUST be 767 ignored by a version 2.0 implementation ("Be conservative in what you 768 send and liberal in what you receive"). In this way, future versions 769 of the protocol can use those fields in a way that is guaranteed to 770 be ignored by implementations that do not understand them. 771 Similarly, payload types that are not defined are reserved for future 772 use and implementations of version 2.0 MUST skip over those payloads 773 and ignore their contents. 775 IKEv2 adds a "critical" flag to each payload header for further 776 flexibility for forward compatibility. If the critical flag is set 777 and the payload type is unrecognised, the message MUST be rejected 778 and the response to the IKE request containing that payload MUST 779 include a notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an 780 unsupported critical payload was included. If the critical flag is 781 not set and the payload type is unsupported, that payload MUST be 782 ignored. 784 While new payload types may be added in the future and may appear 785 interleaved with the fields defined in this specification, 786 implementations MUST send the payloads defined in this specification 787 in the order shown in section 3 and implementations SHOULD reject as 788 invalid a message with payloads in any other order. 790 2.6 Cookies 792 The term "cookies" originates with Karn and Simpson [RFC 2522] in 793 Photuris, an early proposal for key management with IPsec. It has 794 persisted because the IETF has never rejected a proposal involving 795 cookies. The ISAKMP fixed message header includes two eight octet 796 fields titled "cookies", and that syntax is used by both IKEv1 and 797 IKEv2 though in IKEv2 they are referred to as the IKE SPI and there 798 is a new separate field in a NOTIFY payload holding the cookie. The 799 initial two eight octet fields in the header are used as a connection 800 identifier at the beginning of IKE packets. Each endpoint chooses one 801 of the two SPIs and SHOULD choose them so as to be unique identifiers 802 of an IKE_SA. An SPI value of zero is special and indicates that the 803 remote SPI value is not yet known by the sender. 805 Unlike ESP and AH where only the recipient's SPI appears in the 806 header of a message, in IKE the sender's SPI is also sent in every 807 message. Since the SPI chosen by the original initiator of the IKE_SA 808 is always sent first, an endpoint with multiple IKE_SAs open that 809 wants to find the appropriate IKE_SA using the SPI it assigned must 810 look at the I(nitiator) Flag bit in the header to determine whether 811 it assigned the first or the second eight octets. 813 In the first message of an initial IKE exchange, the initiator will 814 not know the responder's SPI value and will therefore set that field 815 to zero. 817 An expected attack against IKE is state and CPU exhaustion, where the 818 target is flooded with session initiation requests from forged IP 819 addresses. This attack can be made less effective if an 820 implementation of a responder uses minimal CPU and commits no state 821 to an SA until it knows the initiator can receive packets at the 822 address from which he claims to be sending them. To accomplish this, 823 a responder SHOULD - when it detects a large number of half-open 824 IKE_SAs - reject initial IKE messages unless they contain a notify 825 payload of type COOKIE. It SHOULD instead send an unprotected IKE 826 message as a response and include COOKIE notify payload with the 827 cookie data to be returned. Initiators who receive such responses 828 MUST retry the IKE_SA_INIT with a NOTIFY payload of type COOKIE 829 containing the responder supplied cookie data as the first payload. 830 The initial exchange will then be as follows: 832 Initiator Responder 833 ----------- ----------- 834 HDR(A,0), SAi1, KEi, Ni --> 836 <-- HDR(A,0), N(COOKIE) 838 HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> 840 <-- HDR(A,B), SAr1, KEr, Nr, [CERTREQ] 842 HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,] 843 AUTH, SAi2, TSi, TSr} --> 845 <-- HDR(A,B), SK {IDr, [CERT,] AUTH, 846 SAr2, TSi, TSr} 848 The first two messages do not affect any initiator or responder state 849 except for communicating the cookie. In particular, the message 850 sequence numbers in the first four messages will all be zero and the 851 message sequence numbers in the last two messages will be one. 853 An IKE implementation SHOULD implement its responder cookie 854 generation in such a way as to not require any saved state to 855 recognise its valid cookie when the second IKE_SA_INIT message 856 arrives. The exact algorithms and syntax they use to generate 857 cookies does not affect interoperability and hence is not specified 858 here. The following is an example of how an endpoint could use 859 cookies to implement limited DOS protection. 861 A good way to do this is to set the responder cookie to be: 863 Cookie = | Hash(Ni | IPi | SPIi | ) 865 where is a randomly generated secret known only to the 866 responder and periodically changed. should be 867 changed whenever is regenerated. The cookie can be 868 recomputed when the IKE_SA_INIT arrives the second time and compared 869 to the cookie in the received message. If it matches, the responder 870 knows that SPIr was generated since the last change to and 871 that IPi must be the same as the source address it saw the first 872 time. Incorporating SPIi into the calculation assures that if 873 multiple IKE_SAs are being set up in parallel they will all get 874 different cookies (assuming the initiator chooses unique SPIi's). 875 Incorporating Ni into the hash assures that an attacker who sees only 876 message 2 can't successfully forge a message 3. 878 If a new value for is chosen while there are connections in 879 the process of being initialized, an IKE_SA_INIT might be returned 880 with other than the current . The responder in 881 that case MAY reject the message by sending another response with a 882 new cookie or it MAY keep the old value of around for a 883 short time and accept cookies computed from either one. The 884 responder SHOULD NOT accept cookies indefinitely after is 885 changed, since that would defeat part of the denial of service 886 protection. The responder SHOULD change the value of 887 frequently, especially if under attack. 889 2.7 Cryptographic Algorithm Negotiation 891 The payload type known as "SA" indicates a proposal for a set of 892 choices of protocols (IKE, ESP, and/or AH) for the SA as well as 893 cryptographic algorithms associated with each protocol. 895 An SA consists of one or more proposals. Each proposal includes one 896 or more protocols (usually one). Each protocol contains one or more 897 transforms - each specifying a cryptographic algorithm. Each 898 transform contains zero or more attributes (attributes are only 899 needed if the transform identifier does not completely specify the 900 cryptographic algorithm). 902 This hierarchical structure was designed to be able to efficiently 903 encode proposals for cryptographic suites when the number of 904 supported suites is large because multiple values are acceptable for 905 multiple transforms. The responder MUST choose a single suite, which 906 MAY be any subset of the SA proposal following the rules below: 908 Each proposal contains one or more protocols. If a proposal is 909 accepted, the SA response must contain the same protocols in the 910 same order as the proposal. At most one proposal MAY be accepted. 911 (Example: if a single proposal contains ESP and AH and that 912 proposal is accepted, both ESP and AH MUST be accepted. If ESP and 913 AH are included in separate proposals, only one of them MAY be 914 accepted). 916 Each protocol contains one or more transforms. Each transform 917 contains a transform type. The accepted crytographic suite MUST 918 contain exactly one transform of each type included in the 919 proposal. (Example: if an ESP proposal includes transforms 920 ENCR_3DES, ENCR_AES128, AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the 921 accepted suite MUST contain one of the ENCR_ transforms and one of 922 the AUTH_ transforms. Thus four combinations are acceptable). 924 Since Alice sends her Diffie-Hellman value in the IKE_SA_INIT, she 925 must guess at the Diffie-Hellman group that Bob will select from her 926 list of supported groups. If she guesses wrong, Bob will respond 927 with a NOTIFY payload of type INVALID_KE_PAYLOAD indicating the 928 selected group. In this case, Alice MUST retry the IKE_SA_INIT with 929 the corrected Diffie-Hellman group. Alice MUST again propose her full 930 set of acceptable cryptographic suites because the rejection message 931 was unauthenticated and otherwise an active attacker could trick 932 Alice and Bob into negotiating a weaker suite than a stronger one 933 that they both prefer. 935 2.8 Rekeying 937 IKE, ESP, and AH security associations use secret keys which SHOULD 938 only be used for a limited amount of time and to protect a limited 939 amount of data. This limits the lifetime of the entire security 940 association. When the lifetime of a security association expires the 941 security association MUST NOT be used. If there is demand, new 942 security associations MAY be established. Reestablishment of 943 security associations to take the place of ones which expire is 944 referred to as "rekeying". 946 To rekey a CHILD_SA, create a new, equivalent SA (see section 2.17 947 below), and when the new one is established, delete the old one. To 948 rekey an IKE_SA, establish a new equivalent IKE_SA (see section 2.18 949 below) with the peer to whom the old IKE_SA is shared using a 950 CREATE_CHILD_SA within the existing IKE_SA. An IKE_SA so created 951 inherits all of the original IKE_SA's CHILD_SAs. Use the new IKE_SA 952 for all control messages needed to maintain the CHILD_SAs created by 953 the old IKE_SA, and delete the old IKE_SA. The Delete payload to 954 delete itself MUST be the last request sent over an IKE_SA. 956 SAs SHOULD be rekeyed proactively, i.e., the new SA should be 957 established before the old one expires and becomes unusable. Enough 958 time should elapse between the time the new SA is established and the 959 old one becomes unusable so that traffic can be switched over to the 960 new SA. 962 A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes 963 were negotiated. In IKEv2, each end of the SA is responsible for 964 enforcing its own lifetime policy on the SA and rekeying the SA when 965 necessary. If the two ends have different lifetime policies, the end 966 with the shorter lifetime will end up always being the one to request 967 the rekeying. If an SA bundle has been inactive for a long time and 968 if an endpoint would not initiate the SA in the absense of traffic, 969 the endpoint MAY choose to close the SA instead of rekeying it when 970 its lifetime expires. It SHOULD do so if there has been no traffic 971 since the last time the SA was rekeyed. 973 If the two ends have the same lifetime policies, it is possible that 974 both will initiate a rekeying at the same time (which will result in 975 redundant SAs). To reduce the probability of this happening, the 976 timing of rekeying requests SHOULD be jittered (delayed by a random 977 amount of time after the need for rekeying is noticed). 979 This form of rekeying may temporarily result in multiple similar SAs 980 between the same pairs of nodes. When there are two SAs eligible to 981 receive packets, a node MUST accept incoming packets through either 982 SA. If redundant SAs are created though such a collision, the SA 983 created with the lowest of the four nonces used in the two exchanges 984 SHOULD be closed by the endpoint that created it. 986 The node that initiated the surviving rekeyed SA SHOULD delete the 987 replaced SA after the new one is established. 989 2.9 Traffic Selector Negotiation 991 When an IP packet is received by an RFC2401 compliant IPsec subsystem 992 and matches a "protect" selector in its SPD, the subsystem MUST 993 protect that packet with IPsec. When no SA exists yet it is the task 994 of IKE to create it. Maintenance of of a system's SPD is outside the 995 scope of IKE (see [PFKEY] for an example protocol), though some 996 implementations might update their SPD in connection with the running 997 of IKE (for an example scenario, see section 1.1.3). 999 Traffic Selector (TS) payloads allow endpoints to communicate some of 1000 the information from their SPD to their peers. TS payloads specify 1001 the selection criteria for packets that will be forwarded over the 1002 newly set up SA. This can serve as a consistency check in some 1003 scenarios to assure that the SPDs are consistent. In others, it 1004 guides the dynamic update of the SPD. 1006 Two TS payloads appear in each of the messages in the exchange that 1007 creates a CHILD_SA pair. Each TS payload contains one or more Traffic 1008 Selectors. Each Traffic Selector consists of an address range (IPv4 1009 or IPv6), a port range, and a protocol ID. In support of the scenario 1010 described in section 1.1.3, an initiator may request that the 1011 responder assign an IP address and tell the initiator what it is. 1013 IKEv2 allows the responder to choose a subset of the traffic proposed 1014 by the initiator. This could happen when the configuration of the 1015 two endpoints are being updated but only one end has received the new 1016 information. Since the two endpoints may be configured by different 1017 people, the incompatibility may persist for an extended period even 1018 in the absense of errors. It also allows for intentionally different 1019 configurations, as when one end is configured to tunnel all addresses 1020 and depends on the other end to have the up to date list. 1022 The first of the two TS payloads is known as TSi (Traffic Selector- 1023 initiator). The second is known as TSr (Traffic Selector-responder). 1024 TSi specifies the source address of traffic forwarded from (or the 1025 destination address of traffic forwarded to) the initiator of the 1026 CHILD_SA pair. TSr specifies the destination address of the traffic 1027 forwarded from (or the source address of the traffic forwarded to) 1028 the responder of the CHILD_SA pair. For example, if Alice initiates 1029 the creation of the CHILD_SA pair from Alice to Bob, and wishes to 1030 tunnel all traffic from subnet 10.2.16.* on Alice's side to subnet 1031 18.16.*.* on Bob's side, Alice would include a single traffic 1032 selector in each TS payload. TSi would specify the address range 1033 (10.2.16.0 - 10.2.16.255) and TSr would specify the address range 1034 (18.16.0.0 - 18.16.255.255). Assuming that proposal was acceptable to 1035 Bob, he would send identical TS payloads back. 1037 The Responder is allowed to narrow the choices by selecting a subset 1038 of the traffic, for instance by eliminating or narrowing the range of 1039 one or more members of the set of traffic selectors, provided the set 1040 does not become the NULL set. 1042 It is possible for the Responder's policy to contain multiple smaller 1043 ranges, all encompassed by the Initiator's traffic selector, and with 1044 the Responder's policy being that each of those ranges should be sent 1045 over a different SA. Continuing the example above, Bob might have a 1046 policy of being willing to tunnel those addresses to and from Alice, 1047 but might require that each address pair be on a separately 1048 negotiated CHILD_SA. If Alice generated her request in response to an 1049 incoming packet from 10.2.16.43 to 18.16.2.123, there would be no way 1050 for Bob to determine which pair of addresses should be included in 1051 this tunnel, and he would have to make his best guess or reject the 1052 request with a status of SINGLE_PAIR_REQUIRED. 1054 To enable Bob to choose the appropriate range in this case, if Alice 1055 has initiated the SA due to a data packet, Alice SHOULD include as 1056 the first traffic selector in each of TSi and TSr a very specific 1057 traffic selector including the addresses in the packet triggering the 1058 request. In the example, Alice would include in TSi two traffic 1059 selectors: the first containing the address range (10.2.16.43 - 1060 10.2.16.43) and the source port and protocol from the packet and the 1061 second containing (10.2.16.0 - 10.2.16.255) with all ports and 1062 protocols. She would similarly include two traffic selectors in TSr. 1064 If Bob's policy does not allow him to accept the entire set of 1065 traffic selectors in Alice's request, but does allow him to accept 1066 the first selector of TSi and TSr, then Bob MUST narrow the traffic 1067 selectors to a subset that includes Alice's first choices. In this 1068 example, Bob might respond with TSi being (10.2.16.43 - 10.2.16.43) 1069 with all ports and protocols. 1071 If Alice creates the CHILD_SA pair not in response to an arriving 1072 packet, but rather - say - upon startup, then there may be no 1073 specific addresses Alice prefers for the initial tunnel over any 1074 other. In that case, the first values in TSi and TSr MAY be ranges 1075 rather than specific values, and Bob chooses a subset of Alice's TSi 1076 and TSr that are acceptable to him. If more than one subset is 1077 acceptable but their union is not, Bob MUST accept some subset and 1078 MAY include a NOTIFY payload of type ADDITIONAL_TS_POSSIBLE to 1079 indicate that Alice might want to try again. This case will only 1080 occur when Alice and Bob are configured differently from one another. 1081 If Alice and Bob agree on the granularity of tunnels, she will never 1082 request a tunnel wider than Bob will accept. 1084 2.10 Nonces 1086 The IKE_SA_INIT messages each contain a nonce. These nonces are used 1087 as inputs to cryptographic functions. The CREATE_CHILD_SA request 1088 and the CREATE_CHILD_SA response also contain nonces. These nonces 1089 are used to add freshness to the key derivation technique used to 1090 obtain keys for CHILD_SAs. Nonces used in IKEv2 MUST therefore be 1091 randomly chosen and be at least 128 bits in size (or half the key 1092 size of the negotiated prf if greater). If the same random number 1093 source is used for both keys and nonces, care must be taken to ensure 1094 that the latter use does not compromise the former. 1096 2.11 Address and Port Agility 1098 IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and 1099 AH associations for the same IP addresses it runs over. The IP 1100 addresses and ports in the outer header are, however, not themselves 1101 cryptographically protected, and IKE is designed to work even through 1102 Network Address Translation (NAT) boxes. An implementation MUST 1103 accept incoming connection requests even if not received from UDP 1104 port 500 or 4500, and MUST respond to the address and port from which 1105 the request was received. IKE functions identically over IPv4 or 1106 IPv6. 1108 2.12 Reuse of Diffie-Hellman Exponentials 1110 IKE generates keying material using an ephemeral Diffie-Hellman 1111 exchange in order to gain the property of "perfect forward secrecy". 1112 This means that once a connection is closed and its corresponding 1113 keys are forgotten, even someone who has recorded all of the data 1114 from the connection and gets access to all of the long term keys of 1115 the two endpoints cannot reconstruct the keys used to protect the 1116 conversation. 1118 Achieving perfect forward secrecy requires that when a connection is 1119 closed, each endpoint must forget not only the keys used by the 1120 connection but any information that could be used to recompute those 1121 keys. In particular, it must forget the secrets used in the Diffie- 1122 Hellman calculation and any state that may persist in the state of a 1123 pseudo-random number generater that could be used to recompute the 1124 Diffie-Hellman secrets. 1126 Since the computing of Diffie-Hellman exponentials is computationally 1127 expensive, an endpoint may find it advantageous to reuse those 1128 exponentials for multiple connection setups. There are several 1129 reasonable strategies for doing this. An endpoint could choose a new 1130 exponential only periodically though this could result in less-than- 1131 perfect forward secrecy if some connection lasts for less than the 1132 lifetime of the exponential. Or it could keep track of which 1133 exponential was used for each connection and delete the information 1134 associated with the exponential only when some corresponding 1135 connection was closed. This would allow the exponential to be reused 1136 without losing perfect forward secrecy at the cost of maintaining 1137 more state. 1139 Decisions as to whether and when to reuse Diffie-Hellman exponentials 1140 is a private decision in the sense that it will not affect 1141 interoperability. An implementation that reuses exponentials MAY 1142 choose to remember the exponential used by the other endpoint on past 1143 exchanges and if one is reused to avoid the second half of the 1144 calculation. 1146 2.13 Generating Keying Material 1148 In the context of the IKE_SA, four cryptographic algorithms are 1149 negotiated: an encryption algorithm, an integrity protection 1150 algorithm, a Diffie-Hellman group, and a pseudo-random function 1151 (prf). The pseudo-random function is used for the construction of 1152 keying material for all of the cryptographic algorithms used in both 1153 the IKE_SA and the CHILD_SAs. 1155 We assume that each encryption algorithm and integrity protection 1156 algorithm uses a fixed size key, and that any randomly chosen value 1157 of that fixed size can serve as an appropriate key. For algorithms 1158 that accept a variable length key, a fixed key size MUST be specified 1159 as part of the cryptographic transform negotiated. For integrity 1160 protection functions based on HMAC, the fixed key size is the size of 1161 the output of the underlying hash function. When the prf function 1162 takes a variable length key, variable length data, and produces a 1163 fixed length output (e.g. when using HMAC), the formulas in this 1164 document apply. When the key for the prf function has fixed length, 1165 the data provided as a key is truncated or padded with zeros as 1166 necessary unless exceptional processing is explained following the 1167 formula. 1169 Keying material will always be derived as the output of the 1170 negotiated prf algorithm. Since the amount of keying material needed 1171 may be greater than the size of the output of the prf algorithm, we 1172 will use the prf iteratively. We will use the terminology prf+ to 1173 describe the function that outputs a pseudo-random stream based on 1174 the inputs to a prf as follows: (where | indicates concatenation) 1176 prf+ (K,S) = T1 | T2 | T3 | T4 | ... 1178 where: 1179 T1 = prf (K, S | 0x01) 1180 T2 = prf (K, T1 | S | 0x02) 1181 T3 = prf (K, T2 | S | 0x03) 1182 T4 = prf (K, T3 | S | 0x04) 1184 continuing as needed to compute all required keys. The keys are taken 1185 from the output string without regard to boundaries (e.g. if the 1186 required keys are a 256 bit AES key and a 160 bit HMAC key, and the 1187 prf function generates 160 bits, the AES key will come from T1 and 1188 the beginning of T2, while the HMAC key will come from the rest of T2 1189 and the beginning of T3). 1191 The constant concatenated to the end of each string feeding the prf 1192 is a single octet. prf+ in this document is not defined beyond 255 1193 times the size of the prf output. 1195 2.14 Generating Keying Material for the IKE_SA 1197 The shared keys are computed as follows. A quantity called SKEYSEED 1198 is calculated from the nonces exchanged during the IKE_SA_INIT 1199 exchange and the Diffie-Hellman shared secret established during that 1200 exchange. SKEYSEED is used to calculate five other secrets: SK_d 1201 used for deriving new keys for the CHILD_SAs established with this 1202 IKE_SA; SK_ai and SK_ar used as a key to the integrity protection 1203 algorithm for authenticating the component messages of subsequent 1204 exchanges; and SK_ei and SK_er used for encrypting (and of course 1205 decrypting) all subsequent exchanges. SKEYSEED and its derivatives 1206 are computed as follows: 1208 SKEYSEED = prf(Ni | Nr, g^ir) 1210 {SK_d, SK_ai, SK_ar, SK_ei, SK_er} 1211 = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) 1213 (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, and SK_er 1214 are taken in order from the generated bits of the prf+). g^ir is the 1215 shared secret from the ephemeral Diffie-Hellman exchange. g^ir is 1216 represented as a string of octets in big endian order padded with 1217 zeros if necessary to make it the length of the modulus. Ni and Nr 1218 are the nonces, stripped of any headers. If the negotiated prf takes 1219 a fixed length key, Ni and Nr MUST each be truncated to one half of 1220 the fixed key length. 1222 The two directions of flow use different keys. The keys used to 1223 protect messages from the original initiator are SK_ai and SK_ei. The 1224 keys used to protect messages in the other direction are SK_ar and 1225 SK_er. Each algorithm takes a fixed number of bits of keying 1226 material, which is specified as part of the algorithm. For integrity 1227 algorithms based on HMAC, the key size is always equal to the length 1228 of the output of the underlying hash function. 1230 2.15 Authentication of the IKE_SA 1232 When not using extended authentication (see section 2.16), the peers 1233 are authenticated by having each sign (or MAC using a shared secret 1234 as the key) a block of data. For the responder, the octets to be 1235 signed start with the first octet of the first SPI in the header of 1236 the second message and end with the last octet of the last payload in 1237 the second message. Appended to this (for purposes of computing the 1238 signature) are the initiator's nonce Ni (just the value, not the 1239 payload containing it), and the value prf(SK_ar,IDr') where IDr' is 1240 the responder's ID payload excluding the fixed header. Note that 1241 neither the nonce Ni nor the value prf(SK_ar,IDr') are transmitted. 1242 Similarly, the initiator signs the first message, starting with the 1243 first octet of the first SPI in the header and ending with the last 1244 octet of the last payload. Appended to this (for purposes of 1245 computing the signature) are the responder's nonce Nr, and the value 1246 prf(SK_ai,IDi'). In the above calculation, IDi' and IDr' are the 1247 entire ID payloads excluding the fixed header. It is critical to the 1248 security of the exchange that each side sign the other side's nonce 1249 (see [SIGMA]). 1251 Note that all of the payloads are included under the signature, 1252 including any payload types not defined in this document. If the 1253 first message of the exchange is sent twice (the second time with a 1254 responder cookie and/or a different Diffie-Hellman group), it is the 1255 second version of the message that is signed. 1257 Optionally, messages 3 and 4 MAY include a certificate, or 1258 certificate chain providing evidence that the key used to compute a 1259 digital signature belongs to the name in the ID payload. The 1260 signature or MAC will be computed using algorithms dictated by the 1261 type of key used by the signer, an RSA-signed PKCS1-padded-hash for 1262 an RSA digital signature, a DSS-signed SHA1-hash for a DSA digital 1263 signature, or the negotiated prf function for a pre-shared key. 1264 There is no requirement that the Initiator and Responder sign with 1265 the same cryptographic algorithms. The choice of cryptographic 1266 algorithms depends on the type of key each has. This type is either 1267 indicated in the certificate supplied or, if the keys were exchanged 1268 out of band, the key types must have been similarly learned. In 1269 particular, the initiator may be using a shared key while the 1270 responder may have a public signature key and certificate. It will 1271 commonly be the case (but it is not required) that if a shared secret 1272 is used for authentication that the same key is used in both 1273 directions. Note that it is a common but typically insecure practice 1274 to have a shared key derived solely from a user chosen password 1275 without incorporating another source of randomness. This is 1276 typically insecure because user chosen passwords are unlikely to have 1277 sufficient unpredictability to resist dictionary attacks. The pre- 1278 shared key SHOULD contain as much unpredictability as the strongest 1279 key being negotiated. In the case of a pre-shared key, the AUTH 1280 value is computed as: 1282 AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), ) 1285 where the string "Key Pad for IKEv2" is ASCII encoded and not null 1286 terminated. The shared secret can be variable length. The pad string 1287 is added so that if the shared secret is derived from a password, the 1288 IKE implementation need not store the password in cleartext, but 1289 rather can store a one way transformation of it that could not be 1290 used as a password equivalent for protocols other than IKEv2. As 1291 noted above, deriving the shared secret from a password is not 1292 secure. This construction is used because it is anticipated that 1293 people will do it anyway. The management interface by which the 1294 Shared Secret is provided MUST accept ASCII strings of at least 64 1295 octets and MUST NOT add a null terminator before using them as shared 1296 secrets. The management interface MAY accept other forms, like hex 1297 encoding. If the negotiated prf takes a fixed size key, the shared 1298 secret MUST be of that fixed size. 1300 2.16 Extended Authentication Protocol Methods 1302 In addition to authentication using public key signatures and shared 1303 secrets, IKE supports authentication using methods defined in RFC 1304 2284 [EAP]. Typically, these methods are asymmetric (designed for a 1305 user authenticating to a server), and they may not be mutual. For 1306 this reason, these protocols are typically used to authenticate the 1307 initiator to the responder and are used in addition to a public key 1308 signature based authentication of the responder to the initator. 1309 These methods are also referred to as "Legacy Authentication" 1310 mechanisms. 1312 While this memo references [EAP] with the intent that new methods can 1313 be added in the future without updating this specification, the 1314 protocols expected to be used most commonly are fully documented here 1315 and in section 3.16. [EAP] defines an authentication protocol 1316 requiring a variable number of messages. Extended Authentication is 1317 implemented in IKE as additional IKE_AUTH exchanges that MUST be 1318 completed in order to initialize the IKE_SA. 1320 An initiator indicates a desire to use extended authentication by 1321 leaving out the AUTH payload from message 3. By including an IDi 1322 payload but not an AUTH payload, the initiator has declared an 1323 identity but has not proven it. If the responder is willing to use an 1324 extended authentication method, it will place an EAP payload in 1325 message 4 and defer sending SAr2, TSi, and TSr until initiator 1326 authentication is complete in a subsequent IKE_AUTH exchange. In the 1327 case of a minimal extended authentication, the initial SA 1328 establishment will appear as follows: 1330 Initiator Responder 1331 ----------- ----------- 1332 HDR, SAi1, KEi, Ni --> 1334 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 1336 HDR, SK {IDi, [CERTREQ,] [IDr,] 1337 SAi2, TSi, TSr} --> 1339 <-- HDR, SK {IDr, [CERT,] AUTH, 1340 EAP } 1342 HDR, SK {EAP, [AUTH] } --> 1343 <-- HDR, SK {EAP, [AUTH], 1344 SAr2, TSi, TSr } 1346 For EAP methods that create a shared key as a side effect of 1347 authentication, that shared key MUST be used by both the Initiator 1348 and Responder to generate an AUTH payload using the syntax for shared 1349 secrets specified in section 2.15. This shared key MUST NOT be used 1350 for any other purpose. 1352 The Initiator of an IKE_SA using EAP SHOULD be capable of extending 1353 the initial protocol exchange to at least ten IKE_AUTH exchanges in 1354 the event the Responder sends notification messages and/or retries 1355 the authentication prompt. The protocol terminates when the Responder 1356 sends the Initiator an EAP payload containing either a success or 1357 failure type. 1359 2.17 Generating Keying Material for CHILD_SAs 1361 CHILD_SAs are created either by being piggybacked on the IKE_AUTH 1362 exchange, or in a CREATE_CHILD_SA exchange. Keying material for them 1363 is generated as follows: 1365 KEYMAT = prf+(SK_d, Ni | Nr) 1367 Where Ni and Nr are the Nonces from the IKE_SA_INIT exchange if this 1368 request is the first CHILD_SA created or the fresh Ni and Nr from the 1369 CREATE_CHILD_SA exchange if this is a subsequent creation. 1371 For CREATE_CHILD_SA exchanges with PFS the keying material is defined 1372 as: 1374 KEYMAT = prf+(SK_d, g^ir (ph2) | Ni | Nr ) 1376 where g^ir (ph2) is the shared secret from the ephemeral Diffie- 1377 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 1378 octet string in big endian order padded with zeros if necessary to 1379 make it the length of the modulus), 1381 A single CHILD_SA negotiation may result in multiple security 1382 associations. ESP and AH SAs exist in pairs (one in each direction), 1383 and four SAs could be created in a single CHILD_SA negotiation if a 1384 combination of ESP and AH is being negotiated. 1386 Keying material is taken from the expanded KEYMAT in the following 1387 order: 1389 All keys for SAs carrying data from the initiator to the responder 1390 are taken before SAs going in the reverse direction. 1392 If multiple protocols are negotiated, keying material is taken in 1393 the order in which the protocol headers will appear in the 1394 encapsulated packet. 1396 If a single protocol has both encryption and authentication keys, 1397 the encryption key is taken from the first octets of KEYMAT and 1398 the authentication key is taken from the next octets. 1400 Each cryptographic algorithm takes a fixed number of bits of keying 1401 material specified as part of the algorithm. 1403 2.18 Rekeying IKE_SAs using a CREATE_CHILD_SA exchange 1405 The CREATE_CHILD_SA exchange can be used to re-key an existing IKE_SA 1406 (see section 2.8). New Initiator and Responder SPIs are supplied in 1407 the SPI fields. The TS payloads are omitted when rekeying an IKE_SA. 1408 SKEYSEED for the new IKE_SA is computed using SK_d from the existing 1409 IKE_SA as follows: 1411 SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr) 1413 where g^ir (new) is the shared secret from the ephemeral Diffie- 1414 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 1415 octet string in big endian order padded with zeros if necessary to 1416 make it the length of the modulus) and Ni and Nr are the two nonces 1417 stripped of any headers. 1419 The new IKE_SA MUST reset its message counters to 0. 1421 SK_d, SK_ai, SK_ar, and SK_ei, and SK_er are computed from SKEYSEED 1422 as specified in section 2.14. 1424 2.19 Requesting an internal address on a remote network 1426 Most commonly in the endpoint to gateway scenario, an endpoint may 1427 need an IP address on the gateway's internal network, and may need to 1428 have that address dynamically assigned. A request for such a 1429 temporary address can be included in any request to create a CHILD_SA 1430 (including the implicit request in message 3) by including a CP 1431 payload. 1433 This function provides address allocation to an IRAC trying to tunnel 1434 into a network protected by an IRAS. Since the IKE_AUTH exchange 1435 creates an IKE_SA and a CHILD_SA, the IRAC MUST request the internal 1436 address (and optionally other information concerning the internal 1437 network) in the IKE_AUTH exchange. The IRAS may procure an internal 1438 address for the IRAC from any number of sources such as a DHCP/BOOTP 1439 server or its own address pool. 1441 Initiator Responder 1442 ----------------------------- --------------------------- 1443 HDR, SK {IDi, [CERT,] [CERTREQ,] 1444 [IDr,] AUTH, CP(CFG_REQUEST), 1445 SAi2, TSi, TSr} --> 1447 <-- HDR, SK {IDr, [CERT,] AUTH, 1448 CP(CFG_REPLY), SAr2, 1449 TSi, TSr} 1451 In all cases, the CP payload MUST be inserted immediately before the 1452 SA payload. In variations of the protocol where there are multiple 1453 IKE_AUTH exchanges, the CP payloads MUST be inserted in the messages 1454 containing the SA payloads. 1456 CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute 1457 (either IPv4 or IPv6) but MAY contain any number of additional 1458 attributes the initiator wants returned in the response. 1460 For example, message from Initiator to Responder: 1461 CP(CFG_REQUEST)= 1462 INTERNAL_ADDRESS(0.0.0.0) 1463 INTERNAL_NETMASK(0.0.0.0) 1464 INTERNAL_DNS(0.0.0.0) 1465 TSi = (0, 0-65536,0.0.0.0-255.255.255.255) 1466 TSr = (0, 0-65536,0.0.0.0-255.255.255.255) 1468 NOTE: Traffic Selectors are a (protocol, port range, address range) 1470 Message from Responder to Initiator: 1472 CP(CFG_REPLY)= 1473 INTERNAL_ADDRESS(192.168.219.202) 1474 INTERNAL_NETMASK(255.255.255.0) 1475 INTERNAL_SUBNET(192.168.219.0/255.255.255.0) 1476 TSi = (0, 0-65536,192.168.219.202-192.168.219.202) 1477 TSr = (0, 0-65536,192.168.219.0-192.168.219.255) 1479 All returned values will be implementation dependent. As can be seen 1480 in the above example, the IRAS MAY also send other attributes that 1481 were not included in CP(CFG_REQUEST) and MAY ignore the non- 1482 mandatory attributes that it does not support. 1484 The responder MUST not send a CFG_REPLY without having first received 1485 a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS 1486 to perform an unnecessary configuration lookup if the IRAC cannot 1487 process the REPLY. In the case where the IRAS's configuration 1488 requires that CP be used for a given identity IDi, but IRAC has 1489 failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and 1490 terminate the IKE exchange with a FAILED_CP_REQUIRED error. 1492 2.20 Requesting the Peer's Version 1494 An IKE peer wishing to inquire about the other peer's version 1495 information MUST use the method below. This is an example of a 1496 configuration request within an INFORMATIONAL Exchange, after the 1497 IKE_SA and first CHILD_SA have been created. 1499 An IKE implementation MAY decline to give out version information 1500 prior to authentication or even after authentication to prevent 1501 trolling in case some implementation is known to have some security 1502 weakness. In that case, it MUST either return an empty string or no 1503 CP payload if CP is not supported. 1505 Initiator Responder 1506 ----------------------------- -------------------------- 1507 HDR, SK{CP(CFG_REQUEST)} --> 1508 <-- HDR, SK{CP(CFG_REPLY)} 1510 CP(CFG_REQUEST)= 1511 APPLICATION_VERSION("") 1513 CP(CFG_REPLY) 1514 APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar Inc.") 1516 2.21 Error Handling 1518 There are many kinds of errors that can occur during IKE processing. 1519 If a request is received that is badly formatted or unacceptable for 1520 reasons of policy (e.g. no matching cryptographic algorithms), the 1521 response MUST contain a Notify payload indicating the error. If an 1522 error occurs outside the context of an IKE request (e.g. the node is 1523 getting ESP messages on a non-existent SPI), the node SHOULD initiate 1524 an INFORMATIONAL Exchange with a Notify payload describing the 1525 problem. 1527 Errors that occur before a cryptographically protected IKE_SA is 1528 established must be handled very carefully. There is a trade-off 1529 between wanting to be helpful in diagnosing a problem and responding 1530 to it and wanting to avoid being a dupe in a denial of service attack 1531 based on forged messages. 1533 If a node receives a message on UDP port 500 outside the context of 1534 an IKE_SA known to it (and not a request to start one), it may be the 1535 result of a recent crash of the node. If the message is marked as a 1536 response, the node MAY audit the suspicious event but MUST NOT 1537 respond. If the message is marked as a request, the node MAY audit 1538 the suspicious event and MAY send a response. If a response is sent, 1539 the response MUST be sent to the IP address and port from whence it 1540 came with the same IKE SPIs and the Message ID copied. The response 1541 MUST NOT be cryptographically protected and MUST contain a notify 1542 payload indicating INVALID_IKE_SPI. 1544 A node receiving such an unprotected NOTIFY payload MUST NOT respond 1545 and MUST NOT change the state of any existing SAs. The message might 1546 be a forgery or might be a response the genuine correspondent was 1547 tricked into sending. A node SHOULD treat such a message (and also a 1548 network message like ICMP destination unreachable) as a hint that 1549 there might be problems with SAs to that IP address and SHOULD 1550 initiate a liveness test for any such IKE_SA. An implementation 1551 SHOULD limit the frequency of such tests to avoid being tricked into 1552 participating in a denial of service attack. 1554 A node receiving a suspicious message from an IP address with which 1555 it has an IKE_SA MAY send an IKE notify payload in an IKE 1556 INFORMATIONAL exchange over that SA. The recipient MUST NOT change 1557 the state of any SA's as a result but SHOULD audit the event to aid 1558 in diagnosing malfunctions. A node MUST limit the rate at which it 1559 will send messages in response to unprotected messages. 1561 2.22 IPcomp 1563 Use of IP compression [IPCOMP] can be negotiated as part of the setup 1564 of a CHILD_SA. While IP compression involves an extra header in each 1565 packet and a CPI (compression parameter index), the virtual 1566 "compression association" has no life outside the ESP or AH SA that 1567 contains it. Compression associations disappear when the 1568 corresponding ESP or AH SA goes away, and is not explicitly mentioned 1569 in any DELETE payload. 1571 Negotiation of IP compression is separate from the negotiation of 1572 cryptographic parameters associated with a CHILD_SA. A node 1573 requesting a CHILD_SA MAY advertise its support for one or more 1574 compression algorithms though one or more NOTIFY payloads of type 1575 IPCOMP_SUPPORTED. The response MAY indicate acceptance of a single 1576 compression algorithm with a NOTIFY payload of type IPCOMP_SUPPORTED. 1577 These payloads MAY ONLY occur in the same messages that contain SA 1578 payloads. 1580 While there has been discussion of allowing multiple compression 1581 algorithms to be accepted and to have different compression 1582 algorithms available for the two directions of a CHILD_SA, 1583 implementations of this specification MUST NOT accept an IPcomp 1584 algorithm that was not proposed, MUST NOT accept more than one, and 1585 MUST NOT compress using an algorithm other than one proposed and 1586 accepted in the setup of the CHILD_SA. 1588 A side effect of separating the negotiation of IPcomp from 1589 cryptographic parameters is that it is not possible to propose 1590 multiple cryptographic suites and propose IP compression with some of 1591 them but not others. 1593 2.23 NAT Traversal 1595 NAT (Network Address Translation) gateways are a controversial 1596 subject. This section briefly describes what they are and how they 1597 are likely to act on IKE traffic. Many people believe that NATs are 1598 evil and that we should not design our protocols so as to make them 1599 work better. IKEv2 does specify some unintuitive processing rules in 1600 order that NATs are more likely to work. 1602 NATs exist primarily because of the shortage of IPv4 addresses, 1603 though there are other rationales. IP nodes that are "behind" a NAT 1604 have IP addresses that are not globally unique, but rather are 1605 assigned from some space that is unique within the network behind the 1606 NAT but which are likely to be reused by nodes behind other NATs. 1607 Generally, nodes behind NATs can communicate with other nodes behind 1608 the same NAT and with nodes with globally unique addresses, but not 1609 with nodes behind other NATs. There are exceptions to that rule. 1610 When those nodes make connections to nodes on the real Internet, the 1611 NAT gateway "translates" the IP source address to an address that 1612 will be routed back to the gateway. Messages to the gateway from the 1613 Internet have their destination addresses "translated" to the 1614 internal address that will route the packet to the correct endnode. 1616 NATs are designed to be "transparent" to endnodes. Neither software 1617 on the node behind the NAT nor the node on the Internet require 1618 modification to communicate through the NAT. Achieving this 1619 transparency is more difficult with some protocols than with others. 1620 Protocols that include IP addresses of the endpoints within the 1621 payloads of the packet will fail unless the NAT gateway understands 1622 the protocol and modifies the internal references as well as those in 1623 the headers. Such knowledge is inherently unreliable, is a network 1624 layer violation, and often results in subtle problems. 1626 Opening an IPsec connection through a NAT introduces special 1627 problems. If the connection runs in transport mode, changing the IP 1628 addresses on packets will cause the checksums to fail and the NAT 1629 cannot correct the checksums because they are cryptographically 1630 protected. Even in tunnel mode, there are routing problems because 1631 transparently translating the addresses of AH and ESP packets 1632 requires special logic in the NAT and that logic is heuristic and 1633 unreliable in nature. For that reason, IKEv2 can negotiate UDP 1634 encapsulation of IKE, ESP, and AH packets. This encoding is slightly 1635 less efficient but is easier for NATs to process. In addition, 1636 firewalls may be configured to pass IPsec traffic over UDP but not 1637 ESP/AH or vice versa. 1639 It is a common practice of NATs to translate TCP and UDP port numbers 1640 as well as addresses and use the port numbers of inbound packets to 1641 decide which internal node should get a given packet. For this 1642 reason, even though IKE packets MUST be sent from and to UDP port 1643 500, they SHOULD be accepted coming from any port and responses 1644 SHOULD be sent to the port from whence they came. This is because the 1645 ports may be modified as the packets pass through NATs. Similarly, IP 1646 addresses of the IKE endpoints are generally not included in the IKE 1647 payloads because the payloads are cryptographically protected and 1648 could not be transparently modified by NATs. 1650 Port 4500 is reserved for UDP encapsulated ESP, AH, and IKE. When 1651 working through a NAT, it is generally better to pass IKE packets 1652 over port 4500 because some older NATs modify IKE traffic on port 500 1653 in an attempt to transparently establish IPsec connections. Such NATs 1654 may interfere with the straightforward NAT traversal envisioned by 1655 this document, so an IPsec endpoint that discovers a NAT between it 1656 and its correspondent MUST send all subsequent traffic to and from 1657 port 4500, which all NATs should know run the NAT-friendly protocol. 1659 The specific requirements for supporting NAT traversal are listed 1660 below. Support for NAT traversal is optional. In this section only, 1661 requirements listed as MUST only apply to implementations supporting 1662 NAT traversal. 1664 IKE MUST listen on port 4500 as well as port 500. IKE MUST respond 1665 to the IP address and port from which packets arrived. 1667 The IKE responder MUST include in its IKE_SA_INIT response Notify 1668 payloads of type NAT_DETECTION_SOURCE_IP and 1669 NAT_DETECTION_DESTINATION_IP. The IKE initiator MUST check these 1670 payloads if present and if they do not match the addresses in the 1671 outer packet MUST tunnel all future IKE, ESP, and AH packets 1672 associated with this IKE_SA over UDP port 4500. 1674 2.24 ECN Notification 1676 Sections 5.1.2.1 and 5.1.2.2 of [RFC 2401] specify that the IPv4 TOS 1677 octet and IPv6 traffic class octet are to be copied from the inner 1678 header to the outer header by the encapsulator and that the outer 1679 header is to be discarded (no change to inner header) by the 1680 decapsulator. If ECN is in use, ECT codepoints will be copied to the 1681 outer header, but if a router within the tunnel changes an ECT 1682 codepoint to a CE codepoint to indicate congestion, that indication 1683 will be discarded by the decapsulator. This behavior is highly 1684 undesirable, and Section 9.2 of [RFC 3168] specifies changes to IPsec 1685 to avoid it. These changes include two ECN operating modes and 1686 negotiation support to detect and cope with IPsec decapsulators that 1687 discard ECN congestion indications; use of ECN in the outer IP header 1688 of IPsec tunnels is not permitted when such discarding is a 1689 possibility. 1691 In order to avoid multiple ECN operating modes and negotiation, 1692 tunnel decapsulators for tunnel-mode Security Associations (SAs) 1693 created by IKEv2 MUST implement the following modifications to 1694 prevent discarding of ECN congestion indications. IKEv2 tunnel- mode 1695 SA negotiation is handled by the USE_TRANSPORT_MODE notify message 1696 type (see Section 5.10.1 of [IKEv2]). The following modifications 1697 *replace* Section 9.2 of RFC 3168 and *update* Sections 5.1.2.1 and 1698 5.1.2.2 of RFC 2401. 1700 Encapsulation and Decapsulation of packets for a tunnel-mode SA 1701 created by IKEv2 MUST NOT follow the modifications specified by 1702 Section 9.2 of RFC 3168 and its subsections. Instead, the following 1703 modifications to encapsulation and decapsulation in Sections 5.1.2.1 1704 and 5.1.2.2 of RFC 2401 MUST be performed: 1706 Outer Hdr at Inner Hdr at 1707 IPv4 Encapsulator Decapsulator 1708 Header fields: -------------------- ------------ 1709 DS Field copied from inner hdr (5) no change 1710 ECN Field copied from inner hdr constructed (7) 1711 IPv6 1712 Header fields: 1713 DS Field copied from inner hdr (6) no change 1714 ECN Field copied from inner hdr constructed (7) 1716 (5)(6) If the packet will immediately enter a domain for which the 1717 DSCP value in the outer header is not appropriate, that value MUST 1718 be mapped to an appropriate value for the domain [RFC 2474]. Also 1719 see [RFC 2475] for further information. 1721 (7) If the ECN field in the inner header is set to ECT(0) or 1722 ECT(1) and the ECN field in the outer header is set to CE, then 1723 set the ECN field in the inner header to CE, otherwise make no 1724 change to the ECN field in the inner header. 1726 (5) and (6) are identical to match usage in [RFC2401], although 1727 they are different in [RFC2401]. These actions are not related to 1728 ECN, but are required for Differentiated Services support. They 1729 are carried over to this document from RFC 3168 so that all of RFC 1730 3168's changes to IPsec can be made non-applicable to SAs created 1731 by IKEv2. 1733 3 Header and Payload Formats 1735 3.1 The IKE Header 1737 IKE messages use UDP ports 500 and/or 4500, with one IKE message per 1738 UDP datagram. Information from the UDP header is largely ignored 1739 except that the IP addresses and UDP ports from the headers are 1740 reversed and used for return packets. When sent on UDP port 500, IKE 1741 messages begin immediately following the UDP header. When sent on UDP 1742 port 4500, IKE messages have prepended four octets of zero. These 1743 four octets of zero are not part of the IKE message and are not 1744 included in any of the length fields or checksums defined by IKE. 1745 Each IKE message begins with the IKE header, denoted HDR in this 1746 memo. Following the header are one or more IKE payloads each 1747 identified by a "Next Payload" field in the preceding payload. 1748 Payloads are processed in the order in which they appear in an IKE 1749 message by invoking the appropriate processing routine according to 1750 the "Next Payload" field in the IKE header and subsequently according 1751 to the "Next Payload" field in the IKE payload itself until a "Next 1752 Payload" field of zero indicates that no payloads follow. If a 1753 payload of type "Encrypted" is found, that payload is decrypted and 1754 its contents parsed as additional payloads. An Encrypted payload MUST 1755 be the last payload in a packet and an encrypted payload MUST NOT 1756 contain another encrypted payload. 1758 The Recipient SPI in the header identifies an instance of an IKE 1759 security association. It is therefore possible for a single instance 1760 of IKE to multiplex distinct sessions with multiple peers. 1762 All multi-octet fields representing integers are laid out in big 1763 endian order (aka most significant byte first, or network byte 1764 order). 1766 The format of the IKE header is shown in Figure 4. 1767 1 2 3 1768 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 1769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1770 ! IKE_SA Initiator's SPI ! 1771 ! ! 1772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1773 ! IKE_SA Responder's SPI ! 1774 ! ! 1775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1776 ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! 1777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1778 ! Message ID ! 1779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1780 ! Length ! 1781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1783 Figure 4: IKE Header Format 1785 o Initiator's SPI (8 octets) - A value chosen by the 1786 initiator to identify a unique IKE security association. This 1787 value MUST NOT be zero. 1789 o Responder's SPI (8 octets) - A value chosen by the 1790 responder to identify a unique IKE security association. This 1791 value MUST be zero in the first message of an IKE Initial 1792 Exchange and MUST NOT be zero in any other message other 1793 than following a cookie request (see section 2.6). 1795 o Next Payload (1 octet) - Indicates the type of payload that 1796 immediately follows the header. The format and value of each 1797 payload is defined below. 1799 o Major Version (4 bits) - indicates the major version of the IKE 1800 protocol in use. Implementations based on this version of IKE 1801 MUST set the Major Version to 2. Implementations based on 1802 previous versions of IKE and ISAKMP MUST set the Major Version 1803 to 1. Implementations based on this version of IKE MUST reject 1804 (or ignore) messages containing a version number greater than 1805 2. 1807 o Minor Version (4 bits) - indicates the minor version of the 1808 IKE protocol in use. Implementations based on this version of 1809 IKE MUST set the Minor Version to 0. They MUST ignore the minor 1810 version number of received messages. 1812 o Exchange Type (1 octet) - indicates the type of exchange being 1813 used. This dictates the payloads sent in each message and 1814 message orderings in the exchanges. 1816 Exchange Type Value 1818 RESERVED 0 1819 Reserved for ISAKMP 1-31 1820 Reserved for IKEv1 32-33 1821 IKE_SA_INIT 34 1822 IKE_AUTH 35 1823 CREATE_CHILD_SA 36 1824 INFORMATIONAL 37 1825 Reserved for IKEv2+ 38-239 1826 Reserved for private use 240-255 1828 o Flags (1 octet) - indicates specific options that are set 1829 for the message. Presence of options are indicated by the 1830 appropriate bit in the flags field being set. The bits are 1831 defined LSB first, so bit 0 would be the least significant 1832 bit of the Flags octet. In the description below, a bit 1833 being 'set' means its value is '1', while 'cleared' means 1834 its value is '0'. 1836 -- X(reserved) (bits 0-2) - These bits MUST be cleared 1837 when sending and MUST be ignored on receipt. 1839 -- I(nitiator) (bit 3 of Flags) - This bit MUST be set in 1840 messages sent by the original Initiator of the IKE_SA 1841 and MUST be cleared in messages sent by the original 1842 Responder. It is used by the recipient to determine 1843 which eight octets of the SPI was generated by the 1844 recipient. 1846 -- V(ersion) (bit 4 of Flags) - This bit indicates that 1847 the transmitter is capable of speaking a higher major 1848 version number of the protocol than the one indicated 1849 in the major version number field. Implementations of 1850 IKEv2 must clear this bit when sending and MUST ignore 1851 it in incoming messages. 1853 -- R(esponse) (bit 5 of Flags) - This bit indicates that 1854 this message is a response to a message containing 1855 the same message ID. This bit MUST be cleared in all 1856 request messages and MUST be set in all responses. 1857 An IKE endpoint MUST NOT generate a response to a 1858 message that is marked as being a response. 1860 -- X(reserved) (bits 6-7 of Flags) - These bits MUST be 1861 cleared when sending and MUST be ignored on receipt. 1863 o Message ID (4 octets) - Message identifier used to control 1864 retransmission of lost packets and matching of requests and 1865 responses. It is essential to the security of the protocol 1866 because it is used to prevent message replay attacks. 1867 See section 2.2. 1869 o Length (4 octets) - Length of total message (header + payloads) 1870 in octets. 1872 3.2 Generic Payload Header 1874 Each IKE payload defined in sections 3.3 through 3.16 begins with a 1875 generic header, shown in Figure 5. Figures for each payload below 1876 will include the generic payload header but for brevity the 1877 description of each field will be omitted. 1879 1 2 3 1880 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 1881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1882 ! Next Payload !C! RESERVED ! Payload Length ! 1883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1885 Figure 5: Generic Payload Header 1887 The Generic Payload Header fields are defined as follows: 1889 o Next Payload (1 octet) - Identifier for the payload type of the 1890 next payload in the message. If the current payload is the last 1891 in the message, then this field will be 0. This field provides 1892 a "chaining" capability whereby additional payloads can be 1893 added to a message by appending it to the end of the message 1894 and setting the "Next Payload" field of the preceding payload 1895 to indicate the new payload's type. For an Encrypted payload, 1896 which must always be the last payload of a message, the Next 1897 Payload field is set to the payload type of the first contained 1898 payload. 1900 Payload Type Values 1902 Next Payload Type Value 1904 Security Association (SA) 1 1905 Key Exchange (KE) 4 1906 Initiator Identification (IDi) 5 1907 Certificate (CERT) 6 1908 Certificate Request (CERTREQ) 7 1909 Authentication (AUTH) 9 1910 Nonce (Ni, Nr) 10 1911 Notification (N) 11 1912 Delete (D) 12 1913 Vendor ID (V) 13 1914 Initiator Traffic Selector (TSi) 14 1915 Encrypted (E) 15 1916 Configuration (CP) 16 1917 Extended Authentication (EAP) 17 1918 Responder Identication (IDr) 18 1919 Responder Traffic Selector (TSr) 19 1921 Payload type values 20-127 are reserved to IANA for future 1922 assignment in IKEv2 (see section 6). Payload type values 128-255 1923 are for private use among mutually consenting parties. 1925 o Critical (1 bit) - MUST be set to zero if the sender wants 1926 the recipient to skip this payload if he does not 1927 understand the payload type code in the Next Payload field 1928 of the previous payload. MUST be set to one if the 1929 sender wants the recipient to reject this entire message 1930 if he does not understand the payload type. MUST be ignored 1931 by the recipient if the recipient understands the payload type 1932 code. MUST be set to zero for payload types defined in this 1933 document. Note that the critical bit applies to the current 1934 payload rather than the "next" payload whose type code 1935 appears in the first octet. The reasoning behind not setting 1936 the critical bit for payloads defined in this document is 1937 that all implementations MUST understand all payload types 1938 defined in this document and therefore must ignore the 1939 Critical bit's value. Skipped payloads are expected to 1940 have valid Next Payload and Payload Length fields. 1942 o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored. 1944 o Payload Length (2 octets) - Length in octets of the current 1945 payload, including the generic payload header. 1947 3.3 Security Association Payload 1949 The Security Association Payload, denoted SA in this memo, is used to 1950 negotiate attributes of a security association. Assembly of Security 1951 Association Payloads requires great peace of mind. An SA may contain 1952 multiple proposals. Each proposal may contain multiple protocols 1953 (where a protocol is IKE, ESP, or AH), each protocol may contain 1954 multiple transforms, and each transform may contain multiple 1955 attributes. When parsing an SA, an implementation MUST check that the 1956 total Payload Length is consistent with the payload's internal 1957 lengths and counts. Proposals, Transforms, and Attributes each have 1958 their own variable length encodings. They are nested such that the 1959 Payload Length of an SA includes the combined contents of the SA, 1960 Proposal, Transform, and Attribute information. The length of a 1961 Proposal includes the lengths of all Transforms and Attributes it 1962 contains. The length of a Transform includes the lengths of all 1963 Attributes it contains. 1965 The syntax of Security Associations, Proposals, Transforms, and 1966 Attributes is based on ISAKMP, however the semantics are somewhat 1967 different. The reason for the complexity and the hierarchy is to 1968 allow for multiple possible combinations of algorithms to be encoded 1969 in a single SA. Sometimes there is a choice of multiple algorithms, 1970 while other times there is a combination of algorithms. For example, 1971 an Initiator might want to propose using (AH w/MD5 and ESP w/3DES) OR 1972 (ESP w/MD5 and 3DES). 1974 One of the reasons the semantics of the SA payload has changed from 1975 ISAKMP and IKEv1 is to make the encodings more compact in common 1976 cases. 1978 The Proposal structure contains within it a Proposal # and a 1979 SECURITY_PROTOCOL_ID. Each structure MUST have the same Proposal # 1980 as the previous one or one greater. The first Proposal MUST have a 1981 Proposal # of one. If two successive structures have the same 1982 Proposal number, it means that the proposal consists of the first 1983 structure AND the second. So a proposal of AH AND ESP would have two 1984 proposal structures, one for AH and one for ESP and both would have 1985 Proposal #1. A proposal of AH OR ESP would have two proposal 1986 structures, one for AH with proposal #1 and one for ESP with proposal 1987 #2. 1989 Each Proposal/Protocol structure is followed by one or more transform 1990 structures. The number of different transforms is generally 1991 determined by the Protocol. AH generally has a single transform: an 1992 integrity check algorithm. ESP generally has two: an encryption 1993 algorithm AND an integrity check algorithm. IKE generally has four 1994 transforms: a Diffie-Hellman group, an integrity check algorithm, a 1995 prf algorithm, and an encryption algorithm. For each Protocol, the 1996 set of permissible transforms are assigned transform ID numbers, 1997 which appear in the header of each transform. 1999 If there are multiple transforms with the same Transform Type, the 2000 proposal is an OR of those transforms. If there are multiple 2001 Transforms with different Transform Types, the proposal is an AND of 2002 the different groups. For example, to propose ESP with (3DES or IDEA) 2003 and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two 2004 Transform Type 1 candidates (one for 3DES and one for IDEA) and two 2005 Transform Type 2 candidates (one for HMAC_MD5 and one for HMAC_SHA). 2006 This effectively proposes four combinations of algorithms. If the 2007 Initiator wanted to propose only a subset of those - say (3DES and 2008 HMAC_MD5) or (IDEA and HMAC_SHA), there is no way to encode that as 2009 multiple transforms within a single Proposal. Instead, the Initiator 2010 would have to construct two different Proposals, each with two 2011 transforms. 2013 A given transform MAY have one or more Attributes. Attributes are 2014 necessary when the transform can be used in more than one way, as 2015 when an encryption algorithm has a variable key size. The transform 2016 would specify the algorithm and the attribute would specify the key 2017 size. Most transforms do not have attributes. 2019 Note that the semantics of Transforms and Attributes are quite 2020 different than in IKEv1. In IKEv1, a single Transform carried 2021 multiple algorithms for a protocol with one carried in the Transform 2022 and the others carried in the Attributes. 2024 1 2 3 2025 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 2026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2027 ! Next Payload !C! RESERVED ! Payload Length ! 2028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2029 ! ! 2030 ~ ~ 2031 ! ! 2032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2034 Figure 6: Security Association Payload 2036 o Proposals (variable) - one or more proposal substructures. 2038 The payload type for the Security Association Payload is one (1). 2040 3.3.1 Proposal Substructure 2042 1 2 3 2043 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 2044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2045 ! 0 (last) or 2 ! RESERVED ! Proposal Length ! 2046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2047 ! Proposal # ! Protocol-Id ! SPI Size !# of Transforms! 2048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2049 ~ SPI (variable) ~ 2050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2051 ! ! 2052 ~ ~ 2053 ! ! 2054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2056 Figure 7: Proposal Substructure 2058 o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the 2059 last Proposal Substructure in the SA. This syntax is inherited 2060 from ISAKMP, but is unnecessary because the last Proposal 2061 could be identified from the length of the SA. The value (2) 2062 corresponds to a Payload Type of Proposal, and the first 2063 four octets of the Proposal structure are designed to look 2064 somewhat like the header of a Payload. 2066 o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored. 2068 o Proposal Length (2 octets) - Length of this proposal, 2069 including all transforms and attributes that follow. 2071 o Proposal # (1 octet) - When a proposal is made, the first 2072 proposal in an SA MUST be #1, and subsequent proposals 2073 MUST either be the same as the previous proposal (indicating 2074 an AND of the two proposals) or one more than the previous 2075 proposal (indicating an OR of the two proposals). When a 2076 proposal is accepted, all of the proposal numbers in the 2077 SA must be the same and must match the number on the 2078 proposal sent that was accepted. 2080 o Protocol-Id (1 octet) - Specifies the protocol identifier 2081 for the current negotiation. Zero (0) indicates IKE, 2082 one (1) indicated ESP, and two (2) indicates AH. 2084 o SPI Size (1 octet) - For an initial IKE_SA negotiation, 2085 this field MUST be zero; the SPI is obtained from the 2086 outer header. During subsequent negotiations, 2087 it is equal to the size, in octets, of the SPI of the 2088 corresponding protocol (8 for IKE, 4 for ESP and AH). 2090 o # of Transforms (1 octet) - Specifies the number of 2091 transforms in this proposal. 2093 o SPI (variable) - The sending entity's SPI. Even if the SPI 2094 Size is not a multiple of 4 octets, there is no padding 2095 applied to the payload. When the SPI Size field is zero, 2096 this field is not present in the Security Association 2097 payload. 2099 o Transforms (variable) - one or more transform substructures. 2101 3.3.2 Transform Substructure 2103 1 2 3 2104 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 2105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2106 ! 0 (last) or 3 ! RESERVED ! Transform Length ! 2107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2108 !Transform Type ! RESERVED ! Transform ID ! 2109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2110 ! ! 2111 ~ Transform Attributes ~ 2112 ! ! 2113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2115 Figure 8: Transform Substructure 2117 o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the 2118 last Transform Substructure in the Proposal. This syntax is 2119 inherited from ISAKMP, but is unnecessary because the last 2120 Proposal could be identified from the length of the SA. The 2121 value (3) corresponds to a Payload Type of Transform, and 2122 the first four octets of the Transform structure are designed 2123 to look somewhat like the header of a Payload. 2125 o RESERVED - MUST be sent as zero; MUST be ignored. 2127 o Transform Length - The length (in octets) of the Transform 2128 Substructure including Header and Attributes. 2130 o Transform Type (1 octet) - The type of transform being specified 2131 in this transform. Different protocols support different 2132 transform types. For some protocols, some of the transforms 2133 may be optional. If a transform is optional and the initiator 2134 wishes to propose that the transform be omitted, no transform 2135 of the given type is included in the proposal. If the 2136 initiator wishes to make use of the transform optional to 2137 the responder, she includes a transform substructure with 2138 transform ID = 0 as one of the options. 2140 o Transform ID (1 octet) - The specific instance of the transform 2141 type being proposed. 2143 Transform Type Values 2145 Transform Used In 2146 Type 2147 Encryption Algorithm 1 (IKE and ESP) 2148 Pseudo-random Function 2 (IKE) 2149 Integrity Algorithm 3 (IKE, AH, and optional in ESP) 2150 Diffie-Hellman Group 4 (IKE and optional in AH and ESP) 2151 Extended Sequence Numbers 5 (Optional in AH and ESP) 2153 values 8-240 are reserved to IANA. Values 241-255 are for 2154 private use among mutually consenting parties. 2156 For Transform Type 1 (Encryption Algorithm), defined Transform IDs 2157 are: 2159 Name Number Defined In 2160 RESERVED 0 2161 ENCR_DES_IV64 1 (RFC1827) 2162 ENCR_DES 2 (RFC2405) 2163 ENCR_3DES 3 (RFC2451) 2164 ENCR_RC5 4 (RFC2451) 2165 ENCR_IDEA 5 (RFC2451) 2166 ENCR_CAST 6 (RFC2451) 2167 ENCR_BLOWFISH 7 (RFC2451) 2168 ENCR_3IDEA 8 (RFC2451) 2169 ENCR_DES_IV32 9 2170 ENCR_RC4 10 2171 ENCR_NULL 11 (RFC2410) 2172 ENCR_AES_128_CBC 12 2173 ENCR_AES_128_CTR 13 2175 values 13-240 are reserved to IANA. Values 241-255 are for 2176 private use among mutually consenting parties. 2178 For Transform Type 2 (Pseudo-random Function), defined Transform IDs 2179 are: 2181 Name Number Defined In 2182 RESERVED 0 2183 PRF_HMAC_MD5 1 (RFC2104) 2184 PRF_HMAC_SHA1 2 (RFC2104) 2185 PRF_HMAC_TIGER 3 (RFC2104) 2186 PRF_AES128_CBC 4 2188 values 4-240 are reserved to IANA. Values 241-255 are for 2189 private use among mutually consenting parties. 2191 For Transform Type 3 (Integrity Algorithm), defined Transform IDs 2192 are: 2194 Name Number Defined In 2195 NONE 0 2196 AUTH_HMAC_MD5_96 1 (RFC2403) 2197 AUTH_HMAC_SHA1_96 2 (RFC2404) 2198 AUTH_DES_MAC 3 2199 AUTH_KPDK_MD5 4 (RFC1826) 2200 AUTH_AES_XCBC_96 5 2202 For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs 2203 are: 2205 Name Number 2206 NONE 0 2207 Pre-defined (see Appendix B) 1 - 5 2208 RESERVED 6 - 200 2209 MODP (exponentiation) 201 (w/attributes) 2210 ECP (elliptic curve over GF[P] 202 (w/attributes) 2211 EC2N (elliptic curve over GF[2^N]) 203 (w/attributes) 2213 values 6-200 are reserved to IANA for new MODP, ECP or EC2N 2214 groups. Values 204-255 are for private use among mutually 2215 consenting parties. Specification of values 201, 202 or 203 2216 allow peers to define a new Diffie-Hellman group in-line as 2217 part of the exchange. Private use of values 204-255 may entail 2218 complete definition of a group or may require attributes to 2219 accompany them. 2221 For Transform Type 5 (Extended Sequence Numbers), defined Transform 2222 IDs are: 2224 Name Number 2225 No Extended Sequence Numbers 0 2226 Extended Sequence Numbers 1 2227 RESERVED 2 - 255 2228 If Transform Type 5 is not included in a proposal, use of 2229 Extended Sequence Numbers is assumed. 2231 3.3.3 Mandatory Transform Types 2233 The number and type of transforms that accompany an SA payload are 2234 dependent on the protocol in the SA itself. An SA payload proposing 2235 the establishment of an SA has the following mandatory and optional 2236 transform types. A compliant implementation MUST support all 2237 mandatory and optional types for each protocol it supports. Whether 2238 the optional types are present in a particular proposal depends 2239 solely on the discretion of the sender. 2241 Protocol Mandatory Types Optional Types 2242 IKE 1, 2, 3, 4 2243 ESP 1 3, 4, 5 2244 AH 3 4, 5 2246 3.3.4 Mandatory Transform IDs 2248 The specification of suites that MUST and SHOULD be supported for 2249 interoperability has been removed from this document because they are 2250 likely to change more rapidly than this document evolves. 2252 The previously-MUST ciphersuites (3DES/HMAC_SHA1/DH Group 2) are 2253 based on currently-deployed hardware that meets the security 2254 requirements of the vast majority of current IPsec users, and should 2255 be useful for at least a decade according to cryptographic estimates 2256 from NIST for business user scenarios. The previously-SHOULD 2257 ciphersuites (AES/HMAC_SHA1/DH Group 5) are based on expectations of 2258 where the security industry is moving (namely, to the AES encryption 2259 suite) and where more security-conscious users are moving as current 2260 key lengths become more attackable due to the steady lowering of cost 2261 to mount brute-force attacks. 2263 An important lesson learned from IKEv1 is that no system should only 2264 implement the mandatory algorithms and expect them to be the best 2265 choice for all customers. For example, at the time that this document 2266 was being written, many IKEv1 implementers are starting to migrate to 2267 AES in CBC mode for VPN applications. Many IPsec systems based on 2268 IKEv2 will implement AES, longer Diffie-Hellman keys, and additional 2269 hash algorithms, and some IPsec customers already require these 2270 algorithms in addition to the ones listed above. 2272 It is likely that IANA will add additional transforms in the future, 2273 and some users may want to use private suites, especially for IKE 2274 where implementations should be capable of supporting different 2275 parameters, up to certain size limits. In support of this goal, all 2276 implementations of IKEv2 SHOULD include a management facility that 2277 allows specification (by a user or system administrator) of Diffie- 2278 Hellman parameters (the generator, modulus, and exponent lengths and 2279 values) for new DH groups. Implementations SHOULD provide a 2280 management interface via which these parameters and the associated 2281 transform IDs may be entered (by a user or system administrator), to 2282 enable negotiating such groups. 2284 All implementations of IKEv2 MUST include a management facility that 2285 enables a user or system administrator to specify the suites that are 2286 acceptable for use with IKE. Upon receipt of a payload with a set of 2287 transform IDs, the implementation MUST compare the transmitted 2288 transform IDs against those locally configured via the management 2289 controls, to verify that the proposed suite is acceptable based on 2290 local policy. The implementation MUST reject SA proposals that are 2291 not authorized by these IKE suite controls. 2292 3.3.5 Transform Attributes 2294 Each transform in a Security Association payload may include 2295 attributes that modify or complete the specification of the 2296 transform. These attributes are type/value pairs and are defined 2297 below. For example, if an encryption algorithm has a variable length 2298 key, the key length to be used may be specified as an attribute. 2299 Attributes can have a value with a fixed two octet length or a 2300 variable length value. For the latter the attribute is the form of 2301 type/length/value. 2303 1 2 3 2304 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 2305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2306 !A! Attribute Type ! AF=0 Attribute Length ! 2307 !F! ! AF=1 Attribute Value ! 2308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2309 ! AF=0 Attribute Value ! 2310 ! AF=1 Not Transmitted ! 2311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2313 Figure 9: Data Attributes 2315 o Attribute Type (2 octets) - Unique identifier for each type of 2316 attribute (see below). 2318 The most significant bit of this field is the Attribute Format 2319 bit (AF). It indicates whether the data attributes follow the 2320 Type/Length/Value (TLV) format or a shortened Type/Value (TV) 2321 format. If the AF bit is zero (0), then the Data Attributes 2322 are of the Type/Length/Value (TLV) form. If the AF bit is a 2323 one (1), then the Data Attributes are of the Type/Value form. 2325 o Attribute Length (2 octets) - Length in octets of the Attribute 2326 Value. When the AF bit is a one (1), the Attribute Value is 2327 only 2 octets and the Attribute Length field is not present. 2329 o Attribute Value (variable length) - Value of the Attribute 2330 associated with the Attribute Type. If the AF bit is a 2331 zero (0), this field has a variable length defined by the 2332 Attribute Length field. If the AF bit is a one (1), the 2333 Attribute Value has a length of 2 octets. 2335 Note that while quite a few attribute types are defined, the only 2336 algorithms defined in this document that accept attributes are the 2337 defined on the fly Diffie-Hellman groups, whose use is optional and 2338 likely unusual. An IKEv2 implementation MAY ignore attributes if it 2339 does not support any algorithms that use them. 2341 Attributes described as basic MUST NOT be encoded as variable. 2342 Variable length attributes MUST NOT be encoded as basic even if their 2343 value can fit into two octets. NOTE: This is a change from IKEv1, 2344 where increased flexibility may have simplified the composer of 2345 messages but certainly complicated the parser. 2347 Attribute Type value Attribute Format 2348 -------------------------------------------------------------- 2349 RESERVED 0-5 2350 Group Prime/Irreducible Polynomial 6 TLV 2351 Group Generator One 7 TLV 2352 Group Generator Two 8 TLV 2353 Group Curve A 9 TLV 2354 Group Curve B 10 TLV 2355 RESERVED 11-13 2356 Key Length 14 TV 2357 Field Size 15 TV 2358 Group Order 16 TLV 2359 Block Size 17 TV 2361 values 0-5, 11-13, and 18-16383 are reserved to IANA. Values 2362 16384-32767 are for private use among mutually consenting parties. 2364 - Group Prime/Irreducible Polynomial 2366 The prime number of a MODP Diffie-Hellman group or the irreducible 2367 polynomial of an elliptic curve when specifying a private Diffie- 2368 Hellman group. 2370 - Generator One, Generator Two 2372 The X- and Y-coordinate of a point on an elliptic curve. When the 2373 Y-coordinate (generator two) is not given it can be computed with 2374 the X-coordinate and the definition of the curve. 2376 - Curve A, Curve B 2378 Coefficients from the definition of an elliptic curve: 2380 y^2 + xy = x^3 + (curve A)x^2 + (curve B) 2382 - Key Length 2384 When using an Encryption Algorithm that has a variable length key, 2385 this attribute specifies the key length in bits. (MUST use network 2386 byte order). This attribute MUST NOT be used when the specified 2387 Encryption Algorithm uses a fixed length key. 2389 - Field Size 2391 The field size, in bits, of a Diffie-Hellman group. 2393 - Group Order 2395 The group order of an elliptic curve group. Note the length of 2396 this attribute depends on the field size. 2398 - Block Size 2400 The number of bits per block of a cipher with a variable block 2401 length. 2403 3.3.6 Attribute Negotiation 2405 During security association negotiation Initiators present offers to 2406 Responders. Responders MUST select a single complete set of 2407 parameters from the offers (or reject all offers if none are 2408 acceptable). If there are multiple proposals, the Responder MUST 2409 choose a single proposal number and return all of the Proposal 2410 substructures with that Proposal number. If there are multiple 2411 Transforms with the same type the Responder MUST choose a single one. 2412 Any attributes of a selected transform MUST be returned unmodified. 2413 The Initiator of an exchange MUST check that the accepted offer is 2414 consistent with one of its proposals, and if not that response MUST 2415 be rejected. 2417 Negotiating Diffie-Hellman groups presents some special challenges. 2418 Diffie-Hellman groups are specified either using a defined group 2419 description (see Appendix B) or by defining all attributes of a group 2420 in an IKE policy offer. Group attributes, such as group type or prime 2421 number MUST NOT be offered in conjunction with a previously defined 2422 group. SA offers include proposed attributes and a Diffie-Hellman 2423 public number (KE) in the same message. If the Initiator offers to 2424 use one of several Diffie-Hellman groups, it SHOULD pick the one the 2425 Responder is most likely to accept and include a KE corresponding to 2426 that group. If the guess turns out to be wrong, the Responder will 2427 indicate the correct group in the response and the Initiator SHOULD 2428 pick an element of that group for its KE value in the third message. 2429 If the Initiator guesses wrong in a CREATE_CHILD_SA negotiation, no 2430 SA is created and the Initiator SHOULD retry with the correct group. 2432 Implementation Note: 2434 Certain negotiable attributes can have ranges or could have 2435 multiple acceptable values. These are the Diffie-Hellman group and 2436 the key length of a variable key length symmetric cipher. To 2437 further interoperability and to support upgrading endpoints 2438 independently, implementers of this protocol SHOULD accept values 2439 which they deem to supply greater security. For instance if a peer 2440 is configured to accept a variable lengthed cipher with a key 2441 length of X bits and is offered that cipher with a larger key 2442 length an implementation SHOULD accept the offer. 2444 Support of this capability allows an implementation to express a 2445 concept of "at least" a certain level of security-- "a key length of 2446 _at least_ X bits for cipher foo". 2448 3.4 Key Exchange Payload 2450 The Key Exchange Payload, denoted KE in this memo, is used to 2451 exchange Diffie-Hellman public numbers as part of a Diffie-Hellman 2452 key exchange. The Key Exchange Payload consists of the IKE generic 2453 header followed by the Diffie-Hellman public value itself. 2455 1 2 3 2456 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 2457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2458 ! Next Payload !C! RESERVED ! Payload Length ! 2459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2460 ! DH Group # ! RESERVED (MBZ) ! 2461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2462 ! ! 2463 ~ Key Exchange Data ~ 2464 ! ! 2465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2467 Figure 10: Key Exchange Payload Format 2469 A key exchange payload is constructed by copying ones Diffie-Hellman 2470 public value into the "Key Exchange Data" portion of the payload. 2471 The length of the Diffie-Hellman public value MUST be equal to the 2472 length of the prime modulus over which the exponentiation was 2473 performed, prepending zero bits to the value if necessary. 2475 The DH Group # identifies the Diffie-Hellman group in which the Key 2476 Exchange Data was computed. If the selected proposal uses a 2477 different Diffie-Hellman group, the message MUST be rejected with a 2478 Notify payload of type INVALID_KE_PAYLOAD. 2480 The payload type for the Key Exchange payload is four (4). 2482 3.5 Identification Payloads 2484 The Identification Payloads, denoted IDi and IDr in this memo, allow 2485 peers to assert an identity to one another. This identity may be used 2486 for policy lookup, but does not necessarily have to match anything in 2487 the CERT payload; both fields may be used by an implementation to 2488 perform access control decisions. 2490 NOTE: In IKEv1, two ID payloads were used in each direction to hold 2491 Traffic Selector information for data passing over the SA. In IKEv2, 2492 this information is carried in Traffic Selector (TS) payloads (see 2493 section 3.13). 2495 The Identification Payload consists of the IKE generic header 2496 followed by identification fields as follows: 2498 1 2 3 2499 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 2500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2501 ! Next Payload !C! RESERVED ! Payload Length ! 2502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2503 ! ID Type ! RESERVED | 2504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2505 ! ! 2506 ~ Identification Data ~ 2507 ! ! 2508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2510 Figure 11: Identification Payload Format 2512 o ID Type (1 octet) - Specifies the type of Identification being 2513 used. 2515 o RESERVED - MUST be sent as zero; MUST be ignored. 2517 o Identification Data (variable length) - Value, as indicated by 2518 the Identification Type. The length of the Identification Data 2519 is computed from the size in the ID payload header. 2521 The payload types for the Identification Payload are five (5) for IDi 2522 and eighteen (18) for IDr. 2524 The following table lists the assigned values for the Identification 2525 Type field, followed by a description of the Identification Data 2526 which follows: 2528 ID Type Value 2529 ------- ----- 2530 RESERVED 0 2532 ID_IPV4_ADDR 1 2534 A single four (4) octet IPv4 address. 2536 ID_FQDN 2 2538 A fully-qualified domain name string. An example of a 2539 ID_FQDN is, "lounge.org". The string MUST not contain any 2540 terminators (e.g. NULL, CR, etc.). 2542 ID_RFC822_ADDR 3 2544 A fully-qualified RFC822 email address string, An example of 2545 a ID_RFC822_ADDR is, "lizard@lounge.org". The string MUST 2546 not contain any terminators. 2548 ID_IPV6_ADDR 5 2550 A single sixteen (16) octet IPv6 address. 2552 ID_DER_ASN1_DN 9 2554 The binary DER encoding of an ASN.1 X.500 Distinguished Name 2555 [X.501]. 2557 ID_DER_ASN1_GN 10 2559 The binary DER encoding of an ASN.1 X.500 GeneralName 2560 [X.509]. 2562 ID_KEY_ID 11 2564 An opaque octet stream which may be used to pass an account 2565 name or to pass vendor-specific information necessary to do 2566 certain proprietary forms of identification. 2568 Two implementations will interoperate only if each can generate a 2569 form of ID acceptable to the other. To assure maximum 2570 interoperability, implementations MUST be configurable to send at 2571 least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and 2572 MUST be configurable to accept all of these forms. Implementations 2573 SHOULD be capable of generating and accepting all of these forms. 2575 3.6 Certificate Payload 2577 The Certificate Payload, denoted CERT in this memo, provides a means 2578 to transport certificates or other authentication related information 2579 via IKE. Certificate payloads SHOULD be included in an exchange if 2580 certificates are available to the sender unless the peer has 2581 indicated an ability to retrieve this information from elsewhere. 2582 Note that the term "Certificate Payload" is somewhat misleading, 2583 because not all authentication mechanisms use certificates and data 2584 other than certificates may be passed in this payload. 2586 The Certificate Payload is defined as follows: 2588 1 2 3 2589 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 2590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2591 ! Next Payload !C! RESERVED ! Payload Length ! 2592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2593 ! Cert Encoding ! ! 2594 +-+-+-+-+-+-+-+-+ ! 2595 ~ Certificate Data ~ 2596 ! ! 2597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2599 Figure 12: Certificate Payload Format 2601 o Certificate Encoding (1 octet) - This field indicates the type 2602 of certificate or certificate-related information contained 2603 in the Certificate Data field. 2605 Certificate Encoding Value 2606 -------------------- ----- 2607 RESERVED 0 2608 PKCS #7 wrapped X.509 certificate 1 2609 PGP Certificate 2 2610 DNS Signed Key 3 2611 X.509 Certificate - Signature 4 2612 Kerberos Token 6 2613 Certificate Revocation List (CRL) 7 2614 Authority Revocation List (ARL) 8 2615 SPKI Certificate 9 2616 X.509 Certificate - Attribute 10 2617 Raw RSA Key 11 2618 Hash and URL of PKIX certificate 12 2619 Hash and URL of PKIX bundle 13 2620 RESERVED 14 - 200 2621 PRIVATE USE 201 - 255 2623 o Certificate Data (variable length) - Actual encoding of 2624 certificate data. The type of certificate is indicated 2625 by the Certificate Encoding field. 2627 The payload type for the Certificate Payload is six (6). 2629 Specific syntax is for some of the certificate type codes above is 2630 not defined in this document. The types whose syntax is defined in 2631 this document are: 2633 X.509 Certificate - Signature (4) contains a BER encoded X.509 2634 certificate. 2636 Certificate Revocation List (7) contains a BER encoded X.509 2637 certificate revocation list. 2639 Raw RSA Key (11) contains a PKCS #1 encoded RSA key. 2641 Hash and URL of PKIX certificate (12) contains a 20 octet SHA-1 2642 hash of a PKIX certificate followed by a variable length URL that 2643 resolves to the BER encoded certificate itself. 2645 Hash and URL of PKIX bundle (13) contains a 20 octet SHA-1 hash of 2646 a PKIX certificate bundle followed by a variable length URL the 2647 resolves to the BER encoded certificate bundle itself. The bundle 2648 is a BER encoded SEQUENCE of certificates and CRLs. 2650 Implementations MUST be capable of being configured to send and 2651 accept up to four X.509 certificates in support of authentication. 2652 Implementations SHOULD be capable of being configured to send and 2653 accept Raw RSA keys and the two Hash and URL formats. If multiple 2654 certificates are sent, the first certificate MUST contain the public 2655 key used to sign the AUTH payload. 2657 3.7 Certificate Request Payload 2659 The Certificate Request Payload, denoted CERTREQ in this memo, 2660 provides a means to request preferred certificates via IKE and can 2661 appear in the second and/or third message of the initial exchanges. 2662 Certificate Request payloads SHOULD be included in an exchange 2663 whenever the peer may have multiple certificates, some of which might 2664 be trusted while others are not or when multiple formats might be 2665 acceptable. If multiple root CAs are trusted, then multiple 2666 Certificate Request payloads SHOULD be transmitted. 2668 Empty (zero length) CA names MUST NOT be generated and SHOULD be 2669 ignored. 2671 The Certificate Request Payload is defined as follows: 2673 1 2 3 2674 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 2675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2676 ! Next Payload !C! RESERVED ! Payload Length ! 2677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2678 ! Cert Encoding ! ! 2679 +-+-+-+-+-+-+-+-+ ! 2680 ~ Certification Authority ~ 2681 ! ! 2682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2684 Figure 13: Certificate Request Payload Format 2686 o Certificate Encoding (1 octet) - Contains an encoding of the type 2687 or format of certificate requested. Values are listed in section 2688 3.6. 2690 o Certification Authority (variable length) - Contains an encoding 2691 of an acceptable certification authority for the type of 2692 certificate requested. 2694 The payload type for the Certificate Request Payload is seven (7). 2696 The Certificate Encoding field has the same values as those defined 2697 in section 3.6. The value field contains an indicator of trusted 2698 authorities for this certificate type. For certificate encoding four 2699 (4) (X.509 signing certificate), the CA value is a concatenated list 2700 of SHA-1 hashes of the public keys of trusted root CAs. 2702 Note that the term "Certificate Request" is somewhat misleading, in 2703 that values other than certificates are defined in a "Certificate" 2704 payload and requests for those values can be present in a Certificate 2705 Request Payload. 2707 The Certificate Request Payload is processed by inspecting the "Cert 2708 Encoding" field to determine whether the processor has any 2709 certificates of this type. If so the "Certification Authority" field 2710 is inspected to determine if the processor has any certificates which 2711 can be validated up to the specified certification authority. This 2712 can be a chain of certificates. If a certificate exists which 2713 satisfies the criteria specified in the Certificate Request Payload 2714 it MUST be sent back to the certificate requestor; if a certificate 2715 chain exists which goes back to the certification authority specified 2716 in the request the entire chain SHOULD be sent back to the 2717 certificate requestor. If no certificates exist then no further 2718 processing is performed-- this is not an error condition of the 2719 protocol. There may be cases where there is a preferred CA, but an 2720 alternate might be acceptable (perhaps after prompting a human 2721 operator). 2723 3.8 Authentication Payload 2725 The Authentication Payload, denoted AUTH in this memo, contains data 2726 used for authentication purposes. The syntax of the Authentication 2727 data varies according the the Auth Method as specified below. 2729 The Authentication Payload is defined as follows: 2731 1 2 3 2732 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2734 ! Next Payload !C! RESERVED ! Payload Length ! 2735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2736 ! Auth Method ! RESERVED ! 2737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2738 ! ! 2739 ~ Authentication Data ~ 2740 ! ! 2741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2743 Figure 14: Authentication Payload Format 2745 o Auth Method (1 octet) - Specifies the method of authentication 2746 used. Values defined are: 2748 RSA Digital Signature (1) - Computed as specified in section 2749 2.15 using an RSA private key over a PKCS#1 padded hash. 2751 Shared Key Message Integrity Code (2) - Computed as specified in 2752 section 2.15 using the shared key associated with the identity 2753 in the ID payload and the negotiated prf function 2755 DSS Digital Signature (3) - Computed as specified in section 2756 2.15 using a DSS private key over a SHA-1 hash. 2758 The values 0 and 4-200 are reserved to IANA. The values 201-255 2759 are available for private use. 2761 o Authentication Data (variable length) - see section 2.15. 2763 The payload type for the Authentication Payload is nine (9). 2765 3.9 Nonce Payload 2767 The Nonce Payload, denoted Ni and Nr in this memo for the Initiator's 2768 and Responder's nonce respectively, contains random data used to 2769 guarantee liveness during an exchange and protect against replay 2770 attacks. 2772 The Nonce Payload is defined as follows: 2774 1 2 3 2775 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 2776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2777 ! Next Payload !C! RESERVED ! Payload Length ! 2778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2779 ! ! 2780 ~ Nonce Data ~ 2781 ! ! 2782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2784 Figure 15: Nonce Payload Format 2786 o Nonce Data (variable length) - Contains the random data generated 2787 by the transmitting entity. 2789 The payload type for the Nonce Payload is ten (10). 2791 The size of a Nonce MUST be between 8 and 256 octets inclusive. Nonce 2792 values MUST NOT be reused. 2794 3.10 Notify Payload 2796 The Notify Payload, denoted N in this document, is used to transmit 2797 informational data, such as error conditions and state transitions, 2798 to an IKE peer. A Notify Payload may appear in a response message 2799 (usually specifying why a request was rejected), in an INFORMATIONAL 2800 Exchange (to report an error not in an IKE request), or in any other 2801 message to indicate sender capabilities or to modify the meaning of 2802 the request. 2804 The Notify Payload is defined as follows: 2806 1 2 3 2807 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 2808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2809 ! Next Payload !C! RESERVED ! Payload Length ! 2810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2811 ! S_Protocol_ID ! SPI Size ! Notify Message Type ! 2812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2813 ! ! 2814 ~ Security Parameter Index (SPI) ~ 2815 ! ! 2816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2817 ! ! 2818 ~ Notification Data ~ 2819 ! ! 2820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2822 Figure 16: Notification Payload Format 2824 o SECURITY_PROTOCOL_ID (1 octet) - Specifies the protocol about 2825 which 2826 this notification is being sent. For IKE_SA notifications, 2827 this field MUST be one (1). For notifications 2828 concerning IPsec SAs this field will contain either (2) 2829 to indicate AH or (3) to indicate ESP. For notifications 2830 for which no protocol ID is relevant, this field MUST be 2831 sent as zero and MUST be ignored. All other values for this 2832 field are reserved to IANA for future assignment. 2834 o SPI Size (1 octet) - Length in octets of the SPI as defined by 2835 the SECURITY_PROTOCOL_ID or zero if no SPI is applicable. For a 2836 notification concerning the IKE_SA, the SPI Size MUST be zero. 2838 o Notify Message Type (2 octets) - Specifies the type of 2839 notification message. 2841 o SPI (variable length) - Security Parameter Index. 2843 o Notification Data (variable length) - Informational or error data 2844 transmitted in addition to the Notify Message Type. Values for 2845 this field are message specific, see below. 2847 The payload type for the Notification Payload is eleven (11). 2849 3.10.1 Notify Message Types 2851 Notification information can be error messages specifying why an SA 2852 could not be established. It can also be status data that a process 2853 managing an SA database wishes to communicate with a peer process. 2854 The table below lists the Notification messages and their 2855 corresponding values. The number of different error statuses was 2856 greatly reduced from IKE V1 both for simplication and to avoid giving 2857 configuration information to probers. 2859 Types in the range 0 - 16383 are intended for reporting errors. An 2860 implementation receiving a Notify payload with one of these types 2861 that it does not recognise in a response MUST assume that the 2862 corresponding request has failed entirely. Unrecognised error types 2863 in a request and status types in a request or response MUST be 2864 ignored except that they SHOULD be logged. 2866 Notify payloads with status types MAY be added to any message and 2867 MUST be ignored if not recognised. They are intended to indicate 2868 capabilities, and as part of SA negotiation are used to negotiate 2869 non-cryptographic parameters. 2871 NOTIFY MESSAGES - ERROR TYPES Value 2872 ----------------------------- ----- 2873 UNSUPPORTED_CRITICAL_PAYLOAD 1 2875 Sent if the payload has the "critical" bit set and the 2876 payload type is not recognised. Notification Data contains 2877 the one octet payload type. 2879 INVALID_IKE_SPI 4 2881 Indicates an IKE message was received with an unrecognized 2882 destination SPI. This usually indicates that the recipient 2883 has rebooted and forgotten the existence of an IKE_SA. 2885 INVALID_MAJOR_VERSION 5 2887 Indicates the recipient cannot handle the version of IKE 2888 specified in the header. The closest version number that the 2889 recipient can support will be in the reply header. 2891 INVALID_SYNTAX 7 2893 Indicates the IKE message was received was invalid because 2894 some type, length, or value was out of range or because the 2895 request was rejected for policy reasons. To avoid a denial 2896 of service attack using forged messages, this status may 2897 only be returned for and in an encrypted packet if the 2898 MESSAGE_ID and cryptographic checksum were valid. To avoid 2899 leaking information to someone probing a node, this status 2900 MUST be sent in response to any error not covered by one of 2901 the other status codes. To aid debugging, more detailed 2902 error information SHOULD be written to a console or log. 2904 INVALID_MESSAGE_ID 9 2906 Sent when an IKE MESSAGE_ID outside the supported window is 2907 received. This Notify MUST NOT be sent in a response; the 2908 invalid request MUST NOT be acknowledged. Instead, inform 2909 the other side by initiating an INFORMATIONAL exchange with 2910 Notification data containing the four octet invalid 2911 MESSAGE_ID. Sending this notification is optional and if 2912 sent MUST be rate limited. 2914 INVALID_SPI 11 2916 MAY be sent in an IKE INFORMATIONAL Exchange when a node 2917 receives an ESP or AH packet with an invalid SPI. The 2918 Notification Data contains the SPI of the invalid packet. 2919 This usually indicates a node has rebooted and forgotten an 2920 SA. If this Informational Message is sent outside the 2921 context of an IKE_SA, it should only be used by the 2922 recipient as a "hint" that something might be wrong (because 2923 it could easily be forged). 2925 NO_PROPOSAL_CHOSEN 14 2927 None of the proposed crypto suites was acceptable. 2929 AUTHENTICATION_FAILED 24 2931 Sent in the response to an IKE_AUTH message when for some 2932 reason the authentication failed. There is no associated 2933 data. 2935 SINGLE_PAIR_REQUIRED 34 2937 This error indicates that a CREATE_CHILD_SA request is 2938 unacceptable because the Responder is willing to accept 2939 traffic selectors specifying a single pair of addresses. 2940 The Initiator is expected to respond by requesting an SA for 2941 only the specific traffic he is trying to forward. 2943 NO_ADDITIONAL_SAS 35 2944 This error indicates that a CREATE_CHILD_SA request is 2945 unacceptable because the Responder is unwilling to accept 2946 any more CHILD_SAs on this IKE_SA. Some minimal 2947 implementations may only accept a single CHILD_SA setup in 2948 the context of an initial IKE exchange and reject any 2949 subsequent attempts to add more. 2951 INTERNAL_ADDRESS_FAILURE 36 2952 Indicates an error assigning an internal address (i.e., 2953 INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS) during the 2954 processing of a Configuration Payload by a Responder. If 2955 this error is generated within an IKE_AUTH exchange no 2956 CHILD_SA will be created. 2958 FAILED_CP_REQUIRED 37 2959 Sent by responder in the case where CP(CFG_REQUEST) was 2960 expected but not received, and so is a conflict with locally 2961 configured policy. There is no associated data. 2963 TS_UNACCEPTABLE 38 2964 Indicates that none of the addresses/protocols/ports in the 2965 supplied traffic selectors is acceptable. 2967 RESERVED TO IANA - Errors 39 - 8191 2969 Private Use - Errors 8192 - 16383 2971 NOTIFY MESSAGES - STATUS TYPES Value 2972 ------------------------------ ----- 2974 RESERVED TO IANA - STATUS 16384 - 24577 2976 INITIAL_CONTACT 24578 2978 This notification asserts that this IKE_SA is the only 2979 IKE_SA currently active between the authenticated 2980 identities. It MAY be sent when an IKE_SA is established 2981 after a crash, and the recipient MAY use this information to 2982 delete any other IKE_SAs it has to the same authenticated 2983 identity without waiting for a timeout. This notification 2984 MUST NOT be sent by an entity that may be replicated (e.g. a 2985 roaming user's credentials where the user is allowed to 2986 connect to the corporate firewall from two remote systems at 2987 the same time). 2989 SET_WINDOW_SIZE 24579 2990 This notification asserts that the sending endpoint is 2991 capable of keeping state for multiple outstanding exchanges, 2992 permitting the recipient to send multiple requests before 2993 getting a response to the first. The data associated with a 2994 SET_WINDOW_SIZE notification MUST be 4 octets long and 2995 contain the big endian represention of the number of 2996 messages the sender promises to keep. Window size is always 2997 one until the initial exchanges complete. 2999 ADDITIONAL_TS_POSSIBLE 24580 3001 This notification asserts that the sending endpoint narrowed 3002 the proposed traffic selectors but that other traffic 3003 selectors would also have been acceptable, though only in a 3004 separate SA. There is no data associated with this notify 3005 type. It may only be sent as an additional payload in a 3006 message including accepted TSs. 3008 IPCOMP_SUPPORTED 24581 3010 This notification may only be included in a message 3011 containing an SA payload negotiating a CHILD_SA and 3012 indicates a willingness by its sender to use IPcomp on this 3013 SA. The data associated with this notification includes a 3014 two octet IPcomp CPI followed by a one octet transform ID 3015 optionally followed by attributes whose length and format is 3016 defined by that transform ID. A message proposing an SA may 3017 contain multiple IPCOMP_SUPPORTED notifications to indicate 3018 multiple supported algorithms. A message accepting an SA may 3019 contain at most one. 3021 The transform IDs currently defined are: 3023 NAME NUMBER DEFINED IN 3024 ----------- ------ ----------- 3025 RESERVED 0 3026 IPCOMP_OUI 1 3027 IPCOMP_DEFLATE 2 RFC 2394 3028 IPCOMP_LZS 3 RFC 2395 3030 values 4-240 are reserved to IANA. Values 241-255 are 3031 for private use among mutually consenting parties. 3033 NAT_DETECTION_SOURCE_IP 24582 3035 This notification is used to by its recipient to determine 3036 whether the source is behind a NAT box. The data associated 3037 with this notification is a SHA-1 digest of the SPIs, IP 3038 address and port on which this packet was sent. There MAY 3039 be multiple notify payloads of this type in a message if the 3040 sender does not know which of several network attachments 3041 will be used to send the packet. The recipient of this 3042 notification MAY compare the supplied value to a SHA-1 hash 3043 of the SPIs, source IP address and port and if they don't 3044 match it SHOULD enable NAT traversal (see section 2.23). 3045 Alternately, it MAY reject the connection attempt if NAT 3046 traversal is not supported. 3048 NAT_DETECTION_DESTINATION_IP 24583 3050 This notification is used to by its recipient to determine 3051 whether it is behind a NAT box. The data associated with 3052 this notification is a SHA-1 digest of the SPIs, IP address 3053 and port to which this packet was sent. The recipient of 3054 this notification MAY compare the supplied value to a hash 3055 of the SPIs, destination IP address and port and if they 3056 don't match it SHOULD invoke NAT traversal (see section 3057 2.23). If this check fails, it means that this end is behind 3058 a NAT and that therefore this end should perform NAT 3059 specific processing. Alternately, it MAY reject the 3060 connection attempt if NAT traversal is not supported. 3062 COOKIE 24584 3064 This notification MAY be included in an IKE_SA_INIT 3065 response. It indicates that the request should be retried 3066 with a copy of this notification as the first payload. This 3067 notification MUST be included in an IKE_SA_INIT request 3068 retry if a COOKIE notification was included in the initial 3069 response. The data associated with this notification MUST 3070 be between 1 and 64 octets in length (inclusive). 3072 USE_TRANSPORT_MODE 24585 3074 This notification MAY be included in a request message that 3075 also includes an SA requesting a CHILD_SA. It requests that 3076 the CHILD_SA use transport mode rather than tunnel mode for 3077 the SA created. If the request is accepted, the response 3078 MUST also include a notification of type USE_TRANSPORT_MODE. 3079 If the responder declines the request, the CHILD_SA can 3080 still be established, but will use tunnel mode. If this is 3081 unacceptable to the initiator, the initiator MUST delete the 3082 SA. Note: except when using this option to negotiate 3083 transport mode, all CHILD_SAs will use tunnel mode. 3085 HTTP_CERT_LOOKUP_SUPPORTED 24586 3086 This notification MAY be included any message that can 3087 include a CERTREQ payload and indicates that the sender is 3088 capable of looking up certificates based on an HTTP-based 3089 URL (and hence presumeably would prefer to receive 3090 certificate specifications in that format). 3092 RESERVED TO IANA - STATUS 24587 - 40959 3094 Private Use - STATUS 40960 - 65535 3096 3.11 Delete Payload 3098 The Delete Payload, denoted D in this memo, contains a protocol 3099 specific security association identifier that the sender has removed 3100 from its security association database and is, therefore, no longer 3101 valid. Figure 17 shows the format of the Delete Payload. It is 3102 possible to send multiple SPIs in a Delete payload, however, each SPI 3103 MUST be for the same protocol. Mixing of Protocol Identifiers MUST 3104 NOT be performed in a the Delete payload. It is permitted, however, 3105 to include multiple Delete payloads in a single INFORMATIONAL 3106 Exchange where each Delete payload lists SPIs for a different 3107 protocol. 3109 Deletion of the IKE_SA is indicated by a SECURITY_PROTOCOL_ID of 1 3110 (IKE) but no SPIs. Deletion of a CHILD_SA, such as ESP or AH, will 3111 contain the SECURITY_PROTOCOL_ID of that protocol (2 for AH, 3 for 3112 ESP) and the SPI is the SPI the sending endpoint would expect in 3113 inbound ESP or AH packets. 3115 The Delete Payload is defined as follows: 3117 1 2 3 3118 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 3119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3120 ! Next Payload !C! RESERVED ! Payload Length ! 3121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3122 ! S_PROTOCOL_ID ! SPI Size ! # of SPIs ! 3123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3124 ! ! 3125 ~ Security Parameter Index(es) (SPI) ~ 3126 ! ! 3127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3129 Figure 17: Delete Payload Format 3131 o SECURITY_PROTOCOL_ID (1 octet) - Must be 1 for an IKE_SA, 2 3132 for AH, or 3 for ESP. 3134 o SPI Size (1 octet) - Length in octets of the SPI as defined by 3135 the SECURITY_PROTOCOL_ID. Zero for IKE (SPI is in message 3136 header) or four for AH and ESP. 3138 o # of SPIs (2 octets) - The number of SPIs contained in the Delete 3139 payload. The size of each SPI is defined by the SPI Size field. 3141 o Security Parameter Index(es) (variable length) - Identifies the 3142 specific security association(s) to delete. The length of this 3143 field is determined by the SPI Size and # of SPIs fields. 3145 The payload type for the Delete Payload is twelve (12). 3147 3.12 Vendor ID Payload 3149 The Vendor ID Payload contains a vendor defined constant. The 3150 constant is used by vendors to identify and recognize remote 3151 instances of their implementations. This mechanism allows a vendor 3152 to experiment with new features while maintaining backwards 3153 compatibility. 3155 A Vendor ID payload MAY announce that the sender is capable to 3156 accepting certain extensions to the protocol, or it MAY simply 3157 identify the implementation as an aid in debugging. If parameter 3158 values "reserved for use by consenting parties" are used, they must 3159 be preceded by a Vendor ID payload that disambiguates them. A Vendor 3160 ID payload MUST NOT change the interpretation of any information 3161 defined in this specification (i.e. it MUST be non-critical). 3162 Multiple Vendor ID payloads MAY be sent. An implementation is NOT 3163 REQUIRED to send any Vendor ID payload at all. 3165 A Vendor ID payload may be sent as part of any message. Reception of 3166 a familiar Vendor ID payload allows an implementation to make use of 3167 Private USE numbers described throughout this memo-- private 3168 payloads, private exchanges, private notifications, etc. Unfamiliar 3169 Vendor IDs MUST be ignored. 3171 Writers of Internet-Drafts who wish to extend this protocol MUST 3172 define a Vendor ID payload to announce the ability to implement the 3173 extension in the Internet-Draft. It is expected that Internet-Drafts 3174 which gain acceptance and are standardized will be given "magic 3175 numbers" out of the Future Use range by IANA and the requirement to 3176 use a Vendor ID will go away. 3178 The Vendor ID Payload fields are defined as follows: 3180 1 2 3 3181 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 3182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3183 ! Next Payload !C! RESERVED ! Payload Length ! 3184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3185 ! ! 3186 ~ Vendor ID (VID) ~ 3187 ! ! 3188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3190 Figure 18: Vendor ID Payload Format 3192 o Vendor ID (variable length) - It is the responsibility of 3193 the person choosing the Vendor ID to assure its uniqueness 3194 in spite of the absence of any central registry for IDs. 3195 Good practice is to include a company name, a person name 3196 or some such. If you want to show off, you might include 3197 the latitude and longitude and time where you were when 3198 you chose the ID and some random input. A message digest 3199 of a long unique string is preferable to the long unique 3200 string itself. 3202 The payload type for the Vendor ID Payload is thirteen (13). 3204 3.13 Traffic Selector Payload 3206 The Traffic Selector Payload, denoted TS in this memo, allows peers 3207 to identify packet flows for processing by IPsec security services. 3208 The Traffic Selector Payload consists of the IKE generic header 3209 followed by individual traffic selectors as follows: 3211 1 2 3 3212 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 3213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3214 ! Next Payload !C! RESERVED ! Payload Length ! 3215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3216 ! Number of TSs ! RESERVED ! 3217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3218 ! ! 3219 ~ ~ 3220 ! ! 3221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3223 Figure 19: Traffic Selectors Payload Format 3225 o Number of TSs (1 octet) - Number of traffic selectors 3226 being provided. 3228 o RESERVED - This field MUST be sent as zero and MUST be ignored. 3230 o Traffic Selectors (variable length) - one or more individual 3231 traffic selectors. 3233 The length of the Traffic Selector payload includes the TS header and 3234 all the traffic selectors. 3236 The payload type for the Traffic Selector payload is fourteen (14) 3237 for TSi and nineteen (19) for TSr. 3239 3.13.1 Traffic Selector 3241 1 2 3 3242 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 3243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3244 ! TS Type ! Protocol_ID | Selector Length | 3245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3246 | Start_Port | End_Port | 3247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3248 ! ! 3249 ~ Starting Address ~ 3250 ! ! 3251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3252 ! ! 3253 ~ Ending Address ~ 3254 ! ! 3255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3257 Figure 20: Traffic Selector 3259 o TS Type (one octet) - Specifies the type of traffic selector. 3261 o Protocol ID (1 octet) - Value specifying an associated IP 3262 protocol ID (e.g. UDP/TCP). A value of zero means that the 3263 Protocol ID is not relevant to this traffic selector-- 3264 the SA can carry all protocols. 3266 o Selector Length - Specifies the length of this Traffic 3267 Selector Substructure including the header. 3269 o Start_Port (2 octets) - Value specifying the smallest port 3270 number allowed by this Traffic Selector. For protocols for 3271 which port is undefined, or if all ports are allowed by 3272 this Traffic Selector, this field MUST be zero. 3274 o End_Port (2 octets) - Value specifying the largest port 3275 number allowed by this Traffic Selector. For protocols for 3276 which port is undefined, or it all ports are allowed by 3277 this Traffic Selector, this field MUST be 65535. 3279 o Starting Address - The smallest address included in this 3280 Traffic Selector (length determined by TS type). 3282 o Ending Address - The largest address included in this 3283 Traffic Selector (length determined by TS type). 3285 The following table lists the assigned values for the Traffic 3286 Selector Type field and the corresponding Address Selector Data. 3288 TS Type Value 3289 ------- ----- 3290 RESERVED 0 3292 TS_IPV4_ADDR_RANGE 7 3294 A range of IPv4 addresses, represented by two four (4) octet 3295 values. The first value is the beginning IPv4 address 3296 (inclusive) and the second value is the ending IPv4 address 3297 (inclusive). All addresses falling between the two specified 3298 addresses are considered to be within the list. 3300 TS_IPV6_ADDR_RANGE 8 3302 A range of IPv6 addresses, represented by two sixteen (16) 3303 octet values. The first value is the beginning IPv6 address 3304 (inclusive) and the second value is the ending IPv6 address 3305 (inclusive). All addresses falling between the two specified 3306 addresses are considered to be within the list. 3308 3.14 Encrypted Payload 3310 The Encrypted Payload, denoted SK{...} in this memo, contains other 3311 payloads in encrypted form. The Encrpted Payload, if present in a 3312 message, must be the last payload in the message. Often, it is the 3313 only payload in the message. 3315 The algorithms for encryption and integrity protection are negotiated 3316 during IKE_SA setup, and the keys are computed as specified in 3317 sections 2.14 and 2.18. 3319 The encryption and integrity protection algorithms are modelled after 3320 the ESP algorithms described in RFCs 2104, 2406, 2451. This document 3321 completely specifies the cryptographic processing of IKE data, but 3322 those documents should be consulted for design rationale. We assume a 3323 block cipher with a fixed block size and an integrity check algorithm 3324 that computes a fixed length checksum over a variable size message. 3326 The Payload Type for an Encrypted payload is fifteen (15). The 3327 Encrypted Payload consists of the IKE generic header followed by 3328 individual fields as follows: 3330 1 2 3 3331 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 3332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3333 ! Next Payload !C! RESERVED ! Payload Length ! 3334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3335 ! Initialization Vector ! 3336 ! (length is block size for encryption algorithm) ! 3337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3338 ! Encrypted IKE Payloads ! 3339 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3340 ! ! Padding (0-255 octets) ! 3341 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 3342 ! ! Pad Length ! 3343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3344 ~ Integrity Checksum Data ~ 3345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3347 Figure 21: Encrypted Payload Format 3349 o Next Payload - The payload type of the first embedded payload. 3350 Since the Encrypted payload must be last in a message, there 3351 is no need to specify a payload type for a payload beyond it. 3353 o Payload Length - Includes the lengths of the IV, Padding, and 3354 Authentication data. 3356 o Initialization Vector - A randomly chosen value whose length 3357 is equal to the block length of the underlying encryption 3358 algorithm. Recipients MUST accept any value. Senders SHOULD 3359 either pick this value pseudo-randomly and independently for 3360 each message or use the final ciphertext block of the previous 3361 message sent. Senders MUST NOT use the same value for each 3362 message, use a sequence of values with low hamming distance 3363 (e.g. a sequence number), or use ciphertext from a received 3364 message. 3366 o IKE Payloads are as specified earlier in this section. This 3367 field is encrypted with the negotiated cipher. 3369 o Padding may contain any value chosen by the sender, and must 3370 have a length that makes the combination of the Payloads, the 3371 Padding, and the Pad Length to be a multiple of the encryption 3372 block size. This field is encrypted with the negotiated 3373 cipher. 3375 o Pad Length is the length of the Padding field. The sender 3376 SHOULD set the Pad Length to the minimum value that makes 3377 the combination of the Payloads, the Padding, and the Pad 3378 Length a multiple of the block size, but the recipient MUST 3379 accept any length that results in proper alignment. This 3380 field is encrypted with the negotiated cipher. 3382 o Integrity Checksum Data is the cryptographic checksum of 3383 the entire message starting with the Fixed IKE Header 3384 through the Pad Length. The checksum MUST be computed over 3385 the encrypted message. 3387 3.15 Configuration Payload 3389 The Configuration payload, denoted CP in this document, is used to 3390 exchange configuration information between IKE peers. Currently, the 3391 only defined uses for this exchange is for an IRAC to request an 3392 internal IP address from an IRAS or for either party to request 3393 version information from the other, but this payload is intended as a 3394 likely place for future extensions. 3396 Configuration payloads are of type CFG_REQUEST/CFG_REPLY or 3397 CFG_SET/CFG_ACK (see CFG Type in the payload description below). 3398 CFG_REQUEST and CFG_SET payloads may optionally be added to any IKE 3399 request. The IKE response MUST include either a corresponding 3400 CFG_REPLY or CFG_ACK or a Notify payload with an error code 3401 indicating why the request could not be honored. An exception is that 3402 a minimal implementation MAY ignore all CFG_REQUEST and CFG_SET 3403 payloads, so a response message without a corresponding CFG_REPLY or 3404 CFG_ACK MUST be accepted as an indication that the request was not 3405 supported. 3407 "CFG_REQUEST/CFG_REPLY" allows an IKE endpoint to request information 3408 from its peer. If an attribute in the CFG_REQUEST Configuration 3409 Payload is not zero length it is taken as a suggestion for that 3410 attribute. The CFG_REPLY Configuration Payload MAY return that 3411 value, or a new one. It MAY also add new attributes and not include 3412 some requested ones. Requestors MUST ignore returned attributes that 3413 they do not recognise. 3415 Some attributes MAY be multi-valued, in which case multiple attribute 3416 values of the same type are sent and/or returned. Generally, all 3417 values of an attribute are returned when the attribute is requested. 3419 For some attributes (in this version of the specification only 3420 internal addresses), multiple requests indicates a request that 3421 multiple values be assigned. For these attributes, the number of 3422 values returned SHOULD NOT exceed the number requested. 3424 If the data type requested in a CFG_REQUEST is not recognised or not 3425 supported, the responder MUST NOT return an error code but rather 3426 MUST either send a CFG_REPLY which MAY be empty or a reply not 3427 containing a CFG_REPLY payload at all. Error returns are reserved for 3428 cases where the request is recognised but cannot be performed as 3429 requested or the request is badly formatted. 3431 "CFG_SET/CFG_ACK" allows an IKE endpoint to push configuration data 3432 to its peer. In this case the CFG_SET Configuration Payload contains 3433 attributes the initiator wants its peer to alter. The responder MUST 3434 return a Configuration Payload if it accepted any of the 3435 configuration data and it MUST contain the attributes that the 3436 responder accepted with zero length data. Those attributes that it 3437 did not accept MUST NOT be in the CFG_ACK Configuration Payload. If 3438 no attributes were accepted, the responder MUST return either an 3439 empty CFG_ACK payload or a response message without a CFG_ACK 3440 payload. There are currently no defined uses for the CFG_SET/CFG_ACK 3441 exchange, though they may be used in connection with extensions based 3442 on Vendor IDs. An minimal implementation of this specification MAY 3443 ignore CFG_SET payloads. 3445 Extensions via the CP payload SHOULD NOT be used for general purpose 3446 management. Its main intent is to provide a bootstrap mechanism to 3447 exchange information within IPSec from IRAS to IRAC. While it MAY be 3448 useful to use such a method to exchange information between some 3449 Security Gateways (SGW) or small networks, existing management 3450 protocols such as DHCP [DHCP], RADIUS [RADIUS], SNMP or LDAP [LDAP] 3451 should be preferred for enterprise management as well as subsequent 3452 information exchanges. 3454 The Configuration Payload is defined as follows: 3456 1 2 3 3457 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 3458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3459 ! Next Payload !C! RESERVED ! Payload Length ! 3460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3461 ! CFG Type ! RESERVED ! 3462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3463 ! ! 3464 ~ Configuration Attributes ~ 3465 ! ! 3466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3468 Figure 22: Configuration Payload Format 3470 The payload type for the Configuration Payload is 16. 3472 o CFG Type (1 octet) - The type of exchange represented by the 3473 Configuration Attributes. 3475 CFG Type Value 3476 =========== ===== 3477 RESERVED 0 3478 CFG_REQUEST 1 3479 CFG_REPLY 2 3480 CFG_SET 3 3481 CFG_ACK 4 3483 values 5-127 are reserved to IANA. Values 128-255 are for private 3484 use among mutually consenting parties. 3486 o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored. 3488 o Configuration Attribute (variable length) - These are type length 3489 values specific to the Configuration Payload and are defined 3490 below. There may be zero or more Configuration Attributes in this 3491 payload. 3493 3.15.1 Configuration Attributes 3495 1 2 3 3496 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 3497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3498 !R| Attribute Type ! Length | 3499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3500 | | 3501 ~ Value ~ 3502 | | 3503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3505 Figure 23: Configuration Attribute Format 3507 o Reserved (1 bit) - This bit MUST be set to zero and MUST be 3508 ignored. 3510 o Attribute Type (7 bits) - A unique identifier for each of the 3511 Configuration Attribute Types. 3513 o Length (2 octets) - Length in octets of Value. 3515 o Value (0 or more octets) - The variable length value of this 3516 Configuration Attribute. 3518 The following attribute types have been defined: 3520 Multi- 3521 Attribute Type Value Valued Length 3522 ======================= ===== ====== ================== 3523 RESERVED 0 3524 INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets 3525 INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets 3526 INTERNAL_IP4_DNS 3 YES 0 or 4 octets 3527 INTERNAL_IP4_NBNS 4 YES 0 or 4 octets 3528 INTERNAL_ADDRESS_EXPIRY 5 NO 0 or 4 octets 3529 INTERNAL_IP4_DHCP 6 YES 0 or 4 octets 3530 APPLICATION_VERSION 7 NO 0 or more 3531 INTERNAL_IP6_ADDRESS 8 YES* 0 or 16 octets 3532 INTERNAL_IP6_NETMASK 9 NO 0 or 16 octets 3533 INTERNAL_IP6_DNS 10 YES 0 or 16 octets 3534 INTERNAL_IP6_NBNS 11 YES 0 or 16 octets 3535 INTERNAL_IP6_DHCP 12 YES 0 or 16 octets 3536 INTERNAL_IP4_SUBNET 13 NO 0 or 8 octets 3537 SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 3538 INTERNAL_IP6_SUBNET 15 NO 17 octets 3540 * These attributes may be multi-valued on return only if 3541 multiple values were requested. 3543 Types 16-16383 are reserved to IANA. Values 16384-32767 are for 3544 private use among mutually consenting parties. 3546 o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the 3547 internal network, sometimes called a red node address or 3548 private address and MAY be a private address on the Internet. 3549 Multiple internal addresses MAY be requested by requesting 3550 multiple internal address attributes. The responder MAY only 3551 send up to the number of addresses requested. 3553 The requested address is valid until the expiry time defined 3554 with the INTERNAL_ADDRESS EXPIRY attribute or there are no 3555 IKE_SAs between the peers. 3557 o INTERNAL_IP4_NETMASK, INTERNAL_IP6_NETMASK - The internal 3558 network's netmask. Only one netmask is allowed in the request 3559 and reply messages (e.g. 255.255.255.0) and it MUST be used 3560 only with an INTERNAL_ADDRESS attribute. 3562 o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a 3563 DNS server within the network. Multiple DNS servers MAY be 3564 requested. The responder MAY respond with zero or more DNS 3565 server attributes. 3567 o INTERNAL_IP4_NBNS, INTERNAL_IP6_NBNS - Specifies an address of 3568 a NetBios Name Server (WINS) within the network. Multiple NBNS 3569 servers MAY be requested. The responder MAY respond with zero 3570 or more NBNS server attributes. 3572 o INTERNAL_ADDRESS_EXPIRY - Specifies the number of seconds that 3573 the host can use the internal IP address. The host MUST renew 3574 the IP address before this expiry time. Only one of these 3575 attributes MAY be present in the reply. 3577 o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to 3578 send any internal DHCP requests to the address contained within 3579 the attribute. Multiple DHCP servers MAY be requested. The 3580 responder MAY respond with zero or more DHCP server attributes. 3582 o APPLICATION_VERSION - The version or application information of 3583 the IPSec host. This is a string of printable ASCII characters 3584 that is NOT null terminated. 3586 o INTERNAL_IP4_SUBNET - The protected sub-networks that this 3587 edge-device protects. This attribute is made up of two fields; 3588 the first being an IP address and the second being a netmask. 3590 Multiple sub-networks MAY be requested. The responder MAY 3591 respond with zero or more sub-network attributes. 3593 o SUPPORTED_ATTRIBUTES - When used within a Request, this 3594 attribute must be zero length and specifies a query to the 3595 responder to reply back with all of the attributes that it 3596 supports. The response contains an attribute that contains a 3597 set of attribute identifiers each in 2 octets. The length 3598 divided by 2 (octets) would state the number of supported 3599 attributes contained in the response. 3601 o INTERNAL_IP6_SUBNET - The protected sub-networks that this 3602 edge-device protects. This attribute is made up of two fields; 3603 the first being a 16 octet IPv6 address the second being a one 3604 octet prefix-mask as defined in [ADDRIPV6]. Multiple 3605 sub-networks MAY be requested. The responder MAY respond with 3606 zero or more sub-network attributes. 3608 Note that no recommendations are made in this document how an 3609 implementation actually figures out what information to send in a 3610 reply. i.e. we do not recommend any specific method of an IRAS 3611 determining which DNS server should be returned to a requesting 3612 IRAC. 3614 3.16 Extended Authentication Protocol (EAP) Payload 3616 The Extended Authentication Protocol Payload, denoted EAP in this 3617 memo, allows IKE SAs to be authenticated using the protocol defined 3618 in RFC 2284 [EAP] and subsequent extensions to that protocol. The 3619 full set of acceptable values for the payload are defined elsewhere, 3620 but a short summary of RFC 2284 is included here to make this 3621 document stand alone in the common cases. 3623 1 2 3 3624 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 3625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3626 ! Next Payload !C! RESERVED ! Payload Length ! 3627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3628 ! ! 3629 ~ EAP Message ~ 3630 ! ! 3631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3633 Figure 24: EAP Payload Format 3635 The payload type for an EAP Payload is 17. 3637 1 2 3 3638 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 3639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3640 ! Code ! Identifier ! Length ! 3641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3642 ! Type ! Type_Data... 3643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 3645 Figure 25: EAP Message Format 3647 o Code (one octet) indicates whether this message is a 3648 Request (1), Response (2), Success (3), or Failure (4). 3650 o Identifier (one octet) is used in PPP to distinguish replayed 3651 messages from repeated ones. Since in IKE, EAP runs over a 3652 reliable protocol, it serves no function here. In a response 3653 message this octet MUST be set to match the identifier in the 3654 corresponding request. In other messages, this field MAY 3655 be set to any value. 3657 o Length (two octets) is the length of the EAP message and MUST 3658 be four less than the Payload Length of the encapsulating 3659 payload. 3661 o Type (one octet) is present only if the Code field is Request 3662 (1) or Response (2). For other types, the EAP message length 3663 MUST be four octets and the Type and Type_Data fields MUST NOT 3664 be present. In a Request (1) message, Type indicates the 3665 data being requested. In a Response (2) message, Type must 3666 either be NAC or match the type of the data requested. The 3667 following types are defined in RFC 2284: 3669 1 Identity 3670 2 Notification 3671 3 NAK (Response Only) 3672 4 MD5-Challenge 3673 5 One-Time Password (OTP) 3674 6 Generic Token Card 3676 o Type_Data (Variable Length) contains data depending on the Code 3677 and Type. In Requests other than MD5-Challenge, this field 3678 contains a prompt to be displayed to a human user. For NAK, it 3679 contains one octet suggesting the form of authentication the 3680 Initiator would prefer to use. For most other responses, it 3681 contains the authentication code typed by the human user. 3683 Note that since IKE passes an indication of initiator identity in 3684 message 3 of the protocol, EAP based prompts for Identity SHOULD NOT 3685 be used. 3687 4 Conformance Requirements 3689 In order to assure that all implementations of IKEv2 can 3690 interoperate, there are MUST support requirements in addition to 3691 those listed elsewhere. Of course, IKEv2 is a security protocol, and 3692 one of its major functions is preventing the bad guys from 3693 interoperating with one's systems. So a particular implementation may 3694 be configured with any of a number of restrictions concerning 3695 algorithms and trusted authorities that will prevent universal 3696 interoperability. 3698 IKEv2 is designed to permit minimal implementations that can 3699 interoperate with all compliant implementations. There are a series 3700 of optional features that can easily be ignored by a particular 3701 implementation if it does not support that feature. Those features 3702 include: 3704 Ability to negotiate SAs through a NAT and tunnel the resulting ESP 3705 SA over UDP. 3707 Ability to request (and respond to a request for) a temporary IP 3708 address on the remote end of a tunnel. 3710 Ability to support various forms of legacy authentication. 3712 Ability to support window sizes greater than one. 3714 Ability to establish multiple ESP and/or AH SAs within a single IKE 3715 SA. 3717 Ability to rekey SAs. 3719 To assure interoperability, all implementations MUST be capable of 3720 parsing all payload types (if only to skip over them) and to ignore 3721 payload types that it does not support unless the critical bit is set 3722 in the payload header. If the critical bit is set in an unsupported 3723 payload header, all implementations MUST reject the messages 3724 containing those payloads. 3726 Every implementation MUST be capable of doing four message 3727 IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, 3728 one for ESP and/or AH). Implementations MAY be initiate-only or 3729 respond-only if appropriate for their platform. Every implementation 3730 MUST be capable of responding to an INFORMATIONAL exchange, but a 3731 minimal implementation MAY respond to any INFORMATIONAL message with 3732 an empty INFORMATIONAL reply. A minimal implementation MAY support 3733 the CREATE_CHILD_SA exchange only in so far as to recognise requests 3734 and reject them with a Notify payload of type NO_ADDITIONAL_SAS. A 3735 minimal implementation need not be able to initiate CREATE_CHILD_SA 3736 or INFORMATIONAL exchanges. When an SA expires (based on either 3737 lifetime or octets passed), and implementation MAY either try to 3738 renew it with a CREATE_CHILD_SA exchange or it MAY delete (close) the 3739 old SA and create a new one. If the responder rejects the 3740 CREATE_CHILD_SA request with a NO_ADDITIONAL_SAS notification, the 3741 implementation MUST be capable of instead closing the old SA and 3742 creating a new one. 3744 Implementations are not required to support requesting temporary IP 3745 addresses or responding to such requests. If an implementation does 3746 support issuing such requests, it MUST include a CP payload in 3747 message 3 containing at least a field of type INTERNAL_IP4_ADDRESS or 3748 INTERNAL_IP6_ADDRESS. All other fields are optional. If an 3749 implementation supports responding to such requests, it MUST parse 3750 the CP payload of type CFG_REQUEST in message 3 and recognise a field 3751 of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports 3752 leasing an address of the appropriate type, it MUST return a CP 3753 payload of type CFG_REPLY containing an address of the requested 3754 type. The responder SHOULD include all of the other related 3755 attributes if it has them. 3757 A minimal responder implementation will ignore the contents of the CP 3758 payload except to determine that it includes an INTERNAL_IP4_ADDRESS 3759 attribute and will respond with the address and other related 3760 attributes regardless of whether the initiator requested them. 3762 A minimal initiator will generate a CP payload containing only an 3763 INTERNAL_IP4_ADDRESS attribute and will parse the response ignoring 3764 attributes it does not know how to use. The only attribute it MUST be 3765 able to process is INTERNAL_ADDRESS_EXPIRY, which it must use to 3766 bound the lifetime of the SA unless it successfully renews the lease 3767 before it expires. Minimal initiators need not be able to request 3768 lease renewals and minimal responders need not respond to them. 3770 For an implementation to be called conforming to this specification, 3771 it MUST be possible to configure it to accept the following: 3773 PKIX Certificates containing and signed by RSA keys of size 1024 or 3774 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, 3775 ID_RFC822_ADDR, or ID_DER_ASN1_DN. 3777 Shared key authentication where the ID passes is any of ID_KEY_ID, 3778 ID_FQDN, or ID_RFC822_ADDR. 3780 Authentication where the responder authenticates using PKIX 3781 Certificates and the initiator authenticates using shared key 3782 authentication. 3784 5 Security Considerations 3786 Repeated re-keying using CREATE_CHILD_SA without PFS leave all SAs 3787 vulnerable to cryptanalysis of a single key or overrun of either 3788 endpoint. Implementers should take note of this fact and set a limit 3789 on CREATE_CHILD_SA exchanges between exponentiations. This memo does 3790 not prescribe such a limit. 3792 The strength of a key derived from a Diffie-Hellman exchange using 3793 any of the groups defined here depends on the inherent strength of 3794 the group, the size of the exponent used, and the entropy provided by 3795 the random number generator used. Due to these inputs it is difficult 3796 to determine the strength of a key for any of the defined groups. 3797 Diffie-Hellman group number two, when used with a strong random 3798 number generator and an exponent no less than 200 bits, is sufficient 3799 for use with 3DES. Groups three through five provide greater 3800 security. Group one is for historic purposes only and does not 3801 provide sufficient strength except for use with DES, which is also 3802 for historic use only. Implementations should make note of these 3803 conservative estimates when establishing policy and negotiating 3804 security parameters. 3806 The strength of all keys are limited by the size of the output of the 3807 negotiated prf function. For this reason, a prf function whose output 3808 is less than 128 bits (e.g. 3DES-CBC) MUST never be used with this 3809 protocol. 3811 Note that these limitations are on the Diffie-Hellman groups 3812 themselves. There is nothing in IKE which prohibits using stronger 3813 groups nor is there anything which will dilute the strength obtained 3814 from stronger groups (limited by the strength of the other algorithms 3815 negotiated including the prf function). In fact, the extensible 3816 framework of IKE encourages the definition of more groups; use of 3817 elliptical curve groups may greatly increase strength using much 3818 smaller numbers. 3820 It is assumed that the Diffie-Hellman exponents in this exchange are 3821 erased from memory after use. In particular, these exponents MUST NOT 3822 be derived from long-lived secrets like the seed to a pseudo-random 3823 generator that is not erased after use. 3825 The security of this protocol is critically dependent on the 3826 randomness of the randomly chosen parameters. These should be 3827 generated by a strong random or properly seeded pseudo-random source 3828 (see [RFC1715]). Implementors should take care to ensure that use of 3829 random numbers for both keys and nonces is engineered in a fashion 3830 that does not undermine the security of the keys. 3832 When using pre-shared keys, a critical consideration is how to assure 3833 the randomness of these secrets. The strongest practice is to ensure 3834 that any pre-shared key contain as much randomness as the strongest 3835 key being negotiated. Deriving a shared secret from a password, name, 3836 or other low entropy source is not secure. These sources are subject 3837 to dictionary and social engineering attacks, among others. 3839 The NAT_DETECTION_*_IP notifications contain a hash of the addresses 3840 and ports in an attempt to hide internal IP addresses behind a NAT 3841 from the IKE peer. As the IPv4 address space is only 32 bits, and it 3842 is usually very sparse, it might be possible for the attacker to find 3843 out the internal address used behind the NAT box by trying all 3844 possible IP-addresses and trying to find the matching hash. The port 3845 numbers are normally fixed to 500, and the SPIs can be extracted from 3846 the packet. This limits the hash calculations down to 2^32. If 3847 educated guess of use of private address space is done, then the 3848 number of hash calculations needed to find out the internal IP 3849 address goes down to the 2^24 + 2 * (2^16). 3850 6 IANA Considerations 3852 This document contains many "magic numbers" to be maintained by the 3853 IANA. This section explains the criteria to be used by the IANA to 3854 assign additional numbers in each of these lists. 3856 Cryptographic Algorithm types, codes, and attributes 3857 Error Codes 3858 Status Codes 3859 IPcomp Transform IDs 3860 Configuration request types 3861 Configuration attribute types 3862 Payload Types 3863 IKE Exchange Types 3865 Values of the Cryptographic Suite-ID define a set of cryptographic 3866 algorithms to be used in an IKE, ESP, or AH SA. Requests for 3867 assignment of new values must be accompanied by a reference to an RFC 3868 that describes how to use these algorithms. 3870 This memo defines four exchange types for use with IKEv2. Requests 3871 for assignment of new exchange types MUST be accompanied by an RFC 3872 which defines the following: 3874 - the purpose of and need for the new exchange. 3875 - the payloads (mandatory and optional) that accompany 3876 messages in the exchange. 3878 - when the exchange may take place. 3879 - requirements the new exchange has on existing 3880 exchanges which have assigned numbers. 3882 Payloads are defined in this memo to convey information between 3883 peers. New payloads may be required when defining a new 3884 authentication method or exchange. Requests for new payload types 3885 MUST be accompanied by an RFC which defines the physical layout of 3886 the payload and the fields it contains. All payloads MUST use the 3887 same generic header defined in Figure 5. 3889 7 Intellectual Property Rights 3891 The IETF has been notified of intellectual property rights claimed in 3892 regard to some or all of the specification contained in this 3893 document. For more information consult the online list of claimed 3894 rights. 3896 8 Acknowledgements 3898 This document is a collaborative effort of the entire IPsec WG. If 3899 there were no limit to the number of authors that could appear on an 3900 RFC, the following, in alphabetical order, would have been listed: 3901 Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt 3902 Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, J. 3903 Ioannidis, Steve Kent, Angelos Keromytis, Tero Kivinen, Hugo 3904 Krawczyk, Andrew Krywaniuk, Radia Perlman, O. Reingold. Many other 3905 people contributed to the design. It is an evolution of IKEv1, 3906 ISAKMP, and the IPSec DOI, each of which has its own list of authors. 3907 Hugh Daniel suggested the feature of having the initiator, in message 3908 3, specify a name for the responder, and gave the feature the cute 3909 name "You Tarzan, Me Jane". David Faucher and Valery Smyzlov helped 3910 refine the design of the traffic selector negotiation. 3912 9 References 3914 9.1 Normative References 3916 [Bra96] Bradner, S., "The Internet Standards Process -- Revision 3", 3917 BCP 9, RFC 2026, October 1996. 3919 [Bra97] Bradner, S., "Key Words for use in RFCs to indicate 3920 Requirement Levels", BCP 14, RFC 2119, March 1997. 3922 [EAP] Blunk, L. and Volibrecht, J., "PPP Extensible Authentication 3923 Protocol (EAP), RFC 2284, March 1998. 3925 [ESPCBC] Pereira, R., Adams, R., "The ESP CBC-Mode Cipher 3926 Algorithms", 3927 RFC 2451, November 1998. 3929 9.2 Non-normative References 3931 [Ble98] Bleichenbacher, D., "Chosen Ciphertext Attacks against 3932 Protocols Based on RSA Encryption Standard PKCS#1", Advances 3933 in Cryptology Eurocrypt '98, Springer-Verlag, 1998. 3935 [BR94] Bellare, M., and Rogaway P., "Optimal Asymmetric 3936 Encryption", Advances in Cryptology Eurocrypt '94, 3937 Springer-Verlag, 1994. 3939 [DES] ANSI X3.106, "American National Standard for Information 3940 Systems-Data Link Encryption", American National Standards 3941 Institute, 1983. 3943 [DH] Diffie, W., and Hellman M., "New Directions in 3944 Cryptography", IEEE Transactions on Information Theory, V. 3945 IT-22, n. 6, June 1977. 3947 [DHCP] R. Droms, "Dynamic Host Configuration Protocol", 3948 RFC2131 3950 [DSS] NIST, "Digital Signature Standard", FIPS 186, National 3951 Institute of Standards and Technology, U.S. Department of 3952 Commerce, May, 1994. 3954 [HC98] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", 3955 RFC 2409, November 1998. 3957 [Hutt02] Huttunen, A. et. al., "UDP Encapsulation of IPsec Packets", 3958 draft-ietf-ipsec-udp-encaps-05.txt, December 2002. 3960 [IDEA] Lai, X., "On the Design and Security of Block Ciphers," ETH 3961 Series in Information Processing, v. 1, Konstanz: Hartung- 3962 Gorre Verlag, 1992 3964 [Ker01] Keronytis, A., Sommerfeld, B., "The 'Suggested ID' Extension 3965 for IKE", draft-keronytis-ike-id-00.txt, 2001 3967 [KBC96] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 3968 Hashing for Message Authentication", RFC 2104, February 3969 1997. 3971 [LDAP] M. Wahl, T. Howes, S. Kille., "Lightweight Directory 3972 Access Protocol (v3)", RFC2251 3974 [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, 3975 April 1992. 3977 [MSST98] Maughhan, D., Schertler, M., Schneider, M., and Turner, J. 3978 "Internet Security Association and Key Management Protocol 3979 (ISAKMP)", RFC 2408, November 1998. 3981 [Orm96] Orman, H., "The Oakley Key Determination Protocol", RFC 3982 2412, November 1998. 3984 [PFKEY] McDonald, D., Metz, C., and Phan, B., "PFKEY Key Management 3985 API, Version 2", RFC2367, July 1998. 3987 [PKCS1] Kaliski, B., and J. Staddon, "PKCS #1: RSA Cryptography 3988 Specifications Version 2", September 1998. 3990 [PK01] Perlman, R., and Kaufman, C., "Analysis of the IPsec key 3991 exchange Standard", WET-ICE Security Conference, MIT, 2001, 3992 http://sec.femto.org/wetice-2001/papers/radia-paper.pdf. 3994 [Pip98] Piper, D., "The Internet IP Security Domain Of 3995 Interpretation for ISAKMP", RFC 2407, November 1998. 3997 [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote 3998 Authentication Dial In User Service (RADIUS)", RFC2138 4000 [RFC1715] 4002 [RSA] Rivest, R., Shamir, A., and Adleman, L., "A Method for 4003 Obtaining Digital Signatures and Public-Key Cryptosystems", 4004 Communications of the ACM, v. 21, n. 2, February 1978. 4006 [SHA] NIST, "Secure Hash Standard", FIPS 180-1, National Institute 4007 of Standards and Technology, U.S. Department of Commerce, 4008 May 1994. 4010 [SIGMA] Krawczyk, H., "SIGMA: the `SIGn-and-MAc' Approach to 4011 Authenticated Diffie-Hellman and its Use in the IKE 4012 Protocols", Nov. 2002. 4013 http://www.ee.technion.ac.il/~hugo/sigma.html 4015 [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange 4016 Mechanism for Internet", from IEEE Proceedings of the 1996 4017 Symposium on Network and Distributed Systems Security. 4019 Appendix A: Summary of changes from IKEv1 4021 The goals of this revision to IKE are: 4023 1) To define the entire IKE protocol in a single document, replacing 4024 RFCs 2407, 2408, and 2409 and incorporating subsequent changes to 4025 support NAT Traversal, Extended Authentication, and Remote Address 4026 acquisition. 4028 2) To simplify IKE by replacing the eight different initial exchanges 4029 with a single four message exchange (with changes in authentication 4030 mechanisms affecting only a single AUTH payload rather than 4031 restructuring the entire exchange); 4033 3) To remove the Domain of Interpretation (DOI), Situation (SIT), and 4034 Labeled Domain Identifier fields, and the Commit and Authentication 4035 only bits; 4037 4) To decrease IKE's latency in the common case by making the initial 4038 exchange be 2 round trips (4 messages), and allowing the ability to 4039 piggyback setup of a CHILD-SA on that exchange; 4041 5) To replace the cryptographic syntax for protecting the IKE 4042 messages themselves with one based closely on ESP to simplify 4043 implementation and security analysis; 4045 6) To reduce the number of possible error states by making the 4046 protocol reliable (all messages are acknowledged) and sequenced. This 4047 allows shortening CREATE_CHILD_SA exchanges from 3 messages to 2; 4049 7) To increase robustness by allowing the responder to not do 4050 significant processing until it receives a message proving that the 4051 initiator can receive messages at its claimed IP address, and not 4052 commit any state to an exchange until the initiator can be 4053 cryptographically authenticated; 4055 8) To fix bugs such as the hash problem documented in [draft-ietf- 4056 ipsec-ike-hash-revised-02.txt]; 4058 9) To specify Traffic Selectors in their own payloads type rather 4059 than overloading ID payloads, and making more flexible the Traffic 4060 Selectors that may be specified; 4062 10) To specify required behavior under certain error conditions or 4063 when data that is not understood is received in order to make it 4064 easier to make future revisions in a way that does not break 4065 backwards compatibility; 4066 11) To incorporate ideas from draft-ietf-ipsec-nat-reqts-02.txt to 4067 allow IKE to negotiate through NAT gateways; 4069 12) To simplify and clarify how shared state is maintained in the 4070 presence of network failures and Denial of Service attacks; and 4072 13) To maintain existing syntax and magic numbers to the extent 4073 possible to make it likely that implementations of IKEv1 can be 4074 enhanced to support IKEv2 with minimum effort. 4076 Appendix B: Diffie-Hellman Groups 4078 There are 5 groups different Diffie-Hellman groups defined for use in 4079 IKE. These groups were generated by Richard Schroeppel at the 4080 University of Arizona. Properties of these primes are described in 4081 [Orm96]. 4083 The strength supplied by group one may not be sufficient for the 4084 mandatory-to-implement encryption algorithm and is here for historic 4085 reasons. 4087 Additional Diffie-Hellman groups have been defined in [ADDGROUP]. 4088 Future IANA-registered and private use Suite-IDs MAY use Diffie- 4089 Hellman groups that have modulus values and generators that are 4090 different than those in this document or in [ADDGROUP]. 4092 B.1 Group 1 - 768 Bit MODP 4094 IKE implementations MAY support a MODP group with the following prime 4095 and generator. This group is assigned id 1 (one). 4097 The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } 4098 Its hexadecimal value is: 4100 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 4101 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 4102 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 4103 A63A3620 FFFFFFFF FFFFFFFF 4105 The generator is 2. 4107 B.2 Group 2 - 1024 Bit MODP 4109 IKE implementations SHOULD support a MODP group with the following 4110 prime and generator. This group is assigned id 2 (two). 4112 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. 4113 Its hexadecimal value is: 4115 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 4116 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 4117 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 4118 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 4119 49286651 ECE65381 FFFFFFFF FFFFFFFF 4121 The generator is 2. 4123 B.3 Group 3 - 155 Bit EC2N 4125 IKE implementations MAY support a EC2N group with the following 4126 characteristics. This group is assigned id 3 (three). The curve is 4127 based on the Galois Field GF[2^155]. The field size is 155. The 4128 irreducible polynomial for the field is: 4129 u^155 + u^62 + 1. 4130 The equation for the elliptic curve is: 4131 y^2 + xy = x^3 + ax^2 + b. 4133 Field Size: 155 4134 Group Prime/Irreducible Polynomial: 4135 0x0800000000000000000000004000000000000001 4136 Group Generator One: 0x7b 4137 Group Curve A: 0x0 4138 Group Curve B: 0x07338f 4139 Group Order: 0x0800000000000000000057db5698537193aef944 4141 The data in the KE payload when using this group is the value x from 4142 the solution (x,y), the point on the curve chosen by taking the 4143 randomly chosen secret Ka and computing Ka*P, where * is the 4144 repetition of the group addition and double operations, P is the 4145 curve point with x coordinate equal to generator 1 and the y 4146 coordinate determined from the defining equation. The equation of 4147 curve is implicitly known by the Group Type and the A and B 4148 coefficients. There are two possible values for the y coordinate; 4149 either one can be used successfully (the two parties need not agree 4150 on the selection). 4152 B.4 Group 4 - 185 Bit EC2N 4154 IKE implementations MAY support a EC2N group with the following 4155 characteristics. This group is assigned id 4 (four). The curve is 4156 based on the Galois Field GF[2^185]. The field size is 185. The 4157 irreducible polynomial for the field is: 4158 u^185 + u^69 + 1. 4160 The equation for the elliptic curve is: 4161 y^2 + xy = x^3 + ax^2 + b. 4163 Field Size: 185 4164 Group Prime/Irreducible Polynomial: 4165 0x020000000000000000000000000000200000000000000001 4166 Group Generator One: 0x18 4167 Group Curve A: 0x0 4168 Group Curve B: 0x1ee9 4169 Group Order: 0x01ffffffffffffffffffffffdbf2f889b73e484175f94ebc 4171 The data in the KE payload when using this group will be identical to 4172 that as when using Oakley Group 3 (three). 4174 B.5 Group 5 - 1536 Bit MODP 4176 IKE implementations MUST support a MODP group with the following 4177 prime and generator. This group is assigned id 5 (five). 4179 The prime is 2^1536 - 2^1472 - 1 + 2^64 * {[2^1406 pi] + 741804}. 4180 Its hexadecimal value is 4182 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 4183 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 4184 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 4185 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 4186 49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 4187 FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 4188 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF 4190 The generator is 2. 4192 Change History 4194 H.1 Changes from IKEv2-00 to IKEv2-01 February 2002 4196 1) Changed Appendix B to specify the encryption and authentication 4197 processing for IKE rather than referencing ESP. Simplified the format 4198 by removing idiosyncracies not needed for IKE. 4200 2) Added option for authentication via a shared secret key. 4202 3) Specified different keys in the two directions of IKE messages. 4203 Removed requirement of different cookies in the two directions since 4204 now no longer required. 4206 4) Change the quantities signed by the two ends in AUTH fields to 4207 assure the two parties sign different quantities. 4209 5) Changed reference to AES to AES_128. 4211 6) Removed requirement that Diffie-Hellman be repeated when rekeying 4212 IKE_SA. 4214 7) Fixed typos. 4216 8) Clarified requirements around use of port 500 at the remote end in 4217 support of NAT. 4219 9) Clarified required ordering for payloads. 4221 10) Suggested mechanisms for avoiding DoS attacks. 4223 11) Removed claims in some places that the first phase 2 piggybacked 4224 on phase 1 was optional. 4226 H.2 Changes from IKEv2-01 to IKEv2-02 April 2002 4228 1) Moved the Initiator CERTREQ payload from message 1 to message 3. 4230 2) Added a second optional ID payload in message 3 for the Initiator 4231 to name a desired Responder to support the case where multiple named 4232 identities are served by a single IP address. 4234 3) Deleted the optimization whereby the Diffie-Hellman group did not 4235 need to be specified in phase 2 if it was the same as in phase 1 (it 4236 complicated the design with no meaningful benefit). 4238 4) Added a section on the implications of reusing Diffie-Hellman 4239 expontentials 4240 5) Changed the specification of sequence numbers to being at 0 in 4241 both directions. 4243 6) Many editorial changes and corrections, the most significant being 4244 a global replace of "byte" with "octet". 4246 H.3 Changes from IKEv2-02 to IKEv2-03 October 2002 4248 1) Reorganized the document moving introductory material to the 4249 front. 4251 2) Simplified the specification of Traffic Selectors to allow only 4252 IPv4 and IPv6 address ranges, as was done in the JFK spec. 4254 3) Fixed the problem brought up by David Faucher with the fix 4255 suggested by Valery Smyslov. If Bob needs to narrow the selector 4256 range, but has more than one matching narrower range, then if Alice's 4257 first selector is a single address pair, Bob chooses the range that 4258 encompasses that. 4260 4) To harmonize with the JFK spec, changed the exchange so that the 4261 initial exchange can be completed in four messages even if the 4262 responder must invoke an anti-clogging defense and the initiator 4263 incorrectly anticipates the responder's choice of Diffie-Hellman 4264 group. 4266 5) Replaced the hierarchical SA payload with a simplified version 4267 that only negotiates suites of cryptographic algorithms. 4269 H.4 Changes from IKEv2-03 to IKEv2-04 January 2003 4271 1) Integrated NAT traversal changes (including Appendix A). 4273 2) Moved the anti-clogging token (cookie) from the SPI to a NOTIFY 4274 payload; changed negotation back to 6 messages when a cookie is 4275 needed. 4277 3) Made capitalization of IKE_SA and CHILD_SA consistent. 4279 4) Changed how IPcomp was negotiated. 4281 5) Added usage scenarios. 4283 6) Added configuration payload for acquiring internal addresses on 4284 remote networks. 4286 7) Added negotiation of tunnel vs transport mode. 4288 H.5 Changes from IKEv2-04 to IKEv2-05 February 2003 4290 1) Shortened Abstract 4292 2) Moved NAT Traversal from Appendix to section 2. Moved changes from 4293 IKEv2 to Appendix A. Renumbered sections. 4295 3) Made language more consistent. Removed most references to Phase 1 4296 and Phase 2. 4298 4) Made explicit the requirements for support of NAT Traversal. 4300 5) Added support for Extended Authentication Protocol methods. 4302 6) Added Response bit to message header. 4304 7) Made more explicit the encoding of Diffie-Hellman numbers in key 4305 expansion algorithms. 4307 8) Added ID payloads to AUTH payload computation. 4309 9) Expanded set of defined cryptographic suites. 4311 10) Added text for MUST/SHOULD support for ID payloads. 4313 11) Added new certificate formats and added MUST/SHOULD text. 4315 12) Clarified use of CERTREQ. 4317 13) Deleted "MUST SUPPORT" column in CP payload specification (it was 4318 inconsistent with surrounding text). 4320 14) Extended and clarified Conformance Requirements section, 4321 including specification of a minimal implementation. 4323 15) Added text to specify ECN handling. 4325 H.6 Changes from IKEv2-05 to IKEv2-06 March 2003 4327 1) Changed the suite based crypto negotiation back to ala carte. 4329 2) Eliminated some awkward page breaks, typographical errors, and 4330 other formatting issues. 4332 3) Tightened language describing cryptographic strength. 4334 4) Added references. 4336 5) Added more specific error codes. 4338 6) Added rationale for unintuitive key generation hash with shared 4339 secret based authentication. 4341 7) Changed the computation of the authenticating AUTH payload as 4342 proposed by Hugo Krawczyk. 4344 8) Changed the dashes (-) to underscores (_) in the names of fields 4345 and constants. 4347 H.7 Changes from IKEv2-06 to IKEv2-07 April 2003 4349 1) Added a list of payload types to section 3.2. 4351 2) Clarified use of SET_WINDOW_SIZE notify payload. 4353 3) Removed references to COOKIE_REQUIRED notify payload. 4355 4) Specified how to use a prf with a fixed key size. 4357 5) Removed g^ir from data processed by prf+. 4359 6) Strengthened cautions against using passwords as shared keys. 4361 7) Renamed Protocol_id field SECURITY_PROTOCOL_ID when it is not the 4362 Protocol ID from IP, and changed its values for consistency with 4363 IKEv1. 4365 8) Clarified use of ID payload in access control decisions. 4367 9) Gave IDr and TSr their own payload type numbers. 4369 10) Added Intellectual Property rights section. 4371 11) Clarified some issues in NAT Traversal. 4373 Editor's Address 4375 Charlie Kaufman 4376 charlie_kaufman@notesdev.ibm.com 4377 IBM 4379 Full Copyright Statement 4381 "Copyright (C) The Internet Society (2003). All Rights Reserved. 4383 This document and translations of it may be copied and furnished to 4384 others, and derivative works that comment on or otherwise explain it 4385 or assist in its implementation may be prepared, copied, published 4386 and distributed, in whole or in part, without restriction of any 4387 kind, provided that the above copyright notice and this paragraph are 4388 included on all such copies and derivative works. However, this 4389 document itself may not be modified in any way, such as by removing 4390 the copyright notice or references to the Internet Society or other 4391 Internet organizations, except as needed for the purpose of 4392 developing Internet standards in which case the procedures for 4393 copyrights defined in the Internet Standards process must be 4394 followed, or as required to translate it into languages other than 4395 English. 4397 The limited permissions granted above are perpetual and will not be 4398 revoked by the Internet Society or its successors or assigns. 4400 This document and the information contained herein is provided on an 4401 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 4402 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 4403 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 4404 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 4405 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."