idnits 2.17.1 draft-ietf-ipsec-ikev2-01.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-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 4019 lines 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 2691 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 (February 2002) is 8106 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 514, but not defined == Missing Reference: 'CERTREQ' is mentioned on line 839, but not defined == Missing Reference: 'KEi' is mentioned on line 988, but not defined == Missing Reference: 'KEr' is mentioned on line 1001, but not defined == Missing Reference: 'P' is mentioned on line 1672, but not defined == Unused Reference: 'CAST' is defined on line 2863, but no explicit reference was found in the text == Unused Reference: 'BLOW' is defined on line 2866, but no explicit reference was found in the text == Unused Reference: 'Ble98' is defined on line 2875, but no explicit reference was found in the text == Unused Reference: 'BR94' is defined on line 2881, but no explicit reference was found in the text == Unused Reference: 'DES' is defined on line 2885, but no explicit reference was found in the text == Unused Reference: 'DH' is defined on line 2889, but no explicit reference was found in the text == Unused Reference: 'DSS' is defined on line 2893, but no explicit reference was found in the text == Unused Reference: 'IDEA' is defined on line 2897, but no explicit reference was found in the text == Unused Reference: 'Ker01' is defined on line 2901, but no explicit reference was found in the text == Unused Reference: 'KBC96' is defined on line 2904, but no explicit reference was found in the text == Unused Reference: 'SKEME' is defined on line 2908, but no explicit reference was found in the text == Unused Reference: 'MD5' is defined on line 2912, but no explicit reference was found in the text == Unused Reference: 'MSST98' is defined on line 2915, but no explicit reference was found in the text == Unused Reference: 'PKCS1' is defined on line 2925, but no explicit reference was found in the text == Unused Reference: 'PK01' is defined on line 2930, but no explicit reference was found in the text == Unused Reference: 'Pip98' is defined on line 2934, but no explicit reference was found in the text == Unused Reference: 'RC5' is defined on line 2937, but no explicit reference was found in the text == Unused Reference: 'RSA' is defined on line 2940, but no explicit reference was found in the text == Unused Reference: 'Sch96' is defined on line 2944, but no explicit reference was found in the text == Unused Reference: 'SHA' is defined on line 2947, but no explicit reference was found in the text == Unused Reference: 'TIGER' is defined on line 2951, 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' -- No information found for draft-keronytis-ike-id - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Ker01' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'KBC96') -- Possible downref: Non-RFC (?) normative reference: ref. 'SKEME' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') ** Obsolete normative reference: RFC 2408 (ref. 'MSST98') (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 2412 (ref. 'Orm96') ** Downref: Normative reference to an Informational RFC: RFC 2367 (ref. 'PFKEY') -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS1' -- Possible downref: Non-RFC (?) normative reference: ref. 'PK01' ** Obsolete normative reference: RFC 2407 (ref. 'Pip98') (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. '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: 14 errors (**), 0 flaws (~~), 33 warnings (==), 21 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 Steve Kent 5 Tero Kivinen 6 Radia Perlman 7 editors 8 draft-ietf-ipsec-ikev2-01.txt February 2002 10 Proposal for the IKEv2 Protocol 11 13 Status of this Memo 15 This document is an Internet Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026 [Bra96]. Internet Drafts are 17 working documents of the Internet Engineering Task Force (IETF), its 18 areas, and working groups. Note that other groups may also distribute 19 working documents as Internet Drafts. 21 Internet Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet Drafts as reference 24 material or to cite them other than as "work in progress." 26 To learn the current status of any Internet Draft, please check the 27 "1id-abstracts.txt" listing contained in the Internet Drafts Shadow 28 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au (Australia), ds.internic.net (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 Abstract 34 This document describes version 2 of the IKE (Internet Key Exchange) 35 protocol. IKE performs mutual authentication and establishes an IKE 36 security association that can be used to efficiently establish SAs 37 for ESP, AH and/or IPcomp. This version greatly simplifies IKE by 38 replacing the 8 possible phase 1 exchanges with a single exchange 39 based on either public signature keys or shared secret keys. The 40 single exchange provides identity hiding, yet works in 2 round trips 41 (all the identity hiding exchanges in IKE v1 required 3 round trips). 42 Latency of setup of an IPsec SA is further reduced from IKEv1 by 43 allowing setup of an SA for ESP, AH, and/or IPcomp to be piggybacked 44 on the initial IKE exchange. It also improves security by allowing 45 the Responder to be stateless until it can be assured that the 46 Initiator can receive at the claimed IP source address. This version 48 Harkins Kaufman Perlman [Page 1]^L 49 also presents the entire protocol in a single self-contained 50 document, in contrast to IKEv1, in which the protocol was described 51 in ISAKMP (RFC 2408), IKE (RFC 2409), and the DOI (RFC 2407) 52 documents. 54 Table of Contents 56 1. Introduction..............................................3 57 1.1 The IKE Protocol.........................................3 58 1.2 Change History...........................................4 59 1.3 Requirements Terminology.................................6 60 2 Protocol Overview..........................................6 61 2.1 Use of Retransmission Timers.............................6 62 2.2 Use of Sequence Numbers for Message ID...................7 63 2.3 Window Size for overlapping requests.....................8 64 2.4 State Synchronization and Connection Timeouts............8 65 2.5 Version Numbers and Forward Compatibility................9 66 2.6 Cookies..................................................11 67 2.7 Cryptographic Algorithm Negotiation......................14 68 2.8 Rekeying.................................................15 69 2.9 Traffic Selector Negotiation.............................16 70 2.10 Nonces..................................................16 71 2.11 Address and Port Agility................................17 72 3 The Phase 1 Exchange.......................................17 73 3.1 Generating Keying Material for the IKE-SA................18 74 3.2 Authentication of the IKE-SA.............................19 75 4 The CREATE-CHILD-SA (Phase 2) Exchange.....................20 76 4.1 Generating Keying Material for Child-SAs.................21 77 4.2 Generating Keying Material for IKE-SAs during rollover...22 78 5 Informational (Phase 2) Exchange...........................23 79 6 Error Handling.............................................24 80 7 Header and Payload Formats.................................25 81 7.1 The IKE Header...........................................25 82 7.2 Generic Payload Header...................................28 83 7.3 Security Association Payload.............................29 84 7.3.1 Proposal Substructure..................................31 85 7.3.2 Transform Substructure.................................33 86 7.3.3 Mandatory Transform Types..............................36 87 7.3.4 Mandatory Transform-IDs................................36 88 7.3.5 Transform Attributes...................................37 89 7.3.6 Attribute Negotiation..................................38 90 7.4 Key Exchange Payload.....................................38 91 7.5 Identification Payload...................................39 92 7.6 Certificate Payload......................................41 93 7.7 Certificate Request Payload..............................42 94 7.8 Authentication Payload...................................43 96 Harkins Kaufman Perlman [Page 2]^L 97 7.9 Nonce Payload............................................44 98 7.10 Notify Payload..........................................45 99 7.10.1 Notify Message Types..................................46 100 7.11 Delete Payload..........................................50 101 7.12 Vendor ID Payload.......................................51 102 7.13 Traffic Selector Payload................................52 103 7.13.1 Traffic Selector Substructure.........................53 104 7.14 Other Payload types.....................................55 105 8 Diffie-Hellman Groups......................................55 106 9 Security Considerations....................................57 107 10 IANA Considerations.......................................58 108 10.1 Transform Types and Attribute Values....................58 109 10.2 Exchange Types..........................................59 110 10.3 Payload Types...........................................60 111 11 Acknowledgements..........................................60 112 12 References................................................60 113 Appendix A: Attribute Assigned Numbers.......................63 114 Appendix B: Cryptographic Protection of IKE Data.............65 115 Authors' Addresses...........................................67 117 1. Introduction 119 IP Security (IPsec) provides confidentiality, data integrity, and 120 data source authentication to IP datagrams. These services are 121 provided by maintaining shared state between the source and the sink 122 of an IP datagram. This state defines, among other things, the 123 specific services provided to the datagram, which cryptographic 124 algorithms will be used to provide the services, and the keys used as 125 input to the cryptographic algorithms. 127 Establishing this shared state in a manual fashion does not scale 128 well. Therefore a protocol to establish this state dynamically is 129 needed. This memo describes such a protocol-- the Internet Key 130 Exchange (IKE). This is version 2 of IKE. Version 1 of IKE was 131 defined in RFCs 2407, 2408, and 2409. This single document is 132 intended to replace all three of those RFCs. 134 1.1 The IKE Protocol 136 IKE performs mutual authentication between two parties and 137 establishes an IKE security association that includes shared secret 138 information that can be used to efficiently establish SAs for ESP 139 (RFC 2406), AH (RFC 2402) and/or IPcomp (RFC 2393). We call the IKE 140 SA an "IKE-SA", and the SAs for ESP, AH, and/or IPcomp that get set 141 up through that IKE-SA we call "child-SA"s. 143 We call the setup of the IKE-SA "phase 1" and subsequent IKE 144 exchanges "phase 2" even though setup of a child-SA can be 146 Harkins Kaufman Perlman [Page 3]^L 147 piggybacked on the initial phase 1 exchange. The phase 1 exchange is 148 two request/response pairs. A phase 2 exchange is one 149 request/response pair, and can be used to create or delete a child- 150 SA, rekey or delete the IKE-SA, or give information such as error 151 conditions. 153 IKE message flow always consists of a request followed by a response. 154 It is the responsibility of the requester to ensure reliability. If 155 the response is not received within a timeout interval, the requester 156 retransmits the request. 158 The first request/response of a phase 1 exchange, which we'll call 159 IKE_SA_init, negotiates security parameters for the IKE-SA, and sends 160 Diffie-Hellman values. We call the response IKE_SA_init_response. 162 The second request/response, which we'll call IKE_auth, transmits 163 identities, proves knowledge of the private signature key, and sets 164 up an SA for the first (and often only) AH and/or ESP and/or IPcomp. 165 We call the response IKE_auth_response. 167 If the Responder feels it is under attack, and wishes to use a 168 stateless cookie (see section on cookies). it can respond to an 169 IKE_SA_init with an IKE_SA_init_reject with a cookie value that must 170 be sent with a subsequent IKE_SA_init_request. The Initiator then 171 sends another IKE_SA_init, but this time including the Responder's 172 cookie value. 174 Phase 2 exchanges each consist of a single request/response pair. The 175 types of exchanges are CREATE_CHILD_SA (creates a child-SA), or an 176 informational exchange which deletes a child-SA or the IKE-SA or 177 informs the other side of some error condition. All these messages 178 require a response, so an informational message with no payloads can 179 serve as a check for liveness. 181 1.2 Change History 183 1.2.1 Changes from IKEv1 to IKEv2-00 November 2001 185 The goals of this revision to IKE are: 187 1) To define the entire IKE protocol in a single document, rather 188 than three that cross reference one another; 190 2) To simplify IKE by eliminating the Aggressive Mode option and all 191 but one of the authentication algorithms making phase 1 a single 192 exchange (based on public signature keys); 194 Harkins Kaufman Perlman [Page 4]^L 195 3) To remove the Domain of Interpretation (DOI), Situation (SIT), and 196 Labeled Domain Identifier fields, and the Commit and Authentication 197 only bits; 199 4) To decrease IKE's latency by making the initial exchange be 2 200 round trips (4 messages), and allowing the ability to piggyback setup 201 of a Child-SA on that exchange; 203 5) To replace the cryptographic algorithms for protecting the IKE 204 messages themselves with one based closely on ESP to simplify 205 implementation and security analysis; 207 6) To reduce the number of possible error states by making the 208 protocol reliable (all messages are acknowledged) and sequenced. This 209 allows shortening Phase 2 exchanges from 3 messages to 2; 211 7) To increase robustness by allowing the Responder, if under attack, 212 to require return of a cookie before the Responder commits any state 213 to the exchange; 215 8) To fix bugs such as the hash problem documented in [draft-ietf- 216 ipsec-ike-hash-revised-02.txt]; 218 9) To specify Traffic Selectors in their own payload type rather then 219 overloading ID payloads, and making more flexible the Traffic 220 Selectors that may be specified; 222 10) To avoid unnecessary exponential explosion of space in attribute 223 negotiation, by allowing choices when multiple algorithms of one type 224 (say, encryption) can work with any of a number of acceptable 225 algorithms of another type (say, integrity protection); 227 11) To specify required behavior under certain error conditions or 228 when data that is not understood is received in order to make it 229 easier to make future revisions in a way that does not break 230 backwards compatibility; 232 12) To simplify and clarify how shared state is maintained in the 233 presence of network failures and Denial of Service attacks; and 235 13) To maintain existing syntax and magic numbers to the extent 236 possible to make it likely that implementations of IKEv1 can be 237 enhanced to support IKEv2 with minimum effort. 239 1.2.2 Changes from IKEv2-00 to IKEv2-01 February 2002 241 1) Changed Appendix B to specify the encryption and authentication 242 processing for IKE rather than referencing ESP. Simplified the format 244 Harkins Kaufman Perlman [Page 5]^L 245 by removing idiosyncracies not needed for IKE. 247 2) Added option for authentication via a shared secret key. 249 3) Specified different keys in the two directions of IKE messages. 250 Removed requirement of different cookies in the two directions since 251 now no longer required. 253 4) Change the quantities signed by the two ends in AUTH fields to 254 assure the two parties sign different quantities. 256 5) Changed reference to AES to AES_128. 258 6) Removed requirement that Diffie-Hellman be repeated when rekeying 259 IKE SA. 261 7) Fixed typos. 263 8) Clarified requirements around use of port 500 at the remote end in 264 support of NAT. 266 9) Clarified required ordering for payloads. 268 10) Suggested mechanisms for avoiding DoS attacks. 270 11) Removed claims in some places that the first phase 2 piggybacked 271 on phase 1 was optional. 273 1.3 Requirements Terminology 275 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 276 "MAY" that appear in this document are to be interpreted as described 277 in [Bra97]. 279 2 Protocol Overview 281 IKE runs over UDP port 500. Since UDP is a datagram (unreliable) 282 protocol, IKE includes in its definition recovery from transmission 283 errors, including packet loss, packet replay, and packet forgery. IKE 284 is designed to function so long as at least one of a series of 285 retransmitted packets reaches its destination before timing out and 286 the channel is not so full of forged and replayed packets so as to 287 exhaust the network or CPU capacities of either endpoint. Even in the 288 absence of those minimum performance requirements, IKE is designed to 289 fail cleanly (as though the network were broken). 291 Harkins Kaufman Perlman [Page 6]^L 292 2.1 Use of Retransmission Timers 294 All messages in IKE exist in pairs: a request and a response. Either 295 end of a security association may initiate requests at any time, and 296 there can be many requests and responses "in flight" at any given 297 moment. But each message is labelled as either a request or a 298 response and for each pair one end of the security association is the 299 Initiator and the other is the Responder. 301 For every pair of messages, the Initiator is responsible for 302 retransmission in the event of a timeout. The Responder will never 303 retransmit a response unless it receives a retransmission of the 304 request. In that event, the Responder MUST either ignore the 305 retransmitted request except insofar as it triggers a retransmission 306 of the response OR if the request is idempotent, the Responder may 307 choose to process the request again and send a semantically 308 equivalent reply. 310 IKE is a reliable protocol, in the sense that the Initiator MUST 311 retransmit a request until either it receives a corresponding reply 312 OR it deems the IKE security association to have failed and it 313 discards all state associated with the IKE-SA and any Child-SAs 314 negotiated using that IKE-SA. 316 2.2 Use of Sequence Numbers for Message ID 318 Every IKE message contains a Message ID as part of its fixed header. 319 This Message ID is used to match up requests and responses, and to 320 identify retransmissions of messages. 322 The Message ID is a 32 bit quantity, with is zero for the first IKE 323 message. Each endpoint in the IKE Security Association maintains two 324 "current" Message IDs: the next one to be used for a request it 325 initiates and the next one it expects to see from the other end. 326 These counters increment as requests are generated and received. 327 Responses always contain the same message ID as the corresponding 328 request. That means that after the initial setup, each integer n will 329 appear as the message ID in four distinct messages: The nth request 330 from the original IKE Initiator, the corresponding response, the nth 331 request from the original IKE Responder, and the corresponding 332 response. If the two ends make very different numbers of requests, 333 the Message IDs in the two directions can be very different. There is 334 no ambiguity in the messages, however, because each packet contains 335 enough information to determine which of the four messages a 336 particular one is. 338 In the case where the IKE_SA_init is rejected (e.g. in order to 339 require a cookie), the second IKE_SA_init message will begin the 341 Harkins Kaufman Perlman [Page 7]^L 342 sequence over with Message #0. 344 2.3 Window Size for overlapping requests 346 In order to maximize IKE throughput, an IKE endpoint MAY issue 347 multiple requests before getting a response to any of them. For 348 simplicity, an IKE implementation MAY choose to process requests 349 strictly in order and/or wait for a response to one request before 350 issuing another. Certain rules must be followed to assure 351 interoperability between implementations using different strategies. 353 After an IKE-SA is set up, either end can initiate one or more 354 requests. These requests may pass one another over the network. An 355 IKE endpoint MUST be prepared to accept and process a request while 356 it has a request outstanding in order to avoid a deadlock in this 357 situation. An IKE endpoint SHOULD be prepared to accept and process 358 multiple requests while it has a request outstanding. 360 An IKE endpoint MUST NOT exceed the peer's stated window size (see 361 section 7.3.2) for transmitted IKE requests. In other words, if Bob 362 stated his window size is N, then when Alice needs to make a request 363 X, she MUST wait until she has received responses to all requests up 364 through request X-N. An IKE endpoint MUST keep a copy of (or be able 365 to regenerate exactly) each request it has sent until it receives the 366 corresponding response. An IKE endpoint MUST keep a copy of (or be 367 able to regenerate with semantic equivalence) the number of previous 368 responses equal to its contracted window size in case its response 369 was lost and the Initiator requests its retransmission by 370 retransmitting the request. 372 An IKE endpoint SHOULD be capable of processing incoming requests out 373 of order to maximize performance in the event of network failures or 374 packet reordering. 376 2.4 State Synchronization and Connection Timeouts 378 An IKE endpoint is allowed to forget all of its state associated with 379 an IKE-SA and the collection of corresponding child-SAs at any time. 380 This is the anticipated behavior in the event of an endpoint crash 381 and restart. It is important when an endpoint either fails or 382 reinitializes its state that the other endpoint detect those 383 conditions and not continue to waste network bandwidth by sending 384 packets over those SAs and having them fall into a black hole. 386 Since IKE is designed to operate in spite of Denial of Service (DoS) 387 attacks from the network, an endpoint MUST NOT conclude that the 388 other endpoint has failed based on any routing information (e.g. ICMP 390 Harkins Kaufman Perlman [Page 8]^L 391 messages) or IKE messages that arrive without cryptographic 392 protection (e.g., notify messages complaining about unknown SPIs). An 393 endpoint MUST conclude that the other endpoint has failed only when 394 repeated attempts to contact it have gone unanswered for a timeout 395 period. An endpoint SHOULD suspect that the other endpoint has failed 396 based on routing information and initiate a request to see whether 397 the other endpoint is alive. To check whether the other side is 398 alive, IKE provides a null query notify message that requires an 399 acknowledgment. If a cryptographically protected message has been 400 received from the other side recently, unprotected notifications MAY 401 be ignored. Implementations MUST limit the rate at which they 402 generate responses to unprotected messages. 404 Numbers of retries and lengths of timeouts are not covered in this 405 specification because they do not affect interoperability. It is 406 suggested that messages be retransmitted at least a dozen times over 407 a period of at least several minutes before giving up on an SA, but 408 different environments may require different rules. An exception to 409 this rule is that a Responder who has not received a 410 cryptographically protected message on an IKE-SA MUST eventually time 411 it out and delete it. Note that consuming state on an IKE Responder 412 by setting up large numbers of half-open IKE-SAs is a likely denial 413 of service attack, so the policy for timing these out and limiting 414 the resources they consume should be considered carefully. 416 There is a Denial of Service attack on the Initiator of an IKE SA 417 that can be avoided if the Initiator takes the proper care. Since the 418 first two messages of an SA setup are not cryptographically 419 protected, an attacker could respond to the Initiator's message 420 before the genuine Responder and poison the connection setup attempt. 421 To prevent this, the Initiator SHOULD be willing to accept multiple 422 responses to its first message, treat each as potentially legitimate, 423 respond to it, and then discard all the invalid half open connections 424 when she receives a valid cryptographically protected response to any 425 one of her responses. 427 Note that with these rules, there is no reason to negotiate and agree 428 upon an SA lifetime. If IKE presumes the partner is dead, based on 429 repeated lack of acknowledgment to an IKE message, then the IKE SA 430 and all child-SAs set up through that IKE-SA are deleted. 432 An IKE endpoint MAY delete inactive Child-SAs to recover resources 433 used to hold their state. If an IKE endpoint chooses to do so, it 434 MUST send Delete payloads to the other end notifying it of the 435 deletion. It MAY similarly time out the IKE-SA. Closing the IKE-SA 436 implicitly closes all associated Child-SAs. An IKE endpoint SHOULD 437 send a Delete payload indicating that it has closed the IKE-SA. 439 Harkins Kaufman Perlman [Page 9]^L 440 2.5 Version Numbers and Forward Compatibility 442 This document describes version 2.0 of IKE, meaning the major version 443 number is 2 and the minor version number is zero. It is likely that 444 some implementations will want to support both version 1.0 and 445 version 2.0, and in the future, other versions. 447 The major version number should only be incremented if the packet 448 formats have changed so dramatically that an older version node would 449 not be able to interoperate with messages in the new version format. 450 The minor version number indicates new capabilities, and MUST be 451 ignored by a node with a smaller minor version number, but used for 452 informational purposes by the node with the larger minor version 453 number. For example, it might indicate the ability to process a newly 454 defined notification message. The node with the larger minor version 455 number would simply note that its correspondent would not be able to 456 understand that message and therefore would not send it. 458 If you receive a message with a higher major version number, you MUST 459 drop the message and SHOULD send an unauthenticated notification 460 message containing the highest version number you support. If you 461 support major version n, and major version m, you MUST support all 462 versions between n and m. If you receive a message with a major 463 version that you support, you MUST respond with that version number. 464 In order to prevent two nodes from being tricked into corresponding 465 with a lower major version number than the maximum that they both 466 support, IKE has a flag that indicates that the node is capable of 467 speaking a higher major version number. 469 Thus the major version number in the IKE header indicates the version 470 number of the message, not the highest version number that the 471 transmitter supports. If A is capable of speaking versions n, n+1, 472 and n+2, and B is capable of speaking versions n and n+1, then they 473 will negotiate speaking n+1, where A will set the flag indicating 474 ability to speak a higher version. If they mistakenly (perhaps 475 through an active attacker sending error messages) negotiate to 476 version n, then both will notice that the other side can support a 477 higher version number, and they MUST break the connection and 478 reconnect using version n+1. 480 Note that v1 does not follow these rules, because there is no way in 481 v1 of noting that you are capable of speaking a higher version 482 number. So an active attacker can trick two v2-capable nodes into 483 speaking v1. Given the design of v1, there is no way of preventing 484 this, but this version number discipline will prevent such problems 485 in future versions. 487 Also for forward compatibility, all fields marked RESERVED MUST be 489 Harkins Kaufman Perlman [Page 10]^L 490 set to zero by a version 2.0 implementation and their content MUST be 491 ignored by a version 2.0 implementation ("Be conservative in what you 492 send and liberal in what you receive"). In this way, future versions 493 of the protocol can use those fields in a way that is guaranteed to 494 be ignored by implementations that do not understand them. 495 Similarly, payload types that are not defined are reserved for future 496 use and implementations of version 2.0 MUST skip over those payloads 497 and ignore their contents. 499 IKEv2 adds a "critical" flag to each payload header for further 500 flexibility for forward compatibility. If the critical flag is set 501 and the payload type is unsupported, the message MUST be rejected and 502 the response to the IKE request containing that payload MUST include 503 a notify payload INVALID-PAYLOAD-TYPE, indicating an unsupported 504 critical payload was included. If the critical flag is not set and 505 the payload type is unsupported, that payload is simply skipped. 506 While new payload types may be added in the future and may appear 507 interleaved with the fields defined in this specification, 508 implementations MUST send the payloads defined in this specification 509 in the stated order and implementations SHOULD reject as invalid a 510 message with payloads in an unexpected order. 512 2.6 Cookies 514 The term "cookies" originates with Karn and Simpson [RFC 2522] in 515 Photurus, an early proposal for key managment with IPsec. It has 516 persisted because the IETF has never rejected an offer involving 517 cookies. In IKEv2, the cookies serve two purposes. First, they are 518 used as IKE-SA identifiers in the headers of IKE messages. As with 519 ESP and AH, in IKEv2 the recipient of a message chooses an IKE-SA 520 identifier that uniquely defines that SA to that recipient. For this 521 purpose (IKE-SA identifiers), it might be convenient for the cookie 522 value to be chosen so as to be a table index for fast lookups of SAs. 523 But this conflicts with the second purpose of the cookies (to be 524 explained shortly). 526 Unlike ESP and AH where only the recipient's SA identifier appears in 527 the message, in IKE, the sender's IKE SA identifier is also sent in 528 every message. In IKEv1 the IKE-SA identifier consisted of the pair 529 (Initiator cookie, Responder cookie), whereas in IKEv2, the SA is 530 uniquely defined by the recipient's SA identifier even though both 531 are included in the IKEv2 header. 533 The second use of cookies in IKEv2 is for a limited protection from 534 denial of service attacks. Receipt of a request to start an SA can 535 consume substantial resources. A likely denial of service attack 536 against IKE is to overwhelm a system with large numbers of SA 537 requests from forged IP addresses. This can consume CPU resources 539 Harkins Kaufman Perlman [Page 11]^L 540 doing the crypto, and memory resources remembering the state of the 541 "half open" connections until they time out. A robust design would 542 limit the resources it is willing to devote to new connection 543 establishment, but even so the denial of service attack could 544 effectively prevent any new connections. 546 This attack can be rendered more difficult by requiring that the 547 Responder to an SA request do minimal computation and allocate no 548 memory until the Initiator has proven that it can receive messages at 549 the address it claims to be sending from. This is done in a stateless 550 way by computing the cookie in a way that the Responder can recompute 551 the same value, but the Initiator can't guess it. A recommended 552 strategy is to compute the cookie as a cryptographic hash of the 553 Initiator's IP address, the Initiator's cookie value (its chosen IKE 554 security identifier), and a secret known only to the Responder. That 555 secret should be changed periodically to prevent the "cookie jar" 556 attack where an attacker accumulates lots of cookies from lots of IP 557 addresses over time and then replays them all at once to overwhelm 558 the Responder. 560 In ISAKMP and IKEv1, the term cookie was used for the connection 561 identifier, but the protocol did not permit their use against this 562 particular denial of service attack. To avoid the cookie exchange 563 adding extra messages to the protocol in the common case where the 564 Responder is not under attack, IKEv2 goes back to the approach in 565 Oakley (RFC 2412) where the cookie challenge is optional. Upon 566 receipt of an IKE_SA_init, a Responder may either proceed with 567 setting up the SA or may tell the Initiator to send another 568 IKE_SA_init, this time providing a supplied cookie. 570 It may be convenient for the IKE-SA identifier to be an index into a 571 table. It is not difficult for the Initiator to choose an IKE-SA 572 identifier that is convenient as a table identifier, since the 573 Initiator does not need to use it as an anti-clogging token, and is 574 keeping state. IKEv2 allows the Responder to initially choose a 575 stateless anti-clogging type cookie by responding to an IKE_SA_init 576 with a cookie request, and then upon receipt of an IKE_SA_init with a 577 valid cookie, change his cookie value from the computed anti-clogging 578 token to a more convenient value, by sending a different value for 579 his cookie in the IKE_SA_init_response. This will not confuse the 580 Initiator (Alice), because she will have chosen a unique cookie value 581 A, so if her SA state for the partially set up IKE-SA says that Bob's 582 cookie for the SA that Alice knows as "A" is B, and she receives a 583 response from Bob with cookies (A,C), that means that Bob wants to 584 change his value from B to C for the SA that Alice knows uniquely as 585 "A". 587 Another reason why Bob might want to change his cookie value is that 589 Harkins Kaufman Perlman [Page 12]^L 590 it is possible (though unlikely) that Bob will choose the same cookie 591 for multiple SAs if the hash of the Initiator cookie, Initiator IP 592 address, and whatever other information might be included happens to 593 hash to the same value. 595 In IKEv2, like IKEv1, both 8-byte cookies appear in the message, but 596 in IKEv2 (unlike v1), the value chosen by the message recipient 597 always appears first in the message. This change eliminates a flaw in 598 IKEv1, as well as having other advantages (allowing the recipient to 599 look up the SA based on a small, conveniently chosen value rather 600 than a 16-byte pseudorandom value.) 602 The flaw in IKEv1 is that it was possible (though unlikely) for two 603 connections to have the same set of cookies. For instance, if Alice 604 chose A as the Initiator cookie when initiating a connection to Bob, 605 she might subsequently receive a connection request from Carol, and 606 Carol might also have chosen A as the Initiator cookie. Whatever 607 value Alice responds to Carol, say B, might be selected as the 608 Responder cookie by Bob for the Alice-Bob SA. Then Alice would be 609 involved in two IKE sessions, both of which had Initiator cookie=A 610 and Responder cookie=B. To minimize, but not eliminate, the 611 probability of this happening, version 1 IKE recommended that cookies 612 be chosen at random. 614 The cookies are one of the inputs into the function that computes the 615 keying material. If the Responder initially sends a stateless cookie 616 value in its IKE_SA_init_reject, and changes to a different value 617 when it sends its IKE_SA_init_response, it is the cookie value in the 618 IKE_SA_init_response that is the input for generating the keying 619 material. 621 Note that one of the denial of service attacks that cookies are 622 designed to thwart is exhaustion of state at the target by creating 623 half-open connections. This defense would be ineffective if there 624 were another equally easy way for an attacker to consume state at the 625 target. IKE runs over UDP, and may send messages sufficiently large 626 that they must be fragmented. But accumulating fragments of UDP 627 packets consumes state at the target, so if an IKE responder were 628 required to accept and reassemble UDP packets from unknown sources, 629 another equally easy denial of service attack would be possible. 631 To thwart the UDP reassembly buffer attack, the IKE responder SHOULD, 632 when it detects that it is under attack, have a mechanism to inform 633 IP reassembly to only accept UDP fragments from IP addresses from 634 which it has received a valid cookie and to refuse to accept UDP 635 fragments from all other IP addresses. To faccilitate this, the 636 IKE_SA_init message SHOULD be kept under 500 bytes and responders MAY 637 reject fragmented IKE_SA_init messages. 639 Harkins Kaufman Perlman [Page 13]^L 640 2.7 Cryptographic Algorithm Negotiation 642 The payload type known as "SA" indicates a proposal for a set of 643 choices of protocols (e.g., IKE, ESP, AH, and/or IPcomp) for the SA 644 as well as cryptographic algorithms associated with each protocol. In 645 IKEv1 it was extremely complex, and required a separate proposal for 646 each possible combination. If there were n algorithms of one type 647 (say encryption) that were acceptable and worked with any one of m 648 algorithms of another type (say integrity protection), then it would 649 take space proportional to n*m to express all of the possibilities. 651 IKEv2 has simplified the format of the SA payload somewhat, but in 652 addition to simplifying the format, solves the exponential explosion 653 by allowing, within a proposal, multiple algorithms of the same type. 654 If more than one algorithm of the same type (say encryption) appears 655 in a proposal, that means that the sender of that SA proposal is 656 willing to accept the proposal with any of those choices, and the 657 recipient when it accepts the proposal selects exactly one of each of 658 the types of algorithms from the choices offered within that 659 proposal. 661 An SA consists of one or more proposals. Each proposal has a number 662 (so that the recipient can specify which proposal has been accepted), 663 and contains a protocol (IKE, ESP, AH, or IPcomp), a SPI to identify 664 the SA for ESP or AH or IPcomp, and set of transforms. Each transform 665 consists of a type (e.g., encryption, integrity protection, 666 authentication, Diffie-Hellman group, compression) and a transform ID 667 (e.g., DES, IDEA, HMAC-MD5). To negotiate an SA that does ESP, 668 IPcomp, and AH, the SA will contain three proposals with the same 669 proposal number, one proposing ESP, a 4 byte SPI to be used with ESP, 670 and a set of transforms; one proposing AH, a 4-byte SPI to be used 671 with AH, and a set of transforms; and one proposing IPcomp, a 2-byte 672 SPI to be used with IPcomp, and a set of transforms. If the recipient 673 selects that proposal number, it means that SAs will be created for 674 all of ESP, AH, and IPcomp. 676 In IKEv2, since the Initiator sends her Diffie-Hellman value in the 677 IKE_SA_init, she must guess at the Diffie-Hellman group that Bob will 678 select from her list of supported groups. Her guess MUST be the first 679 in the list to allow Bob to unambiguously identify which group the 680 accompanying KE payload is from. If her guess is incorrect then Bob's 681 response informs her of the group he would choose, and notifies her 682 that her offer is invalid because the KE payload is not from the 683 desired group. In this case Alice will send a new IKE_SA_init, with 684 the same original choices in the list (this is important to prevent 685 an active attacker from tricking them into using a weaker group than 686 they would have agreed upon) but with Bob's preferred group first, 687 and a KE payload containing an exponential from that group. 689 Harkins Kaufman Perlman [Page 14]^L 690 If none of Alice's options are acceptable, then Bob notifies her 691 accordingly. 693 2.8 Rekeying 695 Security associations negotiated in both phase 1 and phase 2 contain 696 secret keys which may only be used for a limited amount of time. This 697 determines the lifetime of the entire security association. When the 698 lifetime of a security association expires the security association 699 MUST NOT be used. If there is demand, new security associations can 700 be established. Reestablishment of security associations to take the 701 place of ones which expire is referred to as "rekeying". 703 To rekey a child-SA, create a new, equivalent SA (see section 4 and 704 4.1 below), and when the new one is established, delete the old one. 705 To rekey an IKE-SA, establish a new equivalent IKE-SA (see section 4 706 and 4.2 below) with the peer to whom the old IKE-SA is shared using a 707 Phase 2 negotiation within the existing IKE-SA. An IKE-SA so created 708 inherits all of the original IKE-SA's child SAs. Use the new IKE-SA 709 for all control messages needed to maintain the child-SAs created by 710 the old IKE-SA, and delete the old IKE-SA. 712 SAs SHOULD be rekeyed proactively, i.e., the new SA should be 713 established before the old one expires and becomes unusable. Enough 714 time should elapse between the time the new SA is established and the 715 old one becomes unusable so that traffic can be switched over to the 716 new SA. 718 A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes 719 were negotiated. In IKEv2, each end of the SA is responsible for 720 enforcing its own lifetime policy on the SA and rekeying the SA when 721 necessary. If the two ends have different lifetime policies, the end 722 with the shorter lifetime will end up always being the one to request 723 the rekeying. 725 If the two ends have the same lifetime policies, it is possible that 726 both will initiate a rekeying at the same time (which will result in 727 redundant SAs). To reduce the probability of this happening, the 728 timing of rekeying requests should be jittered (delayed by a random 729 amount of time). 731 This form of rekeying will temporarily result in multiple similar SAs 732 between the same pairs of nodes. When there are two SAs eligible to 733 receive packets, a node MUST accept incoming packets through either 734 SA. The node that initiated the rekeying SHOULD delete the older SA 735 after the new one is established. 737 Harkins Kaufman Perlman [Page 15]^L 738 2.9 Traffic Selector Negotiation 740 When an IP packet is received by an RFC2401 compliant IPsec subsystem 741 and matches a "protect" selector in its SPD, the subsystem MUST 742 protect that packet with IPsec. When no SA exists yet it is the task 743 of IKE to create it. Information about the traffic that needs 744 protection is transmitted to the IKE subsystem in a manner outside 745 the scope of this document (see [PFKEY] for an example). This 746 information is negotiated between the two IKE endpoints using TS 747 (Traffic Selector) payloads. 749 The TS payload consists of a set of individual traffic selectors. 750 The selector from the SPD has "source" and "destination" components 751 and these are represented in IKE as a pair of TS payloads, TSi 752 (traffic selector-initiator) and TSr (traffic selector-responder). 753 TSi describes the addresses and ports that the Initiator will send 754 from over the SA and which it will accept packets for. TSr describes 755 the addresses and ports that the Initiator will sent to over the SA 756 and which it will accept packets from. 758 The Responder is allowed to narrow the choices by selecting a subset 759 of the traffic, for instance by eliminating one or more members of 760 the set of traffic selectors provided the set does not become the 761 NULL set. 763 Note that the traffic selectors apply to both child-SAs (from the 764 Initiator to the Responder and from the Responder to the Initiator), 765 but the Responder does not change the order of the TS payloads. An 766 address within the selector of TSi would appear as a source address 767 in the child-SA from the Initiator, and would appear as a destination 768 address in traffic on the child-SA to the Initiator (from the 769 Responder). 771 IKEv2 is more flexible than IKEv1. IKEv2 allows sets of ranges of 772 both addresses and ports, and allows the Responder to choose a subset 773 of the requested traffic rather than simply responding "not 774 acceptable". 776 2.10 Nonces 778 The IKE_SA_init_request and the IKE_SA_init_response each contain a 779 nonce. These nonces are used as inputs to cryptographic functions. 780 The child-create-request and the child-create-response also contain a 781 nonce. These nonces are used to add freshness to the key derivation 782 technique used to obtain keys for child SAs. Nonces used in IKEv2 783 MUST therefore have strong pseudo-random properties (see RFC1715). 785 Harkins Kaufman Perlman [Page 16]^L 786 2.11 Address and Port Agility 788 IKE runs over UDP port 500, and implicitly sets up ESP, AH, and 789 IPcomp associations for the same IP addresses it runs over. The IP 790 addresses and ports in the outer header are, however, not themselves 791 cryptographically protected, and IKE is designed to work even through 792 Network Address Translation (NAT) boxes. An implementation MUST 793 accept incoming connection requests even if not received from UDP 794 port 500, and should respond to the address and port from which the 795 request was received. An implementation MUST, however, accept 796 incoming requests only on UDP port 500 and send all responses from 797 UDP port 500. IKE functions identically over IPv4 or IPv6. 799 3 The Phase 1 Exchange 801 The base Phase 1 exchange is a four message exchange (two 802 request/response pairs). The first pair of messages, the IKE_SA_init 803 exchange, negotiate cryptographic algorithms, (optionally) indicate 804 trusted CA names, exchange nonces, and do a Diffie-Hellman exchange. 805 This pair might be repeated if the response indicates that none of 806 the cryptographic proposals are acceptable, or the Diffie-Hellman 807 group chosen by the Initiator for sending her Diffie-Hellman value is 808 not the group that the Responder would have chosen, of if the 809 Responder is under attack and will only answer IKE_SA_init requests 810 containing a valid returned cookie value. 812 The second pair of messages, the IKE_auth and the IKE_auth_response, 813 authenticate the previous messages, exchange identities and 814 certificates, and establish the first child_SA. This pair of messages 815 is encrypted with a key established through the IKE_SA_init exchange, 816 so the identities are hidden from eavesdroppers. 818 In the following description, the payloads contained in the message 819 are indicated by names such as SA. The details of the contents of 820 each payload are described later. Payloads which may optionally 821 appear will be shown in brackets, such as [CERTREQ], would indicate 822 that optionally a certificate request payload can be included. The 823 certificate request payload indicates a CA name trusted by the 824 sender. If the sender trusts multiple CAs, it includes multiple 825 CERTREQ payloads, one for each trusted CA. 827 The Phase 1 exchange is as follows: 829 Initiator Responder 830 ----------- ----------- 831 HDR, SAi, KEi, Ni, [CERTREQ] --> 833 The SAi payload states the cryptographic algorithms the Initiator 835 Harkins Kaufman Perlman [Page 17]^L 836 supports. The KE payload sends the Initiator's Diffie-Hellman value. 837 Ni is the Initiator's nonce. 839 <-- HDR, SAr, KEr, Nr, [CERTREQ] 841 The Responder chooses among the Initiator's cryptographic algorithms 842 and expresses that choice in the SAr payload, completes the Diffie- 843 Hellman exchange with the KEr payload, and sends its nonce in the Nr 844 payload 846 At this point in time each party generates SKEYSEED and its 847 derivatives. The following two messages, the SA_auth and 848 SA_auth_response, are encrypted and integrity protected (as indicated 849 by the '*' following the IKE header) and the encryption bit in the 850 IKE header is set. 852 HDR*, IDi, [CERT,] AUTH, 853 SAi2, TSi, TSr --> 855 The Initiator identifies herself with the IDi payload, optionally 856 sends one or more certificates, authenticates herself to the 857 Responder with the AUTH payload, and begins negotiation of a child-SA 858 using the SA2 payload. The fields starting with SAi2 are described in 859 the description of Phase 2. 861 <-- HDR*, IDr, [CERT,] AUTH, 862 SAr2, TSi, TSr 864 The Responder identifies himself with an ID payload optionally sends 865 one or more certificates, authenticates himself with the AUTH 866 payload, and completes negotiation of a child-SA with the additional 867 fields described below in the phase 2 exchange. 869 3.1 Generating Keying Material for the IKE-SA 871 The shared secret information is computed as follows. A quantity 872 called SKEYSEED is calculated from the nonces exchanged during the 873 IKE_SA_init exchange, and the Diffie-Hellman shared secret 874 established during that exchange. SKEYSEED is used to calculate 875 three other secrets: SK_d used for deriving new keys for the child- 876 SAs established with this IKE-SA; SK_a used for authenticating the 877 component messages of subsequent exchanges; and SK_e used for 878 encrypting (and of course decrypting) all subsequent exchanges. 879 SKEYSEED and its derivatives are computed as follows: 881 Harkins Kaufman Perlman [Page 18]^L 882 SKEYSEED = prf(Ni | Nr, g^ir) 883 SK_d = prf(SKEYSEED, g^ir | Ni | Nr | CKY-I | CKY-R | 0) 884 SK_a = prf(SKEYSEED, SK_d | g^ir | Ni | Nr | CKY-I | CKY-R | 1) 885 SK_e = prf(SKEYSEED, SK_a | g^ir | Ni | Nr | CKY-I | CKY-R | 2) 887 CKY-I and CKY-R are the Initiator's and Responder's cookies, 888 respectively, from the IKE header. g^ir is the shared secret from the 889 ephemeral Diffie-Hellman exchange. Ni and Nr are the nonces, 890 stripped of any headers. 0, 1, and 2 are represented by a single byte 891 containing the value 0, 1, or 2 (the values, not the ASCII 892 representation of the digits). prf is the "pseudo-random" 893 cryptographic function negotiated in the IKE-SA-init exchange. 895 The two directions of flow use different keys. Keys used to protect 896 messages from the original initiator are taken from the first bits of 897 SK_a and SK_e. Keys used to protect messages in the other direction 898 are taken from subsequent bits. This will most likely require both 899 SK_a and SK_e to be expanded as follows. 901 For situations where the amount of keying material desired is greater 902 than that supplied by the prf, KEYMAT is expanded by feeding the 903 results of the prf back into itself and concatenating results until 904 the required keying material has been reached. In other words, 906 KEYMAT = K1 | K2 | K3 | ... 907 where: 908 K1 = prf(SK_x, 0) 909 K2 = prf(SK_x, K1) 910 K3 = prf(SK_x, K2) 911 etc. 913 where 0 is represented by a single byte containing the value 0 (the 914 value, not the ASCII representation of the digit), and SK_x is either 915 SK_e or SK_a depending on which keying material needs expansion. 917 3.2 Authentication of the IKE-SA 919 The peers are authenticated by having each sign (or MAC using a 920 shared secret as the key) the concatenation of their own first 921 message and the other peer's nonce. The bytes to be signed start 922 with the first byte of the header and end with the last byte of the 923 last payload. The bytes of the nonce are only the content and not the 924 header. 926 Note that all of payloads of the peer's own first message are 927 included under the signature, including payload types not defined in 928 this document. It is possible that some other payloads defined in 929 the future might appropriately be zeroed before signing, but such a 931 Harkins Kaufman Perlman [Page 19]^L 932 possibility is not supported by this version of IKE. 934 Optionally, messages 3 and 4 MAY include a certificate, or 935 certificate chain providing evidence that the key used to compute a 936 digital signature belongs to the name in the ID payload. The 937 signature or MAC will be computed using algorithms dictated by the 938 type of key used by the signer, an RSA-signed PKCS1-padded-SHA1-hash 939 for an RSA digital signature, a DSS-signed SHA1-hash for a DSA 940 digital signature, or the negotiated PRF function for a pre-shared 941 key. There is no requirement that the Initiator and Responder sign 942 with the same cryptographic algorithms. The choice of cryptographic 943 algorithms depends on the type of key each has. This type is either 944 indicated in the certificate supplied or, if the keys were exchanged 945 out of band, the key types must have been similarly learned. It will 946 commonly be the case, but it is not required that if a shared secret 947 is used for authentication that the same key is used in both 948 directions. In particular, the initiator may be using a shared key 949 derived from a password while the responder may have a public 950 signature key and certificate. 952 4 The CREATE-CHILD-SA (Phase 2) Exchange 954 A phase 2 exchange is one request/response pair, and can be used to 955 create or delete a child-SA, delete or rekey the IKE-SA, or deliver 956 information such as error conditions. It is encrypted and integrity 957 protected using the keys negotiated during the creation of the IKE- 958 SA. 960 Messages are cryptographically protected using the cryptographic 961 algorithms and keys negotiated in the first two messages of the IKE 962 exchange using a syntax described in Appendix B. Encryption uses 963 keys derived from SK_e, one in each direction; Integrity uses keys 964 derived from SK_a, one in each direction. 966 Either side may initiate a phase 2 exchange. A child-SA is created by 967 sending a CREATE_CHILD_SA request. If PFS for the child-SA is 968 desired, the CREATE_CHILD_SA request contains KE payloads for an 969 additional Diffie-Hellman exchange. The keying material for the 970 child-SA is a function of SK_d established during the establishment 971 of the IKE-SA, the nonces exchanged during the CREATE_CHILD_SA 972 exchange, and the Diffie-Hellman value (if KE payloads are included 973 in the CREATE_CHILD_SA exchange). If the Diffie-Hellman group for the 974 child-SA is desired to be different from the group for the IKE-SA, 975 then a Diffie-Hellman group transform MUST be included in the SA 976 payload. If it is absent, the Diffie-Hellman group is assumed to be 977 the same as the one used in establishing the IKE-SA. In the child-SA 978 created as part of the phase 1 exchange, a second KE payload MUST NOT 979 be used, and the Nonces are not transmitted but are assumed to be the 981 Harkins Kaufman Perlman [Page 20]^L 982 same as the phase 1 nonces. 984 The CREATE_CHILD_SA request contains: 986 Initiator Responder 987 ----------- ----------- 988 HDR*, SA, Ni, [KEi], 989 TSi, TSr --> 991 The Initiator sends SA offer(s) in the SA payload(s), a nonce in the 992 Ni payload, optionally a Diffie-Hellman value in the KE payload, and 993 the proposed traffic selectors in the TSi and TSr payloads. 995 The message past the header is encrypted and the message including 996 the header is integrity protected using the cryptographic algorithms 997 negotiated in Phase 1. 999 The CREATE_CHILD_SA response contains: 1001 <-- HDR*, SA, Nr, [KEr], 1002 TSi, TSr 1004 The Responder replies (using the same Message ID to respond) with the 1005 accepted offer in an SA payload, a Diffie-Hellman value in the KE 1006 payload if and only if the Initiator included one, and the traffic 1007 selectors for traffic to be sent on that SA in the TS payloads, which 1008 may be a subset of what the Initiator of the child-SA proposed. 1010 4.1 Generating Keying Material for IPsec SAs 1012 Child-SAs are created either by being piggybacked on the phase 1 1013 exchange, or in a phase 2 CREATE_CHILD_SA exchange. Keying material 1014 for them is generated as follows: 1016 KEYMAT = prf(SK_d, protocol | SPI | Nin | Nout ) 1018 For phase 2 exchanges with PFS the keying material is defined as: 1020 KEYMAT = prf(SK_d, g(p2)^ir | protocol | SPI | Nin | Nout ) 1022 where g(p2)^ir is the shared secret from the ephemeral Diffie-Hellman 1023 exchange of this phase 2 exchange, 1025 In either case, "protocol", and "SPI", are from the SA payload that 1026 contained the negotiated (and accepted) proposal, Nin is the body of 1027 the sender's (inbound using thie SPI) nonce payload minus the generic 1028 header, and Nout is the body of the destination's (outbound using 1029 this SPI) nonce payload minus the generic header. 1031 Harkins Kaufman Perlman [Page 21]^L 1032 A single child-SA negotiation results in two security associations-- 1033 one inbound and one outbound. Different Nonces and SPIs for each SA 1034 (one chosen by the Initiator, the other by the Responder) guarantee a 1035 different key for each direction. The SPI chosen by the destination 1036 of the SA and the Nonces (ordered source followed by destination) are 1037 used to derive KEYMAT for that SA. 1039 For situations where the amount of keying material desired is greater 1040 than that supplied by the prf, KEYMAT is expanded by feeding the 1041 results of the prf back into itself and concatenating results until 1042 the required keying material has been reached. In other words, 1044 KEYMAT = K1 | K2 | K3 | ... 1045 where: 1046 K1 = prf(SK_d, [ g(p2)^ir | ] protocol | SPI | Nin | Nout) 1047 K2 = prf(SK_d, K1 | [ g(p2)^ir | ] protocol | SPI | Nin | Nout) 1048 K3 = prf(SK_d, K2 | [ g(p2)^ir | ] protocol | SPI | Nin | Nout) 1049 etc. 1051 This keying material (whether with PFS or without) MUST be used with 1052 the negotiated SA. In the case of an ESP SA needing two keys for 1053 encryption and authentication, the encryption key is taken from the 1054 first bytes of KEYMAT and the authentication key is taken from the 1055 next bytes. 1057 4.2 Generating Keying Material for IKE-SAs from a create-child exchange 1059 The create-child exchange can be used to re-key an existing IKE-SA 1060 (see section 2.8). New Initiator and Responder cookies are supplied 1061 in the SPI fields. The ID and TS payloads are omitted when rekeying 1062 an IKE-SA. SKEYSEED for the new IKE-SA is computed using SK_d from 1063 the existing IKE-SA as follows: 1065 SKEYSEED = prf(SK_d (old), [g(p2)^ir] | 0 | CKY-I | CKY-R | Ni | 1066 Nr) 1068 where g(p2)^ir is the shared secret from the ephemeral Diffie-Hellman 1069 exchange of this phase 2 exchange, CKY-I is the 8-byte "SPI" from the 1070 SA payload in the CREATE_CHILD_SA request, CKY-R is the 8-byte "SPI" 1071 from the SA payload in the CREATE_CHILD_SA response, and Ni and Nr 1072 are the two nonces stripped of any headers. "0" is a single byte 1073 containing the value zero (the protocol ID of IKE). 1075 The new IKE SA MUST reset its message counters to 1. 1077 SK_d, SK_a, and SK_e are computed from SKEYSEED as specified in 1078 section 3.1. 1080 Harkins Kaufman Perlman [Page 22]^L 1081 5 Informational (Phase 2) Exchange 1083 At various points during an IKE-SA, peers may desire to convey 1084 control messages to each other regarding errors or notifications of 1085 certain events. To accomplish this IKE defines a (reliable) 1086 Informational exchange. Usually Informational exchanges happen 1087 during phase 2 and are cryptographically protected with the IKE 1088 exchange. 1090 Control messages that pertain to an IKE-SA MUST be sent under that 1091 IKE-SA. Control messages that pertain to Child-SAs MUST be sent under 1092 the protection of the IKE-SA which generated them (or its successor 1093 if the IKE-SA keys are rolled over). 1095 There are two cases in which there is no IKE-SA to protect the 1096 information. One is in the response to an IKE_SA_init_request to 1097 request a cookie or to refuse the SA proposal. This would be conveyed 1098 in a Notify payload of the IKE_SA_init_response. 1100 The other case in which there is no IKE-SA to protect the information 1101 is when a packet is received with an unknown SPI. In that case the 1102 notification of this condition will be sent in an informational 1103 exchange that is cryptographically unprotected. 1105 Messages in an Informational Exchange contain zero or more 1106 Notification or Delete payloads. The Recipient of an Informational 1107 Exchange request MUST send some response (else the Sender will assume 1108 the message was lost in the network and will retransmit it). That 1109 response can be a message with no payloads. Actually, the request 1110 message in an Informational Exchange can also contain no payloads. 1111 This is the expected way an endpoint can ask the other endpoint to 1112 verify that it is alive. 1114 ESP, AH, and IPcomp SAs always exist in pairs, with one SA in each 1115 direction. When an SA is closed, both members of the pair MUST be 1116 closed. When SAs are nested, as when data is encapsulated first with 1117 IPcomp, then with ESP, and finally with AH between the same pair of 1118 endpoints, all of the SAs (up to six) must be deleted together. To 1119 delete an SA, an Informational Exchange with one or more delete 1120 payloads is sent listing the SPIs (as known to the recipient) of the 1121 SAs to be deleted. The recipient MUST close the designated SAs. 1122 Normally, the reply in the Informational Exchange will contain delete 1123 payloads for the paired SAs going in the other direction. There is 1124 one exception. If by chance both ends of a set of SAs independently 1125 decide to close them, each may send a delete payload and the two 1126 requests may cross in the network. If a node receives a delete 1127 request for SAs that it has already issued a delete request for, it 1128 MUST delete the incoming SAs while processing the request and the 1130 Harkins Kaufman Perlman [Page 23]^L 1131 outgoing SAs while processing the response. In that case, the 1132 responses MUST NOT include delete payloads for the deleted SAs, since 1133 that would result in duplicate deletion and could in theory delete 1134 the wrong SA. 1136 A node SHOULD regard half open connections as anomalous and audit 1137 their existence should they persist. Note that this specification 1138 nowhere specifies time periods, so it is up to individual endpoints 1139 to decide how long to wait. A node MAY refuse to accept incoming data 1140 on half open connections but MUST NOT unilaterally close them and 1141 reuse the SPIs. If connection state becomes sufficiently messed up, a 1142 node MAY close the IKE-SA which will implicitly close all SAs 1143 negotiated under it. It can then rebuild the SA's it needs on a clean 1144 base under a new IKE-SA. 1146 The Informational Exchange is defined as: 1148 Initiator Responder 1149 ----------- ----------- 1150 HDR*, N, ..., D, ... --> 1151 <-- HDR*, N, ..., D, ... 1153 The processing of an Informational Exchange is determined by its 1154 component payloads. 1156 6 Error Handling 1158 There are many kinds of errors that can occur during IKE processing. 1159 If a request is received that is badly formatted or unacceptable for 1160 reasons of policy (e.g. no matching cryptographic algorithms), the 1161 response MUST contain a Notify payload indicating the error. If an 1162 error occurs outside the context of an IKE request (e.g. the node is 1163 getting ESP messages on a non-existent SPI), the node SHOULD initiate 1164 an Informational Exchange with a Notify payload describing the 1165 problem. 1167 Errors that occur before a cryptographically protected IKE-SA is 1168 established must be handled very carefully. There is a trade-off 1169 between wanting to be helpful in diagnosing a problem and responding 1170 to it and wanting to avoid being a dupe in a denial of service attack 1171 based on forged messages. 1173 If a node receives a message on UDP port 500 outside the context of 1174 an IKE-SA (and not a request to start one), it may be the result of a 1175 recent crash. If the message is marked as a response, the node MAY 1176 audit the suspicious event but MUST NOT respond. If the message is 1177 marked as a request, the node MAY audit the suspicious event and MAY 1178 send a response. If a response is sent, the response MUST be sent to 1180 Harkins Kaufman Perlman [Page 24]^L 1181 the IP address from whence it came with the IKE cookies reversed in 1182 the header and the Message ID copied. The response MUST NOT be 1183 cryptographically protected and MUST contain a notify payload 1184 indicating the nature of the problem. 1186 A node receiving such a message MUST NOT respond and MUST NOT change 1187 the state of any existing SAs. The message might be a forgery or 1188 might be a response the genuine correspondent was tricked into 1189 sending. A node SHOULD treat such a message (and also a network 1190 message like ICMP destination unreachable) as a hint that there might 1191 be problems with SAs to that IP address and SHOULD initiate a 1192 liveness test for any such IKE-SA. An implementation SHOULD limit the 1193 frequency of such tests to avoid being tricked into participating in 1194 a denial of service attack. 1196 A node receiving a suspicious message from an IP address with which 1197 it has an IKE-SA MAY send an IKE notify payload in an IKE 1198 Informational exchange over that SA. The recipient MUST NOT change 1199 the state of any SA's as a result but SHOULD audit the event to aid 1200 in diagnosing malfunctions. A node MUST limit the rate at which it 1201 will send messages in response to unprotected messages. 1203 7 Header and Payload Formats 1205 7.1 The IKE Header 1207 IKE messages use UDP port 500, with one IKE message per UDP datagram. 1208 Information from the UDP header is largely ignored except that the IP 1209 addresses and UDP ports from the headers are reversed and used for 1210 return packets. Each IKE message begins with the IKE header, denoted 1211 HDR in this memo. Following the header are one or more IKE payloads 1212 each identified by a "Next Payload" field in the preceding payload. 1213 Payloads are processed in the order in which they appear in an IKE 1214 message by invoking the appropriate processing routine according to 1215 the "Next Payload" field in the IKE header and subsequently according 1216 to the "Next Payload" field in the IKE payload itself until a "Next 1217 Payload" field of zero indicates that no payloads follow. 1219 The Recipient SPI in the header identifies an instance of an IKE 1220 security association. It is therefore possible for a single instance 1221 of IKE to multiplex distinct sessions with multiple peers. 1223 Harkins Kaufman Perlman [Page 25]^L 1224 The format of the IKE header is shown in Figure 1. 1225 1 2 3 1226 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 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 ! Recipient ! 1229 ! SPI (aka Cookie) ! 1230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1231 ! Sender ! 1232 ! SPI (aka Cookie) ! 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1234 ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! 1235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 ! Message ID ! 1237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 ! Length ! 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 ~ Initialization Vector ~ 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1243 Figure 1: IKE Header Format 1245 o Recipient SPI (aka Cookie) (8 bytes) - A value chosen by the 1246 recipient to identify a unique IKE security association. 1247 [NOTE: this is a deviation from ISAKMP and IKEv1, where the 1248 cookies were always sent with the Initiator of the IKE-SA's 1249 cookie first and the Responder's second. See section 2.6.] 1251 o Sender SPI (aka Cookie) (8 bytes) - A value chosen by the 1252 sender to identify a unique IKE security association. 1254 o Next Payload (1 byte) - Indicates the type of payload that 1255 immediately follows the header. The format and value of each 1256 payload is defined below. 1258 o Major Version (4 bits) - indicates the major version of the IKE 1259 protocol in use. Implementations based on this version of IKE 1260 MUST set the Major Version to 2. Implementations based on 1261 previous versions of IKE and ISAKMP MUST set the Major Version 1262 to 1. Implementations based on this version of IKE MUST reject 1263 (or ignore) messages containing a version number greater than 1264 2. 1266 o Minor Version (4 bits) - indicates the minor version of the 1267 IKE protocol in use. Implementations based on this version of 1268 IKE MUST set the Minor Version to 0. They MUST ignore the minor 1269 version number of received messages. 1271 o Exchange Type (1 byte) - indicates the type of exchange being 1273 Harkins Kaufman Perlman [Page 26]^L 1274 used. This dictates the payloads sent in each message and 1275 message orderings in the exchanges. 1277 Exchange Type Value 1279 RESERVED 0 1280 Reserved for ISAKMP 1 - 31 1281 Reserved for IKEv1 32 - 33 1282 Phase One 34 1283 CREATE-CHILD-SA 35 1284 Informational 36 1285 Reserved for IKEv2+ 37-239 1286 Reserved for private use 240-255 1288 o Flags (1 byte) - indicates specific options that are set for 1289 the message. Presence of options are indicated by the 1290 appropriate bit in the flags field being set. The bits are 1291 defined LSB first, so bit 0 would be the least significant 1292 bit of the Flags byte. 1294 -- E(ncryption) (bit 0 of Flags) - If set, all payloads 1295 following the header are encrypted and integrity 1296 protected using the algorithms negotiated during 1297 session establishment and a key derived during the key 1298 exchange portion of IKE. If not set, the payloads are 1299 not protected. All payloads MUST be protected if a key 1300 has been negotiated and any unprotected payload may 1301 only be used to establish a new session or indicate a 1302 problem. 1304 -- C(ommit) (bit 1 of Flags) - This bit is defined by 1305 ISAKMP but not used by IKEv2. Implementations of IKEv2 1306 MUST clear this bit when sending and SHOULD ignore it 1307 in incoming messages. 1309 -- A(uthentication Only) (bit 2 of Flags) - This bit is 1310 defined by ISAKMP but not used by IKEv2. Implementations 1311 of IKEv2 MUST clear this bit when sending and SHOULD 1312 ignore it in incoming messages. 1314 -- I(nitiator) (bit 3 of Flags) - This bit MUST be set in 1315 messages sent by the Initiator of an exchange and MUST 1316 be cleared in messages sent by the Responder. It is 1317 used by the recipient to determine whether the message 1318 number should be interpreted in the context of its 1319 initiating state or its responding state. 1321 -- V(ersion) (bit 4 of Flags) - This bit indicates that 1323 Harkins Kaufman Perlman [Page 27]^L 1324 the transmitter is capable of speaking a higher major 1325 version number of the protocol than the one indicated 1326 in the major version number field. 1328 -- R(eserved) (bits 5-7 of Flags) - These bit MUST be 1329 cleared in messages sent and received messages with 1330 these bits set MUST be rejected. 1332 o Message ID (4 bytes) - Message identifier used to control 1333 retransmission of lost packets and matching of requests and 1334 responses. See section 2.2. In the first message of a Phase 1 1335 negotiation, the value MUST be set to 0. The response to that 1336 message MUST also have a Message ID of 0. 1338 o Length (4 bytes) - Length of total message (header + payloads) 1339 in bytes. Session encryption can expand the size of an IKE 1340 message and that is reflected in the total length of the 1341 message. 1343 o Initialization Vector (variable) - random bytes used to provide 1344 initialization to an encryption mode-- e.g. 1345 cipher block chaining (CBC) mode. This field MUST be present 1346 when the encryption bit is set in the flags field (see below) 1347 and MUST NOT be present otherwise. The length of the 1348 Initialization Vector is cipher and mode dependent. 1350 7.2 Generic Payload Header 1352 Each IKE payload defined in sections 7.3 through 7.13 begins with a 1353 generic header, shown in Figure 2. Figures for each payload below 1354 will include the generic payload header but for brevity a repeat of 1355 the description of each field will be omitted. The construction and 1356 processing of the generic payload header is identical for each 1357 payload and will similarly be omitted. 1359 1 2 3 1360 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 1361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1362 ! Next Payload !C! RESERVED ! Payload Length ! 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 Figure 2: Generic Payload Header 1367 The Generic Payload Header fields are defined as follows: 1369 o Next Payload (1 byte) - Identifier for the payload type of the 1370 next payload in the message. If the current payload is the last 1371 in the message, then this field will be 0. This field provides 1373 Harkins Kaufman Perlman [Page 28]^L 1374 a "chaining" capability whereby additional payloads can be 1375 added to a message by appending it to the end of the message 1376 and setting the "Next Payload" field of the preceding payload 1377 to indicate the new payload's type. 1379 o Critical (1 bit) - MUST be set to zero if the sender wants 1380 the recipient to skip this payload if he does not 1381 understand the payload type code. MUST be set to one if the 1382 sender wants the recipient to reject this entire message 1383 if he does not understand this payload type. MUST be ignored 1384 by recipient if the recipient understands the payload type 1385 code. MUST be set to zero for payload types defined in this 1386 document. Note that the critical bit applies to the current 1387 payload rather than the "next" payload whose type code 1388 appears in the first byte. 1390 o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored. 1392 o Payload Length (2 bytes) - Length in bytes of the current 1393 payload, including the generic payload header. 1395 7.3 Security Association Payload 1397 The Security Association Payload, denoted SA in this memo, is used to 1398 negotiate attributes of a security association. Assembly of Security 1399 Association Payloads requires great peace of mind. An SA may contain 1400 multiple proposals. Each proposal may contain multiple protocols 1401 (where a protocol is IKE, ESP, AH, or IPCOMP), each protocol may 1402 contain multiple transforms, and each transform may contain multiple 1403 attributes. When parsing an SA, an implementation MUST check that the 1404 total Payload Length is consistent with the payload's internal 1405 lengths and counts. Proposals, Transforms, and Attributes each have 1406 their own variable length encodings. They are nested such that the 1407 Payload Length of an SA includes the combined contents of the SA, 1408 Proposal, Transform, and Attribute information. The length of a 1409 Proposal includes the lengths of all Transforms and Attributes it 1410 contains. The length of a Transform includes the lengths of all 1411 Attributes it contains. 1413 The syntax of Security Associations, Proposals, Transforms, and 1414 Attributes is based on ISAKMP, however the semantics are somewhat 1415 different. The reason for the complexity and the hierarchy is to 1416 allow for multiple possible combinations of algorithms to be encoded 1417 in a single SA. Sometimes there is a choice of multiple algorithms, 1418 while other times there is a combination of algorithms. For example, 1419 an Initiator might want to propose using (AH w/MD5 and ESP w/3DES) OR 1420 (ESP w/MD5 and 3DES). 1422 Harkins Kaufman Perlman [Page 29]^L 1423 One of the reasons the semantics of the SA payload has changed from 1424 ISAKMP and IKEv1 is to make the encodings more compact in common 1425 cases. 1427 The Proposal structure contains within it a Proposal # and a 1428 Protocol-id. Each structure MUST have the same Proposal # as the 1429 previous one or one greater. The first Proposal MUST have a Proposal 1430 # of one. If two successive structures have the same Proposal number, 1431 it means that the proposal consists of the first structure AND the 1432 second. So a proposal of AH AND ESP would have two proposal 1433 structures, one for AH and one for ESP and both would have Proposal 1434 #1. A proposal of AH OR ESP would have two proposal structures, one 1435 for AH with proposal #1 and one for ESP with proposal #2. 1437 Each Proposal/Protocol structure is followed by one or more transform 1438 structures. The number of different transforms is generally 1439 determined by the Protocol. AH generally has a single transform: an 1440 integrity check algorithm. ESP generally has two: an encryption 1441 algorithm AND an integrity check algorithm. IKE generally has five 1442 transforms: a Diffie-Hellman group, an authentication algorithm, an 1443 integrity check algorithm, a PRF algorithm, and an encryption 1444 algorithm. For each Protocol, the set of permissible transforms are 1445 assigned transform ID numbers, which appear in the header of each 1446 transform. 1448 If there are multiple transforms with the same Transform Type, the 1449 proposal is an OR of those transforms. If there are multiple 1450 Transforms with different Transform Types, the proposal is an AND of 1451 the different groups. For example, to propose ESP with (3DES or IDEA) 1452 and (HMAC-MD5 or HMAC-SHA), the ESP proposal would contain two 1453 Transform Type 1 candidates (one for 3DES and one for IDEA) and two 1454 Transform Type 2 candidates (one for HMAC-MD5 and one for HMAC-SHA). 1455 This effectively proposes four combinations of algorithms. If the 1456 Initiator wanted to propose only a subset of those - say (3DES and 1457 HMAC-MD5) or (IDEA and HMAC-SHA), there is no way to encode that as 1458 multiple transforms within a single Proposal/Protocol. Instead, the 1459 Initiator would have to construct two different Proposals, each with 1460 two transforms. 1462 A given transform MAY have one or more Attributes. Attributes are 1463 necessary when the transform can be used in more than one way, as 1464 when an encryption algorithm has a variable key size. The transform 1465 would specify the algorithm and the attribute would specify the key 1466 size. Most transforms do not have attributes. 1468 Note that the semantics of Transforms and Attributes are quite 1469 different than in IKEv1. In IKEv1, a single Transform carried 1470 multiple algorithms for a protocol with one carried in the Transform 1472 Harkins Kaufman Perlman [Page 30]^L 1473 and the others carried in the Attributes. 1475 1 2 3 1476 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 1477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1478 ! Next Payload !C! RESERVED ! Payload Length ! 1479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1480 ! ! 1481 ~ ~ 1482 ! ! 1483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1485 Figure 3: Security Association Payload 1487 o Proposals (variable) - one or more proposal substructures. 1489 The payload type for the Security Association Payload is one (1). 1491 7.3.1 Proposal Substructure 1493 1 2 3 1494 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 1495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1496 ! 0 (last) or 2 ! RESERVED ! Proposal Length ! 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 ! Proposal # ! Protocol-Id ! SPI Size !# of Transforms! 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 ~ SPI (variable) ~ 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1502 ! ! 1503 ~ ~ 1504 ! ! 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1507 Figure 4: Proposal Substructure 1509 o 0 (last) or 2 (more) (1 byte) - Specifies whether this is the 1510 last Proposal Substructure in the SA. This syntax is inherited 1511 from ISAKMP, but is unnecessary because the last Proposal 1512 could be identified from the length of the SA. The value (2) 1513 corresponds to a Payload Type of Proposal, and the first 1514 four bytes of the Proposal structure are designed to look 1515 somewhat like the header of a Payload. 1517 o RESERVED (1 byte) - MUST be sent as zero; MUST be ignored. 1519 o Proposal Length (2 bytes) - Length of this proposal, 1520 including all transforms and attributes that follow. 1522 Harkins Kaufman Perlman [Page 31]^L 1523 o Proposal # (1 byte) - When a proposal is made, the first 1524 proposal in an SA MUST be #1, and subsequent proposals 1525 MUST either be the same as the previous proposal (indicating 1526 an AND of the two proposals) or one more than the previous 1527 proposal (indicating an OR of the two proposals). When a 1528 proposal is accepted, all of the proposal numbers in the 1529 SA must be the same and must match the number on the 1530 proposal sent that was accepted. 1532 o Protocol-Id (1 byte) - Specifies the protocol identifier 1533 for the current negotiation. During phase 1 negotiation 1534 this field MUST be zero (0). During phase 2 it will be the 1535 protocol of the SA being established as assigned by IANA, 1536 for example, 50 for ESP, 51 for AH, and 108 for IPComp. 1538 o SPI Size (1 byte) - During phase 1 negotiation this field 1539 MUST be zero. During phase 2 negotiation it is equal to the 1540 size, in bytes, of the SPI of the corresponding protocol 1541 (8 for IKE, 4 for ESP and AH, 2 for IPcomp). 1543 o # of Transforms (1 byte) - Specifies the number of 1544 transforms in this proposal. 1546 o SPI (variable) - The sending entity's SPI. Even if the SPI 1547 Size is not a multiple of 4 bytes, there is no padding 1548 applied to the payload. When the SPI Size field is zero, 1549 this field is not present in the Security Association 1550 payload. This case occurs when negotiating the IKE-SA 1551 (but not during the rekeying of an IKE-SA). 1553 o Transforms (variable) - one or more transform substructures. 1555 Harkins Kaufman Perlman [Page 32]^L 1556 7.3.2 Transform Substructure 1558 1 2 3 1559 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 1560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1561 ! 0 (last) or 3 ! RESERVED ! Transform Length ! 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 !Transform Type ! RESERVED ! Transform ID ! 1564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1565 ! ! 1566 ~ Transform Attributes ~ 1567 ! ! 1568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1570 Figure 5: Transform Substructure 1572 o 0 (last) or 3 (more) (1 byte) - Specifies whether this is the 1573 last Transform Substructure in the Proposal. This syntax is 1574 inherited from ISAKMP, but is unnecessary because the last 1575 Proposal could be identified from the length of the SA. The 1576 value (3) corresponds to a Payload Type of Transform, and 1577 the first four bytes of the Transform structure are designed 1578 to look somewhat like the header of a Payload. 1580 o RESERVED - MUST be sent as zero; MUST be ignored. 1582 o Transform Length - The length (in bytes) of the Transform 1583 Substructure including Header and Attributes. 1585 o Transform Type (1 byte) - The type of transform being specified 1586 in this transform. Different protocols support different 1587 transform types. For some protocols, some of the transforms 1588 may be optional. 1590 o Transform-ID (1 byte) - The specific instance of the transform 1591 type being proposed. 1593 Harkins Kaufman Perlman [Page 33]^L 1594 Transform Type Values 1596 Transform Used In 1597 Type 1598 Encryption Algorithm 1 (IKE and ESP) 1599 Pseudo-random Function 2 (IKE) 1600 Authentication Method 3 (IKE) 1601 Integrity Algorithm 4 (IKE, AH, and optional in ESP) 1602 Diffie-Hellman Group 5 (IKE and optional in AH and ESP) 1603 Compression 6 (IPcomp) 1604 Window Size 7 (IKE) 1606 values 8-240 are reserved to IANA. Values 241-255 are for 1607 private use among mutually consenting parties. 1609 For Transform Type 1 (Encryption Algorithm), defined Transform-IDs 1610 are: 1612 Name Number Defined In 1613 RESERVED 0 1614 ENCR_DES_IV64 1 (RFC1827) 1615 ENCR_DES 2 (RFC2405) 1616 ENCR_3DES 3 (RFC2451) 1617 ENCR_RC5 4 (RFC2451) 1618 ENCR_IDEA 5 (RFC2451) 1619 ENCR_CAST 6 (RFC2451) 1620 ENCR_BLOWFISH 7 (RFC2451) 1621 ENCR_3IDEA 8 (RFC2451) 1622 ENCR_DES_IV32 9 1623 ENCR_RC4 10 1624 ENCR_NULL 11 (RFC2410) 1625 ENCR_AES_128 12 1627 values 12-240 are reserved to IANA. Values 241-255 are for 1628 private use among mutually consenting parties. 1630 For Transform Type 2 (Pseudo-random Function), defined Transform-IDs 1631 are: 1633 Name Number Defined In 1634 RESERVED 0 1635 PRF_HMAC_MD5 1 (RFC2104) 1636 PRF_HMAC_SHA 2 (RFC2104) 1637 PRF_HMAC_TIGER 3 (RFC2104) 1639 values 3-240 are reserved to IANA. Values 241-255 are for 1640 private use among mutually consenting parties. 1642 Harkins Kaufman Perlman [Page 34]^L 1643 For Transform Type 3 (Authentication Method), defined Transform-IDs 1644 are: 1646 Name Number Defined In 1647 RESERVED 0 1648 RESERVED for IKEv1 1 - 5 (RFC2409) 1649 Authenticated Diffie-Hellman 6 (this memo) 1651 values 7-240 are reserved to IANA. Values 241-255 are for 1652 private use among mutually consenting parties. 1654 For Transform Type 4 (Integrity Algorithm), defined Transform-IDs 1655 are: 1657 Name Number Defined In 1658 RESERVED 0 1659 AUTH_HMAC_MD5 1 (RFC2403) 1660 AUTH_HMAC_SHA 2 (RFC2404) 1661 AUTH_DES_MAC 3 1662 AUTH_KPDK_MD5 4 (RFC1826) 1664 For Transform Type 5 (Diffie-Hellman Group), defined Transform-IDs 1665 are: 1667 Name Number 1668 RESERVED 0 1669 Pre-defined (see section 8) 1 - 5 1670 RESERVED 6 - 200 1671 MODP (exponentiation) 201 (w/attributes) 1672 ECP (elliptic curve over GF[P] 202 (w/attributes) 1673 EC2N (elliptic curve over GF[2^N]) 203 (w/attributes) 1675 values 6-200 are reserved to IANA for new MODP, ECP or EC2N 1676 groups. Values 204-255 are for private use among mutually 1677 consenting parties. Specification of values 201, 202 or 203 1678 allow peers to define a new Diffie-Hellman group in-line as 1679 part of the exchange. Private use of values 204-255 may entail 1680 complete definition of a group or may require attributes to 1681 accompany them. Attributes MUST NOT accompany groups using 1682 values between 6 and 200. 1684 Harkins Kaufman Perlman [Page 35]^L 1685 For Transform Type 6 (Compression), defined Transform-IDs are: 1687 Name Number Defined In 1688 RESERVED 0 1689 IPCOMP_OUI 1 (w/attributes) 1690 IPCOMP_DEFLATE 2 1691 (RFC2394) 1692 IPCOMP_LZS 3 1693 (RFC2395) 1695 values 4-240 are reserved to IANA. Values 241-255 are for 1696 private use among mutually consenting parties. 1698 For Transform Type 7 (Window Size), the Transform-ID specifies the 1699 window size a peer is contracting to support to handle overlapping 1700 requests (see section 2.3). 1702 7.3.3 Mandatory Transform Types 1704 The number and type of transforms that accompany an SA payload are 1705 dependent on the protocol in the SA itself. An SA payload proposing 1706 the establishment of an SA has the following mandatory and optional 1707 transform types. A compliant implementation MUST support all 1708 mandatory and optional types for each protocol it supports. Whether 1709 the optional types are present in a particular proposal depends 1710 solely on the discretion of the sender. 1712 Protocol Mandatory Types Optional Types 1713 IKE 1, 2, 3, 5, 7 1714 ESP 1 4, 5 1715 AH 4 5 1716 IPCOMP 6 1718 7.3.4 Mandatory Transform-IDs 1720 Each transform type has corresponding transform IDs to specify the 1721 specific transform. Some transforms are mandatory to support and 1722 others are optional to support. The mandatory transform IDs for AH, 1723 ESP, and IPCOMP are left to their respective RFCs, RFC2402, RFC2406, 1724 and RFC2393. The transform IDs that are mandatory to support for 1725 IKEv2 are: 1727 Name TransType Mandatory Transform-ID 1728 Encryption Algorithm 1 12 (ENCR_AES_128) 1729 Pseudo-Random Function 2 2 (PRF_HMAC_SHA) 1730 Authentication Method 3 6 (signed D-H) 1731 Diffie-Hellman Group 5 5 (1536 bit MODP) 1732 Window Size 7 1 1734 Harkins Kaufman Perlman [Page 36]^L 1735 All other transform-IDs for a given transform type are optional to 1736 support. While implementations MUST support a window size of 1, they 1737 SHOULD support a window size of at least 10 and MAY support larger 1738 window sizes. 1740 7.3.5 Transform Attributes 1742 Each transform in a Security Association payload may include 1743 attributes that modify or complete the specification of the 1744 transform. These attributes are type/value pairs and are defined in 1745 Appendix A. For example, if an encryption algorithm has a variable 1746 length key, the key length to be used may be specified as an 1747 attribute. Attributes can have a value with a fixed two byte length 1748 or a variable length value. For the latter the attribute is the form 1749 of type/length/value. 1751 1 2 3 1752 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 1753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1754 !A! Attribute Type ! AF=0 Attribute Length ! 1755 !F! ! AF=1 Attribute Value ! 1756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1757 ! AF=0 Attribute Value ! 1758 ! AF=1 Not Transmitted ! 1759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1761 Figure 6: Data Attributes 1763 o Attribute Type (2 bytes) - Unique identifier for each type of 1764 attribute. The identifiers for IKE are defined in Appendix A. 1766 The most significant bit of this field is the Attribute Format 1767 bit (AF). It indicates whether the data attributes follow the 1768 Type/Length/Value (TLV) format or a shortened Type/Value (TV) 1769 format. If the AF bit is zero (0), then the Data Attributes 1770 are of the Type/Length/Value (TLV) form. If the AF bit is a 1771 one (1), then the Data Attributes are of the Type/Value form. 1773 o Attribute Length (2 bytes) - Length in bytes of the Attribute 1774 Value. When the AF bit is a one (1), the Attribute Value is 1775 only 2 bytes and the Attribute Length field is not present. 1777 o Attribute Value (variable length) - Value of the Attribute 1778 associated with the Attribute Type. If the AF bit is a 1779 zero (0), this field has a variable length defined by the 1780 Attribute Length field. If the AF bit is a one (1), the 1781 Attribute Value has a length of 2 bytes. 1783 Harkins Kaufman Perlman [Page 37]^L 1784 7.3.6 Attribute Negotiation 1786 During security association negotiation Initiators present offers to 1787 Responders. Responders MUST select a single complete set of 1788 parameters from the offers (or reject all offers if none are 1789 acceptable). If there are multiple proposals, the Responder MUST 1790 choose a single proposal number and return all of the Proposal 1791 substructures with that Proposal number. If there are multiple 1792 Transforms with the same type the Responder MUST choose a single one. 1793 Any attributes of a selected transform MUST be returned unmodified. 1794 The Initiator of an exchange MUST check that the accepted offer is 1795 consistent with one of its proposals, and if not that response MUST 1796 be rejected. 1798 Negotiating Diffie-Hellman groups presents some special challenges. 1799 Diffie-Hellman groups are specified either using a defined group 1800 description (section 5) or by defining all attributes of a group (see 1801 Appendix A) in an IKE policy offer. Group attributes, such as group 1802 type or prime number MUST NOT be offered in conjunction with a 1803 previously defined group. SA offers include proposed attributes and a 1804 Diffie-Hellman public number (KE) in the same message. If the 1805 Initiator offers to use one of several Diffie-Hellman groups, it 1806 SHOULD pick the one the Responder is most likely to accept and 1807 include a KE corresponding to that group. If the guess turns out to 1808 be wrong, the Responder will indicate the correct group in the 1809 response and the Initiator SHOULD start over this time using a 1810 different group (see section 2.7). 1812 Implementation Note: 1814 Certain negotiable attributes can have ranges or could have 1815 multiple acceptable values. These are the Diffie-Hellman group and 1816 the key length of a variable key length symmetric cipher. To 1817 further interoperability and to support upgrading endpoints 1818 independently, implementers of this protocol SHOULD accept values 1819 which they deem to supply greater security. For instance if a peer 1820 is configured to accept a variable lengthed cipher with a key 1821 length of X bits and is offered that cipher with a larger key 1822 length an implementation SHOULD accept the offer. 1824 Support of this capability allows an implementation to express a 1825 concept of "at least" a certain level of security-- "a key length 1826 of _at least_ X bits for cipher foo". 1828 7.4 Key Exchange Payload 1830 The Key Exchange Payload, denoted KE in this memo, is used to 1831 exchange Diffie-Hellman public numbers as part of a Diffie-Hellman 1833 Harkins Kaufman Perlman [Page 38]^L 1834 key exchange. The Key Exchange Payload consists of the IKE generic 1835 header followed by the Diffie-Hellman public value itself. 1837 1 2 3 1838 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 1839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1840 ! Next Payload !C! RESERVED ! Payload Length ! 1841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1842 ! ! 1843 ~ Key Exchange Data ~ 1844 ! ! 1845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1847 Figure 7: Key Exchange Payload Format 1849 A key exchange payload is constructed by copying one's Diffie-Hellman 1850 public value into the "Key Exchange Data" portion of the payload. 1851 The length of the Diffie-Hellman public value MUST be equal to the 1852 length of the prime modulus over which the exponentiation was 1853 performed, prepending zero bits to the value if necessary. 1855 A key exchange payload is processed by first checking whether the 1856 length of the key exchange data (the "Payload Length" from the 1857 generic header minus the size of the generic header) is equal to the 1858 length of the prime modulus over which the exponentiation was 1859 performed. 1861 The payload type for the Key Exchange payload is four (4). 1863 7.5 Identification Payload 1865 The Identification Payload, denoted ID in this memo, allows peers to 1866 identify themselves to each other. In Phase 1, the ID Payload names 1867 the identity to be authenticated with the signature. In Phase 2, the 1868 ID Payload is optional and if present names an identity asserted to 1869 be responsible for this SA. An example use would be a shared computer 1870 opening an IKE-SA to a server and asserting the name of its logged in 1871 user for the Phase 2 SA. If missing, this defaults to the Phase 1 1872 identity. 1874 NOTE: In IKEv1, two ID payloads were used in each direction in Phase 1875 2 to hold Traffic Selector information for data passing over the SA. 1876 In IKEv2, this information is carried in Traffic Selector (TS) 1877 payloads (see section 7.13). 1879 The Identification Payload consists of the IKE generic header 1880 followed by identification fields as follows: 1882 Harkins Kaufman Perlman [Page 39]^L 1883 1 2 3 1884 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 1885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1886 ! Next Payload !C! RESERVED ! Payload Length ! 1887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1888 ! ID Type ! RESERVED | 1889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1890 ! ! 1891 ~ Identification Data ~ 1892 ! ! 1893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1895 Figure 8: Identification Payload Format 1897 o ID Type (1 byte) - Specifies the type of Identification being 1898 used. 1900 o RESERVED - MUST be sent as zero; MUST be ignored. 1902 o Identification Data (variable length) - Value, as indicated by 1903 the Identification Type. The length of the Identification Data 1904 is computed from the size in the ID payload header. 1906 The payload type for the Identification Payload is five (5). 1908 The following table lists the assigned values for the Identification 1909 Type field, followed by a description of the Identification Data 1910 which follows: 1912 ID Type Value 1913 ------- ----- 1914 RESERVED 0 1916 ID_IPV4_ADDR 1 1918 A single four (4) byte IPv4 address. 1920 ID_FQDN 2 1922 A fully-qualified domain name string. An example of a 1923 ID_FQDN is, "lounge.org". The string MUST not contain any 1924 terminators (e.g. NULL, CR, etc.). 1926 ID_USER_FQDN 3 1928 A fully-qualified username string, An example of a 1929 ID_USER_FQDN is, "lizard@lounge.org". The string MUST not 1930 contain any terminators. 1932 Harkins Kaufman Perlman [Page 40]^L 1933 ID_IPV6_ADDR 5 1935 A single sixteen (16) byte IPv6 address. 1937 ID_DER_ASN1_DN 9 1939 The binary DER encoding of an ASN.1 X.500 Distinguished Name 1940 [X.501]. 1942 ID_DER_ASN1_GN 10 1944 The binary DER encoding of an ASN.1 X.500 GeneralName 1945 [X.509]. 1947 ID_KEY_ID 11 1949 An opaque byte stream which may be used to pass vendor- 1950 specific information necessary to do certain proprietary 1951 forms of identification. 1953 7.6 Certificate Payload 1955 The Certificate Payload, denoted CERT in this memo, provides a means 1956 to transport certificates or other certificate-related information 1957 via IKE. Certificate payloads SHOULD be included in an exchange if 1958 certificates are available to the sender. 1960 The Certificate Payload is defined as follows: 1962 1 2 3 1963 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 1964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1965 ! Next Payload !C! RESERVED ! Payload Length ! 1966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1967 ! Cert Encoding ! ! 1968 +-+-+-+-+-+-+-+-+ ! 1969 ~ Certificate Data ~ 1970 ! ! 1971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1973 Figure 9: Certificate Payload Format 1975 o Certificate Encoding (1 byte) - This field indicates the type 1976 of certificate or certificate-related information contained 1977 in the Certificate Data field. 1979 Harkins Kaufman Perlman [Page 41]^L 1980 Certificate Encoding Value 1981 -------------------- ----- 1982 NONE 0 1983 PKCS #7 wrapped X.509 certificate 1 1984 PGP Certificate 2 1985 DNS Signed Key 3 1986 X.509 Certificate - Signature 4 1987 Kerberos Token 6 1988 Certificate Revocation List (CRL) 7 1989 Authority Revocation List (ARL) 8 1990 SPKI Certificate 9 1991 X.509 Certificate - Attribute 10 1992 RESERVED 11 - 255 1994 o Certificate Data (variable length) - Actual encoding of 1995 certificate data. The type of certificate is indicated 1996 by the Certificate Encoding field. 1998 The payload type for the Certificate Payload is six (6). 2000 7.7 Certificate Request Payload 2002 The Certificate Request Payload, denoted CERTREQ in this memo, 2003 provides a means to request preferred certificates via IKE and can 2004 appear in the first, second, or third message of Phase 1. 2005 Certificate Request payloads SHOULD be included in an exchange 2006 whenever the peer may have multiple certificates, some of which might 2007 be trusted while others are not. If multiple root CA's are trusted, 2008 then multiple Certificate Request payloads SHOULD be transmitted. 2010 Empty (zero length) CA names MUST NOT be generated and SHOULD be 2011 ignorred. 2013 The Certificate Request Payload is defined as follows: 2015 1 2 3 2016 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 2017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2018 ! Next Payload !C! RESERVED ! Payload Length ! 2019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2020 ! Cert Encoding ! ! 2021 +-+-+-+-+-+-+-+-+ ! 2022 ~ Certification Authority ~ 2023 ! ! 2024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2026 Figure 10: Certificate Request Payload Format 2028 Harkins Kaufman Perlman [Page 42]^L 2029 o Certificate Encoding (1 byte) - Contains an encoding of the type 2030 of certificate requested. Acceptable values are listed in 2031 section 7.6. 2033 o Certification Authority (variable length) - Contains an encoding 2034 of an acceptable certification authority for the type of 2035 certificate requested. 2037 The payload type for the Certificate Request Payload is seven (7). 2039 The Certificate Request Payload is constructed by setting the "Cert 2040 Encoding" field to be the type of certificate being desired and the 2041 "Certification Authority" field to a proper encoding of a 2042 certification authority for the specified certificate. For example, 2043 for an X.509 certificate this field would contain the Distinguished 2044 Name encoding of the Issuer Name of an X.509 certification authority 2045 acceptable to the sender of this payload. 2047 The Certificate Request Payload is processed by inspecting the "Cert 2048 Encoding" field to determine whether the processor has any 2049 certificates of this type. If so the "Certification Authority" field 2050 is inspected to determine if the processor has any certificates which 2051 can be validated up to the specified certification authority. This 2052 can be a chain of certificates. If a certificate exists which 2053 satisfies the criteria specified in the Certificate Request Payload 2054 it MUST be sent back to the certificate requestor; if a certificate 2055 chain exists which goes back to the certification authority specified 2056 in the request the entire chain SHOULD be sent back to the 2057 certificate requestor. If no certificates exist then no further 2058 processing is performed-- this is not an error condition of the 2059 protocol. There may be cases where there is a preferred CA, but an 2060 alternate might be acceptable (perhaps after prompting a human 2061 operator). 2063 7.8 Authentication Payload 2065 The Authentication Payload, denoted AUTH in this memo, contains data 2066 used for authentication purposes. The only authentication method 2067 defined in this memo is digital signatures and therefore the contents 2068 of this payload when used with this memo will be the output generated 2069 by a digital signature function. 2071 Harkins Kaufman Perlman [Page 43]^L 2072 The Authentication Payload is defined as follows: 2074 1 2 3 2075 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2077 ! Next Payload !C! RESERVED ! Payload Length ! 2078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2079 ! ! 2080 ~ Authentication Data ~ 2081 ! ! 2082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2084 Figure 11: Authentication Payload Format 2086 o Authentication Data (variable length) - Data that results from 2087 applying the digital signature function to the IKE state 2088 (see section 3). 2090 The payload type for the Authentication Payload is nine (9). 2092 The Authentication Payload is constructed by computing a digital 2093 signature (or secret key MAC) over the concatenation of the sender's 2094 first IKE message and the other peer's nonce. The result is placed 2095 in the "Authentication Data" portion of the payload. The encoding 2096 depends on the type of key being used to authenticate (see section 2097 3.2). The payload length is the size of the generic header plus the 2098 size of the "Authentication Data" portion of the payload which 2099 depends on the specific authentication method being used. 2101 The Authentication Payload is processed by extracting the 2102 "Authentication Data" from the payload and verifying it according to 2103 the specific authentication method being used. If authentication 2104 fails a NOTIFY Error message of AUTHENTICATION-FAILED MUST be sent 2105 back to the peer and the connection closed. 2107 7.9 Nonce Payload 2109 The Nonce Payload, denoted Ni and Nr in this memo for the Initiator's 2110 and Responder's nonce respectively, contains random data used to 2111 guarantee liveness during an exchange and protect against replay 2112 attacks. 2114 Harkins Kaufman Perlman [Page 44]^L 2115 The Nonce Payload is defined as follows: 2117 1 2 3 2118 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 2119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2120 ! Next Payload !C! RESERVED ! Payload Length ! 2121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2122 ! ! 2123 ~ Nonce Data ~ 2124 ! ! 2125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2127 Figure 12: Nonce Payload Format 2129 o Nonce Data (variable length) - Contains the random data generated 2130 by the transmitting entity. 2132 The payload type for the Nonce Payload is ten (10). 2134 The Nonce Payload is constructed by computing a pseudo-random value 2135 and copying it into the "Nonce Data" field. The size of a Nonce MUST 2136 be between 8 and 256 bytes inclusive. 2138 7.10 Notify Payload 2140 The Notify Payload, denoted NOTIFY in this memo, is used to transmit 2141 informational data, such as error conditions and state transitions to 2142 an IKE peer. A Notify Payload may appear in a response message 2143 (usually specifying why a request was rejected), or in an 2144 Informational Exchange (to report an error not in an IKE request). 2146 The Notify Payload is defined as follows: 2148 1 2 3 2149 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 2150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2151 ! Next Payload !C! RESERVED ! Payload Length ! 2152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2153 ! Protocol-ID ! SPI Size ! Notify Message Type ! 2154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2155 ! ! 2156 ~ Security Parameter Index (SPI) ~ 2157 ! ! 2158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2159 ! ! 2160 ~ Notification Data ~ 2161 ! ! 2162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2164 Harkins Kaufman Perlman [Page 45]^L 2165 Figure 13: Notification Payload Format 2167 o Protocol-Id (1 byte) - Specifies the protocol about which 2168 this notification is being sent. For phase 1 notifications, 2169 this field MUST be zero (0). For phase 2 notifications 2170 concerning IPsec SAs this field will contain an IPsec 2171 protocol (either ESP, AH, or IPcomp). For notifications 2172 for which no protocol ID is relevant, this field MUST be 2173 sent as zero and MUST be ignored. 2175 o SPI Size (1 byte) - Length in bytes of the SPI as defined by 2176 the Protocol-Id or zero if no SPI is applicable. For phase 1 2177 notification concerning the IKE-SA, the SPI Size MUST be zero. 2179 o Notify Message Type (2 bytes) - Specifies the type of 2180 notification message. 2182 o SPI (variable length) - Security Parameter Index. 2184 o Notification Data (variable length) - Informational or error data 2185 transmitted in addition to the Notify Message Type. Values for 2186 this field are message specific, see below. 2188 The payload type for the Notification Payload is eleven (11). 2190 7.10.1 Notify Message Types 2192 Notification information can be error messages specifying why an SA 2193 could not be established. It can also be status data that a process 2194 managing an SA database wishes to communicate with a peer process. 2195 For example, a secure front end or security gateway may use the 2196 Notify message to synchronize SA communication. The table below 2197 lists the Notification messages and their corresponding values. 2199 NOTIFY MESSAGES - ERROR TYPES Value 2200 ----------------------------- ----- 2201 INVALID-PAYLOAD-TYPE 1 2203 Only sent if the payload has the "critical" bit set. 2204 Notification Data contains the one byte payload type. 2206 INVALID-COOKIE 4 2208 Indicates an IKE message was received with an unrecognized 2209 destination cookie. This usually indicates that the 2210 recipient has rebooted and forgotten the existence of an 2211 IKE-SA. 2213 Harkins Kaufman Perlman [Page 46]^L 2214 INVALID-MAJOR-VERSION 5 2216 Indicates the recipient cannot handle the version of IKE 2217 specified in the header. The closest version number that the 2218 recipient can support will be in the reply header. 2220 INVALID-EXCHANGE-TYPE 7 2222 Notification Data contains the one byte Exchange Type. 2224 INVALID-FLAGS 8 2226 Notification Data contains one byte with the unacceptable 2227 flag bits set. 2229 INVALID-MESSAGE-ID 9 2231 Sent when an IKE MESSAGE-ID outside the negotiated window is 2232 received. This Notify MUST NOT be sent in a response; the 2233 invalid request MUST NOT be acknowledged. Instead, inform 2234 the other side by initiating an Informational exchange with 2235 Notification data containing the four byte invalid MESSAGE- 2236 ID. 2238 INVALID-PROTOCOL-ID 10 2240 Notification Data contains the one byte invalid protocol ID. 2242 INVALID-SPI 11 2244 MAY be sent in an IKE Informational Exchange when a node 2245 receives an ESP or AH packet with an invalid SPI. address 2246 as the source address in the invalid packet. This usually 2247 indicates a node has rebooted and forgotten an SA. This 2248 Informational Message is sent outside the context of an IKE- 2249 SA, and therefore should only be used by the recipient as a 2250 "hint" that something might be wrong (because it could 2251 easily be forged). 2253 INVALID-TRANSFORM-ID 12 2255 Notification Data contains the one byte invalid transform 2256 ID. 2258 ATTRIBUTES-NOT-SUPPORTED 13 2260 The "Notification Data" for this type are the attribute or 2261 attributes that are not supported. 2263 Harkins Kaufman Perlman [Page 47]^L 2264 NO-PROPOSAL-CHOSEN 14 2266 BAD-PROPOSAL-SYNTAX 15 2268 PAYLOAD-MALFORMED 16 2270 INVALID-KEY-INFORMATION 17 2272 The KE field is the wrong length. 2274 INVALID-ID-INFORMATION 18 2276 INVALID-CERT-ENCODING 19 2278 The "Notification Data" for this type are the "Cert 2279 Encoding" field from a Certificate Payload or Certificate 2280 Request Payload. 2282 INVALID-CERTIFICATE 20 2284 The "Notification Data" for this type are the "Certificate 2285 Data" field from a Certificate Payload. 2287 CERT-TYPE-UNSUPPORTED 21 2289 This is identical to the INVALID-CERT-ENCODING error. 2291 INVALID-CERT-AUTHORITY 22 2293 The "Notification Data" for this type are the "Cert 2294 Encoding" field from a Certificate Payload or Certificate 2295 Request Payload. 2297 AUTHENTICATION-FAILED 24 2299 INVALID-SIGNATURE 25 2301 ADDRESS-NOTIFICATION 26 2303 Don't understand. 2305 UNSUPPORTED-EXCHANGE-TYPE 29 2307 The "Notification Data" for this type are the Exchange Type 2308 field from the IKE header. 2310 UNEQUAL-PAYLOAD-LENGTHS 30 2312 Harkins Kaufman Perlman [Page 48]^L 2313 The "Notification Data" for this type are the entire message 2314 in which the unequal lengths were observed. Receipt of this 2315 notify MAY be logged for debugging purposes. 2317 UNSUPPORTED-NOTIFY-TYPE 31 2319 The "Notification Data" for this type is the two byte Notify 2320 Type that was not supported. 2322 IKE-SA-INIT-REJECT 32 2324 This notification is sent in an IKE-SA-RESPONSE to request 2325 that the Initiator retry the request with the supplied 2326 cookie (and optionally the supplied Diffie-Hellman group). 2327 This is not really an error, but is processed like one in 2328 that it indicates that the connection request was rejected. 2329 The Notification Data, if present, contains the Transform 2330 Substructure describing the preferred Diffie-Hellman group. 2332 SINGLE-PAIR-REQUIRED 34 2334 This error indicates that a Phase 2 SA request is 2335 unacceptable because the Responder requires a separate SA 2336 for each source / destination address pair. The Initiator is 2337 expected to respond by requesting an SA for only the 2338 specific traffic he is trying to forward. 2340 RESERVED - Errors 34 - 8191 2342 Private Use - Errors 8192 - 16383 2344 NOTIFY MESSAGES - STATUS TYPES Value 2345 ------------------------------ ----- 2347 RESERVED 16384 - 24577 2349 INITIAL-CONTACT 24578 2351 This notification asserts that this IKE-SA is the only IKE- 2352 SA currently active between the authenticated identities. It 2353 MAY be sent when an IKE-SA is established after a crash, and 2354 the recipient MAY use this information to delete any other 2355 IKE-SAs it has to the same authenticated identity without 2356 waiting for a timeout if those IKE-SAs reside at the IP 2357 address from which this notification arrived. This 2358 notification MUST NOT be sent by an entity that may be 2360 Harkins Kaufman Perlman [Page 49]^L 2361 replicated (e.g. a roaming user's credentials where the user 2362 is allowed to connect to the corporate firewall from two 2363 remote systems at the same time). 2365 RESERVED 24578 - 40959 2367 Private Use - STATUS 40960 - 65535 2369 7.11 Delete Payload 2371 The Delete Payload, denoted D in this memo, contains a protocol- 2372 specific security association identifier that the sender has removed 2373 from its security association database and is, therefore, no longer 2374 valid. Figure 14 shows the format of the Delete Payload. It is 2375 possible to send multiple SPIs in a Delete payload, however, each SPI 2376 MUST be for the same protocol. Mixing of Protocol Identifiers MUST 2377 NOT be performed with the Delete payload. It is permitted, however, 2378 to include multiple Delete payloads in a single Informational 2379 Exchange where each Delete payload lists SPIs for a different 2380 protocol. 2382 Deletion of the IKE-SA is indicated by a Protocol-Id of 0 (IKE) but 2383 no SPIs. Deletion which is concerned with a Child-SA, such as ESP or 2384 AH, will contain the Protocol-Id of that protocol (e.g. ESP, AH) and 2385 the SPI is the receiving entity's SPI(s). 2387 NOTE: What's the deal with IPcomp SAs. This mechanism is probably not 2388 appropriate for deleting them!! 2390 The Delete Payload is defined as follows: 2392 1 2 3 2393 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 2394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2395 ! Next Payload !C! RESERVED ! Payload Length ! 2396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2397 ! Protocol-Id ! SPI Size ! # of SPIs ! 2398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2399 ! ! 2400 ~ Security Parameter Index(es) (SPI) ~ 2401 ! ! 2402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2404 Figure 14: Delete Payload Format 2406 o Protocol-Id (1 byte) - Must be zero for an IKE-SA, 50 for 2407 ESP, 51 for AH, and 108 for IPcomp. 2409 Harkins Kaufman Perlman [Page 50]^L 2410 o SPI Size (1 byte) - Length in bytes of the SPI as defined by 2411 the Protocol-Id. Zero for IKE (SPI is in message header), 2412 four for AH and ESP, two for IPcomp. 2414 o # of SPIs (2 bytes) - The number of SPIs contained in the Delete 2415 payload. The size of each SPI is defined by the SPI Size field. 2417 o Security Parameter Index(es) (variable length) - Identifies the 2418 specific security association(s) to delete. 2419 The length of this field is 2420 determined by the SPI Size and # of SPIs fields. 2422 The payload type for the Delete Payload is twelve (12). 2424 7.12 Vendor ID Payload 2426 The Vendor ID Payload contains a vendor defined constant. The 2427 constant is used by vendors to identify and recognize remote 2428 instances of their implementations. This mechanism allows a vendor 2429 to experiment with new features while maintaining backwards 2430 compatibility. 2432 The Vendor ID payload is not an announcement from the sender that it 2433 will send private payload types but rather an announcement of the 2434 sort of private payloads it is willing to accept. The implementation 2435 sending the Vendor ID MUST not make any assumptions about private 2436 payloads that it may send unless a Vendor ID of like stature is 2437 received as well. Multiple Vendor ID payloads MAY be sent. An 2438 implementation is NOT REQUIRED to send any Vendor ID payload at all. 2440 A Vendor ID payload may be sent as part of any message. Reception of 2441 a familiar Vendor ID payload allows an implementation to make use of 2442 Private USE numbers described throughout this memo-- private 2443 payloads, private exchanges, private notifications, etc. Unfamiliar 2444 Vendor ID's MUST be ignored. 2446 Writers of Internet-Drafts who wish to extend this protocol MUST 2447 define a Vendor ID payload to announce the ability to implement the 2448 extension in the Internet-Draft. It is expected that Internet-Drafts 2449 which gain acceptance and are standardized will be given "magic 2450 numbers" out of the Future Use range by IANA and the requirement to 2451 use a Vendor ID will go away. 2453 Harkins Kaufman Perlman [Page 51]^L 2454 The Vendor ID Payload fields are defined as follows: 2456 1 2 3 2457 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 2458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2459 ! Next Payload !C! RESERVED ! Payload Length ! 2460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2461 ! ! 2462 ~ Vendor ID (VID) ~ 2463 ! ! 2464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2466 Figure 15: Vendor ID Payload Format 2468 o Vendor ID (variable length) - It is the responsibility of 2469 the person choosing the Vendor ID to assure its uniqueness 2470 in spite of the absence of any central registry for IDs. 2471 Good practice is to include a company name, a person name 2472 or some such. If you want to show off, you might include 2473 the latitude and longitude and time where you were when 2474 you chose the ID and some random input. A message digest 2475 of a long unique string is preferable to the long unique 2476 string itself. 2478 The payload type for the Vendor ID Payload is thirteen (13). 2480 7.13 Traffic Selector Payload 2482 The Traffic Selector Payload, denoted TS in this memo, allows peers 2483 to identify packet flows for processing by IPsec security services. 2484 The Traffic Selector Payload consists of the IKE generic header 2485 followed by selector information fields as follows: 2487 1 2 3 2488 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 2489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2490 ! Next Payload !C! RESERVED ! Payload Length ! 2491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2492 ! Number of TSs ! RESERVED ! 2493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2494 ! ! 2495 ~ ~ 2496 ! ! 2497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2499 Figure 16: Traffic Selectors Payload Format 2501 Harkins Kaufman Perlman [Page 52]^L 2502 o Number of TSs (1 byte) - Number of traffic selectors 2503 being provided. 2505 o RESERVED - This field MUST be sent as zero and MUST be ignored. 2507 o Traffic Selectors (variable length) - one or more traffic 2508 selector substructures. 2510 The length of the Traffic Selector payload includes the TS header and 2511 all the traffic selector substructures. 2512 The payload type for the Traffic Selector payload is fourteen (14). 2514 7.13.1 Traffic Selector Substructure 2516 1 2 3 2517 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 2518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2519 ! TS Type ! Protocol ID | Selector Length | 2520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2521 | Start-Port | End-Port | 2522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2523 ! ! 2524 ~ Address Selector Data ~ 2525 ! ! 2526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2528 Figure 17: Traffic Selector Substructure 2530 o TS Type (one byte) - Specifies the type of traffic selector. 2532 o Protocol ID (1 byte) - Value specifying an associated IP 2533 protocol ID (e.g. UDP/TCP). A value of zero means that the 2534 Protocol ID is not relevant to this traffic selector-- 2535 the SA can carry all protocols. 2537 o Selector Length - Specifies the length of this Traffic 2538 Selector Substructure including the header. 2540 o Start-Port (2 bytes) - Value specifying the smallest port 2541 number allowed by this Traffic Selector. For protocols for 2542 which port is undefined, or if all ports are allowed by 2543 this Traffic Selector, this field MUST be zero. 2545 o End-Port (2 bytes) - Value specifying the largest port 2546 number allowed by this Traffic Selector. For protocols for 2547 which port is undefined, or it all ports are allowed by 2548 this Traffic Selector, this field MUST be 65535. 2550 Harkins Kaufman Perlman [Page 53]^L 2551 o Address Selector Data - a specification of one or more 2552 addresses included in this Traffic Selector with format 2553 determined by TS type. 2555 The following table lists the assigned values for the Traffic 2556 Selector Type field and the corresponding Address Selector Data. 2558 TS Type Value 2559 ------- ----- 2560 RESERVED 0 2562 TS_IPV4_ADDR 1 2564 A four (4) byte IPv4 address 2566 TS_IPV4_ADDR_SUBNET 4 2568 An IPv4 subnet represented by a pair of four (4) byte 2569 values. The first value is an IPv4 address. The second is 2570 an IPv4 network mask. Note that ones (1s) in the network 2571 mask indicate that the corresponding bit in the address is 2572 fixed, while zeros (0s) indicate a "wildcard" bit. 2574 TS_IPV6_ADDR 5 2576 A sixteen (16) byte IPv6 address 2578 TS_IPV6_ADDR_SUBNET 6 2580 An IPv6 subnet represented by a pair sixteen (16) byte 2581 values. The first value is an IPv6 address. The second is 2582 an IPv6 network mask. Note that ones (1s) in the network 2583 mask indicate that the corresponding bit in the address is 2584 fixed, while zeros (0s) indicate a "wildcard" bit. 2586 TS_IPV4_ADDR_RANGE 7 2588 A range of IPv4 addresses, represented by two four (4) byte 2589 values. The first value is the beginning IPv4 address 2590 (inclusive) and the second value is the ending IPv4 address 2591 (inclusive). All addresses falling between the two specified 2592 addresses are considered to be within the list. 2594 TS_IPV6_ADDR_RANGE 8 2596 A range of IPv6 addresses, represented by two sixteen (16) 2597 byte values. The first value is the beginning IPv6 address 2598 (inclusive) and the second value is the ending IPv6 address 2600 Harkins Kaufman Perlman [Page 54]^L 2601 (inclusive). All addresses falling between the two specified 2602 addresses are considered to be within the list. 2604 7.14 Other Payload Types 2606 Payload type values 15-127 are reserved to IANA for future assignment 2607 in IKEv2 (see section 10). Payload type values 128-255 are for 2608 private use among mutually consenting parties. 2610 8 Diffie-Hellman Groups 2612 There are 5 groups different Diffie-Hellman groups defined for use in 2613 IKE. These groups were generated by Richard Schroeppel at the 2614 University of Arizona. Properties of these primes are described in 2615 [Orm96]. 2617 The strength supplied by group one may not be sufficient for the 2618 mandatory-to-implement encryption algorithm and is here for historic 2619 reasons. 2621 8.1 First Group 2623 IKE implementations MAY support a MODP group with the following prime 2624 and generator. This group is assigned id 1 (one). 2626 The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } 2627 Its hexadecimal value is: 2629 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 2630 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 2631 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 2632 A63A3620 FFFFFFFF FFFFFFFF 2634 The generator is: 2. 2636 8.2 Second Group 2638 IKE implementations SHOULD support a MODP group with the following 2639 prime and generator. This group is assigned id 2 (two). 2641 Harkins Kaufman Perlman [Page 55]^L 2642 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. 2643 Its hexadecimal value is: 2645 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 2646 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 2647 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 2648 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 2649 49286651 ECE65381 FFFFFFFF FFFFFFFF 2651 The generator is 2 (decimal) 2653 8.3 Third Group 2655 IKE implementations SHOULD support a EC2N group with the following 2656 characteristics. This group is assigned id 3 (three). The curve is 2657 based on the Galois Field GF[2^155]. The field size is 155. The 2658 irreducible polynomial for the field is: 2659 u^155 + u^62 + 1. 2660 The equation for the elliptic curve is: 2661 y^2 + xy = x^3 + ax^2 + b. 2663 Field Size: 155 2664 Group Prime/Irreducible Polynomial: 2665 0x0800000000000000000000004000000000000001 2666 Group Generator One: 0x7b 2667 Group Curve A: 0x0 2668 Group Curve B: 0x07338f 2669 Group Order: 0x0800000000000000000057db5698537193aef944 2671 The data in the KE payload when using this group is the value x from 2672 the solution (x,y), the point on the curve chosen by taking the 2673 randomly chosen secret Ka and computing Ka*P, where * is the 2674 repetition of the group addition and double operations, P is the 2675 curve point with x coordinate equal to generator 1 and the y 2676 coordinate determined from the defining equation. The equation of 2677 curve is implicitly known by the Group Type and the A and B 2678 coefficients. There are two possible values for the y coordinate; 2679 either one can be used successfully (the two parties need not agree 2680 on the selection). 2682 Harkins Kaufman Perlman [Page 56]^L 2683 8.4 Fourth Group 2685 IKE implementations SHOULD support a EC2N group with the following 2686 characteristics. This group is assigned id 4 (four). The curve is 2687 based on the Galois Field GF[2^185]. The field size is 185. The 2688 irreducible polynomial for the field is: 2689 u^185 + u^69 + 1. 2691 The equation for the elliptic curve is: 2692 y^2 + xy = x^3 + ax^2 + b. 2694 Field Size: 185 2695 Group Prime/Irreducible Polynomial: 2696 0x020000000000000000000000000000200000000000000001 2697 Group Generator One: 0x18 2698 Group Curve A: 0x0 2699 Group Curve B: 0x1ee9 2700 Group Order: 0x01ffffffffffffffffffffffdbf2f889b73e484175f94ebc 2702 The data in the KE payload when using this group will be identical to 2703 that as when using Oakley Group 3 (three). 2705 8.5 Fifth Group 2707 IKE implementations MUST support a MODP group with the following 2708 prime and generator. This group is assigned id 5 (five). 2710 The prime is 2^1536 - 2^1472 - 1 + 2^64 * {[2^1406 pi] + 741804}. 2711 Its hexadecimal value is 2713 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 2714 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 2715 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 2716 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 2717 49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 2718 FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 2719 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF 2721 The generator is 2. 2723 9 Security Considerations 2725 Repeated re-keying using Phase 2 without PFS can consume the entropy 2726 of the Diffie-Hellman shared secret. Implementers should take note of 2727 this fact and set a limit on Phase 2 Exchanges between 2728 exponentiations. This memo does not prescribe such a limit. 2730 Harkins Kaufman Perlman [Page 57]^L 2731 The strength of a key derived from a Diffie-Hellman exchange using 2732 any of the groups defined here depends on the inherent strength of 2733 the group, the size of the exponent used, and the entropy provided by 2734 the random number generator used. Due to these inputs it is difficult 2735 to determine the strength of a key for any of the defined groups. 2736 Diffie-Hellman group number two when used with a strong random number 2737 generator and an exponent no less than 160 bits is sufficient to use 2738 for 3DES. Groups three through five provide greater security. Group 2739 one is for historic purposes only and does not provide sufficient 2740 strength to the required cipher (although it is sufficient for use 2741 with DES, which is also for historic use only). Implementations 2742 should make note of these conservative estimates when establishing 2743 policy and negotiating security parameters. 2745 Note that these limitations are on the Diffie-Hellman groups 2746 themselves. There is nothing in IKE which prohibits using stronger 2747 groups nor is there anything which will dilute the strength obtained 2748 from stronger groups. In fact, the extensible framework of IKE 2749 encourages the definition of more groups; use of elliptical curve 2750 groups will greatly increase strength using much smaller numbers. 2752 It is assumed that the Diffie-Hellman exponents in this exchange are 2753 erased from memory after use. In particular, these exponents MUST NOT 2754 be derived from long-lived secrets like the seed to a pseudo-random 2755 generator that is not erased after use. 2757 The security of this protocol is critically dependent on the 2758 randomness of the Diffie-Hellman exponents, which should be generated 2759 by a strong random or properly seeded pseudo-random source (see 2760 RFC1715). While the protocol was designed to be secure even if the 2761 Nonces and other values specified as random are not strongly random, 2762 they should similarly be generated from a strong random source as 2763 part of a conservative design. 2765 10 IANA Considerations 2767 This document contains many "magic numbers" to be maintained by the 2768 IANA. This section explains the criteria to be used by the IANA to 2769 assign additional numbers in each of these lists. 2771 10.1 Transform Types and Attribute Values 2773 10.1.1 Attributes 2775 Transform attributes are uses to modify or complete the specification 2776 of a particular transform. Requests for new transform attributes MUST 2777 be accompanied by a standards-track or Informational RFC which 2778 defines the transform which it modifies or completes and the method 2780 Harkins Kaufman Perlman [Page 58]^L 2781 in which it does so. 2783 10.1.2 Encryption Algorithm Transform Type 2785 Values of the Encryption Algorithm define an encryption algorithm to 2786 use when called for in this document. Requests for assignment of new 2787 encryption algorithm values must be accompanied by a reference to a 2788 standards-track or informational RFC that describes how to use this 2789 algorithm with ESP. 2791 10.1.3 Pseudo-random function Transform Type 2793 Values for the pseudo-random function define which pseudo-random 2794 function is used in IKE for key generation and expansion. Requests 2795 for assignment of a new pseudo-random function MUST be accompanied by 2796 a reference to a standards-track or informational RFC describing this 2797 function. 2799 10.1.4 Authentication Method Transform Type 2801 The only Authentication method defined in the memo is for digital 2802 signatures. Other methods of authentication are possible and MUST be 2803 accompanied by a standards-track or informational RFC which defines 2804 the following: 2806 - the cryptographic method of authentication. 2807 - content of the Authentication Data in the Authentication 2808 Payload. 2809 - new payloads, their construction and processing, if needed. 2810 - additions of payloads to any messages, if needed. 2812 10.1.5 Diffie-Hellman Groups 2814 Values of the Diffie-Hellman Group Transform types define a group in 2815 which a Diffie-Hellman key exchange can be completed. Requests for 2816 assignment of a new Diffie-Hellman group type MUST be accompanied by 2817 a reference to a standards-track or informational RFC which fully 2818 defines the group. 2820 10.2 Exchange Types 2822 This memo defines three exchange types for use with IKEv2. Requests 2823 for assignment of new exchange types MUST be accompanied by a 2824 standards-track or informational RFC which defines the following: 2826 - the purpose of and need for the new exchange. 2827 - the payloads (mandatory and optional) that accompany 2828 messages in the exchange. 2830 Harkins Kaufman Perlman [Page 59]^L 2831 - the phase of the exchange. 2832 - requirements the new exchange has on existing 2833 exchanges which have assigned numbers. 2835 10.3 Payload Types 2837 Payloads are defined in this memo to convey information between 2838 peers. New payloads may be required when defining a new 2839 authentication method or exchange. Requests for new payload types 2840 MUST be accompanied by a standards-track or informational RFC which 2841 defines the physical layout of the payload and the fields it 2842 contains. All payloads MUST use the same generic header defined in 2843 Figure 2. 2845 11 Acknowledgements 2847 We would like to thank the many members of the IPsec working group 2848 that provided helpful and constructive suggestions on improving IKE. 2849 Special thanks go to those of you who've implemented it! 2851 This protocol is built on the shoulders of many designers who came 2852 before. While they have not necessarily reviewed or endorsed this 2853 version and should not be blamed for any defects, they deserve much 2854 of the credit for its design. We would like to acknowledge Oakley, 2855 SKEME and their authors, Hilarie Orman (Oakley), Hugo Krawczyk 2856 (SKEME). Without the hard work of Doug Maughan, Mark Schertler, Mark 2857 Schneider, Jeff Turner, Dave Carrel, and Derrell Piper, this memo 2858 would not exist. Their contributions to the IPsec WG have been 2859 considerable and critical. 2861 12 References 2863 [CAST] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, 2864 May 1997. 2866 [BLOW] Schneier, B., "The Blowfish Encryption Algorithm", Dr. 2867 Dobb's Journal, v. 19, n. 4, April 1994. 2869 [Bra96] Bradner, S., "The Internet Standards Process -- Revision 3", 2870 BCP 9, RFC 2026, October 1996. 2872 [Bra97] Bradner, S., "Key Words for use in RFCs to indicate 2873 Requirement Levels", BCP 14, RFC 2119, March 1997. 2875 [Ble98] Bleichenbacher, D., "Chosen Ciphertext Attacks against 2876 Protocols Based on RSA Encryption Standard PKCS#1", Advances 2877 in Cryptology Eurocrypt '98, Springer-Verlag, 1998. 2879 Harkins Kaufman Perlman [Page 60]^L 2881 [BR94] Bellare, M., and Rogaway P., "Optimal Asymmetric 2882 Encryption", Advances in Cryptology Eurocrypt '94, 2883 Springer-Verlag, 1994. 2885 [DES] ANSI X3.106, "American National Standard for Information 2886 Systems-Data Link Encryption", American National Standards 2887 Institute, 1983. 2889 [DH] Diffie, W., and Hellman M., "New Directions in 2890 Cryptography", IEEE Transactions on Information Theory, V. 2891 IT-22, n. 6, June 1977. 2893 [DSS] NIST, "Digital Signature Standard", FIPS 186, National 2894 Institute of Standards and Technology, U.S. Department of 2895 Commerce, May, 1994. 2897 [IDEA] Lai, X., "On the Design and Security of Block Ciphers," ETH 2898 Series in Information Processing, v. 1, Konstanz: Hartung- 2899 Gorre Verlag, 1992 2901 [Ker01] Keronytis, A., Sommerfeld, B., "The 'Suggested ID' Extension 2902 for IKE", draft-keronytis-ike-id-00.txt, 2001 2904 [KBC96] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2905 Hashing for Message Authentication", RFC 2104, February 2906 1997. 2908 [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange 2909 Mechanism for Internet", from IEEE Proceedings of the 1996 2910 Symposium on Network and Distributed Systems Security. 2912 [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, 2913 April 1992. 2915 [MSST98] Maughhan, D., Schertler, M., Schneider, M., and J. Turner, 2916 "Internet Security Association and Key Management Protocol 2917 (ISAKMP)", RFC 2408, November 1998. 2919 [Orm96] Orman, H., "The Oakley Key Determination Protocol", RFC 2920 2412, November 1998. 2922 [PFKEY] McDonald, D., Metz, C., and Phan, B., "PFKEY Key Management 2923 API, Version 2", RFC2367, July 1998. 2925 [PKCS1] Kaliski, B., and J. Staddon, "PKCS #1: RSA Cryptography 2926 Specifications Version 2", September 1998. 2928 Harkins Kaufman Perlman [Page 61]^L 2930 [PK01] Perlman, R., and Kaufman, C., "Analysis of the IPsec key 2931 exchange Standard", WET-ICE Security Conference, MIT, 2001, 2932 http://sec.femto.org/wetice-2001/papers/radia-paper.pdf. 2934 [Pip98] Piper, D., "The Internet IP Security Domain Of 2935 Interpretation for ISAKMP", RFC 2407, November 1998. 2937 [RC5] Rivest, R., "The RC5 Encryption Algorithm", Dr. Dobb's 2938 Journal, v. 20, n. 1, January 1995. 2940 [RSA] Rivest, R., Shamir, A., and Adleman, L., "A Method for 2941 Obtaining Digital Signatures and Public-Key Cryptosystems", 2942 Communications of the ACM, v. 21, n. 2, February 1978. 2944 [Sch96] Schneier, B., "Applied Cryptography, Protocols, Algorithms, 2945 and Source Code in C", 2nd edition. 2947 [SHA] NIST, "Secure Hash Standard", FIPS 180-1, National Institute 2948 of Standards and Technology, U.S. Department of Commerce, 2949 May 1994. 2951 [TIGER] Anderson, R., and Biham, E., "Fast Software Encryption", 2952 Springer LNCS v. 1039, 1996. 2954 Harkins Kaufman Perlman [Page 62]^L 2955 Appendix A 2957 Attribute Assigned Numbers 2959 Certain transforms negotiated in an SA payload can have associated 2960 attributes. Attribute types can be either Basic (B) or Variable- 2961 length (V). Encoding of these attributes is defined as Type/Value 2962 (Basic) and Type/Length/Value (Variable). See section 7.3.3. 2964 Attributes described as basic MUST NOT be encoded as variable. 2965 Variable length attributes MUST NOT be encoded as basic even if their 2966 value can fit into two bytes. NOTE: This is a change from IKEv1, 2967 where increased flexibility may have simplified the composer of 2968 messages but certainly complicated the parser. 2970 Attribute Classes 2972 class value type 2973 -------------------------------------------------------------- 2974 RESERVED 0-5 2975 Group Prime/Irreducible Polynomial 6 V 2976 Group Generator One 7 V 2977 Group Generator Two 8 V 2978 Group Curve A 9 V 2979 Group Curve B 10 V 2980 RESERVED 11-13 2981 Key Length 14 B 2982 Field Size 15 B 2983 Group Order 16 V 2984 Block Size 17 B 2986 values 0-5, 11-13, and 18-16383 are reserved to IANA. Values 2987 16384-32767 are for private use among mutually consenting parties. 2989 - Group Prime/Irreducible Polynomial 2991 The prime number of a MODP Diffie-Hellman group or the irreducible 2992 polynomial of an elliptic curve when specifying a private Diffie- 2993 Hellman group. 2995 - Generator One, Generator Two 2997 The X- and Y-coordinate of a point on an elliptic curve. When the 2998 Y-coordinate (generator two) is not given it can be computed with 2999 the X-coordinate and the definition of the curve. 3001 - Curve A, Curve B 3003 Harkins Kaufman Perlman [Page 63]^L 3004 Coefficients from the definition of an elliptic curve: 3006 y^2 + xy = x^3 + (curve A)x^2 + (curve B) 3008 - Key Length 3010 When using an Encryption Algorithm that has a variable length key, 3011 this attribute specifies the key length in bits. (MUST use network 3012 byte order). This attribute MUST NOT be used when the specified 3013 Encryption Algorithm uses a fixed length key. 3015 - Field Size 3017 The field size, in bits, of a Diffie-Hellman group. 3019 - Group Order 3021 The group order of an elliptic curve group. Note the length of 3022 this attribute depends on the field size. 3024 - Block Size 3026 The number of bits per block of a cipher with a variable block 3027 length. 3029 Harkins Kaufman Perlman [Page 64]^L 3030 Appendix B: Cryptographic Protection of IKE Data 3032 With the exception of the IKE-SA-INIT-REQUEST, IKE-SA-INIT-RESPONSE, 3033 and Informational Exchange error notifications when no IKE-SA exists, 3034 all IKE messages are encrypted and integrity protected. The 3035 algorithms for encryption and integrity protection are negotiated 3036 during IKE-SA setup, and the keys are computed as specified in 3037 sections 3 and 4.2. 3039 The encryption and integrity protection algorithms are modelled after 3040 the ESP algorithms described in RFCs 2104, 2406, 2451. This appendix 3041 completely specifies the cryptographic processing of IKE data, but 3042 those documents should be consulted for design rationale. This 3043 appendix assumes a block cipher with a fixed block size and an 3044 integrity check algorithm that computes a fixed length checksum over 3045 a variable size message. The mandatory to implement algorithms are 3046 AES-128 and HMAC-SHA1. 3048 Harkins Kaufman Perlman [Page 65]^L 3049 The format of an IKE message is shown in Figure 18. 3050 1 2 3 3051 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 3052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3053 ! Fixed IKE Header - 28 Bytes ! 3054 ! (including cookies, message ID, Length) ! 3055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3056 ! Initialization Vector ! 3057 ! (length is block size for encryption algorithm) ! 3058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3059 ! IKE Payloads ! 3060 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3061 ! ! Padding (0-255 bytes) ! 3062 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 3063 ! ! Pad Length ! 3064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3065 ~ Authentication Data ~ 3066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3068 Figure 18: IKE message with cryptographic protection 3070 o Initialization Vector - A randomly chosen value whose length 3071 is equal to the block length of the underlying encryption 3072 algorithm. Recipients MUST accept any value. Senders SHOULD 3073 either pick this value pseudo-randomly and independently for 3074 each message or use the final ciphertext block of the previous 3075 message sent. Senders MUST NOT use the same value for each 3076 message, use a sequence of values with low hamming distance 3077 (e.g. a sequence number), or use ciphertext from a received 3078 message. 3080 o IKE Payloads are as specified in Section 7. This field is 3081 encrypted with the negotiated cipher. 3083 o Padding may contain any value chosen by the sender, and must 3084 have a length that makes the combination of the Payloads, the 3085 Padding, and the Pad Length to be a multiple of the encryption 3086 block size. This field is encrypted with the negotiated 3087 cipher. 3089 o Pad Length is the length of the Padding field. The sender 3090 SHOULD set the Pad Length to the minimum value that makes 3091 the combination of the Payloads, the Padding, and the Pad 3092 Length a multiple of the block size, but the recipient MUST 3093 accept any length that results in proper alignment. This 3094 field is encrypted with the negotiated cipher. 3096 o Authentication Data is the cryptographic checksum of the 3098 Harkins Kaufman Perlman [Page 66]^L 3099 entire message starting with the Fixed IKE Header through 3100 the Pad Length. The checksum MUST be computed over the 3101 encrypted message. 3103 Authors' Addresses 3105 Dan Harkins 3106 dharkins@tibernian.com 3107 Tibernian Systems 3109 Charlie Kaufman 3110 ckaufman@iris.com 3111 IBM 3113 Steve Kent 3114 kent@bbn.com 3115 BBN Technologies 3117 Tero Kivinen 3118 kivinen@ssh.com 3119 SSH Communications Security 3121 Radia Perlman 3122 radia.perlman@sun.com 3123 Sun Microsystems 3125 Harkins Kaufman Perlman [Page 67]^L