idnits 2.17.1 draft-ietf-ipsec-ikev2-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 99 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 100 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 5 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The draft header indicates that this document obsoletes RFC2407, but the abstract doesn't seem to directly say this. It does mention RFC2407 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC2408, but the abstract doesn't seem to directly say this. It does mention RFC2408 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC2409, but the abstract doesn't seem to directly say this. It does mention RFC2409 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 4311 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: The responder MUST not send a CFG_REPLY without having first received a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS to perform an unnecessary configuration lookup if the IRAC cannot process the REPLY. In the case where the IRAS's configuration requires that CP be used for a given identity IDi, but IRAC has failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and terminate the IKE exchange with a FAILED_CP_REQUIRED error. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A fully-qualified domain name string. An example of a ID_FQDN is, "example.com". The string MUST not contain any terminators (e.g., NULL, CR, etc.). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A fully-qualified RFC822 email address string, An example of a ID_RFC822_ADDR is, "jsmith@example.com". The string MUST not contain any terminators. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 9, 2003) is 7495 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2406' is mentioned on line 146, but not defined ** Obsolete undefined reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) == Missing Reference: 'RFC2402' is mentioned on line 146, but not defined ** Obsolete undefined reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) == Missing Reference: 'CERTREQ' is mentioned on line 1392, but not defined == Missing Reference: 'N' is mentioned on line 421, but not defined == Missing Reference: 'KEi' is mentioned on line 421, but not defined == Missing Reference: 'KEr' is mentioned on line 442, but not defined == Missing Reference: 'CP' is mentioned on line 519, but not defined == Missing Reference: 'RFC 2522' is mentioned on line 793, but not defined == Missing Reference: 'RFC 2983' is mentioned on line 1005, but not defined == Missing Reference: 'AUTH' is mentioned on line 1402, but not defined == Missing Reference: 'RFC 2401' is mentioned on line 1771, but not defined ** Obsolete undefined reference: RFC 2401 (Obsoleted by RFC 4301) -- Looks like a reference, but probably isn't: '0' on line 2670 -- Looks like a reference, but probably isn't: '1' on line 2671 == Missing Reference: 'RFC 3168' is mentioned on line 4581, but not defined == Unused Reference: 'ESPCBC' is defined on line 4030, but no explicit reference was found in the text == Unused Reference: 'RFC3280' is defined on line 4041, but no explicit reference was found in the text == Unused Reference: 'Ble98' is defined on line 4048, but no explicit reference was found in the text == Unused Reference: 'BR94' is defined on line 4053, but no explicit reference was found in the text == Unused Reference: 'DES' is defined on line 4057, but no explicit reference was found in the text == Unused Reference: 'DH' is defined on line 4061, but no explicit reference was found in the text == Unused Reference: 'DSS' is defined on line 4068, but no explicit reference was found in the text == Unused Reference: 'HC98' is defined on line 4076, but no explicit reference was found in the text == Unused Reference: 'IDEA' is defined on line 4083, but no explicit reference was found in the text == Unused Reference: 'Ker01' is defined on line 4091, but no explicit reference was found in the text == Unused Reference: 'KBC96' is defined on line 4094, but no explicit reference was found in the text == Unused Reference: 'MD5' is defined on line 4101, but no explicit reference was found in the text == Unused Reference: 'MSST98' is defined on line 4104, but no explicit reference was found in the text == Unused Reference: 'PKCS1' is defined on line 4114, but no explicit reference was found in the text == Unused Reference: 'PK01' is defined on line 4117, but no explicit reference was found in the text == Unused Reference: 'Pip98' is defined on line 4121, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 4130, but no explicit reference was found in the text == Unused Reference: 'RFC2474' is defined on line 4133, but no explicit reference was found in the text == Unused Reference: 'RFC2475' is defined on line 4138, but no explicit reference was found in the text == Unused Reference: 'RFC2522' is defined on line 4143, but no explicit reference was found in the text == Unused Reference: 'RFC2983' is defined on line 4146, but no explicit reference was found in the text == Unused Reference: 'RSA' is defined on line 4149, but no explicit reference was found in the text == Unused Reference: 'SHA' is defined on line 4154, but no explicit reference was found in the text == Unused Reference: 'SKEME' is defined on line 4164, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3513 (ref. 'ADDRIPV6') (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 2284 (ref. 'EAP') (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. 'HC98') (Obsoleted by RFC 4306) == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-udp-encaps-05 -- Obsolete informational reference (is this intentional?): RFC 2251 (ref. 'LDAP') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) -- Obsolete informational reference (is this intentional?): RFC 2408 (ref. 'MSST98') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2407 (ref. 'Pip98') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2138 (ref. 'RADIUS') (Obsoleted by RFC 2865) -- Obsolete informational reference (is this intentional?): RFC 1750 (Obsoleted by RFC 4086) -- Duplicate reference: RFC2401, mentioned in 'RFC2401', was also mentioned in 'RFC2401bis'. -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) Summary: 9 errors (**), 0 flaws (~~), 48 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Charlie Kaufman, Editor 3 draft-ietf-ipsec-ikev2-11.txt 4 Obsoletes: 2407, 2408, 2409 October 9, 2003 5 Expires: April 2004 7 Internet Key Exchange (IKEv2) Protocol 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 10 of RFC2026. Internet-Drafts are working documents of 13 the Internet Engineering Task Force (IETF), its areas, and its 14 working groups. Note that other groups may also distribute working 15 documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/1id-abstracts.html 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html 28 This document is a submission by the IPSEC Working Group of the 29 Internet Engineering Task Force (IETF). Comments should be submitted 30 to the ipsec@lists.tislabs.com mailing list. 32 Distribution of this memo is unlimited. 34 This Internet-Draft expires in April 2004. 36 Copyright Notice 38 Copyright (C) The Internet Society (2003). All Rights Reserved. 40 Abstract 42 This document describes version 2 of the Internet Key Exchange (IKE) 43 protocol. IKE is a component of IPsec used for performing mutual 44 authentication and establishing and maintaining security 45 associations. 47 This version of the IKE specification combines the contents of what 48 were previously separate documents, including ISAKMP (RFC 2408), IKE 49 (RFC 2409), the Internet DOI (RFC 2407), NAT Traversal, Legacy 50 authentication, and remote address acquisition. 52 Version 2 of IKE does not interoperate with version 1, but it has 53 enough of the header format in common that both versions can 54 unambiguously run over the same UDP port. 56 Table of Contents 58 1 Introduction 59 1.1 Usage Scenarios 60 1.2 The Initial Exchange 61 1.3 The CREATE_CHILD_SA Exchange 62 1.4 The INFORMATIONAL Exchange 63 1.5 Informational Messages outside of an IKE_SA 64 2 IKE Protocol Details and Variations 65 2.1 Use of Retransmission Timers 66 2.2 Use of Sequence Numbers for Message ID 67 2.3 Window Size for overlapping requests 68 2.4 State Synchronization and Connection Timeouts 69 2.5 Version Numbers and Forward Compatibility 70 2.6 Cookies 71 2.7 Cryptographic Algorithm Negotiation 72 2.8 Rekeying 73 2.9 Traffic Selector Negotiation 74 2.10 Nonces 75 2.11 Address and Port Agility 76 2.12 Reuse of Diffie-Hellman Exponentials 77 2.13 Generating Keying Material 78 2.14 Generating Keying Material for the IKE_SA 79 2.15 Authentication of the IKE_SA 80 2.16 Extended Authentication Protocol Methods 81 2.17 Generating Keying Material for CHILD_SAs 82 2.18 Rekeying IKE_SAs using a CREATE_CHILD_SA exchange 83 2.19 Requesting an internal address on a remote network 84 2.20 Requesting a Peer's Version 85 2.21 Error Handling 86 2.22 IPComp 87 2.23 NAT Traversal 88 2.24 ECN (Explicit Congestion Notification) 89 3 Header and Payload Formats 90 3.1 The IKE Header 91 3.2 Generic Payload Header 92 3.3 Security Association Payload 93 3.4 Key Exchange Payload 94 3.5 Identification Payloads 95 3.6 Certificate Payload 96 3.7 Certificate Request Payload 97 3.8 Authentication Payload 98 3.9 Nonce Payload 99 3.10 Notify Payload 100 3.11 Delete Payload 101 3.12 Vendor ID Payload 102 3.13 Traffic Selector Payload 103 3.14 Encrypted Payload 104 3.15 Configuration Payload 105 3.16 Extended Authentication Protocol (EAP) Payload 106 4 Conformance Requirements 107 5 Security Considerations 108 6 IANA Considerations 109 7 Intellectual property rights 110 8 Acknowledgements 111 9 References 112 9.1 Normative References 113 9.2 Informative References 114 Appendix A: Summary of Changes from IKEv1 115 Appendix B: Diffie-Hellman Groups 116 Change History (To be removed from RFC) 117 Editor's Address 118 Full Copyright Statement 120 Requirements Terminology 122 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 123 "MAY" that appear in this document are to be interpreted as described 124 in [Bra97]. 126 1 Introduction 128 IP Security (IPsec) provides confidentiality, data integrity, access 129 control, and data source authentication to IP datagrams. These 130 services are provided by maintaining shared state between the source 131 and the sink of an IP datagram. This state defines, among other 132 things, the specific services provided to the datagram, which 133 cryptographic algorithms will be used to provide the services, and 134 the keys used as input to the cryptographic algorithms. 136 Establishing this shared state in a manual fashion does not scale 137 well. Therefore a protocol to establish this state dynamically is 138 needed. This memo describes such a protocol-- the Internet Key 139 Exchange (IKE). This is version 2 of IKE. Version 1 of IKE was 140 defined in RFCs 2407, 2408, and 2409. This single document is 141 intended to replace all three of those RFCs. 143 IKE performs mutual authentication between two parties and 144 establishes an IKE security association that includes shared secret 145 information that can be used to efficiently establish SAs for ESP 146 [RFC2406] and/or AH [RFC2402] and a set of cryptographic algorithms 147 to be used to protect the SAs. In this document, the term "suite" or 148 "cryptographic suite" refers to a complete set of algorithms used to 149 protect an SA. An initiator proposes one or more suites by listing 150 supported algorithms that can be combined into suites in a mix and 151 match fashion. IKE can also negotiate use of IPComp [IPCOMP] in 152 connection with an ESP and/or AH SA. We call the IKE SA an "IKE_SA". 153 The SAs for ESP and/or AH that get set up through that IKE_SA we call 154 "CHILD_SA"s. 156 All IKE communications consist of pairs of messages: a request and a 157 response. The pair is called an "exchange". We call the first 158 messages establishing an IKE_SA IKE_SA_INIT and IKE_AUTH exchanges 159 and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL 160 exchanges. In the common case, there is a single IKE_SA_INIT exchange 161 and a single IKE_AUTH exchange (a total of four messages) to 162 establish the IKE_SA and the first CHILD_SA. In exceptional cases, 163 there may be more than one of each of these exchanges. In all cases, 164 all IKE_SA_INIT exchanges MUST complete before any other exchange 165 type, then all IKE_AUTH exchanges MUST complete, and following that 166 any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur 167 in any order. In some scenarios, only a single CHILD_SA is needed 168 between the IPsec endpoints and therefore there would be no 169 additional exchanges. Subsequent exchanges MAY be used to establish 170 additional CHILD_SAs between the same authenticated pair of endpoints 171 and to perform housekeeping functions. 173 IKE message flow always consists of a request followed by a response. 174 It is the responsibility of the requester to ensure reliability. If 175 the response is not received within a timeout interval, the requester 176 needs to retransmit the request (or abandon the connection). 178 The first request/response of an IKE session negotiates security 179 parameters for the IKE_SA, sends nonces, and sends Diffie-Hellman 180 values. We call the initial exchange IKE_SA_INIT (request and 181 response). 183 The second request/response, which we'll call IKE_AUTH transmits 184 identities, proves knowledge of the secrets corresponding to the two 185 identities, and sets up an SA for the first (and often only) AH 186 and/or ESP CHILD_SA. 188 The types of subsequent exchanges are CREATE_CHILD_SA (which creates 189 a CHILD_SA), and INFORMATIONAL (which deletes an SA, reports error 190 conditions, or does other housekeeping). Every request requires a 191 response. An INFORMATIONAL request with no payloads is commonly used 192 as a check for liveness. These subsequent exchanges cannot be used 193 until the initial exchanges have completed. 195 In the description that follows, we assume that no errors occur. 196 Modifications to the flow should errors occur are described in 197 section 2.21. 199 1.1 Usage Scenarios 201 IKE is expected to be used to negotiate ESP and/or AH SAs in a number 202 of different scenarios, each with its own special requirements. 204 1.1.1 Security Gateway to Security Gateway Tunnel 206 +-+-+-+-+-+ +-+-+-+-+-+ 207 ! ! IPsec ! ! 208 Protected !Tunnel ! Tunnel !Tunnel ! Protected 209 Subnet <-->!Endpoint !<---------->!Endpoint !<--> Subnet 210 ! ! ! ! 211 +-+-+-+-+-+ +-+-+-+-+-+ 213 Figure 1: Security Gateway to Security Gateway Tunnel 215 In this scenario, neither endpoint of the IP connection implements 216 IPsec, but network nodes between them protect traffic for part of the 217 way. Protection is transparent to the endpoints, and depends on 218 ordinary routing sending packets through the tunnel endpoints for 219 processing. Each endpoint would announce the set of addresses 220 "behind" it, and packets would be sent in Tunnel Mode where the inner 221 IP header would contain the IP addresses of the actual endpoints. 223 1.1.2 Endpoint to Endpoint Transport 225 +-+-+-+-+-+ +-+-+-+-+-+ 226 ! ! IPsec ! ! 227 !Protected! Tunnel !Protected! 228 !Endpoint !<---------------------------------------->!Endpoint ! 229 ! ! ! ! 230 +-+-+-+-+-+ +-+-+-+-+-+ 232 Figure 2: Endpoint to Endpoint 234 In this scenario, both endpoints of the IP connection implement 235 IPsec. These endpoints may implement application layer access 236 controls based on the authenticated identities of the participants. 237 Transport mode will commonly be used with no inner IP header. If 238 there is an inner IP header, the inner addresses will be the same as 239 the outer addresses. A single pair of addresses will be negotiated 240 for packets to be sent over this SA. 242 It is possible in this scenario that one or both of the protected 243 endpoints will be behind a network address translation (NAT) node, in 244 which case the tunnelled packets will have to be UDP encapsulated so 245 that port numbers in the UDP headers can be used to identify 246 individual endpoints "behind" the NAT. 248 1.1.3 Endpoint to Security Gateway Transport 250 +-+-+-+-+-+ +-+-+-+-+-+ 251 ! ! IPsec ! ! Protected 252 !Protected! Tunnel !Tunnel ! Subnet 253 !Endpoint !<------------------------>!Endpoint !<--- and/or 254 ! ! ! ! Internet 255 +-+-+-+-+-+ +-+-+-+-+-+ 257 Figure 3: Endpoint to Security Gateway Tunnel 259 In this scenario, a protected endpoint (typically a portable roaming 260 computer) connects back to its corporate network through an IPsec 261 protected tunnel. It might use this tunnel only to access information 262 on the corporate network or it might tunnel all of its traffic back 263 through the corporate network in order to take advantage of 264 protection provided by a corporate firewall against Internet based 265 attacks. In either case, the protected endpoint will want an IP 266 address associated with the security gateway so that packets returned 267 to it will go to the security gateway and be tunnelled back. This IP 268 address may be static or may be dynamically allocated by the security 269 gateway. In support of the latter case, IKEv2 includes a mechanism 270 for the initiator to request an IP address owned by the security 271 gateway for use for the duration of its SA. 273 In this scenario, packets will use tunnel mode. On each packet from 274 the protected endpoint, the outer IP header will contain the source 275 IP address associated with its current location (i.e., the address 276 that will get traffic routed to the endpoint directly) while the 277 inner IP header will contain the source IP address assigned by the 278 security gateway (i.e., the address that will get traffic routed to 279 the security gateway for forwarding to the endpoint). The outer 280 destination address will always be that of the security gateway, 281 while the inner destination address will be the ultimate destination 282 for the packet. 284 In this scenario, it is possible that the protected endpoint will be 285 behind a NAT. In that case, the IP address as seen by the security 286 gateway will not be the same as the IP address sent by the protected 287 endpoint, and packets will have to be UDP encapsulated in order to be 288 routed properly. 290 1.1.4 Other Scenarios 292 Other scenarios are possible, as are nested combinations of the 293 above. One notable example combines aspects of 1.1.1 and 1.1.3. A 294 subnet may make all external accesses through a remote security 295 gateway using an IPsec tunnel, where the addresses on the subnet are 296 routed to the security gateway by the rest of the Internet. An 297 example would be someone's home network being virtually on the 298 Internet with static IP addresses even though connectivity is 299 provided by an ISP that assigns a single dynamically assigned IP 300 address to the user's security gateway (where the static IP addresses 301 and an IPsec relay is provided by a third party located elsewhere). 303 1.2 The Initial Exchanges 305 Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH 306 exchanges (known in IKEv1 as Phase 1). These initial exchanges 307 normally consist of four messages, though in some scenarios that 308 number can grow. All communications using IKE consist of 309 request/response pairs. We'll describe the base exchange first, 310 followed by variations. The first pair of messages (IKE_SA_INIT) 311 negotiate cryptographic algorithms, exchange nonces, and do a Diffie- 312 Hellman exchange. 314 The second pair of messages (IKE_AUTH) authenticate the previous 315 messages, exchange identities and certificates, and establish the 316 first CHILD_SA. Parts of these messages are encrypted and integrity 317 protected with keys established through the IKE_SA_INIT exchange, so 318 the identities are hidden from eavesdroppers and all fields in all 319 the messages are authenticated. 321 In the following description, the payloads contained in the message 322 are indicated by names such as SA. The details of the contents of 323 each payload are described later. Payloads which may optionally 324 appear will be shown in brackets, such as [CERTREQ], would indicate 325 that optionally a certificate request payload can be included. 327 The initial exchanges are as follows: 329 Initiator Responder 330 ----------- ----------- 331 HDR, SAi1, KEi, Ni --> 333 HDR contains the SPIs, version numbers, and flags of various sorts. 334 The SAi1 payload states the cryptographic algorithms the Initiator 335 supports for the IKE_SA. The KE payload sends the Initiator's 336 Diffie-Hellman value. Ni is the Initiator's nonce. 338 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 340 The Responder chooses a cryptographic suite from the Initiator's 341 offered choices and expresses that choice in the SAr1 payload, 342 completes the Diffie-Hellman exchange with the KEr payload, and sends 343 its nonce in the Nr payload. 345 At this point in the negotiation each party can generate SKEYSEED, 346 from which all keys are derived for that IKE_SA. All but the headers 347 of all the messages that follow are encrypted and integrity 348 protected. The keys used for the encryption and integrity protection 349 are derived from SKEYSEED and are known as SK_e (encryption) and SK_a 350 (authentication, a.k.a. integrity protection). A separate SK_e and 351 SK_a is computed for each direction. In addition to the keys SK_e 352 and SK_a derived from the DH value for protection of the IKE_SA, 353 another quantity SK_d is derived and used for derivation of further 354 keying material for CHILD_SAs. The notation SK { ... } indicates 355 that these payloads are encrypted and integrity protected using that 356 direction's SK_e and SK_a. 358 HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] 359 AUTH, SAi2, TSi, TSr} --> 361 The Initiator asserts her identity with the IDi payload, proves 362 knowledge of the secret corresponding to IDi and integrity protects 363 the contents of the first two messages using the AUTH payload (see 364 section 2.15). She might also send her certificate(s) in CERT 365 payload(s) and a list of her trust anchors in CERTREQ payload(s). If 366 any CERT payloads are included, the first certificate provided MUST 367 contain the public key used to verify the AUTH field. The optional 368 payload IDr enables Alice to specify which of Bob's identities she 369 wants to talk to. This is useful when Bob is hosting multiple 370 identities at the same IP address. She begins negotiation of a 371 CHILD_SA using the SAi2 payload. The final fields (starting with 372 SAi2) are described in the description of the CREATE_CHILD_SA 373 exchange. 375 <-- HDR, SK {IDr, [CERT,] AUTH, 376 SAr2, TSi, TSr} 378 The Responder asserts his identity with the IDr payload, optionally 379 sends one or more certificates (again with the certificate containing 380 the public key used to verify AUTH listed first), authenticates his 381 identity with the AUTH payload, and completes negotiation of a 382 CHILD_SA with the additional fields described below in the 383 CREATE_CHILD_SA exchange. 385 The recipients of messages 3 and 4 MUST verify that all signatures 386 and MACs are computed correctly and that the names in the ID payloads 387 correspond to the keys used to generate the AUTH payload. 389 1.3 The CREATE_CHILD_SA Exchange 391 This exchange consists of a single request/response pair, and was 392 referred to as a phase 2 exchange in IKEv1. It MAY be initiated by 393 either end of the IKE_SA after the initial exchanges are completed. 395 All messages following the initial exchange are cryptographically 396 protected using the cryptographic algorithms and keys negotiated in 397 the first two messages of the IKE exchange using a syntax described 398 in section 3.14. 400 Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this 401 section the term Initiator refers to the endpoint initiating this 402 exchange. 404 A CHILD_SA is created by sending a CREATE_CHILD_SA request. The 405 CREATE_CHILD_SA request MAY optionally contain a KE payload for an 406 additional Diffie-Hellman exchange to enable stronger guarantees of 407 forward secrecy for the CHILD_SA. The keying material for the 408 CHILD_SA is a function of SK_d established during the establishment 409 of the IKE_SA, the nonces exchanged during the CREATE_CHILD_SA 410 exchange, and the Diffie-Hellman value (if KE payloads are included 411 in the CREATE_CHILD_SA exchange). 413 In the CHILD_SA created as part of the initial exchange, a second KE 414 payload and nonce MUST NOT be sent. The nonces from the initial 415 exchange are used in computing the keys for the CHILD_SA. 417 The CREATE_CHILD_SA request contains: 419 Initiator Responder 420 ----------- ----------- 421 HDR, SK {[N], SA, Ni, [KEi], 422 [TSi, TSr]} --> 424 The Initiator sends SA offer(s) in the SA payload, a nonce in the Ni 425 payload, optionally a Diffie-Hellman value in the KEi payload, and 426 the proposed traffic selectors in the TSi and TSr payloads. If this 427 CREATE_CHILD_SA exchange is rekeying an existing SA other than the 428 IKE_SA, the leading N payload of type REKEY_SA MUST identify the SA 429 being rekeyed. If this CREATE_CHILD_SA exchange is not rekeying and 430 existing SA, the N payload MUST be omitted. If the SA offers include 431 different Diffie-Hellman groups, KEi MUST be an element of the group 432 the Initiator expects the responder to accept. If she guesses wrong, 433 the CREATE_CHILD_SA exchange will fail and she will have to retry 434 with a different KEi. 436 The message following the header is encrypted and the message 437 including the header is integrity protected using the cryptographic 438 algorithms negotiated for the IKE_SA. 440 The CREATE_CHILD_SA response contains: 442 <-- HDR, SK {SA, Nr, [KEr], 443 [TSi, TSr]} 445 The Responder replies (using the same Message ID to respond) with the 446 accepted offer in an SA payload, and a Diffie-Hellman value in the 447 KEr payload if KEi was included in the request and the selected 448 cryptographic suite includes that group. If the responder chooses a 449 cryptographic suite with a different group, it MUST reject the 450 request. The initiator SHOULD repeat the request, but now with a KEi 451 payload from the group the responder selected. 453 The traffic selectors for traffic to be sent on that SA are specified 454 in the TS payloads, which may be a subset of what the Initiator of 455 the CHILD_SA proposed. Traffic selectors are omitted if this 456 CREATE_CHILD_SA request is being used to change the key of the 457 IKE_SA. 459 1.4 The INFORMATIONAL Exchange 461 At various points during the operation of an IKE_SA, peers may desire 462 to convey control messages to each other regarding errors or 463 notifications of certain events. To accomplish this IKE defines an 464 INFORMATIONAL exchange. INFORMATIONAL exchanges MAY ONLY occur after 465 the initial exchanges and are cryptographically protected with the 466 negotiated keys. 468 Control messages that pertain to an IKE_SA MUST be sent under that 469 IKE_SA. Control messages that pertain to CHILD_SAs MUST be sent under 470 the protection of the IKE_SA which generated them (or its successor 471 if the IKE_SA was replaced for the purpose of rekeying). 473 Messages in an INFORMATIONAL Exchange contain zero or more 474 Notification, Delete, and Configuration payloads. The Recipient of an 475 INFORMATIONAL Exchange request MUST send some response (else the 476 Sender will assume the message was lost in the network and will 477 retransmit it). That response MAY be a message with no payloads. The 478 request message in an INFORMATIONAL Exchange MAY also contain no 479 payloads. This is the expected way an endpoint can ask the other 480 endpoint to verify that it is alive. 482 ESP and AH SAs always exist in pairs, with one SA in each direction. 483 When an SA is closed, both members of the pair MUST be closed. When 484 SAs are nested, as when data (and IP headers if in tunnel mode) are 485 encapsulated first with IPComp, then with ESP, and finally with AH 486 between the same pair of endpoints, all of the SAs MUST be deleted 487 together. Each endpoint MUST close its incoming SAs and allow the 488 other endpoint to close the other SA in each pair. To delete an SA, 489 an INFORMATIONAL Exchange with one or more delete payloads is sent 490 listing the SPIs (as they would be expected in the headers of inbound 491 packets) of the SAs to be deleted. The recipient MUST close the 492 designated SAs. Normally, the reply in the INFORMATIONAL Exchange 493 will contain delete payloads for the paired SAs going in the other 494 direction. There is one exception. If by chance both ends of a set 495 of SAs independently decide to close them, each may send a delete 496 payload and the two requests may cross in the network. If a node 497 receives a delete request for SAs for which it has already issued a 498 delete request, it MUST delete the outgoing SAs while processing the 499 request and the incoming SAs while processing the response. In that 500 case, the responses MUST NOT include delete payloads for the deleted 501 SAs, since that would result in duplicate deletion and could in 502 theory delete the wrong SA. 504 A node SHOULD regard half closed connections as anomalous and audit 505 their existence should they persist. Note that this specification 506 nowhere specifies time periods, so it is up to individual endpoints 507 to decide how long to wait. A node MAY refuse to accept incoming data 508 on half closed connections but MUST NOT unilaterally close them and 509 reuse the SPIs. If connection state becomes sufficiently messed up, a 510 node MAY close the IKE_SA which will implicitly close all SAs 511 negotiated under it. It can then rebuild the SAs it needs on a clean 512 base under a new IKE_SA. 514 The INFORMATIONAL Exchange is defined as: 516 Initiator Responder 517 ----------- ----------- 518 HDR, SK {[N,] [D,] [CP,] ...} --> 519 <-- HDR, SK {[N,] [D,] [CP], ...} 521 The processing of an INFORMATIONAL Exchange is determined by its 522 component payloads. 524 1.5 Informational Messages outside of an IKE_SA 526 If a packet arrives with an unrecognized SPI, it could be because the 527 receiving node has recently crashed and lost state or because of some 528 other system malfunction or attack. If the receiving node has an 529 active IKE_SA to the IP address from whence the packet came, it MAY 530 send a notification of the wayward packet over that IKE_SA. If it 531 does not, it MAY send an Informational message without cryptographic 532 protection to the source IP address and port to alert it to a 533 possible problem. 535 2 IKE Protocol Details and Variations 537 IKE normally listens and sends on UDP port 500, though IKE messages 538 may also be received on UDP port 4500 with a slightly different 539 format (see section 2.23). Since UDP is a datagram (unreliable) 540 protocol, IKE includes in its definition recovery from transmission 541 errors, including packet loss, packet replay, and packet forgery. IKE 542 is designed to function so long as (1) at least one of a series of 543 retransmitted packets reaches its destination before timing out; and 544 (2) the channel is not so full of forged and replayed packets so as 545 to exhaust the network or CPU capacities of either endpoint. Even in 546 the absence of those minimum performance requirements, IKE is 547 designed to fail cleanly (as though the network were broken). 549 2.1 Use of Retransmission Timers 551 All messages in IKE exist in pairs: a request and a response. The 552 setup of an IKE_SA normally consists of two request/response pairs. 553 Once the IKE_SA is set up, either end of the security association may 554 initiate requests at any time, and there can be many requests and 555 responses "in flight" at any given moment. But each message is 556 labelled as either a request or a response and for each 557 request/response pair one end of the security association is the 558 Initiator and the other is the Responder. 560 For every pair of IKE messages, the Initiator is responsible for 561 retransmission in the event of a timeout. The Responder MUST never 562 retransmit a response unless it receives a retransmission of the 563 request. In that event, the Responder MUST ignore the retransmitted 564 request except insofar as it triggers a retransmission of the 565 response. The Initiator MUST remember each request until it receives 566 the corresponding response. The Responder MUST remember each response 567 until it receives a request whose sequence number is larger than the 568 sequence number in the response plus his window size (see section 569 2.3). 571 IKE is a reliable protocol, in the sense that the Initiator MUST 572 retransmit a request until either it receives a corresponding reply 573 OR it deems the IKE security association to have failed and it 574 discards all state associated with the IKE_SA and any CHILD_SAs 575 negotiated using that IKE_SA. 577 2.2 Use of Sequence Numbers for Message ID 579 Every IKE message contains a Message ID as part of its fixed header. 580 This Message ID is used to match up requests and responses, and to 581 identify retransmissions of messages. 583 The Message ID is a 32 bit quantity, which is zero for the first IKE 584 request in each direction. The IKE_SA initial setup messages will 585 always be numbered 0 and 1. Each endpoint in the IKE Security 586 Association maintains two "current" Message IDs: the next one to be 587 used for a request it initiates and the next one it expects to see in 588 a request from the other end. These counters increment as requests 589 are generated and received. Responses always contain the same message 590 ID as the corresponding request. That means that after the initial 591 exchange, each integer n may appear as the message ID in four 592 distinct messages: The nth request from the original IKE Initiator, 593 the corresponding response, the nth request from the original IKE 594 Responder, and the corresponding response. If the two ends make very 595 different numbers of requests, the Message IDs in the two directions 596 can be very different. There is no ambiguity in the messages, 597 however, because the (I)nitiator and (R)esponse bits in the message 598 header specify which of the four messages a particular one is. 600 Note that Message IDs are cryptographically protected and provide 601 protection against message replays. In the unlikely event that 602 Message IDs grow too large to fit in 32 bits, the IKE_SA MUST be 603 closed. Rekeying an IKE_SA resets the sequence numbers. 605 2.3 Window Size for overlapping requests 607 In order to maximize IKE throughput, an IKE endpoint MAY issue 608 multiple requests before getting a response to any of them if the 609 other endpoint has indicated its ability to handle such requests. For 610 simplicity, an IKE implementation MAY choose to process requests 611 strictly in order and/or wait for a response to one request before 612 issuing another. Certain rules must be followed to assure 613 interoperability between implementations using different strategies. 615 After an IKE_SA is set up, either end can initiate one or more 616 requests. These requests may pass one another over the network. An 617 IKE endpoint MUST be prepared to accept and process a request while 618 it has a request outstanding in order to avoid a deadlock in this 619 situation. An IKE endpoint SHOULD be prepared to accept and process 620 multiple requests while it has a request outstanding. 622 An IKE endpoint MUST wait for a response to each of its messages 623 before sending a subsequent message unless it has received a 624 SET_WINDOW_SIZE Notify message from its peer informing it that the 625 peer is prepared to maintain state for multiple outstanding messages 626 in order to allow greater throughput. 628 An IKE endpoint MUST NOT exceed the peer's stated window size for 629 transmitted IKE requests. In other words, if Bob stated his window 630 size is N, then when Alice needs to make a request X, she MUST wait 631 until she has received responses to all requests up through request 632 X-N. An IKE endpoint MUST keep a copy of (or be able to regenerate 633 exactly) each request it has sent until it receives the corresponding 634 response. An IKE endpoint MUST keep a copy of (or be able to 635 regenerate exactly) the number of previous responses equal to its 636 declared window size in case its response was lost and the Initiator 637 requests its retransmission by retransmitting the request. 639 An IKE endpoint supporting a window size greater than one SHOULD be 640 capable of processing incoming requests out of order to maximize 641 performance in the event of network failures or packet reordering. 643 2.4 State Synchronization and Connection Timeouts 645 An IKE endpoint is allowed to forget all of its state associated with 646 an IKE_SA and the collection of corresponding CHILD_SAs at any time. 647 This is the anticipated behavior in the event of an endpoint crash 648 and restart. It is important when an endpoint either fails or 649 reinitializes its state that the other endpoint detect those 650 conditions and not continue to waste network bandwidth by sending 651 packets over discarded SAs and having them fall into a black hole. 653 Since IKE is designed to operate in spite of Denial of Service (DoS) 654 attacks from the network, an endpoint MUST NOT conclude that the 655 other endpoint has failed based on any routing information (e.g., 656 ICMP messages) or IKE messages that arrive without cryptographic 657 protection (e.g., Notify messages complaining about unknown SPIs). An 658 endpoint MUST conclude that the other endpoint has failed only when 659 repeated attempts to contact it have gone unanswered for a timeout 660 period or when a cryptographically protected INITIAL_CONTACT 661 notification is received on a different IKE_SA to the same 662 authenticated identity. An endpoint SHOULD suspect that the other 663 endpoint has failed based on routing information and initiate a 664 request to see whether the other endpoint is alive. To check whether 665 the other side is alive, IKE specifies an empty INFORMATIONAL message 666 that (like all IKE requests) requires an acknowledgment. If a 667 cryptographically protected message has been received from the other 668 side recently, unprotected notifications MAY be ignored. 669 Implementations MUST limit the rate at which they take actions based 670 on unprotected messages. 672 Numbers of retries and lengths of timeouts are not covered in this 673 specification because they do not affect interoperability. It is 674 suggested that messages be retransmitted at least a dozen times over 675 a period of at least several minutes before giving up on an SA, but 676 different environments may require different rules. If there has only 677 been outgoing traffic on all of the SAs associated with an IKE_SA, it 678 is essential to confirm liveness of the other endpoint to avoid black 679 holes. If no cryptographically protected messages have been received 680 on an IKE_SA or any of its CHILD_SAs recently, the system needs to 681 perform a liveness check in order to prevent sending messages to a 682 dead peer. Receipt of a fresh cryptographically protected message on 683 an IKE_SA or any of its CHILD_SAs assures liveness of the IKE_SA and 684 all of its CHILD_SAs. Note that this places requirements on the 685 failure modes of an IKE endpoint. An implementation MUST NOT continue 686 sending on any SA if some failure prevents it from receiving on all 687 of the associated SAs. If CHILD_SAs can fail independently from one 688 another without the associated IKE_SA being able to send a delete 689 message, then they MUST be negotiated by separate IKE_SAs. 691 There is a Denial of Service attack on the Initiator of an IKE_SA 692 that can be avoided if the Initiator takes the proper care. Since the 693 first two messages of an SA setup are not cryptographically 694 protected, an attacker could respond to the Initiator's message 695 before the genuine Responder and poison the connection setup attempt. 696 To prevent this, the Initiator MAY be willing to accept multiple 697 responses to its first message, treat each as potentially legitimate, 698 respond to it, and then discard all the invalid half open connections 699 when she receives a valid cryptographically protected response to any 700 one of her requests. Once a cryptographically valid response is 701 received, all subsequent responses should be ignored whether or not 702 they are cryptographically valid. 704 Note that with these rules, there is no reason to negotiate and agree 705 upon an SA lifetime. If IKE presumes the partner is dead, based on 706 repeated lack of acknowledgment to an IKE message, then the IKE SA 707 and all CHILD_SAs set up through that IKE_SA are deleted. 709 An IKE endpoint may at any time delete inactive CHILD_SAs to recover 710 resources used to hold their state. If an IKE endpoint chooses to do 711 so, it MUST send Delete payloads to the other end notifying it of the 712 deletion. It MAY similarly time out the IKE_SA. Closing the IKE_SA 713 implicitly closes all associated CHILD_SAs. In this case, an IKE 714 endpoint SHOULD send a Delete payload indicating that it has closed 715 the IKE_SA. 717 2.5 Version Numbers and Forward Compatibility 719 This document describes version 2.0 of IKE, meaning the major version 720 number is 2 and the minor version number is zero. It is likely that 721 some implementations will want to support both version 1.0 and 722 version 2.0, and in the future, other versions. 724 The major version number should only be incremented if the packet 725 formats or required actions have changed so dramatically that an 726 older version node would not be able to interoperate with a newer 727 version node if it simply ignored the fields it did not understand 728 and took the actions specified in the older specification. The minor 729 version number indicates new capabilities, and MUST be ignored by a 730 node with a smaller minor version number, but used for informational 731 purposes by the node with the larger minor version number. For 732 example, it might indicate the ability to process a newly defined 733 notification message. The node with the larger minor version number 734 would simply note that its correspondent would not be able to 735 understand that message and therefore would not send it. 737 If an endpoint receives a message with a higher major version number, 738 it MUST drop the message and SHOULD send an unauthenticated 739 notification message containing the highest version number it 740 supports. If an endpoint supports major version n, and major version 741 m, it MUST support all versions between n and m. If it receives a 742 message with a major version that it supports, it MUST respond with 743 that version number. In order to prevent two nodes from being tricked 744 into corresponding with a lower major version number than the maximum 745 that they both support, IKE has a flag that indicates that the node 746 is capable of speaking a higher major version number. 748 Thus the major version number in the IKE header indicates the version 749 number of the message, not the highest version number that the 750 transmitter supports. If A is capable of speaking versions n, n+1, 751 and n+2, and B is capable of speaking versions n and n+1, then they 752 will negotiate speaking n+1, where A will set the flag indicating 753 ability to speak a higher version. If they mistakenly (perhaps 754 through an active attacker sending error messages) negotiate to 755 version n, then both will notice that the other side can support a 756 higher version number, and they MUST break the connection and 757 reconnect using version n+1. 759 Note that IKEv1 does not follow these rules, because there is no way 760 in v1 of noting that you are capable of speaking a higher version 761 number. So an active attacker can trick two v2-capable nodes into 762 speaking v1. When a v2-capable node negotiates down to v1, it SHOULD 763 note that fact in its logs. 765 Also for forward compatibility, all fields marked RESERVED MUST be 766 set to zero by a version 2.0 implementation and their content MUST be 767 ignored by a version 2.0 implementation ("Be conservative in what you 768 send and liberal in what you receive"). In this way, future versions 769 of the protocol can use those fields in a way that is guaranteed to 770 be ignored by implementations that do not understand them. 771 Similarly, payload types that are not defined are reserved for future 772 use and implementations of version 2.0 MUST skip over those payloads 773 and ignore their contents. 775 IKEv2 adds a "critical" flag to each payload header for further 776 flexibility for forward compatibility. If the critical flag is set 777 and the payload type is unrecognized, the message MUST be rejected 778 and the response to the IKE request containing that payload MUST 779 include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an 780 unsupported critical payload was included. If the critical flag is 781 not set and the payload type is unsupported, that payload MUST be 782 ignored. 784 While new payload types may be added in the future and may appear 785 interleaved with the fields defined in this specification, 786 implementations MUST send the payloads defined in this specification 787 in the order shown in the figures in section 2 and implementations 788 SHOULD reject as invalid a message with those payloads in any other 789 order. 791 2.6 Cookies 793 The term "cookies" originates with Karn and Simpson [RFC 2522] in 794 Photuris, an early proposal for key management with IPsec. It has 795 persisted because the IETF has never rejected a proposal involving 796 cookies. The ISAKMP fixed message header includes two eight octet 797 fields titled "cookies", and that syntax is used by both IKEv1 and 798 IKEv2 though in IKEv2 they are referred to as the IKE SPI and there 799 is a new separate field in a Notify payload holding the cookie. The 800 initial two eight octet fields in the header are used as a connection 801 identifier at the beginning of IKE packets. Each endpoint chooses one 802 of the two SPIs and SHOULD choose them so as to be unique identifiers 803 of an IKE_SA. An SPI value of zero is special and indicates that the 804 remote SPI value is not yet known by the sender. 806 Unlike ESP and AH where only the recipient's SPI appears in the 807 header of a message, in IKE the sender's SPI is also sent in every 808 message. Since the SPI chosen by the original initiator of the IKE_SA 809 is always sent first, an endpoint with multiple IKE_SAs open that 810 wants to find the appropriate IKE_SA using the SPI it assigned must 811 look at the I(nitiator) Flag bit in the header to determine whether 812 it assigned the first or the second eight octets. 814 In the first message of an initial IKE exchange, the initiator will 815 not know the responder's SPI value and will therefore set that field 816 to zero. 818 An expected attack against IKE is state and CPU exhaustion, where the 819 target is flooded with session initiation requests from forged IP 820 addresses. This attack can be made less effective if an 821 implementation of a responder uses minimal CPU and commits no state 822 to an SA until it knows the initiator can receive packets at the 823 address from which he claims to be sending them. To accomplish this, 824 a responder SHOULD - when it detects a large number of half-open 825 IKE_SAs - reject initial IKE messages unless they contain a Notify 826 payload of type COOKIE. It SHOULD instead send an unprotected IKE 827 message as a response and include COOKIE Notify payload with the 828 cookie data to be returned. Initiators who receive such responses 829 MUST retry the IKE_SA_INIT with a Notify payload of type COOKIE 830 containing the responder supplied cookie data as the first payload 831 and all other payloads unchanged. The initial exchange will then be 832 as follows: 834 Initiator Responder 835 ----------- ----------- 836 HDR(A,0), SAi1, KEi, Ni --> 838 <-- HDR(A,0), N(COOKIE) 840 HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> 842 <-- HDR(A,B), SAr1, KEr, Nr, [CERTREQ] 844 HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,] 845 AUTH, SAi2, TSi, TSr} --> 847 <-- HDR(A,B), SK {IDr, [CERT,] AUTH, 848 SAr2, TSi, TSr} 850 The first two messages do not affect any initiator or responder state 851 except for communicating the cookie. In particular, the message 852 sequence numbers in the first four messages will all be zero and the 853 message sequence numbers in the last two messages will be one. 'A' is 854 the SPI assigned by the initiator, while 'B' is the SPI assigned by 855 the responder. 857 An IKE implementation SHOULD implement its responder cookie 858 generation in such a way as to not require any saved state to 859 recognize its valid cookie when the second IKE_SA_INIT message 860 arrives. The exact algorithms and syntax they use to generate 861 cookies does not affect interoperability and hence is not specified 862 here. The following is an example of how an endpoint could use 863 cookies to implement limited DOS protection. 865 A good way to do this is to set the responder cookie to be: 867 Cookie = | Hash(Ni | IPi | SPIi | ) 869 where is a randomly generated secret known only to the 870 responder and periodically changed. should be 871 changed whenever is regenerated. The cookie can be 872 recomputed when the IKE_SA_INIT arrives the second time and compared 873 to the cookie in the received message. If it matches, the responder 874 knows that SPIr was generated since the last change to and 875 that IPi must be the same as the source address it saw the first 876 time. Incorporating SPIi into the calculation assures that if 877 multiple IKE_SAs are being set up in parallel they will all get 878 different cookies (assuming the initiator chooses unique SPIi's). 879 Incorporating Ni into the hash assures that an attacker who sees only 880 message 2 can't successfully forge a message 3. 882 If a new value for is chosen while there are connections in 883 the process of being initialized, an IKE_SA_INIT might be returned 884 with other than the current . The responder in 885 that case MAY reject the message by sending another response with a 886 new cookie or it MAY keep the old value of around for a 887 short time and accept cookies computed from either one. The 888 responder SHOULD NOT accept cookies indefinitely after is 889 changed, since that would defeat part of the denial of service 890 protection. The responder SHOULD change the value of 891 frequently, especially if under attack. 893 2.7 Cryptographic Algorithm Negotiation 895 The payload type known as "SA" indicates a proposal for a set of 896 choices of protocols (IKE, ESP, and/or AH) for the SA as well as 897 cryptographic algorithms associated with each protocol. 899 An SA consists of one or more proposals. Each proposal includes one 900 or more protocols (usually one). Each protocol contains one or more 901 transforms - each specifying a cryptographic algorithm. Each 902 transform contains zero or more attributes (attributes are only 903 needed if the transform identifier does not completely specify the 904 cryptographic algorithm). 906 This hierarchical structure was designed to be able to efficiently 907 encode proposals for cryptographic suites when the number of 908 supported suites is large because multiple values are acceptable for 909 multiple transforms. The responder MUST choose a single suite, which 910 MAY be any subset of the SA proposal following the rules below: 912 Each proposal contains one or more protocols. If a proposal is 913 accepted, the SA response MUST contain the same protocols in the 914 same order as the proposal. At most one proposal MAY be accepted. 915 (Example: if a single proposal contains ESP and AH and that 916 proposal is accepted, both ESP and AH MUST be accepted. If ESP and 917 AH are included in separate proposals, only one of them MAY be 918 accepted). 920 Each protocol in a proposal contains one or more transforms. Each 921 transform contains a transform type. The accepted cryptographic 922 suite MUST contain exactly one transform of each type included in 923 the proposal. For example: if an ESP proposal includes transforms 924 ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256, 925 AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain 926 one of the ENCR_ transforms and one of the AUTH_ transforms. Thus 927 six combinations are acceptable). 929 Since Alice sends her Diffie-Hellman value in the IKE_SA_INIT, she 930 must guess at the Diffie-Hellman group that Bob will select from her 931 list of supported groups. If she guesses wrong, Bob will respond 932 with a Notify payload of type INVALID_KE_PAYLOAD indicating the 933 selected group. In this case, Alice MUST retry the IKE_SA_INIT with 934 the corrected Diffie-Hellman group. Alice MUST again propose her full 935 set of acceptable cryptographic suites because the rejection message 936 was unauthenticated and otherwise an active attacker could trick 937 Alice and Bob into negotiating a weaker suite than a stronger one 938 that they both prefer. 940 2.8 Rekeying 942 IKE, ESP, and AH security associations use secret keys which SHOULD 943 only be used for a limited amount of time and to protect a limited 944 amount of data. This limits the lifetime of the entire security 945 association. When the lifetime of a security association expires the 946 security association must not be used. If there is demand, new 947 security associations MAY be established. Reestablishment of 948 security associations to take the place of ones which expire is 949 referred to as "rekeying". 951 To allow for minimal IPsec implementations, the ability to rekey SAs 952 without restarting the entire IKE_SA is optional. An implementation 953 MAY refuse all CREATE_CHILD_SA requests within an IKE_SA. If an SA 954 has expired or is about to expire and rekeying attempts using the 955 mechanisms described here fail, an implementation MUST close the 956 IKE_SA and any associated CHILD_SAs and then MAY start new ones. 957 Implementations SHOULD support in place rekeying of SAs, since doing 958 so offers better performance and is likely to reduce the number of 959 packets lost during the transition. 961 To rekey a CHILD_SA within an existing IKE_SA, create a new, 962 equivalent SA (see section 2.17 below), and when the new one is 963 established, delete the old one. To rekey an IKE_SA, establish a new 964 equivalent IKE_SA (see section 2.18 below) with the peer to whom the 965 old IKE_SA is shared using a CREATE_CHILD_SA within the existing 966 IKE_SA. An IKE_SA so created inherits all of the original IKE_SA's 967 CHILD_SAs. Use the new IKE_SA for all control messages needed to 968 maintain the CHILD_SAs created by the old IKE_SA, and delete the old 969 IKE_SA. The Delete payload to delete itself MUST be the last request 970 sent over an IKE_SA. 972 SAs SHOULD be rekeyed proactively, i.e., the new SA should be 973 established before the old one expires and becomes unusable. Enough 974 time should elapse between the time the new SA is established and the 975 old one becomes unusable so that traffic can be switched over to the 976 new SA. 978 A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes 979 were negotiated. In IKEv2, each end of the SA is responsible for 980 enforcing its own lifetime policy on the SA and rekeying the SA when 981 necessary. If the two ends have different lifetime policies, the end 982 with the shorter lifetime will end up always being the one to request 983 the rekeying. If an SA bundle has been inactive for a long time and 984 if an endpoint would not initiate the SA in the absence of traffic, 985 the endpoint MAY choose to close the SA instead of rekeying it when 986 its lifetime expires. It SHOULD do so if there has been no traffic 987 since the last time the SA was rekeyed. 989 If the two ends have the same lifetime policies, it is possible that 990 both will initiate a rekeying at the same time (which will result in 991 redundant SAs). To reduce the probability of this happening, the 992 timing of rekeying requests SHOULD be jittered (delayed by a random 993 amount of time after the need for rekeying is noticed). 995 This form of rekeying may temporarily result in multiple similar SAs 996 between the same pairs of nodes. When there are two SAs eligible to 997 receive packets, a node MUST accept incoming packets through either 998 SA. If redundant SAs are created though such a collision, the SA 999 created with the lowest of the four nonces used in the two exchanges 1000 SHOULD be closed by the endpoint that created it. 1002 Note that IKEv2 deliberately allows parallel SAs with the same 1003 traffic selectors between common endpoints. One of the purposes of 1004 this is to support traffic QoS differences among the SAs (see section 1005 4.1 of [RFC 2983]). Hence unlike IKEv1, the combination of the 1006 endpoints and the traffic selectors may not uniquely identify an SA 1007 between those endpoints, so the IKEv1 rekeying heuristic of deleting 1008 SAs on the basis of duplicate traffic selectors SHOULD NOT be used. 1010 The node that initiated the surviving rekeyed SA SHOULD delete the 1011 replaced SA after the new one is established. 1013 There are timing windows - particularly in the presence of lost 1014 packets - where endpoints may not agree on the state of an SA. The 1015 responder to a CREATE_CHILD_SA MUST be prepared to accept messages on 1016 an SA before sending its response to the creation request, so there 1017 is no ambiguity for the initiator. The initiator may begin sending on 1018 an SA as soon as it processes the response. The initiator, however, 1019 cannot receive on a newly created SA until it receives and processes 1020 the response to its CREATE_CHILD_SA request. How, then, is the 1021 responder to know when it is OK to send on the newly created SA? 1023 From a technical correctness and interoperability perspective, the 1024 responder MAY begin sending on an SA as soon as it sends its response 1025 to the CREATE_CHILD_SA request. In some situations, however, this 1026 could result in packets unnecessarily being dropped, so an 1027 implementation MAY want to defer such sending. 1029 The responder can be assured that the initiator is prepared to 1030 receive messages on an SA if either (1) it has received a 1031 cryptographically valid message on the new SA, or (2) the new SA 1032 rekeys an existing SA and it receives an IKE request to close the 1033 replaced SA. When rekeying an SA, the responder SHOULD continue to 1034 send requests on the old SA until it one of those events occurs. When 1035 establishing a new SA, the responder MAY defer sending messages on a 1036 new SA until either it receives one or a timeout has occurred. If an 1037 initiator receives a message on an SA for which it has not received a 1038 response to its CREATE_CHILD_SA request, it SHOULD interpret that as 1039 a likely packet loss and retransmit the CREATE_CHILD_SA request. An 1040 initiator MAY send a dummy message on a newly created SA if it has no 1041 messages queued in order to assure the responder that the initiator 1042 is ready to receive messages. 1044 2.9 Traffic Selector Negotiation 1046 When an IP packet is received by an RFC2401 compliant IPsec subsystem 1047 and matches a "protect" selector in its SPD, the subsystem MUST 1048 protect that packet with IPsec. When no SA exists yet it is the task 1049 of IKE to create it. Maintenance of a system's SPD is outside the 1050 scope of IKE (see [PFKEY] for an example protocol), though some 1051 implementations might update their SPD in connection with the running 1052 of IKE (for an example scenario, see section 1.1.3). 1054 Traffic Selector (TS) payloads allow endpoints to communicate some of 1055 the information from their SPD to their peers. TS payloads specify 1056 the selection criteria for packets that will be forwarded over the 1057 newly set up SA. This can serve as a consistency check in some 1058 scenarios to assure that the SPDs are consistent. In others, it 1059 guides the dynamic update of the SPD. 1061 Two TS payloads appear in each of the messages in the exchange that 1062 creates a CHILD_SA pair. Each TS payload contains one or more Traffic 1063 Selectors. Each Traffic Selector consists of an address range (IPv4 1064 or IPv6), a port range, and a protocol ID. In support of the scenario 1065 described in section 1.1.3, an initiator may request that the 1066 responder assign an IP address and tell the initiator what it is. 1068 IKEv2 allows the responder to choose a subset of the traffic proposed 1069 by the initiator. This could happen when the configuration of the 1070 two endpoints are being updated but only one end has received the new 1071 information. Since the two endpoints may be configured by different 1072 people, the incompatibility may persist for an extended period even 1073 in the absence of errors. It also allows for intentionally different 1074 configurations, as when one end is configured to tunnel all addresses 1075 and depends on the other end to have the up to date list. 1077 The first of the two TS payloads is known as TSi (Traffic Selector- 1078 initiator). The second is known as TSr (Traffic Selector-responder). 1079 TSi specifies the source address of traffic forwarded from (or the 1080 destination address of traffic forwarded to) the initiator of the 1081 CHILD_SA pair. TSr specifies the destination address of the traffic 1082 forwarded from (or the source address of the traffic forwarded to) 1083 the responder of the CHILD_SA pair. For example, if Alice initiates 1084 the creation of the CHILD_SA pair from Alice to Bob, and wishes to 1085 tunnel all traffic from subnet 10.2.16.* on Alice's side to subnet 1086 18.16.*.* on Bob's side, Alice would include a single traffic 1087 selector in each TS payload. TSi would specify the address range 1088 (10.2.16.0 - 10.2.16.255) and TSr would specify the address range 1089 (18.16.0.0 - 18.16.255.255). Assuming that proposal was acceptable to 1090 Bob, he would send identical TS payloads back. 1092 The Responder is allowed to narrow the choices by selecting a subset 1093 of the traffic, for instance by eliminating or narrowing the range of 1094 one or more members of the set of traffic selectors, provided the set 1095 does not become the NULL set. 1097 It is possible for the Responder's policy to contain multiple smaller 1098 ranges, all encompassed by the Initiator's traffic selector, and with 1099 the Responder's policy being that each of those ranges should be sent 1100 over a different SA. Continuing the example above, Bob might have a 1101 policy of being willing to tunnel those addresses to and from Alice, 1102 but might require that each address pair be on a separately 1103 negotiated CHILD_SA. If Alice generated her request in response to an 1104 incoming packet from 10.2.16.43 to 18.16.2.123, there would be no way 1105 for Bob to determine which pair of addresses should be included in 1106 this tunnel, and he would have to make his best guess or reject the 1107 request with a status of SINGLE_PAIR_REQUIRED. 1109 To enable Bob to choose the appropriate range in this case, if Alice 1110 has initiated the SA due to a data packet, Alice SHOULD include as 1111 the first traffic selector in each of TSi and TSr a very specific 1112 traffic selector including the addresses in the packet triggering the 1113 request. In the example, Alice would include in TSi two traffic 1114 selectors: the first containing the address range (10.2.16.43 - 1115 10.2.16.43) and the source port and protocol from the packet and the 1116 second containing (10.2.16.0 - 10.2.16.255) with all ports and 1117 protocols. She would similarly include two traffic selectors in TSr. 1119 If Bob's policy does not allow him to accept the entire set of 1120 traffic selectors in Alice's request, but does allow him to accept 1121 the first selector of TSi and TSr, then Bob MUST narrow the traffic 1122 selectors to a subset that includes Alice's first choices. In this 1123 example, Bob might respond with TSi being (10.2.16.43 - 10.2.16.43) 1124 with all ports and protocols. 1126 If Alice creates the CHILD_SA pair not in response to an arriving 1127 packet, but rather - say - upon startup, then there may be no 1128 specific addresses Alice prefers for the initial tunnel over any 1129 other. In that case, the first values in TSi and TSr MAY be ranges 1130 rather than specific values, and Bob chooses a subset of Alice's TSi 1131 and TSr that are acceptable to him. If more than one subset is 1132 acceptable but their union is not, Bob MUST accept some subset and 1133 MAY include a Notify payload of type ADDITIONAL_TS_POSSIBLE to 1134 indicate that Alice might want to try again. This case will only 1135 occur when Alice and Bob are configured differently from one another. 1136 If Alice and Bob agree on the granularity of tunnels, she will never 1137 request a tunnel wider than Bob will accept. 1139 2.10 Nonces 1141 The IKE_SA_INIT messages each contain a nonce. These nonces are used 1142 as inputs to cryptographic functions. The CREATE_CHILD_SA request 1143 and the CREATE_CHILD_SA response also contain nonces. These nonces 1144 are used to add freshness to the key derivation technique used to 1145 obtain keys for CHILD_SA, and to extract strong pseudorandom bits 1146 from the Diffie-Hellman key. Nonces used in IKEv2 MUST be randomly 1147 chosen, MUST be at least 128 bits in size, and MUST be at least half 1148 the key size of the negotiated prf. If the same random number source 1149 is used for both keys and nonces, care must be taken to ensure that 1150 the latter use does not compromise the former. 1152 2.11 Address and Port Agility 1154 IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and 1155 AH associations for the same IP addresses it runs over. The IP 1156 addresses and ports in the outer header are, however, not themselves 1157 cryptographically protected, and IKE is designed to work even through 1158 Network Address Translation (NAT) boxes. An implementation MUST 1159 accept incoming requests even if not received from UDP port 500 or 1160 4500, and MUST respond to the address and port from which the request 1161 was received, and from the address and port at which the request was 1162 received. IKE functions identically over IPv4 or IPv6. 1164 2.12 Reuse of Diffie-Hellman Exponentials 1166 IKE generates keying material using an ephemeral Diffie-Hellman 1167 exchange in order to gain the property of "perfect forward secrecy". 1168 This means that once a connection is closed and its corresponding 1169 keys are forgotten, even someone who has recorded all of the data 1170 from the connection and gets access to all of the long term keys of 1171 the two endpoints cannot reconstruct the keys used to protect the 1172 conversation. 1174 Achieving perfect forward secrecy requires that when a connection is 1175 closed, each endpoint MUST forget not only the keys used by the 1176 connection but any information that could be used to recompute those 1177 keys. In particular, it MUST forget the secrets used in the Diffie- 1178 Hellman calculation and any state that may persist in the state of a 1179 pseudo-random number generator that could be used to recompute the 1180 Diffie-Hellman secrets. 1182 Since the computing of Diffie-Hellman exponentials is computationally 1183 expensive, an endpoint may find it advantageous to reuse those 1184 exponentials for multiple connection setups. There are several 1185 reasonable strategies for doing this. An endpoint could choose a new 1186 exponential only periodically though this could result in less-than- 1187 perfect forward secrecy if some connection lasts for less than the 1188 lifetime of the exponential. Or it could keep track of which 1189 exponential was used for each connection and delete the information 1190 associated with the exponential only when some corresponding 1191 connection was closed. This would allow the exponential to be reused 1192 without losing perfect forward secrecy at the cost of maintaining 1193 more state. 1195 Decisions as to whether and when to reuse Diffie-Hellman exponentials 1196 is a private decision in the sense that it will not affect 1197 interoperability. An implementation that reuses exponentials MAY 1198 choose to remember the exponential used by the other endpoint on past 1199 exchanges and if one is reused to avoid the second half of the 1200 calculation. 1202 2.13 Generating Keying Material 1204 In the context of the IKE_SA, four cryptographic algorithms are 1205 negotiated: an encryption algorithm, an integrity protection 1206 algorithm, a Diffie-Hellman group, and a pseudo-random function 1207 (prf). The pseudo-random function is used for the construction of 1208 keying material for all of the cryptographic algorithms used in both 1209 the IKE_SA and the CHILD_SAs. 1211 We assume that each encryption algorithm and integrity protection 1212 algorithm uses a fixed size key, and that any randomly chosen value 1213 of that fixed size can serve as an appropriate key. For algorithms 1214 that accept a variable length key, a fixed key size MUST be specified 1215 as part of the cryptographic transform negotiated. For integrity 1216 protection functions based on HMAC, the fixed key size is the size of 1217 the output of the underlying hash function. When the prf function 1218 takes a variable length key, variable length data, and produces a 1219 fixed length output (e.g., when using HMAC), the formulas in this 1220 document apply. When the key for the prf function has fixed length, 1221 the data provided as a key is truncated or padded with zeros as 1222 necessary unless exceptional processing is explained following the 1223 formula. 1225 Keying material will always be derived as the output of the 1226 negotiated prf algorithm. Since the amount of keying material needed 1227 may be greater than the size of the output of the prf algorithm, we 1228 will use the prf iteratively. We will use the terminology prf+ to 1229 describe the function that outputs a pseudo-random stream based on 1230 the inputs to a prf as follows: (where | indicates concatenation) 1232 prf+ (K,S) = T1 | T2 | T3 | T4 | ... 1234 where: 1235 T1 = prf (K, S | 0x01) 1236 T2 = prf (K, T1 | S | 0x02) 1237 T3 = prf (K, T2 | S | 0x03) 1238 T4 = prf (K, T3 | S | 0x04) 1240 continuing as needed to compute all required keys. The keys are taken 1241 from the output string without regard to boundaries (e.g., if the 1242 required keys are a 256 bit AES key and a 160 bit HMAC key, and the 1243 prf function generates 160 bits, the AES key will come from T1 and 1244 the beginning of T2, while the HMAC key will come from the rest of T2 1245 and the beginning of T3). 1247 The constant concatenated to the end of each string feeding the prf 1248 is a single octet. prf+ in this document is not defined beyond 255 1249 times the size of the prf output. 1251 2.14 Generating Keying Material for the IKE_SA 1253 The shared keys are computed as follows. A quantity called SKEYSEED 1254 is calculated from the nonces exchanged during the IKE_SA_INIT 1255 exchange and the Diffie-Hellman shared secret established during that 1256 exchange. SKEYSEED is used to calculate five other secrets: SK_d 1257 used for deriving new keys for the CHILD_SAs established with this 1258 IKE_SA; SK_ai and SK_ar used as a key to the integrity protection 1259 algorithm for authenticating the component messages of subsequent 1260 exchanges; and SK_ei and SK_er used for encrypting (and of course 1261 decrypting) all subsequent exchanges. SKEYSEED and its derivatives 1262 are computed as follows: 1264 SKEYSEED = prf(Ni | Nr, g^ir) 1266 {SK_d | SK_ai | SK_ar | SK_ei | SK_er} 1267 = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) 1269 (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, and SK_er 1270 are taken in order from the generated bits of the prf+). g^ir is the 1271 shared secret from the ephemeral Diffie-Hellman exchange. g^ir is 1272 represented as a string of octets in big endian order padded with 1273 zeros if necessary to make it the length of the modulus. Ni and Nr 1274 are the nonces, stripped of any headers. If the negotiated prf takes 1275 a fixed length key and the lengths of Ni and Nr do not add up to that 1276 length, half the bits must come from Ni and half from Nr, taking the 1277 first bits of each. 1279 The two directions of flow use different keys. The keys used to 1280 protect messages from the original initiator are SK_ai and SK_ei. The 1281 keys used to protect messages in the other direction are SK_ar and 1282 SK_er. Each algorithm takes a fixed number of bits of keying 1283 material, which is specified as part of the algorithm. For integrity 1284 algorithms based on HMAC, the key size is always equal to the length 1285 of the output of the underlying hash function. 1287 2.15 Authentication of the IKE_SA 1289 When not using extended authentication (see section 2.16), the peers 1290 are authenticated by having each sign (or MAC using a shared secret 1291 as the key) a block of data. For the responder, the octets to be 1292 signed start with the first octet of the first SPI in the header of 1293 the second message and end with the last octet of the last payload in 1294 the second message. Appended to this (for purposes of computing the 1295 signature) are the initiator's nonce Ni (just the value, not the 1296 payload containing it), and the value prf(SK_ar,IDr') where IDr' is 1297 the responder's ID payload excluding the fixed header. Note that 1298 neither the nonce Ni nor the value prf(SK_ar,IDr') are transmitted. 1299 Similarly, the initiator signs the first message, starting with the 1300 first octet of the first SPI in the header and ending with the last 1301 octet of the last payload. Appended to this (for purposes of 1302 computing the signature) are the responder's nonce Nr, and the value 1303 prf(SK_ai,IDi'). In the above calculation, IDi' and IDr' are the 1304 entire ID payloads excluding the fixed header. It is critical to the 1305 security of the exchange that each side sign the other side's nonce 1306 (see [SIGMA]). 1308 Note that all of the payloads are included under the signature, 1309 including any payload types not defined in this document. If the 1310 first message of the exchange is sent twice (the second time with a 1311 responder cookie and/or a different Diffie-Hellman group), it is the 1312 second version of the message that is signed. 1314 Optionally, messages 3 and 4 MAY include a certificate, or 1315 certificate chain providing evidence that the key used to compute a 1316 digital signature belongs to the name in the ID payload. The 1317 signature or MAC will be computed using algorithms dictated by the 1318 type of key used by the signer, and specified by the Auth Method 1319 field in the Authentication payload. There is no requirement that 1320 the Initiator and Responder sign with the same cryptographic 1321 algorithms. The choice of cryptographic algorithms depends on the 1322 type of key each has. In particular, the initiator may be using a 1323 shared key while the responder may have a public signature key and 1324 certificate. It will commonly be the case (but it is not required) 1325 that if a shared secret is used for authentication that the same key 1326 is used in both directions. Note that it is a common but typically 1327 insecure practice to have a shared key derived solely from a user 1328 chosen password without incorporating another source of randomness. 1329 This is typically insecure because user chosen passwords are unlikely 1330 to have sufficient unpredictability to resist dictionary attacks and 1331 these attacks are not prevented in this authentication method. 1332 (Applications using password-based authentication for bootstrapping 1333 and IKE_SA should use the authentication method in section 2.16, 1334 which is designed to prevent off-line dictionary attacks). The pre- 1335 shared key SHOULD contain as much unpredictability as the strongest 1336 key being negotiated. In the case of a pre-shared key, the AUTH 1337 value is computed as: 1339 AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), ) 1342 where the string "Key Pad for IKEv2" is ASCII encoded and not null 1343 terminated. The shared secret can be variable length. The pad string 1344 is added so that if the shared secret is derived from a password, the 1345 IKE implementation need not store the password in cleartext, but 1346 rather can store the value prf(Shared Secret,"Key Pad for IKEv2"), 1347 which could not be used as a password equivalent for protocols other 1348 than IKEv2. As noted above, deriving the shared secret from a 1349 password is not secure. This construction is used because it is 1350 anticipated that people will do it anyway. The management interface 1351 by which the Shared Secret is provided MUST accept ASCII strings of 1352 at least 64 octets and MUST NOT add a null terminator before using 1353 them as shared secrets. The management interface MAY accept other 1354 forms, like hex encoding. If the negotiated prf takes a fixed size 1355 key, the shared secret MUST be of that fixed size. 1357 2.16 Extended Authentication Protocol Methods 1359 In addition to authentication using public key signatures and shared 1360 secrets, IKE supports authentication using methods defined in RFC 1361 2284 [EAP]. Typically, these methods are asymmetric (designed for a 1362 user authenticating to a server), and they may not be mutual. For 1363 this reason, these protocols are typically used to authenticate the 1364 initiator to the responder and are used in addition to a public key 1365 signature based authentication of the responder to the initiator. 1366 These methods are also referred to as "Legacy Authentication" 1367 mechanisms. 1369 While this memo references [EAP] with the intent that new methods can 1370 be added in the future without updating this specification, the 1371 protocols expected to be used most commonly are fully documented here 1372 and in section 3.16. [EAP] defines an authentication protocol 1373 requiring a variable number of messages. Extended Authentication is 1374 implemented in IKE as additional IKE_AUTH exchanges that MUST be 1375 completed in order to initialize the IKE_SA. 1377 An initiator indicates a desire to use extended authentication by 1378 leaving out the AUTH payload from message 3. By including an IDi 1379 payload but not an AUTH payload, the initiator has declared an 1380 identity but has not proven it. If the responder is willing to use an 1381 extended authentication method, it will place an EAP payload in 1382 message 4 and defer sending SAr2, TSi, and TSr until initiator 1383 authentication is complete in a subsequent IKE_AUTH exchange. In the 1384 case of a minimal extended authentication, the initial SA 1385 establishment will appear as follows: 1387 Initiator Responder 1389 ----------- ----------- 1390 HDR, SAi1, KEi, Ni --> 1392 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 1394 HDR, SK {IDi, [CERTREQ,] [IDr,] 1395 SAi2, TSi, TSr} --> 1397 <-- HDR, SK {IDr, [CERT,] AUTH, 1398 EAP } 1400 HDR, SK {EAP, [AUTH] } --> 1402 <-- HDR, SK {EAP, [AUTH], 1403 SAr2, TSi, TSr } 1405 For EAP methods that create a shared key as a side effect of 1406 authentication, that shared key MUST be used by both the Initiator 1407 and Responder to generate an AUTH payload using the syntax for shared 1408 secrets specified in section 2.15. The shared key generated during an 1409 IKE exchange MUST NOT be used for any other purpose. 1411 EAP methods that do not establish a shared key SHOULD NOT be used, as 1412 they are subject to a number of man-in-the-middle attacks if these 1413 EAP methods are used in other protocols that do not use a server- 1414 authenticated tunnel. Please see the Security Considerations section 1415 for more details. If EAP methods that do not generate a shared key 1416 are used, there will be no AUTH payloads in the final messages. 1418 The Initiator of an IKE_SA using EAP SHOULD be capable of extending 1419 the initial protocol exchange to at least ten IKE_AUTH exchanges in 1420 the event the Responder sends notification messages and/or retries 1421 the authentication prompt. The protocol terminates when the Responder 1422 sends the Initiator an EAP payload containing either a success or 1423 failure type. 1425 2.17 Generating Keying Material for CHILD_SAs 1427 CHILD_SAs are created either by being piggybacked on the IKE_AUTH 1428 exchange, or in a CREATE_CHILD_SA exchange. Keying material for them 1429 is generated as follows: 1431 KEYMAT = prf+(SK_d, Ni | Nr) 1433 Where Ni and Nr are the Nonces from the IKE_SA_INIT exchange if this 1434 request is the first CHILD_SA created or the fresh Ni and Nr from the 1435 CREATE_CHILD_SA exchange if this is a subsequent creation. 1437 For CREATE_CHILD_SA exchanges with PFS the keying material is defined 1438 as: 1440 KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr ) 1442 where g^ir (new) is the shared secret from the ephemeral Diffie- 1443 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 1444 octet string in big endian order padded with zeros if necessary to 1445 make it the length of the modulus), 1447 A single CHILD_SA negotiation may result in multiple security 1448 associations. ESP and AH SAs exist in pairs (one in each direction), 1449 and four SAs could be created in a single CHILD_SA negotiation if a 1450 combination of ESP and AH is being negotiated. 1452 Keying material is taken from the expanded KEYMAT in the following 1453 order: 1455 All keys for SAs carrying data from the initiator to the responder 1456 are taken before SAs going in the reverse direction. 1458 If multiple protocols are negotiated, keying material is taken in 1459 the order in which the protocol headers will appear in the 1460 encapsulated packet. 1462 If a single protocol has both encryption and authentication keys, 1463 the encryption key is taken from the first octets of KEYMAT and 1464 the authentication key is taken from the next octets. 1466 Each cryptographic algorithm takes a fixed number of bits of keying 1467 material specified as part of the algorithm. 1469 2.18 Rekeying IKE_SAs using a CREATE_CHILD_SA exchange 1471 The CREATE_CHILD_SA exchange can be used to re-key an existing IKE_SA 1472 (see section 2.8). New Initiator and Responder SPIs are supplied in 1473 the SPI fields. The TS payloads are omitted when rekeying an IKE_SA. 1474 SKEYSEED for the new IKE_SA is computed using SK_d from the existing 1475 IKE_SA as follows: 1477 SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr) 1479 where g^ir (new) is the shared secret from the ephemeral Diffie- 1480 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 1481 octet string in big endian order padded with zeros if necessary to 1482 make it the length of the modulus) and Ni and Nr are the two nonces 1483 stripped of any headers. 1485 The new IKE_SA MUST reset its message counters to 0. 1487 SK_d, SK_ai, SK_ar, and SK_ei, and SK_er are computed from SKEYSEED 1488 as specified in section 2.14. 1490 2.19 Requesting an internal address on a remote network 1492 Most commonly occurring in the endpoint to security gateway scenario, 1493 an endpoint may need an IP address in the network protected by the 1494 security gateway, and may need to have that address dynamically 1495 assigned. A request for such a temporary address can be included in 1496 any request to create a CHILD_SA (including the implicit request in 1497 message 3) by including a CP payload. 1499 This function provides address allocation to an IRAC (IPsec Remote 1500 Access Client) trying to tunnel into a network protected by an IRAS 1501 (IPsec Remote Access Server). Since the IKE_AUTH exchange creates an 1502 IKE_SA and a CHILD_SA, the IRAC MUST request the IRAS controlled 1503 address (and optionally other information concerning the protected 1504 network) in the IKE_AUTH exchange. The IRAS may procure an address 1505 for the IRAC from any number of sources such as a DHCP/BOOTP server 1506 or its own address pool. 1508 Initiator Responder 1509 ----------------------------- --------------------------- 1510 HDR, SK {IDi, [CERT,] [CERTREQ,] 1511 [IDr,] AUTH, CP(CFG_REQUEST), 1512 SAi2, TSi, TSr} --> 1514 <-- HDR, SK {IDr, [CERT,] AUTH, 1515 CP(CFG_REPLY), SAr2, 1516 TSi, TSr} 1518 In all cases, the CP payload MUST be inserted before the SA payload. 1519 In variations of the protocol where there are multiple IKE_AUTH 1520 exchanges, the CP payloads MUST be inserted in the messages 1521 containing the SA payloads. 1523 CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute 1524 (either IPv4 or IPv6) but MAY contain any number of additional 1525 attributes the initiator wants returned in the response. 1527 For example, message from Initiator to Responder: 1528 CP(CFG_REQUEST)= 1529 INTERNAL_ADDRESS(0.0.0.0) 1530 INTERNAL_NETMASK(0.0.0.0) 1531 INTERNAL_DNS(0.0.0.0) 1532 TSi = (0, 0-65536,0.0.0.0-255.255.255.255) 1533 TSr = (0, 0-65536,0.0.0.0-255.255.255.255) 1535 NOTE: Traffic Selectors are a (protocol, port range, address range) 1537 Message from Responder to Initiator: 1539 CP(CFG_REPLY)= 1540 INTERNAL_ADDRESS(192.168.219.202) 1541 INTERNAL_NETMASK(255.255.255.0) 1542 INTERNAL_SUBNET(192.168.219.0/255.255.255.0) 1543 TSi = (0, 0-65536,192.168.219.202-192.168.219.202) 1544 TSr = (0, 0-65536,192.168.219.0-192.168.219.255) 1546 All returned values will be implementation dependent. As can be seen 1547 in the above example, the IRAS MAY also send other attributes that 1548 were not included in CP(CFG_REQUEST) and MAY ignore the non- 1549 mandatory attributes that it does not support. 1551 The responder MUST not send a CFG_REPLY without having first received 1552 a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS 1553 to perform an unnecessary configuration lookup if the IRAC cannot 1554 process the REPLY. In the case where the IRAS's configuration 1555 requires that CP be used for a given identity IDi, but IRAC has 1556 failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and 1557 terminate the IKE exchange with a FAILED_CP_REQUIRED error. 1559 2.20 Requesting the Peer's Version 1561 An IKE peer wishing to inquire about the other peer's IKE software 1562 version information MAY use the method below. This is an example of 1563 a configuration request within an INFORMATIONAL Exchange, after the 1564 IKE_SA and first CHILD_SA have been created. 1566 An IKE implementation MAY decline to give out version information 1567 prior to authentication or even after authentication to prevent 1568 trolling in case some implementation is known to have some security 1569 weakness. In that case, it MUST either return an empty string or no 1570 CP payload if CP is not supported. 1572 Initiator Responder 1573 ----------------------------- -------------------------- 1574 HDR, SK{CP(CFG_REQUEST)} --> 1575 <-- HDR, SK{CP(CFG_REPLY)} 1577 CP(CFG_REQUEST)= 1578 APPLICATION_VERSION("") 1580 CP(CFG_REPLY) 1581 APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar Inc.") 1583 2.21 Error Handling 1585 There are many kinds of errors that can occur during IKE processing. 1586 If a request is received that is badly formatted or unacceptable for 1587 reasons of policy (e.g., no matching cryptographic algorithms), the 1588 response MUST contain a Notify payload indicating the error. If an 1589 error occurs outside the context of an IKE request (e.g., the node is 1590 getting ESP messages on a nonexistent SPI), the node SHOULD initiate 1591 an INFORMATIONAL Exchange with a Notify payload describing the 1592 problem. 1594 Errors that occur before a cryptographically protected IKE_SA is 1595 established must be handled very carefully. There is a trade-off 1596 between wanting to be helpful in diagnosing a problem and responding 1597 to it and wanting to avoid being a dupe in a denial of service attack 1598 based on forged messages. 1600 If a node receives a message on UDP port 500 outside the context of 1601 an IKE_SA known to it (and not a request to start one), it may be the 1602 result of a recent crash of the node. If the message is marked as a 1603 response, the node MAY audit the suspicious event but MUST NOT 1604 respond. If the message is marked as a request, the node MAY audit 1605 the suspicious event and MAY send a response. If a response is sent, 1606 the response MUST be sent to the IP address and port from whence it 1607 came with the same IKE SPIs and the Message ID copied. The response 1608 MUST NOT be cryptographically protected and MUST contain a Notify 1609 payload indicating INVALID_IKE_SPI. 1611 A node receiving such an unprotected Notify payload MUST NOT respond 1612 and MUST NOT change the state of any existing SAs. The message might 1613 be a forgery or might be a response the genuine correspondent was 1614 tricked into sending. A node SHOULD treat such a message (and also a 1615 network message like ICMP destination unreachable) as a hint that 1616 there might be problems with SAs to that IP address and SHOULD 1617 initiate a liveness test for any such IKE_SA. An implementation 1618 SHOULD limit the frequency of such tests to avoid being tricked into 1619 participating in a denial of service attack. 1621 A node receiving a suspicious message from an IP address with which 1622 it has an IKE_SA MAY send an IKE Notify payload in an IKE 1623 INFORMATIONAL exchange over that SA. The recipient MUST NOT change 1624 the state of any SA's as a result but SHOULD audit the event to aid 1625 in diagnosing malfunctions. A node MUST limit the rate at which it 1626 will send messages in response to unprotected messages. 1628 2.22 IPComp 1630 Use of IP compression [IPCOMP] can be negotiated as part of the setup 1631 of a CHILD_SA. While IP compression involves an extra header in each 1632 packet and a CPI (compression parameter index), the virtual 1633 "compression association" has no life outside the ESP or AH SA that 1634 contains it. Compression associations disappear when the 1635 corresponding ESP or AH SA goes away, and is not explicitly mentioned 1636 in any DELETE payload. 1638 Negotiation of IP compression is separate from the negotiation of 1639 cryptographic parameters associated with a CHILD_SA. A node 1640 requesting a CHILD_SA MAY advertise its support for one or more 1641 compression algorithms though one or more Notify payloads of type 1642 IPCOMP_SUPPORTED. The response MAY indicate acceptance of a single 1643 compression algorithm with a Notify payload of type IPCOMP_SUPPORTED. 1644 These payloads MAY ONLY occur in the same messages that contain SA 1645 payloads. 1647 While there has been discussion of allowing multiple compression 1648 algorithms to be accepted and to have different compression 1649 algorithms available for the two directions of a CHILD_SA, 1650 implementations of this specification MUST NOT accept an IPComp 1651 algorithm that was not proposed, MUST NOT accept more than one, and 1652 MUST NOT compress using an algorithm other than one proposed and 1653 accepted in the setup of the CHILD_SA. 1655 A side effect of separating the negotiation of IPComp from 1656 cryptographic parameters is that it is not possible to propose 1657 multiple cryptographic suites and propose IP compression with some of 1658 them but not others. 1660 2.23 NAT Traversal 1662 NAT (Network Address Translation) gateways are a controversial 1663 subject. This section briefly describes what they are and how they 1664 are likely to act on IKE traffic. Many people believe that NATs are 1665 evil and that we should not design our protocols so as to make them 1666 work better. IKEv2 does specify some unintuitive processing rules in 1667 order that NATs are more likely to work. 1669 NATs exist primarily because of the shortage of IPv4 addresses, 1670 though there are other rationales. IP nodes that are "behind" a NAT 1671 have IP addresses that are not globally unique, but rather are 1672 assigned from some space that is unique within the network behind the 1673 NAT but which are likely to be reused by nodes behind other NATs. 1674 Generally, nodes behind NATs can communicate with other nodes behind 1675 the same NAT and with nodes with globally unique addresses, but not 1676 with nodes behind other NATs. There are exceptions to that rule. 1677 When those nodes make connections to nodes on the real Internet, the 1678 NAT gateway "translates" the IP source address to an address that 1679 will be routed back to the gateway. Messages to the gateway from the 1680 Internet have their destination addresses "translated" to the 1681 internal address that will route the packet to the correct endnode. 1683 NATs are designed to be "transparent" to endnodes. Neither software 1684 on the node behind the NAT nor the node on the Internet require 1685 modification to communicate through the NAT. Achieving this 1686 transparency is more difficult with some protocols than with others. 1687 Protocols that include IP addresses of the endpoints within the 1688 payloads of the packet will fail unless the NAT gateway understands 1689 the protocol and modifies the internal references as well as those in 1690 the headers. Such knowledge is inherently unreliable, is a network 1691 layer violation, and often results in subtle problems. 1693 Opening an IPsec connection through a NAT introduces special 1694 problems. If the connection runs in transport mode, changing the IP 1695 addresses on packets will cause the checksums to fail and the NAT 1696 cannot correct the checksums because they are cryptographically 1697 protected. Even in tunnel mode, there are routing problems because 1698 transparently translating the addresses of AH and ESP packets 1699 requires special logic in the NAT and that logic is heuristic and 1700 unreliable in nature. For that reason, IKEv2 can negotiate UDP 1701 encapsulation of IKE, ESP, and AH packets. This encoding is slightly 1702 less efficient but is easier for NATs to process. In addition, 1703 firewalls may be configured to pass IPsec traffic over UDP but not 1704 ESP/AH or vice versa. 1706 It is a common practice of NATs to translate TCP and UDP port numbers 1707 as well as addresses and use the port numbers of inbound packets to 1708 decide which internal node should get a given packet. For this 1709 reason, even though IKE packets MUST be sent from and to UDP port 1710 500, they MUST be accepted coming from any port and responses MUST be 1711 sent to the port from whence they came. This is because the ports may 1712 be modified as the packets pass through NATs. Similarly, IP addresses 1713 of the IKE endpoints are generally not included in the IKE payloads 1714 because the payloads are cryptographically protected and could not be 1715 transparently modified by NATs. 1717 Port 4500 is reserved for UDP encapsulated ESP, AH, and IKE. When 1718 working through a NAT, it is generally better to pass IKE packets 1719 over port 4500 because some older NATs modify IKE traffic on port 500 1720 in an attempt to transparently establish IPsec connections. Such NATs 1721 may interfere with the straightforward NAT traversal envisioned by 1722 this document, so an IPsec endpoint that discovers a NAT between it 1723 and its correspondent MUST send all subsequent traffic to and from 1724 port 4500, which NATs should not treat specially (as they might with 1725 port 500). 1727 The specific requirements for supporting NAT traversal are listed 1728 below. Support for NAT traversal is optional. In this section only, 1729 requirements listed as MUST only apply to implementations supporting 1730 NAT traversal. 1732 IKE MUST listen on port 4500 as well as port 500. IKE MUST respond 1733 to the IP address and port from which packets arrived. 1735 The IKE responder MUST include in its IKE_SA_INIT response Notify 1736 payloads of type NAT_DETECTION_SOURCE_IP and 1737 NAT_DETECTION_DESTINATION_IP. The IKE initiator MUST check these 1738 payloads if present and if they do not match the addresses in the 1739 outer packet MUST tunnel all future IKE, ESP, and AH packets 1740 associated with this IKE_SA over UDP port 4500. To tunnel IKE 1741 packets over UDP port 4500, the IKE header has four octets of zero 1742 prepended and the result immediately follows the UDP header. To 1743 tunnel ESP packets over UDP port 4500, the ESP header immediately 1744 follows the UDP header. Since the first four bytes of the ESP 1745 header contain the SPI, and the SPI cannot validly be zero, it is 1746 always possible to distinguish ESP and IKE messages. 1748 The original source and destination IP address required for the 1749 transport mode TCP and UDP packet checksum fixup (see [Hutt02]) 1750 obtained from the Traffic Selectors associated with the exchange. 1751 In the case of NAT-T, the Traffic Selectors MUST contain exactly 1752 one IP address which is then used as the original IP address. 1754 There are cases where a NAT box decides to remove mappings that 1755 are still alive (for example, the keepalive interval is too long, 1756 or the NAT box is rebooted). To recover in these cases, hosts that 1757 are not behind a NAT SHOULD send all packets (including retried 1758 packets) to the IP address and port from the last valid 1759 authenticated packet from the other end. A host behind a NAT 1760 SHOULD NOT do this because it opens a DoS attack possibility. Any 1761 authenticated IKE packet or any authenticated UDP encapsulated ESP 1762 packet can be used to detect that the IP address or the port has 1763 changed. 1765 Note that similar but probably not identical actions will likely 1766 be needed to make IKE work with Mobile IP, but such processing is 1767 not addressed by this document. 1769 2.24 ECN (Explicit Congestion Notification) 1771 When IPsec tunnels behave as originally specified in [RFC 2401], ECN 1772 usage is not appropriate for the outer IP headers because tunnel 1773 decapsulation processing discards ECN congestion indications to the 1774 detriment of the network. ECN support for IPsec tunnels for 1775 IKEv1-based IPsec requires multiple operating modes and negotiation 1776 (see RFC 3168]). IKEv2 simplifies this situation by requiring that 1777 ECN be usable in the outer IP headers of all tunnel-mode IPsec SAs 1778 created by IKEv2. Specifically, tunnel encapsulators and 1779 decapsulators for all tunnel-mode Security Associations (SAs) created 1780 by IKEv2 MUST support the ECN full-functionality option for tunnels 1781 specified in [RFC3168] and MUST implement the tunnel encapsulation 1782 and decapsulation processing specified in [RFC2401bis] to prevent 1783 discarding of ECN congestion indications. 1785 3 Header and Payload Formats 1787 3.1 The IKE Header 1789 IKE messages use UDP ports 500 and/or 4500, with one IKE message per 1790 UDP datagram. Information from the UDP header is largely ignored 1791 except that the IP addresses and UDP ports from the headers are 1792 reversed and used for return packets. When sent on UDP port 500, IKE 1793 messages begin immediately following the UDP header. When sent on UDP 1794 port 4500, IKE messages have prepended four octets of zero. These 1795 four octets of zero are not part of the IKE message and are not 1796 included in any of the length fields or checksums defined by IKE. 1797 Each IKE message begins with the IKE header, denoted HDR in this 1798 memo. Following the header are one or more IKE payloads each 1799 identified by a "Next Payload" field in the preceding payload. 1800 Payloads are processed in the order in which they appear in an IKE 1801 message by invoking the appropriate processing routine according to 1802 the "Next Payload" field in the IKE header and subsequently according 1803 to the "Next Payload" field in the IKE payload itself until a "Next 1804 Payload" field of zero indicates that no payloads follow. If a 1805 payload of type "Encrypted" is found, that payload is decrypted and 1806 its contents parsed as additional payloads. An Encrypted payload MUST 1807 be the last payload in a packet and an encrypted payload MUST NOT 1808 contain another encrypted payload. 1810 The Recipient SPI in the header identifies an instance of an IKE 1811 security association. It is therefore possible for a single instance 1812 of IKE to multiplex distinct sessions with multiple peers. 1814 All multi-octet fields representing integers are laid out in big 1815 endian order (aka most significant byte first, or network byte 1816 order). 1818 The format of the IKE header is shown in Figure 4. 1819 1 2 3 1820 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 1821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1822 ! IKE_SA Initiator's SPI ! 1823 ! ! 1824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1825 ! IKE_SA Responder's SPI ! 1826 ! ! 1827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1828 ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! 1829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1830 ! Message ID ! 1831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1832 ! Length ! 1833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1835 Figure 4: IKE Header Format 1837 o Initiator's SPI (8 octets) - A value chosen by the 1838 initiator to identify a unique IKE security association. This 1839 value MUST NOT be zero. 1841 o Responder's SPI (8 octets) - A value chosen by the 1842 responder to identify a unique IKE security association. This 1843 value MUST be zero in the first message of an IKE Initial 1844 Exchange (including repeats of that message including a 1845 cookie) and MUST NOT be zero in any other message. 1847 o Next Payload (1 octet) - Indicates the type of payload that 1848 immediately follows the header. The format and value of each 1849 payload is defined below. 1851 o Major Version (4 bits) - indicates the major version of the IKE 1852 protocol in use. Implementations based on this version of IKE 1853 MUST set the Major Version to 2. Implementations based on 1854 previous versions of IKE and ISAKMP MUST set the Major Version 1855 to 1. Implementations based on this version of IKE MUST reject 1856 or ignore messages containing a version number greater than 1857 2. 1859 o Minor Version (4 bits) - indicates the minor version of the 1860 IKE protocol in use. Implementations based on this version of 1861 IKE MUST set the Minor Version to 0. They MUST ignore the minor 1862 version number of received messages. 1864 o Exchange Type (1 octet) - indicates the type of exchange being 1865 used. This constrains the payloads sent in each message and 1866 orderings of messages in an exchange. 1868 Exchange Type Value 1870 RESERVED 0-33 1871 IKE_SA_INIT 34 1872 IKE_AUTH 35 1873 CREATE_CHILD_SA 36 1874 INFORMATIONAL 37 1875 Reserved for IKEv2+ 38-239 1876 Reserved for private use 240-255 1878 o Flags (1 octet) - indicates specific options that are set 1879 for the message. Presence of options are indicated by the 1880 appropriate bit in the flags field being set. The bits are 1881 defined LSB first, so bit 0 would be the least significant 1882 bit of the Flags octet. In the description below, a bit 1883 being 'set' means its value is '1', while 'cleared' means 1884 its value is '0'. 1886 -- X(reserved) (bits 0-2) - These bits MUST be cleared 1887 when sending and MUST be ignored on receipt. 1889 -- I(nitiator) (bit 3 of Flags) - This bit MUST be set in 1890 messages sent by the original Initiator of the IKE_SA 1891 and MUST be cleared in messages sent by the original 1892 Responder. It is used by the recipient to determine 1893 which eight octets of the SPI was generated by the 1894 recipient. 1896 -- V(ersion) (bit 4 of Flags) - This bit indicates that 1897 the transmitter is capable of speaking a higher major 1898 version number of the protocol than the one indicated 1899 in the major version number field. Implementations of 1900 IKEv2 must clear this bit when sending and MUST ignore 1901 it in incoming messages. 1903 -- R(esponse) (bit 5 of Flags) - This bit indicates that 1904 this message is a response to a message containing 1905 the same message ID. This bit MUST be cleared in all 1906 request messages and MUST be set in all responses. 1907 An IKE endpoint MUST NOT generate a response to a 1908 message that is marked as being a response. 1910 -- X(reserved) (bits 6-7 of Flags) - These bits MUST be 1911 cleared when sending and MUST be ignored on receipt. 1913 o Message ID (4 octets) - Message identifier used to control 1914 retransmission of lost packets and matching of requests and 1915 responses. It is essential to the security of the protocol 1916 because it is used to prevent message replay attacks. 1917 See sections 2.1 and 2.2. 1919 o Length (4 octets) - Length of total message (header + payloads) 1920 in octets. 1922 3.2 Generic Payload Header 1924 Each IKE payload defined in sections 3.3 through 3.16 begins with a 1925 generic payload header, shown in Figure 5. Figures for each payload 1926 below will include the generic payload header but for brevity the 1927 description of each field will be omitted. 1929 1 2 3 1930 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 1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1932 ! Next Payload !C! RESERVED ! Payload Length ! 1933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1935 Figure 5: Generic Payload Header 1937 The Generic Payload Header fields are defined as follows: 1939 o Next Payload (1 octet) - Identifier for the payload type of the 1940 next payload in the message. If the current payload is the last 1941 in the message, then this field will be 0. This field provides 1942 a "chaining" capability whereby additional payloads can be 1943 added to a message by appending it to the end of the message 1944 and setting the "Next Payload" field of the preceding payload 1945 to indicate the new payload's type. An Encrypted payload, 1946 which must always be the last payload of a message, is an 1947 exception. It contains data structures in the format of 1948 additional payloads. In the header of an Encrypted payload, 1949 the Next Payload field is set to the payload type of the first 1950 contained payload (instead of 0). 1952 Payload Type Values 1954 Next Payload Type Notation Value 1956 No Next Payload 0 1958 RESERVED 1-32 1959 Security Association SA 33 1960 Key Exchange KE 34 1961 Identification - Initiator IDi 35 1962 Identification - Responder IDr 36 1963 Certificate CERT 37 1964 Certificate Request CERTREQ 38 1965 Authentication AUTH 39 1966 Nonce Ni, Nr 40 1967 Notify N 41 1968 Delete D 42 1969 Vendor ID V 43 1970 Traffic Selector - Initiator TSi 44 1971 Traffic Selector - Responder TSr 45 1972 Encrypted E 46 1973 Configuration CP 47 1974 Extended Authentication EAP 48 1975 RESERVED TO IANA 49-127 1976 PRIVATE USE 128-255 1978 Payload type values 1-32 should not be used so that there is no 1979 overlap with the code assignments for IKEv1. Payload type values 1980 49-127 are reserved to IANA for future assignment in IKEv2 (see 1981 section 6). Payload type values 128-255 are for private use among 1982 mutually consenting parties. 1984 o Critical (1 bit) - MUST be set to zero if the sender wants 1985 the recipient to skip this payload if he does not 1986 understand the payload type code in the Next Payload field 1987 of the previous payload. MUST be set to one if the 1988 sender wants the recipient to reject this entire message 1989 if he does not understand the payload type. MUST be ignored 1990 by the recipient if the recipient understands the payload type 1991 code. MUST be set to zero for payload types defined in this 1992 document. Note that the critical bit applies to the current 1993 payload rather than the "next" payload whose type code 1994 appears in the first octet. The reasoning behind not setting 1995 the critical bit for payloads defined in this document is 1996 that all implementations MUST understand all payload types 1997 defined in this document and therefore must ignore the 1998 Critical bit's value. Skipped payloads are expected to 1999 have valid Next Payload and Payload Length fields. 2001 o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on 2002 receipt. 2004 o Payload Length (2 octets) - Length in octets of the current 2005 payload, including the generic payload header. 2007 3.3 Security Association Payload 2009 The Security Association Payload, denoted SA in this memo, is used to 2010 negotiate attributes of a security association. Assembly of Security 2011 Association Payloads requires great peace of mind. An SA may contain 2012 multiple proposals, ordered from most preferred to least preferred. 2013 Each proposal may contain multiple protocols (where a protocol is 2014 IKE, ESP, or AH), each protocol may contain multiple transforms, and 2015 each transform may contain multiple attributes. When parsing an SA, 2016 an implementation MUST check that the total Payload Length is 2017 consistent with the payload's internal lengths and counts. 2018 Proposals, Transforms, and Attributes each have their own variable 2019 length encodings. They are nested such that the Payload Length of an 2020 SA includes the combined contents of the SA, Proposal, Transform, and 2021 Attribute information. The length of a Proposal includes the lengths 2022 of all Transforms and Attributes it contains. The length of a 2023 Transform includes the lengths of all Attributes it contains. 2025 The syntax of Security Associations, Proposals, Transforms, and 2026 Attributes is based on ISAKMP, however the semantics are somewhat 2027 different. The reason for the complexity and the hierarchy is to 2028 allow for multiple possible combinations of algorithms to be encoded 2029 in a single SA. Sometimes there is a choice of multiple algorithms, 2030 while other times there is a combination of algorithms. For example, 2031 an Initiator might want to propose using (AH w/MD5 and ESP w/3DES) OR 2032 (ESP w/MD5 and 3DES). 2034 One of the reasons the semantics of the SA payload has changed from 2035 ISAKMP and IKEv1 is to make the encodings more compact in common 2036 cases. 2038 The Proposal structure contains within it a Proposal # and a 2039 SECURITY_PROTOCOL_ID. Each structure MUST have the same Proposal # 2040 as the previous one or be one (1) greater. The first Proposal MUST 2041 have a Proposal # of one (1). If two successive structures have the 2042 same Proposal number, it means that the proposal consists of the 2043 first structure AND the second. So a proposal of AH AND ESP would 2044 have two proposal structures, one for AH and one for ESP and both 2045 would have Proposal #1. A proposal of AH OR ESP would have two 2046 proposal structures, one for AH with proposal #1 and one for ESP with 2047 proposal #2. 2049 Each Proposal/Protocol structure is followed by one or more transform 2050 structures. The number of different transforms is generally 2051 determined by the Protocol. AH generally has a single transform: an 2052 integrity check algorithm. ESP generally has two: an encryption 2053 algorithm AND an integrity check algorithm. IKE generally has four 2054 transforms: a Diffie-Hellman group, an integrity check algorithm, a 2055 prf algorithm, and an encryption algorithm. For each Protocol, the 2056 set of permissible transforms are assigned transform ID numbers, 2057 which appear in the header of each transform. 2059 If there are multiple transforms with the same Transform Type, the 2060 proposal is an OR of those transforms. If there are multiple 2061 Transforms with different Transform Types, the proposal is an AND of 2062 the different groups. For example, to propose ESP with (3DES or IDEA) 2063 and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two 2064 Transform Type 1 candidates (one for 3DES and one for IDEA) and two 2065 Transform Type 2 candidates (one for HMAC_MD5 and one for HMAC_SHA). 2066 This effectively proposes four combinations of algorithms. If the 2067 Initiator wanted to propose only a subset of those - say (3DES and 2068 HMAC_MD5) or (IDEA and HMAC_SHA), there is no way to encode that as 2069 multiple transforms within a single Proposal. Instead, the Initiator 2070 would have to construct two different Proposals, each with two 2071 transforms. 2073 A given transform MAY have one or more Attributes. Attributes are 2074 necessary when the transform can be used in more than one way, as 2075 when an encryption algorithm has a variable key size. The transform 2076 would specify the algorithm and the attribute would specify the key 2077 size. Most transforms do not have attributes. 2079 Note that the semantics of Transforms and Attributes are quite 2080 different than in IKEv1. In IKEv1, a single Transform carried 2081 multiple algorithms for a protocol with one carried in the Transform 2082 and the others carried in the Attributes. 2084 1 2 3 2085 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 2086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2087 ! Next Payload !C! RESERVED ! Payload Length ! 2088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2089 ! ! 2090 ~ ~ 2091 ! ! 2092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2094 Figure 6: Security Association Payload 2096 o Proposals (variable) - one or more proposal substructures. 2098 The payload type for the Security Association Payload is thirty 2099 three (33). 2101 3.3.1 Proposal Substructure 2103 1 2 3 2104 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2106 ! 0 (last) or 2 ! RESERVED ! Proposal Length ! 2107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2108 ! Proposal # ! Protocol-Id ! SPI Size !# of Transforms! 2109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2110 ~ SPI (variable) ~ 2111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2112 ! ! 2113 ~ ~ 2114 ! ! 2115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2117 Figure 7: Proposal Substructure 2119 o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the 2120 last Proposal Substructure in the SA. This syntax is inherited 2121 from ISAKMP, but is unnecessary because the last Proposal 2122 could be identified from the length of the SA. The value (2) 2123 corresponds to a Payload Type of Proposal in IKEv1, and the 2124 first four octets of the Proposal structure are designed to 2125 look somewhat like the header of a Payload. 2127 o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on 2128 receipt. 2130 o Proposal Length (2 octets) - Length of this proposal, 2131 including all transforms and attributes that follow. 2133 o Proposal # (1 octet) - When a proposal is made, the first 2134 proposal in an SA MUST be #1, and subsequent proposals 2135 MUST either be the same as the previous proposal (indicating 2136 an AND of the two proposals) or one more than the previous 2137 proposal (indicating an OR of the two proposals). When a 2138 proposal is accepted, all of the proposal numbers in the 2139 SA MUST be the same and MUST match the number on the 2140 proposal sent that was accepted. 2142 o Protocol-Id (1 octet) - Specifies the protocol identifier 2143 for the current negotiation. Zero (0) indicates IKE, 2144 one (1) indicated ESP, and two (2) indicates AH. 2146 o SPI Size (1 octet) - For an initial IKE_SA negotiation, 2147 this field MUST be zero; the SPI is obtained from the 2148 outer header. During subsequent negotiations, 2149 it is equal to the size, in octets, of the SPI of the 2150 corresponding protocol (8 for IKE, 4 for ESP and AH). 2152 o # of Transforms (1 octet) - Specifies the number of 2153 transforms in this proposal. 2155 o SPI (variable) - The sending entity's SPI. Even if the SPI 2156 Size is not a multiple of 4 octets, there is no padding 2157 applied to the payload. When the SPI Size field is zero, 2158 this field is not present in the Security Association 2159 payload. 2161 o Transforms (variable) - one or more transform substructures. 2163 3.3.2 Transform Substructure 2165 1 2 3 2166 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 2167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2168 ! 0 (last) or 3 ! RESERVED ! Transform Length ! 2169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2170 !Transform Type ! RESERVED ! Transform ID ! 2171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2172 ! ! 2173 ~ Transform Attributes ~ 2174 ! ! 2175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2177 Figure 8: Transform Substructure 2179 o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the 2180 last Transform Substructure in the Proposal. This syntax is 2181 inherited from ISAKMP, but is unnecessary because the last 2182 Proposal could be identified from the length of the SA. The 2183 value (3) corresponds to a Payload Type of Transform in IKEv1, 2184 and the first four octets of the Transform structure are 2185 designed to look somewhat like the header of a Payload. 2187 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 2189 o Transform Length - The length (in octets) of the Transform 2190 Substructure including Header and Attributes. 2192 o Transform Type (1 octet) - The type of transform being specified 2193 in this transform. Different protocols support different 2194 transform types. For some protocols, some of the transforms 2195 may be optional. If a transform is optional and the initiator 2196 wishes to propose that the transform be omitted, no transform 2197 of the given type is included in the proposal. If the 2198 initiator wishes to make use of the transform optional to 2199 the responder, she includes a transform substructure with 2200 transform ID = 0 as one of the options. 2202 o Transform ID (1 octet) - The specific instance of the transform 2203 type being proposed. 2205 Transform Type Values 2207 Transform Used In 2208 Type 2209 Encryption Algorithm 1 (IKE and ESP) 2210 Pseudo-random Function 2 (IKE) 2211 Integrity Algorithm 3 (IKE, AH, and optional in ESP) 2212 Diffie-Hellman Group 4 (IKE and optional in AH and ESP) 2213 Extended Sequence Numbers 5 (Optional in AH and ESP) 2215 values 6-240 are reserved to IANA. Values 241-255 are for 2216 private use among mutually consenting parties. 2218 For Transform Type 1 (Encryption Algorithm), defined Transform IDs 2219 are: 2221 Name Number Defined In 2222 RESERVED 0 2223 ENCR_DES_IV64 1 (RFC1827) 2224 ENCR_DES 2 (RFC2405) 2225 ENCR_3DES 3 (RFC2451) 2226 ENCR_RC5 4 (RFC2451) 2227 ENCR_IDEA 5 (RFC2451) 2228 ENCR_CAST 6 (RFC2451) 2229 ENCR_BLOWFISH 7 (RFC2451) 2230 ENCR_3IDEA 8 (RFC2451) 2231 ENCR_DES_IV32 9 2232 ENCR_RC4 10 2233 ENCR_NULL 11 (RFC2410) 2234 ENCR_AES_CBC 12 2235 ENCR_AES_CTR 13 2237 values 14-1023 are reserved to IANA. Values 1024-65535 are for 2238 private use among mutually consenting parties. 2240 For Transform Type 2 (Pseudo-random Function), defined Transform IDs 2241 are: 2243 Name Number Defined In 2244 RESERVED 0 2245 PRF_HMAC_MD5 1 (RFC2104) 2246 PRF_HMAC_SHA1 2 (RFC2104) 2247 PRF_HMAC_TIGER 3 (RFC2104) 2248 PRF_AES_CBC 4 2250 values 5-1023 are reserved to IANA. Values 1024-65535 are for 2251 private use among mutually consenting parties. 2253 For Transform Type 3 (Integrity Algorithm), defined Transform IDs 2254 are: 2256 Name Number Defined In 2257 NONE 0 2258 AUTH_HMAC_MD5_96 1 (RFC2403) 2259 AUTH_HMAC_SHA1_96 2 (RFC2404) 2260 AUTH_DES_MAC 3 2261 AUTH_KPDK_MD5 4 (RFC1826) 2262 AUTH_AES_XCBC_96 5 2264 values 6-1023 are reserved to IANA. Values 1024-65535 are for 2265 private use among mutually consenting parties. 2267 For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs 2268 are: 2270 Name Number 2271 NONE 0 2272 Defined in Appendix B 1 - 4 2273 Defined in [ADDGROUP] 5, 14 - 18 2274 values 6-13 and 19-1023 are reserved to IANA for new MODP, ECP 2275 or EC2N groups. Values 1024-65535 are for private use among 2276 mutually consenting parties. 2278 For Transform Type 5 (Extended Sequence Numbers), defined Transform 2279 IDs are: 2281 Name Number 2282 No Extended Sequence Numbers 0 2283 Extended Sequence Numbers 1 2284 RESERVED 2 - 65535 2286 If Transform Type 5 is not included in a proposal, use of 2287 Extended Sequence Numbers is assumed. 2289 3.3.3 Valid Transform Types by Protocol 2290 The number and type of transforms that accompany an SA payload are 2291 dependent on the protocol in the SA itself. An SA payload proposing 2292 the establishment of an SA has the following mandatory and optional 2293 transform types. A compliant implementation MUST understand all 2294 mandatory and optional types for each protocol it supports (though it 2295 need not accept proposals with unacceptable suites). A proposal MAY 2296 omit the optional types if the only value for them it will accept is 2297 NONE. 2299 Protocol Mandatory Types Optional Types 2300 IKE ENCR, PRF, INTEG, D-H 2301 ESP ENCR INTEG, D-H, ESN 2302 AH INTEG D-H, ESN 2304 3.3.4 Mandatory Transform IDs 2306 The specification of suites that MUST and SHOULD be supported for 2307 interoperability has been removed from this document because they are 2308 likely to change more rapidly than this document evolves. 2310 An important lesson learned from IKEv1 is that no system should only 2311 implement the mandatory algorithms and expect them to be the best 2312 choice for all customers. For example, at the time that this document 2313 was being written, many IKEv1 implementers are starting to migrate to 2314 AES in CBC mode for VPN applications. Many IPsec systems based on 2315 IKEv2 will implement AES, longer Diffie-Hellman keys, and additional 2316 hash algorithms, and some IPsec customers already require these 2317 algorithms in addition to the ones listed above. 2319 It is likely that IANA will add additional transforms in the future, 2320 and some users may want to use private suites, especially for IKE 2321 where implementations should be capable of supporting different 2322 parameters, up to certain size limits. In support of this goal, all 2323 implementations of IKEv2 SHOULD include a management facility that 2324 allows specification (by a user or system administrator) of Diffie- 2325 Hellman parameters (the generator, modulus, and exponent lengths and 2326 values) for new DH groups. Implementations SHOULD provide a 2327 management interface via which these parameters and the associated 2328 transform IDs may be entered (by a user or system administrator), to 2329 enable negotiating such groups. 2331 All implementations of IKEv2 MUST include a management facility that 2332 enables a user or system administrator to specify the suites that are 2333 acceptable for use with IKE. Upon receipt of a payload with a set of 2334 transform IDs, the implementation MUST compare the transmitted 2335 transform IDs against those locally configured via the management 2336 controls, to verify that the proposed suite is acceptable based on 2337 local policy. The implementation MUST reject SA proposals that are 2338 not authorized by these IKE suite controls. 2340 3.3.5 Transform Attributes 2342 Each transform in a Security Association payload may include 2343 attributes that modify or complete the specification of the 2344 transform. These attributes are type/value pairs and are defined 2345 below. For example, if an encryption algorithm has a variable length 2346 key, the key length to be used may be specified as an attribute. 2347 Attributes can have a value with a fixed two octet length or a 2348 variable length value. For the latter, the attribute is encoded as 2349 type/length/value. 2351 1 2 3 2352 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 2353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2354 !A! Attribute Type ! AF=0 Attribute Length ! 2355 !F! ! AF=1 Attribute Value ! 2356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2357 ! AF=0 Attribute Value ! 2358 ! AF=1 Not Transmitted ! 2359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2361 Figure 9: Data Attributes 2363 o Attribute Type (2 octets) - Unique identifier for each type of 2364 attribute (see below). 2366 The most significant bit of this field is the Attribute Format 2367 bit (AF). It indicates whether the data attributes follow the 2368 Type/Length/Value (TLV) format or a shortened Type/Value (TV) 2369 format. If the AF bit is zero (0), then the Data Attributes 2370 are of the Type/Length/Value (TLV) form. If the AF bit is a 2371 one (1), then the Data Attributes are of the Type/Value form. 2373 o Attribute Length (2 octets) - Length in octets of the Attribute 2374 Value. When the AF bit is a one (1), the Attribute Value is 2375 only 2 octets and the Attribute Length field is not present. 2377 o Attribute Value (variable length) - Value of the Attribute 2378 associated with the Attribute Type. If the AF bit is a 2379 zero (0), this field has a variable length defined by the 2380 Attribute Length field. If the AF bit is a one (1), the 2381 Attribute Value has a length of 2 octets. 2383 Note that only a single attribute type (Key Length) is defined, and 2384 it is fixed length. The variable length encoding specification is 2385 included only for future extensions. The only algorithms defined in 2386 this document that accept attributes are the AES based encryption, 2387 integrity, and pseudo-random functions, which require a single 2388 attribute specifying key width. 2390 Attributes described as basic MUST NOT be encoded using the variable 2391 length encoding. Variable length attributes MUST NOT be encoded as 2392 basic even if their value can fit into two octets. NOTE: This is a 2393 change from IKEv1, where increased flexibility may have simplified 2394 the composer of messages but certainly complicated the parser. 2396 Attribute Type value Attribute Format 2397 -------------------------------------------------------------- 2398 RESERVED 0-13 2399 Key Length (in bits) 14 TV 2400 RESERVED 15-17 2401 RESERVED TO IANA 18-16383 2402 PRIVATE USE 16384-32767 2404 Values 0-13 and 15-17 were used in a similar context in IKEv1, and 2405 should not be assigned except to matching values. Values 18-16383 are 2406 reserved to IANA. Values 16384-32767 are for private use among 2407 mutually consenting parties. 2409 - Key Length 2411 When using an Encryption Algorithm that has a variable length key, 2412 this attribute specifies the key length in bits. (MUST use network 2413 byte order). This attribute MUST NOT be used when the specified 2414 Encryption Algorithm uses a fixed length key. 2416 3.3.6 Attribute Negotiation 2418 During security association negotiation Initiators present offers to 2419 Responders. Responders MUST select a single complete set of 2420 parameters from the offers (or reject all offers if none are 2421 acceptable). If there are multiple proposals, the Responder MUST 2422 choose a single proposal number and return all of the Proposal 2423 substructures with that Proposal number. If there are multiple 2424 Transforms with the same type the Responder MUST choose a single one. 2425 Any attributes of a selected transform MUST be returned unmodified. 2426 The Initiator of an exchange MUST check that the accepted offer is 2427 consistent with one of its proposals, and if not that response MUST 2428 be rejected. 2430 Negotiating Diffie-Hellman groups presents some special challenges. 2431 SA offers include proposed attributes and a Diffie-Hellman public 2432 number (KE) in the same message. If in the initial exchange the 2433 Initiator offers to use one of several Diffie-Hellman groups, it 2434 SHOULD pick the one the Responder is most likely to accept and 2435 include a KE corresponding to that group. If the guess turns out to 2436 be wrong, the Responder will indicate the correct group in the 2437 response and the Initiator SHOULD pick an element of that group for 2438 its KE value when retrying the first message. It SHOULD, however, 2439 continue to propose its full supported set of groups in order to 2440 prevent a man in the middle downgrade attack. 2442 Implementation Note: 2444 Certain negotiable attributes can have ranges or could have 2445 multiple acceptable values. These include the key length of a 2446 variable key length symmetric cipher. To further interoperability 2447 and to support upgrading endpoints independently, implementers of 2448 this protocol SHOULD accept values which they deem to supply 2449 greater security. For instance if a peer is configured to accept a 2450 variable lengthed cipher with a key length of X bits and is 2451 offered that cipher with a larger key length an implementation 2452 SHOULD accept the offer. 2454 Support of this capability allows an implementation to express a 2455 concept of "at least" a certain level of security-- "a key length of 2456 _at least_ X bits for cipher foo". 2458 3.4 Key Exchange Payload 2460 The Key Exchange Payload, denoted KE in this memo, is used to 2461 exchange Diffie-Hellman public numbers as part of a Diffie-Hellman 2462 key exchange. The Key Exchange Payload consists of the IKE generic 2463 payload header followed by the Diffie-Hellman public value itself. 2465 1 2 3 2466 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 2467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2468 ! Next Payload !C! RESERVED ! Payload Length ! 2469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2470 ! DH Group # ! RESERVED ! 2471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2472 ! ! 2473 ~ Key Exchange Data ~ 2474 ! ! 2475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2477 Figure 10: Key Exchange Payload Format 2479 A key exchange payload is constructed by copying one's Diffie-Hellman 2480 public value into the "Key Exchange Data" portion of the payload. 2481 The length of the Diffie-Hellman public value MUST be equal to the 2482 length of the prime modulus over which the exponentiation was 2483 performed, prepending zero bits to the value if necessary. 2485 The DH Group # identifies the Diffie-Hellman group in which the Key 2486 Exchange Data was computed (see Appendix B). If the selected 2487 proposal uses a different Diffie-Hellman group, the message MUST be 2488 rejected with a Notify payload of type INVALID_KE_PAYLOAD. 2490 The payload type for the Key Exchange payload is thirty four (34). 2492 3.5 Identification Payloads 2494 The Identification Payloads, denoted IDi and IDr in this memo, allow 2495 peers to assert an identity to one another. This identity may be used 2496 for policy lookup, but does not necessarily have to match anything in 2497 the CERT payload; both fields may be used by an implementation to 2498 perform access control decisions. 2500 NOTE: In IKEv1, two ID payloads were used in each direction to hold 2501 Traffic Selector information for data passing over the SA. In IKEv2, 2502 this information is carried in Traffic Selector (TS) payloads (see 2503 section 3.13). 2505 The Identification Payload consists of the IKE generic payload header 2506 followed by identification fields as follows: 2508 1 2 3 2509 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 2510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2511 ! Next Payload !C! RESERVED ! Payload Length ! 2512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2513 ! ID Type ! RESERVED | 2514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2515 ! ! 2516 ~ Identification Data ~ 2517 ! ! 2518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2520 Figure 11: Identification Payload Format 2522 o ID Type (1 octet) - Specifies the type of Identification being 2523 used. 2525 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 2527 o Identification Data (variable length) - Value, as indicated by 2528 the Identification Type. The length of the Identification Data 2529 is computed from the size in the ID payload header. 2531 The payload types for the Identification Payload are thirty five (35) 2532 for IDi and thirty six (36) for IDr. 2534 The following table lists the assigned values for the Identification 2535 Type field, followed by a description of the Identification Data 2536 which follows: 2538 ID Type Value 2539 ------- ----- 2540 RESERVED 0 2542 ID_IPV4_ADDR 1 2544 A single four (4) octet IPv4 address. 2546 ID_FQDN 2 2548 A fully-qualified domain name string. An example of a 2549 ID_FQDN is, "example.com". The string MUST not contain any 2550 terminators (e.g., NULL, CR, etc.). 2552 ID_RFC822_ADDR 3 2554 A fully-qualified RFC822 email address string, An example of 2555 a ID_RFC822_ADDR is, "jsmith@example.com". The string MUST 2556 not contain any terminators. 2558 ID_IPV6_ADDR 5 2560 A single sixteen (16) octet IPv6 address. 2562 ID_DER_ASN1_DN 9 2564 The binary DER encoding of an ASN.1 X.500 Distinguished Name 2565 [X.501]. 2567 ID_DER_ASN1_GN 10 2569 The binary DER encoding of an ASN.1 X.500 GeneralName 2570 [X.509]. 2572 ID_KEY_ID 11 2574 An opaque octet stream which may be used to pass an account 2575 name or to pass vendor-specific information necessary to do 2576 certain proprietary types of identification. 2578 Two implementations will interoperate only if each can generate a 2579 type of ID acceptable to the other. To assure maximum 2580 interoperability, implementations MUST be configurable to send at 2581 least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and 2582 MUST be configurable to accept all of these types. Implementations 2583 SHOULD be capable of generating and accepting all of these types. 2585 3.6 Certificate Payload 2587 The Certificate Payload, denoted CERT in this memo, provides a means 2588 to transport certificates or other authentication related information 2589 via IKE. Certificate payloads SHOULD be included in an exchange if 2590 certificates are available to the sender unless the peer has 2591 indicated an ability to retrieve this information from elsewhere 2592 using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note that the 2593 term "Certificate Payload" is somewhat misleading, because not all 2594 authentication mechanisms use certificates and data other than 2595 certificates may be passed in this payload. 2597 The Certificate Payload is defined as follows: 2599 1 2 3 2600 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 2601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2602 ! Next Payload !C! RESERVED ! Payload Length ! 2603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2604 ! Cert Encoding ! ! 2605 +-+-+-+-+-+-+-+-+ ! 2606 ~ Certificate Data ~ 2607 ! ! 2608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2610 Figure 12: Certificate Payload Format 2612 o Certificate Encoding (1 octet) - This field indicates the type 2613 of certificate or certificate-related information contained 2614 in the Certificate Data field. 2616 Certificate Encoding Value 2617 -------------------- ----- 2618 RESERVED 0 2619 PKCS #7 wrapped X.509 certificate 1 2620 PGP Certificate 2 2621 DNS Signed Key 3 2622 X.509 Certificate - Signature 4 2623 Kerberos Token 6 2624 Certificate Revocation List (CRL) 7 2625 Authority Revocation List (ARL) 8 2626 SPKI Certificate 9 2627 X.509 Certificate - Attribute 10 2628 Raw RSA Key 11 2629 Hash and URL of PKIX certificate 12 2630 Hash and URL of PKIX bundle 13 2631 RESERVED 14 - 200 2632 PRIVATE USE 201 - 255 2634 o Certificate Data (variable length) - Actual encoding of 2635 certificate data. The type of certificate is indicated 2636 by the Certificate Encoding field. 2638 The payload type for the Certificate Payload is thirty seven (37). 2640 Specific syntax is for some of the certificate type codes above is 2641 not defined in this document. The types whose syntax is defined in 2642 this document are: 2644 X.509 Certificate - Signature (4) contains a BER encoded X.509 2645 certificate. 2647 Certificate Revocation List (7) contains a BER encoded X.509 2648 certificate revocation list. 2650 Raw RSA Key (11) contains a PKCS #1 encoded RSA key. 2652 Hash and URL of PKIX certificate (12) contains a 20 octet SHA-1 2653 hash of a PKIX certificate followed by a variable length URL that 2654 resolves to the BER encoded certificate itself. 2656 Hash and URL of PKIX bundle (13) contains a 20 octet SHA-1 hash of 2657 a PKIX certificate bundle followed by a variable length URL the 2658 resolves to the BER encoded certificate bundle itself. The bundle 2659 is a BER encoded SEQUENCE of certificates and CRLs. 2661 Use the following ASN.1 definition (suggested by Nicholas 2662 Williams): 2664 DEFINITION EXPLICIT TAGS ::= 2665 BEGIN 2667 IMPORTS Certificate, CertificateList FROM PKIX1Explicit93 2669 CertificateOrCRL ::= CHOICE { 2670 cert [0] Certificate, 2671 crl [1] CertificateList 2672 } 2673 CertificateBundle ::= SEQUENCE OF CertificateOrCRL 2674 END 2676 Implementations MUST be capable of being configured to send and 2677 accept up to four X.509 certificates in support of authentication. 2678 Implementations SHOULD be capable of being configured to send and 2679 accept Raw RSA keys and the two Hash and URL formats. If multiple 2680 certificates are sent, the first certificate MUST contain the public 2681 key used to sign the AUTH payload. The other certificates may be sent 2682 in any order. 2684 3.7 Certificate Request Payload 2686 The Certificate Request Payload, denoted CERTREQ in this memo, 2687 provides a means to request preferred certificates via IKE and can 2688 appear in the IKE_INIT_SA response and/or the IKE_AUTH request. 2689 Certificate Request payloads MAY be included in an exchange when the 2690 sender needs to get the certificate of the receiver. If multiple CAs 2691 are trusted and the cert encoding does not allow a list, then 2692 multiple Certificate Request payloads SHOULD be transmitted. 2694 The Certificate Request Payload is defined as follows: 2696 1 2 3 2697 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 2698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2699 ! Next Payload !C! RESERVED ! Payload Length ! 2700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2701 ! Cert Encoding ! ! 2702 +-+-+-+-+-+-+-+-+ ! 2703 ~ Certification Authority ~ 2704 ! ! 2705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2707 Figure 13: Certificate Request Payload Format 2709 o Certificate Encoding (1 octet) - Contains an encoding of the type 2710 or format of certificate requested. Values are listed in section 2711 3.6. 2713 o Certification Authority (variable length) - Contains an encoding 2714 of an acceptable certification authority for the type of 2715 certificate requested. 2717 The payload type for the Certificate Request Payload is thirty eight 2718 (38). 2720 The Certificate Encoding field has the same values as those defined 2721 in section 3.6. The Certification Authority field contains an 2722 indicator of trusted authorities for this certificate type. The 2723 Certification Authority value is a concatenated list of SHA-1 hashes 2724 of the public keys of trusted CAs. Each is encoded as the SHA-1 hash 2725 of the Subject Public Key Info element (see section 4.1.2.7 of [RFC 2726 3280]) from each Trust Anchor certificate. The twenty-octet hashes 2727 are concatenated and included with no other formatting. 2729 Note that the term "Certificate Request" is somewhat misleading, in 2730 that values other than certificates are defined in a "Certificate" 2731 payload and requests for those values can be present in a Certificate 2732 Request Payload. The syntax of the Certificate Request payload in 2733 such cases is not defined in this document. 2735 The Certificate Request Payload is processed by inspecting the "Cert 2736 Encoding" field to determine whether the processor has any 2737 certificates of this type. If so the "Certification Authority" field 2738 is inspected to determine if the processor has any certificates which 2739 can be validated up to one of the specified certification 2740 authorities. This can be a chain of certificates. If a certificate 2741 exists which satisfies the criteria specified in the Certificate 2742 Request Payload, the certificate MUST be sent back to the certificate 2743 requestor; if a certificate chain exists which goes back to the 2744 certification authority specified in the request the entire chain 2745 SHOULD be sent back to the certificate requestor. If multiple 2746 certificates or chains exist that satisfy the request, the sender 2747 MUST pick one. If no certificates exist then the Certificate Request 2748 Payload is ignored. This is not an error condition of the protocol. 2749 There may be cases where there is a preferred CA, but an alternate 2750 might be acceptable (perhaps after prompting a human operator). 2752 3.8 Authentication Payload 2754 The Authentication Payload, denoted AUTH in this memo, contains data 2755 used for authentication purposes. The syntax of the Authentication 2756 data varies according to the Auth Method as specified below. 2758 The Authentication Payload is defined as follows: 2760 1 2 3 2761 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 2762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2763 ! Next Payload !C! RESERVED ! Payload Length ! 2764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2765 ! Auth Method ! RESERVED ! 2766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2767 ! ! 2768 ~ Authentication Data ~ 2769 ! ! 2770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2772 Figure 14: Authentication Payload Format 2774 o Auth Method (1 octet) - Specifies the method of authentication 2775 used. Values defined are: 2777 RSA Digital Signature (1) - Computed as specified in section 2778 2.15 using an RSA private key over a PKCS#1 padded hash. 2780 Shared Key Message Integrity Code (2) - Computed as specified in 2781 section 2.15 using the shared key associated with the identity 2782 in the ID payload and the negotiated prf function 2784 DSS Digital Signature (3) - Computed as specified in section 2785 2.15 using a DSS private key over a SHA-1 hash. 2787 The values 0 and 4-200 are reserved to IANA. The values 201-255 2788 are available for private use. 2790 o Authentication Data (variable length) - see section 2.15. 2792 The payload type for the Authentication Payload is thirty nine (39). 2794 3.9 Nonce Payload 2796 The Nonce Payload, denoted Ni and Nr in this memo for the Initiator's 2797 and Responder's nonce respectively, contains random data used to 2798 guarantee liveness during an exchange and protect against replay 2799 attacks. 2801 The Nonce Payload is defined as follows: 2803 1 2 3 2804 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 2805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2806 ! Next Payload !C! RESERVED ! Payload Length ! 2807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2808 ! ! 2809 ~ Nonce Data ~ 2810 ! ! 2811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2813 Figure 15: Nonce Payload Format 2815 o Nonce Data (variable length) - Contains the random data generated 2816 by the transmitting entity. 2818 The payload type for the Nonce Payload is forty (40). 2820 The size of a Nonce MUST be between 16 and 256 octets inclusive. 2821 Nonce values MUST NOT be reused. 2823 3.10 Notify Payload 2825 The Notify Payload, denoted N in this document, is used to transmit 2826 informational data, such as error conditions and state transitions, 2827 to an IKE peer. A Notify Payload may appear in a response message 2828 (usually specifying why a request was rejected), in an INFORMATIONAL 2829 Exchange (to report an error not in an IKE request), or in any other 2830 message to indicate sender capabilities or to modify the meaning of 2831 the request. 2833 The Notify Payload is defined as follows: 2835 1 2 3 2836 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 2837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2838 ! Next Payload !C! RESERVED ! Payload Length ! 2839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2840 ! S_Protocol_ID ! SPI Size ! Notify Message Type ! 2841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2842 ! ! 2843 ~ Security Parameter Index (SPI) ~ 2844 ! ! 2845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2846 ! ! 2847 ~ Notification Data ~ 2848 ! ! 2849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2851 Figure 16: Notification Payload Format 2853 o SECURITY_PROTOCOL_ID (1 octet) - If this notification concerns 2854 an existing SA, this field indicates the type of that SA. 2855 For IKE_SA notifications, this field MUST be one (1). For 2856 notifications concerning IPsec SAs this field MUST contain 2857 either (2) to indicate AH or (3) to indicate ESP. For 2858 notifications which do not relate to an existing SA, this 2859 field MUST be sent as zero and MUST be ignored on receipt. 2860 All other values for this field are reserved to IANA for future 2861 assignment. 2863 o SPI Size (1 octet) - Length in octets of the SPI as defined by 2864 the SECURITY_PROTOCOL_ID or zero if no SPI is applicable. For a 2865 notification concerning the IKE_SA, the SPI Size MUST be zero. 2867 o Notify Message Type (2 octets) - Specifies the type of 2868 notification message. 2870 o SPI (variable length) - Security Parameter Index. 2872 o Notification Data (variable length) - Informational or error data 2873 transmitted in addition to the Notify Message Type. Values for 2874 this field are type specific (see below). 2876 The payload type for the Notification Payload is forty one (41). 2878 3.10.1 Notify Message Types 2880 Notification information can be error messages specifying why an SA 2881 could not be established. It can also be status data that a process 2882 managing an SA database wishes to communicate with a peer process. 2883 The table below lists the Notification messages and their 2884 corresponding values. The number of different error statuses was 2885 greatly reduced from IKE V1 both for simplification and to avoid 2886 giving configuration information to probers. 2888 Types in the range 0 - 16383 are intended for reporting errors. An 2889 implementation receiving a Notify payload with one of these types 2890 that it does not recognize in a response MUST assume that the 2891 corresponding request has failed entirely. Unrecognized error types 2892 in a request and status types in a request or response MUST be 2893 ignored except that they SHOULD be logged. 2895 Notify payloads with status types MAY be added to any message and 2896 MUST be ignored if not recognized. They are intended to indicate 2897 capabilities, and as part of SA negotiation are used to negotiate 2898 non-cryptographic parameters. 2900 NOTIFY MESSAGES - ERROR TYPES Value 2901 ----------------------------- ----- 2902 UNSUPPORTED_CRITICAL_PAYLOAD 1 2904 Sent if the payload has the "critical" bit set and the 2905 payload type is not recognized. Notification Data contains 2906 the one octet payload type. 2908 INVALID_IKE_SPI 4 2910 Indicates an IKE message was received with an unrecognized 2911 destination SPI. This usually indicates that the recipient 2912 has rebooted and forgotten the existence of an IKE_SA. 2914 INVALID_MAJOR_VERSION 5 2916 Indicates the recipient cannot handle the version of IKE 2917 specified in the header. The closest version number that the 2918 recipient can support will be in the reply header. 2920 INVALID_SYNTAX 7 2922 Indicates the IKE message was received was invalid because 2923 some type, length, or value was out of range or because the 2924 request was rejected for policy reasons. To avoid a denial 2925 of service attack using forged messages, this status may 2926 only be returned for and in an encrypted packet if the 2927 MESSAGE_ID and cryptographic checksum were valid. To avoid 2928 leaking information to someone probing a node, this status 2929 MUST be sent in response to any error not covered by one of 2930 the other status types. To aid debugging, more detailed 2931 error information SHOULD be written to a console or log. 2933 INVALID_MESSAGE_ID 9 2935 Sent when an IKE MESSAGE_ID outside the supported window is 2936 received. This Notify MUST NOT be sent in a response; the 2937 invalid request MUST NOT be acknowledged. Instead, inform 2938 the other side by initiating an INFORMATIONAL exchange with 2939 Notification data containing the four octet invalid 2940 MESSAGE_ID. Sending this notification is optional and 2941 notifications of this type MUST be rate limited. 2943 INVALID_SPI 11 2945 MAY be sent in an IKE INFORMATIONAL Exchange when a node 2946 receives an ESP or AH packet with an invalid SPI. The 2947 Notification Data contains the SPI of the invalid packet. 2948 This usually indicates a node has rebooted and forgotten an 2949 SA. If this Informational Message is sent outside the 2950 context of an IKE_SA, it should only be used by the 2951 recipient as a "hint" that something might be wrong (because 2952 it could easily be forged). 2954 NO_PROPOSAL_CHOSEN 14 2956 None of the proposed crypto suites was acceptable. 2958 INVALID_KE_PAYLOAD 17 2960 The D-H Group # field in the KE payload is not the group # 2961 selected by the responder for this exchange. There are two 2962 octets of data associated with this notification: the 2963 accepted D-H Group # in big endian order. 2965 AUTHENTICATION_FAILED 24 2967 Sent in the response to an IKE_AUTH message when for some 2968 reason the authentication failed. There is no associated 2969 data. 2971 SINGLE_PAIR_REQUIRED 34 2973 This error indicates that a CREATE_CHILD_SA request is 2974 unacceptable because its sender is only willing to accept 2975 traffic selectors specifying a single pair of addresses. 2976 The requestor is expected to respond by requesting an SA for 2977 only the specific traffic he is trying to forward. 2979 NO_ADDITIONAL_SAS 35 2981 This error indicates that a CREATE_CHILD_SA request is 2982 unacceptable because the Responder is unwilling to accept 2983 any more CHILD_SAs on this IKE_SA. Some minimal 2984 implementations may only accept a single CHILD_SA setup in 2985 the context of an initial IKE exchange and reject any 2986 subsequent attempts to add more. 2988 INTERNAL_ADDRESS_FAILURE 36 2990 Indicates an error assigning an internal address (i.e., 2991 INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS) during the 2992 processing of a Configuration Payload by a Responder. If 2993 this error is generated within an IKE_AUTH exchange no 2994 CHILD_SA will be created. 2996 FAILED_CP_REQUIRED 37 2998 Sent by responder in the case where CP(CFG_REQUEST) was 2999 expected but not received, and so is a conflict with locally 3000 configured policy. There is no associated data. 3002 TS_UNACCEPTABLE 38 3004 Indicates that none of the addresses/protocols/ports in the 3005 supplied traffic selectors is acceptable. 3007 RESERVED TO IANA - Error types 39 - 8191 3009 Private Use - Errors 8192 - 16383 3011 NOTIFY MESSAGES - STATUS TYPES Value 3012 ------------------------------ ----- 3014 INITIAL_CONTACT 16384 3016 This notification asserts that this IKE_SA is the only 3017 IKE_SA currently active between the authenticated 3018 identities. It MAY be sent when an IKE_SA is established 3019 after a crash, and the recipient MAY use this information to 3020 delete any other IKE_SAs it has to the same authenticated 3021 identity without waiting for a timeout. This notification 3022 MUST NOT be sent by an entity that may be replicated (e.g., 3023 a roaming user's credentials where the user is allowed to 3024 connect to the corporate firewall from two remote systems at 3025 the same time). 3027 SET_WINDOW_SIZE 16385 3029 This notification asserts that the sending endpoint is 3030 capable of keeping state for multiple outstanding exchanges, 3031 permitting the recipient to send multiple requests before 3032 getting a response to the first. The data associated with a 3033 SET_WINDOW_SIZE notification MUST be 4 octets long and 3034 contain the big endian representation of the number of 3035 messages the sender promises to keep. Window size is always 3036 one until the initial exchanges complete. 3038 ADDITIONAL_TS_POSSIBLE 16386 3040 This notification asserts that the sending endpoint narrowed 3041 the proposed traffic selectors but that other traffic 3042 selectors would also have been acceptable, though only in a 3043 separate SA (see section 2.9). There is no data associated 3044 with this Notify type. It may only be sent as an additional 3045 payload in a message including accepted TSs. 3047 IPCOMP_SUPPORTED 16387 3049 This notification may only be included in a message 3050 containing an SA payload negotiating a CHILD_SA and 3051 indicates a willingness by its sender to use IPComp on this 3052 SA. The data associated with this notification includes a 3053 two octet IPComp CPI followed by a one octet transform ID 3054 optionally followed by attributes whose length and format is 3055 defined by that transform ID. A message proposing an SA may 3056 contain multiple IPCOMP_SUPPORTED notifications to indicate 3057 multiple supported algorithms. A message accepting an SA may 3058 contain at most one. 3060 The transform IDs currently defined are: 3062 NAME NUMBER DEFINED IN 3063 ----------- ------ ----------- 3064 RESERVED 0 3065 IPCOMP_OUI 1 3066 IPCOMP_DEFLATE 2 RFC 2394 3067 IPCOMP_LZS 3 RFC 2395 3068 IPCOMP_LZJH 4 RFC 3051 3070 values 5-240 are reserved to IANA. Values 241-255 are 3071 for private use among mutually consenting parties. 3073 NAT_DETECTION_SOURCE_IP 16388 3075 This notification is used by its recipient to determine 3076 whether the source is behind a NAT box. The data associated 3077 with this notification is a SHA-1 digest of the SPIs (in the 3078 order they appear in the header), IP address and port on 3079 which this packet was sent. There MAY be multiple Notify 3080 payloads of this type in a message if the sender does not 3081 know which of several network attachments will be used to 3082 send the packet. The recipient of this notification MAY 3083 compare the supplied value to a SHA-1 hash of the SPIs, 3084 source IP address and port and if they don't match it SHOULD 3085 enable NAT traversal (see section 2.23). Alternately, it 3086 MAY reject the connection attempt if NAT traversal is not 3087 supported. 3089 NAT_DETECTION_DESTINATION_IP 16389 3091 This notification is used by its recipient to determine 3092 whether it is behind a NAT box. The data associated with 3093 this notification is a SHA-1 digest of the SPIs (in the 3094 order they appear in the header), IP address and port to 3095 which this packet was sent. The recipient of this 3096 notification MAY compare the supplied value to a hash of the 3097 SPIs, destination IP address and port and if they don't 3098 match it SHOULD invoke NAT traversal (see section 2.23). If 3099 they don't match, it means that this end is behind a NAT and 3100 this end SHOULD start start sending keepalive packets as 3101 defined in [Hutt02]. Alternately, it MAY reject the 3102 connection attempt if NAT traversal is not supported. 3104 COOKIE 16390 3106 This notification MAY be included in an IKE_SA_INIT 3107 response. It indicates that the request should be retried 3108 with a copy of this notification as the first payload. This 3109 notification MUST be included in an IKE_SA_INIT request 3110 retry if a COOKIE notification was included in the initial 3111 response. The data associated with this notification MUST 3112 be between 1 and 64 octets in length (inclusive). 3114 USE_TRANSPORT_MODE 16391 3115 This notification MAY be included in a request message that 3116 also includes an SA requesting a CHILD_SA. It requests that 3117 the CHILD_SA use transport mode rather than tunnel mode for 3118 the SA created. If the request is accepted, the response 3119 MUST also include a notification of type USE_TRANSPORT_MODE. 3120 If the responder declines the request, the CHILD_SA will be 3121 established in tunnel mode. If this is unacceptable to the 3122 initiator, the initiator MUST delete the SA. Note: except 3123 when using this option to negotiate transport mode, all 3124 CHILD_SAs will use tunnel mode. 3126 Note: The ECN decapsulation modifications specified in 3127 [RFC2401bis] MUST be performed for every tunnel mode SA 3128 created by IKEv2. 3130 HTTP_CERT_LOOKUP_SUPPORTED 16392 3132 This notification MAY be included in any message that can 3133 include a CERTREQ payload and indicates that the sender is 3134 capable of looking up certificates based on an HTTP-based 3135 URL (and hence presumably would prefer to receive 3136 certificate specifications in that format). 3138 REKEY_SA 16393 3140 This notification MUST be included in a CREATE_CHILD_SA 3141 exchange if the purpose of the exchange is to replace an 3142 existing ESP or AH SA. The SPI field identifies the SA being 3143 rekeyed. There is no data. 3145 RESERVED TO IANA - STATUS TYPES 16394 - 40959 3147 Private Use - STATUS TYPES 40960 - 65535 3149 3.11 Delete Payload 3151 The Delete Payload, denoted D in this memo, contains a protocol 3152 specific security association identifier that the sender has removed 3153 from its security association database and is, therefore, no longer 3154 valid. Figure 17 shows the format of the Delete Payload. It is 3155 possible to send multiple SPIs in a Delete payload, however, each SPI 3156 MUST be for the same protocol. Mixing of Protocol Identifiers MUST 3157 NOT be performed in a the Delete payload. It is permitted, however, 3158 to include multiple Delete payloads in a single INFORMATIONAL 3159 Exchange where each Delete payload lists SPIs for a different 3160 protocol. 3162 Deletion of the IKE_SA is indicated by a SECURITY_PROTOCOL_ID of 1 3163 (IKE) but no SPIs. Deletion of a CHILD_SA, such as ESP or AH, will 3164 contain the SECURITY_PROTOCOL_ID of that protocol (2 for AH, 3 for 3165 ESP) and the SPI is the SPI the sending endpoint would expect in 3166 inbound ESP or AH packets. 3168 The Delete Payload is defined as follows: 3170 1 2 3 3171 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 3172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3173 ! Next Payload !C! RESERVED ! Payload Length ! 3174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3175 ! S_PROTOCOL_ID ! SPI Size ! # of SPIs ! 3176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3177 ! ! 3178 ~ Security Parameter Index(es) (SPI) ~ 3179 ! ! 3180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3182 Figure 17: Delete Payload Format 3184 o SECURITY_PROTOCOL_ID (1 octet) - Must be 1 for an IKE_SA, 2 3185 for AH, or 3 for ESP. 3187 o SPI Size (1 octet) - Length in octets of the SPI as defined by 3188 the SECURITY_PROTOCOL_ID. Zero for IKE (SPI is in message 3189 header) or four for AH and ESP. 3191 o # of SPIs (2 octets) - The number of SPIs contained in the Delete 3192 payload. The size of each SPI is defined by the SPI Size field. 3194 o Security Parameter Index(es) (variable length) - Identifies the 3195 specific security association(s) to delete. The length of this 3196 field is determined by the SPI Size and # of SPIs fields. 3198 The payload type for the Delete Payload is forty two (42). 3200 3.12 Vendor ID Payload 3202 The Vendor ID Payload contains a vendor defined constant. The 3203 constant is used by vendors to identify and recognize remote 3204 instances of their implementations. This mechanism allows a vendor 3205 to experiment with new features while maintaining backwards 3206 compatibility. 3208 A Vendor ID payload MAY announce that the sender is capable to 3209 accepting certain extensions to the protocol, or it MAY simply 3210 identify the implementation as an aid in debugging. A Vendor ID 3211 payload MUST NOT change the interpretation of any information defined 3212 in this specification (i.e., it MUST be non-critical). Multiple 3213 Vendor ID payloads MAY be sent. An implementation is NOT REQUIRED to 3214 send any Vendor ID payload at all. 3216 A Vendor ID payload may be sent as part of any message. Reception of 3217 a familiar Vendor ID payload allows an implementation to make use of 3218 Private USE numbers described throughout this memo-- private 3219 payloads, private exchanges, private notifications, etc. Unfamiliar 3220 Vendor IDs MUST be ignored. 3222 Writers of Internet-Drafts who wish to extend this protocol MUST 3223 define a Vendor ID payload to announce the ability to implement the 3224 extension in the Internet-Draft. It is expected that Internet-Drafts 3225 which gain acceptance and are standardized will be given "magic 3226 numbers" out of the Future Use range by IANA and the requirement to 3227 use a Vendor ID will go away. 3229 The Vendor ID Payload fields are defined as follows: 3231 1 2 3 3232 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 3233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3234 ! Next Payload !C! RESERVED ! Payload Length ! 3235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3236 ! ! 3237 ~ Vendor ID (VID) ~ 3238 ! ! 3239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3241 Figure 18: Vendor ID Payload Format 3243 o Vendor ID (variable length) - It is the responsibility of 3244 the person choosing the Vendor ID to assure its uniqueness 3245 in spite of the absence of any central registry for IDs. 3246 Good practice is to include a company name, a person name 3247 or some such. If you want to show off, you might include 3248 the latitude and longitude and time where you were when 3249 you chose the ID and some random input. A message digest 3250 of a long unique string is preferable to the long unique 3251 string itself. 3253 The payload type for the Vendor ID Payload is forty three (43). 3255 3.13 Traffic Selector Payload 3257 The Traffic Selector Payload, denoted TS in this memo, allows peers 3258 to identify packet flows for processing by IPsec security services. 3259 The Traffic Selector Payload consists of the IKE generic payload 3260 header followed by individual traffic selectors as follows: 3262 1 2 3 3263 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 3264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3265 ! Next Payload !C! RESERVED ! Payload Length ! 3266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3267 ! Number of TSs ! RESERVED ! 3268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3269 ! ! 3270 ~ ~ 3271 ! ! 3272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3274 Figure 19: Traffic Selectors Payload Format 3276 o Number of TSs (1 octet) - Number of traffic selectors 3277 being provided. 3279 o RESERVED - This field MUST be sent as zero and MUST be ignored 3280 on receipt. 3282 o Traffic Selectors (variable length) - one or more individual 3283 traffic selectors. 3285 The length of the Traffic Selector payload includes the TS header and 3286 all the traffic selectors. 3288 The payload type for the Traffic Selector payload is forty four (44) 3289 for addresses at the initiator's end of the SA and forty five (45) 3290 for addresses at the responder's end. 3292 3.13.1 Traffic Selector 3294 1 2 3 3295 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 3296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3297 ! TS Type ! Protocol_ID* | Selector Length | 3298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3299 | Start_Port* | End_Port* | 3300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3301 ! ! 3302 ~ Starting Address* ~ 3303 ! ! 3304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3305 ! ! 3306 ~ Ending Address* ~ 3307 ! ! 3308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3310 Figure 20: Traffic Selector 3312 *Note: all fields other than TS Type and Selector Length depend on 3313 the TS Type. The fields shown are for TS Types 7 and 8, the only two 3314 values currently defined. 3316 o TS Type (one octet) - Specifies the type of traffic selector. 3318 o Protocol ID (1 octet) - Value specifying an associated IP 3319 protocol ID (e.g., UDP/TCP/ICMP). A value of zero means that 3320 the Protocol ID is not relevant to this traffic selector-- 3321 the SA can carry all protocols. 3323 o Selector Length - Specifies the length of this Traffic 3324 Selector Substructure including the header. 3326 o Start_Port (2 octets) - Value specifying the smallest port 3327 number allowed by this Traffic Selector. For protocols for 3328 which port is undefined, or if all ports are allowed by 3329 this Traffic Selector, this field MUST be zero. For the 3330 ICMP protocol, the two one octet fields Type and Code are 3331 treated as a single 16 bit integer port number for the 3332 purposes of filtering based on this field. 3334 o End_Port (2 octets) - Value specifying the largest port 3335 number allowed by this Traffic Selector. For protocols for 3336 which port is undefined, or if all ports are allowed by 3337 this Traffic Selector, this field MUST be 65535. For the 3338 ICMP protocol, the two one octet fields Type and Code are 3339 treated as a single 16 bit integer port number for the 3340 purposed of filtering based on this field. 3342 o Starting Address - The smallest address included in this 3343 Traffic Selector (length determined by TS type). 3345 o Ending Address - The largest address included in this 3346 Traffic Selector (length determined by TS type). 3348 The following table lists the assigned values for the Traffic 3349 Selector Type field and the corresponding Address Selector Data. 3351 TS Type Value 3352 ------- ----- 3353 RESERVED 0-6 3355 TS_IPV4_ADDR_RANGE 7 3357 A range of IPv4 addresses, represented by two four (4) octet 3358 values. The first value is the beginning IPv4 address 3359 (inclusive) and the second value is the ending IPv4 address 3360 (inclusive). All addresses falling between the two specified 3361 addresses are considered to be within the list. 3363 TS_IPV6_ADDR_RANGE 8 3365 A range of IPv6 addresses, represented by two sixteen (16) 3366 octet values. The first value is the beginning IPv6 address 3367 (inclusive) and the second value is the ending IPv6 address 3368 (inclusive). All addresses falling between the two specified 3369 addresses are considered to be within the list. 3371 3.14 Encrypted Payload 3373 The Encrypted Payload, denoted SK{...} in this memo, contains other 3374 payloads in encrypted form. The Encrypted Payload, if present in a 3375 message, MUST be the last payload in the message. Often, it is the 3376 only payload in the message. 3378 The algorithms for encryption and integrity protection are negotiated 3379 during IKE_SA setup, and the keys are computed as specified in 3380 sections 2.14 and 2.18. 3382 The encryption and integrity protection algorithms are modelled after 3383 the ESP algorithms described in RFCs 2104, 2406, 2451. This document 3384 completely specifies the cryptographic processing of IKE data, but 3385 those documents should be consulted for design rationale. We assume a 3386 block cipher with a fixed block size and an integrity check algorithm 3387 that computes a fixed length checksum over a variable size message. 3389 The payload type for an Encrypted payload is forty six (46). The 3390 Encrypted Payload consists of the IKE generic payload header followed 3391 by individual fields as follows: 3393 1 2 3 3394 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 3395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3396 ! Next Payload !C! RESERVED ! Payload Length ! 3397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3398 ! Initialization Vector ! 3399 ! (length is block size for encryption algorithm) ! 3400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3401 ! Encrypted IKE Payloads ! 3402 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3403 ! ! Padding (0-255 octets) ! 3404 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 3405 ! ! Pad Length ! 3406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3407 ~ Integrity Checksum Data ~ 3408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3410 Figure 21: Encrypted Payload Format 3412 o Next Payload - The payload type of the first embedded payload. 3413 Note that this is an exception in the standard header format, 3414 since the Encrypted payload is the last payload in the 3415 message and therefore the Next Payload field would normally 3416 be zero. But because the content of this payload is embedded 3417 payloads and there was no natural place to put the type of 3418 the first one, that type is placed here. 3420 o Payload Length - Includes the lengths of the header, IV, 3421 Encrypted IKE Payloads, Padding, Pad Length and Integrity 3422 Checksum Data. 3424 o Initialization Vector - A randomly chosen value whose length 3425 is equal to the block length of the underlying encryption 3426 algorithm. Recipients MUST accept any value. Senders SHOULD 3427 either pick this value pseudo-randomly and independently for 3428 each message or use the final ciphertext block of the previous 3429 message sent. Senders MUST NOT use the same value for each 3430 message, use a sequence of values with low hamming distance 3431 (e.g., a sequence number), or use ciphertext from a received 3432 message. 3434 o IKE Payloads are as specified earlier in this section. This 3435 field is encrypted with the negotiated cipher. 3437 o Padding MAY contain any value chosen by the sender, and MUST 3438 have a length that makes the combination of the Payloads, the 3439 Padding, and the Pad Length to be a multiple of the encryption 3440 block size. This field is encrypted with the negotiated 3441 cipher. 3443 o Pad Length is the length of the Padding field. The sender 3444 SHOULD set the Pad Length to the minimum value that makes 3445 the combination of the Payloads, the Padding, and the Pad 3446 Length a multiple of the block size, but the recipient MUST 3447 accept any length that results in proper alignment. This 3448 field is encrypted with the negotiated cipher. 3450 o Integrity Checksum Data is the cryptographic checksum of 3451 the entire message starting with the Fixed IKE Header 3452 through the Pad Length. The checksum MUST be computed over 3453 the encrypted message. 3455 3.15 Configuration Payload 3457 The Configuration payload, denoted CP in this document, is used to 3458 exchange configuration information between IKE peers. Currently, the 3459 only defined uses for this exchange is for an IRAC to request an 3460 internal IP address from an IRAS or for either party to request 3461 version information from the other, but this payload is intended as a 3462 likely place for future extensions. 3464 Configuration payloads are of type CFG_REQUEST/CFG_REPLY or 3465 CFG_SET/CFG_ACK (see CFG Type in the payload description below). 3466 CFG_REQUEST and CFG_SET payloads may optionally be added to any IKE 3467 request. The IKE response MUST include either a corresponding 3468 CFG_REPLY or CFG_ACK or a Notify payload with an error type 3469 indicating why the request could not be honored. An exception is that 3470 a minimal implementation MAY ignore all CFG_REQUEST and CFG_SET 3471 payloads, so a response message without a corresponding CFG_REPLY or 3472 CFG_ACK MUST be accepted as an indication that the request was not 3473 supported. 3475 "CFG_REQUEST/CFG_REPLY" allows an IKE endpoint to request information 3476 from its peer. If an attribute in the CFG_REQUEST Configuration 3477 Payload is not zero length it is taken as a suggestion for that 3478 attribute. The CFG_REPLY Configuration Payload MAY return that 3479 value, or a new one. It MAY also add new attributes and not include 3480 some requested ones. Requestors MUST ignore returned attributes that 3481 they do not recognize. 3483 Some attributes MAY be multi-valued, in which case multiple attribute 3484 values of the same type are sent and/or returned. Generally, all 3485 values of an attribute are returned when the attribute is requested. 3486 For some attributes (in this version of the specification only 3487 internal addresses), multiple requests indicates a request that 3488 multiple values be assigned. For these attributes, the number of 3489 values returned SHOULD NOT exceed the number requested. 3491 If the data type requested in a CFG_REQUEST is not recognized or not 3492 supported, the responder MUST NOT return an error type but rather 3493 MUST either send a CFG_REPLY which MAY be empty or a reply not 3494 containing a CFG_REPLY payload at all. Error returns are reserved for 3495 cases where the request is recognized but cannot be performed as 3496 requested or the request is badly formatted. 3498 "CFG_SET/CFG_ACK" allows an IKE endpoint to push configuration data 3499 to its peer. In this case the CFG_SET Configuration Payload contains 3500 attributes the initiator wants its peer to alter. The responder MUST 3501 return a Configuration Payload if it accepted any of the 3502 configuration data and it MUST contain the attributes that the 3503 responder accepted with zero length data. Those attributes that it 3504 did not accept MUST NOT be in the CFG_ACK Configuration Payload. If 3505 no attributes were accepted, the responder MUST return either an 3506 empty CFG_ACK payload or a response message without a CFG_ACK 3507 payload. There are currently no defined uses for the CFG_SET/CFG_ACK 3508 exchange, though they may be used in connection with extensions based 3509 on Vendor IDs. An minimal implementation of this specification MAY 3510 ignore CFG_SET payloads. 3512 Extensions via the CP payload SHOULD NOT be used for general purpose 3513 management. Its main intent is to provide a bootstrap mechanism to 3514 exchange information within IPsec from IRAS to IRAC. While it MAY be 3515 useful to use such a method to exchange information between some 3516 Security Gateways (SGW) or small networks, existing management 3517 protocols such as DHCP [DHCP], RADIUS [RADIUS], SNMP or LDAP [LDAP] 3518 should be preferred for enterprise management as well as subsequent 3519 information exchanges. 3521 The Configuration Payload is defined as follows: 3523 1 2 3 3524 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 3525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3526 ! Next Payload !C! RESERVED ! Payload Length ! 3527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3528 ! CFG Type ! RESERVED ! 3529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3530 ! ! 3531 ~ Configuration Attributes ~ 3532 ! ! 3533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3535 Figure 22: Configuration Payload Format 3537 The payload type for the Configuration Payload is forty seven (47). 3539 o CFG Type (1 octet) - The type of exchange represented by the 3540 Configuration Attributes. 3542 CFG Type Value 3543 =========== ===== 3544 RESERVED 0 3545 CFG_REQUEST 1 3546 CFG_REPLY 2 3547 CFG_SET 3 3548 CFG_ACK 4 3550 values 5-127 are reserved to IANA. Values 128-255 are for private 3551 use among mutually consenting parties. 3553 o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on 3554 receipt. 3556 o Configuration Attributes (variable length) - These are type 3557 length values specific to the Configuration Payload and are 3558 defined below. There may be zero or more Configuration 3559 Attributes in this payload. 3561 3.15.1 Configuration Attributes 3563 1 2 3 3564 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 3565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3566 !R| Attribute Type ! Length | 3567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3568 | | 3569 ~ Value ~ 3570 | | 3571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3573 Figure 23: Configuration Attribute Format 3575 o Reserved (1 bit) - This bit MUST be set to zero and MUST be 3576 ignored on receipt. 3578 o Attribute Type (7 bits) - A unique identifier for each of the 3579 Configuration Attribute Types. 3581 o Length (2 octets) - Length in octets of Value. 3583 o Value (0 or more octets) - The variable length value of this 3584 Configuration Attribute. 3586 The following attribute types have been defined: 3588 Multi- 3589 Attribute Type Value Valued Length 3590 ======================= ===== ====== ================== 3591 RESERVED 0 3592 INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets 3593 INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets 3594 INTERNAL_IP4_DNS 3 YES 0 or 4 octets 3595 INTERNAL_IP4_NBNS 4 YES 0 or 4 octets 3596 INTERNAL_ADDRESS_EXPIRY 5 NO 0 or 4 octets 3597 INTERNAL_IP4_DHCP 6 YES 0 or 4 octets 3598 APPLICATION_VERSION 7 NO 0 or more 3599 INTERNAL_IP6_ADDRESS 8 YES* 0 or 16 octets 3600 INTERNAL_IP6_NETMASK 9 NO 0 or 16 octets 3601 INTERNAL_IP6_DNS 10 YES 0 or 16 octets 3602 INTERNAL_IP6_NBNS 11 YES 0 or 16 octets 3603 INTERNAL_IP6_DHCP 12 YES 0 or 16 octets 3604 INTERNAL_IP4_SUBNET 13 NO 0 or 8 octets 3605 SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 3606 INTERNAL_IP6_SUBNET 15 NO 17 octets 3608 * These attributes may be multi-valued on return only if 3609 multiple values were requested. 3611 Types 16-16383 are reserved to IANA. Values 16384-32767 are for 3612 private use among mutually consenting parties. 3614 o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the 3615 internal network, sometimes called a red node address or 3616 private address and MAY be a private address on the Internet. 3617 Multiple internal addresses MAY be requested by requesting 3618 multiple internal address attributes. The responder MAY only 3619 send up to the number of addresses requested. 3621 The requested address is valid until the expiry time defined 3622 with the INTERNAL_ADDRESS EXPIRY attribute or there are no 3623 IKE_SAs between the peers. 3625 o INTERNAL_IP4_NETMASK, INTERNAL_IP6_NETMASK - The internal 3626 network's netmask. Only one netmask is allowed in the request 3627 and reply messages (e.g., 255.255.255.0) and it MUST be used 3628 only with an INTERNAL_ADDRESS attribute. 3630 o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a 3631 DNS server within the network. Multiple DNS servers MAY be 3632 requested. The responder MAY respond with zero or more DNS 3633 server attributes. 3635 o INTERNAL_IP4_NBNS, INTERNAL_IP6_NBNS - Specifies an address of 3636 a NetBios Name Server (WINS) within the network. Multiple NBNS 3637 servers MAY be requested. The responder MAY respond with zero 3638 or more NBNS server attributes. 3640 o INTERNAL_ADDRESS_EXPIRY - Specifies the number of seconds that 3641 the host can use the internal IP address. The host MUST renew 3642 the IP address before this expiry time. Only one of these 3643 attributes MAY be present in the reply. 3645 o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to 3646 send any internal DHCP requests to the address contained within 3647 the attribute. Multiple DHCP servers MAY be requested. The 3648 responder MAY respond with zero or more DHCP server attributes. 3650 o APPLICATION_VERSION - The version or application information of 3651 the IPsec host. This is a string of printable ASCII characters 3652 that is NOT null terminated. 3654 o INTERNAL_IP4_SUBNET - The protected sub-networks that this 3655 edge-device protects. This attribute is made up of two fields; 3656 the first being an IP address and the second being a netmask. 3658 Multiple sub-networks MAY be requested. The responder MAY 3659 respond with zero or more sub-network attributes. 3661 o SUPPORTED_ATTRIBUTES - When used within a Request, this 3662 attribute MUST be zero length and specifies a query to the 3663 responder to reply back with all of the attributes that it 3664 supports. The response contains an attribute that contains a 3665 set of attribute identifiers each in 2 octets. The length 3666 divided by 2 (octets) would state the number of supported 3667 attributes contained in the response. 3669 o INTERNAL_IP6_SUBNET - The protected sub-networks that this 3670 edge-device protects. This attribute is made up of two fields; 3671 the first being a 16 octet IPv6 address the second being a one 3672 octet prefix-length as defined in [ADDRIPV6]. Multiple 3673 sub-networks MAY be requested. The responder MAY respond with 3674 zero or more sub-network attributes. 3676 Note that no recommendations are made in this document how an 3677 implementation actually figures out what information to send in a 3678 reply. i.e., we do not recommend any specific method of an IRAS 3679 determining which DNS server should be returned to a requesting 3680 IRAC. 3682 3.16 Extended Authentication Protocol (EAP) Payload 3684 The Extended Authentication Protocol Payload, denoted EAP in this 3685 memo, allows IKE_SAs to be authenticated using the protocol defined 3686 in RFC 2284 [EAP] and subsequent extensions to that protocol. The 3687 full set of acceptable values for the payload are defined elsewhere, 3688 but a short summary of RFC 2284 is included here to make this 3689 document stand alone in the common cases. 3691 1 2 3 3692 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 3693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3694 ! Next Payload !C! RESERVED ! Payload Length ! 3695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3696 ! ! 3697 ~ EAP Message ~ 3698 ! ! 3699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3701 Figure 24: EAP Payload Format 3703 The payload type for an EAP Payload is forty eight (48). 3705 1 2 3 3706 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 3707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3708 ! Code ! Identifier ! Length ! 3709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3710 ! Type ! Type_Data... 3711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 3713 Figure 25: EAP Message Format 3715 o Code (one octet) indicates whether this message is a 3716 Request (1), Response (2), Success (3), or Failure (4). 3718 o Identifier (one octet) is used in PPP to distinguish replayed 3719 messages from repeated ones. Since in IKE, EAP runs over a 3720 reliable protocol, it serves no function here. In a response 3721 message this octet MUST be set to match the identifier in the 3722 corresponding request. In other messages, this field MAY 3723 be set to any value. 3725 o Length (two octets) is the length of the EAP message and MUST 3726 be four less than the Payload Length of the encapsulating 3727 payload. 3729 o Type (one octet) is present only if the Code field is Request 3730 (1) or Response (2). For other codes, the EAP message length 3731 MUST be four octets and the Type and Type_Data fields MUST NOT 3732 be present. In a Request (1) message, Type indicates the 3733 data being requested. In a Response (2) message, Type MUST 3734 either be NAC or match the type of the data requested. The 3735 following types are defined in RFC 2284: 3737 1 Identity 3738 2 Notification 3739 3 NAK (Response Only) 3740 4 MD5-Challenge 3741 5 One-Time Password (OTP) 3742 6 Generic Token Card 3744 o Type_Data (Variable Length) contains data depending on the Code 3745 and Type. In Requests other than MD5-Challenge, this field 3746 contains a prompt to be displayed to a human user. For NAK, it 3747 contains one octet suggesting the type of authentication the 3748 Initiator would prefer to use. For most other responses, it 3749 contains the authentication code typed by the human user. 3751 Note that since IKE passes an indication of initiator identity in 3752 message 3 of the protocol, EAP based prompts for Identity SHOULD NOT 3753 be used. 3755 4 Conformance Requirements 3757 In order to assure that all implementations of IKEv2 can 3758 interoperate, there are MUST support requirements in addition to 3759 those listed elsewhere. Of course, IKEv2 is a security protocol, and 3760 one of its major functions is preventing the bad guys from 3761 interoperating with one's systems. So a particular implementation may 3762 be configured with any of a number of restrictions concerning 3763 algorithms and trusted authorities that will prevent universal 3764 interoperability. 3766 IKEv2 is designed to permit minimal implementations that can 3767 interoperate with all compliant implementations. There are a series 3768 of optional features that can easily be ignored by a particular 3769 implementation if it does not support that feature. Those features 3770 include: 3772 Ability to negotiate SAs through a NAT and tunnel the resulting ESP 3773 SA over UDP. 3775 Ability to request (and respond to a request for) a temporary IP 3776 address on the remote end of a tunnel. 3778 Ability to support various types of legacy authentication. 3780 Ability to support window sizes greater than one. 3782 Ability to establish multiple ESP and/or AH SAs within a single 3783 IKE_SA. 3785 Ability to rekey SAs. 3787 To assure interoperability, all implementations MUST be capable of 3788 parsing all payload types (if only to skip over them) and to ignore 3789 payload types that it does not support unless the critical bit is set 3790 in the payload header. If the critical bit is set in an unsupported 3791 payload header, all implementations MUST reject the messages 3792 containing those payloads. 3794 Every implementation MUST be capable of doing four message 3795 IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, 3796 one for ESP and/or AH). Implementations MAY be initiate-only or 3797 respond-only if appropriate for their platform. Every implementation 3798 MUST be capable of responding to an INFORMATIONAL exchange, but a 3799 minimal implementation MAY respond to any INFORMATIONAL message with 3800 an empty INFORMATIONAL reply. A minimal implementation MAY support 3801 the CREATE_CHILD_SA exchange only in so far as to recognize requests 3802 and reject them with a Notify payload of type NO_ADDITIONAL_SAS. A 3803 minimal implementation need not be able to initiate CREATE_CHILD_SA 3804 or INFORMATIONAL exchanges. When an SA expires (based on locally 3805 configured values of either lifetime or octets passed), and 3806 implementation MAY either try to renew it with a CREATE_CHILD_SA 3807 exchange or it MAY delete (close) the old SA and create a new one. If 3808 the responder rejects the CREATE_CHILD_SA request with a 3809 NO_ADDITIONAL_SAS notification, the implementation MUST be capable of 3810 instead closing the old SA and creating a new one. 3812 Implementations are not required to support requesting temporary IP 3813 addresses or responding to such requests. If an implementation does 3814 support issuing such requests, it MUST include a CP payload in 3815 message 3 containing at least a field of type INTERNAL_IP4_ADDRESS or 3816 INTERNAL_IP6_ADDRESS. All other fields are optional. If an 3817 implementation supports responding to such requests, it MUST parse 3818 the CP payload of type CFG_REQUEST in message 3 and recognize a field 3819 of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports 3820 leasing an address of the appropriate type, it MUST return a CP 3821 payload of type CFG_REPLY containing an address of the requested 3822 type. The responder SHOULD include all of the other related 3823 attributes if it has them. 3825 A minimal IPv4 responder implementation will ignore the contents of 3826 the CP payload except to determine that it includes an 3827 INTERNAL_IP4_ADDRESS attribute and will respond with the address and 3828 other related attributes regardless of whether the initiator 3829 requested them. 3831 A minimal IPv4 initiator will generate a CP payload containing only 3832 an INTERNAL_IP4_ADDRESS attribute and will parse the response 3833 ignoring attributes it does not know how to use. The only attribute 3834 it MUST be able to process is INTERNAL_ADDRESS_EXPIRY, which it must 3835 use to bound the lifetime of the SA unless it successfully renews the 3836 lease before it expires. Minimal initiators need not be able to 3837 request lease renewals and minimal responders need not respond to 3838 them. 3840 For an implementation to be called conforming to this specification, 3841 it MUST be possible to configure it to accept the following: 3843 PKIX Certificates containing and signed by RSA keys of size 1024 or 3844 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, 3845 ID_RFC822_ADDR, or ID_DER_ASN1_DN. 3847 Shared key authentication where the ID passes is any of ID_KEY_ID, 3848 ID_FQDN, or ID_RFC822_ADDR. 3850 Authentication where the responder is authenticated using PKIX 3851 Certificates and the initiator is authenticated using shared key 3852 authentication. 3854 5 Security Considerations 3856 Repeated re-keying using CREATE_CHILD_SA without PFS leaves all SAs 3857 vulnerable to cryptanalysis of a single key or overrun of either 3858 endpoint. Implementers should take note of this fact and set a limit 3859 on CREATE_CHILD_SA exchanges between exponentiations. This memo does 3860 not prescribe such a limit. 3862 The strength of a key derived from a Diffie-Hellman exchange using 3863 any of the groups defined here depends on the inherent strength of 3864 the group, the size of the exponent used, and the entropy provided by 3865 the random number generator used. Due to these inputs it is difficult 3866 to determine the strength of a key for any of the defined groups. 3867 Diffie-Hellman group number two, when used with a strong random 3868 number generator and an exponent no less than 200 bits, is sufficient 3869 for use with 3DES. Groups three through five provide greater 3870 security. Group one is for historic purposes only and does not 3871 provide sufficient strength except for use with DES, which is also 3872 for historic use only. Implementations should make note of these 3873 conservative estimates when establishing policy and negotiating 3874 security parameters. 3876 Note that these limitations are on the Diffie-Hellman groups 3877 themselves. There is nothing in IKE which prohibits using stronger 3878 groups nor is there anything which will dilute the strength obtained 3879 from stronger groups (limited by the strength of the other algorithms 3880 negotiated including the prf function). In fact, the extensible 3881 framework of IKE encourages the definition of more groups; use of 3882 elliptical curve groups may greatly increase strength using much 3883 smaller numbers. 3885 It is assumed that all Diffie-Hellman exponents are erased from 3886 memory after use. In particular, these exponents MUST NOT be derived 3887 from long-lived secrets like the seed to a pseudo-random generator 3888 that is not erased after use. 3890 The strength of all keys are limited by the size of the output of the 3891 negotiated prf function. For this reason, a prf function whose output 3892 is less than 128 bits (e.g., 3DES-CBC) MUST never be used with this 3893 protocol. 3895 The security of this protocol is critically dependent on the 3896 randomness of the randomly chosen parameters. These should be 3897 generated by a strong random or properly seeded pseudo-random source 3898 (see [RFC1750]). Implementers should take care to ensure that use of 3899 random numbers for both keys and nonces is engineered in a fashion 3900 that does not undermine the security of the keys. 3902 For information on the rationale of many of the cryptographic design 3903 choices in this protocol, see [SIGMA]. 3905 When using pre-shared keys, a critical consideration is how to assure 3906 the randomness of these secrets. The strongest practice is to ensure 3907 that any pre-shared key contain as much randomness as the strongest 3908 key being negotiated. Deriving a shared secret from a password, name, 3909 or other low entropy source is not secure. These sources are subject 3910 to dictionary and social engineering attacks, among others. 3912 The NAT_DETECTION_*_IP notifications contain a hash of the addresses 3913 and ports in an attempt to hide internal IP addresses behind a NAT 3914 from the IKE peer. As the IPv4 address space is only 32 bits, and it 3915 is usually very sparse, it might be possible for the attacker to find 3916 out the internal address used behind the NAT box by trying all 3917 possible IP-addresses and trying to find the matching hash. The port 3918 numbers are normally fixed to 500, and the SPIs can be extracted from 3919 the packet. This limits the hash calculations down to 2^32. If 3920 educated guess of use of private address space is done, then the 3921 number of hash calculations needed to find out the internal IP 3922 address goes down to the 2^24 + 2 * (2^16). 3924 When using an EAP authentication method that does not generate a 3925 shared key for protecting a subsequent AUTH payload, certain man-in- 3926 the-middle and server impersonation attacks are possible [EAPMITM]. 3927 These vulnerabilities occur when EAP is also used in protocols which 3928 are not protected with a secure tunnel. Since EAP is a general- 3929 purpose authentication protocol, which is often used to provide 3930 single-signon facilities, a deployed IPsec solution which relies on 3931 an EAP authentication method that does not generate a shared key 3932 (also known as a non-key-generating EAP method) can become 3933 compromised due to the deployment of an entirely unrelated 3934 application that also happens to use the same non-key-generating EAP 3935 method, but in an unprotected fashion. Note that this vulnerability 3936 is not limited to just EAP, but can occur in other scenarios where an 3937 authentication infrastructure is reused. For example, if the EAP 3938 mechanism used by IKEv2 utilizes a token authenticator, a man-in-the- 3939 middle attacker could impersonate the web server, intercept the token 3940 authentication exchange, and use it to initiate an IKEv2 connection. 3941 For this reason, use of non-key-generating EAP methods SHOULD be 3942 avoided where possible. Where they are used, it is extremely 3943 important that all usages of these EAP methods SHOULD utilize a 3944 protected tunnel, where the initiator validates the responder's 3945 certificate before initiating the EAP exchange. Implementors SHOULD 3946 describe the vulnerabilities of using non-key-generating EAP methods 3947 in the documentation of their implementations so that the 3948 administrators deploying IPsec solutions are aware of these dangers. 3950 6 IANA Considerations 3952 This document contains many "magic numbers" to be maintained by the 3953 Internet Assigned Numbers Authority (IANA). While in many cases the 3954 values were chosen so as to avoid collisions with other 3955 specifications, these should be considered a new IANA registry for 3956 IKEv2. The tables to be maintained are: 3958 Payload Types 3959 Transform Types 3960 For each Transform Type defined, the assigned Transform values 3961 Authentication Method 3962 Security Protocol ID 3963 Error types 3964 Status types 3965 IPComp Transform IDs 3966 Configuration request types 3967 Configuration attribute types 3969 7 Intellectual Property Rights 3971 The IETF takes no position regarding the validity or scope of any 3972 intellectual property or other rights that might be claimed to 3973 pertain to the implementation or use of the technology described in 3974 this document or the extent to which any license under such rights 3975 might or might not be available; neither does it represent that it 3976 has made any effort to identify any such rights. Information on the 3977 IETF's procedures with respect to rights in standards-track and 3978 standards-related documentation can be found in BCP-11. Copies of 3979 claims of rights made available for publication and any assurances of 3980 licenses to be made available, or the result of an attempt made to 3981 obtain a general license or permission for the use of such 3982 proprietary rights by implementors or users of this specification can 3983 be obtained from the IETF Secretariat. 3985 The IETF encourages any interested party to bring to its attention 3986 any copyrights, patents, or patent applications, or other proprietary 3987 rights which may cover technology that may be required to practice 3988 this standard. Please address the information to the IETF Executive 3989 Director. 3991 The IETF has been notified of intellectual property rights claimed in 3992 regard to some or all of the specification contained in this 3993 document. For more information consult the online list of claimed 3994 rights. 3996 8 Acknowledgements 3998 This document is a collaborative effort of the entire IPsec WG. If 3999 there were no limit to the number of authors that could appear on an 4000 RFC, the following, in alphabetical order, would have been listed: 4001 Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt 4002 Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, J. 4003 Ioannidis, Steve Kent, Angelos Keromytis, Tero Kivinen, Hugo 4004 Krawczyk, Andrew Krywaniuk, Radia Perlman, O. Reingold. Many other 4005 people contributed to the design. It is an evolution of IKEv1, 4006 ISAKMP, and the IPsec DOI, each of which has its own list of authors. 4007 Hugh Daniel suggested the feature of having the initiator, in message 4008 3, specify a name for the responder, and gave the feature the cute 4009 name "You Tarzan, Me Jane". David Faucher and Valery Smyzlov helped 4010 refine the design of the traffic selector negotiation. 4012 9 References 4014 9.1 Normative References 4016 [ADDGROUP] Kivinen, T., and Kojo, M., "More Modular Exponential 4017 (MODP) Diffie-Hellman groups for Internet Key 4018 Exchange (IKE)", RFC 3526, May 2003. 4020 [ADDRIPV6] Hinden, R., and Deering, S., 4021 "Internet Protocol Version 6 (IPv6) Addressing 4022 Architecture", RFC 3513, April 2003. 4024 [Bra97] Bradner, S., "Key Words for use in RFCs to indicate 4025 Requirement Levels", BCP 14, RFC 2119, March 1997. 4027 [EAP] Blunk, L. and Vollbrecht, J., "PPP Extensible 4028 Authentication Protocol (EAP), RFC 2284, March 1998. 4030 [ESPCBC] Pereira, R., Adams, R., "The ESP CBC-Mode Cipher 4031 Algorithms", RFC 2451, November 1998. 4033 [RFC2401bis] Kent, S. and Atkinson, R., "Security Architecture 4034 for the Internet Protocol", un-issued Internet 4035 Draft, work in progress. 4037 [RFC3168] Ramakrishnan, K., Floyd, S., and Black, D., 4038 "The Addition of Explicit Congestion Notification (ECN) 4039 to IP", RFC 3168, September 2001. 4041 [RFC3280] Housley, R., Polk, W., Ford, W., Solo, D., "Internet 4042 X.509 Public Key Infrastructure Certificate and 4043 Certificate Revocation List (CRL) Profile", RFC 3280, 4044 April 2002. 4046 9.2 Informative References 4048 [Ble98] Bleichenbacher, D., "Chosen Ciphertext Attacks against 4049 Protocols Based on RSA Encryption Standard PKCS#1", 4050 Advances in Cryptology Eurocrypt '98, Springer-Verlag, 4051 1998. 4053 [BR94] Bellare, M., and Rogaway P., "Optimal Asymmetric 4054 Encryption", Advances in Cryptology Eurocrypt '94, 4055 Springer-Verlag, 1994. 4057 [DES] ANSI X3.106, "American National Standard for Information 4058 Systems-Data Link Encryption", American National Standards 4059 Institute, 1983. 4061 [DH] Diffie, W., and Hellman M., "New Directions in 4062 Cryptography", IEEE Transactions on Information Theory, V. 4063 IT-22, n. 6, June 1977. 4065 [DHCP] R. Droms, "Dynamic Host Configuration Protocol", 4066 RFC2131 4068 [DSS] NIST, "Digital Signature Standard", FIPS 186, National 4069 Institute of Standards and Technology, U.S. Department of 4070 Commerce, May, 1994. 4072 [EAPMITM] Asokan, N., Nierni, V., and Nyberg, K., "Man-in-the-Middle 4073 in Tunneled Authentication Protocols", 4074 http://eprint.iacr.org/2002/163, November 2002. 4076 [HC98] Harkins, D., Carrel, D., "The Internet Key Exchange 4077 (IKE)", RFC 2409, November 1998. 4079 [Hutt02] Huttunen, A. et. al., "UDP Encapsulation of IPsec 4080 Packets", draft-ietf-ipsec-udp-encaps-05.txt, December 4081 2002. 4083 [IDEA] Lai, X., "On the Design and Security of Block Ciphers," 4084 ETH Series in Information Processing, v. 1, Konstanz: 4085 Hartung-Gorre Verlag, 1992 4087 [IPCOMP] Shacham, A., Monsour, R., Pereira, R., and Thomas, M., "IP 4088 Payload Compression Protocol (IPComp)", RFC 3173, 4089 September 2001. 4091 [Ker01] Keromytis, A., Sommerfeld, B., "The 'Suggested ID' 4092 Extension for IKE", draft-keromytis-ike-id-00.txt, 2001 4094 [KBC96] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 4095 Hashing for Message Authentication", RFC 2104, February 4096 1997. 4098 [LDAP] M. Wahl, T. Howes, S. Kille., "Lightweight Directory 4099 Access Protocol (v3)", RFC2251 4101 [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, 4102 April 1992. 4104 [MSST98] Maughhan, D., Schertler, M., Schneider, M., and Turner, J. 4105 "Internet Security Association and Key Management Protocol 4106 (ISAKMP)", RFC 2408, November 1998. 4108 [Orm96] Orman, H., "The Oakley Key Determination Protocol", RFC 4109 2412, November 1998. 4111 [PFKEY] McDonald, D., Metz, C., and Phan, B., "PFKEY Key 4112 Management API, Version 2", RFC2367, July 1998. 4114 [PKCS1] Kaliski, B., and J. Staddon, "PKCS #1: RSA Cryptography 4115 Specifications Version 2", September 1998. 4117 [PK01] Perlman, R., and Kaufman, C., "Analysis of the IPsec key 4118 exchange Standard", WET-ICE Security Conference, MIT,2001, 4119 http://sec.femto.org/wetice-2001/papers/radia-paper.pdf. 4121 [Pip98] Piper, D., "The Internet IP Security Domain Of 4122 Interpretation for ISAKMP", RFC 2407, November 1998. 4124 [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote 4125 Authentication Dial In User Service (RADIUS)", RFC2138 4127 [RFC1750] Eastlake, D., Crocker, S., and Schiller, J., "Randomness 4128 Recommendations for Security", RFC 1750, December 1994. 4130 [RFC2401] Kent, S., and Atkinson, R., "Security Architecture for 4131 the Internet Protocol", RFC 2401, November 1998. 4133 [RFC2474] Nichols, K., Blake, S., Baker, F. and Black, D., 4134 "Definition of the Differentiated Services Field (DS 4135 Field) in the IPv4 and IPv6 Headers", RFC 2474, 4136 December 1998. 4138 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. 4140 and Weiss, W., "An Architecture for Differentiated 4141 Services", RFC 2475, December 1998. 4143 [RFC2522] Karn, P., and Simpson, W., "Photuris: Session-Key 4144 Management Protocol", RFC 2522, March 1999. 4146 [RFC2983] Black, D., "Differentiated Services and Tunnels", 4147 RFC 2983, October 2000. 4149 [RSA] Rivest, R., Shamir, A., and Adleman, L., "A Method for 4150 Obtaining Digital Signatures and Public-Key 4151 Cryptosystems", Communications of the ACM, v. 21, n. 2, 4152 February 1978. 4154 [SHA] NIST, "Secure Hash Standard", FIPS 180-1, National 4155 Institute of Standards and Technology, U.S. Department 4156 of Commerce, May 1994. 4158 [SIGMA] Krawczyk, H., "SIGMA: the `SIGn-and-MAc' Approach to 4159 Authenticated Diffie-Hellman and its Use in the IKE 4160 Protocols", in Advances in Cryptography - CRYPTO 2003 4161 Proceedings, LNCS 2729, Springer, 2003. Available at: 4162 http://www.ee.technion.ac.il/~hugo/sigma.html 4164 [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange 4165 Mechanism for Internet", from IEEE Proceedings of the 4166 1996 Symposium on Network and Distributed Systems 4167 Security. 4169 [X.501] ITU-T Recommendation X.501: Information Technology - 4170 Open Systems Interconnection - The Directory: Models, 4171 1993. 4173 [X.509] ITU-T Recommendation X.509 (1997 E): Information 4174 Technology - Open Systems Interconnection - The 4175 Directory: Authentication Framework, June 1997. 4177 Appendix A: Summary of changes from IKEv1 4179 The goals of this revision to IKE are: 4181 1) To define the entire IKE protocol in a single document, replacing 4182 RFCs 2407, 2408, and 2409 and incorporating subsequent changes to 4183 support NAT Traversal, Extended Authentication, and Remote Address 4184 acquisition. 4186 2) To simplify IKE by replacing the eight different initial exchanges 4187 with a single four message exchange (with changes in authentication 4188 mechanisms affecting only a single AUTH payload rather than 4189 restructuring the entire exchange); 4191 3) To remove the Domain of Interpretation (DOI), Situation (SIT), and 4192 Labeled Domain Identifier fields, and the Commit and Authentication 4193 only bits; 4195 4) To decrease IKE's latency in the common case by making the initial 4196 exchange be 2 round trips (4 messages), and allowing the ability to 4197 piggyback setup of a CHILD-SA on that exchange; 4199 5) To replace the cryptographic syntax for protecting the IKE 4200 messages themselves with one based closely on ESP to simplify 4201 implementation and security analysis; 4203 6) To reduce the number of possible error states by making the 4204 protocol reliable (all messages are acknowledged) and sequenced. This 4205 allows shortening CREATE_CHILD_SA exchanges from 3 messages to 2; 4207 7) To increase robustness by allowing the responder to not do 4208 significant processing until it receives a message proving that the 4209 initiator can receive messages at its claimed IP address, and not 4210 commit any state to an exchange until the initiator can be 4211 cryptographically authenticated; 4213 8) To fix bugs such as the hash problem documented in [draft-ietf- 4214 ipsec-ike-hash-revised-02.txt]; 4216 9) To specify Traffic Selectors in their own payloads type rather 4217 than overloading ID payloads, and making more flexible the Traffic 4218 Selectors that may be specified; 4220 10) To specify required behavior under certain error conditions or 4221 when data that is not understood is received in order to make it 4222 easier to make future revisions in a way that does not break 4223 backwards compatibility; 4224 11) To incorporate ideas from draft-ietf-ipsec-nat-reqts-04.txt to 4225 allow IKE to negotiate through NAT gateways; 4227 12) To simplify and clarify how shared state is maintained in the 4228 presence of network failures and Denial of Service attacks; and 4230 13) To maintain existing syntax and magic numbers to the extent 4231 possible to make it likely that implementations of IKEv1 can be 4232 enhanced to support IKEv2 with minimum effort. 4234 Appendix B: Diffie-Hellman Groups 4236 There are 5 different Diffie-Hellman groups defined for use in IKE. 4237 These groups were generated by Richard Schroeppel at the University 4238 of Arizona. Properties of these primes are described in [Orm96]. 4240 The strength supplied by group one may not be sufficient for the 4241 mandatory-to-implement encryption algorithm and is here for historic 4242 reasons. 4244 Additional Diffie-Hellman groups have been defined in [ADDGROUP]. 4246 B.1 Group 1 - 768 Bit MODP 4248 This group is assigned id 1 (one). 4250 The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } 4251 Its hexadecimal value is: 4253 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 4254 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 4255 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 4256 A63A3620 FFFFFFFF FFFFFFFF 4258 The generator is 2. 4260 B.2 Group 2 - 1024 Bit MODP 4262 This group is assigned id 2 (two). 4264 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. 4265 Its hexadecimal value is: 4267 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 4268 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 4269 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 4270 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 4271 49286651 ECE65381 FFFFFFFF FFFFFFFF 4273 The generator is 2. 4275 B.3 Group 3 - 155 Bit EC2N 4277 This group is assigned id 3 (three). The curve is based on the Galois 4278 Field GF[2^155]. The field size is 155. The irreducible polynomial 4279 for the field is: 4280 u^155 + u^62 + 1. 4281 The equation for the elliptic curve is: 4283 y^2 + xy = x^3 + ax^2 + b. 4285 Field Size: 155 4286 Group Prime/Irreducible Polynomial: 4287 0x0800000000000000000000004000000000000001 4288 Group Generator One: 0x7b 4289 Group Curve A: 0x0 4290 Group Curve B: 0x07338f 4291 Group Order: 0x0800000000000000000057db5698537193aef944 4293 The data in the KE payload when using this group is the value x from 4294 the solution (x,y), the point on the curve chosen by taking the 4295 randomly chosen secret Ka and computing Ka*P, where * is the 4296 repetition of the group addition and double operations, P is the 4297 curve point with x coordinate equal to generator 1 and the y 4298 coordinate determined from the defining equation. The equation of 4299 curve is implicitly known by the Group Type and the A and B 4300 coefficients. There are two possible values for the y coordinate; 4301 either one can be used successfully (the two parties need not agree 4302 on the selection). 4304 B.4 Group 4 - 185 Bit EC2N 4306 This group is assigned id 4 (four). The curve is based on the Galois 4307 Field GF[2^185]. The field size is 185. The irreducible polynomial 4308 for the field is: 4309 u^185 + u^69 + 1. 4311 The equation for the elliptic curve is: 4312 y^2 + xy = x^3 + ax^2 + b. 4314 Field Size: 185 4315 Group Prime/Irreducible Polynomial: 4316 0x020000000000000000000000000000200000000000000001 4317 Group Generator One: 0x18 4318 Group Curve A: 0x0 4319 Group Curve B: 0x1ee9 4320 Group Order: 0x01ffffffffffffffffffffffdbf2f889b73e484175f94ebc 4322 The data in the KE payload when using this group will be identical to 4323 that as when using Oakley Group 3 (three). 4325 Change History (To be removed from RFC) 4327 H.1 Changes from IKEv2-00 to IKEv2-01 February 2002 4329 1) Changed Appendix B to specify the encryption and authentication 4330 processing for IKE rather than referencing ESP. Simplified the format 4331 by removing idiosyncrasies not needed for IKE. 4333 2) Added option for authentication via a shared secret key. 4335 3) Specified different keys in the two directions of IKE messages. 4336 Removed requirement of different cookies in the two directions since 4337 now no longer required. 4339 4) Change the quantities signed by the two ends in AUTH fields to 4340 assure the two parties sign different quantities. 4342 5) Changed reference to AES to AES_128. 4344 6) Removed requirement that Diffie-Hellman be repeated when rekeying 4345 IKE_SA. 4347 7) Fixed typos. 4349 8) Clarified requirements around use of port 500 at the remote end in 4350 support of NAT. 4352 9) Clarified required ordering for payloads. 4354 10) Suggested mechanisms for avoiding DoS attacks. 4356 11) Removed claims in some places that the first phase 2 piggybacked 4357 on phase 1 was optional. 4359 H.2 Changes from IKEv2-01 to IKEv2-02 April 2002 4361 1) Moved the Initiator CERTREQ payload from message 1 to message 3. 4363 2) Added a second optional ID payload in message 3 for the Initiator 4364 to name a desired Responder to support the case where multiple named 4365 identities are served by a single IP address. 4367 3) Deleted the optimization whereby the Diffie-Hellman group did not 4368 need to be specified in phase 2 if it was the same as in phase 1 (it 4369 complicated the design with no meaningful benefit). 4371 4) Added a section on the implications of reusing Diffie-Hellman 4372 expontentials 4373 5) Changed the specification of sequence numbers to being at 0 in 4374 both directions. 4376 6) Many editorial changes and corrections, the most significant being 4377 a global replace of "byte" with "octet". 4379 H.3 Changes from IKEv2-02 to IKEv2-03 October 2002 4381 1) Reorganized the document moving introductory material to the 4382 front. 4384 2) Simplified the specification of Traffic Selectors to allow only 4385 IPv4 and IPv6 address ranges, as was done in the JFK spec. 4387 3) Fixed the problem brought up by David Faucher with the fix 4388 suggested by Valery Smyslov. If Bob needs to narrow the selector 4389 range, but has more than one matching narrower range, then if Alice's 4390 first selector is a single address pair, Bob chooses the range that 4391 encompasses that. 4393 4) To harmonize with the JFK spec, changed the exchange so that the 4394 initial exchange can be completed in four messages even if the 4395 responder must invoke an anti-clogging defense and the initiator 4396 incorrectly anticipates the responder's choice of Diffie-Hellman 4397 group. 4399 5) Replaced the hierarchical SA payload with a simplified version 4400 that only negotiates suites of cryptographic algorithms. 4402 H.4 Changes from IKEv2-03 to IKEv2-04 January 2003 4404 1) Integrated NAT traversal changes (including Appendix A). 4406 2) Moved the anti-clogging token (cookie) from the SPI to a NOTIFY 4407 payload; changed negotiation back to 6 messages when a cookie is 4408 needed. 4410 3) Made capitalization of IKE_SA and CHILD_SA consistent. 4412 4) Changed how IPComp was negotiated. 4414 5) Added usage scenarios. 4416 6) Added configuration payload for acquiring internal addresses on 4417 remote networks. 4419 7) Added negotiation of tunnel vs transport mode. 4421 H.5 Changes from IKEv2-04 to IKEv2-05 February 2003 4423 1) Shortened Abstract 4425 2) Moved NAT Traversal from Appendix to section 2. Moved changes from 4426 IKEv2 to Appendix A. Renumbered sections. 4428 3) Made language more consistent. Removed most references to Phase 1 4429 and Phase 2. 4431 4) Made explicit the requirements for support of NAT Traversal. 4433 5) Added support for Extended Authentication Protocol methods. 4435 6) Added Response bit to message header. 4437 7) Made more explicit the encoding of Diffie-Hellman numbers in key 4438 expansion algorithms. 4440 8) Added ID payloads to AUTH payload computation. 4442 9) Expanded set of defined cryptographic suites. 4444 10) Added text for MUST/SHOULD support for ID payloads. 4446 11) Added new certificate formats and added MUST/SHOULD text. 4448 12) Clarified use of CERTREQ. 4450 13) Deleted "MUST SUPPORT" column in CP payload specification (it was 4451 inconsistent with surrounding text). 4453 14) Extended and clarified Conformance Requirements section, 4454 including specification of a minimal implementation. 4456 15) Added text to specify ECN handling. 4458 H.6 Changes from IKEv2-05 to IKEv2-06 March 2003 4460 1) Changed the suite based crypto negotiation back to ala carte. 4462 2) Eliminated some awkward page breaks, typographical errors, and 4463 other formatting issues. 4465 3) Tightened language describing cryptographic strength. 4467 4) Added references. 4469 5) Added more specific error codes. 4471 6) Added rationale for unintuitive key generation hash with shared 4472 secret based authentication. 4474 7) Changed the computation of the authenticating AUTH payload as 4475 proposed by Hugo Krawczyk. 4477 8) Changed the dashes (-) to underscores (_) in the names of fields 4478 and constants. 4480 H.7 Changes from IKEv2-06 to IKEv2-07 April 2003 4482 1) Added a list of payload types to section 3.2. 4484 2) Clarified use of SET_WINDOW_SIZE Notify payload. 4486 3) Removed references to COOKIE_REQUIRED Notify payload. 4488 4) Specified how to use a prf with a fixed key size. 4490 5) Removed g^ir from data processed by prf+. 4492 6) Strengthened cautions against using passwords as shared keys. 4494 7) Renamed Protocol_id field SECURITY_PROTOCOL_ID when it is not the 4495 Protocol ID from IP, and changed its values for consistency with 4496 IKEv1. 4498 8) Clarified use of ID payload in access control decisions. 4500 9) Gave IDr and TSr their own payload type numbers. 4502 10) Added Intellectual Property rights section. 4504 11) Clarified some issues in NAT Traversal. 4506 H.8 Changes from IKEv2-07 to IKEv2-08 May 2003 4508 1) Numerous editorial corrections and clarifications. 4510 2) Renamed Gateway to Security Gateway. 4512 3) Made explicit that the ability to rekey SAs without restarting IKE 4513 was optional. 4515 4) Removed last references to MUST and SHOULD ciphersuites. 4517 5) Changed examples to "example.com". 4519 6) Changed references to status codes to status types. 4521 7) Simplified IANA Considerations section 4523 8) Updated References 4525 H.9 Changes from IKEv2-08 to IKEv2-09 August 2003 4527 1) Numerous editorial corrections and clarifications. 4529 2) Added REKEY_SA notify payload to the first message of a 4530 CREATE_CHILD_SA exchange if the new exchange was rekeying an existing 4531 SA. 4533 3) Renamed AES_ENCR128 to AES_ENCR and made it take a single 4534 parameter that is the key size (which may be 128, 192, or 256 bits). 4536 4) Clarified when a newly created SA is useable. 4538 5) Added additional text to section 2.23 specifying how to negotiate 4539 NAT Traversal. 4541 6) Replaced specification of ECN handling with a reference to 4542 [RFC2401bis]. 4544 7) Renumbered payloads so that numbers would not collide with IKEv1 4545 payload numbers in hopes of making code implementing both protocols 4546 simpler. 4548 8) Expanded the Transform ID field (also referred to as Diffie- 4549 Hellman group number) from one byte to two bytes. 4551 9) Removed ability to negotiate Diffie-Hellman groups by explicitly 4552 passing parameters. They must now be negotiated using Transform IDs. 4554 10) Renumbered status codes to be contiguous. 4556 11) Specified the meaning of the "Port" fields in Traffic Selectors 4557 when the ICMP protocol is being used. 4559 12) Removed the specification of D-H Group #5 since it is already 4560 specified in [ADDGROUP]. 4562 H.10 Changes from IKEv2-09 to IKEv2-10 August 2003 4564 1) Numerous boilerplate and formatting corrections to comply with RFC 4565 Editorial Guidelines and procedures. 4567 2) Fixed five typographical errors. 4569 3) Added a sentence to the end of "Security considerations" 4570 discouraging the use of non-key-generating EAP mechanisms. 4572 H.11 Changes from IKEv2-10 to IKEv2-11 October 2003 4574 1) Added SHOULD NOT language concerning use of non-key-generating EAP 4575 authentication methods and added reference [EAPMITM]. 4577 2) Clarified use of parallel SAs with identical traffic selectors for 4578 purposes of QoS handling. 4580 3) Fixed description of ECN handling to make normative references to 4581 [RFC 2401bis] and [RFC 3168]. 4583 4) Fixed two typos in the description of NAT traversal. 4585 5) Added specific ASN.1 encoding of certificate bundles in section 4586 3.6. 4588 Editor's Address 4590 Charlie Kaufman 4591 IBM 4592 5 Technology Park Drive 4593 Westford, MA 01886 4594 1-978-399-5000 4596 charlie_kaufman@notesdev.ibm.com 4598 Full Copyright Statement 4600 "Copyright (C) The Internet Society (2003). All Rights Reserved. 4602 This document and translations of it may be copied and furnished to 4603 others, and derivative works that comment on or otherwise explain it 4604 or assist in its implementation may be prepared, copied, published 4605 and distributed, in whole or in part, without restriction of any 4606 kind, provided that the above copyright notice and this paragraph are 4607 included on all such copies and derivative works. However, this 4608 document itself may not be modified in any way, such as by removing 4609 the copyright notice or references to the Internet Society or other 4610 Internet organizations, except as needed for the purpose of 4611 developing Internet standards in which case the procedures for 4612 copyrights defined in the Internet Standards process must be 4613 followed, or as required to translate it into languages other than 4614 English. 4616 The limited permissions granted above are perpetual and will not be 4617 revoked by the Internet Society or its successors or assigns. 4619 This document and the information contained herein is provided on an 4620 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 4621 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 4622 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 4623 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 4624 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 4626 Acknowledgement 4628 Funding for the RFC Editor function is currently provided by the 4629 Internet Society. 4631 Expiration 4633 This Internet-Draft (draft-ietf-ipsec-ikev2-10.txt) expires in 4634 February 2004.