idnits 2.17.1 draft-ietf-ipsec-ikev2-00.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-25) 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 63 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 64 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 2526 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 username string, An example of a ID_USER_FQDN 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 (November 2001) is 8197 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2522' is mentioned on line 443, but not defined == Missing Reference: 'CERTREQ' is mentioned on line 723, but not defined == Missing Reference: 'P' is mentioned on line 1525, but not defined == Missing Reference: 'ESP' is mentioned on line 2867, but not defined == Unused Reference: 'CAST' is defined on line 2693, but no explicit reference was found in the text == Unused Reference: 'BLOW' is defined on line 2696, but no explicit reference was found in the text == Unused Reference: 'Ble98' is defined on line 2705, but no explicit reference was found in the text == Unused Reference: 'BR94' is defined on line 2709, but no explicit reference was found in the text == Unused Reference: 'DES' is defined on line 2713, but no explicit reference was found in the text == Unused Reference: 'DH' is defined on line 2717, but no explicit reference was found in the text == Unused Reference: 'DSS' is defined on line 2721, but no explicit reference was found in the text == Unused Reference: 'IDEA' is defined on line 2725, but no explicit reference was found in the text == Unused Reference: 'KBC96' is defined on line 2729, but no explicit reference was found in the text == Unused Reference: 'SKEME' is defined on line 2733, but no explicit reference was found in the text == Unused Reference: 'MD5' is defined on line 2737, but no explicit reference was found in the text == Unused Reference: 'MSST98' is defined on line 2740, but no explicit reference was found in the text == Unused Reference: 'PKCS1' is defined on line 2750, but no explicit reference was found in the text == Unused Reference: 'PK01' is defined on line 2753, but no explicit reference was found in the text == Unused Reference: 'Pip98' is defined on line 2757, but no explicit reference was found in the text == Unused Reference: 'RC5' is defined on line 2760, but no explicit reference was found in the text == Unused Reference: 'RSA' is defined on line 2763, but no explicit reference was found in the text == Unused Reference: 'Sch96' is defined on line 2767, but no explicit reference was found in the text == Unused Reference: 'SHA' is defined on line 2770, but no explicit reference was found in the text == Unused Reference: 'TIGER' is defined on line 2774, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2144 (ref. 'CAST') -- Possible downref: Non-RFC (?) normative reference: ref. 'BLOW' -- 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'IDEA' ** 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. 'RC5' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSA' -- Possible downref: Non-RFC (?) normative reference: ref. 'Sch96' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA' -- Possible downref: Non-RFC (?) normative reference: ref. 'TIGER' Summary: 12 errors (**), 0 flaws (~~), 32 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSEC Working Group Dan Harkins 3 INTERNET-DRAFT Charlie Kaufman 4 Radia Perlman 5 editors 6 draft-ietf-ipsec-ikev2-00.txt November 2001 8 The Internet Key Exchange (IKE) Protocol 9 11 Status of this Memo 13 This document is an Internet Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026 [Bra96]. Internet Drafts are 15 working documents of the Internet Engineering Task Force (IETF), its 16 areas, and working groups. Note that other groups may also distribute 17 working documents as Internet Drafts. 19 Internet Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Abstract 32 This document describes version 2 of the IKE (Internet Key Exchange) 33 protocol. IKE performs mutual authentication and establishes an IKE 34 security association that can be used to efficiently establish SAs 35 for ESP, AH and/or IPcomp. This version greatly simplifies IKE by 36 replacing the 8 possible phase 1 exchanges with a single exchange 37 based on public signature keys. The single exchange provides 38 identity hiding, yet works in 2 round trips (all the identity hiding 39 exchanges in IKE v1 required 3 round trips). Latency of setup of an 40 IPsec SA is further reduced from IKEv1 by allowing setup of an SA for 41 ESP, AH, and/or IPcomp to be piggybacked on the initial IKE exchange. 42 It also improves security by allowing the Responder to be stateless 43 until it can be assured that the Initiator can receive at the claimed 44 IP source address. This version also presents the entire protocol in 45 a single self-contained document, in contrast to IKEv1, in which the 46 protocol was described in ISAKMP (RFC 2408), IKE (RFC 2409), and the 47 DOI (RFC 2407) documents. 49 Table of Contents 51 1. Introduction..............................................3 52 1.1 The IKE Protocol.........................................3 53 1.2 Changes from IKEv1.......................................4 54 1.3 Requirements Terminology.................................5 55 2 Protocol Overview..........................................5 56 2.1 Use of Retransmission Timers.............................6 57 2.2 Use of Sequence Numbers for Message ID...................6 58 2.3 Window Size for overlapping requests.....................7 59 2.4 State Synchronization and Connection Timeouts............7 60 2.5 Version Numbers and Forward Compatibility................8 61 2.6 Cookies..................................................10 62 2.7 Cryptographic Algorithm Negotiation......................12 63 2.8 Rekeying.................................................13 64 2.9 Traffic Selector Negotiation.............................14 65 2.10 Nonces..................................................15 66 3 The Phase 1 Exchange.......................................15 67 3.1 Generating Keying Material for the IKE-SA................17 68 3.2 Authentication of the IKE-SA.............................17 69 4 The CREATE-CHILD-SA (Phase 2) Exchange.....................18 70 4.1 Generating Keying Material for Child-SAs.................19 71 4.2 Generating Keying Material for IKE-SAs during rollover...20 72 5 Informational (Phase 2) Exchange...........................20 73 6 Error Handling.............................................22 74 7 Header and Payload Formats.................................23 75 7.1 The IKE Header...........................................23 76 7.2 Generic Payload Header...................................26 77 7.3 Security Association Payload.............................27 78 7.3.1 Proposal Substructure..................................29 79 7.3.2 Transform Substructure.................................31 80 7.3.3 Mandatory Transform Types..............................34 81 7.3.4 Mandatory Transform-IDs................................34 82 7.3.5 Transform Attributes...................................35 83 7.3.6 Attribute Negotiation..................................36 84 7.4 Key Exchange Payload.....................................36 85 7.5 Identification Payload...................................37 86 7.6 Certificate Payload......................................39 87 7.7 Certificate Request Payload..............................40 88 7.8 Authentication Payload...................................41 89 7.9 Nonce Payload............................................42 90 7.10 Notify Payload..........................................43 91 7.10.1 Notify Message Types..................................44 92 7.11 Delete Payload..........................................48 93 7.12 Vendor ID Payload.......................................49 94 7.13 Traffic Selector Payload................................50 95 7.13.1 Traffic Selector Substructure.........................51 96 7.14 Other Payload types.....................................53 97 8 Diffie-Hellman Groups......................................53 98 9 Security Considerations....................................55 99 10 IANA Considerations.......................................56 100 10.1 Transform Types and Attribute Values....................56 101 10.2 Exchange Types..........................................57 102 10.3 Payload Types...........................................57 103 11 Acknowledgements..........................................58 104 12 References................................................58 105 Appendix A: Attribute Assigned Numbers.......................61 106 Appendix B: Cryptographic Protection of IKE Data.............63 107 Authors' Addresses...........................................64 109 1. Introduction 111 IP Security (IPsec) provides confidentiality, data integrity, and 112 data source authentication to IP datagrams. These services are 113 provided by maintaining shared state between the source and the sink 114 of an IP datagram. This state defines, among other things, the 115 specific services provided to the datagram, which cryptographic 116 algorithms will be used to provide the services, and the keys used as 117 input to the cryptographic algorithms. 119 Establishing this shared state in a manual fashion does not scale 120 well. Therefore a protocol to establish this state dynamically is 121 needed. This memo describes such a protocol-- the Internet Key 122 Exchange (IKE). This is version 2 of IKE. Version 1 of IKE was 123 defined in RFCs 2407, 2408, and 2409. This single document is 124 intended to replace all three of those RFCs. 126 1.1 The IKE Protocol 128 IKE performs mutual authentication between two parties and 129 establishes an IKE security association that includes shared secret 130 information that can be used to efficiently establish SAs for ESP 131 (RFC 2406), AH (RFC 2402) and/or IPcomp (RFC 2393). We call the IKE 132 SA an "IKE-SA", and the SAs for ESP, AH, and/or IPcomp that get set 133 up through that IKE-SA we call "child-SA"s. 135 We call the setup of the IKE-SA "phase 1" and subsequent IKE 136 exchanges "phase 2" even though setup of a child-SA can be 137 piggybacked on the initial phase 1 exchange. The phase 1 exchange is 138 two request/response pairs. A phase 2 exchange is one 139 request/response pair, and can be used to create or delete a child- 140 SA, rekey or delete the IKE-SA, or give information such as error 141 conditions. 143 IKE message flow always consists of a request followed by a response. 144 It is the responsibility of the requester to ensure reliability. If 145 the response is not received within a timeout interval, the requester 146 retransmits the request. 148 The first request/response of a phase 1 exchange, which we'll call 149 IKE_SA_init, negotiates security parameters for the IKE-SA, and sends 150 Diffie-Hellman values. We call the response IKE_SA_init_response. 152 The second request/response, which we'll call IKE_auth, transmits 153 identities, proves knowledge of the private signature key, and 154 optionally sets up an SA for AH and/or ESP and/or IPcomp. We call 155 the response IKE_auth_response. 157 If the Responder feels it is under attack, and wishes to use a 158 stateless cookie (see section on cookies). it can respond to an 159 IKE_SA_init with an IKE_SA_init_reject with a cookie value that must 160 be sent with a subsequent IKE_SA_init_request. The Initiator then 161 sends another IKE_SA_init, but this time including the Responder's 162 cookie value. 164 Phase 2 exchanges each consist of a single request/response pair. The 165 types of exchanges are CREATE_CHILD_SA (creates a child-SA), or an 166 informational exchange which deletes a child-SA or the IKE-SA or 167 informs the other side of some error condition. All these messages 168 require a response, so an informational message with no payloads can 169 serve as a check for aliveness. 171 1.2 Changes from IKEv1 173 The goals of this revision to IKE are: 175 1) To define the entire IKE protocol in a single document, rather 176 than three that cross reference one another; 178 2) To simplify IKE by eliminating the Aggressive Mode option and all 179 but one of the authentication algorithms making phase 1 a single 180 exchange (based on public signature keys); 182 3) To remove the Domain of Interpretation (DOI), Situation (SIT), and 183 Labeled Domain Identifier fields, and the Commit and Authentication 184 only bits; 186 4) To decrease IKE's latency by making the initial exchange be 2 187 round trips (4 messages), and allowing the ability to piggyback setup 188 of a Child-SA on that exchange; 190 5) To replace the cryptographic algorithms for protecting the IKE 191 messages themselves with one based closely on ESP to simplify 192 implementation and security analysis; 194 6) To reduce the number of possible error states by making the 195 protocol reliable (all messages are acknowledged) and sequenced. This 196 allows shortening Phase 2 exchanges from 3 messages to 2; 198 7) To increase robustness by allowing the Responder, if under attack, 199 to require return of a cookie before the Responder commits any state 200 to the exchange; 202 8) To fix bugs such as the hash problem documented in [draft-ietf- 203 ipsec-ike-hash-revised-02.txt]; 205 9) To specify Traffic Selectors in their own payload type rather then 206 overloading ID payloads, and making more flexible the Traffic 207 Selectors that may be specified; 209 10) To avoid unnecessary exponential explosion of space in attribute 210 negotiation, by allowing choices when multiple algorithms of one type 211 (say, encryption) can work with any of a number of acceptable 212 algorithms of another type (say, integrity protection); 214 11) To specify required behavior under certain error conditions or 215 when data that is not understood is received in order to make it 216 easier to make future revisions in a way that does not break 217 backwards compatibility; 219 12) To simplify and clarify how shared state is maintained in the 220 presence of network failures and Denial of Service attacks; and 222 13) To maintain existing syntax and magic numbers to the extent 223 possible to make it likely that implementations of IKEv1 can be 224 enhanced to support IKEv2 with minimum effort. 226 1.3 Requirements Terminology 228 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 229 "MAY" that appear in this document are to be interpreted as described 230 in [Bra97]. 232 2 Protocol Overview 234 IKE runs over UDP port 500. Since UDP is a datagram (unreliable) 235 protocol, IKE includes in its definition recovery from transmission 236 errors, including packet loss, packet replay, and packet forgery. IKE 237 is designed to function so long as at least one of a series of 238 retransmitted packets reaches its destination before timing out and 239 the channel is not so full of forged and replayed packets so as to 240 exhaust the network or CPU capacities of either endpoint. Even in the 241 absence of those minimum performance requirements, IKE is designed to 242 fail cleanly (as though the network were broken). 244 2.1 Use of Retransmission Timers 246 All messages in IKE exist in pairs: a request and a response. Either 247 end of a security association may initiate requests at any time, and 248 there can be many requests and responses "in flight" at any given 249 moment. But each message is labelled as either a request or a 250 response and for each pair one end of the security association is the 251 Initiator and the other is the Responder. 253 For every pair of messages, the Initiator is responsible for 254 retransmission in the event of a timeout. The Responder will never 255 retransmit a response unless it receives a retransmission of the 256 request. In that event, the Responder MUST either ignore the 257 retransmitted request except insofar as it triggers a retransmission 258 of the response OR if the request is idempotent, the Responder may 259 choose to process the request again and send a semantically 260 equivalent reply. 262 IKE is a reliable protocol, in the sense that the Initiator MUST 263 retransmit a request until either it receives a corresponding reply 264 OR it deems the IKE security association to have failed and it 265 discards all state associated with the IKE-SA and any Child-SAs 266 negotiated using that IKE-SA. 268 2.2 Use of Sequence Numbers for Message ID 270 Every IKE message contains a Message ID as part of its fixed header. 271 This Message ID is used to match up requests and responses, and to 272 identify retransmissions of messages. 274 The Message ID is a 32 bit quantity, with is zero for the first IKE 275 message. Each endpoint in the IKE Security Association maintains two 276 "current" Message IDs: the next one to be used for a request it 277 initiates and the next one it expects to see from the other end. 278 These counters increment as requests are generated and received. 279 Responses always contain the same message ID as the corresponding 280 request. That means that after the initial setup, each integer n will 281 appear as the message ID in four distinct messages: The nth request 282 from the original IKE Initiator, the corresponding response, the nth 283 request from the original IKE Responder, and the corresponding 284 response. If the two ends make very different numbers of requests, 285 the Message IDs in the two directions can be very different. There is 286 no ambiguity in the messages, however, because each packet contains 287 enough information to determine which of the four messages a 288 particular one is. 290 In the case where the IKE_SA_init is rejected (e.g. in order to 291 require a cookie), the second IKE_SA_init message will begin the 292 sequence over with Message #0. 294 2.3 Window Size for overlapping requests 296 In order to maximize IKE throughput, an IKE endpoint MAY issue 297 multiple requests before getting a response to any of them. For 298 simplicity, an IKE implementation MAY choose to process requests 299 strictly in order and/or wait for a response to one request before 300 issuing another. Certain rules must be followed to assure 301 interoperability between implementations using different strategies. 303 After an IKE-SA is set up, either end can initiate one or more 304 requests. These requests may pass one another over the network. An 305 IKE endpoint MUST be prepared to accept and process a request while 306 it has a request outstanding in order to avoid a deadlock in this 307 situation. An IKE endpoint SHOULD be prepared to accept and process 308 multiple requests while it has a request outstanding. 310 An IKE endpoint MUST NOT exceed the peer's stated window size (see 311 section 7.3.2) for transmitted IKE requests. In other words, if Bob 312 stated his window size is N, then when Alice needs to make a request 313 X, she MUST wait until she has received responses to all requests up 314 through request X-N. An IKE endpoint MUST keep a copy of (or be able 315 to regenerate exactly) each request it has sent until it receives the 316 corresponding response. An IKE endpoint MUST keep a copy of (or be 317 able to regenerate with semantic equivalence) the number of previous 318 responses equal to its contracted window size in case its response 319 was lost and the Initiator requests its retransmission by 320 retransmitting the request. 322 An IKE endpoint SHOULD be capable of processing incoming requests out 323 of order to maximize performance in the event of network failures or 324 packet reordering. 326 2.4 State Synchronization and Connection Timeouts 328 An IKE endpoint is allowed to forget all of its state associated with 329 an IKE-SA and the collection of corresponding child-SAs at any time. 330 This is the anticipated behavior in the event of an endpoint crash 331 and restart. It is important when an endpoint either fails or 332 reinitializes its state that the other endpoint detect those 333 conditions and not continue to waste network bandwidth by sending 334 packets over those SAs and having them fall into a black hole. 336 Since IKE is designed to operate in spite of Denial of Service (DoS) 337 attacks from the network, an endpoint MUST NOT conclude that the 338 other endpoint has failed based on any routing information (e.g. ICMP 339 messages) or IKE messages that arrive without cryptographic 340 protection (e.g., notify messages complaining about unknown SPIs). An 341 endpoint MUST conclude that the other endpoint has failed only when 342 repeated attempts to contact it have gone unanswered for a timeout 343 period. An endpoint SHOULD suspect that the other endpoint has failed 344 based on routing information and initiate a request to see whether 345 the other endpoint is alive. To check whether the other side is 346 alive, IKE provides a null query notify message that requires an 347 acknowledgment. If a cryptographically protected message has been 348 received from the other side recently, unprotected notifications MAY 349 be ignored. Implementations MUST limit the rate at which they 350 generate responses to unprotected messages. 352 Numbers of retries and lengths of timeouts are not covered in this 353 specification because they do not affect interoperability. It is 354 suggested that messages be retransmitted at least a dozen times over 355 a period of at least several minutes before giving up on an SA, but 356 different environments may require different rules. An exception to 357 this rule is that a Responder who has not received a 358 cryptographically protected message on an IKE-SA MUST eventually time 359 it out and delete it. Note that consuming state on an IKE Responder 360 by setting up large numbers of half-open IKE-SAs is a likely denial 361 of service attack, so the policy for timing these out and limiting 362 the resources they consume should be considered carefully. 364 Note that with these rules, there is no reason to negotiate and agree 365 upon an SA lifetime. If IKE presumes the partner is dead, based on 366 repeated lack of acknowledgment to an IKE message, then the IKE SA 367 and all child-SAs set up through that IKE-SA are deleted. 369 An IKE endpoint MAY delete inactive Child-SAs to recover resources 370 used to hold their state. If an IKE endpoint chooses to do so, it 371 MUST send Delete payloads to the other end notifying it of the 372 deletion. It MAY similarly time out the IKE-SA. Closing the IKE-SA 373 implicitly closes all associated Child-SAs. An IKE endpoint SHOULD 374 send a Delete payload indicating that it has closed the IKE-SA. 376 2.5 Version Numbers and Forward Compatibility 378 This document describes version 2.0 of IKE, meaning the major version 379 number is 2 and the minor version number is zero. It is likely that 380 some implementations will want to support both version 1.0 and 381 version 2.0, and in the future, other versions. 383 The major version number should only be incremented if the packet 384 formats have changed so dramatically that an older version node would 385 not be able to interoperate with messages in the new version format. 386 The minor version number indicates new capabilities, and MUST be 387 ignored by a node with a smaller minor version number, but used for 388 informational purposes by the node with the larger minor version 389 number. For example, it might indicate the ability to process a newly 390 defined notification message. The node with the larger minor version 391 number would simply note that its correspondent would not be able to 392 understand that message and therefore would not send it. 394 If you receive a message with a higher major version number, you MUST 395 drop the message and SHOULD send an unauthenticated notification 396 message containing the highest version number you support. If you 397 support major version n, and major version m, you MUST support all 398 versions between n and m. If you receive a message with a major 399 version that you support, you MUST respond with that version number. 400 In order to prevent two nodes from being tricked into corresponding 401 with a lower major version number than the maximum that they both 402 support, IKE has a flag that indicates that the node is capable of 403 speaking a higher major version number. 405 Thus the major version number in the IKE header indicates the version 406 number of the message, not the highest version number that the 407 transmitter supports. If A is capable of speaking versions n, n+1, 408 and n+2, and B is capable of speaking versions n and n+1, then they 409 will negotiate speaking n+1, where A will set the flag indicating 410 ability to speak a higher version. If they mistakenly (perhaps 411 through an active attacker sending error messages) negotiate to 412 version n, then both will notice that the other side can support a 413 higher version number, and they MUST break the connection and 414 reconnect using version n+1. 416 Note that v1 does not follow these rules, because there is no way in 417 v1 of noting that you are capable of speaking a higher version 418 number. So an active attacker can trick two v2-capable nodes into 419 speaking v1. Given the design of v1, there is no way of preventing 420 this, but this version number discipline will prevent such problems 421 in future versions. 423 Also for forward compatibility, all fields marked RESERVED MUST be 424 set to zero by a version 2.0 implementation and their content MUST be 425 ignored by a version 2.0 implementation ("Be conservative in what you 426 send and liberal in what you receive"). In this way, future versions 427 of the protocol can use those fields in a way that is guaranteed to 428 be ignored by implementations that do not understand them. 429 Similarly, field types that are not defined are reserved for future 430 use and implementations of version 2.0 MUST skip over those fields 431 and ignore their contents. 433 IKEv2 adds a "critical" flag to each payload header for further 434 flexibility for forward compatibility. If the critical flag is set 435 and the payload type is unsupported, the message MUST be rejected and 436 the response to the IKE request containing that payload MUST include 437 a notify payload INVALID-PAYLOAD-TYPE, indicating an unsupported 438 critical payload was included. If the critical flag is not set and 439 the payload type is unsupported, that payload is simply skipped. 441 2.6 Cookies 443 The term "cookies" originates with Karn and Simpson [RFC 2522] in 444 Photurus, an early proposal for key managment with IPsec. It has 445 persisted because the IETF has never rejected an offer involving 446 cookies. In IKEv2, the cookies serve two purposes. First, they are 447 used as IKE-SA identifiers in the headers of IKE messages. As with 448 ESP and AH, in IKEv2 the recipient of a message chooses an IKE-SA 449 identifier that uniquely defines that SA to that recipient. For this 450 purpose (IKE-SA identifiers), it might be convenient for the cookie 451 value to be chosen so as to be a table index for fast lookups of SAs. 452 But this conflicts with the second purpose of the cookies (to be 453 explained shortly). 455 Unlike ESP and AH where only the recipient's SA identifier appears in 456 the message, in IKE, the sender's IKE SA identifier is also sent in 457 every message. In IKEv1 the IKE-SA identifier consisted of the pair 458 (Initiator cookie, Responder cookie), whereas in IKEv2, the SA is 459 uniquely defined by the recipient's SA identifier even though both 460 are included in the IKEv2 header. 462 The second use of cookies in IKEv2 is for a limited protection from 463 denial of service attacks. Receipt of a request to start an SA can 464 consume substantial resources. A likely denial of service attack 465 against IKE is to overwhelm a system with large numbers of SA 466 requests from forged IP addresses. This can consume CPU resources 467 doing the crypto, and memory resources remembering the state of the 468 "half open" connections until they time out. A robust design would 469 limit the resources it is willing to devote to new connection 470 establishment, but even so the denial of service attack could 471 effectively prevent any new connections. 473 This attack can be rendered more difficult by requiring that the 474 Responder to an SA request do minimal computation and allocate no 475 memory until the Initiator has proven that it can receive messages at 476 the address it claims to be sending from. This is done in a stateless 477 way by computing the cookie in a way that the Responder can recompute 478 the same value, but the Initiator can't guess it. A recommended 479 strategy is to compute the cookie as a cryptographic hash of the 480 Initiator's IP address, the Initiator's cookie value (its chosen IKE 481 security identifier), and a secret known only to the Responder. That 482 secret should be changed periodically to prevent the "cookie jar" 483 attack where an attacker accumulates lots of cookies from lots of IP 484 addresses over time and then replays them all at once to overwhelm 485 the Responder. 487 In ISAKMP and IKEv1, the term cookie was used for the connection 488 identifier, but the protocol did not permit their use against this 489 particular denial of service attack. To avoid the cookie exchange 490 adding extra messages to the protocol in the common case where the 491 Responder is not under attack, IKEv2 goes back to the approach in 492 Oakley (RFC 2412) where the cookie challenge is optional. Upon 493 receipt of an IKE_SA_init, a Responder may either proceed with 494 setting up the SA or may tell the Initiator to send another 495 IKE_SA_init, this time providing a supplied cookie. 497 It may be convenient for the IKE-SA identifier to be an index into a 498 table. It is not difficult for the Initiator to choose an IKE-SA 499 identifier that is convenient as a table identifier, since the 500 Initiator does not need to use it as an anti-clogging token, and is 501 keeping state. IKEv2 allows the Responder to initially choose a 502 stateless anti-clogging type cookie by responding to an IKE_SA_init 503 with a cookie request, and then upon receipt of an IKE_SA_init with a 504 valid cookie, change his cookie value from the computed anti-clogging 505 token to a more convenient value, by sending a different value for 506 his cookie in the IKE_SA_init_response. This will not confuse the 507 Initiator (Alice), because she will have chosen a unique cookie value 508 A, so if her SA state for the partially set up IKE-SA says that Bob's 509 cookie for the SA that Alice knows as "A" is B, and she receives a 510 response from Bob with cookies (A,C), that means that Bob wants to 511 change his value from B to C for the SA that Alice knows uniquely as 512 "A". 514 Another reason why Bob might want to change his cookie value is that 515 it is possible (though unlikely) that Bob will choose the same cookie 516 for multiple SAs if the hash of the Initiator cookie, Initiator IP 517 address, and whatever other information might be included happens to 518 hash to the same value. 520 In IKEv2, like IKEv1, both 8-byte cookies appear in the message, but 521 in IKEv2 (unlike v1), the value chosen by the message recipient 522 always appears first in the message. This change eliminates a flaw in 523 IKEv1, as well as having other advantages (allowing the recipient to 524 look up the SA based on a small, conveniently chosen value rather 525 than a 16-byte pseudorandom value.) 527 The flaw in IKEv1 is that it was possible (though unlikely) for two 528 connections to have the same set of cookies. For instance, if Alice 529 chose A as the Initiator cookie when initiating a connection to Bob, 530 she might subsequently receive a connection request from Carol, and 531 Carol might also have chosen A as the Initiator cookie. Whatever 532 value Alice responds to Carol, say B, might be selected as the 533 Responder cookie by Bob for the Alice-Bob SA. Then Alice would be 534 involved in two IKE sessions, both of which had Initiator cookie=A 535 and Responder cookie=B. To minimize, but not eliminate, the 536 probability of this happening, version 1 IKE recommended that cookies 537 be chosen at random. 539 One additional rule in IKEv2 is that the two cookie values have to be 540 different. The Responder is responsible for choosing a value 541 different from the one chosen by the Initiator. If the Responder's 542 stateless cookie happens to be equal to the Initiator's cookie, that 543 is legal provided that the Responder change his cookie value to 544 something different from the Initiator's in his IKE_SA_init_response. 545 The reason the cookies must be different in the two directions is to 546 prevent reflection attacks. Another way reflection attacks could have 547 been avoided was to compute different integrity and encryption keys 548 in the two directions, but that would be another change from IKEv1. 550 The cookies are one of the inputs into the function that computes the 551 keying material. If the Responder initially sends a stateless cookie 552 value in its IKE_SA_init_reject, and changes to a different value 553 when it sends its IKE_SA_init_response, it is the cookie value in the 554 IKE_SA_init_response that is the input for generating the keying 555 material. 557 2.7 Cryptographic Algorithm Negotiation 559 The payload type known as "SA" indicates a proposal for a set of 560 choices of protocols (e.g., IKE, ESP, AH, and/or IPcomp) for the SA 561 as well as cryptographic algorithms associated with each protocol. In 562 IKEv1 it was extremely complex, and required a separate proposal for 563 each possible combination. If there were n algorithms of one type 564 (say encryption) that were acceptable and worked with any one of m 565 algorithms of another type (say integrity protection), then it would 566 take space proportional to n*m to express all of the possibilities. 568 IKEv2 has simplified the format of the SA payload somewhat, but in 569 addition to simplifying the format, solves the exponential explosion 570 by allowing, within a proposal, multiple algorithms of the same type. 571 If more than one algorithm of the same type (say encryption) appears 572 in a proposal, that means that the sender of that SA proposal is 573 willing to accept the proposal with any of those choices, and the 574 recipient when it accepts the proposal selects exactly one of each of 575 the types of algorithms from the choices offered within that 576 proposal. 578 An SA consists of one or more proposals. Each proposal has a number 579 (so that the recipient can specify which proposal has been accepted), 580 and contains a protocol (IKE, ESP, AH, or IPcomp), a SPI to identify 581 the SA for ESP or AH or IPcomp, and set of transforms. Each transform 582 consists of a type (e.g., encryption, integrity protection, 583 authentication, Diffie-Hellman group, compression) and a transform ID 584 (e.g., DES, IDEA, HMAC-MD5). To negotiate an SA that does ESP, 585 IPcomp, and AH, the SA will contain three proposals with the same 586 proposal number, one proposing ESP, a 4 byte SPI to be used with ESP, 587 and a set of transforms; one proposing AH, a 4-byte SPI to be used 588 with AH, and a set of transforms; and one proposing IPcomp, a 2-byte 589 SPI to be used with IPcomp, and a set of transforms. If the recipient 590 selects that proposal number, it means that SAs will be created for 591 all of ESP, AH, and IPcomp. 593 In IKEv2, since the Initiator sends her Diffie-Hellman value in the 594 IKE_SA_init, she must guess at the Diffie-Hellman group that Bob will 595 select from her list of supported groups. Her guess MUST be the first 596 in the list to allow Bob to unambiguously identify which group the 597 accompanying KE payload is from. If her guess is incorrect then Bob's 598 response informs her of the group he would choose, and notifies her 599 that her offer is invalid because the KE payload is not from the 600 desired group. In this case Alice will send a new IKE_SA_init, with 601 the same original choices in the list (this is important to prevent 602 an active attacker from tricking them into using a weaker group than 603 they would have agreed upon) but with Bob's preferred group first, 604 and a KE payload containing an exponential from that group. 606 If none of Alice's options are acceptable, then Bob notifies her 607 accordingly. 609 2.8 Rekeying 611 Security associations negotiated in both phase 1 and phase 2 contain 612 secret keys which may only be used for a limited amount of time. This 613 determines the lifetime of the entire security association. When the 614 lifetime of a security association expires the security association 615 MUST NOT be used. If there is demand, new security associations can 616 be established. Reestablishment of security associations to take the 617 place of ones which expire is referred to as "rekeying". 619 To rekey a child-SA, create a new, equivalent SA (see section 4 and 620 4.1 below), and when the new one is established, delete the old one. 621 To rekey an IKE-SA, establish a new equivalent IKE-SA (see section 4 622 and 4.2 below) with the peer to whom the old IKE-SA is shared using a 623 Phase 2 negotiation within the existing IKE-SA. An IKE-SA so created 624 inherits all of the original IKE-SA's child SAs. Use the new IKE-SA 625 for all control messages needed to maintain the child-SAs created by 626 the old IKE-SA, and delete the old IKE-SA. 628 SAs SHOULD be rekeyed proactively, i.e., the new SA should be 629 established before the old one expires and becomes unusable. Enough 630 time should elapse between the time the new SA is established and the 631 old one becomes unusable so that traffic can be switched over to the 632 new SA. 634 A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes 635 were negotiated. In IKEv2, each end of the SA is responsible for 636 enforcing its own lifetime policy on the SA and rekeying the SA when 637 necessary. If the two ends have different lifetime policies, the end 638 with the shorter lifetime will end up always being the one to request 639 the rekeying. 641 If the two ends have the same lifetime policies, it is possible that 642 both will initiate a rekeying at the same time (which will result in 643 redundant SAs). To reduce the probability of this happening, the 644 timing of rekeying requests should be dithered (delayed by a random 645 amount of time). 647 This form of rekeying will temporarily result in multiple similar SAs 648 between the same pairs of nodes. When there are two SAs eligible to 649 receive packets, a node MUST accept incoming packets through either 650 SA. The node that initiated the rekeying SHOULD delete the older SA 651 after the new one is established. 653 2.9 Traffic Selector Negotiation 655 When an IP packet is received by an RFC2401 compliant IPsec subsystem 656 and matches a "protect" selector in its SPD, the subsystem MUST 657 protect that packet with IPsec. When no SA exists yet it is the task 658 of IKE to create it. Information about the traffic that needs 659 protection is transmitted to the IKE subsystem in a manner outside 660 the scope of this document (see [PFKEY] for an example). This 661 information is negotiated between the two IKE endpoints using TS 662 (Traffic Selector) payloads. 664 The TS payload consists of a set of individual traffic selectors. 665 The selector from the SPD has "source" and "destination" components 666 and these are represented in IKE as a pair of TS payloads, TSi 667 (traffic selector-initiator) and TSr (traffic selector-responder). 669 TSi describes the addresses and ports that the Initiator will send 670 from over the SA and which it will accept packets for. TSr describes 671 the addresses and ports that the Initiator will sent to over the SA 672 and which it will accept packets from. 674 The Responder is allowed to narrow the choices by selecting a subset 675 of the traffic, for instance by eliminating one or more members of 676 the set of traffic selectors provided the set does not become the 677 NULL set. 679 Note that the traffic selectors apply to both child-SAs (from the 680 Initiator to the Responder and from the Responder to the Initiator), 681 but the Responder does not change the order of the TS payloads. An 682 address within the selector of TSi would appear as a source address 683 in the child-SA from the Initiator, and would appear as a destination 684 address in traffic on the child-SA to the Initiator (from the 685 Responder). 687 IKEv2 is more flexible than IKEv1. IKEv2 allows sets of ranges of 688 both addresses and ports, and allows the Responder to choose a subset 689 of the requested traffic rather than simply responding "not 690 acceptable". 692 2.10 Nonces 694 The IKE_SA_init_request and the IKE_SA_init_response each contain a 695 nonce. These nonces are used as inputs to cryptographic functions. 696 The child-create-request and the child-create-response also contain a 697 nonce. These nonces are used to add freshness to the key derivation 698 technique used to obtain keys for child SAs. Nonces used in IKEv2 699 MUST therefore have strong pseudo-random properties (see RFC1715). 701 3 The Phase 1 Exchange 703 The base Phase 1 exchange is a four message exchange (two 704 request/response pairs). The first pair of messages, the IKE_SA_init 705 exchange, negotiate cryptographic algorithms, indicate trusted CA 706 names, exchange nonces, and do a Diffie-Hellman exchange. This pair 707 might be repeated if the response indicates that none of the 708 cryptographic proposals are acceptable, or the Diffie-Hellman group 709 chosen by the Initiator for sending her Diffie-Hellman value is not 710 the group that the Responder would have chosen, of if the Responder 711 is under attack and will only answer IKE_SA_init requests containing 712 a valid returned cookie value. 714 The second pair of messages, the IKE_auth and the IKE_auth_response, 715 authenticate the previous messages, exchange identities and 716 certificates, and optionally also establish a child_SA. This pair of 717 messages is encrypted with a key established through the IKE_SA_init 718 exchange, so the identities are hidden from eavesdroppers. 720 In the following description, the payloads contained in the message 721 are indicated by names such as SA. The details of the contents of 722 each payload are described later. Payloads which may optionally 723 appear will be shown in brackets, such as [CERTREQ], would indicate 724 that optionally a certificate request payload can be included. The 725 certificate request payload indicates a CA name trusted by the 726 sender. If the sender trusts multiple CAs, it includes multiple 727 CERTREQ payloads, one for each trusted CA. 729 The Phase 1 exchange is as follows: 731 Initiator Responder 732 ----------- ----------- 733 HDR, SA, KE, Ni [,CERTREQ] --> 735 The SA payload states the cryptographic algorithms the Initiator 736 supports. The KE payload sends the Initiator's Diffie-Hellman value. 737 Ni is the Initiator's nonce, sent in an N payload. 739 <-- HDR, SA, KE, Nr [,CERTREQ] 741 The Responder chooses among the Initiator's cryptographic algorithms 742 and expresses that choice in the SA payload, completes the Diffie- 743 Hellman exchange with the KE payload, and sends its nonce in the N 744 payload (with an "r" to signify the Responder's nonce). 746 At this point in time each party generates SKEYSEED and its 747 derivatives. The following two messages, the SA_auth and 748 SA_auth_response, are encrypted (as indicated by the '*' following 749 the IKE header) and the encryption bit in the IKE header is set. 751 HDR*, ID, AUTH, [CERT,] 752 SA, TSi, TSr --> 754 The Initiator identifies herself with the ID payload, authenticates 755 herself to the Responder with the AUTH payload, optionally sends one 756 or more certificates, and begins negotiation of a child-SA using the 757 SA payload and the Traffic Selector payloads: TSi (which describes 758 sources of packets to be sent over the child-SA), and TSr (which 759 describes destinations of packets to be sent over the child-SA). The 760 protocol (ESP, AH, and/or IPcomp) and the SPI she wants to use to 761 identify her inbound child-SA are placed in the "protocol" and "SPI" 762 fields, respectively, in the SA payload. 764 <-- HDR*, ID, AUTH, [CERT,] 765 SA, TSi, TSr 767 The Responder identifies himself with an ID payload authenticates 768 himself with the AUTH payload, optionally sends one or more 769 certificates, and completes negotiation of a child-SA using the SA 770 payload. The Responder places the SPI he wants to use to identify his 771 inbound child-SA in the SA payload. The TSi and TSr, respectively, 772 describe the sources and destinations of packets to be sent over the 773 child-SA. These MUST be equal to, or a subset of, the ones suggested 774 by the Initiator. 776 3.1 Generating Keying Material for the IKE-SA 778 The shared secret information is computed as follows. A quantity 779 called SKEYSEED is calculated from the nonces exchanged during the 780 IKE_SA_init exchange, and the Diffie-Hellman shared secret 781 established during that exchange. SKEYSEED is used to calculate 782 three other secrets: SKEYSEED_d used for deriving new keys for the 783 child-SAs established with this IKE-SA; SKEYSEED_a used for 784 authenticating the component messages of subsequent exchanges; and 785 SKEYSEED_e used for encrypting (and of course decrypting) all 786 subsequent exchanges. SKEYSEED and its derivatives are computed as 787 follows: 789 SKEYSEED = prf(Ni | Nr, g^ir) 790 SKEYSEED_d = prf(SKEYSEED, g^ir | CKY-I | CKY-R | 0) 791 SKEYSEED_a = prf(SKEYSEED, SKEYSEED_d | g^ir | CKY-I | CKY-R | 1) 792 SKEYSEED_e = prf(SKEYSEED, SKEYSEED_a | g^ir | CKY-I | CKY-R | 2) 794 CKY-I and CKY-R are the Initiator's and Responder's cookie, 795 respectively, from the IKE header. g^ir is the shared secret from the 796 ephemeral Diffie-Hellman exchange. Ni and Nr are the nonces, 797 stripped of any headers. 0, 1, and 2 are represented by a single byte 798 containing the value 0, 1, or 2 (the values, not the ASCII 799 representation of the digits). prf is the "pseudo-random" 800 cryptographic function negotiated in the IKE-SA-init exchange. The 801 pseudo-random functions defined for IKE are HMAC_MD5 and HMAC_SHA, 802 defined in RFC 2104. 804 3.2 Authentication of the IKE-SA 806 The peers are authenticated by having each sign the concatenation of 807 the first two messages of the exchange. Optionally, they MAY include 808 a certificate or certificate chain providing evidence that the public 809 key they are using belongs to the name in the ID payload. The public 810 key signature will be computed using algorithms chosen by the signer, 811 most commonly an RSA-signed PKCS1-padded-SHA1-hash of the 812 concatenated messages or a DSS-signed SHA1-hash of the concatenated 813 messages. There is no requirement that the Initiator and Responder 814 sign with the same cryptographic algorithms. The choice of 815 cryptographic algorithms depends on the type of public key each has. 816 This type is either indicated in the certificate supplied or, if the 817 public keys were exchanged out of band, the key types must have been 818 similarly learned. 820 4 The CREATE-CHILD-SA (Phase 2) Exchange 822 A phase 2 exchange is one request/response pair, and can be used to 823 create or delete a child-SA, delete the IKE-SA, or deliver 824 information such as error conditions. It is encrypted and integrity 825 protected using the keys negotiated during the creation of the IKE- 826 SA. The two directions of flow use the same keys. 828 Messages are cryptographically protected using the cryptographic 829 algorithms and keys negotiated in the first two messages of the IKE 830 exchange using a syntax based on the encoding in ESP (see Appendix 831 B). Encryption uses a key derived from SKEYSEED_e; Integrity uses a 832 key derived from SKEYSEED_a. 834 Either side may initiate a phase 2 exchange. A child-SA is created by 835 sending a CREATE_CHILD_SA request. If PFS for the child-SA is 836 desired, the CREAT_CHILD_SA request contains KE payloads for an 837 additional Diffie-Hellman exchange. The keying material for the 838 child_SA is a function of SKEYSEED_d established during the 839 establishment of the IKE-SA, the nonces exchanged during the 840 CREATE_CHILD_SA exchange, and the Diffie-Hellman value, if KE 841 payloads are included in the CREATE_CHILD_SA exchange. If the Diffie- 842 Hellman group for the child-SA is desired to be different from the 843 group for the IKE-SA, then a Diffie-Hellman group transform MUST be 844 included in the SA payload. If it is absent, the Diffie-Hellman group 845 is assumed to be the same as the one in the IKE-SA. 847 The CREATE_CHILD_SA request contains: 849 Initiator Responder 850 ----------- ----------- 851 HDR*, SA, Ni, [KEi,] 852 TSi, TSr --> 854 The Initiator sends SA offer(s) in the SA payload(s), a nonce in the 855 Ni payload, optionally a Diffie-Hellman value in the KE payload, and 856 the proposed traffic selectors in the TSi and TSr payloads. The 857 message past the header is encrypted and the message including the 858 header is integrity protected using the cryptographic algorithms 859 negotiated in Phase 1. 861 The CREATE_CHILD_SA response contains: 863 <-- HDR*, SA, Nr, [KEr,] 864 TSi, TSr 866 The Responder replies (using the same Message ID to respond) with the 867 accepted offer in an SA payload, optionally a Diffie-Hellman value in 868 the KE payload, and the traffic selectors for traffic to be sent on 869 that SA in the TS payloads, which may be a subset of what the 870 Initiator of the child-SA proposed. 872 4.1 Generating Keying Material for IPsec SAs 874 Child-SAs are created either by being piggybacked on the phase 1 875 exchange, or in a phase 2 CREATE_CHILD_SA exchange. Keying material 876 for them is generated as follows: 878 KEYMAT = prf(SKEYSEED_d, protocol | SPId | Ns | Nd ) 880 For phase 2 exchanges with PFS the keying material is defined as: 882 KEYMAT = prf(SKEYSEED_d, g(p2)^ir | protocol | SPId | Ns | Nd ) 884 where g(p2)^ir is the shared secret from the ephemeral Diffie-Hellman 885 exchange of this phase 2 exchange. 887 In either case, "protocol", and "SPI", are from the SA payload that 888 contained the negotiated (and accepted) proposal, Ns is the body of 889 the Source's nonce payload (minus the generic header), and Nr is the 890 body of the Destination's nonce payload (minus the generic header). 892 A single child-SA negotiation results in two security associations-- 893 one inbound and one outbound. Different Nonces and SPIs for each SA 894 (one chosen by the Initiator, the other by the Responder) guarantee a 895 different key for each direction. The SPI chosen by the destination 896 of the SA and the Nonces (ordered source followed by destination) are 897 used to derive KEYMAT for that SA. 899 For situations where the amount of keying material desired is greater 900 than that supplied by the prf, KEYMAT is expanded by feeding the 901 results of the prf back into itself and concatenating results until 902 the required keying material has been reached. In other words, 904 KEYMAT = K1 | K2 | K3 | ... 905 where: 906 K1 = prf(SKEYSEED_d, [ g(p2)^ir | ] protocol | SPId | Ns | Nd) 907 K2 = prf(SKEYSEED_d, K1 | [ g(p2)^ir | ] protocol | SPId | Ns | Nd) 908 K3 = prf(SKEYSEED_d, K2 | [ g(p2)^ir | ] protocol | SPId | Ns | Nd) 909 etc. 911 This keying material (whether with PFS or without) MUST be used with 912 the negotiated SA. In the case of an ESP SA needing two keys for 913 encryption and authentication, the encryption key is taken from the 914 first bytes of KEYMAT and the authentication key is taken from the 915 next bytes. 917 4.2 Generating Keying Material for IKE-SAs from a create-child exchange 919 The create-child exchange can be used to re-key an existing IKE-SA 920 (see section 2.8). When used for this purpose the create-child 921 exchange MUST be done with the PFS option. New Initiator and 922 Responder cookies are supplied in the SPI fields. The TS payloads are 923 omitted when rekeying an IKE-SA. SKEYSEED for the new IKE-SA is 924 computed using SKEYSEED_d from the existing IKE-SA as follows: 926 SKEYSEED = prf(SKEYSEED_d (old), g(p2)^ir | 0 | CKY-I | CKY-R 927 | Ni | Nr) 929 where g(p2)^ir is the shared secret from the ephemeral Diffie-Hellman 930 exchange of this phase 2 exchange, CKY-I is the 8-byte "SPI" from the 931 SA payload in the CREATE_CHILD_SA request, CKY-R is the 8-byte "SPI" 932 from the SA payload in the CREATE_CHILD_SA response, and Ni and Nr 933 are the two nonces stripped of any headers. "0" is a single byte 934 containing the value zero (the protocol ID of IKE). 936 SKEYSEED_d, SKEYSEED_a, and SKEYSEED_e are computed from SKEYSEED as 937 specified in section 3.1. 939 5 Informational (Phase 2) Exchange 941 At various points during an IKE-SA, peers may desire to convey 942 control messages to each other regarding errors or notifications of 943 certain events. To accomplish this IKE defines a (reliable) 944 Informational exchange. Usually Informational exchanges happen 945 during phase 2 and are cryptographically protected with the IKE 946 exchange. 948 Control messages that pertain to an IKE-SA MUST be sent under that 949 IKE-SA. Control messages that pertain to Child-SAs MUST be sent under 950 the protection of the IKE-SA which generated them. 952 There are two cases in which there is no IKE-SA to protect the 953 information. One is in the response to an IKE_SA_init_request to 954 request a cookie or to refuse the SA proposal. This would be conveyed 955 in a Notify payload of the IKE_SA_init_response. 957 The other case in which there is no IKE-SA to protect the information 958 is when a packet is received with an unknown SPI. In that case the 959 notification of this condition will be sent in an informational 960 exchange that is cryptographically unprotected. 962 Messages in an Informational Exchange contain zero or more 963 Notification or Delete payloads. The Recipient of an Informational 964 Exchange request MUST send some response (else the Sender will assume 965 the message was lost in the network and will retransmit it). That 966 response can be a message with no payloads. Actually, the request 967 message in an Informational Exchange can also contain no payloads. 968 This is the expected way an endpoint can ask the other endpoint to 969 verify that it is alive. 971 ESP, AH, and IPcomp SAs always exist in pairs, with one SA in each 972 direction. When an SA is closed, both members of the pair MUST be 973 closed. When SAs are nested, as when data is encapsulated first with 974 IPcomp, then with ESP, and finally with AH between the same pair of 975 endpoints, all of the SAs (up to six) must be deleted together. To 976 delete an SA, an Informational Exchange with one or more delete 977 payloads is sent listing the SPIs (as known to the recipient) of the 978 SAs to be deleted. The recipient MUST close the designated SAs. 979 Normally, the reply in the Informational Exchange will contain delete 980 payloads for the paired SAs going in the other direction. There is 981 one exception. If by chance both ends of a set of SAs independently 982 decide to close them, each may send a delete payload and the two 983 requests may cross in the network. If a node receives a delete 984 request for SAs that it has already issued a delete request for, it 985 MUST delete the incoming SAs while processing the request and the 986 outgoing SAs while processing the response. In that case, the 987 responses MUST NOT include delete payloads for the deleted SAs, since 988 that would result in duplicate deletion and could in theory delete 989 the wrong SA. 991 A node SHOULD regard half open connections as anomalous and audit 992 their existence should they persist. Note that this specification 993 nowhere specifies time periods, so it is up to individual endpoints 994 to decide how long to wait. A node MAY refuse to accept incoming data 995 on half open connections but MUST NOT unilaterally close them and 996 reuse the SPIs. If connection state becomes sufficiently messed up, a 997 node MAY close the IKE-SA which will implicitly close all SAs 998 negotiated under it. It can then rebuild the SA's it needs on a clean 999 base under a new IKE-SA. 1001 The Informational Exchange is defined as: 1003 Initiator Responder 1004 ----------- ----------- 1005 HDR*, N, ..., D, ... --> 1006 <-- HDR*, N, ..., D, ... 1008 The processing of an Informational Exchange is determined by its 1009 component payloads. 1011 6 Error Handling 1013 There are many kinds of errors that can occur during IKE processing. 1014 If a request is received that is badly formatted or unacceptable for 1015 reasons of policy (e.g. no matching cryptographic algorithms), the 1016 response MUST contain a Notify payload indicating the error. If an 1017 error occurs outside the context of an IKE request (e.g. the node is 1018 getting ESP messages on a non-existent SPI), the node SHOULD initiate 1019 an Informational Exchange with a Notify payload describing the 1020 problem. 1022 Errors that occur before a cryptographically protected IKE-SA is 1023 established must be handled very carefully. There is a trade-off 1024 between wanting to be helpful in diagnosing a problem and responding 1025 to it and wanting to avoid being a dupe in a denial of service attack 1026 based on forged messages. 1028 If a node receives a message on UDP port 500 outside the context of 1029 an IKE-SA (and not a request to start one), it may be the result of a 1030 recent crash. If the message is marked as a response, the node MAY 1031 audit the suspicious event but MUST NOT respond. If the message is 1032 marked as a request, the node MAY audit the suspicious event and MAY 1033 send a response. If a response is sent, the response MUST be sent to 1034 the IP address from whence it came with the IKE cookies reversed in 1035 the header and the Message ID copied. The response MUST NOT be 1036 cryptographically protected and MUST contain a notify payload 1037 indicating the nature of the problem. 1039 A node receiving such a message MUST NOT respond and MUST NOT change 1040 the state of any existing SAs. The message might be a forgery or 1041 might be a response the genuine correspondent was tricked into 1042 sending. A node SHOULD treat such a message (and also a network 1043 message like ICMP destination unreachable) as a hint that there might 1044 be problems with SAs to that IP address and SHOULD initiate a 1045 liveness test for any such IKE-SA. An implementation SHOULD limit the 1046 frequency of such tests to avoid being tricked into participating in 1047 a denial of service attack. 1049 A node receiving a suspicious message from an IP address with which 1050 it has an IKE-SA MAY send an IKE notify payload in an IKE 1051 Informational exchange over that SA. The recipient MUST NOT change 1052 the state of any SA's as a result but SHOULD audit the event to aid 1053 in diagnosing malfunctions. A node MUST limit the rate at which it 1054 will send messages in response to unprotected messages. 1056 7 Header and Payload Formats 1058 7.1 The IKE Header 1060 IKE messages use UDP port 500, with one IKE message per UDP datagram. 1061 Information from the UDP header is largely ignored except that the IP 1062 addresses from the headers are reversed and used for return packets. 1063 Each IKE message begins with the IKE header, denoted HDR in this 1064 memo. Following the header are one or more IKE payloads each 1065 identified by a "Next Payload" field in the preceding payload. 1066 Payloads are processed in the order in which they appear in an IKE 1067 message by invoking the appropriate processing routine according to 1068 the "Next Payload" field in the IKE header and subsequently according 1069 to the "Next Payload" field in the IKE payload itself until a "Next 1070 Payload" field of zero indicates that no payloads follow. 1072 The Recipient SPI in the header identifies an instance of an IKE 1073 security association. It is therefore possible for a single instance 1074 of IKE to multiplex distinct sessions with multiple peers. 1076 The format of the IKE header is shown in Figure 1. 1077 1 2 3 1078 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 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 ! Recipient ! 1081 ! SPI (aka Cookie) ! 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 ! Sender ! 1084 ! SPI (aka Cookie) ! 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 ! Message ID ! 1089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 ! Length ! 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 ~ Initialization Vector ~ 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 Figure 1: IKE Header Format 1097 o Recipient SPI (aka Cookie) (8 bytes) - A value chosen by the 1098 recipient to identify a unique IKE security association. 1099 [NOTE: this is a deviation from ISAKMP and IKEv1, where the 1100 cookies were always sent with the Initiator of the IKE-SA's 1101 cookie first and the Responder's second. See section 2.6.] 1103 o Sender SPI (aka Cookie) (8 bytes) - A value chosen by the 1104 sender to identify a unique IKE security association. 1106 o Next Payload (1 byte) - Indicates the type of payload that 1107 immediately follows the header. The format and value of each 1108 payload is defined below. 1110 o Major Version (4 bits) - indicates the major version of the IKE 1111 protocol in use. Implementations based on this version of IKE 1112 MUST set the Major Version to 2. Implementations based on 1113 previous versions of IKE and ISAKMP MUST set the Major Version 1114 to 1. Implementations based on this version of IKE MUST reject 1115 (or ignore) messages containing a version number greater than 1116 2. 1118 o Minor Version (4 bits) - indicates the minor version of the 1119 IKE protocol in use. Implementations based on this version of 1120 IKE MUST set the Minor Version to 0. They MUST ignore the minor 1121 version number of received messages. 1123 o Exchange Type (1 byte) - indicates the type of exchange being 1124 used. This dictates the payloads sent in each message and 1125 message orderings in the exchanges. 1127 Exchange Type Value 1129 RESERVED 0 1130 Reserved for ISAKMP 1 - 31 1131 Reserved for IKEv1 32 - 33 1132 Phase One 34 1133 CREATE-CHILD-SA 35 1134 Informational 36 1135 Reserved for IKEv2+ 37-239 1136 Reserved for private use 240-255 1138 o Flags (1 byte) - indicates specific options that are set for 1139 the message. Presence of options are indicated by the 1140 appropriate bit in the flags field being set. The bits are 1141 defined LSB first, so bit 0 would be the least significant 1142 bit of the Flags byte. 1144 -- E(ncryption) (bit 0 of Flags) - If set, all payloads 1145 following the header are encrypted and integrity 1146 protected using the algorithms negotiated during 1147 session establishment and a key derived during the key 1148 exchange portion of IKE. If not set, the payloads are 1149 not protected. All payloads MUST be protected if a key 1150 has been negotiated and any unprotected payload may 1151 only be used to establish a new session or indicate a 1152 problem. 1154 -- C(ommit) (bit 1 of Flags) - This bit is defined by 1155 ISAKMP but not used by IKEv2. Implementations of IKEv2 1156 MUST clear this bit when sending and SHOULD ignore it 1157 in incoming messages. 1159 -- A(uthentication Only) (bit 2 of Flags) - This bit is 1160 defined by ISAKMP but not used by IKEv2. Implementations 1161 of IKEv2 MUST clear this bit when sending and SHOULD 1162 ignore it in incoming messages. 1164 -- I(nitiator) (bit 3 of Flags) - This bit MUST be set in 1165 messages sent by the Initiator of an exchange and MUST 1166 be cleared in messages sent by the Responder. It is 1167 used by the recipient to determine whether the message 1168 number should be interpreted in the context of its 1169 initiating state or its responding state. 1171 -- V(ersion) (bit 4 of Flags) - This bit indicates that 1172 the transmitter is capable of speaking a higher major 1173 version number of the protocol than the one indicated 1174 in the major version number field. 1176 -- R(eserved) (bits 5-7 of Flags) - These bit MUST be 1177 cleared in messages sent and received messages with 1178 these bits set MUST be rejected. 1180 o Message ID (4 bytes) - Message identifier used to control 1181 retransmission of lost packets and matching of requests and 1182 responses. See section 2.2. In the first message of a Phase 1 1183 negotiation, the value MUST be set to 0. The response to that 1184 message MUST also have a Message ID of 0. 1186 o Length (4 bytes) - Length of total message (header + payloads) 1187 in bytes. Session encryption can expand the size of an IKE 1188 message and that is reflected in the total length of the 1189 message. 1191 o Initialization Vector (variable) - random bytes used to provide 1192 initialization to an encryption mode-- e.g. 1193 cipher block chaining (CBC) mode. This field MUST be present 1194 when the encryption bit is set in the flags field (see below) 1195 and MUST NOT be present otherwise. The length of the 1196 Initialization Vector is cipher and mode dependent. 1198 7.2 Generic Payload Header 1200 Each IKE payload defined in sections 7.3 through 7.13 begins with a 1201 generic header, shown in Figure 2. Figures for each payload below 1202 will include the generic payload header but for brevity a repeat of 1203 the description of each field will be omitted. The construction and 1204 processing of the generic payload header is identical for each 1205 payload and will similarly be omitted. 1207 1 2 3 1208 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 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 ! Next Payload !C! RESERVED ! Payload Length ! 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 Figure 2: Generic Payload Header 1215 The Generic Payload Header fields are defined as follows: 1217 o Next Payload (1 byte) - Identifier for the payload type of the 1218 next payload in the message. If the current payload is the last 1219 in the message, then this field will be 0. This field provides 1220 a "chaining" capability whereby additional payloads can be 1221 added to a message by appending it to the end of the message 1222 and setting the "Next Payload" field of the preceding payload 1223 to indicate the new payload's type. 1225 o Critical (1 bit) - MUST be set to zero if the sender wants 1226 the recipient to skip this payload if he does not 1227 understand the payload type code. MUST be set to one if the 1228 sender wants the recipient to reject this entire message 1229 if he does not understand this payload type. MUST be ignored 1230 by recipient if the recipient understands the payload type 1231 code. MUST be set to zero for payload types defined in this 1232 document. Note that the critical bit applies to the current 1233 payload rather than the "next" payload whose type code 1234 appears in the first byte. 1236 o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored. 1238 o Payload Length (2 bytes) - Length in bytes of the current 1239 payload, including the generic payload header. 1241 7.3 Security Association Payload 1243 The Security Association Payload, denoted SA in this memo, is used to 1244 negotiate attributes of a security association. Assembly of Security 1245 Association Payloads requires great peace of mind. An SA may contain 1246 multiple proposals. Each proposal may contain multiple protocols 1247 (where a protocol is IKE, ESP, AH, or IPCOMP), each protocol may 1248 contain multiple transforms, and each transform may contain multiple 1249 attributes. When parsing an SA, an implementation MUST check that the 1250 total Payload Length is consistent with the payload's internal 1251 lengths and counts. Proposals, Transforms, and Attributes each have 1252 their own variable length encodings. They are nested such that the 1253 Payload Length of an SA includes the combined contents of the SA, 1254 Proposal, Transform, and Attribute information. The length of a 1255 Proposal includes the lengths of all Transforms and Attributes it 1256 contains. The length of a Transform includes the lengths of all 1257 Attributes it contains. 1259 The syntax of Security Associations, Proposals, Transforms, and 1260 Attributes is based on ISAKMP, however the semantics are somewhat 1261 different. The reason for the complexity and the hierarchy is to 1262 allow for multiple possible combinations of algorithms to be encoded 1263 in a single SA. Sometimes there is a choice of multiple algorithms, 1264 while other times there is a combination of algorithms. For example, 1265 an Initiator might want to propose using (AH w/MD5 and ESP w/3DES) OR 1266 (ESP w/MD5 and 3DES). 1268 One of the reasons the semantics of the SA payload has changed from 1269 ISAKMP and IKEv1 is to make the encodings more compact in common 1270 cases. 1272 The Proposal structure contains within it a Proposal # and a 1273 Protocol-id. Each structure MUST have the same Proposal # as the 1274 previous one or one greater. The first Proposal MUST have a Proposal 1275 # of one. If two successive structures have the same Proposal number, 1276 it means that the proposal consists of the first structure AND the 1277 second. So a proposal of AH AND ESP would have two proposal 1278 structures, one for AH and one for ESP and both would have Proposal 1279 #1. A proposal of AH OR ESP would have two proposal structures, one 1280 for AH with proposal #1 and one for ESP with proposal #2. 1282 Each Proposal/Protocol structure is followed by one or more transform 1283 structures. The number of different transforms is generally 1284 determined by the Protocol. AH generally has a single transform: an 1285 integrity check algorithm. ESP generally has two: an encryption 1286 algorithm AND an integrity check algorithm. IKE generally has five 1287 transforms: a Diffie-Hellman group, an authentication algorithm, an 1288 integrity check algorithm, a PRF algorithm, and an encryption 1289 algorithm. For each Protocol, the set of permissible transforms are 1290 assigned transform ID numbers, which appear in the header of each 1291 transform. 1293 If there are multiple transforms with the same Transform Type, the 1294 proposal is an OR of those transforms. If there are multiple 1295 Transforms with different Transform Types, the proposal is an AND of 1296 the different groups. For example, to propose ESP with (3DES or IDEA) 1297 and (HMAC-MD5 or HMAC-SHA), the ESP proposal would contain two 1298 Transform Type 1 candidates (one for 3DES and one for IDEA) and two 1299 Transform Type 2 candidates (one for HMAC-MD5 and one for HMAC-SHA). 1300 This effectively proposes four combinations of algorithms. If the 1301 Initiator wanted to propose only a subset of those - say (3DES and 1302 HMAC-MD5) or (IDEA and HMAC-SHA), there is no way to encode that as 1303 multiple transforms within a single Proposal/Protocol. Instead, the 1304 Initiator would have to construct two different Proposals, each with 1305 two transforms. 1307 A given transform MAY have one or more Attributes. Attributes are 1308 necessary when the transform can be used in more than one way, as 1309 when an encryption algorithm has a variable key size. The transform 1310 would specify the algorithm and the attribute would specify the key 1311 size. Most transforms do not have attributes. 1313 Note that the semantics of Transforms and Attributes are quite 1314 different than in IKEv1. In IKEv1, a single Transform carried 1315 multiple algorithms for a protocol with one carried in the Transform 1316 and the others carried in the Attributes. 1318 1 2 3 1319 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 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1321 ! Next Payload !C! RESERVED ! Payload Length ! 1322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1323 ! ! 1324 ~ ~ 1325 ! ! 1326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 Figure 3: Security Association Payload 1330 o Proposals (variable) - one or more proposal substructures. 1332 The payload type for the Security Association Payload is one (1). 1334 7.3.1 Proposal Substructure 1336 1 2 3 1337 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 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 ! 0 (last) or 2 ! RESERVED ! Proposal Length ! 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 ! Proposal # ! Protocol-Id ! SPI Size !# of Transforms! 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 ~ SPI (variable) ~ 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 ! ! 1346 ~ ~ 1347 ! ! 1348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1350 Figure 4: Proposal Substructure 1352 o 0 (last) or 2 (more) (1 byte) - Specifies whether this is the 1353 last Proposal Substructure in the SA. This syntax is inherited 1354 from ISAKMP, but is unnecessary because the last Proposal 1355 could be identified from the length of the SA. The value (2) 1356 corresponds to a Payload Type of Proposal, and the first 1357 four bytes of the Proposal structure are designed to look 1358 somewhat like the header of a Payload. 1360 o RESERVED (1 byte) - MUST be sent as zero; MUST be ignored. 1362 o Proposal Length (2 bytes) - Length of this proposal, 1363 including all transforms and attributes that follow. 1365 o Proposal # (1 byte) - When a proposal is made, the first 1366 proposal in an SA MUST be #1, and subsequent proposals 1367 MUST either be the same as the previous proposal (indicating 1368 an AND of the two proposals) or one more than the previous 1369 proposal (indicating an OR of the two proposals). When a 1370 proposal is accepted, all of the proposal numbers in the 1371 SA must be the same and must match the number on the 1372 proposal sent that was accepted. 1374 o Protocol-Id (1 byte) - Specifies the protocol identifier 1375 for the current negotiation. During phase 1 negotiation 1376 this field MUST be zero (0). During phase 2 it will be the 1377 protocol of the SA being established as assigned by IANA, 1378 for example, 50 for ESP, 51 for AH, and 108 for IPComp. 1380 o SPI Size (1 byte) - During phase 1 negotiation this field 1381 MUST be zero. During phase 2 negotiation it is equal to the 1382 size, in bytes, of the SPI of the corresponding protocol 1383 (4 for ESP and AH, 2 for IPcomp). 1385 o # of Transforms (1 byte) - Specifies the number of 1386 transforms in this proposal. 1388 o SPI (variable) - The sending entity's SPI. Even if the SPI 1389 Size is not a multiple of 4 bytes, there is no padding 1390 applied to the payload. When the SPI Size field is zero, 1391 this field is not present in the Security Association 1392 payload. This case occurs when negotiating the IKE-SA. 1394 o Proposal # (1 byte) - Identifies the immediate proposal. The 1395 first proposal has the number of one (1) and each subsequent 1396 proposal has a number which is one greater than the last. 1398 o Proposal Length (2 bytes) - Length in bytes of the proposal 1399 including all SA Attributes. 1401 o SA Attributes (variable length) - This field contains SA 1402 attributes for the immediate transform. The SA Attributes 1403 MUST be represented using the Transform Attributes format 1404 described below. 1406 o RESERVED (1 byte) - MUST be sent as zero; MUST be ignored. 1408 o Transforms (variable) - one or more transform substructures. 1410 7.3.2 Transform Substructure 1412 1 2 3 1413 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 1414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1415 ! 0 (last) or 3 ! RESERVED ! Transform Length ! 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 !Transform Type ! RESERVED2 ! Transform ID ! 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1419 ! ! 1420 ~ Transform Attributes ~ 1421 ! ! 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1424 Figure 5: Transform Substructure 1426 o 0 (last) or 3 (more) (1 byte) - Specifies whether this is the 1427 last Transform Substructure in the Proposal. This syntax is 1428 inherited from ISAKMP, but is unnecessary because the last 1429 Proposal could be identified from the length of the SA. The 1430 value (3) corresponds to a Payload Type of Transform, and 1431 the first four bytes of the Transform structure are designed 1432 to look somewhat like the header of a Payload. 1434 o RESERVED (1 byte) - MUST be sent as zero; MUST be ignored. 1436 o Transform Length - The length (in bytes) of the Transform 1437 Substructure including Header and Attributes. 1439 o Transform Type (1 byte) - The type of transform being specified 1440 in this transform. Different protocols support different 1441 transform types. For some protocols, some of the transforms 1442 may be optional. 1444 o Transform-ID (2 bytes) - The specific instance of the transform 1445 type being proposed. 1447 Transform Type Values 1449 Transform Used In 1450 Type 1451 Encryption Algorithm 1 (IKE and ESP) 1452 Pseudo-random Function 2 (IKE) 1453 Authentication Method 3 (IKE) 1454 Integrity Algorithm 4 (IKE, AH, and optional in ESP) 1455 Diffie-Hellman Group 5 (IKE and optional in AH and 1456 ESP) 1457 Compression 6 (IPcomp) 1458 Window Size 7 (IKE) 1460 values 8-240 are reserved to IANA. Values 241-255 are for 1461 private use among mutually consenting parties. 1463 For Transform Type 1 (Encryption Algorithm), defined Transform-IDs 1464 are: 1466 Name Number Defined In 1467 RESERVED 0 1468 ENCR_DES_IV64 1 (RFC1827) 1469 ENCR_DES 2 (RFC2405) 1470 ENCR_3DES 3 (RFC2451) 1471 ENCR_RC5 4 (RFC2451) 1472 ENCR_IDEA 5 (RFC2451) 1473 ENCR_CAST 6 (RFC2451) 1474 ENCR_BLOWFISH 7 (RFC2451) 1475 ENCR_3IDEA 8 (RFC2451) 1476 ENCR_DES_IV32 9 1477 ENCR_RC4 10 1478 ENCR_NULL 11 (RFC2410) 1479 ENCR_AES 12 1481 values 12-240 are reserved to IANA. Values 241-255 are for 1482 private use among mutually consenting parties. 1484 For Transform Type 2 (Pseudo-random Function), defined Transform-IDs 1485 are: 1487 Name Number Defined In 1488 RESERVED 0 1489 PRF_HMAC_MD5 1 (RFC2104) 1490 PRF_HMAC_SHA 2 (RFC2104) 1491 PRF_HMAC_TIGER 3 (RFC2104) 1493 values 3-240 are reserved to IANA. Values 241-255 are for 1494 private use among mutually consenting parties. 1496 For Transform Type 3 (Authentication Method), defined Transform-IDs 1497 are: 1499 Name Number Defined In 1500 RESERVED 0 1501 Methods in IKEv1 1 - 5 (RFC2409) 1502 Authenticated Diffie-Hellman 6 (this memo) 1504 values 7-240 are reserved to IANA. Values 241-255 are for 1505 private use among mutually consenting parties. 1507 For Transform Type 4 (Integrity Algorithm), defined Transform-IDs 1508 are: 1510 Name Number Defined In 1511 RESERVED 0 1512 AUTH_HMAC_MD5 1 (RFC2403) 1513 AUTH_HMAC_SHA 2 (RFC2404) 1514 AUTH_DES_MAC 3 1515 AUTH_KPDK_MD5 4 (RFC1826) 1517 For Transform Type 5 (Diffie-Hellman Group), defined Transform-IDs 1518 are: 1520 Name Number 1521 RESERVED 0 1522 Pre-defined (see section 8) 1 - 5 1523 RESERVED 6 - 200 1524 MODP (exponentiation) 201 (w/attributes) 1525 ECP (elliptic curve over GF[P] 202 (w/attributes) 1526 EC2N (elliptic curve over GF[2^N]) 203 (w/attributes) 1528 values 6-200 are reserved to IANA for new MODP, ECP or EC2N 1529 groups. Values 204-255 are for private use among mutually 1530 consenting parties. Specification of values 201, 202 or 203 1531 allow peers to define a new Diffie-Hellman group in-line as 1532 part of the exchange. Private use of values 204-255 may entail 1533 complete definition of a group or may require attributes to 1534 accompany them. Attributes MUST NOT accompany groups using 1535 values between 6 and 200. 1537 For Transform Type 6 (Compression), defined Transform-IDs are: 1539 Name Number Defined In 1540 RESERVED 0 1541 IPCOMP_OUI 1 (w/attributes) 1542 IPCOMP_DEFLATE 2 1543 (RFC2394) 1544 IPCOMP_LZS 3 1545 (RFC2395) 1547 values 4-240 are reserved to IANA. Values 241-255 are for 1548 private use among mutually consenting parties. 1550 For Transform Type 7 (Window Size), the Transform-ID specifies the 1551 window size a peer is contracting to support to handle overlapping 1552 requests (see section 2.3). 1554 7.3.3 Mandatory Transform Types 1556 The number and type of transforms that accompany an SA payload are 1557 dependent on the protocol in the SA itself. An SA payload proposing 1558 the establishment of an SA has the following mandatory and optional 1559 transform types. A compliant implementation MUST support all 1560 mandatory and optional types for each protocol it supports. Whether 1561 the optional types are present in a particular proposal depends 1562 solely on the discretion of the sender. 1564 Protocol Mandatory Types Optional Types 1565 IKE 1, 2, 3, 5, 7 1566 ESP 1 4, 5 1567 AH 4 5 1568 IPCOMP 6 1570 7.3.4 Mandatory Transform-IDs 1572 Each transform type has corresponding transform IDs to specify the 1573 specific transform. Some transforms are mandatory to support and 1574 others are optional to support. The mandatory transform IDs for AH, 1575 ESP, and IPCOMP are left to their respective RFCs, RFC2402, RFC2406, 1576 and RFC2393. The transform IDs that are mandatory to support for 1577 IKEv2 are: 1579 Name TransType Mandatory Transform-ID 1580 Encryption Algorithm 1 12 (ENCR_AES) 1581 Pseudo-Random Function 2 2 (PRF_HMAC_SHA) 1582 Authentication Method 3 6 (signed D-H) 1583 Diffie-Hellman Group 5 5 (1536 bit MODP) 1584 Window Size 7 1 1586 All other transform-IDs for a given transform type are optional to 1587 support. While implementations MUST have a window size of at least 1 1588 they SHOULD support a window size of at least 10 and MAY support 1589 larger window sizes. 1591 7.3.4 Transform Attributes 1593 Each transform in a Security Association payload may include 1594 attributes that modify or complete the specification of the 1595 transform. These attributes are type/value pairs and are defined in 1596 Appendix A. For example, if an encryption algorithm has a variable 1597 length key, the key length to be used may be specified as an 1598 attribute. Attributes can have a value with a fixed two byte length 1599 or a variable length value. For the latter the attribute is the form 1600 of type/length/value. 1602 1 2 3 1603 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 1604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1605 !A! Attribute Type ! AF=0 Attribute Length ! 1606 !F! ! AF=1 Attribute Value ! 1607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1608 ! AF=0 Attribute Value . 1609 ! AF=1 Not Transmitted . 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1612 Figure 6: Data Attributes 1614 o Attribute Type (2 bytes) - Unique identifier for each type of 1615 attribute. The identifiers for IKE are defined in Appendix A. 1617 The most significant bit of this field is the Attribute Format 1618 bit (AF). It indicates whether the data attributes follow the 1619 Type/Length/Value (TLV) format or a shortened Type/Value (TV) 1620 format. If the AF bit is zero (0), then the Data Attributes 1621 are of the Type/Length/Value (TLV) form. If the AF bit is a 1622 one (1), then the Data Attributes are of the Type/Value form. 1624 o Attribute Length (2 bytes) - Length in bytes of the Attribute 1625 Value. When the AF bit is a one (1), the Attribute Value is 1626 only 2 bytes and the Attribute Length field is not present. 1628 o Attribute Value (variable length) - Value of the Attribute 1629 associated with the Attribute Type. If the AF bit is a 1630 zero (0), this field has a variable length defined by the 1631 Attribute Length field. If the AF bit is a one (1), the 1632 Attribute Value has a length of 2 bytes. 1634 7.3.5 Attribute Negotiation 1636 During security association negotiation Initiators present offers to 1637 Responders. Responders MUST select a single complete set of 1638 parameters from the offers (or reject all offers if none are 1639 acceptable). If there are multiple proposals, the Responder MUST 1640 choose a single proposal number and return all of the Proposal 1641 substructures with that Proposal number. If there are multiple 1642 Transforms with the same type the Responder MUST choose a single one. 1643 Any attributes of a selected transform MUST be returned unmodified. 1644 The Initiator of an exchange MUST check that the accepted offer is 1645 consistent with one of its proposals, and if not that response MUST 1646 be rejected. 1648 Negotiating Diffie-Hellman groups presents some special challenges. 1649 Diffie-Hellman groups are specified either using a defined group 1650 description (section 5) or by defining all attributes of a group (see 1651 Appendix A) in an IKE policy offer. Group attributes, such as group 1652 type or prime number MUST NOT be offered in conjunction with a 1653 previously defined group. SA offers include proposed attributes and a 1654 Diffie-Hellman public number (KE) in the same message. If the 1655 Initiator offers to use one of several Diffie-Hellman groups, it 1656 SHOULD pick the one the Responder is most likely to accept and 1657 include a KE corresponding to that group. If the guess turns out to 1658 be wrong, the Responder will indicate the correct group in the 1659 response and the Initiator SHOULD start over this time using a 1660 different group (see section 2.7). 1662 Implementation Note: 1664 Certain negotiable attributes can have ranges or could have 1665 multiple acceptable values. These are the Diffie-Hellman group and 1666 the key length of a variable key length symmetric cipher. To 1667 further interoperability and to support upgrading endpoints 1668 independently, implementers of this protocol SHOULD accept values 1669 which they deem to supply greater security. For instance if a peer 1670 is configured to accept a variable lengthed cipher with a key 1671 length of X bits and is offered that cipher with a larger key 1672 length an implementation SHOULD accept the offer. 1674 Support of this capability allows an implementation to express a 1675 concept of "at least" a certain level of security-- "a key length 1676 of _at least_ X bits for cipher foo". 1678 7.4 Key Exchange Payload 1680 The Key Exchange Payload, denoted KE in this memo, is used to 1681 exchange Diffie-Hellman public numbers as part of a Diffie-Hellman 1682 key exchange. The Key Exchange Payload consists of the IKE generic 1683 header followed by the Diffie-Hellman public value itself. 1685 1 2 3 1686 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 1687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1688 ! Next Payload !C! RESERVED ! Payload Length ! 1689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1690 ! ! 1691 ~ Key Exchange Data ~ 1692 ! ! 1693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1695 Figure 7: Key Exchange Payload Format 1697 A key exchange payload is constructed by copying one's Diffie-Hellman 1698 public value into the "Key Exchange Data" portion of the payload. 1699 The length of the Diffie-Hellman public value MUST be equal to the 1700 length of the prime modulus over which the exponentiation was 1701 performed, prepending zero bits to the value if necessary. 1703 A key exchange payload is processed by first checking whether the 1704 length of the key exchange data (the "Payload Length" from the 1705 generic header minus the size of the generic header) is equal to the 1706 length of the prime modulus over which the exponentiation was 1707 performed. 1709 The payload type for the Key Exchange payload is four (4). 1711 7.5 Identification Payload 1713 The Identification Payload, denoted ID in this memo, allows peers to 1714 identify themselves to each other. In Phase 1, the ID Payload names 1715 the identity to be authenticated with the signature. In Phase 2, the 1716 ID Payload is optional and if present names an identity asserted to 1717 be responsible for this SA. An example use would be a shared computer 1718 opening an IKE-SA to a server and asserting the name of its logged in 1719 user for the Phase 2 SA. If missing, this defaults to the Phase 1 1720 identity. 1722 NOTE: In IKEv1, two ID payloads were used in each direction in Phase 1723 2 to hold Traffic Selector information for data passing over the SA. 1724 In IKEv2, this information is carried in Traffic Selector (TS) 1725 payloads (see section 7.13). 1727 The Identification Payload consists of the IKE generic header 1728 followed by identification fields as follows: 1730 1 2 3 1731 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 1732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1733 ! Next Payload !C! RESERVED ! Payload Length ! 1734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1735 ! ID Type ! RESERVED | 1736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1737 ! ! 1738 ~ Identification Data ~ 1739 ! ! 1740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1742 Figure 8: Identification Payload Format 1744 o ID Type (1 byte) - Specifies the type of Identification being 1745 used. 1747 o RESERVED - MUST be sent as zero; MUST be ignored. 1749 o Identification Data (variable length) - Value, as indicated by 1750 the Identification Type. The length of the Identification Data 1751 is computed from the size in the ID payload header. 1753 The payload type for the Identification Payload is five (5). 1755 The following table lists the assigned values for the Identification 1756 Type field, followed by a description of the Identification Data 1757 which follows: 1759 ID Type Value 1760 ------- ----- 1761 RESERVED 0 1763 ID_IPV4_ADDR 1 1765 A single four (4) byte IPv4 address. 1767 ID_FQDN 2 1769 A fully-qualified domain name string. An example of a 1770 ID_FQDN is, "lounge.org". The string MUST not contain any 1771 terminators (e.g. NULL, CR, etc.). 1773 ID_USER_FQDN 3 1775 A fully-qualified username string, An example of a 1776 ID_USER_FQDN is, "lizard@lounge.org". The string MUST not 1777 contain any terminators. 1779 ID_IPV6_ADDR 5 1781 A single sixteen (16) byte IPv6 address. 1783 ID_DER_ASN1_DN 9 1785 The binary DER encoding of an ASN.1 X.500 Distinguished Name 1786 [X.501]. 1788 ID_DER_ASN1_GN 10 1790 The binary DER encoding of an ASN.1 X.500 GeneralName 1791 [X.509]. 1793 ID_KEY_ID 11 1795 An opaque byte stream which may be used to pass vendor- 1796 specific information necessary to do certain proprietary 1797 forms of identification. 1799 7.6 Certificate Payload 1801 The Certificate Payload, denoted CERT in this memo, provides a means 1802 to transport certificates or other certificate-related information 1803 via IKE. Certificate payloads SHOULD be included in an exchange if 1804 certificates are available to the sender. 1806 The Certificate Payload is defined as follows: 1808 1 2 3 1809 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 1810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1811 ! Next Payload !C! RESERVED ! Payload Length ! 1812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1813 ! Cert Encoding ! ! 1814 +-+-+-+-+-+-+-+-+ ! 1815 ~ Certificate Data ~ 1816 ! ! 1817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1819 Figure 9: Certificate Payload Format 1821 o Certificate Encoding (1 byte) - This field indicates the type 1822 of certificate or certificate-related information contained 1823 in the Certificate Data field. 1825 Certificate Encoding Value 1826 -------------------- ----- 1827 NONE 0 1828 PKCS #7 wrapped X.509 certificate 1 1829 PGP Certificate 2 1830 DNS Signed Key 3 1831 X.509 Certificate - Signature 4 1832 X.509 Certificate - Key Exchange 5 1833 Kerberos Tokens 6 1834 Certificate Revocation List (CRL) 7 1835 Authority Revocation List (ARL) 8 1836 SPKI Certificate 9 1837 X.509 Certificate - Attribute 10 1838 RESERVED 11 - 255 1840 o Certificate Data (variable length) - Actual encoding of 1841 certificate data. The type of certificate is indicated 1842 by the Certificate Encoding field. 1844 The payload type for the Certificate Payload is six (6). 1846 7.7 Certificate Request Payload 1848 The Certificate Request Payload, denoted CERTREQ in this memo, 1849 provides a means to request preferred certificates via IKE and can 1850 appear in the first, second, or third message of Phase 1. 1851 Certificate Request payloads SHOULD be included in an exchange 1852 whenever the peer may have multiple certificates, some of which might 1853 be trusted while others are not. If multiple root CA's are trusted, 1854 then multiple Certificate Request payloads SHOULD be transmitted. 1856 The Certificate Payload is defined as follows: 1858 1 2 3 1859 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 1860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1861 ! Next Payload !C! RESERVED ! Payload Length ! 1862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1863 ! Cert Encoding ! ! 1864 +-+-+-+-+-+-+-+-+ ! 1865 ~ Certification Authority ~ 1866 ! ! 1867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1869 Figure 10: Certificate Request Payload Format 1871 o Certificate Encoding (1 byte) - Contains an encoding of the type 1872 of certificate requested. Acceptable values are listed in 1873 section 7.6. 1875 o Certification Authority (variable length) - Contains an encoding 1876 of an acceptable certification authority for the type of 1877 certificate requested. 1879 The payload type for the Certificate Request Payload is seven (7). 1881 The Certificate Request Payload is constructed by setting the "Cert 1882 Encoding" field to be the type of certificate being desired and the 1883 "Certification Authority" field to a proper encoding of a 1884 certification authority for the specified certificate. For example, 1885 for an X.509 certificate this field would contain the Distinguished 1886 Name encoding of the Issuer Name of an X.509 certification authority 1887 acceptable to the sender of this payload. 1889 The Certificate Request Payload is processed by inspecting the "Cert 1890 Encoding" field to determine whether the processor has any 1891 certificates of this type. If so the "Certification Authority" field 1892 is inspected to determine if the processor has any certificates which 1893 can be validated up to the specified certification authority. This 1894 can be a chain of certificates. If a certificate exists which 1895 satisfies the criteria specified in the Certificate Request Payload 1896 it MUST be sent back to the certificate requestor; if a certificate 1897 chain exists which goes back to the certification authority specified 1898 in the request the entire chain MUST be sent back to the certificate 1899 requestor. If no certificates exist then no further processing is 1900 performed-- this is not an error condition of the protocol. 1902 7.8 Authentication Payload 1904 The Authentication Payload, denoted AUTH in this memo, contains data 1905 used for authentication purposes. The only authentication method 1906 defined in this memo is digital signatures and therefore the contents 1907 of this payload when used with this memo will be the output generated 1908 by a digital signature function. 1910 The Authentication Payload is defined as follows: 1912 1 2 3 1913 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 1914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1915 ! Next Payload !C! RESERVED ! Payload Length ! 1916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1917 ! ! 1918 ~ Authentication Data ~ 1919 ! ! 1920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1921 Figure 11: Authentication Payload Format 1923 o Authentication Data (variable length) - Data that results from 1924 applying the digital signature function to the IKE state 1925 (see section 3). 1927 The payload type for the Authentication Payload is nine (9). 1929 The Authentication Payload is constructed by computing a digital 1930 signature over the concatentation of the two IKE messages in the 1931 initial unprotected IKE-SA-INIT exchange and placing the result in 1932 the "Authentication Data" portion of the payload. The signature MUST 1933 be a PKCS#1 encoded signature using the cryptographic hash and 1934 signature algorithms chosen by the signer. The algorithms used by 1935 the two ends MAY be different. The payload length is the size of the 1936 generic header plus the size of the "Authentication Data" portion of 1937 the payload which depends on the specific digital signature algorithm 1938 being used. 1940 The Authentication Payload is processed by extracting the 1941 "Authentication Data" from the payload and verifying it according to 1942 the specific digital signature being used. If authentication fails a 1943 NOTIFY Error message of AUTHENTICATION-FAILED MUST be sent back to 1944 the peer and the connection closed. 1946 7.9 Nonce Payload 1948 The Nonce Payload, denoted Ni and Nr in this memo for the Initiator's 1949 and Responder's nonce respectively, contains random data used to 1950 guarantee liveness during an exchange and protect against replay 1951 attacks. 1953 The Nonce Payload is defined as follows: 1955 1 2 3 1956 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 1957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1958 ! Next Payload !C! RESERVED ! Payload Length ! 1959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1960 ! ! 1961 ~ Nonce Data ~ 1962 ! ! 1963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1965 Figure 12: Nonce Payload Format 1967 o Nonce Data (variable length) - Contains the random data generated 1968 by the transmitting entity. 1970 The payload type for the Nonce Payload is ten (10). 1972 The Nonce Payload is constructed by computing a pseudo-random value 1973 and copying it into the "Nonce Data" field. The size of a Nonce in 1974 this memo must be between eight (8) and two-hundred fifty-six (256) 1975 bytes inclusive. 1977 7.10 Notify Payload 1979 The Notify Payload, denoted NOTIFY in this memo, is used to transmit 1980 informational data, such as error conditions and state transitions to 1981 an IKE peer. A Notify Payload may appear in a response message 1982 (usually specifying why a request was rejected), or in an 1983 Informational Exchange (to report an error not in an IKE request). 1985 The Notify Payload is defined as follows: 1987 1 2 3 1988 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 1989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1990 ! Next Payload !C! RESERVED ! Payload Length ! 1991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1992 ! Protocol-ID ! SPI Size ! Notify Message Type ! 1993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1994 ! ! 1995 ~ Security Parameter Index (SPI) ~ 1996 ! ! 1997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1998 ! ! 1999 ~ Notification Data ~ 2000 ! ! 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2003 Figure 13: Notification Payload Format 2005 o Protocol-Id (1 byte) - Specifies the protocol about which 2006 this notification is being sent. For phase 1 notifications, 2007 this field MUST be zero (0). For phase 2 notifications 2008 concerning IPsec SAs this field will contain an IPsec 2009 protocol (either ESP, AH, or IPcomp). For notifications 2010 for which no protocol ID is relevant, this field MUST be 2011 sent as zero and MUST be ignored. 2013 o SPI Size (1 byte) - Length in bytes of the SPI as defined by 2014 the Protocol-Id or zero if no SPI is applicable. For phase 1 2015 notification concerning the IKE-SA, the SPI Size MUST be zero. 2017 o Notify Message Type (2 bytes) - Specifies the type of 2018 notification message. 2020 o SPI (variable length) - Security Parameter Index. 2022 o Notification Data (variable length) - Informational or error data 2023 transmitted in addition to the Notify Message Type. Values for 2024 this field are message specific, see below. 2026 The payload type for the Notification Payload is eleven (11). 2028 7.10.1 Notify Message Types 2030 Notification information can be error messages specifying why an SA 2031 could not be established. It can also be status data that a process 2032 managing an SA database wishes to communicate with a peer process. 2033 For example, a secure front end or security gateway may use the 2034 Notify message to synchronize SA communication. The table below 2035 lists the Notification messages and their corresponding values. 2037 NOTIFY MESSAGES - ERROR TYPES Value 2038 ----------------------------- ----- 2039 INVALID-PAYLOAD-TYPE 1 2041 Only sent if the payload has the "critical" bit set. 2042 Notification Data contains the one byte payload type. 2044 INVALID-COOKIE 4 2046 Indicates an IKE message was received with an unrecognized 2047 destination cookie. This usually indicates that the 2048 recipient has rebooted and forgotten the existence of an 2049 IKE-SA. 2051 INVALID-MAJOR-VERSION 5 2053 Indicates the recipient cannot handle the version of IKE 2054 specified in the header. The closest version number that the 2055 recipient can support will be in the reply header. 2057 INVALID-EXCHANGE-TYPE 7 2059 Notification Data contains the one byte Exchange Type. 2061 INVALID-FLAGS 8 2063 Notification Data contains one byte with the unacceptable 2064 flag bits set. 2066 INVALID-MESSAGE-ID 9 2068 Sent when either an IKE MESSAGE-ID more that ten greater 2069 than the highest acknowledged MESSAGE-ID. This Notify MUST 2070 NOT be sent in a response; the invalid request MUST NOT be 2071 acknowledged. Instead, inform the other side by initiating 2072 an Informational exchange with Notification data containing 2073 the four byte invalid MESSAGE-ID. 2075 INVALID-PROTOCOL-ID 10 2077 Notification Data contains the one byte invalid protocol ID. 2079 INVALID-SPI 11 2081 MAY be sent in an IKE Informational Exchange when a node 2082 receives an ESP or AH packet with an invalid SPI. address 2083 as the source address in the invalid packet. This usually 2084 indicates a node has rebooted and forgotten an SA. This 2085 Informational Message is sent outside the context of an IKE- 2086 SA, and therefore should only be used by the recipient as a 2087 "hint" that something might be wrong (because it could 2088 easily be forged). 2090 INVALID-TRANSFORM-ID 12 2092 Notification Data contains the one byte invalid transform 2093 ID. 2095 ATTRIBUTES-NOT-SUPPORTED 13 2097 The "Notification Data" for this type are the attribute or 2098 attributes that are not supported. 2100 NO-PROPOSAL-CHOSEN 14 2102 BAD-PROPOSAL-SYNTAX 15 2104 PAYLOAD-MALFORMED 16 2106 INVALID-KEY-INFORMATION 17 2108 The KE field is the wrong length. This can occur where there 2109 is no error if the Initiator guesses incorrectly which 2110 Diffie-Hellman group the Responder will accept. 2111 Notification data contains the Transform Substructure 2112 describing the chosen Diffie-Hellman group. 2114 INVALID-ID-INFORMATION 18 2116 INVALID-CERT-ENCODING 19 2118 The "Notification Data" for this type are the "Cert 2119 Encoding" field from a Certificate Payload or Certificate 2120 Request Payload. 2122 INVALID-CERTIFICATE 20 2124 The "Notification Data" for this type are the "Certificate 2125 Data" field from a Certificate Payload. 2127 CERT-TYPE-UNSUPPORTED 21 2129 This is identical to the INVALID-CERT-ENCODING error. 2131 INVALID-CERT-AUTHORITY 22 2133 The "Notification Data" for this type are the "Cert 2134 Encoding" field from a Certificate Payload or Certificate 2135 Request Payload. 2137 AUTHENTICATION-FAILED 24 2139 INVALID-SIGNATURE 25 2141 ADDRESS-NOTIFICATION 26 2143 Don't understand. 2145 UNSUPPORTED-EXCHANGE-TYPE 29 2147 The "Notification Data" for this type are the Exchange Type 2148 field from the IKE header. 2150 UNEQUAL-PAYLOAD-LENGTHS 30 2152 The "Notification Data" for this type are the entire message 2153 in which the unequal lengths were observed. Receipt of this 2154 notify MAY be logged for debugging purposes. 2156 UNSUPPORTED-NOTIFY-TYPE 31 2158 The "Notification Data" for this type is the two byte Notify 2159 Type that was not supported. 2161 IKE-SA-INIT-REJECT 32 2162 This notification is sent in an IKE-SA-RESPONSE to request 2163 that the Initiator retry the request with the supplied 2164 cookie (and optionally the supplied Diffie-Hellman group). 2165 This is not really an error, but is processed like one in 2166 that it indicates that the connection request was rejected. 2167 The Notification Data, if present, contains the Transform 2168 Substructure describing the preferred Diffie-Hellman group. 2170 INVALID-KE-PAYLOAD 33 2172 This error indicates that the KE payload does not match the 2173 chosen Diffie-Hellman group. It can occur legitimately in 2174 either Phase 1 or Phase 2 if the Initiator supports multiple 2175 Diffie-Hellman groups and incorrectly anticipates which one 2176 the Responder will choose. 2178 SINGLE-PAIR-REQUIRED 34 2180 This error indicates that a Phase 2 SA request is 2181 unacceptable because the Responder requires a separate SA 2182 for each source / destination address pair. The Initiator is 2183 expected to respond by requesting an SA for only the 2184 specific traffic he is trying to forward. 2186 RESERVED - Errors 34 - 8191 2188 Private Use - Errors 8192 - 16383 2190 NOTIFY MESSAGES - STATUS TYPES Value 2191 ------------------------------ ----- 2193 RESERVED 16384 - 24577 2195 INITIAL-CONTACT 24578 2197 This notification indicates that this IKE-SA is the only 2198 IKE-SA currently active between the authenticated 2199 identities. It MAY be sent when an IKE-SA is established 2200 after a crash, and the recipient MAY use this information to 2201 delete any other IKE-SA's it has to the same authenticated 2202 identity without waiting for a timeout. This notification 2203 MUST NOT be sent by an entity that may be replicated (e.g. a 2204 roaming user's credentials where the user is allowed to 2205 connect to the corporate firewall from two remote systems at 2206 the same time). 2208 RESERVED 24578 - 40959 2210 Private Use - STATUS 40960 - 65535 2212 7.11 Delete Payload 2214 The Delete Payload, denoted DEL in this memo, contains a protocol- 2215 specific security association identifier that the sender has removed 2216 from its security association database and is, therefore, no longer 2217 valid. Figure 14 shows the format of the Delete Payload. It is 2218 possible to send multiple SPIs in a Delete payload, however, each SPI 2219 MUST be for the same protocol. Mixing of Protocol Identifiers MUST 2220 NOT be performed with the Delete payload. It is permitted, however, 2221 to include multiple Delete payloads in a single Informational 2222 Exchange where each Delete payload lists SPIs for a different 2223 protocol. 2225 Deletion of the IKE-SA is indicated by a Protocol-Id of 0 (IKE) but 2226 no SPIs. Deletion which is concerned with a Child-SA, such as ESP or 2227 AH, will contain the Protocol-Id of that protocol (e.g. ESP, AH) and 2228 the SPI is the receiving entity's SPI(s). 2230 NOTE: What's the deal with IPcomp SAs. This mechanism is probably not 2231 appropriate for deleting them!! 2233 The Delete Payload is defined as follows: 2235 1 2 3 2236 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 2237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2238 ! Next Payload !C! RESERVED ! Payload Length ! 2239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2240 ! Protocol-Id ! SPI Size ! # of SPIs ! 2241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2242 ! ! 2243 ~ Security Parameter Index(es) (SPI) ~ 2244 ! ! 2245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2247 Figure 14: Delete Payload Format 2249 o Protocol-Id (1 byte) - Must be zero for an IKE-SA, [] for 2250 ESP, [] for AH, and [] for IPcomp. 2252 o SPI Size (1 byte) - Length in bytes of the SPI as defined by 2253 the Protocol-Id. Zero for IKE (SPI is in message header), 2254 four for AH and ESP, two for IPcomp. 2256 o # of SPIs (2 bytes) - The number of SPIs contained in the Delete 2257 payload. The size of each SPI is defined by the SPI Size field. 2259 o Security Parameter Index(es) (variable length) - Identifies the 2260 specific security association(s) to delete. 2261 The length of this field is 2262 determined by the SPI Size and # of SPIs fields. 2264 The payload type for the Delete Payload is twelve (12). 2266 7.12 Vendor ID Payload 2268 The Vendor ID Payload contains a vendor defined constant. The 2269 constant is used by vendors to identify and recognize remote 2270 instances of their implementations. This mechanism allows a vendor 2271 to experiment with new features while maintaining backwards 2272 compatibility. 2274 The Vendor ID payload is not an announcement from the sender that it 2275 will send private payload types but rather an announcement of the 2276 sort of private payloads it is willing to accept. The implementation 2277 sending the Vendor ID MUST not make any assumptions about private 2278 payloads that it may send unless a Vendor ID of like stature is 2279 received as well. Multiple Vendor ID payloads MAY be sent. An 2280 implementation is NOT REQUIRED to send any Vendor ID payload at all. 2282 A Vendor ID payload may be sent as part of any message. Reception of 2283 a familiar Vendor ID payload allows an implementation to make use of 2284 Private USE numbers described throughout this memo-- private 2285 payloads, private exchanges, private notifications, etc. Unfamiliar 2286 Vendor ID's MUST be ignored. 2288 Writers of Internet-Drafts who wish to extend this protocol MUST 2289 define a Vendor ID payload to announce the ability to implement the 2290 extension in the Internet-Draft. It is expected that Internet-Drafts 2291 which gain acceptance and are standardized will be given "magic 2292 numbers" out of the Future Use range by IANA and the requirement to 2293 use a Vendor ID will go away. 2295 The Vendor ID Payload fields are defined as follows: 2297 1 2 3 2298 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 2299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2300 ! Next Payload !C! RESERVED ! Payload Length ! 2301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2302 ! ! 2303 ~ Vendor ID (VID) ~ 2304 ! ! 2305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2307 Figure 15: Vendor ID Payload Format 2309 o Vendor ID (variable length) - It is the responsibility of 2310 the person choosing the Vendor ID to assure its uniqueness 2311 in spite of the absence of any central registry for IDs. 2312 Good practice is to include a company name, a person name 2313 or some such. If you want to show off, you might include 2314 the latitude and longitude and time where you were when 2315 you chose the ID and some random input. A message digest 2316 of a long unique string is preferable to the long unique 2317 string itself. 2319 The payload type for the Vendor ID Payload is thirteen (13). 2321 7.13 Traffic Selector Payload 2323 The Traffic Selector Payload, denoted TS in this memo, allows peers 2324 to identify packet flows for processing by IPsec security services. 2325 The Traffic Selector Payload consists of the IKE generic header 2326 followed by selector information fields as follows: 2328 1 2 3 2329 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 2330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2331 ! Next Payload !C! RESERVED ! Payload Length ! 2332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2333 ! Number of TSs ! RESERVED ! 2334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2335 ! ! 2336 ~ ~ 2337 ! ! 2338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2340 Figure 16: Traffic Selectors Payload Format 2342 o Number of TSs (1 byte) - Number of traffic selectors 2343 being provided. 2345 o RESERVED - This field MUST be sent as zero and MUST be ignored. 2347 o Traffic Selectors (variable length) - one or more traffic 2348 selector substructures. 2350 The length of the Traffic Selector payload includes the TS header and 2351 all the traffic selector substructures. 2352 The payload type for the Traffic Selector payload is fourteen (14). 2354 7.13.1 Traffic Selector Substructure 2356 1 2 3 2357 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 2358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2359 ! TS Type ! Protocol ID | Selector Length | 2360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2361 | Start-Port | End-Port | 2362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2363 ! ! 2364 ~ Address Selector Data ~ 2365 ! ! 2366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2368 Figure 17: Traffic Selector Substructure 2370 o TS Type (one byte) - Specifies the type of traffic selector. 2372 o Protocol ID (1 byte) - Value specifying an associated IP 2373 protocol ID (e.g. UDP/TCP). A value of zero means that the 2374 Protocol ID is not relevant to this traffic selector-- 2375 the SA can carry all protocols. 2377 o Selector Length - Specifies the length of this Traffic 2378 Selector Substructure including the header. 2380 o Start-Port (2 bytes) - Value specifying the smallest port 2381 number allowed by this Traffic Selector. For protocols for 2382 which port is undefined, or if all ports are allowed by 2383 this Traffic Selector, this field MUST be zero. 2385 o End-Port (2 bytes) - Value specifying the largest port 2386 number allowed by this Traffic Selector. For protocols for 2387 which port is undefined, or it all ports are allowed by 2388 this Traffic Selector, this field MUST be 65535. 2390 o Address Selector Data - a specification of one or more 2391 addresses included in this Traffic Selector with format 2392 determined by TS type. 2394 The following table lists the assigned values for the Traffic 2395 Selector Type field and the corresponding Address Selector Data. 2397 TS Type Value 2398 ------- ----- 2399 RESERVED 0 2401 TS_IPV4_ADDR 1 2403 A four (4) byte IPv4 address 2405 TS_IPV4_ADDR_SUBNET 4 2407 An IPv4 subnet represented by a pair of four (4) byte 2408 values. The first value is an IPv4 address. The second is 2409 an IPv4 network mask. Note that ones (1s) in the network 2410 mask indicate that the corresponding bit in the address is 2411 fixed, while zeros (0s) indicate a "wildcard" bit. 2413 TS_IPV6_ADDR 5 2415 A sixteen (16) byte IPv6 address 2417 TS_IPV6_ADDR_SUBNET 6 2419 An IPv6 subnet represented by a pair sixteen (16) byte 2420 values. The first value is an IPv6 address. The second is 2421 an IPv6 network mask. Note that ones (1s) in the network 2422 mask indicate that the corresponding bit in the address is 2423 fixed, while zeros (0s) indicate a "wildcard" bit. 2425 TS_IPV4_ADDR_RANGE 7 2427 A range of IPv4 addresses, represented by two four (4) byte 2428 values. The first value is the beginning IPv4 address 2429 (inclusive) and the second value is the ending IPv4 address 2430 (inclusive). All addresses falling between the two specified 2431 addresses are considered to be within the list. 2433 TS_IPV6_ADDR_RANGE 8 2435 A range of IPv6 addresses, represented by two sixteen (16) 2436 byte values. The first value is the beginning IPv6 address 2437 (inclusive) and the second value is the ending IPv6 address 2438 (inclusive). All addresses falling between the two specified 2439 addresses are considered to be within the list. 2441 7.14 Other Payload Types 2443 Payload type values 15-127 are reserved to IANA for future assignment 2444 in IKEv2 (see section 10). Payload type values 128-255 are for 2445 private use among mutually consenting parties. 2447 8 Diffie-Hellman Groups 2449 There are 5 groups different Diffie-Hellman groups defined for use in 2450 IKE. These groups were generated by Richard Schroeppel at the 2451 University of Arizona. Properties of these primes are described in 2452 [Orm96]. 2454 The strength supplied by group one may not be sufficient for the 2455 mandatory-to-implement encryption algorithm and is here for historic 2456 reasons. 2458 8.1 First Group 2460 IKE implementations MAY support a MODP group with the following prime 2461 and generator. This group is assigned id 1 (one). 2463 The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } 2464 Its hexadecimal value is: 2466 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 2467 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 2468 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 2469 A63A3620 FFFFFFFF FFFFFFFF 2471 The generator is: 2. 2473 8.2 Second Group 2475 IKE implementations SHOULD support a MODP group with the following 2476 prime and generator. This group is assigned id 2 (two). 2478 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. 2479 Its hexadecimal value is: 2481 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 2482 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 2483 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 2484 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 2485 49286651 ECE65381 FFFFFFFF FFFFFFFF 2487 The generator is 2 (decimal) 2489 8.3 Third Group 2491 IKE implementations SHOULD support a EC2N group with the following 2492 characteristics. This group is assigned id 3 (three). The curve is 2493 based on the Galois Field GF[2^155]. The field size is 155. The 2494 irreducible polynomial for the field is: 2495 u^155 + u^62 + 1. 2496 The equation for the elliptic curve is: 2497 y^2 + xy = x^3 + ax^2 + b. 2499 Field Size: 155 2500 Group Prime/Irreducible Polynomial: 2501 0x0800000000000000000000004000000000000001 2502 Group Generator One: 0x7b 2503 Group Curve A: 0x0 2504 Group Curve B: 0x07338f 2505 Group Order: 0x0800000000000000000057db5698537193aef944 2507 The data in the KE payload when using this group is the value x from 2508 the solution (x,y), the point on the curve chosen by taking the 2509 randomly chosen secret Ka and computing Ka*P, where * is the 2510 repetition of the group addition and double operations, P is the 2511 curve point with x coordinate equal to generator 1 and the y 2512 coordinate determined from the defining equation. The equation of 2513 curve is implicitly known by the Group Type and the A and B 2514 coefficients. There are two possible values for the y coordinate; 2515 either one can be used successfully (the two parties need not agree 2516 on the selection). 2518 8.4 Fourth Group 2520 IKE implementations SHOULD support a EC2N group with the following 2521 characteristics. This group is assigned id 4 (four). The curve is 2522 based on the Galois Field GF[2^185]. The field size is 185. The 2523 irreducible polynomial for the field is: 2524 u^185 + u^69 + 1. 2526 The equation for the elliptic curve is: 2527 y^2 + xy = x^3 + ax^2 + b. 2529 Field Size: 185 2530 Group Prime/Irreducible Polynomial: 2531 0x020000000000000000000000000000200000000000000001 2532 Group Generator One: 0x18 2533 Group Curve A: 0x0 2534 Group Curve B: 0x1ee9 2535 Group Order: 0x01ffffffffffffffffffffffdbf2f889b73e484175f94ebc 2537 The data in the KE payload when using this group will be identical to 2538 that as when using Oakley Group 3 (three). 2540 8.5 Fifth Group 2542 IKE implementations MUST support a MODP group with the following 2543 prime and generator. This group is assigned id 5 (five). 2545 The prime is 2^1536 - 2^1472 - 1 + 2^64 * {[2^1406 pi] + 741804}. 2546 Its hexadecimal value is 2548 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 2549 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 2550 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 2551 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 2552 49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 2553 FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 2554 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF 2556 The generator is 2. 2558 9 Security Considerations 2560 Repeated re-keying using Phase 2 without PFS can consume the entropy 2561 of the Diffie-Hellman shared secret. Implementers should take note of 2562 this fact and set a limit on Phase 2 Exchanges between 2563 exponentiations. This memo does not prescribe such a limit. 2565 The strength of a key derived from a Diffie-Hellman exchange using 2566 any of the groups defined here depends on the inherent strength of 2567 the group, the size of the exponent used, and the entropy provided by 2568 the random number generator used. Due to these inputs it is difficult 2569 to determine the strength of a key for any of the defined groups. The 2570 default Diffie-Hellman group (number two) when used with a strong 2571 random number generator and an exponent no less than 160 bits is 2572 sufficient to use for 3DES. Groups three through five provide 2573 greater security. Group one is for historic purposes only and does 2574 not provide sufficient strength to the required cipher (although it 2575 is sufficient for use with DES, which is also for historic use only). 2576 Implementations should make note of these conservative estimates when 2577 establishing policy and negotiating security parameters. 2579 Note that these limitations are on the Diffie-Hellman groups 2580 themselves. There is nothing in IKE which prohibits using stronger 2581 groups nor is there anything which will dilute the strength obtained 2582 from stronger groups. In fact, the extensible framework of IKE 2583 encourages the definition of more groups; use of elliptical curve 2584 groups will greatly increase strength using much smaller numbers. 2586 It is assumed that the Diffie-Hellman exponents in this exchange are 2587 erased from memory after use. In particular, these exponents MUST NOT 2588 be derived from long-lived secrets like the seed to a pseudo-random 2589 generator that is not erased after use. 2591 The security of this protocol is critically dependent on the 2592 randomness of the Diffie-Hellman exponents, which should be generated 2593 by a strong random or properly seeded pseudo-random source (see 2594 RFC1715). While the protocol was designed to be secure even if the 2595 Nonces and other values specified as random are not strongly random, 2596 they should similarly be generated from a strong random source as 2597 part of a conservative design. 2599 10 IANA Considerations 2601 This document contains many "magic numbers" to be maintained by the 2602 IANA. This section explains the criteria to be used by the IANA to 2603 assign additional numbers in each of these lists. 2605 10.1 Transform Types and Attribute Values 2607 10.1.1 Attributes 2609 Transform attributes are uses to modify or complete the specification 2610 of a particular transform. Requests for new transform attributes MUST 2611 be accompanied by a standards-track or Informational RFC which 2612 defines the transform which it modifies or completes and the method 2613 in which it does so. 2615 10.1.2 Encryption Algorithm Transform Type 2617 Values of the Encryption Algorithm define an encryption algorithm to 2618 use when called for in this document. Requests for assignment of new 2619 encryption algorithm values must be accompanied by a reference to a 2620 standards-track or informational RFC that describes how to use this 2621 algorithm with ESP. 2623 10.1.3 Pseudo-random function Transform Type 2625 Values for the pseudo-random function define which pseudo-random 2626 function is used in IKE for key generation and expansion. Requests 2627 for assignment of a new pseudo-random function MUST be accompanied by 2628 a reference to a standards-track or informational RFC describing this 2629 function. 2631 10.1.4 Authentication Method Transform Type 2633 The only Authentication method defined in the memo is for digital 2634 signatures. Other methods of authentication are possible and MUST be 2635 accompanied by a standards-track or informational RFC which defines 2636 the following: 2638 - the cryptographic method of authentication. 2639 - content of the Authentication Data in the Authentication 2640 Payload. 2641 - new payloads, their construction and processing, if needed. 2642 - additions of payloads to any messages, if needed. 2644 10.1.5 Diffie-Hellman Groups 2646 Values of the Diffie-Hellman Group Transform types define a group in 2647 which a Diffie-Hellman key exchange can be completed. Requests for 2648 assignment of a new Diffie-Hellman group type MUST be accompanied by 2649 a reference to a standards-track or informational RFC which fully 2650 defines the group. 2652 10.2 Exchange Types 2654 This memo defines three exchange types for use with IKEv2. Requests 2655 for assignment of new exchange types MUST be accompanied by a 2656 standards-track or informational RFC which defines the following: 2658 - the purpose of and need for the new exchange. 2659 - the payloads (mandatory and optional) that accompany 2660 messages in the exchange. 2661 - the phase of the exchange. 2662 - requirements the new exchange has on existing 2663 exchanges which have assigned numbers. 2665 10.3 Payload Types 2667 Payloads are defined in this memo to convey information between 2668 peers. New payloads may be required when defining a new 2669 authentication method or exchange. Requests for new payload types 2670 MUST be accompanied by a standards-track or informational RFC which 2671 defines the physical layout of the payload and the fields it 2672 contains. All payloads MUST use the same generic header defined in 2673 Figure 2. 2675 11 Acknowledgements 2677 We would like to thank the many members of the IPsec working group 2678 that provided helpful and constructive suggestions on improving IKE. 2679 Special thanks go to those of you who've implemented it! 2681 This protocol is built on the shoulders of many designers who came 2682 before. While they have not necessarily reviewed or endorsed this 2683 version and should not be blamed for any defects, they deserve much 2684 of the credit for its design. We would like to acknowledge Oakley, 2685 SKEME and their authors, Hilarie Orman (Oakley), Hugo Krawczyk 2686 (SKEME). Without the hard work of Doug Maughan, Mark Schertler, Mark 2687 Schneider, Jeff Turner, Dave Carrel, and Derrell Piper, this memo 2688 would not exist. Their contributions to the IPsec WG have been 2689 considerable and critical. 2691 12 References 2693 [CAST] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, 2694 May 1997. 2696 [BLOW] Schneier, B., "The Blowfish Encryption Algorithm", Dr. 2697 Dobb's Journal, v. 19, n. 4, April 1994. 2699 [Bra96] Bradner, S., "The Internet Standards Process -- Revision 3", 2700 BCP 9, RFC 2026, October 1996. 2702 [Bra97] Bradner, S., "Key Words for use in RFCs to indicate 2703 Requirement Levels", BCP 14, RFC 2119, March 1997. 2705 [Ble98] Bleichenbacher, D., "Chosen Ciphertext Attacks against 2706 Protocols Based on RSA Encryption Standard PKCS#1", Advances 2707 in Cryptology Eurocrypt '98, Springer-Verlag, 1998. 2709 [BR94] Bellare, M., and Rogaway P., "Optimal Asymmetric 2710 Encryption", Advances in Cryptology Eurocrypt '94, 2711 Springer-Verlag, 1994. 2713 [DES] ANSI X3.106, "American National Standard for Information 2714 Systems-Data Link Encryption", American National Standards 2715 Institute, 1983. 2717 [DH] Diffie, W., and Hellman M., "New Directions in 2718 Cryptography", IEEE Transactions on Information Theory, V. 2719 IT-22, n. 6, June 1977. 2721 [DSS] NIST, "Digital Signature Standard", FIPS 186, National 2722 Institute of Standards and Technology, U.S. Department of 2723 Commerce, May, 1994. 2725 [IDEA] Lai, X., "On the Design and Security of Block Ciphers," ETH 2726 Series in Information Processing, v. 1, Konstanz: Hartung- 2727 Gorre Verlag, 1992 2729 [KBC96] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2730 Hashing for Message Authentication", RFC 2104, February 2731 1997. 2733 [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange 2734 Mechanism for Internet", from IEEE Proceedings of the 1996 2735 Symposium on Network and Distributed Systems Security. 2737 [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, 2738 April 1992. 2740 [MSST98] Maughhan, D., Schertler, M., Schneider, M., and J. Turner, 2741 "Internet Security Association and Key Management Protocol 2742 (ISAKMP)", RFC 2408, November 1998. 2744 [Orm96] Orman, H., "The Oakley Key Determination Protocol", RFC 2745 2412, November 1998. 2747 [PFKEY] McDonald, D., Metz, C., and Phan, B., "PFKEY Key Management 2748 API, Version 2", RFC2367, July 1998. 2750 [PKCS1] Kaliski, B., and J. Staddon, "PKCS #1: RSA Cryptography 2751 Specifications Version 2", September 1998. 2753 [PK01] Perlman, R., and Kaufman, C., "Analysis of the IPsec key 2754 exchange Standard", WET-ICE Security Conference, MIT, 2001, 2755 http://sec.femto.org/wetice-2001/papers/radia-paper.pdf. 2757 [Pip98] Piper, D., "The Internet IP Security Domain Of 2758 Interpretation for ISAKMP", RFC 2407, November 1998. 2760 [RC5] Rivest, R., "The RC5 Encryption Algorithm", Dr. Dobb's 2761 Journal, v. 20, n. 1, January 1995. 2763 [RSA] Rivest, R., Shamir, A., and Adleman, L., "A Method for 2764 Obtaining Digital Signatures and Public-Key Cryptosystems", 2765 Communications of the ACM, v. 21, n. 2, February 1978. 2767 [Sch96] Schneier, B., "Applied Cryptography, Protocols, Algorithms, 2768 and Source Code in C", 2nd edition. 2770 [SHA] NIST, "Secure Hash Standard", FIPS 180-1, National Institute 2771 of Standards and Technology, U.S. Department of Commerce, 2772 May 1994. 2774 [TIGER] Anderson, R., and Biham, E., "Fast Software Encryption", 2775 Springer LNCS v. 1039, 1996. 2777 Appendix A 2779 Attribute Assigned Numbers 2781 Certain transforms negotiated in an SA payload can have associated 2782 attributes. Attribute types can be either Basic (B) or Variable- 2783 length (V). Encoding of these attributes is defined as Type/Value 2784 (Basic) and Type/Length/Value (Variable). See section 7.3.3. 2786 Attributes described as basic MUST NOT be encoded as variable. 2787 Variable length attributes MUST NOT be encoded as basic even if their 2788 value can fit into two bytes. NOTE: This is a change from IKEv1, 2789 where increased flexibility may have simplified the composer of 2790 messages but certainly complicated the parser. 2792 Attribute Classes 2794 class value type 2795 -------------------------------------------------------------- 2796 RESERVED 0-5 2797 Group Prime/Irreducible Polynomial 6 V 2798 Group Generator One 7 V 2799 Group Generator Two 8 V 2800 Group Curve A 9 V 2801 Group Curve B 10 V 2802 RESERVED 11-13 2803 Key Length 14 B 2804 Field Size 15 B 2805 Group Order 16 V 2806 Block Size 17 B 2808 values 0-5, 11-13, and 18-16383 are reserved to IANA. Values 2809 16384-32767 are for private use among mutually consenting parties. 2811 - Group Prime/Irreducible Polynomial 2813 The prime number of a MODP Diffie-Hellman group or the irreducible 2814 polynomial of an elliptic curve when specifying a private Diffie- 2815 Hellman group. 2817 - Generator One, Generator Two 2819 The X- and Y-coordinate of a point on an elliptic curve. When the 2820 Y-coordinate (generator two) is not given it can be computed with 2821 the X-coordinate and the definition of the curve. 2823 - Curve A, Curve B 2824 Coefficients from the definition of an elliptic curve: 2826 y^2 + xy = x^3 + (curve A)x^2 + (curve B) 2828 - Key Length 2830 When using an Encryption Algorithm that has a variable length key, 2831 this attribute specifies the key length in bits. (MUST use network 2832 byte order). This attribute MUST NOT be used when the specified 2833 Encryption Algorithm uses a fixed length key. 2835 - Field Size 2837 The field size, in bits, of a Diffie-Hellman group. 2839 - Group Order 2841 The group order of an elliptical curve group. Note the length of 2842 this attribute depends on the field size. 2844 - Block Size 2846 The number of bits per block of a cipher with a variable block 2847 length. 2849 Appendix B: Cryptographic Protection of IKE Data 2851 With the exception of the IKE-SA-INIT-REQUEST, IKE-SA-INIT-RESPONSE, 2852 and Informational Exchange error notifications when no IKE-SA exists, 2853 all IKE messages are encrypted and integrity protected. The 2854 algorithms for encryption and integrity protection are negotiated 2855 during IKE-SA setup, and the keys are computed as specified in 2856 sections 3 and 4.2. 2858 The encryption and integrity protection algorithms are the same as 2859 those available to the ESP protocol, through their application is 2860 slightly different. Whereas in ESP the header that is integrity 2861 protected but not encrypted is a total of 8 bytes (SPI+Sequence #) 2862 plus the IV, in IKE it is the IKE Header which is 28 bytes plus the 2863 IV (see section 7.1). 2865 All other aspects of cryptographic processing (including IV 2866 insertion, padding, key derivation, trailer insertion) are as 2867 specified in [ESP] and its supporting algorithm documents. The Next 2868 Header byte in the encrypted ESP payload MUST be set to zero. 2870 NOTE: This is a change from IKEv1, which along with its companion 2871 specifications defined its own algorithms for padding, encryption, 2872 and integrity protection and its own codes for cryptographic 2873 algorithms. Since most IKE implementations will also include ESP 2874 implementations, this alternative was thought to simplify both the 2875 specification and the implementation, as well as limit the number of 2876 techniques in need of analysis for soundness. 2878 Expansion of SKEYSEED 2880 In some circumstances SKEYSEED_e may not be long enough to supply all 2881 the necessary keying material an algorithm requires. In this case the 2882 key is derived from feeding the results of the prf into itself, 2883 concatenating the results and taking the highest necessary bits. 2885 Consider a fictitious cipher AKULA which requires 320 bits of key and 2886 the prf used to generate SKEYSEED_e only generates 120 bits of 2887 material. The key for AKULA would be the first 320 bits of Ka where: 2889 Ka = K1 | K2 | K3 2891 and 2893 K1 = prf(SKEYSEED_e, 0) 2894 K2 = prf(SKEYSEED_e, K1) 2895 K3 = prf(SKEYSEED_e, K2) 2897 where 0 is represented by a single byte. Each result of the prf 2898 provides 120 bits of material for a total of 360 bits. AKULA would 2899 use the first 320 bits of that 360 bit string. 2901 Authors' Addresses 2903 Dan Harkins 2904 dharkins@tibernian.com 2905 Tibernian Systems 2907 Charlie Kaufman 2908 ckaufman@iris.com 2909 IBM 2911 Radia Perlman 2912 radia.perlman@sun.com 2913 Sun Microsystems