idnits 2.17.1 draft-ietf-ipsec-ikev2-05.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 82 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 83 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 3672 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: ID_FQDN 2 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 (February 2003) is 7738 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CERTREQ' is mentioned on line 1267, but not defined == Missing Reference: 'KEi' is mentioned on line 414, but not defined == Missing Reference: 'KEr' is mentioned on line 431, but not defined == Missing Reference: 'CP' is mentioned on line 508, but not defined == Missing Reference: 'RFC 2522' is mentioned on line 779, but not defined == Missing Reference: 'AUTH' is mentioned on line 1277, but not defined == Missing Reference: 'IPCOMP' is mentioned on line 1490, but not defined == Missing Reference: 'RFC 2401' is mentioned on line 1603, but not defined ** Obsolete undefined reference: RFC 2401 (Obsoleted by RFC 4301) == Missing Reference: 'RFC 3168' is mentioned on line 1611, but not defined == Missing Reference: 'IKEv2' is mentioned on line 1623, but not defined == Missing Reference: 'RFC 2474' is mentioned on line 1645, but not defined == Missing Reference: 'RFC 2475' is mentioned on line 1646, but not defined == Missing Reference: 'RFC2401' is mentioned on line 1654, but not defined ** Obsolete undefined reference: RFC 2401 (Obsoleted by RFC 4301) == Missing Reference: 'ADDGROUP' is mentioned on line 3602, but not defined == Missing Reference: 'ADDRIPV6' is mentioned on line 3155, but not defined == Unused Reference: 'Ble98' is defined on line 3449, but no explicit reference was found in the text == Unused Reference: 'BR94' is defined on line 3453, but no explicit reference was found in the text == Unused Reference: 'DES' is defined on line 3457, but no explicit reference was found in the text == Unused Reference: 'DH' is defined on line 3461, but no explicit reference was found in the text == Unused Reference: 'DSS' is defined on line 3468, but no explicit reference was found in the text == Unused Reference: 'HC98' is defined on line 3472, but no explicit reference was found in the text == Unused Reference: 'IDEA' is defined on line 3475, but no explicit reference was found in the text == Unused Reference: 'Ker01' is defined on line 3479, but no explicit reference was found in the text == Unused Reference: 'KBC96' is defined on line 3482, but no explicit reference was found in the text == Unused Reference: 'MD5' is defined on line 3489, but no explicit reference was found in the text == Unused Reference: 'MSST98' is defined on line 3492, but no explicit reference was found in the text == Unused Reference: 'PKCS1' is defined on line 3502, but no explicit reference was found in the text == Unused Reference: 'PK01' is defined on line 3505, but no explicit reference was found in the text == Unused Reference: 'Pip98' is defined on line 3509, but no explicit reference was found in the text == Unused Reference: 'RSA' is defined on line 3515, but no explicit reference was found in the text == Unused Reference: 'SHA' is defined on line 3519, but no explicit reference was found in the text == Unused Reference: 'SKEME' is defined on line 3523, 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) -- 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 (~~), 42 warnings (==), 8 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-05.txt February 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.............................8 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.......................11 67 2.1 Use of Retransmission Timers............................12 68 2.2 Use of Sequence Numbers for Message ID..................12 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................................................19 75 2.9 Traffic Selector Negotiation............................20 76 2.10 Nonces.................................................22 77 2.11 Address and Port Agility...............................22 78 2.12 Reuse of Diffie-Hellman Exponentials...................23 79 2.13 Generating Keying Material.............................23 80 2.14 Generating Keying Material for the IKE-SA..............24 81 2.15 Authentication of the IKE-SA...........................25 82 2.16 Extended Authentication Protocol Methods...............26 83 2.17 Generating Keying Material for CHILD-SAs...............27 84 2.18 Rekaying IKE-SAs using a CREATE_CHILD_SA exchange......28 85 2.19 Requesting an internal address on a remote network.....29 86 2.20 Requesting a Peer's Version............................30 87 2.21 Error Handling.........................................31 88 2.22 IPcomp.................................................32 89 2.23 NAT Traversal..........................................32 90 2.24 ECN Notification.......................................34 91 3 Header and Payload Formats................................35 92 3.1 The IKE Header..........................................35 93 3.2 Generic Payload Header..................................38 94 3.3 Security Association Payload............................39 95 3.3.1 Proposal Substructure.................................40 96 3.4 Key Exchange Payload....................................43 97 3.5 Identification Payload..................................43 98 3.6 Certificate Payload.....................................45 99 3.7 Certificate Request Payload.............................47 100 3.8 Authentication Payload..................................48 101 3.9 Nonce Payload...........................................49 102 3.10 Notify Payload.........................................50 103 3.10.1 Notify Message Types.................................51 104 3.11 Delete Payload.........................................56 105 3.12 Vendor ID Payload......................................57 106 3.13 Traffic Selector Payload...............................58 107 3.13.1 Traffic Selector.....................................59 108 3.14 Encrypted Payload......................................60 109 3.15 Configuration Payload..................................62 110 3.15.1 Configuration Attributes.............................64 111 3.16 Extended Authentication Protocol (EAP) Payload.........66 112 3.17 Other Payload types....................................68 113 4 Conformance Requirements..................................68 114 5 Security Considerations...................................70 115 6 IANA Considerations.......................................71 116 7 Acknowledgements..........................................72 117 8 References................................................72 118 8.1 Normative References....................................72 119 8.2 Non-normative References................................72 120 Appendix A: Summary of Changes from IKEv1...................75 121 Appendix B: Diffie-Hellman Groups...........................77 122 Change History..............................................79 123 Author's Address............................................82 124 Full Copyright Statement....................................82 126 Requirements Terminology 128 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 129 "MAY" that appear in this document are to be interpreted as described 130 in [Bra97]. 132 1 IKE Protocol Overview 134 IP Security (IPsec) provides confidentiality, data integrity, access 135 control, and data source authentication to IP datagrams. These 136 services are provided by maintaining shared state between the source 137 and the sink of an IP datagram. This state defines, among other 138 things, the specific services provided to the datagram, which 139 cryptographic algorithms will be used to provide the services, and 140 the keys used as input to the cryptographic algorithms. 142 Establishing this shared state in a manual fashion does not scale 143 well. Therefore a protocol to establish this state dynamically is 144 needed. This memo describes such a protocol-- the Internet Key 145 Exchange (IKE). This is version 2 of IKE. Version 1 of IKE was 146 defined in RFCs 2407, 2408, and 2409. This single document is 147 intended to replace all three of those RFCs. 149 IKE performs mutual authentication between two parties and 150 establishes an IKE security association that includes shared secret 151 information that can be used to efficiently establish SAs for ESP 152 (RFC 2406) and/or AH (RFC 2402). It also negotiates use of IPcomp 153 (RFC 2393) in connection with an ESP and/or AH SA. We call the IKE 154 SA an "IKE-SA". The SAs for ESP and/or AH that get set up through 155 that IKE-SA we call "CHILD-SA"s. 157 All IKE communications consist of pairs of messages: a request and a 158 response. The pair is called an "exchange". We call the first 159 messages establishing an IKE-SA IKE_SA_INIT and IKE_AUTH exchanges 160 and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL 161 exchanges. In the common case, there is a single IKE_SA_INIT exchange 162 and a single IKE_AUTH exchange (a total of four messages) to 163 establish the IKE-SA and the first CHILD-SA. In exceptional cases, 164 there may be more than one of each of these exchanges. In all cases, 165 all IKE_SA_INIT exchanges MUST complete before any other exchange 166 type, then all IKE_AUTH exchanges MUST complete, and following that 167 any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur 168 in any order. In some scenarios, only a single CHILD-SA is needed 169 between the IPsec endpoints and therefore there would be no 170 additional exchanges. Subsequent exchanges MAY be used to establish 171 additional CHILD-SAs between the same authenticated pair of endpoints 172 and to perform housekeeping functions. 174 IKE message flow always consists of a request followed by a response. 175 It is the responsibility of the requester to ensure reliability. If 176 the response is not received within a timeout interval, the requester 177 MUST retransmit the request (or abandon the connection). 179 The first request/response of an IKE session negotiates security 180 parameters for the IKE-SA, sends nonces, and sends Diffie-Hellman 181 values. We call the initial exchange IKE_SA_INIT (request and 182 response). 184 The second request/response, which we'll call IKE_AUTH transmits 185 identities, proves knowledge of the secrets corresponding to the two 186 identities, and sets up an SA for the first (and often only) AH 187 and/or ESP CHILD-SA. 189 The types of subsequent exchanges are CREATE_CHILD_SA (which creates 190 a CHILD-SA), or and INFORMATIONAL (which deletes an SA, reports error 191 conditions, or does other housekeeping). Every request requires a 192 response. An INFORMATIONAL request with no payloads is commonly used 193 as a check for liveness. These subsequent exchanges cannot be used 194 until the initial exchanges have completed. 196 In the description that follows, we assume that no errors occur. 197 Modifications to the flow should errors occur are described in 198 section 2.21. 200 1.1 Usage Scenarios 202 IKE is expected to be used to negotiate ESP and/or AH SAs in a number 203 of different scenarios, each with their own special requirements. 205 1.1.1 Gateway to Gateway Tunnel 207 +-+-+-+-+-+ +-+-+-+-+-+ 208 ! ! IPsec ! ! 209 Protected !Tunnel ! Tunnel !Tunnel ! Protected 210 Subnet <-->!Endpoint !<---------->!Endpoint !<--> Subnet 211 ! ! ! ! 212 +-+-+-+-+-+ +-+-+-+-+-+ 214 Figure 1: Firewall to Firewall Tunnel 216 In this scenario, neither endpoint of the IP connection implements 217 IPsec, but network nodes between them protect traffic for part of the 218 way. Protection is transparent to the endpoints, and depends on 219 ordinary routing sending packets through the tunnel endpoints for 220 processing. Each endpoint would announce the set of addresses 221 "behind" it, and packets would be sent in Tunnel Mode where the inner 222 IP header would contain the IP addresses of the actual endpoints. 224 1.1.2 Endpoint to Endpoint Transport 226 +-+-+-+-+-+ +-+-+-+-+-+ 227 ! ! IPsec ! ! 228 !Protected! Tunnel !Protected! 229 !Endpoint !<---------------------------------------->!Endpoint ! 230 ! ! ! ! 231 +-+-+-+-+-+ +-+-+-+-+-+ 233 Figure 2: Endpoint to Endpoint 235 In this scenario, both endpoints of the IP connection implement 236 IPsec. These endpoints may implement application layer access 237 controls based on the authenticated identities of the participants. 238 Transport mode will commonly be used with no inner IP header. If 239 there is an inner IP header, the inner addresses will be the same as 240 the outer addresses. A single pair of addresses will be negotiated 241 for packets to be sent over this SA. 243 It is possible in this scenario that one of the protected endpoints 244 will be behind a network address translation (NAT) node, in which 245 case the tunnelled packets will have to be UDP encapsulated so that 246 port numbers in the UDP headers can be used to identify individual 247 endpoints "behind" the NAT. 249 1.1.3 Endpoint to Gateway Transport 251 +-+-+-+-+-+ +-+-+-+-+-+ 252 ! ! IPsec ! ! Protected 253 !Protected! Tunnel !Tunnel ! Subnet 254 !Endpoint !<------------------------>!Endpoint !<--- and/or 255 ! ! ! ! Internet 256 +-+-+-+-+-+ +-+-+-+-+-+ 258 Figure 3: Endpoint to Gateway 260 In this scenario, a protected endpoint (typically a portable roaming 261 computer) connects back to its corporate network through an IPsec 262 protected tunnel. It might use this tunnel only to access information 263 on the corporate network or it might tunnel all of its traffic back 264 through the corporate network in order to take advantage of 265 protection provided by a corporate firewall against Internet based 266 attacks. In either case, the protected endpoint will want an IP 267 address associated with the gateway so that packets returned to it 268 will go to the gateway and be tunnelled back. This IP address may be 269 static or may be dynamically allocated by the gateway. In support of 270 the latter case, IKEv2 includes a mechanism for the initiator to 271 request an IP address owned by the gateway for use for the duration 272 of its SA. 274 In this scenario, packets will use tunnel mode. On each packet from 275 the protected endpoint, the outer IP header will contain the source 276 IP address associated with its current location (i.e. the address 277 that will get traffic routed to the endpoint directly) while the 278 inner IP header will contain the source IP address assigned by the 279 gateway (i.e. the address that will get traffic routed to the gateway 280 for forwarding to the endpoint). The outer destination address will 281 always be that of the gateway, while the inner destination address 282 will be the ultimate destination for the packet. 284 In this scenario, it is possible that the protected endpoint will be 285 behind a NAT. In that case, the IP address as seen by the gateway 286 will not be the same as the IP address sent by the protected 287 endpoint, and packets will have to be UDP encapsulated in order to be 288 routed properly. 290 1.1.4 Other Scenarios 292 Other scenarios are possible, as are nested combinations of the 293 above. One noteable example combines aspects of 1.1.1 and 1.1.3. A 294 subnet may make all external accesses through a remote gateway using 295 an IPsec tunnel, where the addresses on the subnet are routed to the 296 gateway by the rest of the Internet. An example would be someones 297 home network being virtually on the Internet with static IP addresses 298 even though connectivity is provided by an ISP that assigns a single 299 dynamically assigned IP address (where the static IP addresses and an 300 IPsec relay is provided by a third party located elsewhere). 302 1.2 The Initial Exchange 304 Communication using IKE always begins with an initial exchange (known 305 in IKEv1 as Phase 1). This initial exchange normally consists of four 306 messages, though in some scenarios that number can grow. All 307 communications using IKE consist of request/response pairs. We'll 308 describe the base exchange first, followed by variations. The first 309 pair of messages (IKE_SA_INIT) negotiate cryptographic algorithms, 310 exchange nonces, and do a Diffie-Hellman exchange. 312 The second pair of messages (IKE_AUTH) authenticate the previous 313 messages, exchange identities and certificates, and establish the 314 first CHILD-SA. Parts of these messages are encrypted and integrity 315 protected with keys established through the IKE_SA_INIT exchange, so 316 the identities are hidden from eavesdroppers and all fields in all 317 the messages are authenticated. 319 In the following description, the payloads contained in the message 320 are indicated by names such as SA. The details of the contents of 321 each payload are described later. Payloads which may optionally 322 appear will be shown in brackets, such as [CERTREQ], would indicate 323 that optionally a certificate request payload can be included. 325 The initial exchange is as follows: 327 Initiator Responder 328 ----------- ----------- 329 HDR, SAi1, KEi, Ni --> 331 HDR contains the SPIs, version numbers, and flags of various sorts. 332 The SAi1 payload states the cryptographic algorithms the Initiator 333 supports for the IKE-SA. The KE payload sends the Initiator's 334 Diffie-Hellman value. Ni is the Initiator's nonce. 336 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 338 The Responder chooses a cryptographic suite from the Initiator's 339 offered choices and expresses that choice in the SAr1 payload, 340 completes the Diffie-Hellman exchange with the KEr payload, and sends 341 its nonce in the Nr payload. 343 At this point in the negotiation each party can generate SKEYSEED, 344 from which all keys are derived for that IKE-SA. All but the headers 345 of all the messages that follow are encrypted and integrity 346 protected. The keys used for the encryption and integrity protection 347 are derived from SKEYSEED and are known as SK_e (encryption) and SK_a 348 (authentication, a.k.a. integrity protection). A separate SK_e and 349 SK_a is computed for each direction. The notation SK { ... } 350 indicates that these payloads are encrypted and integrity protected 351 using that direction's SK_e and SK_a. 353 HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] 354 AUTH, SAi2, TSi, TSr} --> 356 The Initiator asserts her identity with the IDi payload, proves 357 knowledge of the secret corresponding to IDi and integrity protects 358 the contents of the first two messages using the AUTH payload. She 359 might also send her certificate(s) in CERT payload(s) and a list of 360 her trust anchors in CERTREQ payload(s). If any CERT payloads are 361 included, the first certificate provided must contain the public key 362 used to verify the AUTH field. The optional payload IDr enables 363 Alice to specify which of Bob's identities she wants to talk to. This 364 is useful when Bob is hosting multiple identities at the same IP 365 address. She begins negotiation of a CHILD-SA using the SAi2 366 payload. The final fields (starting with SAi2) are described in the 367 description of the CREATE_CHILD_SA exchange. 369 <-- HDR, SK {IDr, [CERT,] AUTH, 370 SAr2, TSi, TSr} 372 The Responder asserts his identity with the IDr payload, optionally 373 sends one or more certificates (again with the certificate containing 374 the public key used to verify AUTH listed first), authenticates his 375 identity with the AUTH payload, and completes negotiation of a CHILD- 376 SA with the additional fields described below in the CREATE_CHILD_SA 377 exchange. 379 The recipients of messages 3 and 4 MUST verify that all signatures 380 and MACs are computed correctly and that the names in the ID payloads 381 correspond to the keys used to generate the AUTH payload. 383 1.3 The CREATE_CHILD_SA Exchange 384 This exchange consists of a single request/response pair, and was 385 referred to as a phase 2 exchange in IKEv1. It MAY be initiated by 386 either end of the IKE-SA after the initial exchange is completed. 388 All messages following the initial exchange are cryptographically 389 protected using the cryptographic algorithms and keys negotiated in 390 the first two messages of the IKE exchange using a syntax described 391 in section 3.14. 393 Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this 394 section the term Initiator refers to the endpoint initiating this 395 exchange. 397 A CHILD-SA is created by sending a CREATE_CHILD_SA request. The 398 CREATE_CHILD_SA request MAY optionally contain a KE payload for an 399 additional Diffie-Hellman exchange to enable stronger guarantees of 400 forward secrecy for the CHILD-SA. The keying material for the CHILD- 401 SA is a function of SK_d established during the establishment of the 402 IKE-SA, the nonces exchanged during the CREATE_CHILD_SA exchange, and 403 the Diffie-Hellman value (if KE payloads are included in the 404 CREATE_CHILD_SA exchange). 406 In the CHILD-SA created as part of the initial exchange, a second KE 407 payload and nonce MUST NOT be sent. The nonces from the initial 408 exchange are used in computing the keys for the CHILD-SA. 410 The CREATE_CHILD_SA request contains: 412 Initiator Responder 413 ----------- ----------- 414 HDR, SK {SA, Ni, [KEi], 415 [TSi, TSr]} --> 417 The Initiator sends SA offer(s) in the SA payload, a nonce in the Ni 418 payload, optionally a Diffie-Hellman value in the KEi payload, and 419 the proposed traffic selectors in the TSi and TSr payloads. If the SA 420 offers include different Diffie-Hellman groups, KEi must be an 421 element of the group the Initiator expects the responder to accept. 422 If she guesses wrong, the CREATE_CHILD_SA exchange will fail and she 423 will have to retry with a different KEi. 425 The message past the header is encrypted and the message including 426 the header is integrity protected using the cryptographic algorithms 427 negotiated for the IKE SA. 429 The CREATE_CHILD_SA response contains: 431 <-- HDR, SK {SA, Nr, [KEr], 433 [TSi, TSr]} 435 The Responder replies (using the same Message ID to respond) with the 436 accepted offer in an SA payload, a Diffie-Hellman value in the KEr 437 payload if KEi was included in the request and the selected 438 cryptographic suite includes that group. If the responder chooses a 439 cryptographic suite with a different group, it must reject the 440 request and have the initiator make another one. 442 The traffic selectors for traffic to be sent on that SA are specified 443 in the TS payloads, which may be a subset of what the Initiator of 444 the CHILD-SA proposed. Traffic selectors are omitted if this 445 CREATE_CHILD_SA request is being used to change the key of the IKE- 446 SA. 448 1.4 The INFORMATIONAL Exchange 450 At various points during the operation of an IKE-SA, peers may desire 451 to convey control messages to each other regarding errors or 452 notifications of certain events. To accomplish this IKE defines an 453 INFORMATIONAL exchange. INFORMATIONAL exchanges MAY ONLY occur after 454 an initial exchange and are cryptographically protected with the 455 negotiated keys. 457 Control messages that pertain to an IKE-SA MUST be sent under that 458 IKE-SA. Control messages that pertain to CHILD-SAs MUST be sent under 459 the protection of the IKE-SA which generated them (or its successor 460 if the IKE-SA was replaced for the purpose of rekeying). 462 Messages in an INFORMATIONAL Exchange contain zero or more 463 Notification, Delete, and Configuration payloads. The Recipient of an 464 INFORMATIONAL Exchange request MUST send some response (else the 465 Sender will assume the message was lost in the network and will 466 retransmit it). That response MAY be a message with no payloads. The 467 request message in an INFORMATIONAL Exchange MAY also contain no 468 payloads. This is the expected way an endpoint can ask the other 469 endpoint to verify that it is alive. 471 ESP and AH SAs always exist in pairs, with one SA in each direction. 472 When an SA is closed, both members of the pair MUST be closed. When 473 SAs are nested, as when data (and IP headers if in tunnel mode) are 474 encapsulated first with IPcomp, then with ESP, and finally with AH 475 between the same pair of endpoints, all of the SAs MUST be deleted 476 together. Each endpoint MUST close the SAs it sends on and allow the 477 other endpoint to close the other SA in each pair. To delete an SA, 478 an INFORMATIONAL Exchange with one or more delete payloads is sent 479 listing the SPIs (as they would be placed in the headers of outbound 480 packets) of the SAs to be deleted. The recipient MUST close the 481 designated SAs. Normally, the reply in the INFORMATIONAL Exchange 482 will contain delete payloads for the paired SAs going in the other 483 direction. There is one exception. If by chance both ends of a set 484 of SAs independently decide to close them, each may send a delete 485 payload and the two requests may cross in the network. If a node 486 receives a delete request for SAs for which it has already issued a 487 delete request, it MUST delete the incoming SAs while processing the 488 request and the outgoing SAs while processing the response. In that 489 case, the responses MUST NOT include delete payloads for the deleted 490 SAs, since that would result in duplicate deletion and could in 491 theory delete the wrong SA. 493 A node SHOULD regard half open connections as anomalous and audit 494 their existence should they persist. Note that this specification 495 nowhere specifies time periods, so it is up to individual endpoints 496 to decide how long to wait. A node MAY refuse to accept incoming data 497 on half open connections but MUST NOT unilaterally close them and 498 reuse the SPIs. If connection state becomes sufficiently messed up, a 499 node MAY close the IKE-SA which will implicitly close all SAs 500 negotiated under it. It can then rebuild the SAs it needs on a clean 501 base under a new IKE-SA. 503 The INFORMATIONAL Exchange is defined as: 505 Initiator Responder 506 ----------- ----------- 507 HDR, SK {[N,] [D,] [CP,] ...} --> 508 <-- HDR, SK {[N,] [D,] [CP], ...} 510 The processing of an INFORMATIONAL Exchange is determined by its 511 component payloads. 513 1.5 Informational Messages outside of an IKE-SA 515 If a packet arrives with an unrecognised SPI, it could be because the 516 receiving node has recently crashed and lost state or because of some 517 other system malfunction or attack. If the receiving node has an 518 active IKE-SA to the IP address from whence the packet came, it MAY 519 send a notification of the wayward packet over that IKE-SA. If it 520 does not, it MAY send an Informational message without cryptographic 521 protection to the source IP address to alert it to a possible 522 problem. 524 2 IKE Protocol Details and Variations 526 IKE normally listens and sends on UDP port 500, though IKE messages 527 may also be received on UDP port 4500 with a slightly different 528 format (see section 2.23). Since UDP is a datagram (unreliable) 529 protocol, IKE includes in its definition recovery from transmission 530 errors, including packet loss, packet replay, and packet forgery. IKE 531 is designed to function so long as (1) at least one of a series of 532 retransmitted packets reaches its destination before timing out; and 533 (2) the channel is not so full of forged and replayed packets so as 534 to exhaust the network or CPU capacities of either endpoint. Even in 535 the absence of those minimum performance requirements, IKE is 536 designed to fail cleanly (as though the network were broken). 538 2.1 Use of Retransmission Timers 540 All messages in IKE exist in pairs: a request and a response. The 541 setup of an IKE-SA normally consists of two request/response pairs. 542 Once the IKE-SA is set up, either end of the security association may 543 initiate requests at any time, and there can be many requests and 544 responses "in flight" at any given moment. But each message is 545 labelled as either a request or a response and for each 546 request/response pair one end of the security association is the 547 Initiator and the other is the Responder. 549 For every pair of messages, the Initiator is responsible for 550 retransmission in the event of a timeout. The Responder MUST never 551 retransmit a response unless it receives a retransmission of the 552 request. In that event, the Responder MUST ignore the retransmitted 553 request except insofar as it triggers a retransmission of the 554 response. The Initiator MUST remember each request until it receives 555 the corresponding response. The Responder MUST remember each response 556 until it receives a request whose sequence number is larger than the 557 sequence number in the response plus his window size (see section 558 2.3). 560 IKE is a reliable protocol, in the sense that the Initiator MUST 561 retransmit a request until either it receives a corresponding reply 562 OR it deems the IKE security association to have failed and it 563 discards all state associated with the IKE-SA and any CHILD-SAs 564 negotiated using that IKE-SA. 566 2.2 Use of Sequence Numbers for Message ID 568 Every IKE message contains a Message ID as part of its fixed header. 569 This Message ID is used to match up requests and responses, and to 570 identify retransmissions of messages. 572 The Message ID is a 32 bit quantity, which is zero for the first IKE 573 request in each direction. The IKE-SA initial setup messages will 574 always be numbered 0 and 1. Each endpoint in the IKE Security 575 Association maintains two "current" Message IDs: the next one to be 576 used for a request it initiates and the next one it expects to see in 577 a request from the other end. These counters increment as requests 578 are generated and received. Responses always contain the same message 579 ID as the corresponding request. That means that after the initial 580 exchange, each integer n may appear as the message ID in four 581 distinct messages: The nth request from the original IKE Initiator, 582 the corresponding response, the nth request from the original IKE 583 Responder, and the corresponding response. If the two ends make very 584 different numbers of requests, the Message IDs in the two directions 585 can be very different. There is no ambiguity in the messages, 586 however, because each the (I)nitiator and (R)eply bits in the message 587 header specify which of the four messages a particular one is. 589 Note that Message IDs are cryptographically protected and provide 590 protection against message replays. In the unlikely event that 591 Message IDs grow too large to fit in 32 bits, the IKE SA MUST be 592 closed. Rekeying and IKE SA resets the sequence numbers. 594 2.3 Window Size for overlapping requests 596 In order to maximize IKE throughput, an IKE endpoint MAY issue 597 multiple requests before getting a response to any of them. For 598 simplicity, an IKE implementation MAY choose to process requests 599 strictly in order and/or wait for a response to one request before 600 issuing another. Certain rules must be followed to assure 601 interoperability between implementations using different strategies. 603 After an IKE-SA is set up, either end can initiate one or more 604 requests. These requests may pass one another over the network. An 605 IKE endpoint MUST be prepared to accept and process a request while 606 it has a request outstanding in order to avoid a deadlock in this 607 situation. An IKE endpoint SHOULD be prepared to accept and process 608 multiple requests while it has a request outstanding. 610 An IKE endpoint MUST wait for a response to each of its messages 611 before sending a subsequent message unless it has received a Notify 612 message from its peer informing it that the peer is prepared to 613 maintain state for multiple outstanding messages in order to allow 614 greater throughput. 616 An IKE endpoint MUST NOT exceed the peer's stated window size for 617 transmitted IKE requests. In other words, if Bob stated his window 618 size is N, then when Alice needs to make a request X, she MUST wait 619 until she has received responses to all requests up through request 620 X-N. An IKE endpoint MUST keep a copy of (or be able to regenerate 621 exactly) each request it has sent until it receives the corresponding 622 response. An IKE endpoint MUST keep a copy of (or be able to 623 regenerate exactly) the number of previous responses equal to its 624 declared window size in case its response was lost and the Initiator 625 requests its retransmission by retransmitting the request. 627 An IKE endpoint supporting a window size greater than one SHOULD be 628 capable of processing incoming requests out of order to maximize 629 performance in the event of network failures or packet reordering. 631 2.4 State Synchronization and Connection Timeouts 633 An IKE endpoint is allowed to forget all of its state associated with 634 an IKE-SA and the collection of corresponding CHILD-SAs at any time. 635 This is the anticipated behavior in the event of an endpoint crash 636 and restart. It is important when an endpoint either fails or 637 reinitializes its state that the other endpoint detect those 638 conditions and not continue to waste network bandwidth by sending 639 packets over those SAs and having them fall into a black hole. 641 Since IKE is designed to operate in spite of Denial of Service (DoS) 642 attacks from the network, an endpoint MUST NOT conclude that the 643 other endpoint has failed based on any routing information (e.g. ICMP 644 messages) or IKE messages that arrive without cryptographic 645 protection (e.g., notify messages complaining about unknown SPIs). An 646 endpoint MUST conclude that the other endpoint has failed only when 647 repeated attempts to contact it have gone unanswered for a timeout 648 period or when a cryptographically protected INITIAL-CONTACT 649 notification is received on a different IKE-SA to the same 650 authenticated identity. An endpoint SHOULD suspect that the other 651 endpoint has failed based on routing information and initiate a 652 request to see whether the other endpoint is alive. To check whether 653 the other side is alive, IKE specifies an empty INFORMATIONAL message 654 that (like all IKE requests) requires an acknowledgment. If a 655 cryptographically protected message has been received from the other 656 side recently, unprotected notifications MAY be ignored. 657 Implementations MUST limit the rate at which they take actions based 658 on unprotected messages. 660 Numbers of retries and lengths of timeouts are not covered in this 661 specification because they do not affect interoperability. It is 662 suggested that messages be retransmitted at least a dozen times over 663 a period of at least several minutes before giving up on an SA, but 664 different environments may require different rules. If there has only 665 been outgoing traffic on all of the SAs associated with an IKE-SA, it 666 is essential to confirm liveness of the other endpoint to avoid black 667 holes. If no cryptographically protected messages have been received 668 on an IKE-SA or any of its CHILD-SAs recently, a liveness check MUST 669 be performed. Receipt of a fresh cryptographically protected message 670 on an IKE-SA or any of its CHILD-SAs assures liveness of the IKE-SA 671 and all of its CHILD-SAs. Note that this places requirements on the 672 failure modes of an IKE endpoint. An implementation MUST NOT continue 673 sending on any SA if some failure prevents it from receiving on all 674 of the associated SAs. If CHILD-SAs can fail independently from one 675 another without the associated IKE-SA being able to send a delete 676 message, then they MUST be negotiated by separate IKE-SAs. 678 There is a Denial of Service attack on the Initiator of an IKE-SA 679 that can be avoided if the Initiator takes the proper care. Since the 680 first two messages of an SA setup are not cryptographically 681 protected, an attacker could respond to the Initiator's message 682 before the genuine Responder and poison the connection setup attempt. 683 To prevent this, the Initiator MAY be willing to accept multiple 684 responses to its first message, treat each as potentially legitimate, 685 respond to it, and then discard all the invalid half open connections 686 when she receives a valid cryptographically protected response to any 687 one of her requests. Once a cryptographically valid response is 688 received, all subsequent responses should be ignored whether or not 689 they are cryptographically valid. 691 Note that with these rules, there is no reason to negotiate and agree 692 upon an SA lifetime. If IKE presumes the partner is dead, based on 693 repeated lack of acknowledgment to an IKE message, then the IKE SA 694 and all CHILD-SAs set up through that IKE-SA are deleted. 696 An IKE endpoint may at any time delete inactive CHILD-SAs to recover 697 resources used to hold their state. If an IKE endpoint chooses to do 698 so, it MUST send Delete payloads to the other end notifying it of the 699 deletion. It MAY similarly time out the IKE-SA. Closing the IKE-SA 700 implicitly closes all associated CHILD-SAs. In this case, an IKE 701 endpoint SHOULD send a Delete payload indicating that it has closed 702 the IKE-SA. 704 2.5 Version Numbers and Forward Compatibility 706 This document describes version 2.0 of IKE, meaning the major version 707 number is 2 and the minor version number is zero. It is likely that 708 some implementations will want to support both version 1.0 and 709 version 2.0, and in the future, other versions. 711 The major version number should only be incremented if the packet 712 formats or required actions have changed so dramatically that an 713 older version node would not be able to interoperate with a newer 714 version node if it simply ignored the fields it did not understand 715 and took the actions specified in the older specification. The minor 716 version number indicates new capabilities, and MUST be ignored by a 717 node with a smaller minor version number, but used for informational 718 purposes by the node with the larger minor version number. For 719 example, it might indicate the ability to process a newly defined 720 notification message. The node with the larger minor version number 721 would simply note that its correspondent would not be able to 722 understand that message and therefore would not send it. 724 If an endpoint receives a message with a higher major version number, 725 it MUST drop the message and SHOULD send an unauthenticated 726 notification message containing the highest version number it 727 supports. If an endpoint supports major version n, and major version 728 m, it MUST support all versions between n and m. If it receives a 729 message with a major version that it supports, it MUST respond with 730 that version number. In order to prevent two nodes from being tricked 731 into corresponding with a lower major version number than the maximum 732 that they both support, IKE has a flag that indicates that the node 733 is capable of speaking a higher major version number. 735 Thus the major version number in the IKE header indicates the version 736 number of the message, not the highest version number that the 737 transmitter supports. If A is capable of speaking versions n, n+1, 738 and n+2, and B is capable of speaking versions n and n+1, then they 739 will negotiate speaking n+1, where A will set the flag indicating 740 ability to speak a higher version. If they mistakenly (perhaps 741 through an active attacker sending error messages) negotiate to 742 version n, then both will notice that the other side can support a 743 higher version number, and they MUST break the connection and 744 reconnect using version n+1. 746 Note that IKEv1 does not follow these rules, because there is no way 747 in v1 of noting that you are capable of speaking a higher version 748 number. So an active attacker can trick two v2-capable nodes into 749 speaking v1. When a v2-capable node negotiates down to v1, it SHOULD 750 note that fact in its logs. 752 Also for forward compatibility, all fields marked RESERVED MUST be 753 set to zero by a version 2.0 implementation and their content MUST be 754 ignored by a version 2.0 implementation ("Be conservative in what you 755 send and liberal in what you receive"). In this way, future versions 756 of the protocol can use those fields in a way that is guaranteed to 757 be ignored by implementations that do not understand them. 758 Similarly, payload types that are not defined are reserved for future 759 use and implementations of version 2.0 MUST skip over those payloads 760 and ignore their contents. 762 IKEv2 adds a "critical" flag to each payload header for further 763 flexibility for forward compatibility. If the critical flag is set 764 and the payload type is unrecognised, the message MUST be rejected 765 and the response to the IKE request containing that payload MUST 766 include a notify payload UNSUPPORTED-CRITICAL-PAYLOAD, indicating an 767 unsupported critical payload was included. If the critical flag is 768 not set and the payload type is unsupported, that payload MUST be 769 ignored. 771 While new payload types may be added in the future and may appear 772 interleaved with the fields defined in this specification, 773 implementations MUST send the payloads defined in this specification 774 in the order shown in section 3 and implementations SHOULD reject as 775 invalid a message with payloads in any other order. 777 2.6 Cookies 779 The term "cookies" originates with Karn and Simpson [RFC 2522] in 780 Photuris, an early proposal for key management with IPsec. It has 781 persisted because the IETF has never rejected a proposal involving 782 cookies. The ISAKMP fixed message header includes two eight octet 783 fields titled "cookies", and that syntax is used by both IKEv1 and 784 IKEv2 though in IKEv2 they are referred to as the IKE SPI and there 785 is a new separate field in a NOTIFY payload holding the cookie. The 786 initial two eight octet fields in the header are used as a connection 787 identifier at the beginning of IKE packets. Each endpoint chooses one 788 of the two SPIs and SHOULD choose them so as to be unique identifiers 789 of an IKE-SA. An SPI value of zero is special and indicates that the 790 remote SPI value is not yet known by the sender. 792 Unlike ESP and AH where only the recipient's SPI appears in the 793 header of a message, in IKE the sender's SPI is also sent in every 794 message. Since the SPI chosen by the original initiator of the IKE-SA 795 is always sent first, an endpoint with multiple IKE-SAs open that 796 wants to find the appropriate IKE-SA using the SPI it assigned must 797 look at the I(nitiator) Flag bit in the header to determine whether 798 it assigned the first or the second eight octets. 800 In the first message of an initial IKE exchange, the initiator will 801 not know the responder's SPI value and will therefore set that field 802 to zero. 804 An expected attack against IKE is state and CPU exhaustion, where the 805 target is flooded with session initiation requests from forged IP 806 addresses. This attack can be made less effective if an 807 implementation of a responder uses minimal CPU and commits no state 808 to an SA until it knows the initiator can receive packets at the 809 address from which he claims to be sending them. To accomplish this, 810 a responder SHOULD - when it detects a large number of half-open IKE- 811 SAs - reject initial IKE messages unless they contain a notify 812 payload of type "cookie". It SHOULD instead send an unprotected IKE 813 message as a response and include its cookie in a notify payload. 814 Initiators who receive such responses MUST retry the IKE_SA_INIT with 815 the responder supplied cookie as the first payload. The initial 816 exchange will then be as follows: 818 Initiator Responder 819 ----------- ----------- 820 HDR(A,0), SAi1, KEi, Ni --> 822 <-- HDR(A,0), N(COOKIE-REQUIRED), 823 N(COOKIE) 825 HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> 827 <-- HDR(A,B), SAr1, KEr, Nr, [CERTREQ] 829 HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,] 830 AUTH, SAi2, TSi, TSr} --> 832 <-- HDR(A,B), SK {IDr, [CERT,] AUTH, 833 SAr2, TSi, TSr} 835 The first two messages do not affect any initiator or responder state 836 except for communicating the cookie. In particular, the message 837 sequence numbers in the first four messages will all be zero and the 838 message sequence numbers in the last two messages will be one. 840 An IKE implementation SHOULD implement its responder cookie 841 generation is such a way as to not require any saved state to 842 recognise its valid cookie when the second IKE_SA_INIT message 843 arrives. The exact algorithms and syntax they use to generate 844 cookies does not affect interoperability and hence is not specified 845 here. The following is an example of how an endpoint could use 846 cookies to implement limited DOS protection. 848 A good way to do this is to set the responder cookie to be: 850 Cookie = | Hash(IPi | SPIi | ) 852 where is a randomly generated secret known only to the 853 responder and periodically changed. should be 854 changed whenever is regenerated. The cookie can be 855 recomputed when the IKE_SA_INIT arrives the second time and compared 856 to the cookie in the received message. If it matches, the responder 857 knows that SPIr was generated since the last change to and 858 that IPi must be the same as the source address it saw the first 859 time. Incorporating SPIi into the calculation assures that if 860 multiple IKE-SAs are being set up in parallel they will all get 861 different cookies (assuming the initiator chooses unique SPIi's). 863 If a new value for is chosen while there are connections in 864 the process of being initialized, an IKE_SA_INIT might be returned 865 with other than the current . The responder in 866 that case MAY reject the message by sending another response with a 867 new cookie or it MAY keep the old value of around for a 868 short time and accept cookies computed from either one. The 869 responder SHOULD NOT accept cookies indefinitely after is 870 changed, since that would defeat part of the denial of service 871 protection. 873 2.7 Cryptographic Algorithm Negotiation 875 The payload type known as "SA" indicates a proposal for a set of 876 choices of protocols (IKE, ESP, and/or AH) for the SA as well as 877 cryptographic algorithms associated with each protocol. 879 An SA consists of one or more proposals. Each proposal includes a 880 Suite-ID, which implies one or more protocols and the associated 881 cryptographic algorithms. 883 Since Alice sends her Diffie-Hellman value in the IKE_SA_INIT, she 884 must guess at the Diffie-Hellman group that Bob will select from her 885 list of supported cryptographic suites. If she guesses wrong, Bob 886 will respond with a NOTIFY payload of type INVALID-KE-PAYLOAD 887 indicating the selected cryptographic suite. In this case, Alice 888 MUST retry the IKE_SA_INIT with the corrected Diffie-Hellman group. 889 Alice MUST again propose her full set of acceptable cryptographic 890 suites because the rejection message was unauthenticated and 891 otherwise an active attacker could trick Alice and Bob into 892 negotiating a weaker suite than a stronger one that they both prefer. 894 2.8 Rekeying 896 IKE, ESP, and AH security associations use secret keys which SHOULD 897 only be used for a limited amount of time and to protect a limited 898 amount of data. This limits the lifetime of the entire security 899 association. When the lifetime of a security association expires the 900 security association MUST NOT be used. If there is demand, new 901 security associations MAY be established. Reestablishment of 902 security associations to take the place of ones which expire is 903 referred to as "rekeying". 905 To rekey a CHILD-SA, create a new, equivalent SA (see section 2.17 906 below), and when the new one is established, delete the old one. To 907 rekey an IKE-SA, establish a new equivalent IKE-SA (see section 2.18 908 below) with the peer to whom the old IKE-SA is shared using a 909 CREATE_CHILD_SA within the existing IKE-SA. An IKE-SA so created 910 inherits all of the original IKE-SA's CHILD-SAs. Use the new IKE-SA 911 for all control messages needed to maintain the CHILD-SAs created by 912 the old IKE-SA, and delete the old IKE-SA. The Delete payload to 913 delete itself MUST be the last request sent over an IKE-SA. 915 SAs SHOULD be rekeyed proactively, i.e., the new SA should be 916 established before the old one expires and becomes unusable. Enough 917 time should elapse between the time the new SA is established and the 918 old one becomes unusable so that traffic can be switched over to the 919 new SA. 921 A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes 922 were negotiated. In IKEv2, each end of the SA is responsible for 923 enforcing its own lifetime policy on the SA and rekeying the SA when 924 necessary. If the two ends have different lifetime policies, the end 925 with the shorter lifetime will end up always being the one to request 926 the rekeying. If an SA bundle has been inactive for a long time and 927 if an endpoint would not initiate the SA in the absense of traffic, 928 the endpoint MAY choose to close the SA instead of rekeying it when 929 its lifetime expires. It SHOULD do so if there has been no traffic 930 since the last time the SA was rekeyed. 932 If the two ends have the same lifetime policies, it is possible that 933 both will initiate a rekeying at the same time (which will result in 934 redundant SAs). To reduce the probability of this happening, the 935 timing of rekeying requests SHOULD be jittered (delayed by a random 936 amount of time after the need for rekeying is noticed). 938 This form of rekeying may temporarily result in multiple similar SAs 939 between the same pairs of nodes. When there are two SAs eligible to 940 receive packets, a node MUST accept incoming packets through either 941 SA. An endpoint SHOULD wait a random amount of time before closing a 942 redundant SA to prevent cycling. 944 The node that initiated the rekeyed SA SHOULD delete the replaced SA 945 after the new one is established. 947 2.9 Traffic Selector Negotiation 949 When an IP packet is received by an RFC2401 compliant IPsec subsystem 950 and matches a "protect" selector in its SPD, the subsystem MUST 951 protect that packet with IPsec. When no SA exists yet it is the task 952 of IKE to create it. Maintenance of of a system's SPD is outside the 953 scope of IKE (see [PFKEY] for an example protocol), though some 954 implementations might update their SPD in connection with the running 955 of IKE (for an example scenario, see section 1.1.3). 957 Traffic Selector (TS) payloads allow endpoints to communicate some of 958 the information from their SPD to their peers. TS payloads specify 959 the selection criteria for packets that will be forwarded over the 960 newly set up SA. This can serve as a consistency check in some 961 scenarios to assure that the SPDs are consistent. In others, it 962 guides the dynamic update of the SPD. 964 Two TS payloads appear in each of the messages in the exchange that 965 creates a CHILD-SA pair. Each TS payload contains one or more Traffic 966 Selectors. Each Traffic Selector consists of an address range (IPv4 967 or IPv6), a port range, and a protocol ID. In support of the scenario 968 described in section 1.1.3, an initiator may request that the 969 responder assign an IP address and tell the initiator what it is. 971 IKEv2 allows the responder to choose a subset of the traffic proposed 972 by the initiator. This could happen when the configuration of the 973 two endpoints are being updated but only one end has received the new 974 information. Since the two endpoints may be configured by different 975 people, the incompatibility may persist for an extended period even 976 in the absense of errors. It also allows for intentionally different 977 configurations, as when one end is configured to tunnel all addresses 978 and depends on the other end to have the up to date list. 980 The first of the two TS payloads is known as TSi (Traffic Selector- 981 initiator). The second is known as TSr (Traffic Selector-responder). 982 TSi specifies the source address of traffic forwarded from (or the 983 destination address of traffic forwarded to) the initiator of the 984 CHILD-SA pair. TSr specifies the destination address of the traffic 985 forwarded from (or the source address of the traffic forwarded to) 986 the responder of the CHILD-SA pair. For example, if Alice initiates 987 the creation of the CHILD-SA pair from Alice to Bob, and wishes to 988 tunnel all traffic from subnet 10.2.16.* on Alice's side to subnet 989 18.16.*.* on Bob's side, Alice would include a single traffic 990 selector in each TS payload. TSi would specify the address range 991 (10.2.16.0 - 10.2.16.255) and TSr would specify the address range 992 (18.16.0.0 - 18.16.255.255). Assuming that proposal was acceptable to 993 Bob, he would send identical TS payloads back. 995 The Responder is allowed to narrow the choices by selecting a subset 996 of the traffic, for instance by eliminating or narrowing the range of 997 one or more members of the set of traffic selectors, provided the set 998 does not become the NULL set. 1000 It is possible for the Responder's policy to contain multiple smaller 1001 ranges, all encompassed by the Initiator's traffic selector, and with 1002 the Responder's policy being that each of those ranges should be sent 1003 over a different SA. Continuing the example above, Bob might have a 1004 policy of being willing to tunnel those addresses to and from Alice, 1005 but might require that each address pair be on a separately 1006 negotiated CHILD-SA. If Alice generated her request in response to an 1007 incoming packet from 10.2.16.43 to 18.16.2.123, there would be no way 1008 for Bob to determine which pair of addresses should be included in 1009 this tunnel, and he would have to make his best guess or reject the 1010 request with a status of SINGLE-PAIR-REQUIRED. 1012 To enable Bob to choose the appropriate range in this case, if Alice 1013 has initiated the SA due to a data packet, Alice MAY include as the 1014 first traffic selector in each of TSi and TSr a very specific traffic 1015 selector including the addresses in the packet triggering the 1016 request. In the example, Alice would include in TSi two traffic 1017 selectors: the first containing the address range (10.2.16.43 - 1018 10.2.16.43) and the source port and protocol from the packet and the 1019 second containing (10.2.16.0 - 10.2.16.255) with all ports and 1020 protocols. She would similarly include two traffic selectors in TSr. 1022 If Bob's policy does not allow him to accept the entire set of 1023 traffic selectors in Alice's request, but does allow him to accept 1024 the first selector of TSi and TSr, then Bob MUST narrow the traffic 1025 selectors to a subset that includes Alice's first choices. In this 1026 example, Bob might respond with TSi being (10.2.16.43 - 10.2.16.43) 1027 with all ports and protocols. 1029 If Alice creates the CHILD-SA pair not in response to an arriving 1030 packet, but rather - say - upon startup, then there may be no 1031 specific addresses Alice prefers for the initial tunnel over any 1032 other. In that case, the first values in TSi and TSr MAY be ranges 1033 rather than specific values, and Bob chooses a subset of Alice's TSi 1034 and TSr that are acceptable to him. If more than one subset is 1035 acceptable but their union is not, Bob MUST accept some subset and 1036 MAY include a NOTIFY payload of type ADDITIONAL-TS-POSSIBLE to 1037 indicate that Alice might want to try again. This case will only 1038 occur when Alice and Bob are configured differently from one another. 1039 If Alice and Bob agree on the granularity of tunnels, she will never 1040 request a tunnel wider than Bob will accept. 1042 2.10 Nonces 1044 The IKE_SA_INIT messages each contain a nonce. These nonces are used 1045 as inputs to cryptographic functions. The CREATE_CHILD_SA request 1046 and the CREATE_CHILD_SA response also contain nonces. These nonces 1047 are used to add freshness to the key derivation technique used to 1048 obtain keys for CHILD-SAs. Nonces used in IKEv2 MUST therefore be 1049 randomly chosen and of size at least equal to the key size of the 1050 strongest cryptographic algorithm used. 1052 2.11 Address and Port Agility 1054 IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and 1055 AH associations for the same IP addresses it runs over. The IP 1056 addresses and ports in the outer header are, however, not themselves 1057 cryptographically protected, and IKE is designed to work even through 1058 Network Address Translation (NAT) boxes. An implementation MUST 1059 accept incoming connection requests even if not received from UDP 1060 port 500 or 4500, and MUST respond to the address and port from which 1061 the request was received. IKE functions identically over IPv4 or 1062 IPv6. 1064 2.12 Reuse of Diffie-Hellman Exponentials 1066 IKE generates keying material using an ephemeral Diffie-Hellman 1067 exchange in order to gain the property of "perfect forward secrecy". 1068 This means that once a connection is closed and its corresponding 1069 keys are forgotten, even someone who has recorded all of the data 1070 from the connection and gets access to all of the long term keys of 1071 the two endpoints cannot reconstruct the keys used to protect the 1072 conversation. 1074 Achieving perfect forward secrecy requires that when a connection is 1075 closed, each endpoint must forget not only the keys used by the 1076 connection but any information that could be used to recompute those 1077 keys. In particular, it must forget the secrets used in the Diffie- 1078 Hellman calculation and any state that may persist in the state of a 1079 pseudo-random number generater that could be used to recompute the 1080 Diffie-Hellman secrets. 1082 Since the computing of Diffie-Hellman exponentials is computationally 1083 expensive, an endpoint may find it advantageous to reuse those 1084 exponentials for multiple connection setups. There are several 1085 reasonable strategies for doing this. An endpoint could choose a new 1086 exponential only periodically though this could result in less-than- 1087 perfect forward secrecy if some connection lasts for less than the 1088 lifetime of the exponential. Or it could keep track of which 1089 exponential was used for each connection and delete the information 1090 associated with the exponential only when some corresponding 1091 connection was closed. This would allow the exponential to be reused 1092 without losing perfect forward secrecy at the cost of maintaining 1093 more state. 1095 Decisions as to whether and when to reuse Diffie-Hellman exponentials 1096 is a private decision in the sense that it will not affect 1097 interoperability. An implementation that reuses exponentials MAY 1098 choose to remember the exponential used by the other endpoint on past 1099 exchanges and if one is reused to avoid the second half of the 1100 calculation. 1102 2.13 Generating Keying Material 1103 In the context of the IKE-SA, three cryptographic algorithms are 1104 negotiated: an encryption algorithm, a Diffie-Hellman group, and a 1105 pseudo-random function (prf). The pseudo-random function is used both 1106 for integrity protection of the IKE payloads and for the construction 1107 of keying material for all of the cryptographic algorithms used in 1108 both the IKE-SA and the CHILD-SAs. 1110 We assume that each cryptographic algorithm accepts a fixed size key, 1111 and that any randomly chosen value of that fixed size can serve as an 1112 appropriate key. For functions that accept a variable length key, a 1113 fixed key size MUST be specified as part of the cryptographic suite 1114 negotiated. For prf functions based on HMAC, the fixed key size is 1115 the size of the output of the HMAC. 1117 Keying material will always be derived as the output of the 1118 negotiated prf algorithm. Since the amount of keying material needed 1119 may be greater than the size of the output of the prf algorithm, we 1120 will use the prf iteratively. We will use the terminology prf+ to 1121 describe the function that outputs a pseudo-random stream based on 1122 the inputs to a prf as follows: (where | indicates concatenation) 1124 prf+ (K,S) = T1 | T2 | T3 | T4 | ... 1126 where: 1127 T1 = prf (K, S | 0x01) 1128 T2 = prf (K, T1 | S | 0x02) 1129 T3 = prf (K, T2 | S | 0x03) 1130 T4 = prf (K, T3 | S | 0x04) 1132 continuing as needed to compute all required keys. The keys are taken 1133 from the output string without regard to boundaries (e.g. if the 1134 required keys are a 256 bit AES key and a 160 bit HMAC key, and the 1135 prf function generates 160 bits, the AES key will come from T1 and 1136 the beginning of T2, while the HMAC key will come from the rest of T2 1137 and the beginning of T3). 1139 The constant concatenated to the end of each string feeding the prf 1140 is a single octet. prf+ in this document is not defined beyond 255 1141 times the size of the prf output. 1143 2.14 Generating Keying Material for the IKE-SA 1145 The shared keys are computed as follows. A quantity called SKEYSEED 1146 is calculated from the nonces exchanged during the IKE_SA_INIT 1147 exchange and the Diffie-Hellman shared secret established during that 1148 exchange. SKEYSEED is used to calculate five other secrets: SK_d 1149 used for deriving new keys for the CHILD-SAs established with this 1150 IKE-SA; SK_ai and SK_ar used as a key to the prf algorithm for 1151 authenticating the component messages of subsequent exchanges; and 1152 SK_ei and SK_er used for encrypting (and of course decrypting) all 1153 subsequent exchanges. SKEYSEED and its derivatives are computed as 1154 follows: 1156 SKEYSEED = prf(Ni | Nr, g^ir) 1158 {SK_d, SK_ai, SK_ar, SK_ei, SK_er} 1159 = prf+ (SKEYSEED, g^ir | Ni | Nr | SPIi | SPIr ) 1161 (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, and SK_er 1162 are taken in order from the generated bits of the prf+). g^ir is the 1163 shared secret from the ephemeral Diffie-Hellman exchange. g^ir is 1164 represented as a string of octets in big endian order padded with 1165 zeros if necessary to make it the length of the modulus. Ni and Nr 1166 are the nonces, stripped of any headers. 1168 The two directions of flow use different keys. The keys used to 1169 protect messages from the original initiator are SK_ai and SK_ei. The 1170 keys used to protect messages in the other direction are SK_ar and 1171 SK_er. Each algorithm takes a fixed number of bits of keying 1172 material, which is specified as part of the algorithm. For integrity 1173 algorithms based on HMAC, the key size is always equal to the length 1174 of the underlying hash function. 1176 2.15 Authentication of the IKE-SA 1178 When not using extended authentication (see section 2.16), the peers 1179 are authenticated by having each sign (or MAC using a shared secret 1180 as the key) a block of data. For the responder, the octets to be 1181 signed start with the first octet of the first SPI in the header of 1182 the second message and end with the last octet of the last payload in 1183 the second message. Appended to this (for purposes of computing the 1184 signature) is the initiator's nonce Ni (just the value, not the 1185 payload containing it) and the contents of the responder's ID payload 1186 (excluding fixed header). Similarly, the initiator signs the first 1187 message, starting with the first octet of the first SPI in the header 1188 and ending with the last octet of the last payload. Appended to this 1189 (for purposes of computing the signature) is the responder's nonce Nr 1190 and the initiator's ID payload (excluding fixed header). It is 1191 critical to the security of the exchange that each side sign the 1192 other side's nonce. 1194 Note that all of the payloads are included under the signature, 1195 including any payload types not defined in this document. If the 1196 first message of the exchange is sent twice (the second time with a 1197 responder cookie and/or a different Diffie-Hellman group), it is the 1198 second version of the message that is signed. 1200 Optionally, messages 3 and 4 MAY include a certificate, or 1201 certificate chain providing evidence that the key used to compute a 1202 digital signature belongs to the name in the ID payload. The 1203 signature or MAC will be computed using algorithms dictated by the 1204 type of key used by the signer, an RSA-signed PKCS1-padded-hash for 1205 an RSA digital signature, a DSS-signed SHA1-hash for a DSA digital 1206 signature, or the negotiated PRF function for a pre-shared key. 1207 There is no requirement that the Initiator and Responder sign with 1208 the same cryptographic algorithms. The choice of cryptographic 1209 algorithms depends on the type of key each has. This type is either 1210 indicated in the certificate supplied or, if the keys were exchanged 1211 out of band, the key types must have been similarly learned. In 1212 particular, the initiator may be using a shared key while the 1213 responder may have a public signature key and certificate. It will 1214 commonly be the case (but it is not required) that if a shared secret 1215 is used for authentication that the same key is used in both 1216 directions. Note that it is a common but insecure practice to have a 1217 shared key derived from a user chosen password. This is insecure 1218 because user chosen passwords are unlikely to have sufficient 1219 randomness to resist dictionary attacks. The pre-shared key SHOULD 1220 contain as much randomness as the strongest key being negotiated. In 1221 the case of a pre-shared key, the AUTH value is computed as: 1223 AUTH = prf(Shared Secret | "Key Pad for IKEv2", ) 1225 where the string "Key Pad for IKEv2" is ASCII encoded and not null 1226 terminated. The shared secret can be variable length. The pad string 1227 is added so that if the shared secret is derived from a password, 1228 this exchange will not compromise use of the same password in other 1229 protocols. As noted above, deriving the shared secret from a 1230 password is not secure. This construction is used because it is 1231 anticipated that people will do it anyway. 1233 2.16 Extended Authentication Protocol Methods 1235 In addition to authentication using public key signatures and shared 1236 secrets, IKE supports authentication using methods defined in RFC 1237 2284 [EAP]. Typically, these methods are asymmetric (designed for a 1238 user authenticating to a server), and they may not be mutual. For 1239 this reason, these protocols are typically used to authenticate the 1240 initiator to the responder and are used in addition to a public key 1241 signature based authentication of the responder to the initator. 1242 These methods are also referred to as "Legacy Authentication" 1243 mechanisms. 1245 While this memo references [EAP] with the intent that new methods can 1246 be added in the future without updating this specification, the 1247 protocols expected to be used most commonly are fully documented here 1248 and in section 3.16. [EAP] defines an authentication protocol 1249 requiring a variable number of messages. Extended Authentication is 1250 implemented in IKE as additional IKE_AUTH exchanges that MUST be 1251 completed in order to initialize the IKE-SA. 1253 An initiator indicates a desire to use extended authentication by 1254 leaving out the AUTH payload from message 3. By including an IDi 1255 payload but not an AUTH payload, the initiator has declared an 1256 identity but has not proven it. If the responder is willing to use an 1257 extended authentication method, it will place an EAP payload in 1258 message 4 and defer sending SAr2, TSi, and TSr until initiator 1259 authentication is complete in a subsequent IKE_AUTH exchange. In the 1260 case of a minimal extended authentication, the initial SA 1261 establishment will appear as follows: 1263 Initiator Responder 1264 ----------- ----------- 1265 HDR, SAi1, KEi, Ni --> 1267 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 1269 HDR, SK {IDi, [CERTREQ,] [IDr,] 1270 SAi2, TSi, TSr} --> 1272 <-- HDR, SK {IDr, [CERT,] AUTH, 1273 EAP } 1275 HDR, SK {EAP, [AUTH] } --> 1277 <-- HDR, SK {EAP, [AUTH], 1278 SAr2, TSi, TSr } 1280 For EAP methods that create a shared key as a side effect of 1281 authentication, that shared key MUST be used by both the Initiator 1282 and Responder to generate an AUTH payload using the syntax for shared 1283 secrets specified in section 2.15. This shared key MUST NOT be used 1284 for any other purpose. 1286 The Initiator of an IKE-SA using EAP SHOULD be capable of extending 1287 the initial protocol exchange to at least ten IKE_AUTH exchanges in 1288 the event the Responder sends notification messages and/or retries 1289 the authentication prompt. The protocol terminates when the Responder 1290 sends the Initiator and EAP payload containing either a success or 1291 failure type. 1293 2.17 Generating Keying Material for CHILD-SAs 1295 CHILD-SAs are created either by being piggybacked on the IKE_AUTH 1296 exchange, or in a CREATE_CHILD_SA exchange. Keying material for them 1297 is generated as follows: 1299 KEYMAT = prf+(SK_d, Ni | Nr) 1301 Where Ni and Nr are the Nonces from the IKE_SA_INIT exchange if this 1302 request is the first CHILD-SA created or the fresh Ni and Nr from the 1303 CREATE_CHILD_SA exchange if this is a subsequent creation. 1305 For CREATE_CHILD_SA exchanges with PFS the keying material is defined 1306 as: 1308 KEYMAT = prf+(SK_d, g^ir (ph2) | Ni | Nr ) 1310 where g^ir (ph2) is the shared secret from the ephemeral Diffie- 1311 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 1312 octet string in big endian order padded with zeros if necessary to 1313 make it the length of the modulus), 1315 A single CHILD-SA negotiation may result in multiple security 1316 associations. ESP and AH SAs exist in pairs (one in each direction), 1317 and four SAs could be created in a single CHILD-SA negotiation if a 1318 combination of ESP and AH is being negotiated. KEYMAT is generated 1319 as described in section 2.13. 1321 Keying material is taken from the expanded KEYMAT in the following 1322 order: 1324 All keys for SAs carrying data from the initiator to the responder 1325 are taken before SAs going in the reverse direction. 1327 If multiple protocols are negotiated, keying material is taken in 1328 the order in which the protocol headers will appear in the 1329 encapsulated packet. 1331 If a single protocol has both encryption and authentication keys, 1332 the encryption key is taken from the first octets of KEYMAT and 1333 the authentication key is taken from the next octets. 1335 Each cryptographic algorithm takes a fixed number of bits of keying 1336 material specified as part of the algorithm. 1338 2.18 Rekeying IKE-SAs using a CREATE_CHILD_SA exchange 1340 The CREATE_CHILD_SA exchange can be used to re-key an existing IKE-SA 1341 (see section 2.8). New Initiator and Responder SPIs are supplied in 1342 the SPI fields. The TS payloads are omitted when rekeying an IKE-SA. 1343 SKEYSEED for the new IKE-SA is computed using SK_d from the existing 1344 IKE-SA as follows: 1346 SKEYSEED = prf(SK_d (old), [g^ir (ph2)] | Ni | Nr) 1348 where g^ir (ph2) is the shared secret from the ephemeral Diffie- 1349 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 1350 octet string in big endian order padded with zeros if necessary to 1351 make it the length of the modulus) and Ni and Nr are the two nonces 1352 stripped of any headers. 1354 The new IKE-SA MUST reset its message counters to 0. 1356 SK_d, SK_ai, SK_ar, and SK_ei, and SK_er are computed from SKEYSEED 1357 as specified in section 2.14. 1359 2.19 Requesting an internal address on a remote network 1361 Most commonly in the endpoint to gateway scenario, an endpoint may 1362 need an IP address on the gateway's internal network, and may need to 1363 have that address dynamically assigned. A request for such a 1364 temporary address can be included in any request to create a CHILD-SA 1365 (including the implicit request in message 3) by including a CP 1366 payload. 1368 This function provides address allocation to an IRAC trying to tunnel 1369 into a network protected by an IRAS. Since the IKE_AUTH exchange 1370 creates an IKE-SA and a CHILD-SA the IRAC MUST request the internal 1371 address, and optionally other information concerning the internal 1372 network, in the IKE_AUTH exchange. The may IRAS procure an internal 1373 address for the IRAC from any number of sources such as a DHCP/BOOTP 1374 server or its own address pool. 1376 Initiator Responder 1377 ----------------------------- --------------------------- 1378 HDR, SK {IDi, [CERT,] [CERTREQ,] 1379 [IDr,] AUTH, CP(CFG_REQUEST), 1380 SAi2, TSi, TSr} --> 1382 <-- HDR, SK {IDr, [CERT,] AUTH, 1383 CP(CFG_REPLY), SAr2, 1384 TSi, TSr} 1386 In all cases, the CP payload MUST be inserted immediately before the 1387 SA payload. In variations of the protocol where there are multiple 1388 IKE_AUTH exchanges, the CP payloads MUST be inserted in the messages 1389 containing the SA payloads. 1391 CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute 1392 (either IPv4 or IPv6) but MAY contain any number of additional 1393 attributes the initiator wants returned in the response. 1395 For example, message from Initiator to Responder: 1396 CP(CFG_REQUEST)= 1397 INTERNAL_ADDRESS(0.0.0.0) 1398 INTERNAL_NETMASK(0.0.0.0) 1399 INTERNAL_DNS(0.0.0.0) 1400 TSi = (0, 0-65536,0.0.0.0-255.255.255.255) 1401 TSr = (0, 0-65536,0.0.0.0-255.255.255.255) 1403 NOTE: Traffic Selectors are a (protocol, port range, address range) 1405 Message from Responder to Initiator: 1407 CP(CFG_REPLY)= 1408 INTERNAL_ADDRESS(192.168.219.202) 1409 INTERNAL_NETMASK(255.255.255.0) 1410 INTERNAL_SUBNET(192.168.219.0/255.255.255.0) 1411 TSi = (0, 0-65536,192.168.219.202-192.168.219.202) 1412 TSr = (0, 0-65536,192.168.219.0-192.168.219.255) 1414 All returned values will be implementation dependent. As can be seen 1415 in the above example, the IRAS MAY also send other attributes that 1416 were not included in CP(CFG_REQUEST) and MAY ignore the non- 1417 mandatory attributes that it does not support. 1419 2.20 Requesting the Peer's Version 1421 An IKE peer wishing to inquire about the other peer's version 1422 information MUST use the method below. This is an example of a 1423 configuration request within an INFORMATIONAL Exchange, after the 1424 IKE-SA and first CHILD-SA have been created. 1426 An IKE implementation MAY decline to give out version information 1427 prior to authentication or even after authentication to prevent 1428 trolling in case some implementation is known to have some security 1429 weakness. In that case, it MUST either return an empty string or no 1430 CP payload if CP is not supported. 1432 Initiator Responder 1433 ----------------------------- -------------------------- 1434 HDR, SK{CP(CFG_REQUEST)} --> 1435 <-- HDR, SK{CP(CFG_REPLY)} 1437 CP(CFG_REQUEST)= 1438 APPLICATION_VERSION("") 1440 CP(CFG_REPLY) 1441 APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar Inc.") 1443 2.21 Error Handling 1445 There are many kinds of errors that can occur during IKE processing. 1446 If a request is received that is badly formatted or unacceptable for 1447 reasons of policy (e.g. no matching cryptographic algorithms), the 1448 response MUST contain a Notify payload indicating the error. If an 1449 error occurs outside the context of an IKE request (e.g. the node is 1450 getting ESP messages on a non-existent SPI), the node SHOULD initiate 1451 an INFORMATIONAL Exchange with a Notify payload describing the 1452 problem. 1454 Errors that occur before a cryptographically protected IKE-SA is 1455 established must be handled very carefully. There is a trade-off 1456 between wanting to be helpful in diagnosing a problem and responding 1457 to it and wanting to avoid being a dupe in a denial of service attack 1458 based on forged messages. 1460 If a node receives a message on UDP port 500 outside the context of 1461 an IKE-SA known to it (and not a request to start one), it may be the 1462 result of a recent crash of the node. If the message is marked as a 1463 response, the node MAY audit the suspicious event but MUST NOT 1464 respond. If the message is marked as a request, the node MAY audit 1465 the suspicious event and MAY send a response. If a response is sent, 1466 the response MUST be sent to the IP address and port from whence it 1467 came with the same IKE SPIs and the Message ID copied. The response 1468 MUST NOT be cryptographically protected and MUST contain a notify 1469 payload indicating INVALID-SPI. 1471 A node receiving such an unprotected NOTIFY payload MUST NOT respond 1472 and MUST NOT change the state of any existing SAs. The message might 1473 be a forgery or might be a response the genuine correspondent was 1474 tricked into sending. A node SHOULD treat such a message (and also a 1475 network message like ICMP destination unreachable) as a hint that 1476 there might be problems with SAs to that IP address and SHOULD 1477 initiate a liveness test for any such IKE-SA. An implementation 1478 SHOULD limit the frequency of such tests to avoid being tricked into 1479 participating in a denial of service attack. 1481 A node receiving a suspicious message from an IP address with which 1482 it has an IKE-SA MAY send an IKE notify payload in an IKE 1483 INFORMATIONAL exchange over that SA. The recipient MUST NOT change 1484 the state of any SA's as a result but SHOULD audit the event to aid 1485 in diagnosing malfunctions. A node MUST limit the rate at which it 1486 will send messages in response to unprotected messages. 1488 2.22 IPcomp 1490 Use of IP compression [IPCOMP] can be negotiated as part of the setup 1491 of a CHILD-SA. While IP compression involves an extra header in each 1492 packet and a CPI (compression parameter index), the virtual 1493 "compression association" has no life outside the ESP or AH SA that 1494 contains it. Compression associations disappear when the 1495 corresponding ESP or AH SA goes away, and is not explicitly mentioned 1496 in any DELETE payload. 1498 Negotiation of IP compression is separate from the negotiation of 1499 cryptographic parameters associated with a CHILD-SA. A node 1500 requesting a CHILD-SA MAY advertise its support for one or more 1501 compression algorithms though one or more NOTIFY payloads of type 1502 IPCOMP_SUPPORTED. The response MAY indicate acceptance of a single 1503 compression algorithm with a NOTIFY payload of type IPCOMP_SUPPORTED. 1504 These payloads MAY ONLY occur in the same messages that contain SA 1505 payloads. 1507 While there has been discussion of allowing multiple compression 1508 algorithms to be accepted and to have different compression 1509 algorithms available for the two directions of a CHILD-SA, 1510 implementations of this specification MUST NOT accept an IPcomp 1511 algorithm that was not proposed, MUST NOT accept more than one, and 1512 MUST NOT compress using an algorithm other than one proposed and 1513 accepted in the setup of the CHILD-SA. 1515 A side effect of separating the negotiation of IPcomp from 1516 cryptographic parameters is that it is not possible to propose 1517 multiple cryptographic suites and propose IP compression with some of 1518 them but not others. 1520 2.23 NAT Traversal 1522 NAT (Network Address Translation) gateways are a controversial 1523 subject. This appendix briefly describes what they are and how they 1524 are likely to act on IKE traffic. Many people believe that NATs are 1525 evil and that we should not design our protocols so as to make them 1526 work better. IKEv2 does specify some unintuitive processing rules in 1527 order that NATs are more likely to work. 1529 NATs exist primarily because of the shortage of IPv4 addresses, 1530 though there are other rationales. IP nodes that are "behind" a NAT 1531 have IP addresses that are not globally unique, but rather are 1532 assigned from some space that is unique within the network behind the 1533 NAT but which are likely to be reused by nodes behind other NATs. 1534 Generally, nodes behind NATs can communicate with other nodes behind 1535 the same NAT and with nodes with globally unique addresses, but not 1536 with nodes behind other NATs. There are exceptions to that rule. 1537 When those nodes make connections to nodes on the real Internet, the 1538 NAT gateway "translates" the IP source address to an address that 1539 will be routed back to the gateway. Messages to the gateway from the 1540 Internet have their destination addresses "translated" to the 1541 internal address that will route the packet to the correct endnode. 1543 NATs are designed to be "transparent" to endnodes. Neither software 1544 on the node behind the NAT nor the node on the Internet require 1545 modification to communicate through the NAT. Achieving this 1546 transparency is more difficult with some protocols than with others. 1547 Protocols that include IP addresses of the endpoints within the 1548 payloads of the packet will fail unless the NAT gateway understands 1549 the protocol and modifies the internal references as well as those in 1550 the headers. Such knowledge is inherently unreliable, is a network 1551 layer violation, and often results in subtle problems. 1553 Opening an IPsec connection through a NAT introduces special 1554 problems. If the connection runs in transport mode, changing the IP 1555 addresses on packets will cause the checksums to fail and the NAT 1556 cannot correct the checksums because they are cryptographically 1557 protected. Even in tunnel mode, there are routing problems because 1558 transparently translating the addresses of AH and ESP packets 1559 requires special logic in the NAT and that logic is heuristic and 1560 unreliable in nature. For that reason, IKEv2 can negotiate UDP 1561 encapsulation of IKE, ESP, and AH packets. This encoding is slightly 1562 less efficient but is easier for NATs to process. In addition, 1563 firewalls may be configured to pass IPsec traffic over UDP but not 1564 ESP/AH or vice versa. 1566 It is a common practice of NATs to translate TCP and UDP port numbers 1567 as well as addresses and use the port numbers of inbound packets to 1568 decide which internal node should get a given packet. For this 1569 reason, even though IKE packets MUST be sent from and to UDP port 1570 500, they SHOULD be accepted coming from any port and responses 1571 SHOULD be sent to the port from whence they came. This is because the 1572 ports may be modified as the packets pass through NATs. Similarly, IP 1573 addresses of the IKE endpoints are generally not included in the IKE 1574 payloads because the payloads are cryptographically protected and 1575 could not be transparently modified by NATs. 1577 Port 4500 is reserved for UDP encapsulated ESP, AH, and IKE. When 1578 working through a NAT, it is generally better to pass IKE packets 1579 over port 4500 because some older NATs modify IKE traffic on port 500 1580 in an attempt to transparently establish IPsec connections. Such NATs 1581 may interfere with the straightforward NAT traversal envisioned by 1582 this document, so an IPsec endpoint that discovers a NAT between it 1583 and its correspondent SHOULD send all subsequent traffic to and from 1584 port 4500, which all NATs should know run the NAT-friendly protocol. 1586 The specific requirements for supporting NAT traversal are listed 1587 below. Support for NAT traversal is optional. In this section only, 1588 requirements listed as MUST only apply to implementations supporting 1589 NAT. 1591 IKE MUST listen on port 4500 as well as port 500. IKE MUST respond 1592 to the IP address and port from which packets arrived. 1594 The IKE responder MUST include in its IKE_SA_INIT response Notify 1595 payloads of type NAT-DETECTION-SOURCE-IP and NAT-DETECTION- 1596 DESTINATION-IP. The IKE initiator MUST check these payloads if 1597 present and if they do not match the addresses in the outer packet 1598 MUST tunnel all future IKE, ESP, and AH packets associated with 1599 this IKE-SA over UDP port 4500. 1601 2.24 ECN Notification 1603 Sections 5.1.2.1 and 5.1.2.2 of [RFC 2401] specify that the IPv4 TOS 1604 byte and IPv6 traffic class octet are to be copied from the inner 1605 header to the outer header by the encapsulator and that the outer 1606 header is to be discarded (no change to inner header) by the 1607 decapsulator. If ECN is in use, ECT codepoints will be copied to the 1608 outer header, but if a router within the tunnel changes an ECT 1609 codepoint to a CE codepoint to indicate congestion, that indication 1610 will be discarded by the decapsulator. This behavior is highly 1611 undesirable, and Section 9.2 of [RFC 3168] specifies changes to IPsec 1612 to avoid it. These changes include two ECN operating modes and 1613 negotiation support to detect and cope with IPsec decapsulators that 1614 discard ECN congestion indications; use of ECN in the outer IP header 1615 of IPsec tunnels is not permitted when such discarding is a 1616 possibility. 1618 In order to avoid multiple ECN operating modes and negotiation, 1619 tunnel decapsulators for tunnel-mode Security Associations (SAs) 1620 created by IKEv2 MUST implement the following modifications to 1621 prevent discarding of ECN congestion indications. IKEv2 tunnel- mode 1622 SA negotiation is handled by the USE-TRANSPORT-MODE notify message 1623 type (see Section 5.10.1 of [IKEv2]). The following modifications 1624 *replace* Section 9.2 of RFC 3168 and *update* Sections 5.1.2.1 and 1625 5.1.2.2 of RFC 2401. 1627 Encapsulation and Decapsulation of packets for a tunnel-mode SA 1628 created by IKEv2 MUST NOT follow the modifications specified by 1629 Section 9.2 of RFC 3168 and its subsections. Instead, the following 1630 modifications to encapsulation and decapsulation in Sections 5.1.2.1 1631 and 5.1.2.2 of RFC 2401 MUST be performed: 1633 Outer Hdr at Inner Hdr at 1634 IPv4 Encapsulator Decapsulator 1635 Header fields: -------------------- ------------ 1636 DS Field copied from inner hdr (5) no change 1637 ECN Field copied from inner hdr constructed (7) 1638 IPv6 1639 Header fields: 1640 DS Field copied from inner hdr (6) no change 1641 ECN Field copied from inner hdr constructed (7) 1643 (5)(6) If the packet will immediately enter a domain for which the 1644 DSCP value in the outer header is not appropriate, that value MUST 1645 be mapped to an appropriate value for the domain [RFC 2474]. Also 1646 see [RFC 2475] for further information. 1648 (7) If the ECN field in the inner header is set to ECT(0) or 1649 ECT(1) and the ECN field in the outer header is set to CE, then 1650 set the ECN field in the inner header to CE, otherwise make no 1651 change to the ECN field in the inner header. 1653 (5) and (6) are identical to match usage in [RFC2401], although 1654 they are different in [RFC2401]. These actions are not related to 1655 ECN, but are required for Differentiated Services support. They 1656 are carried over to this document from RFC 3168 so that all of RFC 1657 3168's changes to IPsec can be made non-applicable to SAs created 1658 by IKEv2. 1660 3 Header and Payload Formats 1662 3.1 The IKE Header 1664 IKE messages use UDP ports 500 and/or 4500, with one IKE message per 1665 UDP datagram. Information from the UDP header is largely ignored 1666 except that the IP addresses and UDP ports from the headers are 1667 reversed and used for return packets. When sent on UDP port 500, IKE 1668 messages begin immediately following the UDP header. When sent on UDP 1669 port 4500, IKE messages have prepended four octets of zero. These 1670 four octets of zero are not part of the IKE message and are not 1671 included in any of the length fields or checksums defined by IKE. 1672 Each IKE message begins with the IKE header, denoted HDR in this 1673 memo. Following the header are one or more IKE payloads each 1674 identified by a "Next Payload" field in the preceding payload. 1675 Payloads are processed in the order in which they appear in an IKE 1676 message by invoking the appropriate processing routine according to 1677 the "Next Payload" field in the IKE header and subsequently according 1678 to the "Next Payload" field in the IKE payload itself until a "Next 1679 Payload" field of zero indicates that no payloads follow. If a 1680 payload of type "Encrypted" is found, that payload is decrypted and 1681 its contents parsed as additional payloads. An Encrypted payload MUST 1682 be the last payload in a packet and an encrypted payload MUST NOT 1683 contain another encrypted payload. 1685 The Recipient SPI in the header identifies an instance of an IKE 1686 security association. It is therefore possible for a single instance 1687 of IKE to multiplex distinct sessions with multiple peers. 1689 All multi-octet fields representing integers are laid out in big 1690 endian order (aka most significant byte first, or network byte 1691 order). 1693 The format of the IKE header is shown in Figure 4. 1694 1 2 3 1695 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 1696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1697 ! IKE-SA Initiator's SPI ! 1698 ! ! 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 ! IKE-SA Responder's SPI ! 1701 ! ! 1702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1703 ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! 1704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1705 ! Message ID ! 1706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1707 ! Length ! 1708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 Figure 4: IKE Header Format 1712 o Initiator's SPI (8 octets) - A value chosen by the 1713 initiator to identify a unique IKE security association. This 1714 value MUST NOT be zero. 1716 o Responder's SPI (8 octets) - A value chosen by the 1717 responder to identify a unique IKE security association. This 1718 value MUST be zero in the first message of an IKE Initial 1719 Exchange and MUST NOT be zero in any other message other 1720 than a cookie request (see section 2.6). 1722 o Next Payload (1 octet) - Indicates the type of payload that 1723 immediately follows the header. The format and value of each 1724 payload is defined below. 1726 o Major Version (4 bits) - indicates the major version of the IKE 1727 protocol in use. Implementations based on this version of IKE 1728 MUST set the Major Version to 2. Implementations based on 1729 previous versions of IKE and ISAKMP MUST set the Major Version 1730 to 1. Implementations based on this version of IKE MUST reject 1731 (or ignore) messages containing a version number greater than 1732 2. 1734 o Minor Version (4 bits) - indicates the minor version of the 1735 IKE protocol in use. Implementations based on this version of 1736 IKE MUST set the Minor Version to 0. They MUST ignore the minor 1737 version number of received messages. 1739 o Exchange Type (1 octet) - indicates the type of exchange being 1740 used. This dictates the payloads sent in each message and 1741 message orderings in the exchanges. 1743 Exchange Type Value 1745 RESERVED 0 1746 Reserved for ISAKMP 1-31 1747 Reserved for IKEv1 32-33 1748 IKE_SA_INIT 34 1749 IKE_AUTH 35 1750 CREATE_CHILD_SA 36 1751 INFORMATIONAL 37 1752 Reserved for IKEv2+ 38-239 1753 Reserved for private use 240-255 1755 o Flags (1 octet) - indicates specific options that are set 1756 for the message. Presence of options are indicated by the 1757 appropriate bit in the flags field being set. The bits are 1758 defined LSB first, so bit 0 would be the least significant 1759 bit of the Flags octet. In the description below, a bit 1760 being 'set' means its value is '1', while 'cleared' means 1761 its value is '0'. 1763 -- X(reserved) (bits 0-2) - These bits MUST be cleared 1764 when sending and MUST be ignored on receipt. 1766 -- I(nitiator) (bit 3 of Flags) - This bit MUST be set in 1767 messages sent by the original Initiator of the IKE-SA 1768 and MUST be cleared in messages sent by the original 1769 Responder. It is used by the recipient to determine 1770 which eight bytes of the SPI was generated by the 1771 recipient. 1773 -- V(ersion) (bit 4 of Flags) - This bit indicates that 1774 the transmitter is capable of speaking a higher major 1775 version number of the protocol than the one indicated 1776 in the major version number field. Implementations of 1777 IKEv2 must clear this bit when sending and MUST ignore 1778 it in incoming messages. 1780 -- R(esponse) (bit 5 of Flags) - This bit indicates that 1781 this message is a response to a message containing 1782 the same message ID. This bit MUST be cleared in all 1783 request messages and MUST be set in all responses. 1784 An IKE endpoint MUST NOT generate a response to a 1785 message that is marked as being a response. 1787 -- X(reserved) (bits 6-7 of Flags) - These bits MUST be 1788 cleared when sending and MUST be ignored on receipt. 1790 o Message ID (4 octets) - Message identifier used to control 1791 retransmission of lost packets and matching of requests and 1792 responses. See section 2.2. 1794 o Length (4 octets) - Length of total message (header + payloads) 1795 in octets. 1797 3.2 Generic Payload Header 1799 Each IKE payload defined in sections 3.3 through 3.16 begins with a 1800 generic header, shown in Figure 5. Figures for each payload below 1801 will include the generic payload header but for brevity the 1802 description of each field will be omitted. 1804 1 2 3 1805 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 1806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1807 ! Next Payload !C! RESERVED ! Payload Length ! 1808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1810 Figure 5: Generic Payload Header 1812 The Generic Payload Header fields are defined as follows: 1814 o Next Payload (1 octet) - Identifier for the payload type of the 1815 next payload in the message. If the current payload is the last 1816 in the message, then this field will be 0. This field provides 1817 a "chaining" capability whereby additional payloads can be 1818 added to a message by appending it to the end of the message 1819 and setting the "Next Payload" field of the preceding payload 1820 to indicate the new payload's type. For an Encrypted payload, 1821 which must always be the last payload of a message, the Next 1822 Payload field is set to the payload type of the first contained 1823 payload. 1825 o Critical (1 bit) - MUST be set to zero if the sender wants 1826 the recipient to skip this payload if he does not 1827 understand the payload type code in the Next Payload field 1828 of the previous payload. MUST be set to one if the 1829 sender wants the recipient to reject this entire message 1830 if he does not understand the payload type. MUST be ignored 1831 by the recipient if the recipient understands the payload type 1832 code. MUST be set to zero for payload types defined in this 1833 document. Note that the critical bit applies to the current 1834 payload rather than the "next" payload whose type code 1835 appears in the first octet. The reasoning behind not setting 1836 the critical bit for payloads defined in this document is 1837 that all implementations MUST understand all payload types 1838 defined in this document and therefore must ignore the 1839 Critical bit's value. Skipped payloads are expected to 1840 have valid Next Payload and Payload Length fields. 1842 o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored. 1844 o Payload Length (2 octets) - Length in octets of the current 1845 payload, including the generic payload header. 1847 3.3 Security Association Payload 1849 The Security Association Payload, denoted SA in this memo, is used to 1850 negotiate attributes of a security association. An SA may contain 1851 multiple proposals. Each proposal may propose multiple protocols 1852 (where a protocol is IKE, ESP, or AH), along with a suite of 1853 cryptographic algorithms to be used by the protocols. The 1854 protocol(s), cryptographic algorithms, and any associated parameters 1855 are determined by the suite number. An SA payload MAY contain 1856 proposals for different protocols. For example, one suite might 1857 contain AH and ESP, while another might contain only ESP and a third 1858 only AH. 1860 1 2 3 1861 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 1862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1863 ! Next Payload !C! RESERVED ! Payload Length ! 1864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1865 ! ! 1866 ~ ~ 1867 ! ! 1868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1870 Figure 6: Security Association Payload 1872 o Proposals (variable) - one or more proposal substructures. 1874 The payload type for the Security Association Payload is one (1). 1876 3.3.1 Proposal Substructure 1878 1 2 3 1879 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 1880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1881 ! 0 (last) or 2 ! RESERVED ! Proposal Length ! 1882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1883 ! Proposal # ! RESERVED-MBZ ! Suite-ID ! 1884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1885 ~ SPI(S) (variable) ~ 1886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1888 Figure 7: Proposal Substructure 1890 o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the 1891 last Proposal Substructure in the SA. This syntax is inherited 1892 from ISAKMP, but is unnecessary because the last Proposal 1893 could be identified from the length of the SA payload. The 1894 value (2) corresponds to a Payload Type of Proposal, and the 1895 first four octets of the Proposal structure are designed to 1896 look somewhat like the header of a Payload. 1898 o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored. 1900 o Proposal Length (2 octets) - Length of this proposal, 1901 including the SPI 1903 o Proposal # (1 octet) - In an SA payload requesting a new 1904 SA is sent, it may contain multiple proposals. The first 1905 proposal in an SA MUST be #1, and subsequent proposals 1906 MUST be one greater than the previous proposal. When an 1907 SA is accepted, the SA payload sent back MUST contain a 1908 single proposal and the proposal number MUST match the 1909 number in the accepted proposal. 1911 o RESERVED-MBZ (1 octet) - This field is reserved for 1912 possible use in specifying different kinds of proposals. 1913 This field MUST be sent as zero and a proposal containing 1914 a non-zero value MUST NOT be accepted. The negotiation 1915 MAY still succeed if there is another acceptable 1916 proposal in the SA payload. 1918 o Suite-ID (2 octets) - This field specifies a suite of 1919 protocols and cryptographic algorithms. See table below. 1921 o SPI(S) (variable) - The sending entity's SPI(s). If the 1922 suite proposed includes more than one protocol, the SPIs 1923 are concatenated together in the order in which they would 1924 appear in a packet sent using the suite (e.g. AH followed 1925 by ESP). When an initial IKE-SA is being proposed, SPIs 1926 are implicit from the IKE header and are not repeated 1927 here. Note that no padding is applied. 1929 For Suite-ID, the following values are defined: 1931 Suite-ID Meaning 1932 -------- ------- 1933 1 Protocol: IKE 1934 168-bit 3DES CBC encryption 1935 Diffie-Hellman group 2 (1024-bit), see Appendix B.2 1936 HMAC-SHA1-96 integrity 1937 HMAC-SHA1 prf 1939 2 Protocol: IKE 1940 168-bit 3DES CBC encryption 1941 Diffie-Hellman group 5 (1536-bit), see Appendix B.5 1942 HMAC-SHA1-96 integrity 1943 HMAC-SHA1 prf 1945 3 Protocol: IKE 1946 AES encryption in CBC mode with 128-bit keys 1947 Diffie-Hellman group 5 (1536-bit), see Appendix B.5 1948 HMAC-SHA1-96 integrity 1949 HMAC-SHA1 prf 1951 4 Protocol: IKE 1952 AES encryption in CBC mode with 128-bit keys 1953 Diffie-Hellman group 14 (2048-bit), see [ADDGROUP] 1954 HMAC-SHA1-96 integrity 1955 HMAC-SHA1 prf 1957 5 Protocol: IKE 1958 AES encryption in CTR mode with 128-bit keys 1959 Diffie-Hellman group 14 (2048-bit), see [ADDGROUP] 1960 AES-CBC MAC + XCBC integrity and prf 1962 1001 Protocol: ESP without extended sequence numbers 1963 3DES encryption with three keys 1964 HMAC-SHA1-96 integrity 1966 1002 Protocol: ESP with extended sequence numbers 1967 AES encryption in CBC mode with 128-bit keys 1968 HMAC-SHA1-96 integrity 1970 1003 Protocol: ESP with extended sequence numbers 1971 AES encryption in CTR mode with 128-bit keys 1972 AES-CBC MAC + XCBC integrity 1974 2001 Protocol: AH 1975 HMAC-SHA1-96 integrity 1977 Other values in the range 0-32000 are reserved to IANA. Values 1978 32001-65533 are for private use among mutually consenting parties. 1979 Additional Suite-ID values will be assigned by IANA based on 1980 consultation with the IESG. 1982 The specification suites that MUST and SHOULD be supported for 1983 interoperability has been removed from this document because they 1984 are likely to change more rapidly than this document evolves. 1986 The previously-MUST ciphersuites (1 and 1001) are based on 1987 currently-deployed hardware that meets the security requirements 1988 of the vast majority of current IPsec users, and should be useful 1989 for at least a decade according to cryptographic estimates from 1990 NIST for business user scenarios. The previously-SHOULD 1991 ciphersuites (2, 3, 4, and 1002) are based on expectations of 1992 where the security industry is moving (namely, to the AES 1993 encryption suite) and where more security-conscious users are 1994 moving as current key lengths become more attackable due to the 1995 steady lowering of cost to mount brute-force attacks. 1997 An important lesson learned from IKEv1 is that no system should 1998 only implement the mandatory algorithms and expect them to be the 1999 best choice for all customers. For example, at the time that this 2000 document was being written, many IKEv1 implementers are starting 2001 to migrate to AES in CBC mode for VPN applications. Many IPsec 2002 systems based on IKEv2 will implement AES, longer Diffie-Hellman 2003 keys, and additional hash algorithms, and some IPsec customers 2004 already require these algorithms in addition to the ones listed 2005 above. 2007 It is likely that IANA will add additional Suite-IDs in the 2008 future, and some users may want to use private suites, especially 2009 for IKE where implementations should be capable of supporting 2010 different parameters, up to certain size limits. In support of 2011 this goal, all implementations of IKEv2 SHOULD include a 2012 management facility that allows specification (by a user or system 2013 administrator) of Diffie-Hellman parameters (the generator, 2014 modulus, and exponent lengths and values) for new IKE Suites. 2015 Implementations SHOULD provide a management interface via which 2016 these parameters and the associated Suite-IDs may be entered (by a 2017 user or system administrator), to enable negotiating such Suites. 2019 All implementations of IKEv2 MUST include a management facility 2020 that enables a user or system administratror to specify the Suite 2021 IDs that are acceptable for use with IKE. Upon receipt of a 2022 payload with a suite ID, the implementation must compare the 2023 transmitted suite ID against those locally configured via the 2024 management controls, to verify that the proposed suite is 2025 acceptable based on local policy. The implementation MUST reject 2026 key exchange payloads that are not authorized by these IKE suite 2027 controls. 2029 3.4 Key Exchange Payload 2031 The Key Exchange Payload, denoted KE in this memo, is used to 2032 exchange Diffie-Hellman public numbers as part of a Diffie-Hellman 2033 key exchange. The Key Exchange Payload consists of the IKE generic 2034 header followed by the Diffie-Hellman public value itself. 2036 1 2 3 2037 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 2038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2039 ! Next Payload !C! RESERVED ! Payload Length ! 2040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2041 ! Suite-ID ! RESERVED (MBZ) ! 2042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2043 ! ! 2044 ~ Key Exchange Data ~ 2045 ! ! 2046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2048 Figure 8: Key Exchange Payload Format 2050 A key exchange payload is constructed by copying ones Diffie-Hellman 2051 public value into the "Key Exchange Data" portion of the payload. 2052 The length of the Diffie-Hellman public value MUST be equal to the 2053 length of the prime modulus over which the exponentiation was 2054 performed, prepending zero bits to the value if necessary. 2056 The Suite-ID is the identifier of the cryptographic suite from which 2057 the Diffie-Hellman group was taken. If the selected proposal uses a 2058 different Diffie-Hellman group, the message MUST be rejected with a 2059 Notify payload of type INVALID-KE-PAYLOAD. 2061 The payload type for the Key Exchange payload is four (4). 2063 3.5 Identification Payload 2065 The Identification Payload, denoted ID in this memo, allows peers to 2066 assert an identify to one another. The ID Payload names the identity 2067 to be authenticated with the AUTH payload. 2069 NOTE: In IKEv1, two ID payloads were used in each direction to hold 2070 Traffic Selector information for data passing over the SA. In IKEv2, 2071 this information is carried in Traffic Selector (TS) payloads (see 2072 section 3.13). 2074 The Identification Payload consists of the IKE generic header 2075 followed by identification fields as follows: 2077 1 2 3 2078 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 2079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2080 ! Next Payload !C! RESERVED ! Payload Length ! 2081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2082 ! ID Type ! RESERVED | 2083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2084 ! ! 2085 ~ Identification Data ~ 2086 ! ! 2087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2089 Figure 9: Identification Payload Format 2091 o ID Type (1 octet) - Specifies the type of Identification being 2092 used. 2094 o RESERVED - MUST be sent as zero; MUST be ignored. 2096 o Identification Data (variable length) - Value, as indicated by 2097 the Identification Type. The length of the Identification Data 2098 is computed from the size in the ID payload header. 2100 The payload type for the Identification Payload is five (5). 2102 The following table lists the assigned values for the Identification 2103 Type field, followed by a description of the Identification Data 2104 which follows: 2106 ID Type Value 2107 ------- ----- 2108 RESERVED 0 2110 ID_IPV4_ADDR 1 2112 A single four (4) octet IPv4 address. 2114 ID_FQDN 2 2115 A fully-qualified domain name string. An example of a 2116 ID_FQDN is, "lounge.org". The string MUST not contain any 2117 terminators (e.g. NULL, CR, etc.). 2119 ID_RFC822_ADDR 3 2121 A fully-qualified RFC822 email address string, An example of 2122 a ID_RFC822_ADDR is, "lizard@lounge.org". The string MUST 2123 not contain any terminators. 2125 ID_IPV6_ADDR 5 2127 A single sixteen (16) octet IPv6 address. 2129 ID_DER_ASN1_DN 9 2131 The binary DER encoding of an ASN.1 X.500 Distinguished Name 2132 [X.501]. 2134 ID_DER_ASN1_GN 10 2136 The binary DER encoding of an ASN.1 X.500 GeneralName 2137 [X.509]. 2139 ID_KEY_ID 11 2141 An opaque octet stream which may be used to pass an account 2142 name or to pass vendor-specific information necessary to do 2143 certain proprietary forms of identification. 2145 Two implementations will interoperate only if each can generate a 2146 form of ID acceptable to the other. To assure maximum 2147 interoperability, implementations MUST be configurable to send at 2148 least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and 2149 MUST be configurable to accept all of these forms. Implementations 2150 SHOULD be capable of generating and accepting all of these forms. 2152 3.6 Certificate Payload 2154 The Certificate Payload, denoted CERT in this memo, provides a means 2155 to transport certificates or other authentication related information 2156 via IKE. Certificate payloads SHOULD be included in an exchange if 2157 certificates are available to the sender unless the peer has 2158 indicated an ability to retrieve this information from elsewhere. 2160 The Certificate Payload is defined as follows: 2162 1 2 3 2163 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 2164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2165 ! Next Payload !C! RESERVED ! Payload Length ! 2166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2167 ! Cert Encoding ! ! 2168 +-+-+-+-+-+-+-+-+ ! 2169 ~ Certificate Data ~ 2170 ! ! 2171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2173 Figure 10: Certificate Payload Format 2175 o Certificate Encoding (1 octet) - This field indicates the type 2176 of certificate or certificate-related information contained 2177 in the Certificate Data field. 2179 Certificate Encoding Value 2180 -------------------- ----- 2181 RESERVED 0 2182 PKCS #7 wrapped X.509 certificate 1 2183 PGP Certificate 2 2184 DNS Signed Key 3 2185 X.509 Certificate - Signature 4 2186 Kerberos Token 6 2187 Certificate Revocation List (CRL) 7 2188 Authority Revocation List (ARL) 8 2189 SPKI Certificate 9 2190 X.509 Certificate - Attribute 10 2191 Raw RSA Key 11 2192 Hash and URL of PKIX certificate 12 2193 Hash and URL of PKIX bundle 13 2194 RESERVED 14 - 200 2195 PRIVATE USE 201 - 255 2197 o Certificate Data (variable length) - Actual encoding of 2198 certificate data. The type of certificate is indicated 2199 by the Certificate Encoding field. 2201 The payload type for the Certificate Payload is six (6). 2203 While the certificate type codes above are defined for backwards 2204 compatibility and possible future use, the types whose syntax is 2205 defined in this document are: 2207 X.509 Certificate - Signature (4) contains a BER encoded X.509 2208 certificate. 2210 Certificate Revocation List (7) contains a BER encoded X.509 2211 certificate revocation list. 2213 Raw RSA Key (11) contains a PKCS #1 encoded RSA key. 2215 Hash and URL of PKIX certificate (12) contains a 20 byte SHA-1 2216 hash of a PKIX certificate followed by a variable length URL that 2217 resolves to the BER encoded certificate itself. 2219 Hash and URL of PKIX bundle (13) contains a 20 byte SHA-1 hash of 2220 a PKIX certificate bundle followed by a variable length URL the 2221 resolves to the BER encoded certificate bundle itself. The bundle 2222 is a BER encoded SEQUENCE of certificates and CRLs. 2224 Implementations MUST be capable of being configured to send and 2225 accept up to four X.509 certificates in support of authentication. 2226 Implementations SHOULD be capable of being configured to send and 2227 accept Raw RSA keys and the two Hash and URL formats. If multiple 2228 certificates are sent, the first certificate MUST contain the public 2229 key used to sign the AUTH payload. 2231 3.7 Certificate Request Payload 2233 The Certificate Request Payload, denoted CERTREQ in this memo, 2234 provides a means to request preferred certificates via IKE and can 2235 appear in the second and/or third message of the initial exchanges. 2236 Certificate Request payloads SHOULD be included in an exchange 2237 whenever the peer may have multiple certificates, some of which might 2238 be trusted while others are not or when multiple formats might be 2239 acceptable. If multiple root CAs are trusted, then multiple 2240 Certificate Request payloads SHOULD be transmitted. 2242 Empty (zero length) CA names MUST NOT be generated and SHOULD be 2243 ignored. 2245 The Certificate Request Payload is defined as follows: 2247 1 2 3 2248 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 2249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2250 ! Next Payload !C! RESERVED ! Payload Length ! 2251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2252 ! Cert Encoding ! ! 2253 +-+-+-+-+-+-+-+-+ ! 2254 ~ Certification Authority ~ 2255 ! ! 2256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2257 Figure 11: Certificate Request Payload Format 2259 o Certificate Encoding (1 octet) - Contains an encoding of the type 2260 or format of certificate requested. Values are listed in section 2261 3.6. 2263 o Certification Authority (variable length) - Contains an encoding 2264 of an acceptable certification authority for the type of 2265 certificate requested. 2267 The payload type for the Certificate Request Payload is seven (7). 2269 While intended to allow for future expansion, the only form of 2270 certificate request currently defined is X.509 signing certificate 2271 (4). For that type, the CA value is a concatenated list of SHA-1 2272 hashes of the public keys of trusted root CAs. 2274 The Certificate Request Payload is processed by inspecting the "Cert 2275 Encoding" field to determine whether the processor has any 2276 certificates of this type. If so the "Certification Authority" field 2277 is inspected to determine if the processor has any certificates which 2278 can be validated up to the specified certification authority. This 2279 can be a chain of certificates. If a certificate exists which 2280 satisfies the criteria specified in the Certificate Request Payload 2281 it MUST be sent back to the certificate requestor; if a certificate 2282 chain exists which goes back to the certification authority specified 2283 in the request the entire chain SHOULD be sent back to the 2284 certificate requestor. If no certificates exist then no further 2285 processing is performed-- this is not an error condition of the 2286 protocol. There may be cases where there is a preferred CA, but an 2287 alternate might be acceptable (perhaps after prompting a human 2288 operator). 2290 3.8 Authentication Payload 2292 The Authentication Payload, denoted AUTH in this memo, contains data 2293 used for authentication purposes. The syntax of the Authentication 2294 data varies according the the Auth Method as specified below. 2296 The Authentication Payload is defined as follows: 2298 1 2 3 2299 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 2300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2301 ! Next Payload !C! RESERVED ! Payload Length ! 2302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2303 ! Auth Method ! RESERVED ! 2304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2305 ! ! 2306 ~ Authentication Data ~ 2307 ! ! 2308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2310 Figure 12: Authentication Payload Format 2312 o Auth Method (1 octet) - Specifies the method of authentication 2313 used. Values defined are: 2315 Digital Signature (1) - Computed as specified in section 2.15 2316 using a public key. 2318 Shared Key Message Integrity Code (2) - Computed as specified in 2319 section 2.15 using the shared key associated with the identity 2320 in the ID payload. 2322 The values 0 and 3-200 are reserved to IANA. The values 201-255 2323 are available for private use. 2325 o Authentication Data (variable length) - see section 2.15. 2327 The payload type for the Authentication Payload is nine (9). 2329 3.9 Nonce Payload 2331 The Nonce Payload, denoted Ni and Nr in this memo for the Initiator's 2332 and Responder's nonce respectively, contains random data used to 2333 guarantee liveness during an exchange and protect against replay 2334 attacks. 2336 The Nonce Payload is defined as follows: 2338 1 2 3 2339 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 2340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2341 ! Next Payload !C! RESERVED ! Payload Length ! 2342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2343 ! ! 2344 ~ Nonce Data ~ 2345 ! ! 2346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2348 Figure 13: Nonce Payload Format 2350 o Nonce Data (variable length) - Contains the random data generated 2351 by the transmitting entity. 2353 The payload type for the Nonce Payload is ten (10). 2355 The size of a Nonce MUST be between 8 and 256 octets inclusive. Nonce 2356 values MUST NOT be reused. 2358 3.10 Notify Payload 2360 The Notify Payload, denoted N in this document, is used to transmit 2361 informational data, such as error conditions and state transitions, 2362 to an IKE peer. A Notify Payload may appear in a response message 2363 (usually specifying why a request was rejected), in an INFORMATIONAL 2364 Exchange (to report an error not in an IKE request), or in any other 2365 message to indicate sender capabilities or to modify the meaning of 2366 the request. 2368 The Notify Payload is defined as follows: 2370 1 2 3 2371 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 2372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2373 ! Next Payload !C! RESERVED ! Payload Length ! 2374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2375 ! Protocol-ID ! SPI Size ! Notify Message Type ! 2376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2377 ! ! 2378 ~ Security Parameter Index (SPI) ~ 2379 ! ! 2380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2381 ! ! 2382 ~ Notification Data ~ 2383 ! ! 2384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2386 Figure 14: Notification Payload Format 2388 o Protocol-Id (1 octet) - Specifies the protocol about which 2389 this notification is being sent. For IKE-SA notifications, 2390 this field MUST be zero (0). For notifications 2391 concerning IPsec SAs this field will contain either (1) 2392 to indicate ESP or (2) to indicate AH. For notifications 2393 for which no protocol ID is relevant, this field MUST be 2394 sent as zero and MUST be ignored. 2396 o SPI Size (1 octet) - Length in octets of the SPI as defined by 2397 the Protocol-Id or zero if no SPI is applicable. For a 2398 notification concerning the IKE-SA, the SPI Size MUST be zero. 2400 o Notify Message Type (2 octets) - Specifies the type of 2401 notification message. 2403 o SPI (variable length) - Security Parameter Index. 2405 o Notification Data (variable length) - Informational or error data 2406 transmitted in addition to the Notify Message Type. Values for 2407 this field are message specific, see below. 2409 The payload type for the Notification Payload is eleven (11). 2411 3.10.1 Notify Message Types 2413 Notification information can be error messages specifying why an SA 2414 could not be established. It can also be status data that a process 2415 managing an SA database wishes to communicate with a peer process. 2416 The table below lists the Notification messages and their 2417 corresponding values. The number of different error statuses was 2418 greatly reduced from IKE V1 both for simplication and to avoid giving 2419 configuration information to probers. 2421 Types in the range 0 - 16383 are intended for reporting errors. An 2422 implementation receiving a Notify payload with one of these types 2423 that it does not recognise in a response MUST assume that the 2424 corresponding request has failed entirely. Unrecognised error types 2425 in a request and status types in a request or response MUST be 2426 ignored except that they SHOULD be logged. 2428 Notify payloads with status types MAY be added to any message and 2429 MUST be ignored if not recognised. They are intended to indicate 2430 capabilities, and as part of SA negotiation are used to negotiate 2431 non-cryptographic parameters. 2433 NOTIFY MESSAGES - ERROR TYPES Value 2434 ----------------------------- ----- 2435 UNSUPPORTED-CRITICAL-PAYLOAD 1 2437 Sent if the payload has the "critical" bit set and the 2438 payload type is not recognised. Notification Data contains 2439 the one octet payload type. 2441 INVALID-SPI 4 2443 Indicates an IKE message was received with an unrecognized 2444 destination SPI. This usually indicates that the recipient 2445 has rebooted and forgotten the existence of an IKE-SA. 2447 INVALID-MAJOR-VERSION 5 2448 Indicates the recipient cannot handle the version of IKE 2449 specified in the header. The closest version number that the 2450 recipient can support will be in the reply header. 2452 INVALID-SYNTAX 7 2454 Indicates the IKE message was received was invalid because 2455 some type, length, or value was out of range or because the 2456 request was rejected for policy reasons. To avoid a denial 2457 of service attack using forged messages, this status may 2458 only be returned for and in an encrypted packet if the 2459 MESSAGE-ID and cryptographic checksum were valid. To avoid 2460 leaking information to someone probing a node, this status 2461 MUST be sent in response to any error not covered by one of 2462 the other status codes. To aid debugging, more detailed 2463 error information SHOULD be written to a console or log. 2465 INVALID-MESSAGE-ID 9 2467 Sent when an IKE MESSAGE-ID outside the supported window is 2468 received. This Notify MUST NOT be sent in a response; the 2469 invalid request MUST NOT be acknowledged. Instead, inform 2470 the other side by initiating an INFORMATIONAL exchange with 2471 Notification data containing the four octet invalid MESSAGE- 2472 ID. Sending this notification is optional, MUST be rate 2473 limited, and MUST NOT be sent unless an IKE-SA exists to the 2474 sending address and port. 2476 INVALID-SPI 11 2478 MAY be sent in an IKE INFORMATIONAL Exchange when a node 2479 receives an ESP or AH packet with an invalid SPI. The 2480 Notification Data contains the SPI of the invalid packet. 2481 This usually indicates a node has rebooted and forgotten an 2482 SA. If this Informational Message is sent outside the 2483 context of an IKE-SA, it should only be used by the 2484 recipient as a "hint" that something might be wrong (because 2485 it could easily be forged). 2487 NO-PROPOSAL-CHOSEN 14 2489 None of the proposed crypto suites was acceptable. 2491 AUTHENTICATION-FAILED 24 2493 Sent in the response to an IKE_AUTH message when for some 2494 reason the authentication failed. There is no associated 2495 data. 2497 SINGLE-PAIR-REQUIRED 34 2499 This error indicates that a CREATE_CHILD_SA request is 2500 unacceptable because the Responder is willing to accept 2501 traffic selectors specifying a single pair of addresses. 2502 The Initiator is expected to respond by requesting an SA for 2503 only the specific traffic he is trying to forward. 2505 NO-ADDITIONAL-SAS 35 2507 This error indicates that a CREATE_CHILD_SA request is 2508 unacceptable because the Responder is unwilling to accept 2509 any more CHILD-SAs on this IKE-SA. Some minimal 2510 implementations may only accept a single CHILD-SA setup in 2511 the context of an initial IKE exchange and reject any 2512 subsequent attempts to add more. 2514 INTERNAL-ADDRESS-FAILURE 36 2515 Indicates an error assigning an internal address (i.e., 2516 INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS) during the 2517 processing of a Configuration Payload by a Responder. If 2518 this error is generated within an IKE_AUTH exchange no 2519 CHILD-SA will be created. 2521 RESERVED TO IANA - Errors 37 - 8191 2523 Private Use - Errors 8192 - 16383 2525 NOTIFY MESSAGES - STATUS TYPES Value 2526 ------------------------------ ----- 2528 RESERVED TO IANA - STATUS 16384 - 24577 2530 INITIAL-CONTACT 24578 2532 This notification asserts that this IKE-SA is the only IKE- 2533 SA currently active between the authenticated identities. It 2534 MAY be sent when an IKE-SA is established after a crash, and 2535 the recipient MAY use this information to delete any other 2536 IKE-SAs it has to the same authenticated identity without 2537 waiting for a timeout if those IKE-SAs reside at the IP 2538 address from which this notification arrived. This 2539 notification MUST NOT be sent by an entity that may be 2540 replicated (e.g. a roaming user's credentials where the user 2541 is allowed to connect to the corporate firewall from two 2542 remote systems at the same time). 2544 SET-WINDOW-SIZE 24579 2546 This notification asserts that the sending endpoint is 2547 capable of keeping state for multiple outstanding exchanges, 2548 permitting the recipient to send multiple requests before 2549 getting a response to the first. The data associated with a 2550 SET-WINDOW-SIZE notification MUST be 4 octets long and 2551 contain the big endian represention of the number of 2552 messages the sender promises to keep. Window size is always 2553 one until the initial exchanges complete. 2555 ADDITIONAL-TS-POSSIBLE 24580 2557 This notification asserts that the sending endpoint narrowed 2558 the proposed traffic selectors but that other traffic 2559 selectors would also have been acceptable, though only in a 2560 separate SA. There is no data associated with this notify 2561 type. It may only be sent as an additional payload in a 2562 message including accepted TSs. 2564 IPCOMP-SUPPORTED 24581 2566 This notification may only be included in a message 2567 containing an SA payload negotiating a CHILD-SA and 2568 indicates a willingness by its sender to use IPcomp on this 2569 SA. The data associated with this notification includes a 2570 two byte IPcomp CPI followed by a one octet transform ID 2571 optionally followed by attributes whose length and format is 2572 defined by that transform ID. A message proposing an SA may 2573 contain multiple IPCOMP-SUPPORTED notifications to indicate 2574 multiple supported algorithms. A message accepting an SA may 2575 contain at most one. 2577 The transform IDs currently defined are: 2579 NAME NUMBER DEFINED IN 2580 ----------- ------ ----------- 2581 RESERVED 0 2582 IPCOMP_OUI 1 2583 IPCOMP_DEFLATE 2 RFC 2394 2584 IPCOMP_LZS 3 RFC 2395 2586 values 4-240 are reserved to IANA. Values 241-255 are 2587 for private use among mutually consenting parties. 2589 NAT-DETECTION-SOURCE-IP 24582 2591 This notification is used to by its recipient to determine 2592 whether the source is behind a NAT box. The data associated 2593 with this notification is a SHA-1 digest of the SPIs, IP 2594 address and port on which this packet was sent. There MAY 2595 be multiple notify payloads of this type in a message if the 2596 sender does not know which of several network attachments 2597 will be used to send the packet. The recipient of this 2598 notification MAY compare the supplied value to a hash of the 2599 source IP address and port and if they don't match it MAY 2600 invoke NAT specific handling (like using UDP encapsulation 2601 of ESP packets and subsequent IKE packets). Alternately, it 2602 MAY reject the connection attempt if NAT traversal is not 2603 supported. 2605 NAT-DETECTION-DESTINATION-IP 24583 2607 This notification is used to by its recipient to determine 2608 whether it is behind a NAT box. The data associated with 2609 this notification is a SHA-1 digest of the SPIs, IP address 2610 and port to which this packet was sent. The recipient of 2611 this notification MAY compare the supplied value to a hash 2612 of the destination IP address and port and if they don't 2613 match it MAY invoke NAT specific handling (like using UDP 2614 encapsulation of ESP packets and subsequent IKE packets). 2615 Alternately, it MAY reject the connection attempt if NAT 2616 traversal is not supported. 2618 COOKIE 24584 2620 This notification MAY be included in an IKE_SA_INIT request 2621 or response. In the response, it indicates that the request 2622 should be retried with the COOKIE included in the request. 2623 That data associated with this notification MUST be between 2624 1 and 64 octets in length (inclusive). 2626 USE-TRANSPORT-MODE 24585 2628 This notification MAY be included in a request message that 2629 also includes an SA requesting a CHILD-SA. It requests that 2630 the CHILD-SA use transport mode rather than tunnel mode for 2631 the SA created. If the request is accepted, the response 2632 MUST also include a notification of type USE-TRANSPORT-MODE. 2633 If the responder declines the request, the CHILD-SA can 2634 still be established, but will use tunnel mode. If this is 2635 unacceptable to the initiator, the initiator MUST delete the 2636 SA. Note: except when using this option to negotiate 2637 transport mode, all CHILD-SAs will use tunnel mode. 2639 HTTP-CERT-LOOKUP-SUPPORTED 24586 2640 This notification MAY be included any message that can 2641 include a CERTREQ payload and indicates that the sender is 2642 capable of looking up certificates based on an HTTP-based 2643 URL (and hence presumeably would prefer to receive 2644 certificate specifications in that format). 2646 RESERVED TO IANA - STATUS 24587 - 40959 2648 Private Use - STATUS 40960 - 65535 2650 3.11 Delete Payload 2652 The Delete Payload, denoted D in this memo, contains a protocol 2653 specific security association identifier that the sender has removed 2654 from its security association database and is, therefore, no longer 2655 valid. Figure 15 shows the format of the Delete Payload. It is 2656 possible to send multiple SPIs in a Delete payload, however, each SPI 2657 MUST be for the same protocol. Mixing of Protocol Identifiers MUST 2658 NOT be performed in a the Delete payload. It is permitted, however, 2659 to include multiple Delete payloads in a single INFORMATIONAL 2660 Exchange where each Delete payload lists SPIs for a different 2661 protocol. 2663 Deletion of the IKE-SA is indicated by a Protocol-Id of 0 (IKE) but 2664 no SPIs. Deletion of a CHILD-SA, such as ESP or AH, will contain the 2665 Protocol-Id of that protocol (1 for ESP, 2 for AH) and the SPI is the 2666 SPI the sending endpoint would place in outbound ESP or AH packets. 2668 The Delete Payload is defined as follows: 2670 1 2 3 2671 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 2672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2673 ! Next Payload !C! RESERVED ! Payload Length ! 2674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2675 ! Protocol-Id ! SPI Size ! # of SPIs ! 2676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2677 ! ! 2678 ~ Security Parameter Index(es) (SPI) ~ 2679 ! ! 2680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2682 Figure 15: Delete Payload Format 2684 o Protocol-Id (1 octet) - Must be zero for an IKE-SA, 1 for 2685 ESP, or 2 for AH. 2687 o SPI Size (1 octet) - Length in octets of the SPI as defined by 2688 the Protocol-Id. Zero for IKE (SPI is in message header) 2689 or four for AH and ESP. 2691 o # of SPIs (2 octets) - The number of SPIs contained in the Delete 2692 payload. The size of each SPI is defined by the SPI Size field. 2694 o Security Parameter Index(es) (variable length) - Identifies the 2695 specific security association(s) to delete. The length of this 2696 field is determined by the SPI Size and # of SPIs fields. 2698 The payload type for the Delete Payload is twelve (12). 2700 3.12 Vendor ID Payload 2702 The Vendor ID Payload contains a vendor defined constant. The 2703 constant is used by vendors to identify and recognize remote 2704 instances of their implementations. This mechanism allows a vendor 2705 to experiment with new features while maintaining backwards 2706 compatibility. 2708 A Vendor ID payload MAY announce that the sender is capable to 2709 accepting certain extensions to the protocol, or it MAY simply 2710 identify the implementation as an aid in debugging. If parameter 2711 values "reserved for use by consenting parties" are used, they must 2712 be preceded by a Vendor ID payload that disambiguates them. A Vendor 2713 ID payload MUST NOT change the interpretation of any information 2714 defined in this specification (i.e. it MUST be non-critical). 2715 Multiple Vendor ID payloads MAY be sent. An implementation is NOT 2716 REQUIRED to send any Vendor ID payload at all. 2718 A Vendor ID payload may be sent as part of any message. Reception of 2719 a familiar Vendor ID payload allows an implementation to make use of 2720 Private USE numbers described throughout this memo-- private 2721 payloads, private exchanges, private notifications, etc. Unfamiliar 2722 Vendor IDs MUST be ignored. 2724 Writers of Internet-Drafts who wish to extend this protocol MUST 2725 define a Vendor ID payload to announce the ability to implement the 2726 extension in the Internet-Draft. It is expected that Internet-Drafts 2727 which gain acceptance and are standardized will be given "magic 2728 numbers" out of the Future Use range by IANA and the requirement to 2729 use a Vendor ID will go away. 2731 The Vendor ID Payload fields are defined as follows: 2733 1 2 3 2734 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 2736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2737 ! Next Payload !C! RESERVED ! Payload Length ! 2738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2739 ! ! 2740 ~ Vendor ID (VID) ~ 2741 ! ! 2742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2744 Figure 16: Vendor ID Payload Format 2746 o Vendor ID (variable length) - It is the responsibility of 2747 the person choosing the Vendor ID to assure its uniqueness 2748 in spite of the absence of any central registry for IDs. 2749 Good practice is to include a company name, a person name 2750 or some such. If you want to show off, you might include 2751 the latitude and longitude and time where you were when 2752 you chose the ID and some random input. A message digest 2753 of a long unique string is preferable to the long unique 2754 string itself. 2756 The payload type for the Vendor ID Payload is thirteen (13). 2758 3.13 Traffic Selector Payload 2760 The Traffic Selector Payload, denoted TS in this memo, allows peers 2761 to identify packet flows for processing by IPsec security services. 2762 The Traffic Selector Payload consists of the IKE generic header 2763 followed by individual traffic selectors as follows: 2765 1 2 3 2766 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 2767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2768 ! Next Payload !C! RESERVED ! Payload Length ! 2769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2770 ! Number of TSs ! RESERVED ! 2771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2772 ! ! 2773 ~ ~ 2774 ! ! 2775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2777 Figure 17: Traffic Selectors Payload Format 2779 o Number of TSs (1 octet) - Number of traffic selectors 2780 being provided. 2782 o RESERVED - This field MUST be sent as zero and MUST be ignored. 2784 o Traffic Selectors (variable length) - one or more individual 2785 traffic selectors. 2787 The length of the Traffic Selector payload includes the TS header and 2788 all the traffic selectors. 2790 The payload type for the Traffic Selector payload is fourteen (14). 2792 3.13.1 Traffic Selector 2794 1 2 3 2795 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 2796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2797 ! TS Type ! Protocol ID | Selector Length | 2798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2799 | Start-Port | End-Port | 2800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2801 ! ! 2802 ~ Starting Address ~ 2803 ! ! 2804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2805 ! ! 2806 ~ Ending Address ~ 2807 ! ! 2808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2810 Figure 18: Traffic Selector 2812 o TS Type (one octet) - Specifies the type of traffic selector. 2814 o Protocol ID (1 octet) - Value specifying an associated IP 2815 protocol ID (e.g. UDP/TCP). A value of zero means that the 2816 Protocol ID is not relevant to this traffic selector-- 2817 the SA can carry all protocols. 2819 o Selector Length - Specifies the length of this Traffic 2820 Selector Substructure including the header. 2822 o Start-Port (2 octets) - Value specifying the smallest port 2823 number allowed by this Traffic Selector. For protocols for 2824 which port is undefined, or if all ports are allowed by 2825 this Traffic Selector, this field MUST be zero. 2827 o End-Port (2 octets) - Value specifying the largest port 2828 number allowed by this Traffic Selector. For protocols for 2829 which port is undefined, or it all ports are allowed by 2830 this Traffic Selector, this field MUST be 65535. 2832 o Starting Address - The smallest address included in this 2833 Traffic Selector (length determined by TS type). 2835 o Ending Address - The largest address included in this 2836 Traffic Selector (length determined by TS type). 2838 The following table lists the assigned values for the Traffic 2839 Selector Type field and the corresponding Address Selector Data. 2841 TS Type Value 2842 ------- ----- 2843 RESERVED 0 2845 TS_IPV4_ADDR_RANGE 7 2847 A range of IPv4 addresses, represented by two four (4) octet 2848 values. The first value is the beginning IPv4 address 2849 (inclusive) and the second value is the ending IPv4 address 2850 (inclusive). All addresses falling between the two specified 2851 addresses are considered to be within the list. 2853 TS_IPV6_ADDR_RANGE 8 2855 A range of IPv6 addresses, represented by two sixteen (16) 2856 octet values. The first value is the beginning IPv6 address 2857 (inclusive) and the second value is the ending IPv6 address 2858 (inclusive). All addresses falling between the two specified 2859 addresses are considered to be within the list. 2861 3.14 Encrypted Payload 2863 The Encrypted Payload, denoted SK{...} in this memo, contains other 2864 payloads in encrypted form. The Encrpted Payload, if present in a 2865 message, must be the last payload in the message. Often, it is the 2866 only payload in the message. 2868 The algorithms for encryption and integrity protection are negotiated 2869 during IKE-SA setup, and the keys are computed as specified in 2870 sections 2.14 and 2.18. 2872 The encryption and integrity protection algorithms are modelled after 2873 the ESP algorithms described in RFCs 2104, 2406, 2451. This document 2874 completely specifies the cryptographic processing of IKE data, but 2875 those documents should be consulted for design rationale. We assume a 2876 block cipher with a fixed block size and an integrity check algorithm 2877 that computes a fixed length checksum over a variable size message. 2879 The Payload Type for an Encrypted payload is fifteen (15). The 2880 Encrypted Payload consists of the IKE generic header followed by 2881 individual fields as follows: 2883 1 2 3 2884 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 2885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2886 ! Next Payload !C! RESERVED ! Payload Length ! 2887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2888 ! Initialization Vector ! 2889 ! (length is block size for encryption algorithm) ! 2890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2891 ! Encrypted IKE Payloads ! 2892 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2893 ! ! Padding (0-255 octets) ! 2894 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 2895 ! ! Pad Length ! 2896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2897 ~ Integrity Checksum Data ~ 2898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2900 Figure 19: Encrypted Payload Format 2902 o Next Payload - The payload type of the first embedded payload. 2903 Since the Encrypted payload must be last in a message, there 2904 is no need to specify a payload type for a payload beyond it. 2906 o Payload Length - Includes the lengths of the IV, Padding, and 2907 Authentication data. 2909 o Initialization Vector - A randomly chosen value whose length 2910 is equal to the block length of the underlying encryption 2911 algorithm. Recipients MUST accept any value. Senders SHOULD 2912 either pick this value pseudo-randomly and independently for 2913 each message or use the final ciphertext block of the previous 2914 message sent. Senders MUST NOT use the same value for each 2915 message, use a sequence of values with low hamming distance 2916 (e.g. a sequence number), or use ciphertext from a received 2917 message. 2919 o IKE Payloads are as specified earlier in this section. This 2920 field is encrypted with the negotiated cipher. 2922 o Padding may contain any value chosen by the sender, and must 2923 have a length that makes the combination of the Payloads, the 2924 Padding, and the Pad Length to be a multiple of the encryption 2925 block size. This field is encrypted with the negotiated 2926 cipher. 2928 o Pad Length is the length of the Padding field. The sender 2929 SHOULD set the Pad Length to the minimum value that makes 2930 the combination of the Payloads, the Padding, and the Pad 2931 Length a multiple of the block size, but the recipient MUST 2932 accept any length that results in proper alignment. This 2933 field is encrypted with the negotiated cipher. 2935 o Integrity Checksum Data is the cryptographic checksum of 2936 the entire message starting with the Fixed IKE Header 2937 through the Pad Length. The checksum MUST be computed over 2938 the encrypted message. 2940 3.15 Configuration Payload 2942 The Configuration payload, denoted CP in this document, is used to 2943 exchange configuration information between IKE peers. Currently, the 2944 only defined uses for this exchange is for an IRAC to request an 2945 internal IP address from an IRAS or for either party to request 2946 version information from the other, but this payload is intended as a 2947 likely place for future extensions. 2949 Configuration payloads are of type CFG_REQUEST/CFG_REPLY or 2950 CFG_SET/CFG_ACK (see CFG Type in the payload description below). 2951 CFG_REQUEST and CFG_SET payloads may optionally be added to any IKE 2952 request. The IKE response MUST include either a corresponding 2953 CFG_REPLY or CFG_ACK or a Notify payload with an error code 2954 indicating why the request could not be honored. An exception is that 2955 a minimal implementation MAY ignore all CFG_REQUEST and CFG_SET 2956 payloads, so a response message without a corresponding CFG_REPLY or 2957 CFG_ACK MUST be accepted as an indication that the request was not 2958 supported. 2960 "CFG_REQUEST/CFG_REPLY" allows an IKE endpoint to request information 2961 from its peer. If an attribute in the CFG_REQUEST Configuration 2962 Payload is not zero length it is taken as a suggestion for that 2963 attribute. The CFG_REPLY Configuration Payload MAY return that 2964 value, or a new one. It MAY also add new attributes and not include 2965 some requested ones. Requestors MUST ignore returned attributes that 2966 they do not recognise. 2968 Some attributes MAY be multi-valued, in which case multiple attribute 2969 values of the same type are sent and/or returned. Generally, all 2970 values of an attribute are returned when the attribute is requested. 2971 For some attributes (in this version of the specification only 2972 internal addresses), multiple requests indicates a request that 2973 multiple values be assigned. For these attributes, the number of 2974 values returned SHOULD NOT exceed the number requested. 2976 If the data type requested in a CFG_REQUEST is not recognised or not 2977 supported, the responder MUST NOT return an error code but rather 2978 MUST either send a CFG_REPLY which MAY be empty or a reply not 2979 containing a CFG_REPLY payload at all. Error returns are reserved for 2980 cases where the request is recognised but cannot be performed as 2981 requested or the request is badly formatted. 2983 "CFG_SET/CFG_ACK" allows an IKE endpoint to push configuration data 2984 to its peer. In this case the CFG_SET Configuration Payload contains 2985 attributes the initiator wants its peer to alter. The responder MUST 2986 return a Configuration Payload if it accepted any of the 2987 configuration data and it MUST contain the attributes that the 2988 responder accepted with zero length data. Those attributes that it 2989 did not accept MUST NOT be in the CFG_ACK Configuration Payload. If 2990 no attributes were accepted, the responder MUST return either an 2991 empty CFG_ACK payload or a response message without a CFG_ACK 2992 payload. There are currently no defined uses for the CFG_SET/CFG_ACK 2993 exchange, though they may be used in connection with extensions based 2994 on Vendor IDs. An minimal implementation of this specification MAY 2995 ignore CFG_SET payloads. 2997 Extensions via the CP payload SHOULD NOT be used for general purpose 2998 management. Its main intent is to provide a bootstrap mechanism to 2999 exchange information within IPSec from IRAS to IRAC. While it MAY be 3000 useful to use such a method to exchange information between some 3001 Security Gateways (SGW) or small networks, existing management 3002 protocols such as DHCP [DHCP], RADIUS [RADIUS], SNMP or LDAP [LDAP] 3003 should be preferred for enterprise management as well as subsequent 3004 information exchanges. 3006 The Configuration Payload is defined as follows: 3008 1 2 3 3009 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 3010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3011 ! Next Payload !C! RESERVED ! Payload Length ! 3012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3013 ! CFG Type ! RESERVED ! 3014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3015 ! ! 3016 ~ Configuration Attributes ~ 3017 ! ! 3018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3020 Figure 20: Configuration Payload Format 3022 The payload type for the Configuration Payload is 16. 3024 o CFG Type (1 octet) - The type of exchange represented by the 3025 Configuration Attributes. 3027 CFG Type Value 3028 =========== ===== 3029 RESERVED 0 3030 CFG_REQUEST 1 3031 CFG_REPLY 2 3032 CFG_SET 3 3033 CFG_ACK 4 3035 values 5-127 are reserved to IANA. Values 128-255 are for private 3036 use among mutually consenting parties. 3038 o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored. 3040 o Configuration Attribute (variable length) - These are type length 3041 values specific to the Configuration Payload and are defined 3042 below. There may be zero or more Configuration Attributes in this 3043 payload. 3045 3.15.1 Configuration Attributes 3047 1 2 3 3048 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 3049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3050 !R| Attribute Type ! Length | 3051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3052 | | 3053 ~ Value ~ 3054 | | 3055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3057 Figure 21: Configuration Attribute Format 3059 o Reserved (1 bit) - This bit MUST be set to zero and MUST be 3060 ignored. 3062 o Attribute Type (7 bits) - A unique identifier for each of the 3063 Configuration Attribute Types. 3065 o Length (2 octets) - Length in octets of Value. 3067 o Value (0 or more octets) - The variable length value of this 3068 Configuration Attribute. 3070 The following attribute types have been defined: 3072 Multi- 3073 Attribute Type Value Valued Length 3074 ======================= ===== ====== ================== 3075 RESERVED 0 3076 INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets 3077 INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets 3078 INTERNAL_IP4_DNS 3 YES 0 or 4 octets 3079 INTERNAL_IP4_NBNS 4 YES 0 or 4 octets 3080 INTERNAL_ADDRESS_EXPIRY 5 NO 0 or 4 octets 3081 INTERNAL_IP4_DHCP 6 YES 0 or 4 octets 3082 APPLICATION_VERSION 7 NO 0 or more 3083 INTERNAL_IP6_ADDRESS 8 YES* 0 or 16 octets 3084 INTERNAL_IP6_NETMASK 9 NO 0 or 16 octets 3085 INTERNAL_IP6_DNS 10 YES 0 or 16 octets 3086 INTERNAL_IP6_NBNS 11 YES 0 or 16 octets 3087 INTERNAL_IP6_DHCP 12 YES 0 or 16 octets 3088 INTERNAL_IP4_SUBNET 13 NO 0 or 8 octets 3089 SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 3090 INTERNAL_IP6_SUBNET 15 NO 17 octets 3092 * These attributes may be multi-valued on return only if 3093 multiple values were requested. 3095 Types 16-16383 are reserved to IANA. Values 16384-32767 are for 3096 private use among mutually consenting parties. 3098 o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the 3099 internal network, sometimes called a red node address or 3100 private address and MAY be a private address on the Internet. 3101 Multiple internal addresses MAY be requested by requesting 3102 multiple internal address attributes. The responder MAY only 3103 send up to the number of addresses requested. 3105 The requested address is valid until the expiry time defined 3106 with the INTERNAL_ADDRESS EXPIRY attribute or there are no 3107 IKE-SAs between the peers. 3109 o INTERNAL_IP4_NETMASK, INTERNAL_IP6_NETMASK - The internal 3110 network's netmask. Only one netmask is allowed in the request 3111 and reply messages (e.g. 255.255.255.0) and it MUST be used 3112 only with an INTERNAL_ADDRESS attribute. 3114 o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a 3115 DNS server within the network. Multiple DNS servers MAY be 3116 requested. The responder MAY respond with zero or more DNS 3117 server attributes. 3119 o INTERNAL_IP4_NBNS, INTERNAL_IP6_NBNS - Specifies an address of 3120 a NetBios Name Server (WINS) within the network. Multiple NBNS 3121 servers MAY be requested. The responder MAY respond with zero 3122 or more NBNS server attributes. 3124 o INTERNAL_ADDRESS_EXPIRY - Specifies the number of seconds that 3125 the host can use the internal IP address. The host MUST renew 3126 the IP address before this expiry time. Only one of these 3127 attributes MAY be present in the reply. 3129 o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to 3130 send any internal DHCP requests to the address contained within 3131 the attribute. Multiple DHCP servers MAY be requested. The 3132 responder MAY respond with zero or more DHCP server attributes. 3134 o APPLICATION_VERSION - The version or application information of 3135 the IPSec host. This is a string of printable ASCII characters 3136 that is NOT null terminated. 3138 o INTERNAL_IP4_SUBNET - The protected sub-networks that this 3139 edge-device protects. This attribute is made up of two fields; 3140 the first being an IP address and the second being a netmask. 3141 Multiple sub-networks MAY be requested. The responder MAY 3142 respond with zero or more sub-network attributes. 3144 o SUPPORTED_ATTRIBUTES - When used within a Request, this 3145 attribute must be zero length and specifies a query to the 3146 responder to reply back with all of the attributes that it 3147 supports. The response contains an attribute that contains a 3148 set of attribute identifiers each in 2 octets. The length 3149 divided by 2 (bytes) would state the number of supported 3150 attributes contained in the response. 3152 o INTERNAL_IP6_SUBNET - The protected sub-networks that this 3153 edge-device protects. This attribute is made up of two fields; 3154 the first being a 16 octet IPv6 address the second being a one 3155 octet prefix-mask as defined in [ADDRIPV6]. Multiple 3156 sub-networks MAY be requested. The responder MAY respond with 3157 zero or more sub-network attributes. 3159 Note that no recommendations are made in this document how an 3160 implementation actually figures out what information to send in a 3161 reply. i.e. we do not recommend any specific method of an IRAS 3162 determining which DNS server should be returned to a requesting 3163 IRAC. 3165 3.16 Extended Authentication Protocol (EAP) Payload 3167 The Extended Authentication Protocol Payload, denoted EAP in this 3168 memo, allows IKE SAs to be authenticated using the protocol defined 3169 in RFC 2284 [EAP] and subsequent extensions to that protocol. The 3170 full set of acceptable values for the payload are defined elsewhere, 3171 but a short summary of RFC 2284 is included here to make this 3172 document stand alone in the common cases. 3174 1 2 3 3175 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 3176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3177 ! Next Payload !C! RESERVED ! Payload Length ! 3178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3179 ! ! 3180 ~ EAP Message ~ 3181 ! ! 3182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3184 Figure 22: EAP Payload Format 3186 1 2 3 3187 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 3188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3189 ! Code ! Identifier ! Length ! 3190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3191 ! Type ! Type-Data... 3192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 3194 Figure 23: EAP Message Format 3196 o Code (one octet) indicates whether this message is a 3197 Request (1), Response (2), Success (3), or Failure (4). 3199 o Identifier (one octet) is used in PPP to distinguish replayed 3200 messages from repeated ones. Since in IKE, EAP runs over a 3201 reliable protocol, it serves no function here. In a response 3202 message this octet MUST be set to match the identifier in the 3203 corresponding request. In other messages, this field MAY 3204 be set to any value. 3206 o Length (two octets) is the length of the EAP message and MUST 3207 be four less than the Payload Length of the encapsulating 3208 payload. 3210 o Type (one octet) is present only if the Code field is Request 3211 (1) or Response (2). For other types, the EAP message length 3212 MUST be four octets and the Type and Type-Data fields MUST NOT 3213 be present. In a Request (1) message, Type indicates the 3214 data being requested. In a Response (2) message, Type must 3215 either be NAC or match the type of the data requested. The 3216 following types are defined in RFC 2284: 3218 1 Identity 3219 2 Notification 3220 3 NAK (Response Only) 3221 4 MD5-Challenge 3222 5 One-Time Password (OTP) 3223 6 Generic Token Card 3225 o Type-Data (Variable Length) contains data depending on the Code 3226 and Type. In Requests other than MD5-Challenge, this field 3227 contains a prompt to be displayed to a human user. For NAK, it 3228 contains one octet suggesting the form of authentication the 3229 Initiator would prefer to use. For most other responses, it 3230 contains the authentication code typed by the human user. 3232 Note that since IKE passes an indication of initiator identity in 3233 message 3 of the protocol, EAP based prompts for Identity SHOULD NOT 3234 be used. 3236 3.17 Other Payload Types 3238 Payload type values 17-127 are reserved to IANA for future assignment 3239 in IKEv2 (see section 10). Payload type values 128-255 are for 3240 private use among mutually consenting parties. 3242 4 Conformance Requirements 3244 In order to assure that all implementations of IKEv2 can 3245 interoperate, there are MUST support requirements in addition to 3246 those listed elsewhere. Of course, IKEv2 is a security protocol, and 3247 one of its major functions is preventing the bad guys from 3248 interoperating with one's systems. So a particular implementation may 3249 be configured with any of a number of restrictions concerning 3250 algorithms and trusted authorities that will prevent universal 3251 interoperability. 3253 IKEv2 is designed to permit minimal implementations that can 3254 interoperate with all compliant implementations. There are a series 3255 of optional features that can easily be ignored by a particular 3256 implementation if it does not support that feature. Those features 3257 include: 3259 Ability to negotiate SAs through a NAT and tunnel the resulting ESP 3260 SA over UDP. 3262 Ability to request (and respond to a request for) a temporary IP 3263 address on the remote end of a tunnel. 3265 Ability to support various forms of legacy authentication. 3267 Ability to support window sizes greater than one. 3269 Ability to establish multiple ESP and/or AH SAs within a single IKE 3270 SA. 3272 Ability to rekey SAs. 3274 To assure interoperability, all implementations MUST be capable of 3275 parsing all payload types (if only to skip over them) and to ignore 3276 payload types that it does not support unless the critical bit is set 3277 in the payload header. If the critical bit is set in an unsupported 3278 payload header, all implementations MUST reject the messages 3279 containing those payloads. 3281 Every implementation MUST be capable of doing four message 3282 IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, 3283 one for ESP and/or AH). Implementations MAY be initiate-only or 3284 respond-only if appropriate for their platform. Every implementation 3285 MUST be capable of responding to an INFORMATIONAL exchange, but a 3286 minimal implementation MAY respond to any INFORMATIONAL message with 3287 an empty INFORMATIONAL reply. A minimal implementation MAY support 3288 the CREATE_CHILD_SA exchange only in so far as to recognise requests 3289 and reject them with a Notify payload of type NO-ADDITIONAL-SAS. A 3290 minimal implementation need not be able to initiate CREATE_CHILD_SA 3291 or INFORMATIONAL exchanges. When an SA expires (based on either 3292 lifetime or bytes passed), and implementation MAY either try to renew 3293 it with a CREATE_CHILD_SA exchange or it MAY delete (close) the old 3294 SA and create a new one. If the responder rejects the CREATE_CHILD_SA 3295 request with a NO-ADDITIONAL-SAS notification, the implementation 3296 MUST be capable of instead closing the old SA and creating a new one. 3298 Implementations are not required to support requesting temporary IP 3299 addresses or responding to such requests. If an implementation does 3300 support issuing such requests, it MUST include a CP payload in 3301 message 3 containing at least a field of type INTERNAL_IP4_ADDRESS or 3302 INTERNAL_IP6_ADDRESS. All other fields are optional. If an 3303 implementation supports responding to such requests, it MUST parse 3304 the CP payload of type CFG_REQUEST in message 3 and recognise a field 3305 of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports 3306 leasing an address of the appropriate type, it MUST return a CP 3307 payload of type CFG_REPLY containing an address of the requested 3308 type. The responder SHOULD include all of the other related 3309 attributes if it has them. 3311 A minimal responder implementation will ignore the contents of the CP 3312 payload except to determine that it includes an INTERNAL_IP4_ADDRESS 3313 attribute and will respond with the address and other related 3314 attributes regardless of whether the initiator requested them. 3316 A minimal initiator will generate a CP payload containing only an 3317 INTERNAL_IP4_ADDRESS attribute and will parse the response ignoring 3318 attributes it does not know how to use. The only attribute it MUST be 3319 able to process is INTERNAL_ADDRESS_EXPIRY, which it must use to 3320 bound the lifetime of the SA unless it successfully renews the lease 3321 before it expires. Minimal initiators need not be able to request 3322 lease renewals and minimal responders need not respond to them. 3324 For an implementation to be called conforming to this specification, 3325 it MUST be possible to configure it to accept the following: 3327 PKIX Certificates containing and signed by RSA keys of size 1024 or 3328 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, 3329 ID_RFC822_ADDR, or ID_DER_ASN1_DN. 3331 Shared key authentication where the ID passes is any of ID_KEY_ID, 3332 ID_FQDN, or ID_RFC822_ADDR. 3334 Authentication where the responder authenticates using PKIX 3335 Certificates and the initiator authenticates using shared key 3336 authentication. 3338 5 Security Considerations 3340 Repeated re-keying using CREATE_CHILD_SA without PFS leave all SAs 3341 vulnerable to cryptanalysis of a single key or overrun of either 3342 endpoint. Implementers should take note of this fact and set a limit 3343 on CREATE_CHILD_SA exchanges between exponentiations. This memo does 3344 not prescribe such a limit. 3346 The strength of a key derived from a Diffie-Hellman exchange using 3347 any of the groups defined here depends on the inherent strength of 3348 the group, the size of the exponent used, and the entropy provided by 3349 the random number generator used. Due to these inputs it is difficult 3350 to determine the strength of a key for any of the defined groups. 3351 Diffie-Hellman group number two when used with a strong random number 3352 generator and an exponent no less than 160 bits is sufficient to use 3353 for 3DES. Groups three through five provide greater security. Group 3354 one is for historic purposes only and does not provide sufficient 3355 strength to the required cipher (although it is sufficient for use 3356 with DES, which is also for historic use only). Implementations 3357 should make note of these conservative estimates when establishing 3358 policy and negotiating security parameters. 3360 Note that these limitations are on the Diffie-Hellman groups 3361 themselves. There is nothing in IKE which prohibits using stronger 3362 groups nor is there anything which will dilute the strength obtained 3363 from stronger groups. In fact, the extensible framework of IKE 3364 encourages the definition of more groups; use of elliptical curve 3365 groups may greatly increase strength using much smaller numbers. 3367 It is assumed that the Diffie-Hellman exponents in this exchange are 3368 erased from memory after use. In particular, these exponents MUST NOT 3369 be derived from long-lived secrets like the seed to a pseudo-random 3370 generator that is not erased after use. 3372 The security of this protocol is critically dependent on the 3373 randomness of the Diffie-Hellman exponents, which should be generated 3374 by a strong random or properly seeded pseudo-random source (see 3375 RFC1715). While the protocol was designed to be secure even if the 3376 Nonces and other values specified as random are not strongly random, 3377 they should similarly be generated from a strong random source as 3378 part of a conservative design. 3380 6 IANA Considerations 3382 This document contains many "magic numbers" to be maintained by the 3383 IANA. This section explains the criteria to be used by the IANA to 3384 assign additional numbers in each of these lists. 3386 Cryptographic Suite-IDs 3387 Error Codes 3388 Status Codes 3389 IPcomp Transform IDs 3390 Configuration request types 3391 Configuration attribute types 3392 Payload Types 3393 IKE Exchange Types 3395 Values of the Cryptographic Suite-ID define a set of cryptographic 3396 algorithms to be used in an IKE, ESP, or AH SA. Requests for 3397 assignment of new values must be accompanied by a reference to an RFC 3398 that describes how to use these algorithms. 3400 This memo defines four exchange types for use with IKEv2. Requests 3401 for assignment of new exchange types MUST be accompanied by an RFC 3402 which defines the following: 3404 - the purpose of and need for the new exchange. 3405 - the payloads (mandatory and optional) that accompany 3406 messages in the exchange. 3407 - when the exchange may take place. 3408 - requirements the new exchange has on existing 3409 exchanges which have assigned numbers. 3411 Payloads are defined in this memo to convey information between 3412 peers. New payloads may be required when defining a new 3413 authentication method or exchange. Requests for new payload types 3414 MUST be accompanied by an RFC which defines the physical layout of 3415 the payload and the fields it contains. All payloads MUST use the 3416 same generic header defined in Figure 5. 3418 7 Acknowledgements 3420 This document is a collaborative effort of the entire IPsec WG. If 3421 there were no limit to the number of authors that could appear on an 3422 RFC, the following, in alphabetical order, would have been listed: 3423 Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt 3424 Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, J. 3425 Ioannidis, Steve Kent, Angelos Keromytis, Tero Kivinen, Hugo 3426 Krawczyk, Andrew Krywaniuk, Radia Perlman, O. Reingold. Many other 3427 people contributed to the design. It is an evolution of IKEv1, 3428 ISAKMP, and the IPSec DOI, each of which has its own list of authors. 3429 Hugh Daniel suggested the feature of having the initiator, in message 3430 3, specify a name for the responder, and gave the feature the cute 3431 name "You Tarzan, Me Jane". David Faucher and Valery Smyzlov helped 3432 refine the design of the traffic selector negotiation. 3434 8 References 3436 8.1 Normative References 3438 [Bra96] Bradner, S., "The Internet Standards Process -- Revision 3", 3439 BCP 9, RFC 2026, October 1996. 3441 [Bra97] Bradner, S., "Key Words for use in RFCs to indicate 3442 Requirement Levels", BCP 14, RFC 2119, March 1997. 3444 [EAP] Blunk, L. and Volibrecht, J., "PPP Extensible Authentication 3445 Protocol (EAP), RFC 2284, March 1998. 3447 8.2 Non-normative References 3449 [Ble98] Bleichenbacher, D., "Chosen Ciphertext Attacks against 3450 Protocols Based on RSA Encryption Standard PKCS#1", Advances 3451 in Cryptology Eurocrypt '98, Springer-Verlag, 1998. 3453 [BR94] Bellare, M., and Rogaway P., "Optimal Asymmetric 3454 Encryption", Advances in Cryptology Eurocrypt '94, 3455 Springer-Verlag, 1994. 3457 [DES] ANSI X3.106, "American National Standard for Information 3458 Systems-Data Link Encryption", American National Standards 3459 Institute, 1983. 3461 [DH] Diffie, W., and Hellman M., "New Directions in 3462 Cryptography", IEEE Transactions on Information Theory, V. 3463 IT-22, n. 6, June 1977. 3465 [DHCP] R. Droms, "Dynamic Host Configuration Protocol", 3466 RFC2131 3468 [DSS] NIST, "Digital Signature Standard", FIPS 186, National 3469 Institute of Standards and Technology, U.S. Department of 3470 Commerce, May, 1994. 3472 [HC98] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", 3473 RFC 2409, November 1998. 3475 [IDEA] Lai, X., "On the Design and Security of Block Ciphers," ETH 3476 Series in Information Processing, v. 1, Konstanz: Hartung- 3477 Gorre Verlag, 1992 3479 [Ker01] Keronytis, A., Sommerfeld, B., "The 'Suggested ID' Extension 3480 for IKE", draft-keronytis-ike-id-00.txt, 2001 3482 [KBC96] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 3483 Hashing for Message Authentication", RFC 2104, February 3484 1997. 3486 [LDAP] M. Wahl, T. Howes, S. Kille., "Lightweight Directory 3487 Access Protocol (v3)", RFC2251 3489 [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, 3490 April 1992. 3492 [MSST98] Maughhan, D., Schertler, M., Schneider, M., and Turner, J. 3493 "Internet Security Association and Key Management Protocol 3494 (ISAKMP)", RFC 2408, November 1998. 3496 [Orm96] Orman, H., "The Oakley Key Determination Protocol", RFC 3497 2412, November 1998. 3499 [PFKEY] McDonald, D., Metz, C., and Phan, B., "PFKEY Key Management 3500 API, Version 2", RFC2367, July 1998. 3502 [PKCS1] Kaliski, B., and J. Staddon, "PKCS #1: RSA Cryptography 3503 Specifications Version 2", September 1998. 3505 [PK01] Perlman, R., and Kaufman, C., "Analysis of the IPsec key 3506 exchange Standard", WET-ICE Security Conference, MIT, 2001, 3507 http://sec.femto.org/wetice-2001/papers/radia-paper.pdf. 3509 [Pip98] Piper, D., "The Internet IP Security Domain Of 3510 Interpretation for ISAKMP", RFC 2407, November 1998. 3512 [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote 3513 Authentication Dial In User Service (RADIUS)", RFC2138 3515 [RSA] Rivest, R., Shamir, A., and Adleman, L., "A Method for 3516 Obtaining Digital Signatures and Public-Key Cryptosystems", 3517 Communications of the ACM, v. 21, n. 2, February 1978. 3519 [SHA] NIST, "Secure Hash Standard", FIPS 180-1, National Institute 3520 of Standards and Technology, U.S. Department of Commerce, 3521 May 1994. 3523 [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange 3524 Mechanism for Internet", from IEEE Proceedings of the 1996 3525 Symposium on Network and Distributed Systems Security. 3527 Appendix A: Summary of changes from IKEv1 3529 The goals of this revision to IKE are: 3531 1) To define the entire IKE protocol in a single document, replacing 3532 RFCs 2407, 2408, and 2409 and incorporating subsequent changes to 3533 support NAT Traversal, Extended Authentication, and Remote Address 3534 acquisition. 3536 2) To simplify IKE by replacing the eight different initial exchanges 3537 with a single four message exchange (with changes in authentication 3538 mechanisms affecting only a single AUTH payload rather than 3539 restructuring the entire exchange); 3541 3) To remove the Domain of Interpretation (DOI), Situation (SIT), and 3542 Labeled Domain Identifier fields, and the Commit and Authentication 3543 only bits; 3545 4) To decrease IKE's latency in the common case by making the initial 3546 exchange be 2 round trips (4 messages), and allowing the ability to 3547 piggyback setup of a CHILD-SA on that exchange; 3549 5) To replace the cryptographic syntax for protecting the IKE 3550 messages themselves with one based closely on ESP to simplify 3551 implementation and security analysis; 3553 6) To reduce the number of possible error states by making the 3554 protocol reliable (all messages are acknowledged) and sequenced. This 3555 allows shortening CREATE_CHILD_SA exchanges from 3 messages to 2; 3557 7) To increase robustness by allowing the responder to not do 3558 significant processing until it receives a message proving that the 3559 initiator can receive messages at its claimed IP address, and not 3560 commit any state to an exchange until the initiator can be 3561 cryptographically authenticated; 3563 8) To fix bugs such as the hash problem documented in [draft-ietf- 3564 ipsec-ike-hash-revised-02.txt]; 3566 9) To specify Traffic Selectors in their own payloads type rather 3567 than overloading ID payloads, and making more flexible the Traffic 3568 Selectors that may be specified; 3570 10) To replace the complex mix and match negotiation of cryptographic 3571 algorithms with proposals based on suites of algorithms; 3573 11) To specify required behavior under certain error conditions or 3574 when data that is not understood is received in order to make it 3575 easier to make future revisions in a way that does not break 3576 backwards compatibility; 3578 12) To incorporate ideas from draft-ietf-ipsec-nat-reqts-02.txt to 3579 allow IKE to negotiate through NAT gateways; 3581 12) To simplify and clarify how shared state is maintained in the 3582 presence of network failures and Denial of Service attacks; and 3584 13) To maintain existing syntax and magic numbers to the extent 3585 possible to make it likely that implementations of IKEv1 can be 3586 enhanced to support IKEv2 with minimum effort. 3588 Appendix B: Diffie-Hellman Groups 3590 There are 5 groups different Diffie-Hellman groups defined for use in 3591 IKE. These groups were generated by Richard Schroeppel at the 3592 University of Arizona. Properties of these primes are described in 3593 [Orm96]. 3595 The strength supplied by group one may not be sufficient for the 3596 mandatory-to-implement encryption algorithm and is here for historic 3597 reasons. 3599 Additional Diffie-Hellman groups have been defined in [ADDGROUP]. 3600 Future IANA-registered and private use Suite-IDs MAY use Diffie- 3601 Hellman groups that have modulus values and generators that are 3602 different than those in this document or in [ADDGROUP]. 3604 B.1 Group 1 - 768 Bit MODP 3606 IKE implementations MAY support a MODP group with the following prime 3607 and generator. This group is assigned id 1 (one). 3609 The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } 3610 Its hexadecimal value is: 3612 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 3613 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 3614 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 3615 A63A3620 FFFFFFFF FFFFFFFF 3617 The generator is 2. 3619 B.2 Group 2 - 1024 Bit MODP 3621 IKE implementations SHOULD support a MODP group with the following 3622 prime and generator. This group is assigned id 2 (two). 3624 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. 3625 Its hexadecimal value is: 3627 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 3628 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 3629 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 3630 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 3631 49286651 ECE65381 FFFFFFFF FFFFFFFF 3633 The generator is 2. 3635 B.3 Group 3 - 155 Bit EC2N 3637 IKE implementations MAY support a EC2N group with the following 3638 characteristics. This group is assigned id 3 (three). The curve is 3639 based on the Galois Field GF[2^155]. The field size is 155. The 3640 irreducible polynomial for the field is: 3641 u^155 + u^62 + 1. 3642 The equation for the elliptic curve is: 3643 y^2 + xy = x^3 + ax^2 + b. 3645 Field Size: 155 3646 Group Prime/Irreducible Polynomial: 3647 0x0800000000000000000000004000000000000001 3648 Group Generator One: 0x7b 3649 Group Curve A: 0x0 3650 Group Curve B: 0x07338f 3651 Group Order: 0x0800000000000000000057db5698537193aef944 3653 The data in the KE payload when using this group is the value x from 3654 the solution (x,y), the point on the curve chosen by taking the 3655 randomly chosen secret Ka and computing Ka*P, where * is the 3656 repetition of the group addition and double operations, P is the 3657 curve point with x coordinate equal to generator 1 and the y 3658 coordinate determined from the defining equation. The equation of 3659 curve is implicitly known by the Group Type and the A and B 3660 coefficients. There are two possible values for the y coordinate; 3661 either one can be used successfully (the two parties need not agree 3662 on the selection). 3664 B.4 Group 4 - 185 Bit EC2N 3666 IKE implementations MAY support a EC2N group with the following 3667 characteristics. This group is assigned id 4 (four). The curve is 3668 based on the Galois Field GF[2^185]. The field size is 185. The 3669 irreducible polynomial for the field is: 3670 u^185 + u^69 + 1. 3672 The equation for the elliptic curve is: 3673 y^2 + xy = x^3 + ax^2 + b. 3675 Field Size: 185 3676 Group Prime/Irreducible Polynomial: 3677 0x020000000000000000000000000000200000000000000001 3678 Group Generator One: 0x18 3679 Group Curve A: 0x0 3680 Group Curve B: 0x1ee9 3681 Group Order: 0x01ffffffffffffffffffffffdbf2f889b73e484175f94ebc 3683 The data in the KE payload when using this group will be identical to 3684 that as when using Oakley Group 3 (three). 3686 B.5 Group 5 - 1536 Bit MODP 3688 IKE implementations MUST support a MODP group with the following 3689 prime and generator. This group is assigned id 5 (five). 3691 The prime is 2^1536 - 2^1472 - 1 + 2^64 * {[2^1406 pi] + 741804}. 3692 Its hexadecimal value is 3694 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 3695 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 3696 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 3697 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 3698 49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 3699 FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 3700 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF 3702 The generator is 2. 3704 Change History 3706 H.1 Changes from IKEv2-00 to IKEv2-01 February 2002 3708 1) Changed Appendix B to specify the encryption and authentication 3709 processing for IKE rather than referencing ESP. Simplified the format 3710 by removing idiosyncracies not needed for IKE. 3712 2) Added option for authentication via a shared secret key. 3714 3) Specified different keys in the two directions of IKE messages. 3715 Removed requirement of different cookies in the two directions since 3716 now no longer required. 3718 4) Change the quantities signed by the two ends in AUTH fields to 3719 assure the two parties sign different quantities. 3721 5) Changed reference to AES to AES_128. 3723 6) Removed requirement that Diffie-Hellman be repeated when rekeying 3724 IKE-SA. 3726 7) Fixed typos. 3728 8) Clarified requirements around use of port 500 at the remote end in 3729 support of NAT. 3731 9) Clarified required ordering for payloads. 3733 10) Suggested mechanisms for avoiding DoS attacks. 3735 11) Removed claims in some places that the first phase 2 piggybacked 3736 on phase 1 was optional. 3738 H.2 Changes from IKEv2-01 to IKEv2-02 April 2002 3740 1) Moved the Initiator CERTREQ payload from message 1 to message 3. 3742 2) Added a second optional ID payload in message 3 for the Initiator 3743 to name a desired Responder to support the case where multiple named 3744 identities are served by a single IP address. 3746 3) Deleted the optimization whereby the Diffie-Hellman group did not 3747 need to be specified in phase 2 if it was the same as in phase 1 (it 3748 complicated the design with no meaningful benefit). 3750 4) Added a section on the implications of reusing Diffie-Hellman 3751 expontentials 3753 5) Changed the specification of sequence numbers to being at 0 in 3754 both directions. 3756 6) Many editorial changes and corrections, the most significant being 3757 a global replace of "byte" with "octet". 3759 H.3 Changes from IKEv2-02 to IKEv2-03 October 2002 3761 1) Reorganized the document moving introductory material to the 3762 front. 3764 2) Simplified the specification of Traffic Selectors to allow only 3765 IPv4 and IPv6 address ranges, as was done in the JFK spec. 3767 3) Fixed the problem brought up by David Faucher with the fix 3768 suggested by Valery Smyslov. If Bob needs to narrow the selector 3769 range, but has more than one matching narrower range, then if Alice's 3770 first selector is a single address pair, Bob chooses the range that 3771 encompasses that. 3773 4) To harmonize with the JFK spec, changed the exchange so that the 3774 initial exchange can be completed in four messages even if the 3775 responder must invoke an anti-clogging defense and the initiator 3776 incorrectly anticipates the responder's choice of Diffie-Hellman 3777 group. 3779 5) Replaced the hierarchical SA payload with a simplified version 3780 that only negotiates suites of cryptographic algorithms. 3782 H.4 Changes from IKEv2-03 to IKEv2-04 January 2003 3784 1) Integrated NAT traversal changes (including Appendix A). 3786 2) Moved the anti-clogging token (cookie) from the SPI to a NOTIFY 3787 payload; changed negotation back to 6 messages when a cookie is 3788 needed. 3790 3) Made capitalization of IKE-SA and CHILD-SA consistent. 3792 4) Changed how IPcomp was negotiated. 3794 5) Added usage scenarios. 3796 6) Added configuration payload for acquiring internal addresses on 3797 remote networks. 3799 7) Added negotiation of tunnel vs transport mode. 3801 H.4 Changes from IKEv2-05 to IKEv2-05 February 2003 3803 1) Shortened Abstract 3805 2) Moved NAT Traversal from Appendix to section 2. Moved changes from 3806 IKEv2 to Appendix A. Renumbered sections. 3808 3) Made language more consistent. Removed most references to Phase 1 3809 and Phase 2. 3811 4) Made explicit the requirements for support of NAT Traversal. 3813 5) Added support for Extended Authentication Protocol methods. 3815 6) Added Response bit to message header. 3817 7) Made more explicit the encoding of Diffie-Hellman numbers in key 3818 expansion algorithms. 3820 8) Added ID payloads to AUTH payload computation. 3822 9) Expanded set of defined cryptographic suites. 3824 10) Added text for MUST/SHOULD support for ID payloads. 3826 11) Added new certificate formats and added MUST/SHOULD text. 3828 12) Clarified use of CERTREQ. 3830 13) Deleted "MUST SUPPORT" column in CP payload specification (it was 3831 inconsistent with surrounding text). 3833 14) Extended and clarified Conformance Requirements section, 3834 including specification of a minimal implementation. 3836 15) Added text to specify ECN handling. 3838 Author's Address 3840 Charlie Kaufman charlie_kaufman@notesdev.ibm.com IBM 3842 Full Copyright Statement 3844 "Copyright (C) The Internet Society (2003). All Rights Reserved. 3846 This document and translations of it may be copied and furnished to 3847 others, and derivative works that comment on or otherwise explain it 3848 or assist in its implementation may be prepared, copied, published 3849 and distributed, in whole or in part, without restriction of any 3850 kind, provided that the above copyright notice and this paragraph are 3851 included on all such copies and derivative works. However, this 3852 document itself may not be modified in any way, such as by removing 3853 the copyright notice or references to the Internet Society or other 3854 Internet organizations, except as needed for the purpose of 3855 developing Internet standards in which case the procedures for 3856 copyrights defined in the Internet Standards process must be 3857 followed, or as required to translate it into languages other than 3858 English. 3860 The limited permissions granted above are perpetual and will not be 3861 revoked by the Internet Society or its successors or assigns. 3863 This document and the information contained herein is provided on an 3864 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3865 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3866 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3867 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3868 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."