idnits 2.17.1 draft-ietf-ipsec-ikev2-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-16) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 58 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 59 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 2655 has weird spacing: '... The equati...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A fully-qualified domain name string. An example of a ID_FQDN is, "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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Vendor ID payload is not an announcement from the sender that it will send private payload types but rather an announcement of the sort of private payloads it is willing to accept. The implementation sending the Vendor ID MUST not make any assumptions about private payloads that it may send unless a Vendor ID of like stature is received as well. Multiple Vendor ID payloads MAY be sent. An implementation is NOT REQUIRED to send any Vendor ID payload at all. -- 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 (October 2002) is 7854 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 302, but not defined == Missing Reference: 'CERT' is mentioned on line 301, but not defined == Missing Reference: 'IDr' is mentioned on line 303, but not defined == Missing Reference: 'KEi' is mentioned on line 354, but not defined == Missing Reference: 'KEr' is mentioned on line 369, but not defined == Missing Reference: 'RFC 2522' is mentioned on line 696, but not defined == Unused Reference: 'Ble98' is defined on line 2507, but no explicit reference was found in the text == Unused Reference: 'BR94' is defined on line 2511, but no explicit reference was found in the text == Unused Reference: 'DES' is defined on line 2515, but no explicit reference was found in the text == Unused Reference: 'DH' is defined on line 2519, but no explicit reference was found in the text == Unused Reference: 'DSS' is defined on line 2523, but no explicit reference was found in the text == Unused Reference: 'HC98' is defined on line 2527, but no explicit reference was found in the text == Unused Reference: 'IDEA' is defined on line 2530, but no explicit reference was found in the text == Unused Reference: 'Ker01' is defined on line 2534, but no explicit reference was found in the text == Unused Reference: 'KBC96' is defined on line 2537, but no explicit reference was found in the text == Unused Reference: 'SKEME' is defined on line 2541, but no explicit reference was found in the text == Unused Reference: 'MD5' is defined on line 2545, but no explicit reference was found in the text == Unused Reference: 'MSST98' is defined on line 2548, but no explicit reference was found in the text == Unused Reference: 'PKCS1' is defined on line 2558, but no explicit reference was found in the text == Unused Reference: 'PK01' is defined on line 2561, but no explicit reference was found in the text == Unused Reference: 'Pip98' is defined on line 2565, but no explicit reference was found in the text == Unused Reference: 'RSA' is defined on line 2568, but no explicit reference was found in the text == Unused Reference: 'SHA' is defined on line 2572, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Ble98' -- Possible downref: Non-RFC (?) normative reference: ref. 'BR94' -- Possible downref: Non-RFC (?) normative reference: ref. 'DES' -- Possible downref: Non-RFC (?) normative reference: ref. 'DH' -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS' ** Obsolete normative reference: RFC 2409 (ref. 'HC98') (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. 'IDEA' -- No information found for draft-keronytis-ike-id - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Ker01' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'KBC96') -- Possible downref: Non-RFC (?) normative reference: ref. 'SKEME' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') ** Obsolete normative reference: RFC 2408 (ref. 'MSST98') (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 2412 (ref. 'Orm96') ** Downref: Normative reference to an Informational RFC: RFC 2367 (ref. 'PFKEY') -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS1' -- Possible downref: Non-RFC (?) normative reference: ref. 'PK01' ** Obsolete normative reference: RFC 2407 (ref. 'Pip98') (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. 'RSA' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA' Summary: 15 errors (**), 0 flaws (~~), 31 warnings (==), 16 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-03.txt October 2002 6 Internet Key Exchange (IKEv2) Protocol 7 9 Status of this Memo 11 This document is an Internet Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026 [Bra96]. Internet Drafts are 13 working documents of the Internet Engineering Task Force (IETF), its 14 areas, and working groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet Drafts as reference 20 material or to cite them other than as "work in progress." 22 To learn the current status of any Internet Draft, please check the 23 "1id-abstracts.txt" listing contained in the Internet Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Australia), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 This document describes version 2 of the IKE (Internet Key Exchange) 31 protocol. IKE performs mutual authentication and establishes an IKE 32 security association that can be used to efficiently establish SAs 33 for ESP, AH and/or IPcomp. This version greatly simplifies IKE by 34 replacing the 8 possible phase 1 exchanges with a single exchange 35 based on either public signature keys or shared secret keys. The 36 single exchange provides identity hiding, yet works in 2 round trips 37 (all the identity hiding exchanges in IKE v1 required 3 round trips). 38 Latency of setup of an IPsec SA is further reduced from IKEv1 by 39 allowing setup of an SA for ESP, AH, and/or IPcomp to be piggybacked 40 on the initial IKE exchange. It also improves security by allowing 41 the Responder to be stateless until it can be assured that the 42 Initiator can receive at the claimed IP source address. This version 43 also presents the entire protocol in a single self-contained 44 document, in contrast to IKEv1, in which the protocol was described 45 in ISAKMP (RFC 2408), IKE (RFC 2409), and the DOI (RFC 2407) 46 documents. 48 Table of Contents 50 Abstract.....................................................1 51 1 Summary of Changes from IKEv1..............................3 52 2 Requirements Terminology...................................4 53 3 IKE Protocol Overview......................................4 54 3.1 The Initial (Phase 1) Exchange...........................6 55 3.2 The CREATE_CHILD_SA (Phase 2) Exchange...................7 56 3.3 Informational (Phase 2) Exchange.........................9 57 4 IKE Protocol Details and Variations.......................10 58 4.1 Use of Retransmission Timers............................10 59 4.2 Use of Sequence Numbers for Message ID..................11 60 4.3 Window Size for overlapping requests....................12 61 4.4 State Synchronization and Connection Timeouts...........12 62 4.5 Version Numbers and Forward Compatibility...............14 63 4.6 Cookies.................................................15 64 4.7 Cryptographic Algorithm Negotiation.....................18 65 4.8 Rekeying................................................19 66 4.9 Traffic Selector Negotiation............................20 67 4.10 Nonces.................................................21 68 4.11 Address and Port Agility...............................22 69 4.12 Reuse of Diffie-Hellman Exponentials...................22 70 4.13 Generating Keying Material.............................23 71 4.14 Generating Keying Material for the IKE-SA..............23 72 4.15 Authentication of the IKE-SA...........................24 73 4.16 Generating Keying Material for Child-SAs...............25 74 4.17 Rekaying IKE-SAs using a CREATE_CHILD_SA exchange......26 75 4.18 Error Handling.........................................26 76 5 Header and Payload Formats................................27 77 5.1 The IKE Header..........................................27 78 5.2 Generic Payload Header..................................30 79 5.3 Security Association Payload............................31 80 5.3.1 Proposal Substructure.................................32 81 5.4 Key Exchange Payload....................................33 82 5.5 Identification Payload..................................34 83 5.6 Certificate Payload.....................................36 84 5.7 Certificate Request Payload.............................37 85 5.8 Authentication Payload..................................38 86 5.9 Nonce Payload...........................................39 87 5.10 Notify Payload.........................................40 88 5.10.1 Notify Message Types.................................41 89 5.11 Delete Payload.........................................43 90 5.12 Vendor ID Payload......................................45 91 5.13 Traffic Selector Payload...............................46 92 5.13.1 Traffic Selector.....................................46 93 5.14 Encrypted Payload......................................48 94 5.15 Other Payload types....................................49 95 6 Conformance Requirements..................................50 96 7 Security Considerations...................................50 97 8 IANA Considerations.......................................51 98 9 Acknowledgements..........................................52 99 10 References...............................................52 100 Appendix B: Diffie-Hellman Groups...........................55 101 Change History..............................................58 102 Author's Address............................................59 104 1 Summary of changes from IKEv1 106 The goals of this revision to IKE are: 108 1) To define the entire IKE protocol in a single document, rather 109 than three that cross reference one another; 111 2) To simplify IKE by replacing the eight different initial phase 1 112 exchanges with a single four message exchange (with changes in 113 authentication mechanisms affecting only a single AUTH payload rather 114 than restructuring the entire exchange); 116 3) To remove the Domain of Interpretation (DOI), Situation (SIT), and 117 Labeled Domain Identifier fields, and the Commit and Authentication 118 only bits; 120 4) To decrease IKE's latency by making the initial exchange be 2 121 round trips (4 messages), and allowing the ability to piggyback setup 122 of a Child-SA on that exchange; 124 5) To replace the cryptographic syntax for protecting the IKE 125 messages themselves with one based closely on ESP to simplify 126 implementation and security analysis; 128 6) To reduce the number of possible error states by making the 129 protocol reliable (all messages are acknowledged) and sequenced. This 130 allows shortening Phase 2 exchanges from 3 messages to 2; 132 7) To increase robustness by allowing the responder to not do 133 significant processing until it receives a message proving that the 134 initiator can receive messages at its claimed IP address, and not 135 commit any state to an exchange until the initiator can be 136 cryptographically authenticated; 138 8) To fix bugs such as the hash problem documented in [draft-ietf- 139 ipsec-ike-hash-revised-02.txt]; 141 9) To specify Traffic Selectors in their own payloads type rather 142 than overloading ID payloads, and making more flexible the Traffic 143 Selectors that may be specified; 145 10) To replace the complex mix and match negotiation of cryptographic 146 algorithms with proposals based on suites of algorithms. 148 11) To specify required behavior under certain error conditions or 149 when data that is not understood is received in order to make it 150 easier to make future revisions in a way that does not break 151 backwards compatibility; 153 12) To simplify and clarify how shared state is maintained in the 154 presence of network failures and Denial of Service attacks; and 156 13) To maintain existing syntax and magic numbers to the extent 157 possible to make it likely that implementations of IKEv1 can be 158 enhanced to support IKEv2 with minimum effort. 160 2 Requirements Terminology 162 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 163 "MAY" that appear in this document are to be interpreted as described 164 in [Bra97]. 166 3 IKE Protocol Overview 168 IP Security (IPsec) provides confidentiality, data integrity, and 169 data source authentication to IP datagrams. These services are 170 provided by maintaining shared state between the source and the sink 171 of an IP datagram. This state defines, among other things, the 172 specific services provided to the datagram, which cryptographic 173 algorithms will be used to provide the services, and the keys used as 174 input to the cryptographic algorithms. 176 Establishing this shared state in a manual fashion does not scale 177 well. Therefore a protocol to establish this state dynamically is 178 needed. This memo describes such a protocol-- the Internet Key 179 Exchange (IKE). This is version 2 of IKE. Version 1 of IKE was 180 defined in RFCs 2407, 2408, and 2409. This single document is 181 intended to replace all three of those RFCs. 183 IKE performs mutual authentication between two parties and 184 establishes an IKE security association that includes shared secret 185 information that can be used to efficiently establish SAs for ESP 186 (RFC 2406), AH (RFC 2402) and/or IPcomp (RFC 2393). We call the IKE 187 SA an "IKE-SA". The SAs for ESP, AH, and/or IPcomp that get set up 188 through that IKE-SA we call "child-SA"s. 190 We call the first four messages establishing an IKE-SA a "phase 1" 191 exchange and subsequent IKE exchanges "phase 2", inheriting this 192 terminology from IKEv1. The phase 1 exchange establishes the IKE-SA 193 and the first child-SA. In some scenarios, only a single child-SA is 194 needed between the IPsec endpoints and therefore there would be no 195 phase 2 exchanges. Phase 2 exchanges MAY be used to establish 196 additional child-SAs between the same authenticated pair of endpoints 197 as well as other housekeeping. The phase 1 exchange consists of two 198 request/response pairs. A phase 2 exchange is one request/response 199 pair, and can be used to create or delete a child-SA, rekey or delete 200 the IKE-SA, or report information such as error conditions. 202 IKE message flow always consists of a request followed by a response. 203 It is the responsibility of the requester to ensure reliability. If 204 the response is not received within a timeout interval, the requester 205 MUST retransmit the request (or abandon the connection). 207 The first request/response of a phase 1 exchange negotiates security 208 parameters for the IKE-SA, sends nonces, and sends Diffie-Hellman 209 values. We call the request message IKE_SA_init and the response 210 IKE_SA_init_response. 212 The second request/response, which we'll call IKE_auth and 213 IKE_auth_response transmits identities, proves knowledge of the 214 secrets corresponding to the two identities, and sets up an SA for 215 the first (and often only) AH and/or ESP and/or IPcomp child-SA. In 216 order to allow Bob to be stateless until receiving message 3, message 217 3 must repeat all of message 1 and Bob must be able to reconstruct 218 (bit for bit) what he sent in message 2. 220 Phase 2 exchanges each consist of a single request/response pair. The 221 types of exchanges are CREATE_CHILD_SA (which creates a child-SA), or 222 an Informational exchange which deletes a child-SA or the IKE-SA or 223 informs the other side of some error condition. All these messages 224 require a response. An informational message with no payloads is 225 commonly used as a check for liveness. 227 In the description that follow, we assume that no errors occur. 228 Modifications to the flow should errors occur are described in 229 section 4. 231 3.1 The Initial (Phase 1) Exchange 233 The base Phase 1 exchange is a four message exchange (two 234 request/response pairs). The first pair of messages (IKE_SA_init) 235 negotiate cryptographic algorithms, exchange nonces, and do a 236 Diffie-Hellman exchange. 238 The second pair of messages (IKE_AUTH) authenticate the previous 239 messages, exchange identities and certificates, and establish the 240 first child_SA. Parts of these messages are encrypted and integrity 241 protected with keys established through the IKE_SA_init exchange, so 242 the identities are hidden from eavesdroppers and all fields in all 243 the messages are authenticated. 245 In the following description, the payloads contained in the message 246 are indicated by names such as SA. The details of the contents of 247 each payload are described later. Payloads which may optionally 248 appear will be shown in brackets, such as [CERTREQ], would indicate 249 that optionally a certificate request payload can be included. 251 The Phase 1 exchange is as follows: 253 Initiator Responder 254 ----------- ----------- 255 HDR, SAi1, KEi, Ni --> 257 HDR contains the SPIs (formerly called cookies), version numbers, and 258 flags of various sorts. The SAi1 payload states the cryptographic 259 algorithms the Initiator supports for the IKE SA. The KE payload 260 sends the Initiator's Diffie-Hellman value. Ni is the Initiator's 261 nonce. 263 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 265 The Responder chooses a cryptographic suite from the Initiator's 266 offered choices and expresses that choice in the SAr1 payload, 267 completes the Diffie-Hellman exchange with the KEr payload, and sends 268 its nonce in the Nr payload. 270 At this point in time each party can generate SKEYSEED from which all 271 keys are derived for that IKE SA. Parts of the following two 272 messages, the IKE_AUTH and IKE_AUTH_response, are encrypted and 273 integrity protected. The keys used for the encryption and integrity 274 protection are derived from SKEYSEED and are known as SK_e 275 (encryption) and SK_a (authentication, a.k.a. integrity protection). 276 A separate SK_e and SK_a is computed for each direction. The 277 notation SK { ... } indicates that these payloads are encrypted and 278 integrity protected using that direction's SK_e and SK_a. 280 HDR, SAi1, KEi, Ni, Nr, 281 SK {IDi, [CERT,] [CERTREQ,] [IDr,] 282 AUTH, SAi2, TSi, TSr} --> 284 The initial payloads in message three are identical to the payloads 285 in message 1. If message 1 included any optional payloads (e.g. 287 Vendor ID), they must be repeated in message 3 in the same order. 288 Then she includes Nr (Bob's nonce) copied from message 2. The 289 Initiator identifies herself with the IDi payload, proves knowledge 290 of the secret corresponding to IDi and integrity protects the 291 contents of the first two messages using the AUTH payload. She might 292 also send her certificate(s) in CERT payload(s) and a list of her 293 trust anchors in CERTREQ payload(s). The optional payload IDr 294 enables Alice to specify which of Bob's identities she wants to talk 295 to. This is useful when Bob is hosting multiple identities at the 296 same IP address. She begins negotiation of a child-SA using the SAi2 297 payload. The fields starting with SAi2 are described in the 298 description of Phase 2. 300 There are optional fields where the Initiator can provide 301 certificates [CERT] the Responder might find useful in validating 302 AUTH, her list of preferred root certifiers [CERTREQ], and the name 303 of the entity with which she is trying to open a connection [IDr] 304 (for the case where multiple named entities exist at a single IP 305 address). 307 <-- HDR, SK {IDr, [CERT,] AUTH, 308 SAr2, TSi, TSr} 310 The Responder identifies himself with the IDr payload, optionally 311 sends one or more certificates, authenticates himself with the AUTH 312 payload, and completes negotiation of a child-SA with the additional 313 fields described below in the phase 2 exchange. 315 The recipients of messages 3 and 4 MUST verify that all signatures 316 and MACs are computed correctly and that the names in the ID payloads 317 correspond to the keys used to generate the AUTH payload. 319 3.2 The CREATE_CHILD_SA (Phase 2) Exchange 321 A phase 2 exchange is one request/response pair, and can be used to 322 create or delete a child-SA, delete or rekey the IKE-SA, check the 323 liveness of the IKE-SA, or deliver information such as error 324 conditions. It is encrypted and integrity protected using the keys 325 negotiated during the creation of the IKE-SA. 327 Messages are cryptographically protected using the cryptographic 328 algorithms and keys negotiated in the first two messages of the IKE 329 exchange using a syntax described in section 5.14. Encryption uses 330 keys derived from SK_e, one in each direction; Integrity uses keys 331 derived from SK_a, one in each direction. 333 Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this 334 section the term Initiator refers to the endpoint initiating this 335 exchange. 337 A child-SA is created by sending a CREATE_CHILD_SA request. The 338 CREATE_CHILD_SA request MAY optionally contain a KE payload for an 339 additional Diffie-Hellman exchange to enable stronger guarantees of 340 forward secrecy for the child-SA. The keying material for the child- 341 SA is a function of SK_d established during the establishment of the 342 IKE-SA, the nonces exchanged during the CREATE_CHILD_SA exchange, and 343 the Diffie-Hellman value (if KE payloads are included in the 344 CREATE_CHILD_SA exchange). 346 In the child-SA created as part of the phase 1 exchange, a second KE 347 payload MUST NOT be used, and the Nonces are not transmitted but are 348 assumed to be the same as the phase 1 nonces. 350 The CREATE_CHILD_SA request contains: 352 Initiator Responder 353 ----------- ----------- 354 HDR, SK {SA, Ni, [KEi], 355 [TSi, TSr]} --> 357 The Initiator sends SA offer(s) in the SA payload, a nonce in the Ni 358 payload, optionally a Diffie-Hellman value in the KEi payload, and 359 the proposed traffic selectors in the TSi and TSr payloads. If the SA 360 offers include different Diffie-Hellman groups, KEi must be an 361 element of the first group offered. 363 The message past the header is encrypted and the message including 364 the header is integrity protected using the cryptographic algorithms 365 negotiated in Phase 1. 367 The CREATE_CHILD_SA response contains: 369 <-- HDR, SK {SA, Nr, [KEr], 370 [TSi, TSr]} 372 The Responder replies (using the same Message ID to respond) with the 373 accepted offer in an SA payload, a Diffie-Hellman value in the KEr 374 payload if KEi was included in the request and the selected 375 cryptographic suite includes that group. If the responder chooses a 376 cryptographic suite with a different group, it must reject the 377 request and have the initiator make another one. 379 The traffic selectors for traffic to be sent on that SA are specified 380 in the TS payloads, which may be a subset of what the Initiator of 381 the child-SA proposed. Traffic selectors are omitted if this 382 CREATE_CHILD_SA request is being used to change the key of the IKE- 383 SA. 385 3.3 Informational (Phase 2) Exchange 387 At various points during an IKE-SA, peers may desire to convey 388 control messages to each other regarding errors or notifications of 389 certain events. To accomplish this IKE defines a (reliable) 390 Informational exchange. Usually Informational exchanges happen 391 during phase 2 and are cryptographically protected with the IKE 392 exchange. 394 Control messages that pertain to an IKE-SA MUST be sent under that 395 IKE-SA. Control messages that pertain to Child-SAs MUST be sent under 396 the protection of the IKE-SA which generated them (or its successor 397 if the IKE-SA is replaced for the purpose of rekeying). 399 There are two cases in which there is no IKE-SA to protect the 400 information. One is in the response to an IKE_SA_init_request to 401 refuse the SA proposal. This would be conveyed in a Notify payload of 402 the IKE_SA_init_response. 404 The other case in which there is no IKE-SA to protect the information 405 is when a packet is received with an unknown SPI. In that case the 406 notification of this condition will be sent in an informational 407 exchange that is not cryptographically protected. 409 Messages in an Informational Exchange contain zero or more 410 Notification or Delete payloads. The Recipient of an Informational 411 Exchange request MUST send some response (else the Sender will assume 412 the message was lost in the network and will retransmit it). That 413 response can be a message with no payloads. Actually, the request 414 message in an Informational Exchange can also contain no payloads. 415 This is the expected way an endpoint can ask the other endpoint to 416 verify that it is alive. 418 ESP, AH, and IPcomp SAs always exist in pairs, with one SA in each 419 direction. When an SA is closed, both members of the pair MUST be 420 closed. When SAs are nested, as when data is encapsulated first with 421 IPcomp, then with ESP, and finally with AH between the same pair of 422 endpoints, all of the SAs (up to six) must be deleted together. To 423 delete an SA, an Informational Exchange with one or more delete 424 payloads is sent listing the SPIs (as known to the recipient) of the 425 SAs to be deleted. The recipient MUST close the designated SAs. 426 Normally, the reply in the Informational Exchange will contain delete 427 payloads for the paired SAs going in the other direction. There is 428 one exception. If by chance both ends of a set of SAs independently 429 decide to close them, each may send a delete payload and the two 430 requests may cross in the network. If a node receives a delete 431 request for SAs that it has already issued a delete request for, it 432 MUST delete the incoming SAs while processing the request and the 433 outgoing SAs while processing the response. In that case, the 434 responses MUST NOT include delete payloads for the deleted SAs, since 435 that would result in duplicate deletion and could in theory delete 436 the wrong SA. 438 A node SHOULD regard half open connections as anomalous and audit 439 their existence should they persist. Note that this specification 440 nowhere specifies time periods, so it is up to individual endpoints 441 to decide how long to wait. A node MAY refuse to accept incoming data 442 on half open connections but MUST NOT unilaterally close them and 443 reuse the SPIs. If connection state becomes sufficiently messed up, a 444 node MAY close the IKE-SA which will implicitly close all SAs 445 negotiated under it. It can then rebuild the SA's it needs on a clean 446 base under a new IKE-SA. 448 The Informational Exchange is defined as: 450 Initiator Responder 451 ----------- ----------- 452 HDR, SK {N, ..., D, ...} --> 453 <-- HDR, SK {N, ..., D, ...} 455 The processing of an Informational Exchange is determined by its 456 component payloads. 458 4 IKE Protocol Details and Variations 460 IKE runs over UDP port 500. Since UDP is a datagram (unreliable) 461 protocol, IKE includes in its definition recovery from transmission 462 errors, including packet loss, packet replay, and packet forgery. IKE 463 is designed to function so long as at least one of a series of 464 retransmitted packets reaches its destination before timing out and 465 the channel is not so full of forged and replayed packets so as to 466 exhaust the network or CPU capacities of either endpoint. Even in the 467 absence of those minimum performance requirements, IKE is designed to 468 fail cleanly (as though the network were broken). 470 4.1 Use of Retransmission Timers 472 All messages in IKE exist in pairs: a request and a response. The 473 setup of an IKE SA normally consists of two request/response pairs. 474 Once the IKE SA is set up, either end of a security association may 475 initiate requests at any time, and there can be many requests and 476 responses "in flight" at any given moment. But each message is 477 labelled as either a request or a response and for each 478 request/response pair one end of the security association is the 479 Initiator and the other is the Responder. 481 For every pair of messages, the Initiator is responsible for 482 retransmission in the event of a timeout. The Responder will never 483 retransmit a response unless it receives a retransmission of the 484 request. In that event, the Responder MUST either ignore the 485 retransmitted request except insofar as it triggers a retransmission 486 of the response OR if processing the request a second time has no 487 adverse effects, the Responder may choose to process the request 488 again and send a semantically equivalent reply. 490 IKE is a reliable protocol, in the sense that the Initiator MUST 491 retransmit a request until either it receives a corresponding reply 492 OR it deems the IKE security association to have failed and it 493 discards all state associated with the IKE-SA and any Child-SAs 494 negotiated using that IKE-SA. 496 4.2 Use of Sequence Numbers for Message ID 498 Every IKE message contains a Message ID as part of its fixed header. 499 This Message ID is used to match up requests and responses, and to 500 identify retransmissions of messages. 502 The Message ID is a 32 bit quantity, which is zero for the first IKE 503 request in each direction. The IKE SA initial setup messages will 504 always be numbered 0 and 1. Each endpoint in the IKE Security 505 Association maintains two "current" Message IDs: the next one to be 506 used for a request it initiates and the next one it expects to see 507 from the other end. These counters increment as requests are 508 generated and received. Responses always contain the same message ID 509 as the corresponding request. That means that after the initial 510 exchange, each integer n may appear as the message ID in four 511 distinct messages: The nth request from the original IKE Initiator, 512 the corresponding response, the nth request from the original IKE 513 Responder, and the corresponding response. If the two ends make very 514 different numbers of requests, the Message IDs in the two directions 515 can be very different. There is no ambiguity in the messages, 516 however, because each packet contains enough information to determine 517 which of the four messages a particular one is. 519 Note that Message IDs are cryptographically protected and provide 520 protection against message replays. 522 4.3 Window Size for overlapping requests 524 In order to maximize IKE throughput, an IKE endpoint MAY issue 525 multiple requests before getting a response to any of them. For 526 simplicity, an IKE implementation MAY choose to process requests 527 strictly in order and/or wait for a response to one request before 528 issuing another. Certain rules must be followed to assure 529 interoperability between implementations using different strategies. 531 After an IKE-SA is set up, either end can initiate one or more 532 requests. These requests may pass one another over the network. An 533 IKE endpoint MUST be prepared to accept and process a request while 534 it has a request outstanding in order to avoid a deadlock in this 535 situation. An IKE endpoint SHOULD be prepared to accept and process 536 multiple requests while it has a request outstanding. 538 An IKE endpoint MUST wait for a response to each of its messages 539 before sending a subsequent message unless it has received a Notify 540 message from its peer informing it that the peer is prepared to 541 maintain state for multiple outstanding messages in order to allow 542 greater throughput. 544 An IKE endpoint MUST NOT exceed the peer's stated window size (see 545 section 5.3.2) for transmitted IKE requests. In other words, if Bob 546 stated his window size is N, then when Alice needs to make a request 547 X, she MUST wait until she has received responses to all requests up 548 through request X-N. An IKE endpoint MUST keep a copy of (or be able 549 to regenerate exactly) each request it has sent until it receives the 550 corresponding response. An IKE endpoint MUST keep a copy of (or be 551 able to regenerate with semantic equivalence) the number of previous 552 responses equal to its contracted window size in case its response 553 was lost and the Initiator requests its retransmission by 554 retransmitting the request. 556 An IKE endpoint SHOULD be capable of processing incoming requests out 557 of order to maximize performance in the event of network failures or 558 packet reordering. 560 4.4 State Synchronization and Connection Timeouts 562 An IKE endpoint is allowed to forget all of its state associated with 563 an IKE-SA and the collection of corresponding child-SAs at any time. 564 This is the anticipated behavior in the event of an endpoint crash 565 and restart. It is important when an endpoint either fails or 566 reinitializes its state that the other endpoint detect those 567 conditions and not continue to waste network bandwidth by sending 568 packets over those SAs and having them fall into a black hole. 570 Since IKE is designed to operate in spite of Denial of Service (DoS) 571 attacks from the network, an endpoint MUST NOT conclude that the 572 other endpoint has failed based on any routing information (e.g. ICMP 573 messages) or IKE messages that arrive without cryptographic 574 protection (e.g., notify messages complaining about unknown SPIs). An 575 endpoint MUST conclude that the other endpoint has failed only when 576 repeated attempts to contact it have gone unanswered for a timeout 577 period. An endpoint SHOULD suspect that the other endpoint has failed 578 based on routing information and initiate a request to see whether 579 the other endpoint is alive. To check whether the other side is 580 alive, IKE specifies an empty Informational message that (like all 581 IKE requests) requires an acknowledgment. If a cryptographically 582 protected message has been received from the other side recently, 583 unprotected notifications MAY be ignored. Implementations MUST limit 584 the rate at which they take actions based on unprotected messages. 586 Numbers of retries and lengths of timeouts are not covered in this 587 specification because they do not affect interoperability. It is 588 suggested that messages be retransmitted at least a dozen times over 589 a period of at least several minutes before giving up on an SA, but 590 different environments may require different rules. If there is 591 outgoing traffic on an SA, it is essential to confirm liveness of 592 that SA to avoid black holes. If no cryptographically protected 593 messages have been received on an IKE-SA or any of its child-SAs 594 recently, a liveness check MUST be performed. Receipt of a fresh 595 cryptographically protected message on an IKE-SA or any of its 596 child-SAs assures liveness of the IKE-SA and all of its child-SAs. 598 There is a Denial of Service attack on the Initiator of an IKE-SA 599 that can be avoided if the Initiator takes the proper care. Since the 600 first two messages of an SA setup are not cryptographically 601 protected, an attacker could respond to the Initiator's message 602 before the genuine Responder and poison the connection setup attempt. 603 To prevent this, the Initiator SHOULD be willing to accept multiple 604 responses to its first message, treat each as potentially legitimate, 605 respond to it, and then discard all the invalid half open connections 606 when she receives a valid cryptographically protected response to any 607 one of her requests. Once a cryptographically valid response is 608 received, all subsequent responses should be ignorred whether or not 609 they are cryptographically valid. 611 Note that with these rules, there is no reason to negotiate and agree 612 upon an SA lifetime. If IKE presumes the partner is dead, based on 613 repeated lack of acknowledgment to an IKE message, then the IKE SA 614 and all child-SAs set up through that IKE-SA are deleted. 616 An IKE endpoint MAY delete inactive Child-SAs to recover resources 617 used to hold their state. If an IKE endpoint chooses to do so, it 618 MUST send Delete payloads to the other end notifying it of the 619 deletion. It MAY similarly time out the IKE-SA. Closing the IKE-SA 620 implicitly closes all associated Child-SAs. An IKE endpoint SHOULD 621 send a Delete payload indicating that it has closed the IKE-SA. 623 4.5 Version Numbers and Forward Compatibility 625 This document describes version 2.0 of IKE, meaning the major version 626 number is 2 and the minor version number is zero. It is likely that 627 some implementations will want to support both version 1.0 and 628 version 2.0, and in the future, other versions. 630 The major version number should only be incremented if the packet 631 formats or required actions have changed so dramatically that an 632 older version node would not be able to interoperate with a newer 633 version node if it simply ignored the fields it did not understand 634 and took the actions specified in the older specification. The minor 635 version number indicates new capabilities, and MUST be ignored by a 636 node with a smaller minor version number, but used for informational 637 purposes by the node with the larger minor version number. For 638 example, it might indicate the ability to process a newly defined 639 notification message. The node with the larger minor version number 640 would simply note that its correspondent would not be able to 641 understand that message and therefore would not send it. 643 If you receive a message with a higher major version number, you MUST 644 drop the message and SHOULD send an unauthenticated notification 645 message containing the highest version number you support. If you 646 support major version n, and major version m, you MUST support all 647 versions between n and m. If you receive a message with a major 648 version that you support, you MUST respond with that version number. 649 In order to prevent two nodes from being tricked into corresponding 650 with a lower major version number than the maximum that they both 651 support, IKE has a flag that indicates that the node is capable of 652 speaking a higher major version number. 654 Thus the major version number in the IKE header indicates the version 655 number of the message, not the highest version number that the 656 transmitter supports. If A is capable of speaking versions n, n+1, 657 and n+2, and B is capable of speaking versions n and n+1, then they 658 will negotiate speaking n+1, where A will set the flag indicating 659 ability to speak a higher version. If they mistakenly (perhaps 660 through an active attacker sending error messages) negotiate to 661 version n, then both will notice that the other side can support a 662 higher version number, and they MUST break the connection and 663 reconnect using version n+1. 665 Note that IKEv1 does not follow these rules, because there is no way 666 in v1 of noting that you are capable of speaking a higher version 667 number. So an active attacker can trick two v2-capable nodes into 668 speaking v1. When a v2-capable node negotiates down to v1, it SHOULD 669 note that fact in its logs. 671 Also for forward compatibility, all fields marked RESERVED MUST be 672 set to zero by a version 2.0 implementation and their content MUST be 673 ignored by a version 2.0 implementation ("Be conservative in what you 674 send and liberal in what you receive"). In this way, future versions 675 of the protocol can use those fields in a way that is guaranteed to 676 be ignored by implementations that do not understand them. 677 Similarly, payload types that are not defined are reserved for future 678 use and implementations of version 2.0 MUST skip over those payloads 679 and ignore their contents. 681 IKEv2 adds a "critical" flag to each payload header for further 682 flexibility for forward compatibility. If the critical flag is set 683 and the payload type is unsupported, the message MUST be rejected and 684 the response to the IKE request containing that payload MUST include 685 a notify payload UNSUPPORTED-CRITICAL-PAYLOAD, indicating an 686 unsupported critical payload was included. If the critical flag is 687 not set and the payload type is unsupported, that payload is simply 688 skipped. While new payload types may be added in the future and may 689 appear interleaved with the fields defined in this specification, 690 implementations MUST send the payloads defined in this specification 691 in the stated order and implementations SHOULD reject as invalid a 692 message with payloads in an unexpected order. 694 4.6 Cookies 696 The term "cookies" originates with Karn and Simpson [RFC 2522] in 697 Photuris, an early proposal for key management with IPsec. It has 698 persisted because the IETF has never rejected a proposal involving 699 cookies. The ISAKMP fixed message header includes two eight octet 700 fields titled "cookies", and that syntax is used by both IKEv1 and 701 IKEv2. Those eight octet fields are used as an SPI or connection 702 identifier at the beginning of IKE packets. They were also intended 703 to be used as Karn/Simpson "anti-clogging" tokens in IKEv1, but 704 certain aspects of that design prevented them from being used as 705 such. IKEv2 was carefully constructed to allow an implementation to 706 implement these anti-clogging tokens, either using the fields titled 707 "cookies" or by creative choices of nonces. 709 While IKE implementations SHOULD implement anti-clogging tokens to 710 protect themselves from denial of service attacks, the algorithms and 711 syntax they use in cookies and/or nonces does not affect 712 interoperability and hence is not specified here. The following 713 should be interpreted as an explanation of why the protocol has the 714 fields it does and as an example of how an implementation could 715 implementing anti-clogging tokens. 717 In IKEv2, the cookies are used as IKE-SA identifiers in the headers 718 of IKE messages. As with ESP and AH, in IKEv2 the recipient of a 719 message chooses an IKE-SA identifier that uniquely defines that SA to 720 that recipient. For this purpose (IKE-SA identifiers), it might be 721 convenient for the cookie value to be chosen so as to be a table 722 index for fast lookups of SAs. But this conflicts with the second use 723 of the cookies. 725 Unlike ESP and AH where only the recipient's SA identifier appears in 726 the message, in IKE the sender's IKE SA identifier is also sent in 727 every message. In IKEv1 the IKE-SA identifier consisted of the pair 728 (Initiator cookie, Responder cookie), whereas in IKEv2, the SA is 729 uniquely defined by the recipient's SA identifier even though both 730 are included in the IKEv2 header. 732 An expected attack against IKE is state and CPU exhaustion, where the 733 target is flooded with session initiation requests from forged IP 734 addresses. This attack can be made less effective if an 735 implementation of a responder uses minimal CPU and commits no state 736 to a connection until it has received the third message of the 737 protocol. That third message repeats information from the second 738 message, and hence proves that the initiator can receive packets at 739 the address it claims to be sending from. 741 Since all of the information from message 1 is repeated in message 3, 742 the responder need not store any of that information. What the 743 responder must be able to do is: (1) assure itself that the Nr 744 returned in message 3 is fresh and (2) assure that message 3 came 745 from the same IP address as message 1. If the responder uses multiple 746 KEr's during the period of message 1 & 3, it must encode in message 2 747 some way to figure out which KEr applies to this exchange. 749 A good way to do this is to set the IKE-SA identifier to be: 751 SPIr = Hash(KEr | Nr | IPi | ) 753 where is a randomly generated secret known only to the 754 responder and periodically changed. This value can be recomputed when 755 message 3 arrives and compared to the SPIr in message 3. If it 756 matches, the responder knows that Nr was generated since the last 757 change to and that IPi must be the same as the source 758 address it saw in message 1. 760 To prevent replays of message 3 without remembering all the Nr's that 761 were used, the responder must keep a list of all of the Nr's that 762 have been returned in a message 3 since was last changed. 763 If this list becomes long enough to be cumbersome, the responder can 764 change and forget all of the used values. 766 If a new value for is chosen while there are connections in 767 the process of being initialized, a message 3 might be returned where 768 the responder does not know which of its values for were 769 used in generating message 2. Using the formula above, the responder 770 could compute SPIr with each candidate and accept message 3 771 if any of the values match. A similar situation occurs if the 772 responder uses multiple values of KEr. An alternative implementation 773 would be to take a few bits of SPIr as indices of s and KEr's 774 (where the rest of SPIr is computed as the above hash). 776 If the responder wants to keep other forms of state without tying up 777 its memory, it can encode that state in the nonce. The nonce can be 778 up to 256 octets long, and the protocol is secure so long as values 779 are not reused, so the responder can put state there (possibly 780 encrypted) and be guaranteed that it will come back with message 3. 781 For subtle cryptographic reasons, the nonce SHOULD contain some 782 random bits - at least as many random bits as the size of the 783 strongest key be generated by the exchange. 785 It may be convenient for the IKE-SA identifier to be an index into a 786 table. It is not difficult for the Initiator to choose an IKE-SA 787 identifier that is convenient as a table identifier, since the 788 Initiator does not need to use it as an anti-clogging token, and is 789 keeping state. IKEv2 allows the Responder to initially choose a 790 stateless anti-clogging type cookie by responding to an IKE_SA_init 791 with a cookie request, and then upon receipt of an IKE_SA_init with a 792 valid cookie, change his cookie value from the computed anti-clogging 793 token to a more convenient value, by sending a different value for 794 his cookie in the IKE_SA_auth_response. This will not confuse the 795 Initiator (Alice), because she will have chosen a unique cookie value 796 A, so if her SA state for the partially set up IKE-SA says that Bob's 797 cookie for the SA that Alice knows as "A" is B, and she receives a 798 response from Bob with cookies (A,C), that means that Bob wants to 799 change his value from B to C for the SA that Alice knows uniquely as 800 "A". 802 Another reason why Bob might want to change his cookie value is that 803 it is possible (though unlikely) that Bob will choose the same cookie 804 for multiple SAs if the hash of the Initiator IP address, Nr, and 805 whatever other information might be included happens to hash to the 806 same value. 808 In IKEv2, like IKEv1, both 8-octet cookies appear in the message, but 809 in IKEv2 (unlike v1), the value chosen by the message recipient 810 always appears first in the message. 812 The cookies are one of the inputs into the function that computes the 813 keying material. If the responder changes its cookie to a different 814 value when it sends its IKE_AUTH_response, it is the cookie value in 815 the IKE_SA_init_response that is the input for generating the keying 816 material. 818 4.7 Cryptographic Algorithm Negotiation 820 The payload type known as "SA" indicates a proposal for a set of 821 choices of protocols (IKE, ESP, AH, and/or IPcomp) for the SA as well 822 as cryptographic algorithms associated with each protocol. In IKEv1 823 it was extremely complex, and was one of the motivations for revising 824 the spec. 826 An SA consists of one or more proposals. Each proposal includes a 827 Suite-ID, which implies one or more protocols and the associated 828 cryptographic algorithms. 830 In IKEv2, since the Initiator sends her Diffie-Hellman value in the 831 IKE_SA_init, she must guess at the Diffie-Hellman group that Bob will 832 select from her list of supported groups. Her guess MUST be the first 833 in the list to allow Bob to unambiguously identify which group the 834 accompanying KE payload is from. If her guess is incorrect then Bob's 835 response informs her of the group he chose, and includes his KE from 836 his chosen group. In this case, Alice MUST choose a KE from Bob's 837 chosen group, compute keys based on her and Bob's values and send the 838 new KE in message 3. 840 You might wonder why Alice includes KE in the first message given 841 that Bob doesn't need it until message 3 and it could change in 842 message 3. The reason is to allow an optional optimization in Bob. 843 Bob MAY start his Diffie-Hellman computation as soon as he receives 844 message 1 and likely complete it by the time he receives message 3. 845 This will minimize latency of connection setup in the common case 846 where Alice correctly guesses the Diffie-Hellman group that Bob will 847 choose. If Bob accepts Alice's first choice of Diffie-Hellman group, 848 Alice MUST send the same value for KE in message 3 as she sent in 849 message 1. 851 Note that an implementation cannot simultaneously exploit this 852 optimization and protect itself from a denial of service attack using 853 cookies. But an implementation could alternate between the two based 854 on load. 856 If none of Alice's options are acceptable, then Bob notifies her 857 accordingly. 859 4.8 Rekeying 861 Security associations negotiated in both phase 1 and phase 2 contain 862 secret keys which may only be used for a limited amount of time and 863 to protect a limited amount of data. This determines the lifetime of 864 the entire security association. When the lifetime of a security 865 association expires the security association MUST NOT be used. If 866 there is demand, new security associations can be established. 867 Reestablishment of security associations to take the place of ones 868 which expire is referred to as "rekeying". 870 To rekey a child-SA, create a new, equivalent SA (see section 4.17 871 below), and when the new one is established, delete the old one. To 872 rekey an IKE-SA, establish a new equivalent IKE-SA (see section 4.18 873 below) with the peer to whom the old IKE-SA is shared using a Phase 2 874 negotiation within the existing IKE-SA. An IKE-SA so created inherits 875 all of the original IKE-SA's child SAs. Use the new IKE-SA for all 876 control messages needed to maintain the child-SAs created by the old 877 IKE-SA, and delete the old IKE-SA. The Delete payload to delete 878 itself MUST be the last request sent over an IKE-SA. 880 SAs SHOULD be rekeyed proactively, i.e., the new SA should be 881 established before the old one expires and becomes unusable. Enough 882 time should elapse between the time the new SA is established and the 883 old one becomes unusable so that traffic can be switched over to the 884 new SA. 886 A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes 887 were negotiated. In IKEv2, each end of the SA is responsible for 888 enforcing its own lifetime policy on the SA and rekeying the SA when 889 necessary. If the two ends have different lifetime policies, the end 890 with the shorter lifetime will end up always being the one to request 891 the rekeying. 893 If the two ends have the same lifetime policies, it is possible that 894 both will initiate a rekeying at the same time (which will result in 895 redundant SAs). To reduce the probability of this happening, the 896 timing of rekeying requests should be jittered (delayed by a random 897 amount of time). 899 This form of rekeying will temporarily result in multiple similar SAs 900 between the same pairs of nodes. When there are two SAs eligible to 901 receive packets, a node MUST accept incoming packets through either 902 SA. The node that initiated the rekeying SHOULD delete the older SA 903 after the new one is established. 905 4.9 Traffic Selector Negotiation 907 When an IP packet is received by an RFC2401 compliant IPsec subsystem 908 and matches a "protect" selector in its SPD, the subsystem MUST 909 protect that packet with IPsec. When no SA exists yet it is the task 910 of IKE to create it. Information about the traffic that needs 911 protection is transmitted to the IKE subsystem in a manner outside 912 the scope of this document (see [PFKEY] for an example). This 913 information is negotiated between the two IKE endpoints using TS 914 (Traffic Selector) payloads. 916 Two TS payloads appear in each of the messages in the exchange that 917 creates a child-SA pair. Each TS payload contains one or more Traffic 918 Selectors. Each Traffic Selector consists of an address range (IPv4 919 or IPv6), a port range, and a protocol ID. 921 IKEv2 is more flexible than IKEv1. IKEv2 allows sets of ranges of 922 both addresses and ports, and allows the responder to choose a subset 923 of the requested traffic rather than simply responding "not 924 acceptable". This could happen when the configuration of the two 925 endpoints are being updated but only one end has received the new 926 information. Since the two endpoints may be configured by different 927 people, the incompatibility may persist for an extended period even 928 in the absense of errors. It allows for intentionally different 929 configurations, as when one end is configured to tunnel all addresses 930 and depends on the other end to have the up to date list. 932 The first of the two TS payloads is known as TSi (Traffic Selector- 933 initiator). The second is known as TSr (Traffic Selector-responder). 934 TSi specifies the source address of traffic forwarded from (or the 935 destination address of traffic forwarded to) the initiator of the 936 child-SA pair. TSr specifies the destination address of the traffic 937 forwarded from (or the source address of the traffic forwarded to) 938 the responder of the child-SA pair. For example, if Alice initiates 939 the creation of the child-SA pair from Alice to Bob, and wishes to 940 tunnel all traffic from subnet 10.2.16.* on Alice's side to subnet 941 18.16.*.* on Bob's side, Alice would include a single traffic 942 selector in each TS payload. TSi would specify the address range 943 (10.2.16.0 - 10.2.16.255) and TSr would specify the address range 944 (18.16.0.0 - 18.16.255.255). Assuming that proposal was acceptable to 945 Bob, he would send identical TS payloads back. 947 The Responder is allowed to narrow the choices by selecting a subset 948 of the traffic, for instance by eliminating or narrowing the range of 949 one or more members of the set of traffic selectors, provided the set 950 does not become the NULL set. 952 It is possible for the Responder's policy to contain multiple smaller 953 ranges, all encompassed by the Initiator's traffic selector, and with 954 the Responder's policy being that each of those ranges should be sent 955 over a different SA. Continuing the example above, Bob might have a 956 policy of being willing to tunnel those addresses to and from Alice, 957 but might require that each address pair be on a separately 958 negotiated child-SA. If Alice generated her request in response to an 959 incoming packet from 10.2.16.43 to 18.16.2.123, there would be no way 960 for Bob to determine which pair of addresses it is most urgent to 961 tunnel, and he would have to make his best guess or reject the 962 request with a status of SINGLE-PAIR-REQUIRED. 964 To enable Bob to choose the appropriate range in this case, if Alice 965 has initiated the SA due to a data packet, Alice MAY include as the 966 first traffic selector in each of TSi and TSr a very specific traffic 967 selector including the addresses in the packet triggering the 968 request. In the example, Alice would include in TSi two traffic 969 selectors: the first containing the address range (10.2.16.43 - 970 10.2.16.43) and the source port and protocol from the packet and the 971 second containing (10.2.16.0 - 10.2.16.255) with all ports and 972 protocols. She would similarly include two traffic selectors in TSr. 974 If Bob's policy does not allow him to accept the entire set of 975 traffic selectors in Alice's request, but does allow him to accept 976 the first selector of TSi and TSr, then Bob MUST narrow the traffic 977 selectors to a subset that includes Alice's first choices. In this 978 example, Bob might respond with TSi being (10.2.16.43 - 10.2.16.43) 979 with all ports and protocols. 981 If Alice creates the child-SA pair not in response to an arriving 982 packet, but rather - say - upon startup, then there may be no 983 specific data packet to describe. In that case, the first values in 984 TSi and TSr are ranges rather than specific values, and Bob chooses a 985 subset of Alice's TSi and TSr that are acceptable to him. If more 986 than one subset is acceptable but their union is not, Bob MUST accept 987 some subset and MAY include a NOTIFY payload of type ADDITIONAL-TS- 988 POSSIBLE to indicate that Alice might want to try again. 990 4.10 Nonces 992 The IKE_SA_init and the IKE_SA_init_response each contain a nonce. 993 These nonces are used as inputs to cryptographic functions. The 994 CREATE_CHILD_SA request and the CREATE_CHILD_SA response also contain 995 nonces. These nonces are used to add freshness to the key derivation 996 technique used to obtain keys for child SAs. Nonces used in IKEv2 997 MUST therefore be unique (either deterministically by use of 998 timestamps and sequence numbers or probabilistically by use of a 999 strong pseudo-random number generator). 1001 4.11 Address and Port Agility 1003 IKE runs over UDP port 500, and implicitly sets up ESP, AH, and 1004 IPcomp associations for the same IP addresses it runs over. The IP 1005 addresses and ports in the outer header are, however, not themselves 1006 cryptographically protected, and IKE is designed to work even through 1007 Network Address Translation (NAT) boxes. An implementation MUST 1008 accept incoming connection requests even if not received from UDP 1009 port 500, and should respond to the address and port from which the 1010 request was received. An implementation MUST, however, accept 1011 incoming requests only on UDP port 500 and send all responses from 1012 UDP port 500. IKE functions identically over IPv4 or IPv6. 1014 4.12 Reuse of Diffie-Hellman Exponentials 1016 IKE generates keying material using an ephemeral Diffie-Hellman 1017 exchange in order to gain the property of "perfect forward secrecy". 1018 This means that once a connection is closed and its corresponding 1019 keys are forgotten, even someone who has recorded all of the data 1020 from the connection and gets access to all of the long term keys of 1021 the two endpoints cannot reconstruct the keys used to protect the 1022 conversation. 1024 Achieving perfect forward secrecy requires that when a connection is 1025 closed, each endpoint must forget not only the keys used by the 1026 connection but any information that could be used to recompute those 1027 keys. In particular, it must forget the secrets used in the Diffie- 1028 Hellman calculation and any state that may persist in the state of a 1029 pseudo-random number generater that could be used to recompute the 1030 Diffie-Hellman secrets. 1032 Since the computing of Diffie-Hellman exponentials is computationally 1033 expensive, an endpoint may find it advantageous to reuse those 1034 exponentials for multiple connection setups. There are several 1035 reasonable strategies for doing this. An endpoint could choose a new 1036 exponential periodically though this could result in less-than- 1037 perfect forward secrecy if some connection lasts for less than the 1038 lifetime of the exponential. Or it could keep track of which 1039 exponential was used for each connection and delete the information 1040 associated with the exponential only when some corresponding 1041 connection was closed. This would allow the exponential to be reused 1042 without losing perfect forward secrecy at the cost of maintaining 1043 more state. 1045 Decisions as to whether and when to reuse Diffie-Hellman exponentials 1046 is a private decision in the sense that it will not affect 1047 interoperability. An implementation that reuses exponentials may 1048 choose to remember the exponential used by the other endpoint on past 1049 exchanges and if one is reused to avoid the second half of the 1050 calculation. 1052 4.13 Generating Keying Material 1053 In the context of the IKE SA, three cryptographic algorithms are 1054 negotiated: an encryption algorithm, a Diffie-Hellman group, and a 1055 pseudo-random function (prf). The pseudo-random function is used both 1056 for integrity protection of the IKE payloads and for the construction 1057 of keying material for all of the cryptographic algorithms used in 1058 both the IKE SA and the Child-SAs. 1060 We assume that each cryptographic algorithm accepts a fixed size key, 1061 and that any randomly chosen value of that fixed size can serve as an 1062 appropriate key. For functions that accept a variable length key, a 1063 fixed key size MUST be specified as part of the cryptographic suite 1064 negotiated. For prf functions based on HMAC, the fixed key size is 1065 the size of the output of the HMAC. 1067 Keying material will always be derived as the output of the 1068 negotiated prf algorithm. If the amount of keying material is greater 1069 than the size of the output of the prf algorithm, we will use the prf 1070 iteratively. We will use the terminology prf+ to describe the 1071 function that outputs a pseudo-random stream based on the inputs to a 1072 prf as follows: 1074 prf+ (K,S) = T1 | T2 | T3 | T4 | ... 1076 where: 1077 T1 = prf (K, S | 0x01) 1078 T2 = prf (K, T1 | S | 0x02) 1079 T3 = prf (K, T2 | S | 0x03) 1080 T4 = prf (K, T3 | S | 0x04) 1082 as needed to compute all required keys. The keys are taken from the 1083 output string without regard to boundaries (e.g. if the required keys 1084 are a 256 bit AES key and a 160 bit HMAC key, and the prf function 1085 generates 160 bits, the AES key will come from T1 and the beginning 1086 of T2, while the HMAC key will come from the rest of T2 and the 1087 beginning of T3). 1089 The constant concatenated to the end of each string feeding the prf 1090 is a single octet. prf+ in this document is not defined beyond 255 1091 times the size of the prf output. 1093 4.14 Generating Keying Material for the IKE-SA 1095 The shared keys are computed as follows. A quantity called SKEYSEED 1096 is calculated from the nonces exchanged during the IKE_SA_init 1097 exchange and the Diffie-Hellman shared secret established during that 1098 exchange. SKEYSEED is used to calculate three other secrets: SK_d 1099 used for deriving new keys for the child-SAs established with this 1100 IKE-SA; SK_a used as a key to the prf algorithm for authenticating 1101 the component messages of subsequent exchanges; and SK_e used for 1102 encrypting (and of course decrypting) all subsequent exchanges. 1103 SKEYSEED and its derivatives are computed as follows: 1105 SKEYSEED = prf(Ni | Nr, g^ir) 1106 {SK_d, SK_ai, SK_ar, SK_ei, SK_er} 1107 = prf+ (SKEYSEED, Ni | Nr | CKY-I | CKY-R) 1109 g^ir is the shared secret from the ephemeral Diffie-Hellman exchange. 1110 Ni and Nr are the nonces, stripped of any headers. 1112 The two directions of flow use different keys. The keys used to 1113 protect messages from the original initiator are SK_ai and SK_ei. The 1114 keys used to protect messages in the other direction are SK_ar and 1115 SK_er. Each algorithm takes a fixed number of bits of keying 1116 material, which is specified as part of the algorithm. For integrity 1117 algorithms based on HMAC, the key size is always equal to the length 1118 of the underlying hash function. 1120 4.15 Authentication of the IKE-SA 1122 The peers are authenticated by having each sign (or MAC using a 1123 shared secret as the key) a block of data. For the responder, the 1124 octets to be signed start with the first octet of the header of the 1125 second message and end with the last octet of the last payload in the 1126 second message. Appended to this (for purposes of computing the 1127 signature) is the initiator's nonce Ni (just the value, not the 1128 payload containing it). The initiator signs the unencrypted part of 1129 message 3, starting with the first octet of the IKE header and ending 1130 with the last octet of the last unencrypted payload. Note that 1131 message 3 includes Nr, so it does not need to be appended in order to 1132 be included under the signature. It is critical to the security of 1133 the exchange that each side sign the other side's nonce. 1135 Note that all of the payloads are included under the signature, 1136 including any payload types not defined in this document. 1138 Optionally, messages 3 and 4 MAY include a certificate, or 1139 certificate chain providing evidence that the key used to compute a 1140 digital signature belongs to the name in the ID payload. The 1141 signature or MAC will be computed using algorithms dictated by the 1142 type of key used by the signer, an RSA-signed PKCS1-padded-hash for 1143 an RSA digital signature, a DSS-signed SHA1-hash for a DSA digital 1144 signature, or the negotiated PRF function for a pre-shared key. 1145 There is no requirement that the Initiator and Responder sign with 1146 the same cryptographic algorithms. The choice of cryptographic 1147 algorithms depends on the type of key each has. This type is either 1148 indicated in the certificate supplied or, if the keys were exchanged 1149 out of band, the key types must have been similarly learned. It will 1150 commonly be the case (but it is not required) that if a shared secret 1151 is used for authentication that the same key is used in both 1152 directions. In particular, the initiator may be using a shared key 1153 while the responder may have a public signature key and certificate. 1154 Note that it is a common but insecure practice to have a shared key 1155 derived from a user chosen password. This is insecure because user 1156 chosen passwords are unlikely to have sufficient randomness to resist 1157 dictionary attacks. The pre-shared key SHOULD contain as much 1158 randomness as the strongest key being negotiated. In the case of a 1159 pre-shared key, the AUTH value is computed as: 1161 AUTH = prf(Shared Secret | "Key Pad for IKEv2", ) 1162 where the string "Key Pad for IKEv2" is ASCII encoded and not null 1163 terminated. The shared secret can be variable length. The pad string 1164 is added so that if the shared secret is derived from a password, 1165 this exchange will not compromise use of the same password in other 1166 protocols. 1168 Note that the requirement that the responder sign the content of 1169 message 2 in message 4 introduces some special challenges when the 1170 responder is not maintaining state between messages 2 and 4 (see 1171 Section 4.6). Either the responder must be able to regenerate message 1172 2 octet for octet from the information in message 3, or it must 1173 encode in its nonce enough information to be able to construct the 1174 signature on message 2 after message 3 is returned. 1176 4.16 Generating Keying Material for CHILD-SAs 1178 Child-SAs are created either by being piggybacked on the phase 1 1179 exchange, or in a phase 2 CREATE_CHILD_SA exchange. Keying material 1180 for them is generated as follows: 1182 KEYMAT = prf+(SK_d, Ni | Nr) 1184 Where Ni and Nr are the Nonces from the IKE_init exchange if this 1185 request is the first CHILD-SA created or the fresh Ni and Nr from the 1186 CREATE_CHILD_SA exchange if this is a subsequent creation. 1188 For phase 2 exchanges with PFS the keying material is defined as: 1190 KEYMAT = prf+(SK_d, g^ir (ph2) | Ni | Nr ) 1192 where g^ir (ph2) is the shared secret from the ephemeral Diffie- 1193 Hellman exchange of this phase 2 exchange, 1195 A single child-SA negotiation may result in multiple security 1196 associations. ESP, AH, and IPcomp SAs exist in pairs (one in each 1197 direction), and six SAs could be created in a single child-SA 1198 negotiation if a combination of ESP, AH, and IPcomp is being 1199 negotiated. KEYMAT is generated as described in section 4.13. 1201 Keying material is taken from the expanded KEYMAT in the following 1202 order: 1204 All keys for SAs carrying data from the initiator to the responder 1205 are taken before SAs going in the reverse direction. 1207 If multiple protocols are negotiated, keying material is taken in 1208 the order in which the protocol headers will appear in the 1209 encapsulated packet. 1211 If a single protocol has both encryption and authentication keys, 1212 the encryption key is taken from the first octets of KEYMAT and 1213 the authentication key is taken from the next octets. 1215 Each cryptographic algorithm takes a fixed number of bits of keying 1216 material specified as part of the algorithm. 1218 4.17 Rekeying IKE-SAs using a CREATE_CHILD_SA exchange 1220 The CREATE_CHILD_SA exchange can be used to re-key an existing IKE-SA 1221 (see section 4.8). New Initiator and Responder cookies are supplied 1222 in the SPI fields. The TS payloads are omitted when rekeying an IKE- 1223 SA. SKEYSEED for the new IKE-SA is computed using SK_d from the 1224 existing IKE-SA as follows: 1226 SKEYSEED = prf(SK_d (old), [g^ir (ph2)] | Ni | Nr) 1228 where g^ir (ph2) is the shared secret from the ephemeral Diffie- 1229 Hellman exchange of this phase 2 exchange and Ni and Nr are the two 1230 nonces stripped of any headers. 1232 The new IKE SA MUST reset its message counters to 0. 1234 SK_d, SK_ai, SK_ar, and SK_ei, and SK_er are computed from SKEYSEED 1235 as specified in section 4.14. 1237 4.18 Error Handling 1239 There are many kinds of errors that can occur during IKE processing. 1240 If a request is received that is badly formatted or unacceptable for 1241 reasons of policy (e.g. no matching cryptographic algorithms), the 1242 response MUST contain a Notify payload indicating the error. If an 1243 error occurs outside the context of an IKE request (e.g. the node is 1244 getting ESP messages on a non-existent SPI), the node SHOULD initiate 1245 an Informational Exchange with a Notify payload describing the 1246 problem. 1248 Errors that occur before a cryptographically protected IKE-SA is 1249 established must be handled very carefully. There is a trade-off 1250 between wanting to be helpful in diagnosing a problem and responding 1251 to it and wanting to avoid being a dupe in a denial of service attack 1252 based on forged messages. 1254 If a node receives a message on UDP port 500 outside the context of 1255 an IKE-SA (and not a request to start one), it may be the result of a 1256 recent crash. If the message is marked as a response, the node MAY 1257 audit the suspicious event but MUST NOT respond. If the message is 1258 marked as a request, the node MAY audit the suspicious event and MAY 1259 send a response. If a response is sent, the response MUST be sent to 1260 the IP address and port from whence it came with the IKE cookies 1261 reversed in the header and the Message ID copied. The response MUST 1262 NOT be cryptographically protected and MUST contain a notify payload 1263 indicating INVALID-COOKIE. 1265 A node receiving such a message MUST NOT respond and MUST NOT change 1266 the state of any existing SAs. The message might be a forgery or 1267 might be a response the genuine correspondent was tricked into 1268 sending. A node SHOULD treat such a message (and also a network 1269 message like ICMP destination unreachable) as a hint that there might 1270 be problems with SAs to that IP address and SHOULD initiate a 1271 liveness test for any such IKE-SA. An implementation SHOULD limit the 1272 frequency of such tests to avoid being tricked into participating in 1273 a denial of service attack. 1275 A node receiving a suspicious message from an IP address with which 1276 it has an IKE-SA MAY send an IKE notify payload in an IKE 1277 Informational exchange over that SA. The recipient MUST NOT change 1278 the state of any SA's as a result but SHOULD audit the event to aid 1279 in diagnosing malfunctions. A node MUST limit the rate at which it 1280 will send messages in response to unprotected messages. 1282 5 Header and Payload Formats 1284 5.1 The IKE Header 1286 IKE messages use UDP port 500, with one IKE message per UDP datagram. 1287 Information from the UDP header is largely ignored except that the IP 1288 addresses and UDP ports from the headers are reversed and used for 1289 return packets. Each IKE message begins with the IKE header, denoted 1290 HDR in this memo. Following the header are one or more IKE payloads 1291 each identified by a "Next Payload" field in the preceding payload. 1292 Payloads are processed in the order in which they appear in an IKE 1293 message by invoking the appropriate processing routine according to 1294 the "Next Payload" field in the IKE header and subsequently according 1295 to the "Next Payload" field in the IKE payload itself until a "Next 1296 Payload" field of zero indicates that no payloads follow. If a 1297 payload of type "Encrypted" is found, that payload is decrypted and 1298 its contents parsed as additional payloads. An Encrypted payload must 1299 be the last payload in a packet and an encrypted payload may not 1300 contain another encrypted payload. 1302 The Recipient SPI in the header identifies an instance of an IKE 1303 security association. It is therefore possible for a single instance 1304 of IKE to multiplex distinct sessions with multiple peers. 1306 The format of the IKE header is shown in Figure 1. 1307 1 2 3 1308 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 1309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1310 ! Recipient ! 1311 ! SPI (aka Cookie) ! 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 ! Sender ! 1314 ! SPI (aka Cookie) ! 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 ! Message ID ! 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1320 ! Length ! 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1323 Figure 1: IKE Header Format 1325 o Recipient SPI (aka Cookie) (8 octets) - A value chosen by the 1326 recipient to identify a unique IKE security association. For 1327 the first packet of an IKE_SA_init, this value MUST be zero. 1328 It MUST NOT be zero for any other packet. 1329 [NOTE: this is a deviation from ISAKMP and IKEv1, where the 1330 cookies were always sent with the Initiator of the IKE-SA's 1331 cookie first and the Responder's second. See section 3.6.] 1333 o Sender SPI (aka Cookie) (8 octets) - A value chosen by the 1334 sender to identify a unique IKE security association. This 1335 value MUST NOT be zero. 1337 o Next Payload (1 octet) - Indicates the type of payload that 1338 immediately follows the header. The format and value of each 1339 payload is defined below. 1341 o Major Version (4 bits) - indicates the major version of the IKE 1342 protocol in use. Implementations based on this version of IKE 1343 MUST set the Major Version to 2. Implementations based on 1344 previous versions of IKE and ISAKMP MUST set the Major Version 1345 to 1. Implementations based on this version of IKE MUST reject 1346 (or ignore) messages containing a version number greater than 1347 2. 1349 o Minor Version (4 bits) - indicates the minor version of the 1350 IKE protocol in use. Implementations based on this version of 1351 IKE MUST set the Minor Version to 0. They MUST ignore the minor 1352 version number of received messages. 1354 o Exchange Type (1 octet) - indicates the type of exchange being 1355 used. This dictates the payloads sent in each message and 1356 message orderings in the exchanges. 1358 Exchange Type Value 1360 RESERVED 0 1361 Reserved for ISAKMP 1 - 31 1362 Reserved for IKEv1 32 - 33 1363 IKE_SA_init 34 1364 IKE_SA_AUTH 35 1365 CREATE_CHILD_SA 36 1366 Informational 37 1367 Reserved for IKEv2+ 38-239 1368 Reserved for private use 240-255 1370 o Flags (1 octet) - indicates specific options that are set 1371 for the message. Presence of options are indicated by the 1372 appropriate bit in the flags field being set. The bits are 1373 defined LSB first, so bit 0 would be the least significant 1374 bit of the Flags octet. In the description below, a bit 1375 being 'set' means its value is '1', while 'cleared' means 1376 its value is '0'. 1378 -- R(eserved) (bits 0-2) - These bits MUST be cleared 1379 when sending and MUST be ignored on receipt. 1381 -- I(nitiator) (bit 3 of Flags) - This bit MUST be set in 1382 messages sent by the original Initiator of the IKE SA 1383 and MUST be cleared in messages sent by the original 1384 Responder. It is used by the recipient to determine 1385 whether the message ID should be interpreted 1386 in the context of its initiating state or its responding 1387 state. 1389 -- V(ersion) (bit 4 of Flags) - This bit indicates that 1390 the transmitter is capable of speaking a higher major 1391 version number of the protocol than the one indicated 1392 in the major version number field. Implementations of 1393 IKEv2 must clear this bit when sending and MUST ignore 1394 it in incoming messages. 1396 -- R(eserved) (bits 5-7 of Flags) - These bits MUST be 1397 cleared when sending and MUST be ignored on receipt. 1399 o Message ID (4 octets) - Message identifier used to control 1400 retransmission of lost packets and matching of requests and 1401 responses. See section 4.2. In the first message of a Phase 1 1402 negotiation, the value MUST be set to 0. The response to that 1403 message MUST also have a Message ID of 0. 1405 o Length (4 octets) - Length of total message (header + payloads) 1406 in octets. Session encryption can expand the size of an IKE 1407 message and that is reflected in the total length of the 1408 message. 1410 5.2 Generic Payload Header 1412 Each IKE payload defined in sections 5.3 through 5.14 begins with a 1413 generic header, shown in Figure 2. Figures for each payload below 1414 will include the generic payload header but for brevity the 1415 description of each field will be omitted. The construction and 1416 processing of the generic payload header is identical for each 1417 payload and will similarly be omitted. 1419 1 2 3 1420 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 1421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1422 ! Next Payload !C! RESERVED ! Payload Length ! 1423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 Figure 2: Generic Payload Header 1427 The Generic Payload Header fields are defined as follows: 1429 o Next Payload (1 octet) - Identifier for the payload type of the 1430 next payload in the message. If the current payload is the last 1431 in the message, then this field will be 0. This field provides 1432 a "chaining" capability whereby additional payloads can be 1433 added to a message by appending it to the end of the message 1434 and setting the "Next Payload" field of the preceding payload 1435 to indicate the new payload's type. For an Encrypted payload, 1436 which must always be the last payload of a message, the Next 1437 Payload field is set to the payload type of the first contained 1438 payload. 1440 o Critical (1 bit) - MUST be set to zero if the sender wants 1441 the recipient to skip this payload if he does not 1442 understand the payload type code. MUST be set to one if the 1443 sender wants the recipient to reject this entire message 1444 if he does not understand this payload type. MUST be ignored 1445 by the recipient if the recipient understands the payload type 1446 code. SHOULD be set to zero for payload types defined in this 1447 document. Note that the critical bit applies to the current 1448 payload rather than the "next" payload whose type code 1449 appears in the first octet. The reasoning behind not setting 1450 the critical bit for payloads defined in this document is 1451 that all implementations MUST understand all payload types 1452 defined in this document and therefore must ignore the 1453 Critical bit's value. 1455 o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored. 1457 o Payload Length (2 octets) - Length in octets of the current 1458 payload, including the generic payload header. 1460 5.3 Security Association Payload 1462 The Security Association Payload, denoted SA in this memo, is used to 1463 negotiate attributes of a security association. An SA may contain 1464 multiple proposals. Each proposal may propose multiple protocols 1465 (where a protocol is IKE, ESP, AH, or IPcomp), along with a suite of 1466 cryptographic algorithms to be used by the protocols. The 1467 protocol(s), cryptographic algorithms, and any associated parameters 1468 are determined by the suite number. An SA payload MAY contain 1469 proposals for different protocols. For example, one suite might 1470 contain AH, ESP, and IPcomp, while another might contain only ESP and 1471 a third ESP and IPcomp. 1473 The Proposal structure contains within it a Proposal # and a Suite- 1474 ID. The first proposal MUST have Proposal # = 1, the second MUST 1475 have Proposal # = 2, etc. If the proposals are misnumbered, the 1476 responder MUST reject all of them. 1478 1 2 3 1479 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 1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1481 ! Next Payload !C! RESERVED ! Payload Length ! 1482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1483 ! ! 1484 ~ ~ 1485 ! ! 1486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1488 Figure 3: Security Association Payload 1490 o Proposals (variable) - one or more proposal substructures. 1492 The payload type for the Security Association Payload is one (1). 1494 5.3.1 Proposal Substructure 1496 1 2 3 1497 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 1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1499 ! 0 (last) or 2 ! RESERVED ! Proposal Length ! 1500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1501 ! Proposal # ! RESERVED-MBZ ! Suite-ID ! 1502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 ~ SPI(S) (variable) ~ 1504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 Figure 4: Proposal Substructure 1508 o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the 1509 last Proposal Substructure in the SA. This syntax is inherited 1510 from ISAKMP, but is unnecessary because the last Proposal 1511 could be identified from the length of the SA. The value (2) 1512 corresponds to a Payload Type of Proposal, and the first 1513 four octets of the Proposal structure are designed to look 1514 somewhat like the header of a Payload. 1516 o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored. 1518 o Proposal Length (2 octets) - Length of this proposal, 1519 including the SPI 1521 o Proposal # (1 octet) - When a proposal is made, the first 1522 proposal in an SA MUST be #1, and subsequent proposals 1523 MUST be one greater than the previous proposal. When a 1524 proposal is accepted, the SA MUST contain a single proposal 1525 and the proposal number MUST match the accepted proposal 1526 from the Initiator. 1528 o RESERVED-MBZ (1 octet) - This field is reserved for 1529 possible use in specifying different kinds of proposals. 1530 This field MUST be sent as zero and a proposal containing 1531 a non-zero value MUST NOT be accepted. 1533 o Suite-ID (2 octets) - This field specifies a suite of 1534 protocols and cryptographic algorithms. See table below. 1536 o SPI(S) (variable) - The sending entity's SPI(s). If the 1537 suite proposed includes more than one protocol, the SPIs 1538 are concatenated together in the order in which they would 1539 appear in a packet sent using the suite (i.e. AH followed 1540 by ESP followed by IPcomp. When an initial IKE SA is being 1541 proposed, SPIs are implicit from the IKE header and are not 1542 repeated here. Even if the SPI 1543 Size is not a multiple of 4 octets, there is no padding 1544 applied to the payload. When the SPI Size field is zero, 1545 this field is not present in the Security Association 1546 payload. 1548 For Suite-ID, the following values are defined: 1550 Name Number Algorithms 1551 IKE_CLASSIC 0 DH-Group #5 (1536 bits) 1552 3DES encryption 1553 HMAC-SHA1 integrity and prf 1555 ESP_CLASSIC 1 3DES encryption 1556 HMAC-SHA1 integrity 1558 ~ 2176 ! ! 2177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2179 Figure 16: Traffic Selectors Payload Format 2181 o Number of TSs (1 octet) - Number of traffic selectors 2182 being provided. 2184 o RESERVED - This field MUST be sent as zero and MUST be ignored. 2186 o Traffic Selectors (variable length) - one or more individual 2187 traffic 2188 selectors. 2190 The length of the Traffic Selector payload includes the TS header and 2191 all the traffic selectors. 2192 The payload type for the Traffic Selector payload is fourteen (14). 2194 5.13.1 Traffic Selector 2196 1 2 3 2197 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 2198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2199 ! TS Type ! Protocol ID | Selector Length | 2200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2201 | Start-Port | End-Port | 2202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2203 ! ! 2204 ~ Starting Address ~ 2205 ! ! 2206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2207 ! ! 2208 ~ Ending Address ~ 2209 ! ! 2210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2212 Figure 17: Traffic Selector 2214 o TS Type (one octet) - Specifies the type of traffic selector. 2216 o Protocol ID (1 octet) - Value specifying an associated IP 2217 protocol ID (e.g. UDP/TCP). A value of zero means that the 2218 Protocol ID is not relevant to this traffic selector-- 2219 the SA can carry all protocols. 2221 o Selector Length - Specifies the length of this Traffic 2222 Selector Substructure including the header. 2224 o Start-Port (2 octets) - Value specifying the smallest port 2225 number allowed by this Traffic Selector. For protocols for 2226 which port is undefined, or if all ports are allowed by 2227 this Traffic Selector, this field MUST be zero. 2229 o End-Port (2 octets) - Value specifying the largest port 2230 number allowed by this Traffic Selector. For protocols for 2231 which port is undefined, or it all ports are allowed by 2232 this Traffic Selector, this field MUST be 65535. 2234 o Starting Address - The smallest address included in this 2235 Traffic Selector (length determined by TS type). 2237 o Ending Address - The largest address included in this 2238 Traffic Selector (length determined by TS type). 2240 The following table lists the assigned values for the Traffic 2241 Selector Type field and the corresponding Address Selector Data. 2243 TS Type Value 2244 ------- ----- 2245 RESERVED 0 2247 TS_IPV4_ADDR_RANGE 7 2248 A range of IPv4 addresses, represented by two four (4) octet 2249 values. The first value is the beginning IPv4 address 2250 (inclusive) and the second value is the ending IPv4 address 2251 (inclusive). All addresses falling between the two specified 2252 addresses are considered to be within the list. 2254 TS_IPV6_ADDR_RANGE 8 2256 A range of IPv6 addresses, represented by two sixteen (16) 2257 octet values. The first value is the beginning IPv6 address 2258 (inclusive) and the second value is the ending IPv6 address 2259 (inclusive). All addresses falling between the two specified 2260 addresses are considered to be within the list. 2262 5.14 Encrypted Payload 2264 The Encrypted Payload, denoted SK{...} in this memo, contains other 2265 payloads in encrypted form. The Encrpted Payload, if present in a 2266 message, must be the last payload in the message. Often, it is the 2267 only payload in the message. 2269 The algorithms for encryption and integrity protection are negotiated 2270 during IKE-SA setup, and the keys are computed as specified in 2271 sections 4.14 and 4.17. 2273 The encryption and integrity protection algorithms are modelled after 2274 the ESP algorithms described in RFCs 2104, 2406, 2451. This document 2275 completely specifies the cryptographic processing of IKE data, but 2276 those documents should be consulted for design rationale. We assume a 2277 block cipher with a fixed block size and an integrity check algorithm 2278 that computes a fixed length checksum over a variable size message. 2279 The mandatory to implement algorithms are AES-128-CBC and HMAC-SHA1. 2281 The Payload Type for an Encrypted payload is fifteen (15). The 2282 Encrypted Payload consists of the IKE generic header followed by 2283 individual fields as follows: 2285 1 2 3 2286 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 2287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2288 ! Next Payload !C! RESERVED ! Payload Length ! 2289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2290 ! Initialization Vector ! 2291 ! (length is block size for encryption algorithm) ! 2292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2293 ! Encrypted IKE Payloads ! 2294 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2295 ! ! Padding (0-255 octets) ! 2296 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 2297 ! ! Pad Length ! 2298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2299 ~ Integrity Checksum Data ~ 2300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2302 Figure 9: Encrypted Payload Format 2304 o Next Payload - The payload type of the first embedded payload. 2305 Since the Encrypted payload must be last in a message, there 2306 is no need to specify a payload type for a payload beyond it. 2308 o Payload Length - Includes the lengths of the IV, Padding, and 2309 Authentication data. 2311 o Initialization Vector - A randomly chosen value whose length 2312 is equal to the block length of the underlying encryption 2313 algorithm. Recipients MUST accept any value. Senders SHOULD 2314 either pick this value pseudo-randomly and independently for 2315 each message or use the final ciphertext block of the previous 2316 message sent. Senders MUST NOT use the same value for each 2317 message, use a sequence of values with low hamming distance 2318 (e.g. a sequence number), or use ciphertext from a received 2319 message. 2321 o IKE Payloads are as specified earlier in this section. This 2322 field is encrypted with the negotiated cipher. 2324 o Padding may contain any value chosen by the sender, and must 2325 have a length that makes the combination of the Payloads, the 2326 Padding, and the Pad Length to be a multiple of the encryption 2327 block size. This field is encrypted with the negotiated 2328 cipher. 2330 o Pad Length is the length of the Padding field. The sender 2331 SHOULD set the Pad Length to the minimum value that makes 2332 the combination of the Payloads, the Padding, and the Pad 2333 Length a multiple of the block size, but the recipient MUST 2334 accept any length that results in proper alignment. This 2335 field is encrypted with the negotiated cipher. 2337 o Integrity Checksum Data is the cryptographic checksum of 2338 the entire message starting with the Fixed IKE Header 2339 through the Pad Length. The checksum MUST be computed over 2340 the encrypted message. 2342 5.15 Other Payload Types 2343 Payload type values 16-127 are reserved to IANA for future assignment 2344 in IKE. Payload type values 128-255 are for private use among 2345 mutually consenting parties. 2347 6 Conformance Requirements 2349 In order to assure that all implementations of IKEv2 can 2350 interoperate, there are MUST support requirements in addition to 2351 those listed elsewhere. Of course, IKEv2 is a security protocol, and 2352 one of its major functions is preventing the bad guys from 2353 interoperating with one's systems. So a particular implementation may 2354 be configured with any of a number of restrictions concerning 2355 algorithms and trusted authorities that will prevent universal 2356 interoperability. For an implementation to be called conforming to 2357 this specification, it MUST be possible to configure it to accept the 2358 following: 2360 X.509 certificates containing and signed by RSA keys of size 512, 2361 768, 1024, and 2048 bits. (It SHOULD accept RSA keys of any multiple 2362 of 8 bits in size from 512 bits to 4092 bits, and MAY accept RSA keys 2363 of any size). If there is a limit on the size of an X.509 2364 certificate, it MUST be at least 8K. If there is a limit on the 2365 length of a certificate chain, it MUST be at least 10. 2367 X.509 certificates containing and signed by DSS keys of size 512, 2368 768, 1024, and 2048 bits. (It MAY accept DSS keys of any size). 2370 An implementation MUST be capable of accepting a shared key for 2371 authentication of any size from 1 - 255 bytes. 2373 An implementation MUST be capable of accepting IKE messages with 2374 sizes up to 16K bytes and SHOULD be capable of accepting IKE messages 2375 up to 64K bytes. 2377 An implementation MUST be capable of establishing an IKE-SA and a 2378 single CHILD-SA in the initial four message exchange. An 2379 implementation MAY reject subsequent requests to establish a CHILD- 2380 SA. An implementation MUST respond to valid phase 2 messages, but MAY 2381 otherwise ignore all such messages other than DELETE. There is no 2382 requirement that an implementation be capable of initiating phase 2 2383 exchanges. 2385 The above paragraph allows for a minimal implementation to only do 2386 the initial 4 message IKE exchange and respond to phase 2 pings and 2387 still interoperate with any compliant implementation. In support of 2388 this, and implementation that tries to rekey the IKE-SA by means of a 2389 CREATE_CHILD_SA exchange MUST be prepared to tear down the IKE-SA and 2390 establish a new one if the rekeying operation fails. 2392 7 Security Considerations 2394 Repeated re-keying using Phase 2 without PFS can consume the entropy 2395 of the Diffie-Hellman shared secret. Implementers should take note of 2396 this fact and set a limit on Phase 2 Exchanges between 2397 exponentiations. This memo does not prescribe such a limit. 2399 The strength of a key derived from a Diffie-Hellman exchange using 2400 any of the groups defined here depends on the inherent strength of 2401 the group, the size of the exponent used, and the entropy provided by 2402 the random number generator used. Due to these inputs it is difficult 2403 to determine the strength of a key for any of the defined groups. 2404 Diffie-Hellman group number two when used with a strong random number 2405 generator and an exponent no less than 160 bits is sufficient to use 2406 for 3DES. Groups three through five provide greater security. Group 2407 one is for historic purposes only and does not provide sufficient 2408 strength to the required cipher (although it is sufficient for use 2409 with DES, which is also for historic use only). Implementations 2410 should make note of these conservative estimates when establishing 2411 policy and negotiating security parameters. 2413 Note that these limitations are on the Diffie-Hellman groups 2414 themselves. There is nothing in IKE which prohibits using stronger 2415 groups nor is there anything which will dilute the strength obtained 2416 from stronger groups. In fact, the extensible framework of IKE 2417 encourages the definition of more groups; use of elliptical curve 2418 groups may greatly increase strength using much smaller numbers. 2420 It is assumed that the Diffie-Hellman exponents in this exchange are 2421 erased from memory after use. In particular, these exponents MUST NOT 2422 be derived from long-lived secrets like the seed to a pseudo-random 2423 generator that is not erased after use. 2425 The security of this protocol is critically dependent on the 2426 randomness of the Diffie-Hellman exponents, which should be generated 2427 by a strong random or properly seeded pseudo-random source (see 2428 RFC1715). While the protocol was designed to be secure even if the 2429 Nonces and other values specified as random are not strongly random, 2430 they should similarly be generated from a strong random source as 2431 part of a conservative design. 2433 8 IANA Considerations 2435 This document contains many "magic numbers" to be maintained by the 2436 IANA. This section explains the criteria to be used by the IANA to 2437 assign additional numbers in each of these lists. 2439 8.1.2 Encryption Algorithm Transform Type 2440 Values of the Encryption Algorithm define an encryption algorithm to 2441 use when called for in this document. Requests for assignment of new 2442 encryption algorithm values must be accompanied by a reference to an 2443 RFC that describes how to use this algorithm with ESP. 2445 8.1.4 Authentication Method Transform Type 2447 The only Authentication method defined in the memo is for digital 2448 signatures. Other methods of authentication are possible and MUST be 2449 accompanied by an RFC which defines the following: 2451 - the cryptographic method of authentication. 2452 - content of the Authentication Data in the Authentication 2453 Payload. 2454 - new payloads, their construction and processing, if needed. 2455 - additions of payloads to any messages, if needed. 2457 8.1.5 Diffie-Hellman Groups 2459 Values of the Diffie-Hellman Group Transform types define a group in 2460 which a Diffie-Hellman key exchange can be completed. Requests for 2461 assignment of a new Diffie-Hellman group type MUST be accompanied by 2462 a reference to an RFC which fully defines the group. 2464 8.2 Exchange Types 2466 This memo defines three exchange types for use with IKEv2. Requests 2467 for assignment of new exchange types MUST be accompanied by an RFC 2468 which defines the following: 2470 - the purpose of and need for the new exchange. 2471 - the payloads (mandatory and optional) that accompany 2472 messages in the exchange. 2473 - the phase of the exchange. 2474 - requirements the new exchange has on existing 2475 exchanges which have assigned numbers. 2477 8.3 Payload Types 2479 Payloads are defined in this memo to convey information between 2480 peers. New payloads may be required when defining a new 2481 authentication method or exchange. Requests for new payload types 2482 MUST be accompanied by an RFC which defines the physical layout of 2483 the payload and the fields it contains. All payloads MUST use the 2484 same generic header defined in Figure 2. 2486 9 Acknowledgements 2487 This document is a collaborative effort of the entire IPsec WG. If 2488 there were no limit to the number of authors that could appear on an 2489 RFC, the following, in alphabetical order, would have been listed: 2490 Bill Aiello, Steve Bellovin, Sara Bitan, Matt Blaze, Ran Canetti, Dan 2491 Harkins, Paul Hoffman, J. Ioannidis, Steve Kent, Angelos Keromytis, 2492 Tero Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, O. 2493 Reingold. Many other people contributed to the design. Hugh Daniel 2494 suggested the feature of having the initiator, in message 3, specify 2495 a name for the responder, and gave the feature the cute name "You 2496 Tarzan, Me Jane". David Faucher and Valery Smyzlov helped refine the 2497 design of the traffic selector negotiation. 2499 10 References 2501 [Bra96] Bradner, S., "The Internet Standards Process -- Revision 3", 2502 BCP 9, RFC 2026, October 1996. 2504 [Bra97] Bradner, S., "Key Words for use in RFCs to indicate 2505 Requirement Levels", BCP 14, RFC 2119, March 1997. 2507 [Ble98] Bleichenbacher, D., "Chosen Ciphertext Attacks against 2508 Protocols Based on RSA Encryption Standard PKCS#1", Advances 2509 in Cryptology Eurocrypt '98, Springer-Verlag, 1998. 2511 [BR94] Bellare, M., and Rogaway P., "Optimal Asymmetric 2512 Encryption", Advances in Cryptology Eurocrypt '94, 2513 Springer-Verlag, 1994. 2515 [DES] ANSI X3.106, "American National Standard for Information 2516 Systems-Data Link Encryption", American National Standards 2517 Institute, 1983. 2519 [DH] Diffie, W., and Hellman M., "New Directions in 2520 Cryptography", IEEE Transactions on Information Theory, V. 2521 IT-22, n. 6, June 1977. 2523 [DSS] NIST, "Digital Signature Standard", FIPS 186, National 2524 Institute of Standards and Technology, U.S. Department of 2525 Commerce, May, 1994. 2527 [HC98] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", 2528 RFC 2409, November 1998. 2530 [IDEA] Lai, X., "On the Design and Security of Block Ciphers," ETH 2531 Series in Information Processing, v. 1, Konstanz: Hartung- 2532 Gorre Verlag, 1992 2534 [Ker01] Keronytis, A., Sommerfeld, B., "The 'Suggested ID' Extension 2535 for IKE", draft-keronytis-ike-id-00.txt, 2001 2537 [KBC96] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2538 Hashing for Message Authentication", RFC 2104, February 2539 1997. 2541 [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange 2542 Mechanism for Internet", from IEEE Proceedings of the 1996 2543 Symposium on Network and Distributed Systems Security. 2545 [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, 2546 April 1992. 2548 [MSST98] Maughhan, D., Schertler, M., Schneider, M., and Turner, J. 2549 "Internet Security Association and Key Management Protocol 2550 (ISAKMP)", RFC 2408, November 1998. 2552 [Orm96] Orman, H., "The Oakley Key Determination Protocol", RFC 2553 2412, November 1998. 2555 [PFKEY] McDonald, D., Metz, C., and Phan, B., "PFKEY Key Management 2556 API, Version 2", RFC2367, July 1998. 2558 [PKCS1] Kaliski, B., and J. Staddon, "PKCS #1: RSA Cryptography 2559 Specifications Version 2", September 1998. 2561 [PK01] Perlman, R., and Kaufman, C., "Analysis of the IPsec key 2562 exchange Standard", WET-ICE Security Conference, MIT, 2001, 2563 http://sec.femto.org/wetice-2001/papers/radia-paper.pdf. 2565 [Pip98] Piper, D., "The Internet IP Security Domain Of 2566 Interpretation for ISAKMP", RFC 2407, November 1998. 2568 [RSA] Rivest, R., Shamir, A., and Adleman, L., "A Method for 2569 Obtaining Digital Signatures and Public-Key Cryptosystems", 2570 Communications of the ACM, v. 21, n. 2, February 1978. 2572 [SHA] NIST, "Secure Hash Standard", FIPS 180-1, National Institute 2573 of Standards and Technology, U.S. Department of Commerce, 2574 May 1994. 2576 Appendix B: Diffie-Hellman Groups 2578 There are 5 groups different Diffie-Hellman groups defined for use in 2579 IKE. These groups were generated by Richard Schroeppel at the 2580 University of Arizona. Properties of these primes are described in 2581 [Orm96]. 2583 The strength supplied by group one may not be sufficient for the 2584 mandatory-to-implement encryption algorithm and is here for historic 2585 reasons. 2587 B.1 Group 1 - 768 Bit MODP 2589 IKE implementations MAY support a MODP group with the following prime 2590 and generator. This group is assigned id 1 (one). 2592 The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } 2593 Its hexadecimal value is: 2595 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 2596 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 2597 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 2598 A63A3620 FFFFFFFF FFFFFFFF 2600 The generator is 2. 2602 B.2 Group 2 - 1024 Bit MODP 2604 IKE implementations SHOULD support a MODP group with the following 2605 prime and generator. This group is assigned id 2 (two). 2607 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. 2608 Its hexadecimal value is: 2610 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 2611 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 2612 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 2613 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 2614 49286651 ECE65381 FFFFFFFF FFFFFFFF 2616 The generator is 2. 2618 B.3 Group 3 - 155 Bit EC2N 2620 IKE implementations MAY support a EC2N group with the following 2621 characteristics. This group is assigned id 3 (three). The curve is 2622 based on the Galois Field GF[2^155]. The field size is 155. The 2623 irreducible polynomial for the field is: 2624 u^155 + u^62 + 1. 2625 The equation for the elliptic curve is: 2626 y^2 + xy = x^3 + ax^2 + b. 2628 Field Size: 155 2629 Group Prime/Irreducible Polynomial: 2630 0x0800000000000000000000004000000000000001 2631 Group Generator One: 0x7b 2632 Group Curve A: 0x0 2633 Group Curve B: 0x07338f 2634 Group Order: 0x0800000000000000000057db5698537193aef944 2636 The data in the KE payload when using this group is the value x from 2637 the solution (x,y), the point on the curve chosen by taking the 2638 randomly chosen secret Ka and computing Ka*P, where * is the 2639 repetition of the group addition and double operations, P is the 2640 curve point with x coordinate equal to generator 1 and the y 2641 coordinate determined from the defining equation. The equation of 2642 curve is implicitly known by the Group Type and the A and B 2643 coefficients. There are two possible values for the y coordinate; 2644 either one can be used successfully (the two parties need not agree 2645 on the selection). 2647 B.4 Group 4 - 185 Bit EC2N 2649 IKE implementations MAY support a EC2N group with the following 2650 characteristics. This group is assigned id 4 (four). The curve is 2651 based on the Galois Field GF[2^185]. The field size is 185. The 2652 irreducible polynomial for the field is: 2653 u^185 + u^69 + 1. 2655 The equation for the elliptic curve is: 2656 y^2 + xy = x^3 + ax^2 + b. 2658 Field Size: 185 2659 Group Prime/Irreducible Polynomial: 2660 0x020000000000000000000000000000200000000000000001 2661 Group Generator One: 0x18 2662 Group Curve A: 0x0 2663 Group Curve B: 0x1ee9 2664 Group Order: 0x01ffffffffffffffffffffffdbf2f889b73e484175f94ebc 2666 The data in the KE payload when using this group will be identical to 2667 that as when using Oakley Group 3 (three). 2669 B.5 Group 5 - 1536 Bit MODP 2671 IKE implementations MUST support a MODP group with the following 2672 prime and generator. This group is assigned id 5 (five). 2674 The prime is 2^1536 - 2^1472 - 1 + 2^64 * {[2^1406 pi] + 741804}. 2675 Its hexadecimal value is 2677 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 2678 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 2679 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 2680 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 2681 49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 2682 FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 2683 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF 2685 The generator is 2. 2687 Change History 2689 H.1 Changes from IKEv2-00 to IKEv2-01 February 2002 2691 1) Changed Appendix B to specify the encryption and authentication 2692 processing for IKE rather than referencing ESP. Simplified the format 2693 by removing idiosyncracies not needed for IKE. 2695 2) Added option for authentication via a shared secret key. 2697 3) Specified different keys in the two directions of IKE messages. 2698 Removed requirement of different cookies in the two directions since 2699 now no longer required. 2701 4) Change the quantities signed by the two ends in AUTH fields to 2702 assure the two parties sign different quantities. 2704 5) Changed reference to AES to AES_128. 2706 6) Removed requirement that Diffie-Hellman be repeated when rekeying 2707 IKE SA. 2709 7) Fixed typos. 2711 8) Clarified requirements around use of port 500 at the remote end in 2712 support of NAT. 2714 9) Clarified required ordering for payloads. 2716 10) Suggested mechanisms for avoiding DoS attacks. 2718 11) Removed claims in some places that the first phase 2 piggybacked 2719 on phase 1 was optional. 2721 H.2 Changes from IKEv2-01 to IKEv2-02 April 2002 2723 1) Moved the Initiator CERTREQ payload from message 1 to message 3. 2725 2) Added a second optional ID payload in message 3 for the Initiator 2726 to name a desired Responder to support the case where multiple named 2727 identities are served by a single IP address. 2729 3) Deleted the optimization whereby the Diffie-Hellman group did not 2730 need to be specified in phase 2 if it was the same as in phase 1 (it 2731 complicated the design with no meaningful benefit). 2733 4) Added a section on the implications of reusing Diffie-Hellman 2734 expontentials 2735 5) Changed the specification of sequence numbers to being at 0 in 2736 both directions. 2738 6) Many editorial changes and corrections, the most significant being 2739 a global replace of "byte" with "octet". 2741 H.3 Changes from IKEv2-02 to IKEv2-03 October 2002 2743 1) Reorganized the document moving introductory material to the 2744 front. 2746 2) Simplified the specification of Traffic Selectors to allow only 2747 IPv4 and IPv6 address ranges, as was done in the JFK spec. 2749 3) Fixed the problem brought up by David Faucher with the fix 2750 suggested by Valery Smyslov. If Bob needs to narrow the selector 2751 range, but has more than one matching narrower range, then if Alice's 2752 first selector is a single address pair, Bob chooses the range that 2753 encompasses that. 2755 4) To harmonize with the JFK spec, changed the exchange so that the 2756 initial exchange can be completed in four messages even if the 2757 responder must invoke an anti-clogging defense and the initiator 2758 incorrectly anticipates the responder's choice of Diffie-Hellman 2759 group. This required changing the syntax of encrypted messages to 2760 allow messages that are partially encrypted. 2762 5) Replaced the hierarchical SA payload with a simplified version 2763 that only negotiates suites of cryptographic algorithms. Separated 2764 out negotiation of window size. Removed specifications of large 2765 numbers of rarely used algorithms. 2767 6) Changed the formulas for key derivation as proposed by Hugo 2768 Krawczyk. 2770 7) Added Comformance Requirements section. 2772 Author's Address 2774 Charlie Kaufman charlie_kaufman@notesdev.ibm.com IBM