idnits 2.17.1 draft-ietf-ipsec-ikev2-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 4790. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4801. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4808. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4814. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 4782), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 105 longer pages, the longest (page 98) being 83 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 105 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 4416 has weird spacing: '... The equati...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A fully-qualified domain name string. An example of a ID_FQDN is, "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 (March 22, 2004) is 7312 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2406' is mentioned on line 148, but not defined ** Obsolete undefined reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) == Missing Reference: 'RFC2402' is mentioned on line 148, but not defined ** Obsolete undefined reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) == Missing Reference: 'CERTREQ' is mentioned on line 1408, but not defined == Missing Reference: 'N' is mentioned on line 428, but not defined == Missing Reference: 'KEi' is mentioned on line 428, but not defined == Missing Reference: 'KEr' is mentioned on line 449, but not defined == Missing Reference: 'CP' is mentioned on line 526, but not defined == Missing Reference: 'RFC 2522' is mentioned on line 800, but not defined == Missing Reference: 'RFC 2983' is mentioned on line 1012, but not defined == Missing Reference: 'RFC 2401' is mentioned on line 1820, but not defined ** Obsolete undefined reference: RFC 2401 (Obsoleted by RFC 4301) -- Looks like a reference, but probably isn't: '0' on line 2748 -- Looks like a reference, but probably isn't: '1' on line 2749 == Missing Reference: 'RFC 3168' is mentioned on line 4686, but not defined == Unused Reference: 'ESPCBC' is defined on line 4124, but no explicit reference was found in the text == Unused Reference: 'RFC3280' is defined on line 4143, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 4148, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 4151, but no explicit reference was found in the text == Unused Reference: 'DES' is defined on line 4156, but no explicit reference was found in the text == Unused Reference: 'DH' is defined on line 4160, but no explicit reference was found in the text == Unused Reference: 'DSS' is defined on line 4167, but no explicit reference was found in the text == Unused Reference: 'HC98' is defined on line 4175, but no explicit reference was found in the text == Unused Reference: 'IDEA' is defined on line 4178, but no explicit reference was found in the text == Unused Reference: 'Ker01' is defined on line 4193, but no explicit reference was found in the text == Unused Reference: 'KBC96' is defined on line 4196, but no explicit reference was found in the text == Unused Reference: 'MD5' is defined on line 4203, but no explicit reference was found in the text == Unused Reference: 'MSST98' is defined on line 4206, but no explicit reference was found in the text == Unused Reference: 'PKCS1' is defined on line 4216, but no explicit reference was found in the text == Unused Reference: 'PK01' is defined on line 4219, but no explicit reference was found in the text == Unused Reference: 'Pip98' is defined on line 4223, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 4232, but no explicit reference was found in the text == Unused Reference: 'RFC2474' is defined on line 4235, but no explicit reference was found in the text == Unused Reference: 'RFC2475' is defined on line 4240, but no explicit reference was found in the text == Unused Reference: 'RFC2522' is defined on line 4244, but no explicit reference was found in the text == Unused Reference: 'RFC2983' is defined on line 4247, but no explicit reference was found in the text == Unused Reference: 'RFC3715' is defined on line 4250, but no explicit reference was found in the text == Unused Reference: 'RSA' is defined on line 4254, but no explicit reference was found in the text == Unused Reference: 'SHA' is defined on line 4259, but no explicit reference was found in the text == Unused Reference: 'SKEME' is defined on line 4269, 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) == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-udp-encaps-08 ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. 'HC98') (Obsoleted by RFC 4306) -- 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: 18 errors (**), 0 flaws (~~), 47 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Charlie Kaufman, Editor 2 draft-ietf-ipsec-ikev2-13.txt 3 Obsoletes: 2407, 2408, 2409 March 22, 2004 4 Expires: September 2004 6 Internet Key Exchange (IKEv2) Protocol 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of Section 10 of RFC2026. Internet-Drafts are working documents of 12 the Internet Engineering Task Force (IETF), its areas, and its 13 working groups. Note that other groups may also distribute working 14 documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/1id-abstracts.html 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html 27 This document is a submission by the IPSEC Working Group of the 28 Internet Engineering Task Force (IETF). Comments should be submitted 29 to the ipsec@lists.tislabs.com mailing list. 31 Distribution of this memo is unlimited. 33 This Internet-Draft expires in September 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This document describes version 2 of the Internet Key Exchange (IKE) 42 protocol. IKE is a component of IPsec used for performing mutual 43 authentication and establishing and maintaining security 44 associations. 46 This version of the IKE specification combines the contents of what 47 were previously separate documents, including ISAKMP (RFC 2408), IKE 48 (RFC 2409), the Internet DOI (RFC 2407), NAT Traversal, Legacy 49 authentication, and remote address acquisition. 51 Version 2 of IKE does not interoperate with version 1, but it has 52 enough of the header format in common that both versions can 53 unambiguously run over the same UDP port. 55 Table of Contents 57 1 Introduction...............................................3 58 1.1 Usage Scenarios..........................................5 59 1.2 The Initial Exchange.....................................7 60 1.3 The CREATE_CHILD_SA Exchange.............................9 61 1.4 The INFORMATIONAL Exchange..............................10 62 1.5 Informational Messages outside of an IKE_SA.............12 63 2 IKE Protocol Details and Variations.......................12 64 2.1 Use of Retransmission Timers............................12 65 2.2 Use of Sequence Numbers for Message ID..................13 66 2.3 Window Size for overlapping requests....................13 67 2.4 State Synchronization and Connection Timeouts...........14 68 2.5 Version Numbers and Forward Compatibility...............16 69 2.6 Cookies.................................................17 70 2.7 Cryptographic Algorithm Negotiation.....................19 71 2.8 Rekeying................................................20 72 2.9 Traffic Selector Negotiation............................23 73 2.10 Nonces.................................................25 74 2.11 Address and Port Agility...............................25 75 2.12 Reuse of Diffie-Hellman Exponentials...................25 76 2.13 Generating Keying Material.............................26 77 2.14 Generating Keying Material for the IKE_SA..............27 78 2.15 Authentication of the IKE_SA...........................28 79 2.16 Extended Authentication Protocol Methods...............29 80 2.17 Generating Keying Material for CHILD_SAs...............31 81 2.18 Rekeying IKE_SAs using a CREATE_CHILD_SA exchange......32 82 2.19 Requesting an internal address on a remote network.....32 83 2.20 Requesting a Peer's Version............................33 84 2.21 Error Handling.........................................34 85 2.22 IPComp.................................................35 86 2.23 NAT Traversal..........................................36 87 2.24 ECN (Explicit Congestion Notification).................39 88 3 Header and Payload Formats................................39 89 3.1 The IKE Header..........................................39 90 3.2 Generic Payload Header..................................42 91 3.3 Security Association Payload............................43 92 3.4 Key Exchange Payload....................................53 93 3.5 Identification Payloads.................................54 94 3.6 Certificate Payload.....................................56 95 3.7 Certificate Request Payload.............................59 96 3.8 Authentication Payload..................................60 97 3.9 Nonce Payload...........................................61 98 3.10 Notify Payload.........................................62 99 3.11 Delete Payload.........................................69 100 3.12 Vendor ID Payload......................................70 101 3.13 Traffic Selector Payload...............................71 102 3.14 Encrypted Payload......................................74 103 3.15 Configuration Payload..................................75 104 3.16 Extended Authentication Protocol (EAP) Payload.........80 105 4 Conformance Requirements..................................82 106 5 Security Considerations...................................84 107 6 IANA Considerations.......................................86 108 7 Acknowledgements..........................................87 109 8 References................................................87 110 8.1 Normative References....................................87 111 8.2 Informative References..................................88 112 Appendix A: Summary of Changes from IKEv1...................92 113 Appendix B: Diffie-Hellman Groups...........................94 114 Change History (To be removed from RFC).....................96 115 Editor's Address...........................................104 116 Full Copyright Statement...................................104 117 Intellectual Property Statement............................104 119 Requirements Terminology 121 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 122 "MAY" that appear in this document are to be interpreted as described 123 in [Bra97]. 125 The term "Expert Review" is to be interpreted as defined in 126 [RFC2434]. 128 1 Introduction 130 IP Security (IPsec) provides confidentiality, data integrity, access 131 control, and data source authentication to IP datagrams. These 132 services are provided by maintaining shared state between the source 133 and the sink of an IP datagram. This state defines, among other 134 things, the specific services provided to the datagram, which 135 cryptographic algorithms will be used to provide the services, and 136 the keys used as input to the cryptographic algorithms. 138 Establishing this shared state in a manual fashion does not scale 139 well. Therefore a protocol to establish this state dynamically is 140 needed. This memo describes such a protocol-- the Internet Key 141 Exchange (IKE). This is version 2 of IKE. Version 1 of IKE was 142 defined in RFCs 2407, 2408, and 2409. This single document is 143 intended to replace all three of those RFCs. 145 IKE performs mutual authentication between two parties and 146 establishes an IKE security association that includes shared secret 147 information that can be used to efficiently establish SAs for ESP 148 [RFC2406] and/or AH [RFC2402] and a set of cryptographic algorithms 149 to be used by the SAs to protect the traffic that they carry. In 150 this document, the term "suite" or "cryptographic suite" refers to a 151 complete set of algorithms used to protect an SA. An initiator 152 proposes one or more suites by listing supported algorithms that can 153 be combined into suites in a mix and match fashion. IKE can also 154 negotiate use of IPComp [IPCOMP] in connection with an ESP and/or AH 155 SA. We call the IKE SA an "IKE_SA". The SAs for ESP and/or AH that 156 get set up through that IKE_SA we call "CHILD_SA"s. 158 All IKE communications consist of pairs of messages: a request and a 159 response. The pair is called an "exchange". We call the first 160 messages establishing an IKE_SA IKE_SA_INIT and IKE_AUTH exchanges 161 and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL 162 exchanges. In the common case, there is a single IKE_SA_INIT exchange 163 and a single IKE_AUTH exchange (a total of four messages) to 164 establish the IKE_SA and the first CHILD_SA. In exceptional cases, 165 there may be more than one of each of these exchanges. In all cases, 166 all IKE_SA_INIT exchanges MUST complete before any other exchange 167 type, then all IKE_AUTH exchanges MUST complete, and following that 168 any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur 169 in any order. In some scenarios, only a single CHILD_SA is needed 170 between the IPsec endpoints and therefore there would be no 171 additional exchanges. Subsequent exchanges MAY be used to establish 172 additional CHILD_SAs between the same authenticated pair of endpoints 173 and to perform housekeeping functions. 175 IKE message flow always consists of a request followed by a response. 176 It is the responsibility of the requester to ensure reliability. If 177 the response is not received within a timeout interval, the requester 178 needs to retransmit the request (or abandon the connection). 180 The first request/response of an IKE session negotiates security 181 parameters for the IKE_SA, sends nonces, and sends Diffie-Hellman 182 values. We call the initial exchange IKE_SA_INIT (request and 183 response). 185 The second request/response, which we'll call IKE_AUTH transmits 186 identities, proves knowledge of the secrets corresponding to the two 187 identities, and sets up an SA for the first (and often only) AH 188 and/or ESP CHILD_SA. 190 The types of subsequent exchanges are CREATE_CHILD_SA (which creates 191 a CHILD_SA), and INFORMATIONAL (which deletes an SA, reports error 192 conditions, or does other housekeeping). Every request requires a 193 response. An INFORMATIONAL request with no payloads is commonly used 194 as a check for liveness. These subsequent exchanges cannot be used 195 until the initial exchanges have completed. 197 In the description that follows, we assume that no errors occur. 198 Modifications to the flow should errors occur are described in 199 section 2.21. 201 1.1 Usage Scenarios 203 IKE is expected to be used to negotiate ESP and/or AH SAs in a number 204 of different scenarios, each with its own special requirements. 206 1.1.1 Security Gateway to Security Gateway Tunnel 208 +-+-+-+-+-+ +-+-+-+-+-+ 209 ! ! IPsec ! ! 210 Protected !Tunnel ! Tunnel !Tunnel ! Protected 211 Subnet <-->!Endpoint !<---------->!Endpoint !<--> Subnet 212 ! ! ! ! 213 +-+-+-+-+-+ +-+-+-+-+-+ 215 Figure 1: Security Gateway to Security Gateway Tunnel 217 In this scenario, neither endpoint of the IP connection implements 218 IPsec, but network nodes between them protect traffic for part of the 219 way. Protection is transparent to the endpoints, and depends on 220 ordinary routing to send packets through the tunnel endpoints for 221 processing. Each endpoint would announce the set of addresses 222 "behind" it, and packets would be sent in Tunnel Mode where the inner 223 IP header would contain the IP addresses of the actual endpoints. 225 1.1.2 Endpoint to Endpoint Transport 227 +-+-+-+-+-+ +-+-+-+-+-+ 228 ! ! IPsec ! ! 229 !Protected! Tunnel !Protected! 230 !Endpoint !<---------------------------------------->!Endpoint ! 231 ! ! ! ! 232 +-+-+-+-+-+ +-+-+-+-+-+ 234 Figure 2: Endpoint to Endpoint 236 In this scenario, both endpoints of the IP connection implement 237 IPsec. These endpoints may implement application layer access 238 controls based on the authenticated identities of the participants. 239 Transport mode will commonly be used with no inner IP header. If 240 there is an inner IP header, the inner addresses will be the same as 241 the outer addresses. A single pair of addresses will be negotiated 242 for packets to be protected by this SA. 244 It is possible in this scenario that one or both of the protected 245 endpoints will be behind a network address translation (NAT) node, in 246 which case the tunnelled packets will have to be UDP encapsulated so 247 that port numbers in the UDP headers can be used to identify 248 individual endpoints "behind" the NAT (see section 2.23). 250 1.1.3 Endpoint to Security Gateway Transport 252 +-+-+-+-+-+ +-+-+-+-+-+ 253 ! ! IPsec ! ! Protected 254 !Protected! Tunnel !Tunnel ! Subnet 255 !Endpoint !<------------------------>!Endpoint !<--- and/or 256 ! ! ! ! Internet 257 +-+-+-+-+-+ +-+-+-+-+-+ 259 Figure 3: Endpoint to Security Gateway Tunnel 261 In this scenario, a protected endpoint (typically a portable roaming 262 computer) connects back to its corporate network through an IPsec 263 protected tunnel. It might use this tunnel only to access information 264 on the corporate network or it might tunnel all of its traffic back 265 through the corporate network in order to take advantage of 266 protection provided by a corporate firewall against Internet based 267 attacks. In either case, the protected endpoint will want an IP 268 address associated with the security gateway so that packets returned 269 to it will go to the security gateway and be tunnelled back. This IP 270 address may be static or may be dynamically allocated by the security 271 gateway. In support of the latter case, IKEv2 includes a mechanism 272 for the initiator to request an IP address owned by the security 273 gateway for use for the duration of its SA. 275 In this scenario, packets will use tunnel mode. On each packet from 276 the protected endpoint, the outer IP header will contain the source 277 IP address associated with its current location (i.e., the address 278 that will get traffic routed to the endpoint directly) while the 279 inner IP header will contain the source IP address assigned by the 280 security gateway (i.e., the address that will get traffic routed to 281 the security gateway for forwarding to the endpoint). The outer 282 destination address will always be that of the security gateway, 283 while the inner destination address will be the ultimate destination 284 for the packet. 286 In this scenario, it is possible that the protected endpoint will be 287 behind a NAT. In that case, the IP address as seen by the security 288 gateway will not be the same as the IP address sent by the protected 289 endpoint, and packets will have to be UDP encapsulated in order to be 290 routed properly. 292 1.1.4 Other Scenarios 294 Other scenarios are possible, as are nested combinations of the 295 above. One notable example combines aspects of 1.1.1 and 1.1.3. A 296 subnet may make all external accesses through a remote security 297 gateway using an IPsec tunnel, where the addresses on the subnet are 298 routed to the security gateway by the rest of the Internet. An 299 example would be someone's home network being virtually on the 300 Internet with static IP addresses even though connectivity is 301 provided by an ISP that assigns a single dynamically assigned IP 302 address to the user's security gateway (where the static IP addresses 303 and an IPsec relay is provided by a third party located elsewhere). 305 1.2 The Initial Exchanges 307 Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH 308 exchanges (known in IKEv1 as Phase 1). These initial exchanges 309 normally consist of four messages, though in some scenarios that 310 number can grow. All communications using IKE consist of 311 request/response pairs. We'll describe the base exchange first, 312 followed by variations. The first pair of messages (IKE_SA_INIT) 313 negotiate cryptographic algorithms, exchange nonces, and do a Diffie- 314 Hellman exchange. 316 The second pair of messages (IKE_AUTH) authenticate the previous 317 messages, exchange identities and certificates, and establish the 318 first CHILD_SA. Parts of these messages are encrypted and integrity 319 protected with keys established through the IKE_SA_INIT exchange, so 320 the identities are hidden from eavesdroppers and all fields in all 321 the messages are authenticated. 323 In the following description, the payloads contained in the message 324 are indicated by names such as SA. The details of the contents of 325 each payload are described later. Payloads which may optionally 326 appear will be shown in brackets, such as [CERTREQ], would indicate 327 that optionally a certificate request payload can be included. 329 To simplify the descriptions that follow by allowing the use of 330 gender specific personal pronouns, the initiator is assumed to be 331 named "Alice" and the responder "Bob". 333 The initial exchanges are as follows: 335 Initiator Responder 336 ----------- ----------- 337 HDR, SAi1, KEi, Ni --> 339 HDR contains the SPIs, version numbers, and flags of various sorts. 340 The SAi1 payload states the cryptographic algorithms the Initiator 341 supports for the IKE_SA. The KE payload sends the Initiator's 342 Diffie-Hellman value. Ni is the Initiator's nonce. 344 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 346 The Responder chooses a cryptographic suite from the Initiator's 347 offered choices and expresses that choice in the SAr1 payload, 348 completes the Diffie-Hellman exchange with the KEr payload, and sends 349 its nonce in the Nr payload. 351 At this point in the negotiation each party can generate SKEYSEED, 352 from which all keys are derived for that IKE_SA. All but the headers 353 of all the messages that follow are encrypted and integrity 354 protected. The keys used for the encryption and integrity protection 355 are derived from SKEYSEED and are known as SK_e (encryption) and SK_a 356 (authentication, a.k.a. integrity protection). A separate SK_e and 357 SK_a is computed for each direction. In addition to the keys SK_e 358 and SK_a derived from the DH value for protection of the IKE_SA, 359 another quantity SK_d is derived and used for derivation of further 360 keying material for CHILD_SAs. The notation SK { ... } indicates 361 that these payloads are encrypted and integrity protected using that 362 direction's SK_e and SK_a. 364 HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] 365 AUTH, SAi2, TSi, TSr} --> 367 The Initiator asserts her identity with the IDi payload, proves 368 knowledge of the secret corresponding to IDi and integrity protects 369 the contents of the first message using the AUTH payload (see section 370 2.15). She might also send her certificate(s) in CERT payload(s) and 371 a list of her trust anchors in CERTREQ payload(s). If any CERT 372 payloads are included, the first certificate provided MUST contain 373 the public key used to verify the AUTH field. The optional payload 374 IDr enables Alice to specify which of Bob's identities she wants to 375 talk to. This is useful when Bob is hosting multiple identities at 376 the same IP address. She begins negotiation of a CHILD_SA using the 377 SAi2 payload. The final fields (starting with SAi2) are described in 378 the description of the CREATE_CHILD_SA exchange. 380 <-- HDR, SK {IDr, [CERT,] AUTH, 381 SAr2, TSi, TSr} 383 The Responder asserts his identity with the IDr payload, optionally 384 sends one or more certificates (again with the certificate containing 385 the public key used to verify AUTH listed first), authenticates his 386 identity and protects the integrity of the second message with the 387 AUTH payload, and completes negotiation of a CHILD_SA with the 388 additional fields described below in the CREATE_CHILD_SA exchange. 390 The recipients of messages 3 and 4 MUST verify that all signatures 391 and MACs are computed correctly and that the names in the ID payloads 392 correspond to the keys used to generate the AUTH payload. 394 1.3 The CREATE_CHILD_SA Exchange 396 This exchange consists of a single request/response pair, and was 397 referred to as a phase 2 exchange in IKEv1. It MAY be initiated by 398 either end of the IKE_SA after the initial exchanges are completed. 400 All messages following the initial exchange are cryptographically 401 protected using the cryptographic algorithms and keys negotiated in 402 the first two messages of the IKE exchange. These subsequent 403 messages use the syntax of the Encrypted Payload described in section 404 3.14. 406 Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this 407 section the term initiator refers to the endpoint initiating this 408 exchange. The term "Alice" will always refer to the initiator of the 409 outer IKE_SA. 411 A CHILD_SA is created by sending a CREATE_CHILD_SA request. The 412 CREATE_CHILD_SA request MAY optionally contain a KE payload for an 413 additional Diffie-Hellman exchange to enable stronger guarantees of 414 forward secrecy for the CHILD_SA. The keying material for the 415 CHILD_SA is a function of SK_d established during the establishment 416 of the IKE_SA, the nonces exchanged during the CREATE_CHILD_SA 417 exchange, and the Diffie-Hellman value (if KE payloads are included 418 in the CREATE_CHILD_SA exchange). 420 In the CHILD_SA created as part of the initial exchange, a second KE 421 payload and nonce MUST NOT be sent. The nonces from the initial 422 exchange are used in computing the keys for the CHILD_SA. 424 The CREATE_CHILD_SA request contains: 426 Initiator Responder 427 ----------- ----------- 428 HDR, SK {[N], SA, Ni, [KEi], 429 [TSi, TSr]} --> 431 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni 432 payload, optionally a Diffie-Hellman value in the KEi payload, and 433 the proposed traffic selectors in the TSi and TSr payloads. If this 434 CREATE_CHILD_SA exchange is rekeying an existing SA other than the 435 IKE_SA, the leading N payload of type REKEY_SA MUST identify the SA 436 being rekeyed. If this CREATE_CHILD_SA exchange is not rekeying and 437 existing SA, the N payload MUST be omitted. If the SA offers include 438 different Diffie-Hellman groups, KEi MUST be an element of the group 439 the initiator expects the responder to accept. If it guesses wrong, 440 the CREATE_CHILD_SA exchange will fail and it will have to retry with 441 a different KEi. 443 The message following the header is encrypted and the message 444 including the header is integrity protected using the cryptographic 445 algorithms negotiated for the IKE_SA. 447 The CREATE_CHILD_SA response contains: 449 <-- HDR, SK {SA, Nr, [KEr], 450 [TSi, TSr]} 452 The responder replies (using the same Message ID to respond) with the 453 accepted offer in an SA payload, and a Diffie-Hellman value in the 454 KEr payload if KEi was included in the request and the selected 455 cryptographic suite includes that group. If the responder chooses a 456 cryptographic suite with a different group, it MUST reject the 457 request. The initiator SHOULD repeat the request, but now with a KEi 458 payload from the group the responder selected. 460 The traffic selectors for traffic to be sent on that SA are specified 461 in the TS payloads, which may be a subset of what the initiator of 462 the CHILD_SA proposed. Traffic selectors are omitted if this 463 CREATE_CHILD_SA request is being used to change the key of the 464 IKE_SA. 466 1.4 The INFORMATIONAL Exchange 468 At various points during the operation of an IKE_SA, peers may desire 469 to convey control messages to each other regarding errors or 470 notifications of certain events. To accomplish this IKE defines an 471 INFORMATIONAL exchange. INFORMATIONAL exchanges MAY ONLY occur after 472 the initial exchanges and are cryptographically protected with the 473 negotiated keys. 475 Control messages that pertain to an IKE_SA MUST be sent under that 476 IKE_SA. Control messages that pertain to CHILD_SAs MUST be sent under 477 the protection of the IKE_SA which generated them (or its successor 478 if the IKE_SA was replaced for the purpose of rekeying). 480 Messages in an INFORMATIONAL Exchange contain zero or more 481 Notification, Delete, and Configuration payloads. The Recipient of an 482 INFORMATIONAL Exchange request MUST send some response (else the 483 Sender will assume the message was lost in the network and will 484 retransmit it). That response MAY be a message with no payloads. The 485 request message in an INFORMATIONAL Exchange MAY also contain no 486 payloads. This is the expected way an endpoint can ask the other 487 endpoint to verify that it is alive. 489 ESP and AH SAs always exist in pairs, with one SA in each direction. 490 When an SA is closed, both members of the pair MUST be closed. When 491 SAs are nested, as when data (and IP headers if in tunnel mode) are 492 encapsulated first with IPComp, then with ESP, and finally with AH 493 between the same pair of endpoints, all of the SAs MUST be deleted 494 together. Each endpoint MUST close its incoming SAs and allow the 495 other endpoint to close the other SA in each pair. To delete an SA, 496 an INFORMATIONAL Exchange with one or more delete payloads is sent 497 listing the SPIs (as they would be expected in the headers of inbound 498 packets) of the SAs to be deleted. The recipient MUST close the 499 designated SAs. Normally, the reply in the INFORMATIONAL Exchange 500 will contain delete payloads for the paired SAs going in the other 501 direction. There is one exception. If by chance both ends of a set 502 of SAs independently decide to close them, each may send a delete 503 payload and the two requests may cross in the network. If a node 504 receives a delete request for SAs for which it has already issued a 505 delete request, it MUST delete the outgoing SAs while processing the 506 request and the incoming SAs while processing the response. In that 507 case, the responses MUST NOT include delete payloads for the deleted 508 SAs, since that would result in duplicate deletion and could in 509 theory delete the wrong SA. 511 A node SHOULD regard half closed connections as anomalous and audit 512 their existence should they persist. Note that this specification 513 nowhere specifies time periods, so it is up to individual endpoints 514 to decide how long to wait. A node MAY refuse to accept incoming data 515 on half closed connections but MUST NOT unilaterally close them and 516 reuse the SPIs. If connection state becomes sufficiently messed up, a 517 node MAY close the IKE_SA which will implicitly close all SAs 518 negotiated under it. It can then rebuild the SAs it needs on a clean 519 base under a new IKE_SA. 521 The INFORMATIONAL Exchange is defined as: 523 Initiator Responder 524 ----------- ----------- 525 HDR, SK {[N,] [D,] [CP,] ...} --> 526 <-- HDR, SK {[N,] [D,] [CP], ...} 528 The processing of an INFORMATIONAL Exchange is determined by its 529 component payloads. 531 1.5 Informational Messages outside of an IKE_SA 533 If a packet arrives with an unrecognized SPI, it could be because the 534 receiving node has recently crashed and lost state or because of some 535 other system malfunction or attack. If the receiving node has an 536 active IKE_SA to the IP address from whence the packet came, it MAY 537 send a notification of the wayward packet over that IKE_SA. If it 538 does not, it MAY send an Informational message without cryptographic 539 protection to the source IP address and port to alert it to a 540 possible problem. 542 2 IKE Protocol Details and Variations 544 IKE normally listens and sends on UDP port 500, though IKE messages 545 may also be received on UDP port 4500 with a slightly different 546 format (see section 2.23). Since UDP is a datagram (unreliable) 547 protocol, IKE includes in its definition recovery from transmission 548 errors, including packet loss, packet replay, and packet forgery. IKE 549 is designed to function so long as (1) at least one of a series of 550 retransmitted packets reaches its destination before timing out; and 551 (2) the channel is not so full of forged and replayed packets so as 552 to exhaust the network or CPU capacities of either endpoint. Even in 553 the absence of those minimum performance requirements, IKE is 554 designed to fail cleanly (as though the network were broken). 556 2.1 Use of Retransmission Timers 558 All messages in IKE exist in pairs: a request and a response. The 559 setup of an IKE_SA normally consists of two request/response pairs. 560 Once the IKE_SA is set up, either end of the security association may 561 initiate requests at any time, and there can be many requests and 562 responses "in flight" at any given moment. But each message is 563 labelled as either a request or a response and for each 564 request/response pair one end of the security association is the 565 Initiator and the other is the Responder. 567 For every pair of IKE messages, the Initiator is responsible for 568 retransmission in the event of a timeout. The Responder MUST never 569 retransmit a response unless it receives a retransmission of the 570 request. In that event, the Responder MUST ignore the retransmitted 571 request except insofar as it triggers a retransmission of the 572 response. The Initiator MUST remember each request until it receives 573 the corresponding response. The Responder MUST remember each response 574 until it receives a request whose sequence number is larger than the 575 sequence number in the response plus his window size (see section 576 2.3). 578 IKE is a reliable protocol, in the sense that the Initiator MUST 579 retransmit a request until either it receives a corresponding reply 580 OR it deems the IKE security association to have failed and it 581 discards all state associated with the IKE_SA and any CHILD_SAs 582 negotiated using that IKE_SA. 584 2.2 Use of Sequence Numbers for Message ID 586 Every IKE message contains a Message ID as part of its fixed header. 587 This Message ID is used to match up requests and responses, and to 588 identify retransmissions of messages. 590 The Message ID is a 32 bit quantity, which is zero for the first IKE 591 request in each direction. The IKE_SA initial setup messages will 592 always be numbered 0 and 1. Each endpoint in the IKE Security 593 Association maintains two "current" Message IDs: the next one to be 594 used for a request it initiates and the next one it expects to see in 595 a request from the other end. These counters increment as requests 596 are generated and received. Responses always contain the same message 597 ID as the corresponding request. That means that after the initial 598 exchange, each integer n may appear as the message ID in four 599 distinct messages: The nth request from the original IKE Initiator, 600 the corresponding response, the nth request from the original IKE 601 Responder, and the corresponding response. If the two ends make very 602 different numbers of requests, the Message IDs in the two directions 603 can be very different. There is no ambiguity in the messages, 604 however, because the (I)nitiator and (R)esponse bits in the message 605 header specify which of the four messages a particular one is. 607 Note that Message IDs are cryptographically protected and provide 608 protection against message replays. In the unlikely event that 609 Message IDs grow too large to fit in 32 bits, the IKE_SA MUST be 610 closed. Rekeying an IKE_SA resets the sequence numbers. 612 2.3 Window Size for overlapping requests 614 In order to maximize IKE throughput, an IKE endpoint MAY issue 615 multiple requests before getting a response to any of them if the 616 other endpoint has indicated its ability to handle such requests. For 617 simplicity, an IKE implementation MAY choose to process requests 618 strictly in order and/or wait for a response to one request before 619 issuing another. Certain rules must be followed to assure 620 interoperability between implementations using different strategies. 622 After an IKE_SA is set up, either end can initiate one or more 623 requests. These requests may pass one another over the network. An 624 IKE endpoint MUST be prepared to accept and process a request while 625 it has a request outstanding in order to avoid a deadlock in this 626 situation. An IKE endpoint SHOULD be prepared to accept and process 627 multiple requests while it has a request outstanding. 629 An IKE endpoint MUST wait for a response to each of its messages 630 before sending a subsequent message unless it has received a 631 SET_WINDOW_SIZE Notify message from its peer informing it that the 632 peer is prepared to maintain state for multiple outstanding messages 633 in order to allow greater throughput. 635 An IKE endpoint MUST NOT exceed the peer's stated window size for 636 transmitted IKE requests. In other words, if Bob stated his window 637 size is N, then when Alice needs to make a request X, she MUST wait 638 until she has received responses to all requests up through request 639 X-N. An IKE endpoint MUST keep a copy of (or be able to regenerate 640 exactly) each request it has sent until it receives the corresponding 641 response. An IKE endpoint MUST keep a copy of (or be able to 642 regenerate exactly) the number of previous responses equal to its 643 declared window size in case its response was lost and the Initiator 644 requests its retransmission by retransmitting the request. 646 An IKE endpoint supporting a window size greater than one SHOULD be 647 capable of processing incoming requests out of order to maximize 648 performance in the event of network failures or packet reordering. 650 2.4 State Synchronization and Connection Timeouts 652 An IKE endpoint is allowed to forget all of its state associated with 653 an IKE_SA and the collection of corresponding CHILD_SAs at any time. 654 This is the anticipated behavior in the event of an endpoint crash 655 and restart. It is important when an endpoint either fails or 656 reinitializes its state that the other endpoint detect those 657 conditions and not continue to waste network bandwidth by sending 658 packets over discarded SAs and having them fall into a black hole. 660 Since IKE is designed to operate in spite of Denial of Service (DoS) 661 attacks from the network, an endpoint MUST NOT conclude that the 662 other endpoint has failed based on any routing information (e.g., 663 ICMP messages) or IKE messages that arrive without cryptographic 664 protection (e.g., Notify messages complaining about unknown SPIs). An 665 endpoint MUST conclude that the other endpoint has failed only when 666 repeated attempts to contact it have gone unanswered for a timeout 667 period or when a cryptographically protected INITIAL_CONTACT 668 notification is received on a different IKE_SA to the same 669 authenticated identity. An endpoint SHOULD suspect that the other 670 endpoint has failed based on routing information and initiate a 671 request to see whether the other endpoint is alive. To check whether 672 the other side is alive, IKE specifies an empty INFORMATIONAL message 673 that (like all IKE requests) requires an acknowledgment. If a 674 cryptographically protected message has been received from the other 675 side recently, unprotected notifications MAY be ignored. 676 Implementations MUST limit the rate at which they take actions based 677 on unprotected messages. 679 Numbers of retries and lengths of timeouts are not covered in this 680 specification because they do not affect interoperability. It is 681 suggested that messages be retransmitted at least a dozen times over 682 a period of at least several minutes before giving up on an SA, but 683 different environments may require different rules. If there has only 684 been outgoing traffic on all of the SAs associated with an IKE_SA, it 685 is essential to confirm liveness of the other endpoint to avoid black 686 holes. If no cryptographically protected messages have been received 687 on an IKE_SA or any of its CHILD_SAs recently, the system needs to 688 perform a liveness check in order to prevent sending messages to a 689 dead peer. Receipt of a fresh cryptographically protected message on 690 an IKE_SA or any of its CHILD_SAs assures liveness of the IKE_SA and 691 all of its CHILD_SAs. Note that this places requirements on the 692 failure modes of an IKE endpoint. An implementation MUST NOT continue 693 sending on any SA if some failure prevents it from receiving on all 694 of the associated SAs. If CHILD_SAs can fail independently from one 695 another without the associated IKE_SA being able to send a delete 696 message, then they MUST be negotiated by separate IKE_SAs. 698 There is a Denial of Service attack on the Initiator of an IKE_SA 699 that can be avoided if the Initiator takes the proper care. Since the 700 first two messages of an SA setup are not cryptographically 701 protected, an attacker could respond to the Initiator's message 702 before the genuine Responder and poison the connection setup attempt. 703 To prevent this, the Initiator MAY be willing to accept multiple 704 responses to its first message, treat each as potentially legitimate, 705 respond to it, and then discard all the invalid half open connections 706 when she receives a valid cryptographically protected response to any 707 one of her requests. Once a cryptographically valid response is 708 received, all subsequent responses should be ignored whether or not 709 they are cryptographically valid. 711 Note that with these rules, there is no reason to negotiate and agree 712 upon an SA lifetime. If IKE presumes the partner is dead, based on 713 repeated lack of acknowledgment to an IKE message, then the IKE SA 714 and all CHILD_SAs set up through that IKE_SA are deleted. 716 An IKE endpoint may at any time delete inactive CHILD_SAs to recover 717 resources used to hold their state. If an IKE endpoint chooses to do 718 so, it MUST send Delete payloads to the other end notifying it of the 719 deletion. It MAY similarly time out the IKE_SA. Closing the IKE_SA 720 implicitly closes all associated CHILD_SAs. In this case, an IKE 721 endpoint SHOULD send a Delete payload indicating that it has closed 722 the IKE_SA. 724 2.5 Version Numbers and Forward Compatibility 726 This document describes version 2.0 of IKE, meaning the major version 727 number is 2 and the minor version number is zero. It is likely that 728 some implementations will want to support both version 1.0 and 729 version 2.0, and in the future, other versions. 731 The major version number should only be incremented if the packet 732 formats or required actions have changed so dramatically that an 733 older version node would not be able to interoperate with a newer 734 version node if it simply ignored the fields it did not understand 735 and took the actions specified in the older specification. The minor 736 version number indicates new capabilities, and MUST be ignored by a 737 node with a smaller minor version number, but used for informational 738 purposes by the node with the larger minor version number. For 739 example, it might indicate the ability to process a newly defined 740 notification message. The node with the larger minor version number 741 would simply note that its correspondent would not be able to 742 understand that message and therefore would not send it. 744 If an endpoint receives a message with a higher major version number, 745 it MUST drop the message and SHOULD send an unauthenticated 746 notification message containing the highest version number it 747 supports. If an endpoint supports major version n, and major version 748 m, it MUST support all versions between n and m. If it receives a 749 message with a major version that it supports, it MUST respond with 750 that version number. In order to prevent two nodes from being tricked 751 into corresponding with a lower major version number than the maximum 752 that they both support, IKE has a flag that indicates that the node 753 is capable of speaking a higher major version number. 755 Thus the major version number in the IKE header indicates the version 756 number of the message, not the highest version number that the 757 transmitter supports. If Alice is capable of speaking versions n, 758 n+1, and n+2, and Bob is capable of speaking versions n and n+1, then 759 they will negotiate speaking n+1, where Alice will set the flag 760 indicating ability to speak a higher version. If they mistakenly 761 (perhaps through an active attacker sending error messages) negotiate 762 to version n, then both will notice that the other side can support a 763 higher version number, and they MUST break the connection and 764 reconnect using version n+1. 766 Note that IKEv1 does not follow these rules, because there is no way 767 in v1 of noting that you are capable of speaking a higher version 768 number. So an active attacker can trick two v2-capable nodes into 769 speaking v1. When a v2-capable node negotiates down to v1, it SHOULD 770 note that fact in its logs. 772 Also for forward compatibility, all fields marked RESERVED MUST be 773 set to zero by a version 2.0 implementation and their content MUST be 774 ignored by a version 2.0 implementation ("Be conservative in what you 775 send and liberal in what you receive"). In this way, future versions 776 of the protocol can use those fields in a way that is guaranteed to 777 be ignored by implementations that do not understand them. 778 Similarly, payload types that are not defined are reserved for future 779 use and implementations of version 2.0 MUST skip over those payloads 780 and ignore their contents. 782 IKEv2 adds a "critical" flag to each payload header for further 783 flexibility for forward compatibility. If the critical flag is set 784 and the payload type is unrecognized, the message MUST be rejected 785 and the response to the IKE request containing that payload MUST 786 include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an 787 unsupported critical payload was included. If the critical flag is 788 not set and the payload type is unsupported, that payload MUST be 789 ignored. 791 While new payload types may be added in the future and may appear 792 interleaved with the fields defined in this specification, 793 implementations MUST send the payloads defined in this specification 794 in the order shown in the figures in section 2 and implementations 795 SHOULD reject as invalid a message with those payloads in any other 796 order. 798 2.6 Cookies 800 The term "cookies" originates with Karn and Simpson [RFC 2522] in 801 Photuris, an early proposal for key management with IPsec, and it has 802 persisted. The ISAKMP fixed message header includes two eight octet 803 fields titled "cookies", and that syntax is used by both IKEv1 and 804 IKEv2 though in IKEv2 they are referred to as the IKE SPI and there 805 is a new separate field in a Notify payload holding the cookie. The 806 initial two eight octet fields in the header are used as a connection 807 identifier at the beginning of IKE packets. Each endpoint chooses one 808 of the two SPIs and SHOULD choose them so as to be unique identifiers 809 of an IKE_SA. An SPI value of zero is special and indicates that the 810 remote SPI value is not yet known by the sender. 812 Unlike ESP and AH where only the recipient's SPI appears in the 813 header of a message, in IKE the sender's SPI is also sent in every 814 message. Since the SPI chosen by the original initiator of the IKE_SA 815 is always sent first, an endpoint with multiple IKE_SAs open that 816 wants to find the appropriate IKE_SA using the SPI it assigned must 817 look at the I(nitiator) Flag bit in the header to determine whether 818 it assigned the first or the second eight octets. 820 In the first message of an initial IKE exchange, the initiator will 821 not know the responder's SPI value and will therefore set that field 822 to zero. 824 An expected attack against IKE is state and CPU exhaustion, where the 825 target is flooded with session initiation requests from forged IP 826 addresses. This attack can be made less effective if an 827 implementation of a responder uses minimal CPU and commits no state 828 to an SA until it knows the initiator can receive packets at the 829 address from which he claims to be sending them. To accomplish this, 830 a responder SHOULD - when it detects a large number of half-open 831 IKE_SAs - reject initial IKE messages unless they contain a Notify 832 payload of type COOKIE. It SHOULD instead send an unprotected IKE 833 message as a response and include COOKIE Notify payload with the 834 cookie data to be returned. Initiators who receive such responses 835 MUST retry the IKE_SA_INIT with a Notify payload of type COOKIE 836 containing the responder supplied cookie data as the first payload 837 and all other payloads unchanged. The initial exchange will then be 838 as follows: 840 Initiator Responder 841 ----------- ----------- 842 HDR(A,0), SAi1, KEi, Ni --> 844 <-- HDR(A,0), N(COOKIE) 846 HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> 848 <-- HDR(A,B), SAr1, KEr, Nr, [CERTREQ] 850 HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,] 851 AUTH, SAi2, TSi, TSr} --> 853 <-- HDR(A,B), SK {IDr, [CERT,] AUTH, 854 SAr2, TSi, TSr} 856 The first two messages do not affect any initiator or responder state 857 except for communicating the cookie. In particular, the message 858 sequence numbers in the first four messages will all be zero and the 859 message sequence numbers in the last two messages will be one. 'A' is 860 the SPI assigned by the initiator, while 'B' is the SPI assigned by 861 the responder. 863 An IKE implementation SHOULD implement its responder cookie 864 generation in such a way as to not require any saved state to 865 recognize its valid cookie when the second IKE_SA_INIT message 866 arrives. The exact algorithms and syntax they use to generate 867 cookies does not affect interoperability and hence is not specified 868 here. The following is an example of how an endpoint could use 869 cookies to implement limited DOS protection. 871 A good way to do this is to set the responder cookie to be: 873 Cookie = | Hash(Ni | IPi | SPIi | ) 875 where is a randomly generated secret known only to the 876 responder and periodically changed and | indicates concatenation. 877 should be changed whenever is 878 regenerated. The cookie can be recomputed when the IKE_SA_INIT 879 arrives the second time and compared to the cookie in the received 880 message. If it matches, the responder knows that SPIr was generated 881 since the last change to and that IPi must be the same as 882 the source address it saw the first time. Incorporating SPIi into the 883 calculation assures that if multiple IKE_SAs are being set up in 884 parallel they will all get different cookies (assuming the initiator 885 chooses unique SPIi's). Incorporating Ni into the hash assures that 886 an attacker who sees only message 2 can't successfully forge a 887 message 3. 889 If a new value for is chosen while there are connections in 890 the process of being initialized, an IKE_SA_INIT might be returned 891 with other than the current . The responder in 892 that case MAY reject the message by sending another response with a 893 new cookie or it MAY keep the old value of around for a 894 short time and accept cookies computed from either one. The 895 responder SHOULD NOT accept cookies indefinitely after is 896 changed, since that would defeat part of the denial of service 897 protection. The responder SHOULD change the value of 898 frequently, especially if under attack. 900 2.7 Cryptographic Algorithm Negotiation 902 The payload type known as "SA" indicates a proposal for a set of 903 choices of IPsec protocols (IKE, ESP, and/or AH) for the SA as well 904 as cryptographic algorithms associated with each protocol. 906 An SA consists of one or more proposals. Each proposal includes one 907 or more protocols (usually one). Each protocol contains one or more 908 transforms - each specifying a cryptographic algorithm. Each 909 transform contains zero or more attributes (attributes are only 910 needed if the transform identifier does not completely specify the 911 cryptographic algorithm). 913 This hierarchical structure was designed to efficiently encode 914 proposals for cryptographic suites when the number of supported 915 suites is large because multiple values are acceptable for multiple 916 transforms. The responder MUST choose a single suite, which MAY be 917 any subset of the SA proposal following the rules below: 919 Each proposal contains one or more protocols. If a proposal is 920 accepted, the SA response MUST contain the same protocols in the 921 same order as the proposal. The responder MUST accept a single 922 proposal or reject them all and return an error. (Example: if a 923 single proposal contains ESP and AH and that proposal is accepted, 924 both ESP and AH MUST be accepted. If ESP and AH are included in 925 separate proposals, the responder MUST accept only one of them). 927 Each IPsec protocol proposal contains one or more transforms. Each 928 transform contains a transform type. The accepted cryptographic 929 suite MUST contain exactly one transform of each type included in 930 the proposal. For example: if an ESP proposal includes transforms 931 ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256, 932 AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain 933 one of the ENCR_ transforms and one of the AUTH_ transforms. Thus 934 six combinations are acceptable. 936 Since Alice sends her Diffie-Hellman value in the IKE_SA_INIT, she 937 must guess at the Diffie-Hellman group that Bob will select from her 938 list of supported groups. If she guesses wrong, Bob will respond 939 with a Notify payload of type INVALID_KE_PAYLOAD indicating the 940 selected group. In this case, Alice MUST retry the IKE_SA_INIT with 941 the corrected Diffie-Hellman group. Alice MUST again propose her full 942 set of acceptable cryptographic suites because the rejection message 943 was unauthenticated and otherwise an active attacker could trick 944 Alice and Bob into negotiating a weaker suite than a stronger one 945 that they both prefer. 947 2.8 Rekeying 949 IKE, ESP, and AH security associations use secret keys which SHOULD 950 only be used for a limited amount of time and to protect a limited 951 amount of data. This limits the lifetime of the entire security 952 association. When the lifetime of a security association expires the 953 security association MUST NOT be used. If there is demand, new 954 security associations MAY be established. Reestablishment of 955 security associations to take the place of ones which expire is 956 referred to as "rekeying". 958 To allow for minimal IPsec implementations, the ability to rekey SAs 959 without restarting the entire IKE_SA is optional. An implementation 960 MAY refuse all CREATE_CHILD_SA requests within an IKE_SA. If an SA 961 has expired or is about to expire and rekeying attempts using the 962 mechanisms described here fail, an implementation MUST close the 963 IKE_SA and any associated CHILD_SAs and then MAY start new ones. 964 Implementations SHOULD support in place rekeying of SAs, since doing 965 so offers better performance and is likely to reduce the number of 966 packets lost during the transition. 968 To rekey a CHILD_SA within an existing IKE_SA, create a new, 969 equivalent SA (see section 2.17 below), and when the new one is 970 established, delete the old one. To rekey an IKE_SA, establish a new 971 equivalent IKE_SA (see section 2.18 below) with the peer to whom the 972 old IKE_SA is shared using a CREATE_CHILD_SA within the existing 973 IKE_SA. An IKE_SA so created inherits all of the original IKE_SA's 974 CHILD_SAs. Use the new IKE_SA for all control messages needed to 975 maintain the CHILD_SAs created by the old IKE_SA, and delete the old 976 IKE_SA. The Delete payload to delete itself MUST be the last request 977 sent over an IKE_SA. 979 SAs SHOULD be rekeyed proactively, i.e., the new SA should be 980 established before the old one expires and becomes unusable. Enough 981 time should elapse between the time the new SA is established and the 982 old one becomes unusable so that traffic can be switched over to the 983 new SA. 985 A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes 986 were negotiated. In IKEv2, each end of the SA is responsible for 987 enforcing its own lifetime policy on the SA and rekeying the SA when 988 necessary. If the two ends have different lifetime policies, the end 989 with the shorter lifetime will end up always being the one to request 990 the rekeying. If an SA bundle has been inactive for a long time and 991 if an endpoint would not initiate the SA in the absence of traffic, 992 the endpoint MAY choose to close the SA instead of rekeying it when 993 its lifetime expires. It SHOULD do so if there has been no traffic 994 since the last time the SA was rekeyed. 996 If the two ends have the same lifetime policies, it is possible that 997 both will initiate a rekeying at the same time (which will result in 998 redundant SAs). To reduce the probability of this happening, the 999 timing of rekeying requests SHOULD be jittered (delayed by a random 1000 amount of time after the need for rekeying is noticed). 1002 This form of rekeying may temporarily result in multiple similar SAs 1003 between the same pairs of nodes. When there are two SAs eligible to 1004 receive packets, a node MUST accept incoming packets through either 1005 SA. If redundant SAs are created though such a collision, the SA 1006 created with the lowest of the four nonces used in the two exchanges 1007 SHOULD be closed by the endpoint that created it. 1009 Note that IKEv2 deliberately allows parallel SAs with the same 1010 traffic selectors between common endpoints. One of the purposes of 1011 this is to support traffic QoS differences among the SAs (see section 1012 4.1 of [RFC 2983]). Hence unlike IKEv1, the combination of the 1013 endpoints and the traffic selectors may not uniquely identify an SA 1014 between those endpoints, so the IKEv1 rekeying heuristic of deleting 1015 SAs on the basis of duplicate traffic selectors SHOULD NOT be used. 1017 The node that initiated the surviving rekeyed SA SHOULD delete the 1018 replaced SA after the new one is established. 1020 There are timing windows - particularly in the presence of lost 1021 packets - where endpoints may not agree on the state of an SA. The 1022 responder to a CREATE_CHILD_SA MUST be prepared to accept messages on 1023 an SA before sending its response to the creation request, so there 1024 is no ambiguity for the initiator. The initiator MAY begin sending on 1025 an SA as soon as it processes the response. The initiator, however, 1026 cannot receive on a newly created SA until it receives and processes 1027 the response to its CREATE_CHILD_SA request. How, then, is the 1028 responder to know when it is OK to send on the newly created SA? 1030 From a technical correctness and interoperability perspective, the 1031 responder MAY begin sending on an SA as soon as it sends its response 1032 to the CREATE_CHILD_SA request. In some situations, however, this 1033 could result in packets unnecessarily being dropped, so an 1034 implementation MAY want to defer such sending. 1036 The responder can be assured that the initiator is prepared to 1037 receive messages on an SA if either (1) it has received a 1038 cryptographically valid message on the new SA, or (2) the new SA 1039 rekeys an existing SA and it receives an IKE request to close the 1040 replaced SA. When rekeying an SA, the responder SHOULD continue to 1041 send requests on the old SA until it one of those events occurs. When 1042 establishing a new SA, the responder MAY defer sending messages on a 1043 new SA until either it receives one or a timeout has occurred. If an 1044 initiator receives a message on an SA for which it has not received a 1045 response to its CREATE_CHILD_SA request, it SHOULD interpret that as 1046 a likely packet loss and retransmit the CREATE_CHILD_SA request. An 1047 initiator MAY send a dummy message on a newly created SA if it has no 1048 messages queued in order to assure the responder that the initiator 1049 is ready to receive messages. 1051 2.9 Traffic Selector Negotiation 1053 When an IP packet is received by an RFC2401 compliant IPsec subsystem 1054 and matches a "protect" selector in its SPD, the subsystem MUST 1055 protect that packet with IPsec. When no SA exists yet it is the task 1056 of IKE to create it. Maintenance of a system's SPD is outside the 1057 scope of IKE (see [PFKEY] for an example protocol), though some 1058 implementations might update their SPD in connection with the running 1059 of IKE (for an example scenario, see section 1.1.3). 1061 Traffic Selector (TS) payloads allow endpoints to communicate some of 1062 the information from their SPD to their peers. TS payloads specify 1063 the selection criteria for packets that will be forwarded over the 1064 newly set up SA. This can serve as a consistency check in some 1065 scenarios to assure that the SPDs are consistent. In others, it 1066 guides the dynamic update of the SPD. 1068 Two TS payloads appear in each of the messages in the exchange that 1069 creates a CHILD_SA pair. Each TS payload contains one or more Traffic 1070 Selectors. Each Traffic Selector consists of an address range (IPv4 1071 or IPv6), a port range, and an IP protocol ID. In support of the 1072 scenario described in section 1.1.3, an initiator may request that 1073 the responder assign an IP address and tell the initiator what it is. 1075 IKEv2 allows the responder to choose a subset of the traffic proposed 1076 by the initiator. This could happen when the configuration of the 1077 two endpoints are being updated but only one end has received the new 1078 information. Since the two endpoints may be configured by different 1079 people, the incompatibility may persist for an extended period even 1080 in the absence of errors. It also allows for intentionally different 1081 configurations, as when one end is configured to tunnel all addresses 1082 and depends on the other end to have the up to date list. 1084 The first of the two TS payloads is known as TSi (Traffic Selector- 1085 initiator). The second is known as TSr (Traffic Selector-responder). 1086 TSi specifies the source address of traffic forwarded from (or the 1087 destination address of traffic forwarded to) the initiator of the 1088 CHILD_SA pair. TSr specifies the destination address of the traffic 1089 forwarded from (or the source address of the traffic forwarded to) 1090 the responder of the CHILD_SA pair. For example, if Alice initiates 1091 the creation of the CHILD_SA pair from Alice to Bob, and wishes to 1092 tunnel all traffic from subnet 10.2.16.* on Alice's side to subnet 1093 10.16.*.* on Bob's side, Alice would include a single traffic 1094 selector in each TS payload. TSi would specify the address range 1095 (10.2.16.0 - 10.2.16.255) and TSr would specify the address range 1096 (10.16.0.0 - 10.16.255.255). Assuming that proposal was acceptable to 1097 Bob, he would send identical TS payloads back. 1099 The Responder is allowed to narrow the choices by selecting a subset 1100 of the traffic, for instance by eliminating or narrowing the range of 1101 one or more members of the set of traffic selectors, provided the set 1102 does not become the NULL set. 1104 It is possible for the Responder's policy to contain multiple smaller 1105 ranges, all encompassed by the Initiator's traffic selector, and with 1106 the Responder's policy being that each of those ranges should be sent 1107 over a different SA. Continuing the example above, Bob might have a 1108 policy of being willing to tunnel those addresses to and from Alice, 1109 but might require that each address pair be on a separately 1110 negotiated CHILD_SA. If Alice generated her request in response to an 1111 incoming packet from 10.2.16.43 to 10.16.2.123, there would be no way 1112 for Bob to determine which pair of addresses should be included in 1113 this tunnel, and he would have to make his best guess or reject the 1114 request with a status of SINGLE_PAIR_REQUIRED. 1116 To enable Bob to choose the appropriate range in this case, if Alice 1117 has initiated the SA due to a data packet, Alice SHOULD include as 1118 the first traffic selector in each of TSi and TSr a very specific 1119 traffic selector including the addresses in the packet triggering the 1120 request. In the example, Alice would include in TSi two traffic 1121 selectors: the first containing the address range (10.2.16.43 - 1122 10.2.16.43) and the source port and IP protocol from the packet and 1123 the second containing (10.2.16.0 - 10.2.16.255) with all ports and IP 1124 protocols. She would similarly include two traffic selectors in TSr. 1126 If Bob's policy does not allow him to accept the entire set of 1127 traffic selectors in Alice's request, but does allow him to accept 1128 the first selector of TSi and TSr, then Bob MUST narrow the traffic 1129 selectors to a subset that includes Alice's first choices. In this 1130 example, Bob might respond with TSi being (10.2.16.43 - 10.2.16.43) 1131 with all ports and IP protocols. 1133 If Alice creates the CHILD_SA pair not in response to an arriving 1134 packet, but rather - say - upon startup, then there may be no 1135 specific addresses Alice prefers for the initial tunnel over any 1136 other. In that case, the first values in TSi and TSr MAY be ranges 1137 rather than specific values, and Bob chooses a subset of Alice's TSi 1138 and TSr that are acceptable to him. If more than one subset is 1139 acceptable but their union is not, Bob MUST accept some subset and 1140 MAY include a Notify payload of type ADDITIONAL_TS_POSSIBLE to 1141 indicate that Alice might want to try again. This case will only 1142 occur when Alice and Bob are configured differently from one another. 1143 If Alice and Bob agree on the granularity of tunnels, she will never 1144 request a tunnel wider than Bob will accept. 1146 2.10 Nonces 1148 The IKE_SA_INIT messages each contain a nonce. These nonces are used 1149 as inputs to cryptographic functions. The CREATE_CHILD_SA request 1150 and the CREATE_CHILD_SA response also contain nonces. These nonces 1151 are used to add freshness to the key derivation technique used to 1152 obtain keys for CHILD_SA, and to ensure creation of strong 1153 pseudorandom bits from the Diffie-Hellman key. Nonces used in IKEv2 1154 MUST be randomly chosen, MUST be at least 128 bits in size, and MUST 1155 be at least half the key size of the negotiated prf. ("prf" refers to 1156 "pseudo-random function", one of the cryptographic algorithms 1157 negotiated in the IKE exchange). If the same random number source is 1158 used for both keys and nonces, care must be taken to ensure that the 1159 latter use does not compromise the former. 1161 2.11 Address and Port Agility 1163 IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and 1164 AH associations for the same IP addresses it runs over. The IP 1165 addresses and ports in the outer header are, however, not themselves 1166 cryptographically protected, and IKE is designed to work even through 1167 Network Address Translation (NAT) boxes. An implementation MUST 1168 accept incoming requests even if the source port is not 500 or 4500, 1169 and MUST respond to the address and port from which the request was 1170 received. It MUST specify the address and port at which the request 1171 was received as the source address and port in the response. IKE 1172 functions identically over IPv4 or IPv6. 1174 2.12 Reuse of Diffie-Hellman Exponentials 1176 IKE generates keying material using an ephemeral Diffie-Hellman 1177 exchange in order to gain the property of "perfect forward secrecy". 1178 This means that once a connection is closed and its corresponding 1179 keys are forgotten, even someone who has recorded all of the data 1180 from the connection and gets access to all of the long-term keys of 1181 the two endpoints cannot reconstruct the keys used to protect the 1182 conversation without doing a brute force search of the session key 1183 space. 1185 Achieving perfect forward secrecy requires that when a connection is 1186 closed, each endpoint MUST forget not only the keys used by the 1187 connection but any information that could be used to recompute those 1188 keys. In particular, it MUST forget the secrets used in the Diffie- 1189 Hellman calculation and any state that may persist in the state of a 1190 pseudo-random number generator that could be used to recompute the 1191 Diffie-Hellman secrets. 1193 Since the computing of Diffie-Hellman exponentials is computationally 1194 expensive, an endpoint may find it advantageous to reuse those 1195 exponentials for multiple connection setups. There are several 1196 reasonable strategies for doing this. An endpoint could choose a new 1197 exponential only periodically though this could result in less-than- 1198 perfect forward secrecy if some connection lasts for less than the 1199 lifetime of the exponential. Or it could keep track of which 1200 exponential was used for each connection and delete the information 1201 associated with the exponential only when some corresponding 1202 connection was closed. This would allow the exponential to be reused 1203 without losing perfect forward secrecy at the cost of maintaining 1204 more state. 1206 Decisions as to whether and when to reuse Diffie-Hellman exponentials 1207 is a private decision in the sense that it will not affect 1208 interoperability. An implementation that reuses exponentials MAY 1209 choose to remember the exponential used by the other endpoint on past 1210 exchanges and if one is reused to avoid the second half of the 1211 calculation. 1213 2.13 Generating Keying Material 1215 In the context of the IKE_SA, four cryptographic algorithms are 1216 negotiated: an encryption algorithm, an integrity protection 1217 algorithm, a Diffie-Hellman group, and a pseudo-random function 1218 (prf). The pseudo-random function is used for the construction of 1219 keying material for all of the cryptographic algorithms used in both 1220 the IKE_SA and the CHILD_SAs. 1222 We assume that each encryption algorithm and integrity protection 1223 algorithm uses a fixed size key, and that any randomly chosen value 1224 of that fixed size can serve as an appropriate key. For algorithms 1225 that accept a variable length key, a fixed key size MUST be specified 1226 as part of the cryptographic transform negotiated. For algorithms 1227 for which not all values are valid keys (such as DES or 3DES with key 1228 parity), they algorithm by which keys are derived from arbitrary 1229 values MUST be specified by the cryptographic transform. For 1230 integrity protection functions based on HMAC, the fixed key size is 1231 the size of the output of the underlying hash function. When the prf 1232 function takes a variable length key, variable length data, and 1233 produces a fixed length output (e.g., when using HMAC), the formulas 1234 in this document apply. When the key for the prf function has fixed 1235 length, the data provided as a key is truncated or padded with zeros 1236 as necessary unless exceptional processing is explained following the 1237 formula. 1239 Keying material will always be derived as the output of the 1240 negotiated prf algorithm. Since the amount of keying material needed 1241 may be greater than the size of the output of the prf algorithm, we 1242 will use the prf iteratively. We will use the terminology prf+ to 1243 describe the function that outputs a pseudo-random stream based on 1244 the inputs to a prf as follows: (where | indicates concatenation) 1246 prf+ (K,S) = T1 | T2 | T3 | T4 | ... 1248 where: 1249 T1 = prf (K, S | 0x01) 1250 T2 = prf (K, T1 | S | 0x02) 1251 T3 = prf (K, T2 | S | 0x03) 1252 T4 = prf (K, T3 | S | 0x04) 1254 continuing as needed to compute all required keys. The keys are taken 1255 from the output string without regard to boundaries (e.g., if the 1256 required keys are a 256 bit AES key and a 160 bit HMAC key, and the 1257 prf function generates 160 bits, the AES key will come from T1 and 1258 the beginning of T2, while the HMAC key will come from the rest of T2 1259 and the beginning of T3). 1261 The constant concatenated to the end of each string feeding the prf 1262 is a single octet. prf+ in this document is not defined beyond 255 1263 times the size of the prf output. 1265 2.14 Generating Keying Material for the IKE_SA 1267 The shared keys are computed as follows. A quantity called SKEYSEED 1268 is calculated from the nonces exchanged during the IKE_SA_INIT 1269 exchange and the Diffie-Hellman shared secret established during that 1270 exchange. SKEYSEED is used to calculate seven other secrets: SK_d 1271 used for deriving new keys for the CHILD_SAs established with this 1272 IKE_SA; SK_ai and SK_ar used as a key to the integrity protection 1273 algorithm for authenticating the component messages of subsequent 1274 exchanges; SK_ei and SK_er used for encrypting (and of course 1275 decrypting) all subsequent exchanges; and SK_pi and SK_pr which are 1276 only used when authenticating with an EAP authentication mechanism 1277 that does not generate a shared key. 1279 SKEYSEED and its derivatives are computed as follows: 1281 SKEYSEED = prf(Ni | Nr, g^ir) 1283 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } 1284 = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) 1286 (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, 1287 SK_pi, and SK_pr are taken in order from the generated bits of the 1288 prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman 1289 exchange. g^ir is represented as a string of octets in big endian 1290 order padded with zeros if necessary to make it the length of the 1291 modulus. Ni and Nr are the nonces, stripped of any headers. If the 1292 negotiated prf takes a fixed length key and the lengths of Ni and Nr 1293 do not add up to that length, half the bits must come from Ni and 1294 half from Nr, taking the first bits of each. 1296 The two directions of traffic flow use different keys. The keys used 1297 to protect messages from the original initiator are SK_ai and SK_ei. 1298 The keys used to protect messages in the other direction are SK_ar 1299 and SK_er. Each algorithm takes a fixed number of bits of keying 1300 material, which is specified as part of the algorithm. For integrity 1301 algorithms based on a keyed hash, the key size is always equal to the 1302 length of the output of the underlying hash function. 1304 2.15 Authentication of the IKE_SA 1306 When not using extended authentication (see section 2.16), the peers 1307 are authenticated by having each sign (or MAC using a shared secret 1308 as the key) a block of data. For the responder, the octets to be 1309 signed start with the first octet of the first SPI in the header of 1310 the second message and end with the last octet of the last payload in 1311 the second message. Appended to this (for purposes of computing the 1312 signature) are the initiator's nonce Ni (just the value, not the 1313 payload containing it), and the value prf(SK_ar,IDr') where IDr' is 1314 the responder's ID payload excluding the fixed header. Note that 1315 neither the nonce Ni nor the value prf(SK_ar,IDr') are transmitted. 1316 Similarly, the initiator signs the first message, starting with the 1317 first octet of the first SPI in the header and ending with the last 1318 octet of the last payload. Appended to this (for purposes of 1319 computing the signature) are the responder's nonce Nr, and the value 1320 prf(SK_ai,IDi'). In the above calculation, IDi' and IDr' are the 1321 entire ID payloads excluding the fixed header. It is critical to the 1322 security of the exchange that each side sign the other side's nonce. 1324 Note that all of the payloads are included under the signature, 1325 including any payload types not defined in this document. If the 1326 first message of the exchange is sent twice (the second time with a 1327 responder cookie and/or a different Diffie-Hellman group), it is the 1328 second version of the message that is signed. 1330 Optionally, messages 3 and 4 MAY include a certificate, or 1331 certificate chain providing evidence that the key used to compute a 1332 digital signature belongs to the name in the ID payload. The 1333 signature or MAC will be computed using algorithms dictated by the 1334 type of key used by the signer, and specified by the Auth Method 1335 field in the Authentication payload. There is no requirement that 1336 the Initiator and Responder sign with the same cryptographic 1337 algorithms. The choice of cryptographic algorithms depends on the 1338 type of key each has. In particular, the initiator may be using a 1339 shared key while the responder may have a public signature key and 1340 certificate. It will commonly be the case (but it is not required) 1341 that if a shared secret is used for authentication that the same key 1342 is used in both directions. Note that it is a common but typically 1343 insecure practice to have a shared key derived solely from a user 1344 chosen password without incorporating another source of randomness. 1345 This is typically insecure because user chosen passwords are unlikely 1346 to have sufficient unpredictability to resist dictionary attacks and 1347 these attacks are not prevented in this authentication method. 1348 (Applications using password-based authentication for bootstrapping 1349 and IKE_SA should use the authentication method in section 2.16, 1350 which is designed to prevent off-line dictionary attacks). The pre- 1351 shared key SHOULD contain as much unpredictability as the strongest 1352 key being negotiated. In the case of a pre-shared key, the AUTH 1353 value is computed as: 1355 AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), ) 1358 where the string "Key Pad for IKEv2" is 17 ASCII characters without 1359 null termination. The shared secret can be variable length. The pad 1360 string is added so that if the shared secret is derived from a 1361 password, the IKE implementation need not store the password in 1362 cleartext, but rather can store the value prf(Shared Secret,"Key Pad 1363 for IKEv2"), which could not be used as a password equivalent for 1364 protocols other than IKEv2. As noted above, deriving the shared 1365 secret from a password is not secure. This construction is used 1366 because it is anticipated that people will do it anyway. The 1367 management interface by which the Shared Secret is provided MUST 1368 accept ASCII strings of at least 64 octets and MUST NOT add a null 1369 terminator before using them as shared secrets. The management 1370 interface MAY accept other forms, like hex encoding. If the 1371 negotiated prf takes a fixed size key, the shared secret MUST be of 1372 that fixed size. 1374 2.16 Extended Authentication Protocol Methods 1376 In addition to authentication using public key signatures and shared 1377 secrets, IKE supports authentication using methods defined in RFC 1378 2284 [EAP]. Typically, these methods are asymmetric (designed for a 1379 user authenticating to a server), and they may not be mutual. For 1380 this reason, these protocols are typically used to authenticate the 1381 initiator to the responder and MUST be used in conjunction with a 1382 public key signature based authentication of the responder to the 1383 initiator. These methods are often associated with mechanisms 1384 referred to as "Legacy Authentication" mechanisms. 1386 While this memo references [EAP] with the intent that new methods can 1387 be added in the future without updating this specification, the 1388 protocols expected to be used most commonly are documented here and 1389 in section 3.16. [EAP] defines an authentication protocol requiring 1390 a variable number of messages. Extended Authentication is implemented 1391 in IKE as additional IKE_AUTH exchanges that MUST be completed in 1392 order to initialize the IKE_SA. 1394 An initiator indicates a desire to use extended authentication by 1395 leaving out the AUTH payload from message 3. By including an IDi 1396 payload but not an AUTH payload, the initiator has declared an 1397 identity but has not proven it. If the responder is willing to use an 1398 extended authentication method, it will place an EAP payload in 1399 message 4 and defer sending SAr2, TSi, and TSr until initiator 1400 authentication is complete in a subsequent IKE_AUTH exchange. In the 1401 case of a minimal extended authentication, the initial SA 1402 establishment will appear as follows: 1404 Initiator Responder 1405 ----------- ----------- 1406 HDR, SAi1, KEi, Ni --> 1408 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 1410 HDR, SK {IDi, [CERTREQ,] [IDr,] 1411 SAi2, TSi, TSr} --> 1413 <-- HDR, SK {IDr, [CERT,] AUTH, 1414 EAP } 1416 HDR, SK {EAP} --> 1418 <-- HDR, SK {EAP (success)} 1420 HDR, SK {AUTH} --> 1422 <-- HDR, SK {AUTH, SAr2, TSi, TSr } 1424 For EAP methods that create a shared key as a side effect of 1425 authentication, that shared key MUST be used by both the Initiator 1426 and Responder to generate AUTH payloads in messages 5 and 6 using the 1427 syntax for shared secrets specified in section 2.15. The shared key 1428 from EAP is the field from the EAP specification named MSK. The 1429 shared key generated during an IKE exchange MUST NOT be used for any 1430 other purpose. 1432 EAP methods that do not establish a shared key SHOULD NOT be used, as 1433 they are subject to a number of man-in-the-middle attacks [EAPMITM] 1434 if these EAP methods are used in other protocols that do not use a 1435 server-authenticated tunnel. Please see the Security Considerations 1436 section for more details. If EAP methods that do not generate a 1437 shared key are used, the AUTH payloads in messages 7 and 8 MUST be 1438 generated using SK_pi and SK_pr respectively. 1440 The Initiator of an IKE_SA using EAP SHOULD be capable of extending 1441 the initial protocol exchange to at least ten IKE_AUTH exchanges in 1442 the event the Responder sends notification messages and/or retries 1443 the authentication prompt. The protocol terminates when the Responder 1444 sends the Initiator an EAP payload containing either a success or 1445 failure type. In such an extended exchange, the EAP AUTH payloads 1446 MUST be included in the two messages following the one containing the 1447 EAP (success) message. 1449 2.17 Generating Keying Material for CHILD_SAs 1451 CHILD_SAs are created either by being piggybacked on the IKE_AUTH 1452 exchange, or in a CREATE_CHILD_SA exchange. Keying material for them 1453 is generated as follows: 1455 KEYMAT = prf+(SK_d, Ni | Nr) 1457 Where Ni and Nr are the Nonces from the IKE_SA_INIT exchange if this 1458 request is the first CHILD_SA created or the fresh Ni and Nr from the 1459 CREATE_CHILD_SA exchange if this is a subsequent creation. 1461 For CREATE_CHILD_SA exchanges with PFS the keying material is defined 1462 as: 1464 KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr ) 1466 where g^ir (new) is the shared secret from the ephemeral Diffie- 1467 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 1468 octet string in big endian order padded with zeros in the high order 1469 bits if necessary to make it the length of the modulus). 1471 A single CHILD_SA negotiation may result in multiple security 1472 associations. ESP and AH SAs exist in pairs (one in each direction), 1473 and four SAs could be created in a single CHILD_SA negotiation if a 1474 combination of ESP and AH is being negotiated. 1476 Keying material MUST be taken from the expanded KEYMAT in the 1477 following order: 1479 All keys for SAs carrying data from the initiator to the responder 1480 are taken before SAs going in the reverse direction. 1482 If multiple IPsec protocols are negotiated, keying material is 1483 taken in the order in which the protocol headers will appear in 1484 the encapsulated packet. 1486 If a single protocol has both encryption and authentication keys, 1487 the encryption key is taken from the first octets of KEYMAT and 1488 the authentication key is taken from the next octets. 1490 Each cryptographic algorithm takes a fixed number of bits of keying 1491 material specified as part of the algorithm. 1493 2.18 Rekeying IKE_SAs using a CREATE_CHILD_SA exchange 1495 The CREATE_CHILD_SA exchange can be used to rekey an existing IKE_SA 1496 (see section 2.8). New Initiator and Responder SPIs are supplied in 1497 the SPI fields. The TS payloads are omitted when rekeying an IKE_SA. 1498 SKEYSEED for the new IKE_SA is computed using SK_d from the existing 1499 IKE_SA as follows: 1501 SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr) 1503 where g^ir (new) is the shared secret from the ephemeral Diffie- 1504 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 1505 octet string in big endian order padded with zeros if necessary to 1506 make it the length of the modulus) and Ni and Nr are the two nonces 1507 stripped of any headers. 1509 The new IKE_SA MUST reset its message counters to 0. 1511 SK_d, SK_ai, SK_ar, and SK_ei, and SK_er are computed from SKEYSEED 1512 as specified in section 2.14. 1514 2.19 Requesting an internal address on a remote network 1516 Most commonly occurring in the endpoint to security gateway scenario, 1517 an endpoint may need an IP address in the network protected by the 1518 security gateway, and may need to have that address dynamically 1519 assigned. A request for such a temporary address can be included in 1520 any request to create a CHILD_SA (including the implicit request in 1521 message 3) by including a CP payload. 1523 This function provides address allocation to an IRAC (IPsec Remote 1524 Access Client) trying to tunnel into a network protected by an IRAS 1525 (IPsec Remote Access Server). Since the IKE_AUTH exchange creates an 1526 IKE_SA and a CHILD_SA, the IRAC MUST request the IRAS controlled 1527 address (and optionally other information concerning the protected 1528 network) in the IKE_AUTH exchange. The IRAS may procure an address 1529 for the IRAC from any number of sources such as a DHCP/BOOTP server 1530 or its own address pool. 1532 Initiator Responder 1533 ----------------------------- --------------------------- 1534 HDR, SK {IDi, [CERT,] [CERTREQ,] 1535 [IDr,] AUTH, CP(CFG_REQUEST), 1536 SAi2, TSi, TSr} --> 1538 <-- HDR, SK {IDr, [CERT,] AUTH, 1539 CP(CFG_REPLY), SAr2, 1540 TSi, TSr} 1542 In all cases, the CP payload MUST be inserted before the SA payload. 1543 In variations of the protocol where there are multiple IKE_AUTH 1544 exchanges, the CP payloads MUST be inserted in the messages 1545 containing the SA payloads. 1547 CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute 1548 (either IPv4 or IPv6) but MAY contain any number of additional 1549 attributes the initiator wants returned in the response. 1551 For example, message from Initiator to Responder: 1552 CP(CFG_REQUEST)= 1553 INTERNAL_ADDRESS(0.0.0.0) 1554 INTERNAL_NETMASK(0.0.0.0) 1555 INTERNAL_DNS(0.0.0.0) 1556 TSi = (0, 0-65536,0.0.0.0-255.255.255.255) 1557 TSr = (0, 0-65536,0.0.0.0-255.255.255.255) 1559 NOTE: Traffic Selectors contain (protocol, port range, address range) 1561 Message from Responder to Initiator: 1563 CP(CFG_REPLY)= 1564 INTERNAL_ADDRESS(10.168.219.202) 1565 INTERNAL_NETMASK(255.255.255.0) 1566 INTERNAL_SUBNET(10.168.219.0/255.255.255.0) 1567 TSi = (0, 0-65536,10.168.219.202-10.168.219.202) 1568 TSr = (0, 0-65536,10.168.219.0-10.168.219.255) 1570 All returned values will be implementation dependent. As can be seen 1571 in the above example, the IRAS MAY also send other attributes that 1572 were not included in CP(CFG_REQUEST) and MAY ignore the non- 1573 mandatory attributes that it does not support. 1575 The responder MUST NOT send a CFG_REPLY without having first received 1576 a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS 1577 to perform an unnecessary configuration lookup if the IRAC cannot 1578 process the REPLY. In the case where the IRAS's configuration 1579 requires that CP be used for a given identity IDi, but IRAC has 1580 failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and 1581 terminate the IKE exchange with a FAILED_CP_REQUIRED error. 1583 2.20 Requesting the Peer's Version 1585 An IKE peer wishing to inquire about the other peer's IKE software 1586 version information MAY use the method below. This is an example of 1587 a configuration request within an INFORMATIONAL Exchange, after the 1588 IKE_SA and first CHILD_SA have been created. 1590 An IKE implementation MAY decline to give out version information 1591 prior to authentication or even after authentication to prevent 1592 trolling in case some implementation is known to have some security 1593 weakness. In that case, it MUST either return an empty string or no 1594 CP payload if CP is not supported. 1596 Initiator Responder 1597 ----------------------------- -------------------------- 1598 HDR, SK{CP(CFG_REQUEST)} --> 1599 <-- HDR, SK{CP(CFG_REPLY)} 1601 CP(CFG_REQUEST)= 1602 APPLICATION_VERSION("") 1604 CP(CFG_REPLY) 1605 APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar Inc.") 1607 2.21 Error Handling 1609 There are many kinds of errors that can occur during IKE processing. 1610 If a request is received that is badly formatted or unacceptable for 1611 reasons of policy (e.g., no matching cryptographic algorithms), the 1612 response MUST contain a Notify payload indicating the error. If an 1613 error occurs outside the context of an IKE request (e.g., the node is 1614 getting ESP messages on a nonexistent SPI), the node SHOULD initiate 1615 an INFORMATIONAL Exchange with a Notify payload describing the 1616 problem. 1618 Errors that occur before a cryptographically protected IKE_SA is 1619 established must be handled very carefully. There is a trade-off 1620 between wanting to be helpful in diagnosing a problem and responding 1621 to it and wanting to avoid being a dupe in a denial of service attack 1622 based on forged messages. 1624 If a node receives a message on UDP port 500 outside the context of 1625 an IKE_SA known to it (and not a request to start one), it may be the 1626 result of a recent crash of the node. If the message is marked as a 1627 response, the node MAY audit the suspicious event but MUST NOT 1628 respond. If the message is marked as a request, the node MAY audit 1629 the suspicious event and MAY send a response. If a response is sent, 1630 the response MUST be sent to the IP address and port from whence it 1631 came with the same IKE SPIs and the Message ID copied. The response 1632 MUST NOT be cryptographically protected and MUST contain a Notify 1633 payload indicating INVALID_IKE_SPI. 1635 A node receiving such an unprotected Notify payload MUST NOT respond 1636 and MUST NOT change the state of any existing SAs. The message might 1637 be a forgery or might be a response the genuine correspondent was 1638 tricked into sending. A node SHOULD treat such a message (and also a 1639 network message like ICMP destination unreachable) as a hint that 1640 there might be problems with SAs to that IP address and SHOULD 1641 initiate a liveness test for any such IKE_SA. An implementation 1642 SHOULD limit the frequency of such tests to avoid being tricked into 1643 participating in a denial of service attack. 1645 A node receiving a suspicious message from an IP address with which 1646 it has an IKE_SA MAY send an IKE Notify payload in an IKE 1647 INFORMATIONAL exchange over that SA. The recipient MUST NOT change 1648 the state of any SA's as a result but SHOULD audit the event to aid 1649 in diagnosing malfunctions. A node MUST limit the rate at which it 1650 will send messages in response to unprotected messages. 1652 2.22 IPComp 1654 Use of IP compression [IPCOMP] can be negotiated as part of the setup 1655 of a CHILD_SA. While IP compression involves an extra header in each 1656 packet and a CPI (compression parameter index), the virtual 1657 "compression association" has no life outside the ESP or AH SA that 1658 contains it. Compression associations disappear when the 1659 corresponding ESP or AH SA goes away, and is not explicitly mentioned 1660 in any DELETE payload. 1662 Negotiation of IP compression is separate from the negotiation of 1663 cryptographic parameters associated with a CHILD_SA. A node 1664 requesting a CHILD_SA MAY advertise its support for one or more 1665 compression algorithms though one or more Notify payloads of type 1666 IPCOMP_SUPPORTED. The response MAY indicate acceptance of a single 1667 compression algorithm with a Notify payload of type IPCOMP_SUPPORTED. 1668 These payloads MUST NOT occur messages that do not contain SA 1669 payloads. 1671 While there has been discussion of allowing multiple compression 1672 algorithms to be accepted and to have different compression 1673 algorithms available for the two directions of a CHILD_SA, 1674 implementations of this specification MUST NOT accept an IPComp 1675 algorithm that was not proposed, MUST NOT accept more than one, and 1676 MUST NOT compress using an algorithm other than one proposed and 1677 accepted in the setup of the CHILD_SA. 1679 A side effect of separating the negotiation of IPComp from 1680 cryptographic parameters is that it is not possible to propose 1681 multiple cryptographic suites and propose IP compression with some of 1682 them but not others. 1684 2.23 NAT Traversal 1686 NAT (Network Address Translation) gateways are a controversial 1687 subject. This section briefly describes what they are and how they 1688 are likely to act on IKE traffic. Many people believe that NATs are 1689 evil and that we should not design our protocols so as to make them 1690 work better. IKEv2 does specify some unintuitive processing rules in 1691 order that NATs are more likely to work. 1693 NATs exist primarily because of the shortage of IPv4 addresses, 1694 though there are other rationales. IP nodes that are "behind" a NAT 1695 have IP addresses that are not globally unique, but rather are 1696 assigned from some space that is unique within the network behind the 1697 NAT but which are likely to be reused by nodes behind other NATs. 1698 Generally, nodes behind NATs can communicate with other nodes behind 1699 the same NAT and with nodes with globally unique addresses, but not 1700 with nodes behind other NATs. There are exceptions to that rule. 1701 When those nodes make connections to nodes on the real Internet, the 1702 NAT gateway "translates" the IP source address to an address that 1703 will be routed back to the gateway. Messages to the gateway from the 1704 Internet have their destination addresses "translated" to the 1705 internal address that will route the packet to the correct endnode. 1707 NATs are designed to be "transparent" to endnodes. Neither software 1708 on the node behind the NAT nor the node on the Internet require 1709 modification to communicate through the NAT. Achieving this 1710 transparency is more difficult with some protocols than with others. 1711 Protocols that include IP addresses of the endpoints within the 1712 payloads of the packet will fail unless the NAT gateway understands 1713 the protocol and modifies the internal references as well as those in 1714 the headers. Such knowledge is inherently unreliable, is a network 1715 layer violation, and often results in subtle problems. 1717 Opening an IPsec connection through a NAT introduces special 1718 problems. If the connection runs in transport mode, changing the IP 1719 addresses on packets will cause the checksums to fail and the NAT 1720 cannot correct the checksums because they are cryptographically 1721 protected. Even in tunnel mode, there are routing problems because 1722 transparently translating the addresses of AH and ESP packets 1723 requires special logic in the NAT and that logic is heuristic and 1724 unreliable in nature. For that reason, IKEv2 can negotiate UDP 1725 encapsulation of IKE, ESP, and AH packets. This encoding is slightly 1726 less efficient but is easier for NATs to process. In addition, 1727 firewalls may be configured to pass IPsec traffic over UDP but not 1728 ESP/AH or vice versa. 1730 It is a common practice of NATs to translate TCP and UDP port numbers 1731 as well as addresses and use the port numbers of inbound packets to 1732 decide which internal node should get a given packet. For this 1733 reason, even though IKE packets MUST be sent from and to UDP port 1734 500, they MUST be accepted coming from any port and responses MUST be 1735 sent to the port from whence they came. This is because the ports may 1736 be modified as the packets pass through NATs. Similarly, IP addresses 1737 of the IKE endpoints are generally not included in the IKE payloads 1738 because the payloads are cryptographically protected and could not be 1739 transparently modified by NATs. 1741 Port 4500 is reserved for UDP encapsulated ESP, AH, and IKE. When 1742 working through a NAT, it is generally better to pass IKE packets 1743 over port 4500 because some older NATs modify IKE traffic on port 500 1744 in an attempt to transparently establish IPsec connections. Such NATs 1745 may interfere with the straightforward NAT traversal envisioned by 1746 this document, so an IPsec endpoint that discovers a NAT between it 1747 and its correspondent MUST send all subsequent traffic to and from 1748 port 4500, which NATs should not treat specially (as they might with 1749 port 500). 1751 The specific requirements for supporting NAT traversal are listed 1752 below. Support for NAT traversal is optional. In this section only, 1753 requirements listed as MUST only apply to implementations supporting 1754 NAT traversal. 1756 IKE MUST listen on port 4500 as well as port 500. IKE MUST respond 1757 to the IP address and port from which packets arrived. 1759 Both IKE initiator and responder MUST include in their IKE_SA_INIT 1760 packets Notify payloads of type NAT_DETECTION_SOURCE_IP and 1761 NAT_DETECTION_DESTINATION_IP. Those payloads can be used to detect 1762 if there is NAT between the hosts, and which end is behind the 1763 NAT. The location of the payloads in the IKE_SA_INIT packets are 1764 just after the Ni and Nr payloads (before the optional CERTREQ 1765 payload). 1767 If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches 1768 the hash of the source IP and port found from the IP header of the 1769 packet containing the payload, it means that the the other end is 1770 behind NAT (i.e someone along the route changed the source address 1771 of the original packet to match the address of the NAT box). In 1772 this case this end should allow dynamic update of the other ends 1773 IP address, as described later. 1775 If the NAT_DETECTION_DESTINATION_IP payload received does not 1776 match the hash of the destination IP and port found from the IP 1777 header of the packet containing the payload, it means that this 1778 end is behind NAT (i.e the original sender sent the packet to 1779 address of the NAT box, which then changed the destination address 1780 to this host). In this case the this end should start sending 1781 keepalive packets as explained in [Hutt04]. 1783 The IKE initiator MUST check these payloads if present and if they 1784 do not match the addresses in the outer packet MUST tunnel all 1785 future IKE, ESP, and AH packets associated with this IKE_SA over 1786 UDP port 4500. 1788 To tunnel IKE packets over UDP port 4500, the IKE header has four 1789 octets of zero prepended and the result immediately follows the 1790 UDP header. To tunnel ESP packets over UDP port 4500, the ESP 1791 header immediately follows the UDP header. Since the first four 1792 bytes of the ESP header contain the SPI, and the SPI cannot 1793 validly be zero, it is always possible to distinguish ESP and IKE 1794 messages. 1796 The original source and destination IP address required for the 1797 transport mode TCP and UDP packet checksum fixup (see [Hutt04]) 1798 are obtained from the Traffic Selectors associated with the 1799 exchange. In the case of NAT-T, the Traffic Selectors MUST contain 1800 exactly one IP address which is then used as the original IP 1801 address. 1803 There are cases where a NAT box decides to remove mappings that 1804 are still alive (for example, the keepalive interval is too long, 1805 or the NAT box is rebooted). To recover in these cases, hosts that 1806 are not behind a NAT SHOULD send all packets (including 1807 retranmission packets) to the IP address and port from the last 1808 valid authenticated packet from the other end (i.e dynamically 1809 update the address). A host behind a NAT SHOULD NOT do this 1810 because it opens a DoS attack possibility. Any authenticated IKE 1811 packet or any authenticated UDP encapsulated ESP packet can be 1812 used to detect that the IP address or the port has changed. 1814 Note that similar but probably not identical actions will likely 1815 be needed to make IKE work with Mobile IP, but such processing is 1816 not addressed by this document. 1818 2.24 ECN (Explicit Congestion Notification) 1820 When IPsec tunnels behave as originally specified in [RFC 2401], ECN 1821 usage is not appropriate for the outer IP headers because tunnel 1822 decapsulation processing discards ECN congestion indications to the 1823 detriment of the network. ECN support for IPsec tunnels for 1824 IKEv1-based IPsec requires multiple operating modes and negotiation 1825 (see RFC 3168]). IKEv2 simplifies this situation by requiring that 1826 ECN be usable in the outer IP headers of all tunnel-mode IPsec SAs 1827 created by IKEv2. Specifically, tunnel encapsulators and 1828 decapsulators for all tunnel-mode Security Associations (SAs) created 1829 by IKEv2 MUST support the ECN full-functionality option for tunnels 1830 specified in [RFC3168] and MUST implement the tunnel encapsulation 1831 and decapsulation processing specified in [RFC2401bis] to prevent 1832 discarding of ECN congestion indications. 1834 3 Header and Payload Formats 1836 3.1 The IKE Header 1838 IKE messages use UDP ports 500 and/or 4500, with one IKE message per 1839 UDP datagram. Information from the UDP header is largely ignored 1840 except that the IP addresses and UDP ports from the headers are 1841 reversed and used for return packets. When sent on UDP port 500, IKE 1842 messages begin immediately following the UDP header. When sent on UDP 1843 port 4500, IKE messages have prepended four octets of zero. These 1844 four octets of zero are not part of the IKE message and are not 1845 included in any of the length fields or checksums defined by IKE. 1846 Each IKE message begins with the IKE header, denoted HDR in this 1847 memo. Following the header are one or more IKE payloads each 1848 identified by a "Next Payload" field in the preceding payload. 1849 Payloads are processed in the order in which they appear in an IKE 1850 message by invoking the appropriate processing routine according to 1851 the "Next Payload" field in the IKE header and subsequently according 1852 to the "Next Payload" field in the IKE payload itself until a "Next 1853 Payload" field of zero indicates that no payloads follow. If a 1854 payload of type "Encrypted" is found, that payload is decrypted and 1855 its contents parsed as additional payloads. An Encrypted payload MUST 1856 be the last payload in a packet and an encrypted payload MUST NOT 1857 contain another encrypted payload. 1859 The Recipient SPI in the header identifies an instance of an IKE 1860 security association. It is therefore possible for a single instance 1861 of IKE to multiplex distinct sessions with multiple peers. 1863 All multi-octet fields representing integers are laid out in big 1864 endian order (aka most significant byte first, or network byte 1865 order). 1867 The format of the IKE header is shown in Figure 4. 1868 1 2 3 1869 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 1870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1871 ! IKE_SA Initiator's SPI ! 1872 ! ! 1873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1874 ! IKE_SA Responder's SPI ! 1875 ! ! 1876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1877 ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! 1878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1879 ! Message ID ! 1880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1881 ! Length ! 1882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1884 Figure 4: IKE Header Format 1886 o Initiator's SPI (8 octets) - A value chosen by the 1887 initiator to identify a unique IKE security association. This 1888 value MUST NOT be zero. 1890 o Responder's SPI (8 octets) - A value chosen by the 1891 responder to identify a unique IKE security association. This 1892 value MUST be zero in the first message of an IKE Initial 1893 Exchange (including repeats of that message including a 1894 cookie) and MUST NOT be zero in any other message. 1896 o Next Payload (1 octet) - Indicates the type of payload that 1897 immediately follows the header. The format and value of each 1898 payload is defined below. 1900 o Major Version (4 bits) - indicates the major version of the IKE 1901 protocol in use. Implementations based on this version of IKE 1902 MUST set the Major Version to 2. Implementations based on 1903 previous versions of IKE and ISAKMP MUST set the Major Version 1904 to 1. Implementations based on this version of IKE MUST reject 1905 or ignore messages containing a version number greater than 1906 2. 1908 o Minor Version (4 bits) - indicates the minor version of the 1909 IKE protocol in use. Implementations based on this version of 1910 IKE MUST set the Minor Version to 0. They MUST ignore the minor 1911 version number of received messages. 1913 o Exchange Type (1 octet) - indicates the type of exchange being 1914 used. This constrains the payloads sent in each message and 1915 orderings of messages in an exchange. 1917 Exchange Type Value 1919 RESERVED 0-33 1920 IKE_SA_INIT 34 1921 IKE_AUTH 35 1922 CREATE_CHILD_SA 36 1923 INFORMATIONAL 37 1924 Reserved for IKEv2+ 38-239 1925 Reserved for private use 240-255 1927 o Flags (1 octet) - indicates specific options that are set 1928 for the message. Presence of options are indicated by the 1929 appropriate bit in the flags field being set. The bits are 1930 defined LSB first, so bit 0 would be the least significant 1931 bit of the Flags octet. In the description below, a bit 1932 being 'set' means its value is '1', while 'cleared' means 1933 its value is '0'. 1935 -- X(reserved) (bits 0-2) - These bits MUST be cleared 1936 when sending and MUST be ignored on receipt. 1938 -- I(nitiator) (bit 3 of Flags) - This bit MUST be set in 1939 messages sent by the original Initiator of the IKE_SA 1940 and MUST be cleared in messages sent by the original 1941 Responder. It is used by the recipient to determine 1942 which eight octets of the SPI was generated by the 1943 recipient. 1945 -- V(ersion) (bit 4 of Flags) - This bit indicates that 1946 the transmitter is capable of speaking a higher major 1947 version number of the protocol than the one indicated 1948 in the major version number field. Implementations of 1949 IKEv2 must clear this bit when sending and MUST ignore 1950 it in incoming messages. 1952 -- R(esponse) (bit 5 of Flags) - This bit indicates that 1953 this message is a response to a message containing 1954 the same message ID. This bit MUST be cleared in all 1955 request messages and MUST be set in all responses. 1956 An IKE endpoint MUST NOT generate a response to a 1957 message that is marked as being a response. 1959 -- X(reserved) (bits 6-7 of Flags) - These bits MUST be 1960 cleared when sending and MUST be ignored on receipt. 1962 o Message ID (4 octets) - Message identifier used to control 1963 retransmission of lost packets and matching of requests and 1964 responses. It is essential to the security of the protocol 1965 because it is used to prevent message replay attacks. 1966 See sections 2.1 and 2.2. 1968 o Length (4 octets) - Length of total message (header + payloads) 1969 in octets. 1971 3.2 Generic Payload Header 1973 Each IKE payload defined in sections 3.3 through 3.16 begins with a 1974 generic payload header, shown in Figure 5. Figures for each payload 1975 below will include the generic payload header but for brevity the 1976 description of each field will be omitted. 1978 1 2 3 1979 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 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 ! Next Payload !C! RESERVED ! Payload Length ! 1982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1984 Figure 5: Generic Payload Header 1986 The Generic Payload Header fields are defined as follows: 1988 o Next Payload (1 octet) - Identifier for the payload type of the 1989 next payload in the message. If the current payload is the last 1990 in the message, then this field will be 0. This field provides 1991 a "chaining" capability whereby additional payloads can be 1992 added to a message by appending it to the end of the message 1993 and setting the "Next Payload" field of the preceding payload 1994 to indicate the new payload's type. An Encrypted payload, 1995 which must always be the last payload of a message, is an 1996 exception. It contains data structures in the format of 1997 additional payloads. In the header of an Encrypted payload, 1998 the Next Payload field is set to the payload type of the first 1999 contained payload (instead of 0). 2001 Payload Type Values 2003 Next Payload Type Notation Value 2005 No Next Payload 0 2007 RESERVED 1-32 2008 Security Association SA 33 2009 Key Exchange KE 34 2010 Identification - Initiator IDi 35 2011 Identification - Responder IDr 36 2012 Certificate CERT 37 2013 Certificate Request CERTREQ 38 2014 Authentication AUTH 39 2015 Nonce Ni, Nr 40 2016 Notify N 41 2017 Delete D 42 2018 Vendor ID V 43 2019 Traffic Selector - Initiator TSi 44 2020 Traffic Selector - Responder TSr 45 2021 Encrypted E 46 2022 Configuration CP 47 2023 Extended Authentication EAP 48 2024 RESERVED TO IANA 49-127 2025 PRIVATE USE 128-255 2027 Payload type values 1-32 should not be used so that there is no 2028 overlap with the code assignments for IKEv1. Payload type values 2029 49-127 are reserved to IANA for future assignment in IKEv2 (see 2030 section 6). Payload type values 128-255 are for private use among 2031 mutually consenting parties. 2033 o Critical (1 bit) - MUST be set to zero if the sender wants 2034 the recipient to skip this payload if he does not 2035 understand the payload type code in the Next Payload field 2036 of the previous payload. MUST be set to one if the 2037 sender wants the recipient to reject this entire message 2038 if he does not understand the payload type. MUST be ignored 2039 by the recipient if the recipient understands the payload type 2040 code. MUST be set to zero for payload types defined in this 2041 document. Note that the critical bit applies to the current 2042 payload rather than the "next" payload whose type code 2043 appears in the first octet. The reasoning behind not setting 2044 the critical bit for payloads defined in this document is 2045 that all implementations MUST understand all payload types 2046 defined in this document and therefore must ignore the 2047 Critical bit's value. Skipped payloads are expected to 2048 have valid Next Payload and Payload Length fields. 2050 o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on 2051 receipt. 2053 o Payload Length (2 octets) - Length in octets of the current 2054 payload, including the generic payload header. 2056 3.3 Security Association Payload 2058 The Security Association Payload, denoted SA in this memo, is used to 2059 negotiate attributes of a security association. Assembly of Security 2060 Association Payloads requires great peace of mind. An SA payload MAY 2061 contain multiple proposals. If there is more than one, they MUST be 2062 ordered from most preferred to least preferred. Each proposal may 2063 contain multiple IPsec protocols (where a protocol is IKE, ESP, or 2064 AH), each protocol MAY contain multiple transforms, and each 2065 transform MAY contain multiple attributes. When parsing an SA, an 2066 implementation MUST check that the total Payload Length is consistent 2067 with the payload's internal lengths and counts. Proposals, 2068 Transforms, and Attributes each have their own variable length 2069 encodings. They are nested such that the Payload Length of an SA 2070 includes the combined contents of the SA, Proposal, Transform, and 2071 Attribute information. The length of a Proposal includes the lengths 2072 of all Transforms and Attributes it contains. The length of a 2073 Transform includes the lengths of all Attributes it contains. 2075 The syntax of Security Associations, Proposals, Transforms, and 2076 Attributes is based on ISAKMP, however the semantics are somewhat 2077 different. The reason for the complexity and the hierarchy is to 2078 allow for multiple possible combinations of algorithms to be encoded 2079 in a single SA. Sometimes there is a choice of multiple algorithms, 2080 while other times there is a combination of algorithms. For example, 2081 an Initiator might want to propose using (AH w/MD5 and ESP w/3DES) OR 2082 (ESP w/MD5 and 3DES). 2084 One of the reasons the semantics of the SA payload has changed from 2085 ISAKMP and IKEv1 is to make the encodings more compact in common 2086 cases. 2088 The Proposal structure contains within it a Proposal # and an IPsec 2089 protocol ID. Each structure MUST have the same Proposal # as the 2090 previous one or be one (1) greater. The first Proposal MUST have a 2091 Proposal # of one (1). If two successive structures have the same 2092 Proposal number, it means that the proposal consists of the first 2093 structure AND the second. So a proposal of AH AND ESP would have two 2094 proposal structures, one for AH and one for ESP and both would have 2095 Proposal #1. A proposal of AH OR ESP would have two proposal 2096 structures, one for AH with proposal #1 and one for ESP with proposal 2097 #2. 2099 Each Proposal/Protocol structure is followed by one or more transform 2100 structures. The number of different transforms is generally 2101 determined by the Protocol. AH generally has a single transform: an 2102 integrity check algorithm. ESP generally has two: an encryption 2103 algorithm and an integrity check algorithm. IKE generally has four 2104 transforms: a Diffie-Hellman group, an integrity check algorithm, a 2105 prf algorithm, and an encryption algorithm. If an algorithm that 2106 combines encryption and integrity protection is proposed, it MUST be 2107 proposed as an encryption algorithm and an integrity protection 2108 algorithm MUST NOT be proposed. For each Protocol, the set of 2109 permissible transforms are assigned transform ID numbers, which 2110 appear in the header of each transform. 2112 If there are multiple transforms with the same Transform Type, the 2113 proposal is an OR of those transforms. If there are multiple 2114 Transforms with different Transform Types, the proposal is an AND of 2115 the different groups. For example, to propose ESP with (3DES or IDEA) 2116 and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two 2117 Transform Type 1 candidates (one for 3DES and one for IDEA) and two 2118 Transform Type 2 candidates (one for HMAC_MD5 and one for HMAC_SHA). 2119 This effectively proposes four combinations of algorithms. If the 2120 Initiator wanted to propose only a subset of those - say (3DES and 2121 HMAC_MD5) or (IDEA and HMAC_SHA), there is no way to encode that as 2122 multiple transforms within a single Proposal. Instead, the Initiator 2123 would have to construct two different Proposals, each with two 2124 transforms. 2126 A given transform MAY have one or more Attributes. Attributes are 2127 necessary when the transform can be used in more than one way, as 2128 when an encryption algorithm has a variable key size. The transform 2129 would specify the algorithm and the attribute would specify the key 2130 size. Most transforms do not have attributes. A transform MUST NOT 2131 have multiple attributes of the same type. To propose alternate 2132 values for an attribute (for example, multiple key sizes for the AES 2133 encryption algorithm), and implementation MUST include multiple 2134 Transorms with the same Transform Type each with a single Attribute. 2136 Note that the semantics of Transforms and Attributes are quite 2137 different than in IKEv1. In IKEv1, a single Transform carried 2138 multiple algorithms for a protocol with one carried in the Transform 2139 and the others carried in the Attributes. 2141 1 2 3 2142 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 2143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2144 ! Next Payload !C! RESERVED ! Payload Length ! 2145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2146 ! ! 2147 ~ ~ 2148 ! ! 2149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2151 Figure 6: Security Association Payload 2153 o Proposals (variable) - one or more proposal substructures. 2155 The payload type for the Security Association Payload is thirty 2156 three (33). 2158 3.3.1 Proposal Substructure 2160 1 2 3 2161 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 2162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2163 ! 0 (last) or 2 ! RESERVED ! Proposal Length ! 2164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2165 ! Proposal # ! Protocol ID ! SPI Size !# of Transforms! 2166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2167 ~ SPI (variable) ~ 2168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2169 ! ! 2170 ~ ~ 2171 ! ! 2172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2174 Figure 7: Proposal Substructure 2176 o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the 2177 last Proposal Substructure in the SA. This syntax is inherited 2178 from ISAKMP, but is unnecessary because the last Proposal 2179 could be identified from the length of the SA. The value (2) 2180 corresponds to a Payload Type of Proposal in IKEv1, and the 2181 first four octets of the Proposal structure are designed to 2182 look somewhat like the header of a Payload. 2184 o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on 2185 receipt. 2187 o Proposal Length (2 octets) - Length of this proposal, 2188 including all transforms and attributes that follow. 2190 o Proposal # (1 octet) - When a proposal is made, the first 2191 proposal in an SA MUST be #1, and subsequent proposals 2192 MUST either be the same as the previous proposal (indicating 2193 an AND of the two proposals) or one more than the previous 2194 proposal (indicating an OR of the two proposals). When a 2195 proposal is accepted, all of the proposal numbers in the 2196 SA MUST be the same and MUST match the number on the 2197 proposal sent that was accepted. 2199 o Protocol ID (1 octet) - Specifies the IPsec protocol 2200 identifier for the current negotiation. The defined values 2201 are: 2203 Protocol Protocol ID 2204 RESERVED 0 2205 IKE 1 2206 AH 2 2207 ESP 3 2208 RESERVED TO IANA 4-200 2209 PRIVATE USE 201-255 2211 o SPI Size (1 octet) - For an initial IKE_SA negotiation, 2212 this field MUST be zero; the SPI is obtained from the 2213 outer header. During subsequent negotiations, 2214 it is equal to the size, in octets, of the SPI of the 2215 corresponding protocol (8 for IKE, 4 for ESP and AH). 2217 o # of Transforms (1 octet) - Specifies the number of 2218 transforms in this proposal. 2220 o SPI (variable) - The sending entity's SPI. Even if the SPI 2221 Size is not a multiple of 4 octets, there is no padding 2222 applied to the payload. When the SPI Size field is zero, 2223 this field is not present in the Security Association 2224 payload. 2226 o Transforms (variable) - one or more transform substructures. 2228 3.3.2 Transform Substructure 2230 1 2 3 2231 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 2232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2233 ! 0 (last) or 3 ! RESERVED ! Transform Length ! 2234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2235 !Transform Type ! RESERVED ! Transform ID ! 2236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2237 ! ! 2238 ~ Transform Attributes ~ 2239 ! ! 2240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2242 Figure 8: Transform Substructure 2244 o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the 2245 last Transform Substructure in the Proposal. This syntax is 2246 inherited from ISAKMP, but is unnecessary because the last 2247 Proposal could be identified from the length of the SA. The 2248 value (3) corresponds to a Payload Type of Transform in IKEv1, 2249 and the first four octets of the Transform structure are 2250 designed to look somewhat like the header of a Payload. 2252 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 2254 o Transform Length - The length (in octets) of the Transform 2255 Substructure including Header and Attributes. 2257 o Transform Type (1 octet) - The type of transform being specified 2258 in this transform. Different protocols support different 2259 transform types. For some protocols, some of the transforms 2260 may be optional. If a transform is optional and the initiator 2261 wishes to propose that the transform be omitted, no transform 2262 of the given type is included in the proposal. If the 2263 initiator wishes to make use of the transform optional to 2264 the responder, she includes a transform substructure with 2265 transform ID = 0 as one of the options. 2267 o Transform ID (2 octets) - The specific instance of the transform 2268 type being proposed. 2270 Transform Type Values 2272 Transform Used In 2273 Type 2274 Encryption Algorithm 1 (IKE and ESP) 2275 Pseudo-random Function 2 (IKE) 2276 Integrity Algorithm 3 (IKE, AH, and optional in ESP) 2277 Diffie-Hellman Group 4 (IKE and optional in AH and ESP) 2278 Extended Sequence Numbers 5 (Optional in AH and ESP) 2279 RESERVED TO IANA 6-240 2280 PRIVATE USE 241-255 2282 For Transform Type 1 (Encryption Algorithm), defined Transform IDs 2283 are: 2285 Name Number Defined In 2286 RESERVED 0 2287 ENCR_DES_IV64 1 (RFC1827) 2288 ENCR_DES 2 (RFC2405) 2289 ENCR_3DES 3 (RFC2451) 2290 ENCR_RC5 4 (RFC2451) 2291 ENCR_IDEA 5 (RFC2451) 2292 ENCR_CAST 6 (RFC2451) 2293 ENCR_BLOWFISH 7 (RFC2451) 2294 ENCR_3IDEA 8 (RFC2451) 2295 ENCR_DES_IV32 9 2296 ENCR_RC4 10 2297 ENCR_NULL 11 (RFC2410) 2298 ENCR_AES_CBC 12 2299 ENCR_AES_CTR 13 2301 values 14-1023 are reserved to IANA. Values 1024-65535 are for 2302 private use among mutually consenting parties. 2304 For Transform Type 2 (Pseudo-random Function), defined Transform IDs 2305 are: 2307 Name Number Defined In 2308 RESERVED 0 2309 PRF_HMAC_MD5 1 (RFC2104) 2310 PRF_HMAC_SHA1 2 (RFC2104) 2311 PRF_HMAC_TIGER 3 (RFC2104) 2312 PRF_AES_CBC 4 2314 values 5-1023 are reserved to IANA. Values 1024-65535 are for 2315 private use among mutually consenting parties. 2317 For Transform Type 3 (Integrity Algorithm), defined Transform IDs 2318 are: 2320 Name Number Defined In 2321 NONE 0 2322 AUTH_HMAC_MD5_96 1 (RFC2403) 2323 AUTH_HMAC_SHA1_96 2 (RFC2404) 2324 AUTH_DES_MAC 3 2325 AUTH_KPDK_MD5 4 (RFC1826) 2326 AUTH_AES_XCBC_96 5 2328 values 6-1023 are reserved to IANA. Values 1024-65535 are for 2329 private use among mutually consenting parties. 2331 For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs 2332 are: 2334 Name Number 2335 NONE 0 2336 Defined in Appendix B 1 - 4 2337 Defined in [ADDGROUP] 5, 14 - 18 2338 values 6-13 and 19-1023 are reserved to IANA for new MODP, ECP 2339 or EC2N groups. Values 1024-65535 are for private use among 2340 mutually consenting parties. 2342 For Transform Type 5 (Extended Sequence Numbers), defined Transform 2343 IDs are: 2345 Name Number 2346 No Extended Sequence Numbers 0 2347 Extended Sequence Numbers 1 2348 RESERVED 2 - 65535 2350 If Transform Type 5 is not included in a proposal, use of 2351 Extended Sequence Numbers is assumed. 2353 3.3.3 Valid Transform Types by Protocol 2355 The number and type of transforms that accompany an SA payload are 2356 dependent on the protocol in the SA itself. An SA payload proposing 2357 the establishment of an SA has the following mandatory and optional 2358 transform types. A compliant implementation MUST understand all 2359 mandatory and optional types for each protocol it supports (though it 2360 need not accept proposals with unacceptable suites). A proposal MAY 2361 omit the optional types if the only value for them it will accept is 2362 NONE. 2364 Protocol Mandatory Types Optional Types 2365 IKE ENCR, PRF, INTEG, D-H 2366 ESP ENCR INTEG, D-H, ESN 2367 AH INTEG D-H, ESN 2369 3.3.4 Mandatory Transform IDs 2371 The specification of suites that MUST and SHOULD be supported for 2372 interoperability has been removed from this document because they are 2373 likely to change more rapidly than this document evolves. 2375 An important lesson learned from IKEv1 is that no system should only 2376 implement the mandatory algorithms and expect them to be the best 2377 choice for all customers. For example, at the time that this document 2378 was being written, many IKEv1 implementers are starting to migrate to 2379 AES in CBC mode for VPN applications. Many IPsec systems based on 2380 IKEv2 will implement AES, longer Diffie-Hellman keys, and additional 2381 hash algorithms, and some IPsec customers already require these 2382 algorithms in addition to the ones listed above. 2384 It is likely that IANA will add additional transforms in the future, 2385 and some users may want to use private suites, especially for IKE 2386 where implementations should be capable of supporting different 2387 parameters, up to certain size limits. In support of this goal, all 2388 implementations of IKEv2 SHOULD include a management facility that 2389 allows specification (by a user or system administrator) of Diffie- 2390 Hellman parameters (the generator, modulus, and exponent lengths and 2391 values) for new DH groups. Implementations SHOULD provide a 2392 management interface via which these parameters and the associated 2393 transform IDs may be entered (by a user or system administrator), to 2394 enable negotiating such groups. 2396 All implementations of IKEv2 MUST include a management facility that 2397 enables a user or system administrator to specify the suites that are 2398 acceptable for use with IKE. Upon receipt of a payload with a set of 2399 transform IDs, the implementation MUST compare the transmitted 2400 transform IDs against those locally configured via the management 2401 controls, to verify that the proposed suite is acceptable based on 2402 local policy. The implementation MUST reject SA proposals that are 2403 not authorized by these IKE suite controls. 2405 3.3.5 Transform Attributes 2407 Each transform in a Security Association payload may include 2408 attributes that modify or complete the specification of the 2409 transform. These attributes are type/value pairs and are defined 2410 below. For example, if an encryption algorithm has a variable length 2411 key, the key length to be used may be specified as an attribute. 2412 Attributes can have a value with a fixed two octet length or a 2413 variable length value. For the latter, the attribute is encoded as 2414 type/length/value. 2416 1 2 3 2417 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 2418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2419 !A! Attribute Type ! AF=0 Attribute Length ! 2420 !F! ! AF=1 Attribute Value ! 2421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2422 ! AF=0 Attribute Value ! 2423 ! AF=1 Not Transmitted ! 2424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2426 Figure 9: Data Attributes 2428 o Attribute Type (2 octets) - Unique identifier for each type of 2429 attribute (see below). 2431 The most significant bit of this field is the Attribute Format 2432 bit (AF). It indicates whether the data attributes follow the 2433 Type/Length/Value (TLV) format or a shortened Type/Value (TV) 2434 format. If the AF bit is zero (0), then the Data Attributes 2435 are of the Type/Length/Value (TLV) form. If the AF bit is a 2436 one (1), then the Data Attributes are of the Type/Value form. 2438 o Attribute Length (2 octets) - Length in octets of the Attribute 2439 Value. When the AF bit is a one (1), the Attribute Value is 2440 only 2 octets and the Attribute Length field is not present. 2442 o Attribute Value (variable length) - Value of the Attribute 2443 associated with the Attribute Type. If the AF bit is a 2444 zero (0), this field has a variable length defined by the 2445 Attribute Length field. If the AF bit is a one (1), the 2446 Attribute Value has a length of 2 octets. 2448 Note that only a single attribute type (Key Length) is defined, and 2449 it is fixed length. The variable length encoding specification is 2450 included only for future extensions. The only algorithms defined in 2451 this document that accept attributes are the AES based encryption, 2452 integrity, and pseudo-random functions, which require a single 2453 attribute specifying key width. 2455 Attributes described as basic MUST NOT be encoded using the variable 2456 length encoding. Variable length attributes MUST NOT be encoded as 2457 basic even if their value can fit into two octets. NOTE: This is a 2458 change from IKEv1, where increased flexibility may have simplified 2459 the composer of messages but certainly complicated the parser. 2461 Attribute Type value Attribute Format 2462 -------------------------------------------------------------- 2463 RESERVED 0-13 2464 Key Length (in bits) 14 TV 2465 RESERVED 15-17 2466 RESERVED TO IANA 18-16383 2467 PRIVATE USE 16384-32767 2469 Values 0-13 and 15-17 were used in a similar context in IKEv1, and 2470 should not be assigned except to matching values. Values 18-16383 are 2471 reserved to IANA. Values 16384-32767 are for private use among 2472 mutually consenting parties. 2474 - Key Length 2476 When using an Encryption Algorithm that has a variable length key, 2477 this attribute specifies the key length in bits. (MUST use network 2478 byte order). This attribute MUST NOT be used when the specified 2479 Encryption Algorithm uses a fixed length key. 2481 3.3.6 Attribute Negotiation 2482 During security association negotiation Initiators present offers to 2483 Responders. Responders MUST select a single complete set of 2484 parameters from the offers (or reject all offers if none are 2485 acceptable). If there are multiple proposals, the Responder MUST 2486 choose a single proposal number and return all of the Proposal 2487 substructures with that Proposal number. If there are multiple 2488 Transforms with the same type the Responder MUST choose a single one. 2489 Any attributes of a selected transform MUST be returned unmodified. 2490 The Initiator of an exchange MUST check that the accepted offer is 2491 consistent with one of its proposals, and if not that response MUST 2492 be rejected. 2494 Negotiating Diffie-Hellman groups presents some special challenges. 2495 SA offers include proposed attributes and a Diffie-Hellman public 2496 number (KE) in the same message. If in the initial exchange the 2497 Initiator offers to use one of several Diffie-Hellman groups, it 2498 SHOULD pick the one the Responder is most likely to accept and 2499 include a KE corresponding to that group. If the guess turns out to 2500 be wrong, the Responder will indicate the correct group in the 2501 response and the Initiator SHOULD pick an element of that group for 2502 its KE value when retrying the first message. It SHOULD, however, 2503 continue to propose its full supported set of groups in order to 2504 prevent a man in the middle downgrade attack. 2506 Implementation Note: 2508 Certain negotiable attributes can have ranges or could have 2509 multiple acceptable values. These include the key length of a 2510 variable key length symmetric cipher. To further interoperability 2511 and to support upgrading endpoints independently, implementers of 2512 this protocol SHOULD accept values which they deem to supply 2513 greater security. For instance if a peer is configured to accept a 2514 variable lengthed cipher with a key length of X bits and is 2515 offered that cipher with a larger key length, the implementation 2516 SHOULD accept the offer if it supports use of the longer key. 2518 Support of this capability allows an implementation to express a 2519 concept of "at least" a certain level of security-- "a key length of 2520 _at least_ X bits for cipher Y". 2522 3.4 Key Exchange Payload 2524 The Key Exchange Payload, denoted KE in this memo, is used to 2525 exchange Diffie-Hellman public numbers as part of a Diffie-Hellman 2526 key exchange. The Key Exchange Payload consists of the IKE generic 2527 payload header followed by the Diffie-Hellman public value itself. 2529 1 2 3 2530 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 2531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2532 ! Next Payload !C! RESERVED ! Payload Length ! 2533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2534 ! DH Group # ! RESERVED ! 2535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2536 ! ! 2537 ~ Key Exchange Data ~ 2538 ! ! 2539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2541 Figure 10: Key Exchange Payload Format 2543 A key exchange payload is constructed by copying one's Diffie-Hellman 2544 public value into the "Key Exchange Data" portion of the payload. 2545 The length of the Diffie-Hellman public value MUST be equal to the 2546 length of the prime modulus over which the exponentiation was 2547 performed, prepending zero bits to the value if necessary. 2549 The DH Group # identifies the Diffie-Hellman group in which the Key 2550 Exchange Data was computed (see section 3.3.2). If the selected 2551 proposal uses a different Diffie-Hellman group, the message MUST be 2552 rejected with a Notify payload of type INVALID_KE_PAYLOAD. 2554 The payload type for the Key Exchange payload is thirty four (34). 2556 3.5 Identification Payloads 2558 The Identification Payloads, denoted IDi and IDr in this memo, allow 2559 peers to assert an identity to one another. This identity may be used 2560 for policy lookup, but does not necessarily have to match anything in 2561 the CERT payload; both fields may be used by an implementation to 2562 perform access control decisions. 2564 NOTE: In IKEv1, two ID payloads were used in each direction to hold 2565 Traffic Selector information for data passing over the SA. In IKEv2, 2566 this information is carried in Traffic Selector (TS) payloads (see 2567 section 3.13). 2569 The Identification Payload consists of the IKE generic payload header 2570 followed by identification fields as follows: 2572 1 2 3 2573 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 2574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2575 ! Next Payload !C! RESERVED ! Payload Length ! 2576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2577 ! ID Type ! RESERVED | 2578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2579 ! ! 2580 ~ Identification Data ~ 2581 ! ! 2582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2584 Figure 11: Identification Payload Format 2586 o ID Type (1 octet) - Specifies the type of Identification being 2587 used. 2589 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 2591 o Identification Data (variable length) - Value, as indicated by 2592 the Identification Type. The length of the Identification Data 2593 is computed from the size in the ID payload header. 2595 The payload types for the Identification Payload are thirty five (35) 2596 for IDi and thirty six (36) for IDr. 2598 The following table lists the assigned values for the Identification 2599 Type field, followed by a description of the Identification Data 2600 which follows: 2602 ID Type Value 2603 ------- ----- 2604 RESERVED 0 2606 ID_IPV4_ADDR 1 2608 A single four (4) octet IPv4 address. 2610 ID_FQDN 2 2612 A fully-qualified domain name string. An example of a 2613 ID_FQDN is, "example.com". The string MUST not contain any 2614 terminators (e.g., NULL, CR, etc.). 2616 ID_RFC822_ADDR 3 2618 A fully-qualified RFC822 email address string, An example of 2619 a ID_RFC822_ADDR is, "jsmith@example.com". The string MUST 2620 not contain any terminators. 2622 ID_IPV6_ADDR 5 2624 A single sixteen (16) octet IPv6 address. 2626 ID_DER_ASN1_DN 9 2628 The binary DER encoding of an ASN.1 X.500 Distinguished Name 2629 [X.501]. 2631 ID_DER_ASN1_GN 10 2633 The binary DER encoding of an ASN.1 X.500 GeneralName 2634 [X.509]. 2636 ID_KEY_ID 11 2638 An opaque octet stream which may be used to pass an account 2639 name or to pass vendor-specific information necessary to do 2640 certain proprietary types of identification. 2642 Reserved to IANA 12-200 2644 Reserved for private use 201-255 2646 Two implementations will interoperate only if each can generate a 2647 type of ID acceptable to the other. To assure maximum 2648 interoperability, implementations MUST be configurable to send at 2649 least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and 2650 MUST be configurable to accept all of these types. Implementations 2651 SHOULD be capable of generating and accepting all of these types. 2653 3.6 Certificate Payload 2655 The Certificate Payload, denoted CERT in this memo, provides a means 2656 to transport certificates or other authentication related information 2657 via IKE. Certificate payloads SHOULD be included in an exchange if 2658 certificates are available to the sender unless the peer has 2659 indicated an ability to retrieve this information from elsewhere 2660 using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note that the 2661 term "Certificate Payload" is somewhat misleading, because not all 2662 authentication mechanisms use certificates and data other than 2663 certificates may be passed in this payload. 2665 The Certificate Payload is defined as follows: 2667 1 2 3 2668 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 2669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2670 ! Next Payload !C! RESERVED ! Payload Length ! 2671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2672 ! Cert Encoding ! ! 2673 +-+-+-+-+-+-+-+-+ ! 2674 ~ Certificate Data ~ 2675 ! ! 2676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2678 Figure 12: Certificate Payload Format 2680 o Certificate Encoding (1 octet) - This field indicates the type 2681 of certificate or certificate-related information contained 2682 in the Certificate Data field. 2684 Certificate Encoding Value 2685 -------------------- ----- 2686 RESERVED 0 2687 PKCS #7 wrapped X.509 certificate 1 2688 PGP Certificate 2 2689 DNS Signed Key 3 2690 X.509 Certificate - Signature 4 2691 Kerberos Token 6 2692 Certificate Revocation List (CRL) 7 2693 Authority Revocation List (ARL) 8 2694 SPKI Certificate 9 2695 X.509 Certificate - Attribute 10 2696 Raw RSA Key 11 2697 Hash and URL of X.509 certificate 12 2698 Hash and URL of X.509 bundle 13 2699 RESERVED to IANA 14 - 200 2700 PRIVATE USE 201 - 255 2702 o Certificate Data (variable length) - Actual encoding of 2703 certificate data. The type of certificate is indicated 2704 by the Certificate Encoding field. 2706 The payload type for the Certificate Payload is thirty seven (37). 2708 Specific syntax is for some of the certificate type codes above is 2709 not defined in this document. The types whose syntax is defined in 2710 this document are: 2712 X.509 Certificate - Signature (4) contains a BER encoded X.509 2713 certificate whose public key is used to validate the sender's AUTH 2714 payload. 2716 Certificate Revocation List (7) contains a BER encoded X.509 2717 certificate revocation list. 2719 Raw RSA Key (11) contains a PKCS #1 encoded RSA key. 2721 Hash and URL encodings (12-13) allow IKE messages to remain short 2722 by replacing long data structures with a 20 octet SHA-1 hash of 2723 the replaced value followed by a variable length URL that resolves 2724 to the BER encoded data structure itself. This improves efficiency 2725 when the endpoints have certificate data cached and makes IKE less 2726 subject to denial of service attacks that become easier to mount 2727 when IKE messages are large enough to require IP fragmentation 2728 [KPS03]. 2730 Use the following ASN.1 definition for an X.509 bundle: 2732 CertBundle 2733 { iso(1) identified-organization(3) dod(6) internet(1) 2734 security(5) mechanisms(5) pkix(7) id-mod(0) 2735 id-mod-cert-bundle(TBD) } 2737 DEFINITIONS EXPLICIT TAGS ::= 2738 BEGIN 2740 IMPORTS 2741 Certificate, CertificateList 2742 FROM PKIX1Explicit88 2743 { iso(1) identified-organization(3) dod(6) 2744 internet(1) security(5) mechanisms(5) pkix(7) 2745 id-mod(0) id-pkix1-explicit(18) } ; 2747 CertificateOrCRL ::= CHOICE { 2748 cert [0] Certificate, 2749 crl [1] CertificateList } 2751 CertificateBundle ::= SEQUENCE OF CertificateOrCRL 2753 END 2755 Implementations MUST be capable of being configured to send and 2756 accept up to four X.509 certificates in support of authentication. 2757 Implementations SHOULD be capable of being configured to send and 2758 accept Raw RSA keys and the first two Hash and URL formats. If 2759 multiple certificates are sent, the first certificate MUST contain 2760 the public key used to sign the AUTH payload. The other certificates 2761 may be sent in any order. 2763 3.7 Certificate Request Payload 2765 The Certificate Request Payload, denoted CERTREQ in this memo, 2766 provides a means to request preferred certificates via IKE and can 2767 appear in the IKE_INIT_SA response and/or the IKE_AUTH request. 2768 Certificate Request payloads MAY be included in an exchange when the 2769 sender needs to get the certificate of the receiver. If multiple CAs 2770 are trusted and the cert encoding does not allow a list, then 2771 multiple Certificate Request payloads SHOULD be transmitted. 2773 The Certificate Request Payload is defined as follows: 2775 1 2 3 2776 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 2777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2778 ! Next Payload !C! RESERVED ! Payload Length ! 2779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2780 ! Cert Encoding ! ! 2781 +-+-+-+-+-+-+-+-+ ! 2782 ~ Certification Authority ~ 2783 ! ! 2784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2786 Figure 13: Certificate Request Payload Format 2788 o Certificate Encoding (1 octet) - Contains an encoding of the type 2789 or format of certificate requested. Values are listed in section 2790 3.6. 2792 o Certification Authority (variable length) - Contains an encoding 2793 of an acceptable certification authority for the type of 2794 certificate requested. 2796 The payload type for the Certificate Request Payload is thirty eight 2797 (38). 2799 The Certificate Encoding field has the same values as those defined 2800 in section 3.6. The Certification Authority field contains an 2801 indicator of trusted authorities for this certificate type. The 2802 Certification Authority value is a concatenated list of SHA-1 hashes 2803 of the public keys of trusted CAs. Each is encoded as the SHA-1 hash 2804 of the Subject Public Key Info element (see section 4.1.2.7 of [RFC 2805 3280]) from each Trust Anchor certificate. The twenty-octet hashes 2806 are concatenated and included with no other formatting. 2808 Note that the term "Certificate Request" is somewhat misleading, in 2809 that values other than certificates are defined in a "Certificate" 2810 payload and requests for those values can be present in a Certificate 2811 Request Payload. The syntax of the Certificate Request payload in 2812 such cases is not defined in this document. 2814 The Certificate Request Payload is processed by inspecting the "Cert 2815 Encoding" field to determine whether the processor has any 2816 certificates of this type. If so the "Certification Authority" field 2817 is inspected to determine if the processor has any certificates which 2818 can be validated up to one of the specified certification 2819 authorities. This can be a chain of certificates. If a certificate 2820 exists which satisfies the criteria specified in the Certificate 2821 Request Payload, the certificate MUST be sent back to the certificate 2822 requestor; if a certificate chain exists which goes back to the 2823 certification authority specified in the request the entire chain 2824 SHOULD be sent back to the certificate requestor. If multiple 2825 certificates or chains exist that satisfy the request, the sender 2826 MUST pick one. If no certificates exist then the Certificate Request 2827 Payload is ignored. This is not an error condition of the protocol. 2828 There may be cases where there is a preferred CA, but an alternate 2829 might be acceptable (perhaps after prompting a human operator). 2831 3.8 Authentication Payload 2833 The Authentication Payload, denoted AUTH in this memo, contains data 2834 used for authentication purposes. The syntax of the Authentication 2835 data varies according to the Auth Method as specified below. 2837 The Authentication Payload is defined as follows: 2839 1 2 3 2840 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 2841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2842 ! Next Payload !C! RESERVED ! Payload Length ! 2843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2844 ! Auth Method ! RESERVED ! 2845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2846 ! ! 2847 ~ Authentication Data ~ 2848 ! ! 2849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2851 Figure 14: Authentication Payload Format 2853 o Auth Method (1 octet) - Specifies the method of authentication 2854 used. Values defined are: 2856 RSA Digital Signature (1) - Computed as specified in section 2857 2.15 using an RSA private key over a PKCS#1 padded hash. 2859 Shared Key Message Integrity Code (2) - Computed as specified in 2860 section 2.15 using the shared key associated with the identity 2861 in the ID payload and the negotiated prf function 2863 DSS Digital Signature (3) - Computed as specified in section 2864 2.15 using a DSS private key over a SHA-1 hash. 2866 The values 0 and 4-200 are reserved to IANA. The values 201-255 2867 are available for private use. 2869 o Authentication Data (variable length) - see section 2.15. 2871 The payload type for the Authentication Payload is thirty nine (39). 2873 3.9 Nonce Payload 2875 The Nonce Payload, denoted Ni and Nr in this memo for the Initiator's 2876 and Responder's nonce respectively, contains random data used to 2877 guarantee liveness during an exchange and protect against replay 2878 attacks. 2880 The Nonce Payload is defined as follows: 2882 1 2 3 2883 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 2884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2885 ! Next Payload !C! RESERVED ! Payload Length ! 2886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2887 ! ! 2888 ~ Nonce Data ~ 2889 ! ! 2890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2892 Figure 15: Nonce Payload Format 2894 o Nonce Data (variable length) - Contains the random data generated 2895 by the transmitting entity. 2897 The payload type for the Nonce Payload is forty (40). 2899 The size of a Nonce MUST be between 16 and 256 octets inclusive. 2900 Nonce values MUST NOT be reused. 2902 3.10 Notify Payload 2904 The Notify Payload, denoted N in this document, is used to transmit 2905 informational data, such as error conditions and state transitions, 2906 to an IKE peer. A Notify Payload may appear in a response message 2907 (usually specifying why a request was rejected), in an INFORMATIONAL 2908 Exchange (to report an error not in an IKE request), or in any other 2909 message to indicate sender capabilities or to modify the meaning of 2910 the request. 2912 The Notify Payload is defined as follows: 2914 1 2 3 2915 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 2916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2917 ! Next Payload !C! RESERVED ! Payload Length ! 2918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2919 ! Protocol ID ! SPI Size ! Notify Message Type ! 2920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2921 ! ! 2922 ~ Security Parameter Index (SPI) ~ 2923 ! ! 2924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2925 ! ! 2926 ~ Notification Data ~ 2927 ! ! 2928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2930 Figure 16: Notification Payload Format 2932 o Protocol ID (1 octet) - If this notification concerns 2933 an existing SA, this field indicates the type of that SA. 2934 For IKE_SA notifications, this field MUST be one (1). For 2935 notifications concerning IPsec SAs this field MUST contain 2936 either (2) to indicate AH or (3) to indicate ESP. For 2937 notifications which do not relate to an existing SA, this 2938 field MUST be sent as zero and MUST be ignored on receipt. 2939 All other values for this field are reserved to IANA for future 2940 assignment. 2942 o SPI Size (1 octet) - Length in octets of the SPI as defined by 2943 the IPsec protocol ID or zero if no SPI is applicable. For a 2944 notification concerning the IKE_SA, the SPI Size MUST be zero. 2946 o Notify Message Type (2 octets) - Specifies the type of 2947 notification message. 2949 o SPI (variable length) - Security Parameter Index. 2951 o Notification Data (variable length) - Informational or error data 2952 transmitted in addition to the Notify Message Type. Values for 2953 this field are type specific (see below). 2955 The payload type for the Notification Payload is forty one (41). 2957 3.10.1 Notify Message Types 2959 Notification information can be error messages specifying why an SA 2960 could not be established. It can also be status data that a process 2961 managing an SA database wishes to communicate with a peer process. 2962 The table below lists the Notification messages and their 2963 corresponding values. The number of different error statuses was 2964 greatly reduced from IKE V1 both for simplification and to avoid 2965 giving configuration information to probers. 2967 Types in the range 0 - 16383 are intended for reporting errors. An 2968 implementation receiving a Notify payload with one of these types 2969 that it does not recognize in a response MUST assume that the 2970 corresponding request has failed entirely. Unrecognized error types 2971 in a request and status types in a request or response MUST be 2972 ignored except that they SHOULD be logged. 2974 Notify payloads with status types MAY be added to any message and 2975 MUST be ignored if not recognized. They are intended to indicate 2976 capabilities, and as part of SA negotiation are used to negotiate 2977 non-cryptographic parameters. 2979 NOTIFY MESSAGES - ERROR TYPES Value 2980 ----------------------------- ----- 2981 UNSUPPORTED_CRITICAL_PAYLOAD 1 2983 Sent if the payload has the "critical" bit set and the 2984 payload type is not recognized. Notification Data contains 2985 the one octet payload type. 2987 INVALID_IKE_SPI 4 2989 Indicates an IKE message was received with an unrecognized 2990 destination SPI. This usually indicates that the recipient 2991 has rebooted and forgotten the existence of an IKE_SA. 2993 INVALID_MAJOR_VERSION 5 2995 Indicates the recipient cannot handle the version of IKE 2996 specified in the header. The closest version number that the 2997 recipient can support will be in the reply header. 2999 INVALID_SYNTAX 7 3001 Indicates the IKE message was received was invalid because 3002 some type, length, or value was out of range or because the 3003 request was rejected for policy reasons. To avoid a denial 3004 of service attack using forged messages, this status may 3005 only be returned for and in an encrypted packet if the 3006 message ID and cryptographic checksum were valid. To avoid 3007 leaking information to someone probing a node, this status 3008 MUST be sent in response to any error not covered by one of 3009 the other status types. To aid debugging, more detailed 3010 error information SHOULD be written to a console or log. 3012 INVALID_MESSAGE_ID 9 3014 Sent when an IKE message ID outside the supported window is 3015 received. This Notify MUST NOT be sent in a response; the 3016 invalid request MUST NOT be acknowledged. Instead, inform 3017 the other side by initiating an INFORMATIONAL exchange with 3018 Notification data containing the four octet invalid message 3019 ID. Sending this notification is optional and notifications 3020 of this type MUST be rate limited. 3022 INVALID_SPI 11 3024 MAY be sent in an IKE INFORMATIONAL Exchange when a node 3025 receives an ESP or AH packet with an invalid SPI. The 3026 Notification Data contains the SPI of the invalid packet. 3027 This usually indicates a node has rebooted and forgotten an 3028 SA. If this Informational Message is sent outside the 3029 context of an IKE_SA, it should only be used by the 3030 recipient as a "hint" that something might be wrong (because 3031 it could easily be forged). 3033 NO_PROPOSAL_CHOSEN 14 3035 None of the proposed crypto suites was acceptable. 3037 INVALID_KE_PAYLOAD 17 3039 The D-H Group # field in the KE payload is not the group # 3040 selected by the responder for this exchange. There are two 3041 octets of data associated with this notification: the 3042 accepted D-H Group # in big endian order. 3044 AUTHENTICATION_FAILED 24 3046 Sent in the response to an IKE_AUTH message when for some 3047 reason the authentication failed. There is no associated 3048 data. 3050 SINGLE_PAIR_REQUIRED 34 3052 This error indicates that a CREATE_CHILD_SA request is 3053 unacceptable because its sender is only willing to accept 3054 traffic selectors specifying a single pair of addresses. 3055 The requestor is expected to respond by requesting an SA for 3056 only the specific traffic he is trying to forward. 3058 NO_ADDITIONAL_SAS 35 3060 This error indicates that a CREATE_CHILD_SA request is 3061 unacceptable because the Responder is unwilling to accept 3062 any more CHILD_SAs on this IKE_SA. Some minimal 3063 implementations may only accept a single CHILD_SA setup in 3064 the context of an initial IKE exchange and reject any 3065 subsequent attempts to add more. 3067 INTERNAL_ADDRESS_FAILURE 36 3069 Indicates an error assigning an internal address (i.e., 3070 INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS) during the 3071 processing of a Configuration Payload by a Responder. If 3072 this error is generated within an IKE_AUTH exchange no 3073 CHILD_SA will be created. 3075 FAILED_CP_REQUIRED 37 3077 Sent by responder in the case where CP(CFG_REQUEST) was 3078 expected but not received, and so is a conflict with locally 3079 configured policy. There is no associated data. 3081 TS_UNACCEPTABLE 38 3083 Indicates that none of the addresses/protocols/ports in the 3084 supplied traffic selectors is acceptable. 3086 INVALID_SELECTORS 39 3088 MAY be sent in an IKE INFORMATIONAL Exchange when a node 3089 receives an ESP or AH packet whose selectors do not match 3090 those of the SA on which it was delivered (and which caused 3091 the packet to be dropped). The Notification Data contains 3092 the start of the offending packet (as in ICMP messages) and 3093 the SPI field of the notification is set to match the SPI of 3094 the IPsec SA. 3096 RESERVED TO IANA - Error types 39 - 8191 3098 Private Use - Errors 8192 - 16383 3100 NOTIFY MESSAGES - STATUS TYPES Value 3101 ------------------------------ ----- 3103 INITIAL_CONTACT 16384 3105 This notification asserts that this IKE_SA is the only 3106 IKE_SA currently active between the authenticated 3107 identities. It MAY be sent when an IKE_SA is established 3108 after a crash, and the recipient MAY use this information to 3109 delete any other IKE_SAs it has to the same authenticated 3110 identity without waiting for a timeout. This notification 3111 MUST NOT be sent by an entity that may be replicated (e.g., 3112 a roaming user's credentials where the user is allowed to 3113 connect to the corporate firewall from two remote systems at 3114 the same time). 3116 SET_WINDOW_SIZE 16385 3118 This notification asserts that the sending endpoint is 3119 capable of keeping state for multiple outstanding exchanges, 3120 permitting the recipient to send multiple requests before 3121 getting a response to the first. The data associated with a 3122 SET_WINDOW_SIZE notification MUST be 4 octets long and 3123 contain the big endian representation of the number of 3124 messages the sender promises to keep. Window size is always 3125 one until the initial exchanges complete. 3127 ADDITIONAL_TS_POSSIBLE 16386 3129 This notification asserts that the sending endpoint narrowed 3130 the proposed traffic selectors but that other traffic 3131 selectors would also have been acceptable, though only in a 3132 separate SA (see section 2.9). There is no data associated 3133 with this Notify type. It may only be sent as an additional 3134 payload in a message including accepted TSs. 3136 IPCOMP_SUPPORTED 16387 3138 This notification may only be included in a message 3139 containing an SA payload negotiating a CHILD_SA and 3140 indicates a willingness by its sender to use IPComp on this 3141 SA. The data associated with this notification includes a 3142 two octet IPComp CPI followed by a one octet transform ID 3143 optionally followed by attributes whose length and format is 3144 defined by that transform ID. A message proposing an SA may 3145 contain multiple IPCOMP_SUPPORTED notifications to indicate 3146 multiple supported algorithms. A message accepting an SA may 3147 contain at most one. 3149 The transform IDs currently defined are: 3151 NAME NUMBER DEFINED IN 3152 ----------- ------ ----------- 3153 RESERVED 0 3154 IPCOMP_OUI 1 3155 IPCOMP_DEFLATE 2 RFC 2394 3156 IPCOMP_LZS 3 RFC 2395 3157 IPCOMP_LZJH 4 RFC 3051 3159 values 5-240 are reserved to IANA. Values 241-255 are 3160 for private use among mutually consenting parties. 3162 NAT_DETECTION_SOURCE_IP 16388 3164 This notification is used by its recipient to determine 3165 whether the source is behind a NAT box. The data associated 3166 with this notification is a SHA-1 digest of the SPIs (in the 3167 order they appear in the header), IP address and port on 3168 which this packet was sent. There MAY be multiple Notify 3169 payloads of this type in a message if the sender does not 3170 know which of several network attachments will be used to 3171 send the packet. The recipient of this notification MAY 3172 compare the supplied value to a SHA-1 hash of the SPIs, 3173 source IP address and port and if they don't match it SHOULD 3174 enable NAT traversal (see section 2.23). Alternately, it 3175 MAY reject the connection attempt if NAT traversal is not 3176 supported. 3178 NAT_DETECTION_DESTINATION_IP 16389 3180 This notification is used by its recipient to determine 3181 whether it is behind a NAT box. The data associated with 3182 this notification is a SHA-1 digest of the SPIs (in the 3183 order they appear in the header), IP address and port to 3184 which this packet was sent. The recipient of this 3185 notification MAY compare the supplied value to a hash of the 3186 SPIs, destination IP address and port and if they don't 3187 match it SHOULD invoke NAT traversal (see section 2.23). If 3188 they don't match, it means that this end is behind a NAT and 3189 this end SHOULD start start sending keepalive packets as 3190 defined in [Hutt04]. Alternately, it MAY reject the 3191 connection attempt if NAT traversal is not supported. 3193 COOKIE 16390 3195 This notification MAY be included in an IKE_SA_INIT 3196 response. It indicates that the request should be retried 3197 with a copy of this notification as the first payload. This 3198 notification MUST be included in an IKE_SA_INIT request 3199 retry if a COOKIE notification was included in the initial 3200 response. The data associated with this notification MUST 3201 be between 1 and 64 octets in length (inclusive). 3203 USE_TRANSPORT_MODE 16391 3205 This notification MAY be included in a request message that 3206 also includes an SA requesting a CHILD_SA. It requests that 3207 the CHILD_SA use transport mode rather than tunnel mode for 3208 the SA created. If the request is accepted, the response 3209 MUST also include a notification of type USE_TRANSPORT_MODE. 3210 If the responder declines the request, the CHILD_SA will be 3211 established in tunnel mode. If this is unacceptable to the 3212 initiator, the initiator MUST delete the SA. Note: except 3213 when using this option to negotiate transport mode, all 3214 CHILD_SAs will use tunnel mode. 3216 Note: The ECN decapsulation modifications specified in 3217 [RFC2401bis] MUST be performed for every tunnel mode SA 3218 created by IKEv2. 3220 HTTP_CERT_LOOKUP_SUPPORTED 16392 3222 This notification MAY be included in any message that can 3223 include a CERTREQ payload and indicates that the sender is 3224 capable of looking up certificates based on an HTTP-based 3225 URL (and hence presumably would prefer to receive 3226 certificate specifications in that format). 3228 REKEY_SA 16393 3230 This notification MUST be included in a CREATE_CHILD_SA 3231 exchange if the purpose of the exchange is to replace an 3232 existing ESP or AH SA. The SPI field identifies the SA being 3233 rekeyed. There is no data. 3235 ESP_TFC_PADDING_NOT_SUPPORTED 16394 3237 This notification asserts that the sending endpoint will NOT 3238 accept packets that contain Flow Confidentiality (TFC) 3239 padding. 3241 RESERVED TO IANA - STATUS TYPES 16395 - 40959 3243 Private Use - STATUS TYPES 40960 - 65535 3245 3.11 Delete Payload 3247 The Delete Payload, denoted D in this memo, contains a protocol 3248 specific security association identifier that the sender has removed 3249 from its security association database and is, therefore, no longer 3250 valid. Figure 17 shows the format of the Delete Payload. It is 3251 possible to send multiple SPIs in a Delete payload, however, each SPI 3252 MUST be for the same protocol. Mixing of protocol identifiers MUST 3253 NOT be performed in a the Delete payload. It is permitted, however, 3254 to include multiple Delete payloads in a single INFORMATIONAL 3255 Exchange where each Delete payload lists SPIs for a different 3256 protocol. 3258 Deletion of the IKE_SA is indicated by a protocol ID of 1 (IKE) but 3259 no SPIs. Deletion of a CHILD_SA, such as ESP or AH, will contain the 3260 IPsec protocol ID of that protocol (2 for AH, 3 for ESP) and the SPI 3261 is the SPI the sending endpoint would expect in inbound ESP or AH 3262 packets. 3264 The Delete Payload is defined as follows: 3266 1 2 3 3267 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 3268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3269 ! Next Payload !C! RESERVED ! Payload Length ! 3270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3271 ! Protocol ID ! SPI Size ! # of SPIs ! 3272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3273 ! ! 3274 ~ Security Parameter Index(es) (SPI) ~ 3275 ! ! 3276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3278 Figure 17: Delete Payload Format 3280 o Protocol ID (1 octet) - Must be 1 for an IKE_SA, 2 for AH, or 3281 3 for ESP. 3283 o SPI Size (1 octet) - Length in octets of the SPI as defined by 3284 the protocol ID. It MUST be zero for IKE (SPI is in message 3285 header) or four for AH and ESP. 3287 o # of SPIs (2 octets) - The number of SPIs contained in the Delete 3288 payload. The size of each SPI is defined by the SPI Size field. 3290 o Security Parameter Index(es) (variable length) - Identifies the 3291 specific security association(s) to delete. The length of this 3292 field is determined by the SPI Size and # of SPIs fields. 3294 The payload type for the Delete Payload is forty two (42). 3296 3.12 Vendor ID Payload 3298 The Vendor ID Payload contains a vendor defined constant. The 3299 constant is used by vendors to identify and recognize remote 3300 instances of their implementations. This mechanism allows a vendor 3301 to experiment with new features while maintaining backwards 3302 compatibility. 3304 A Vendor ID payload MAY announce that the sender is capable to 3305 accepting certain extensions to the protocol, or it MAY simply 3306 identify the implementation as an aid in debugging. A Vendor ID 3307 payload MUST NOT change the interpretation of any information defined 3308 in this specification (i.e., it MUST be non-critical). Multiple 3309 Vendor ID payloads MAY be sent. An implementation is NOT REQUIRED to 3310 send any Vendor ID payload at all. 3312 A Vendor ID payload may be sent as part of any message. Reception of 3313 a familiar Vendor ID payload allows an implementation to make use of 3314 Private USE numbers described throughout this memo-- private 3315 payloads, private exchanges, private notifications, etc. Unfamiliar 3316 Vendor IDs MUST be ignored. 3318 Writers of Internet-Drafts who wish to extend this protocol MUST 3319 define a Vendor ID payload to announce the ability to implement the 3320 extension in the Internet-Draft. It is expected that Internet-Drafts 3321 which gain acceptance and are standardized will be given "magic 3322 numbers" out of the Future Use range by IANA and the requirement to 3323 use a Vendor ID will go away. 3325 The Vendor ID Payload fields are defined as follows: 3327 1 2 3 3328 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 3329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3330 ! Next Payload !C! RESERVED ! Payload Length ! 3331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3332 ! ! 3333 ~ Vendor ID (VID) ~ 3334 ! ! 3335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3337 Figure 18: Vendor ID Payload Format 3339 o Vendor ID (variable length) - It is the responsibility of 3340 the person choosing the Vendor ID to assure its uniqueness 3341 in spite of the absence of any central registry for IDs. 3342 Good practice is to include a company name, a person name 3343 or some such. If you want to show off, you might include 3344 the latitude and longitude and time where you were when 3345 you chose the ID and some random input. A message digest 3346 of a long unique string is preferable to the long unique 3347 string itself. 3349 The payload type for the Vendor ID Payload is forty three (43). 3351 3.13 Traffic Selector Payload 3353 The Traffic Selector Payload, denoted TS in this memo, allows peers 3354 to identify packet flows for processing by IPsec security services. 3355 The Traffic Selector Payload consists of the IKE generic payload 3356 header followed by individual traffic selectors as follows: 3358 1 2 3 3359 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 3360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3361 ! Next Payload !C! RESERVED ! Payload Length ! 3362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3363 ! Number of TSs ! RESERVED ! 3364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3365 ! ! 3366 ~ ~ 3367 ! ! 3368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3370 Figure 19: Traffic Selectors Payload Format 3372 o Number of TSs (1 octet) - Number of traffic selectors 3373 being provided. 3375 o RESERVED - This field MUST be sent as zero and MUST be ignored 3376 on receipt. 3378 o Traffic Selectors (variable length) - one or more individual 3379 traffic selectors. 3381 The length of the Traffic Selector payload includes the TS header and 3382 all the traffic selectors. 3384 The payload type for the Traffic Selector payload is forty four (44) 3385 for addresses at the initiator's end of the SA and forty five (45) 3386 for addresses at the responder's end. 3388 3.13.1 Traffic Selector 3390 1 2 3 3391 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 3392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3393 ! TS Type !IP Protocol ID*| Selector Length | 3394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3395 | Start Port* | End Port* | 3396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3397 ! ! 3398 ~ Starting Address* ~ 3399 ! ! 3400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3401 ! ! 3402 ~ Ending Address* ~ 3403 ! ! 3404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3406 Figure 20: Traffic Selector 3408 *Note: all fields other than TS Type and Selector Length depend on 3409 the TS Type. The fields shown are for TS Types 7 and 8, the only two 3410 values currently defined. 3412 o TS Type (one octet) - Specifies the type of traffic selector. 3414 o IP protocol ID (1 octet) - Value specifying an associated IP 3415 protocol ID (e.g., UDP/TCP/ICMP). A value of zero means that 3416 the protocol ID is not relevant to this traffic selector-- 3417 the SA can carry all protocols. 3419 o Selector Length - Specifies the length of this Traffic 3420 Selector Substructure including the header. 3422 o Start Port (2 octets) - Value specifying the smallest port 3423 number allowed by this Traffic Selector. For protocols for 3424 which port is undefined, or if all ports are allowed or 3425 port is OPAQUE, this field MUST be zero. For the 3426 ICMP protocol, the two one octet fields Type and Code are 3427 treated as a single 16 bit integer (with Type in the most 3428 significant eight bits and Code in the least significant 3429 eight bits) port number for the purposes of filtering based 3430 on this field. 3432 o End Port (2 octets) - Value specifying the largest port 3433 number allowed by this Traffic Selector. For protocols for 3434 which port is undefined, or if all ports are allowed or 3435 port is OPAQUE, this field MUST be 65535. For the 3436 ICMP protocol, the two one octet fields Type and Code are 3437 treated as a single 16 bit integer (with Type in the most 3438 significant eight bits and Code in the least significant 3439 eight bits) port number for the purposed of filtering based 3440 on this field. 3442 o Starting Address - The smallest address included in this 3443 Traffic Selector (length determined by TS type). 3445 o Ending Address - The largest address included in this 3446 Traffic Selector (length determined by TS type). 3448 The following table lists the assigned values for the Traffic 3449 Selector Type field and the corresponding Address Selector Data. 3451 TS Type Value 3452 ------- ----- 3453 RESERVED 0-6 3455 TS_IPV4_ADDR_RANGE 7 3457 A range of IPv4 addresses, represented by two four (4) octet 3458 values. The first value is the beginning IPv4 address 3459 (inclusive) and the second value is the ending IPv4 address 3460 (inclusive). All addresses falling between the two specified 3461 addresses are considered to be within the list. 3463 TS_IPV6_ADDR_RANGE 8 3465 A range of IPv6 addresses, represented by two sixteen (16) 3466 octet values. The first value is the beginning IPv6 address 3467 (inclusive) and the second value is the ending IPv6 address 3468 (inclusive). All addresses falling between the two specified 3469 addresses are considered to be within the list. 3471 RESERVED TO IANA 9-240 3472 PRIVATE USE 241-255 3474 3.14 Encrypted Payload 3476 The Encrypted Payload, denoted SK{...} in this memo, contains other 3477 payloads in encrypted form. The Encrypted Payload, if present in a 3478 message, MUST be the last payload in the message. Often, it is the 3479 only payload in the message. 3481 The algorithms for encryption and integrity protection are negotiated 3482 during IKE_SA setup, and the keys are computed as specified in 3483 sections 2.14 and 2.18. 3485 The encryption and integrity protection algorithms are modelled after 3486 the ESP algorithms described in RFCs 2104, 2406, 2451. This document 3487 completely specifies the cryptographic processing of IKE data, but 3488 those documents should be consulted for design rationale. We assume a 3489 block cipher with a fixed block size and an integrity check algorithm 3490 that computes a fixed length checksum over a variable size message. 3492 The payload type for an Encrypted payload is forty six (46). The 3493 Encrypted Payload consists of the IKE generic payload header followed 3494 by individual fields as follows: 3496 1 2 3 3497 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 3498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3499 ! Next Payload !C! RESERVED ! Payload Length ! 3500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3501 ! Initialization Vector ! 3502 ! (length is block size for encryption algorithm) ! 3503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3504 ! Encrypted IKE Payloads ! 3505 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3506 ! ! Padding (0-255 octets) ! 3507 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 3508 ! ! Pad Length ! 3509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3510 ~ Integrity Checksum Data ~ 3511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3513 Figure 21: Encrypted Payload Format 3515 o Next Payload - The payload type of the first embedded payload. 3516 Note that this is an exception in the standard header format, 3517 since the Encrypted payload is the last payload in the 3518 message and therefore the Next Payload field would normally 3519 be zero. But because the content of this payload is embedded 3520 payloads and there was no natural place to put the type of 3521 the first one, that type is placed here. 3523 o Payload Length - Includes the lengths of the header, IV, 3524 Encrypted IKE Payloads, Padding, Pad Length and Integrity 3525 Checksum Data. 3527 o Initialization Vector - A randomly chosen value whose length 3528 is equal to the block length of the underlying encryption 3529 algorithm. Recipients MUST accept any value. Senders SHOULD 3530 either pick this value pseudo-randomly and independently for 3531 each message or use the final ciphertext block of the previous 3532 message sent. Senders MUST NOT use the same value for each 3533 message, use a sequence of values with low hamming distance 3534 (e.g., a sequence number), or use ciphertext from a received 3535 message. 3537 o IKE Payloads are as specified earlier in this section. This 3538 field is encrypted with the negotiated cipher. 3540 o Padding MAY contain any value chosen by the sender, and MUST 3541 have a length that makes the combination of the Payloads, the 3542 Padding, and the Pad Length to be a multiple of the encryption 3543 block size. This field is encrypted with the negotiated 3544 cipher. 3546 o Pad Length is the length of the Padding field. The sender 3547 SHOULD set the Pad Length to the minimum value that makes 3548 the combination of the Payloads, the Padding, and the Pad 3549 Length a multiple of the block size, but the recipient MUST 3550 accept any length that results in proper alignment. This 3551 field is encrypted with the negotiated cipher. 3553 o Integrity Checksum Data is the cryptographic checksum of 3554 the entire message starting with the Fixed IKE Header 3555 through the Pad Length. The checksum MUST be computed over 3556 the encrypted message. Its length is determined by the 3557 integrity algorithm negotiated. 3559 3.15 Configuration Payload 3561 The Configuration payload, denoted CP in this document, is used to 3562 exchange configuration information between IKE peers. The exchange is 3563 for an IRAC to request an internal IP address from an IRAS and to 3564 exchange other information of the sort that one would acquire with 3565 DHCP if the IRAC were directly connected to a LAN. 3567 Configuration payloads are of type CFG_REQUEST/CFG_REPLY or 3568 CFG_SET/CFG_ACK (see CFG Type in the payload description below). 3569 CFG_REQUEST and CFG_SET payloads may optionally be added to any IKE 3570 request. The IKE response MUST include either a corresponding 3571 CFG_REPLY or CFG_ACK or a Notify payload with an error type 3572 indicating why the request could not be honored. An exception is that 3573 a minimal implementation MAY ignore all CFG_REQUEST and CFG_SET 3574 payloads, so a response message without a corresponding CFG_REPLY or 3575 CFG_ACK MUST be accepted as an indication that the request was not 3576 supported. 3578 "CFG_REQUEST/CFG_REPLY" allows an IKE endpoint to request information 3579 from its peer. If an attribute in the CFG_REQUEST Configuration 3580 Payload is not zero length it is taken as a suggestion for that 3581 attribute. The CFG_REPLY Configuration Payload MAY return that 3582 value, or a new one. It MAY also add new attributes and not include 3583 some requested ones. Requestors MUST ignore returned attributes that 3584 they do not recognize. 3586 Some attributes MAY be multi-valued, in which case multiple attribute 3587 values of the same type are sent and/or returned. Generally, all 3588 values of an attribute are returned when the attribute is requested. 3589 For some attributes (in this version of the specification only 3590 internal addresses), multiple requests indicates a request that 3591 multiple values be assigned. For these attributes, the number of 3592 values returned SHOULD NOT exceed the number requested. 3594 If the data type requested in a CFG_REQUEST is not recognized or not 3595 supported, the responder MUST NOT return an error type but rather 3596 MUST either send a CFG_REPLY which MAY be empty or a reply not 3597 containing a CFG_REPLY payload at all. Error returns are reserved for 3598 cases where the request is recognized but cannot be performed as 3599 requested or the request is badly formatted. 3601 "CFG_SET/CFG_ACK" allows an IKE endpoint to push configuration data 3602 to its peer. In this case the CFG_SET Configuration Payload contains 3603 attributes the initiator wants its peer to alter. The responder MUST 3604 return a Configuration Payload if it accepted any of the 3605 configuration data and it MUST contain the attributes that the 3606 responder accepted with zero length data. Those attributes that it 3607 did not accept MUST NOT be in the CFG_ACK Configuration Payload. If 3608 no attributes were accepted, the responder MUST return either an 3609 empty CFG_ACK payload or a response message without a CFG_ACK 3610 payload. There are currently no defined uses for the CFG_SET/CFG_ACK 3611 exchange, though they may be used in connection with extensions based 3612 on Vendor IDs. An minimal implementation of this specification MAY 3613 ignore CFG_SET payloads. 3615 Extensions via the CP payload SHOULD NOT be used for general purpose 3616 management. Its main intent is to provide a bootstrap mechanism to 3617 exchange information within IPsec from IRAS to IRAC. While it MAY be 3618 useful to use such a method to exchange information between some 3619 Security Gateways (SGW) or small networks, existing management 3620 protocols such as DHCP [DHCP], RADIUS [RADIUS], SNMP or LDAP [LDAP] 3621 should be preferred for enterprise management as well as subsequent 3622 information exchanges. 3624 The Configuration Payload is defined as follows: 3626 1 2 3 3627 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 3628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3629 ! Next Payload !C! RESERVED ! Payload Length ! 3630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3631 ! CFG Type ! RESERVED ! 3632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3633 ! ! 3634 ~ Configuration Attributes ~ 3635 ! ! 3636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3638 Figure 22: Configuration Payload Format 3640 The payload type for the Configuration Payload is forty seven (47). 3642 o CFG Type (1 octet) - The type of exchange represented by the 3643 Configuration Attributes. 3645 CFG Type Value 3646 =========== ===== 3647 RESERVED 0 3648 CFG_REQUEST 1 3649 CFG_REPLY 2 3650 CFG_SET 3 3651 CFG_ACK 4 3653 values 5-127 are reserved to IANA. Values 128-255 are for private 3654 use among mutually consenting parties. 3656 o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on 3657 receipt. 3659 o Configuration Attributes (variable length) - These are type 3660 length values specific to the Configuration Payload and are 3661 defined below. There may be zero or more Configuration 3662 Attributes in this payload. 3664 3.15.1 Configuration Attributes 3666 1 2 3 3667 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 3668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3669 !R| Attribute Type ! Length | 3670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3671 | | 3672 ~ Value ~ 3673 | | 3674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3676 Figure 23: Configuration Attribute Format 3678 o Reserved (1 bit) - This bit MUST be set to zero and MUST be 3679 ignored on receipt. 3681 o Attribute Type (7 bits) - A unique identifier for each of the 3682 Configuration Attribute Types. 3684 o Length (2 octets) - Length in octets of Value. 3686 o Value (0 or more octets) - The variable length value of this 3687 Configuration Attribute. 3689 The following attribute types have been defined: 3691 Multi- 3692 Attribute Type Value Valued Length 3693 ======================= ===== ====== ================== 3694 RESERVED 0 3695 INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets 3696 INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets 3697 INTERNAL_IP4_DNS 3 YES 0 or 4 octets 3698 INTERNAL_IP4_NBNS 4 YES 0 or 4 octets 3699 INTERNAL_ADDRESS_EXPIRY 5 NO 0 or 4 octets 3700 INTERNAL_IP4_DHCP 6 YES 0 or 4 octets 3701 APPLICATION_VERSION 7 NO 0 or more 3702 INTERNAL_IP6_ADDRESS 8 YES* 0 or 16 octets 3703 INTERNAL_IP6_NETMASK 9 NO 0 or 16 octets 3704 INTERNAL_IP6_DNS 10 YES 0 or 16 octets 3705 INTERNAL_IP6_NBNS 11 YES 0 or 16 octets 3706 INTERNAL_IP6_DHCP 12 YES 0 or 16 octets 3707 INTERNAL_IP4_SUBNET 13 NO 0 or 8 octets 3708 SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 3709 INTERNAL_IP6_SUBNET 15 NO 17 octets 3711 * These attributes may be multi-valued on return only if 3712 multiple values were requested. 3714 Types 16-16383 are reserved to IANA. Values 16384-32767 are for 3715 private use among mutually consenting parties. 3717 o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the 3718 internal network, sometimes called a red node address or 3719 private address and MAY be a private address on the Internet. 3720 Multiple internal addresses MAY be requested by requesting 3721 multiple internal address attributes. The responder MAY only 3722 send up to the number of addresses requested. 3724 The requested address is valid until the expiry time defined 3725 with the INTERNAL_ADDRESS EXPIRY attribute or there are no 3726 IKE_SAs between the peers. 3728 o INTERNAL_IP4_NETMASK, INTERNAL_IP6_NETMASK - The internal 3729 network's netmask. Only one netmask is allowed in the request 3730 and reply messages (e.g., 255.255.255.0) and it MUST be used 3731 only with an INTERNAL_ADDRESS attribute. 3733 o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a 3734 DNS server within the network. Multiple DNS servers MAY be 3735 requested. The responder MAY respond with zero or more DNS 3736 server attributes. 3738 o INTERNAL_IP4_NBNS, INTERNAL_IP6_NBNS - Specifies an address of 3739 a NetBios Name Server (WINS) within the network. Multiple NBNS 3740 servers MAY be requested. The responder MAY respond with zero 3741 or more NBNS server attributes. 3743 o INTERNAL_ADDRESS_EXPIRY - Specifies the number of seconds that 3744 the host can use the internal IP address. The host MUST renew 3745 the IP address before this expiry time. Only one of these 3746 attributes MAY be present in the reply. 3748 o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to 3749 send any internal DHCP requests to the address contained within 3750 the attribute. Multiple DHCP servers MAY be requested. The 3751 responder MAY respond with zero or more DHCP server attributes. 3753 o APPLICATION_VERSION - The version or application information of 3754 the IPsec host. This is a string of printable ASCII characters 3755 that is NOT null terminated. 3757 o INTERNAL_IP4_SUBNET - The protected sub-networks that this 3758 edge-device protects. This attribute is made up of two fields; 3759 the first being an IP address and the second being a netmask. 3760 Multiple sub-networks MAY be requested. The responder MAY 3761 respond with zero or more sub-network attributes. 3763 o SUPPORTED_ATTRIBUTES - When used within a Request, this 3764 attribute MUST be zero length and specifies a query to the 3765 responder to reply back with all of the attributes that it 3766 supports. The response contains an attribute that contains a 3767 set of attribute identifiers each in 2 octets. The length 3768 divided by 2 (octets) would state the number of supported 3769 attributes contained in the response. 3771 o INTERNAL_IP6_SUBNET - The protected sub-networks that this 3772 edge-device protects. This attribute is made up of two fields; 3773 the first being a 16 octet IPv6 address the second being a one 3774 octet prefix-length as defined in [ADDRIPV6]. Multiple 3775 sub-networks MAY be requested. The responder MAY respond with 3776 zero or more sub-network attributes. 3778 Note that no recommendations are made in this document how an 3779 implementation actually figures out what information to send in a 3780 reply. i.e., we do not recommend any specific method of an IRAS 3781 determining which DNS server should be returned to a requesting 3782 IRAC. 3784 3.16 Extended Authentication Protocol (EAP) Payload 3786 The Extended Authentication Protocol Payload, denoted EAP in this 3787 memo, allows IKE_SAs to be authenticated using the protocol defined 3788 in RFC 2284 [EAP] and subsequent extensions to that protocol. The 3789 full set of acceptable values for the payload are defined elsewhere, 3790 but a short summary of RFC 2284 is included here to make this 3791 document stand alone in the common cases. 3793 1 2 3 3794 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 3795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3796 ! Next Payload !C! RESERVED ! Payload Length ! 3797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3798 ! ! 3799 ~ EAP Message ~ 3800 ! ! 3801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3803 Figure 24: EAP Payload Format 3805 The payload type for an EAP Payload is forty eight (48). 3807 1 2 3 3808 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 3809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3810 ! Code ! Identifier ! Length ! 3811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3812 ! Type ! Type_Data... 3813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 3815 Figure 25: EAP Message Format 3817 o Code (one octet) indicates whether this message is a 3818 Request (1), Response (2), Success (3), or Failure (4). 3820 o Identifier (one octet) is used in PPP to distinguish replayed 3821 messages from repeated ones. Since in IKE, EAP runs over a 3822 reliable protocol, it serves no function here. In a response 3823 message this octet MUST be set to match the identifier in the 3824 corresponding request. In other messages, this field MAY 3825 be set to any value. 3827 o Length (two octets) is the length of the EAP message and MUST 3828 be four less than the Payload Length of the encapsulating 3829 payload. 3831 o Type (one octet) is present only if the Code field is Request 3832 (1) or Response (2). For other codes, the EAP message length 3833 MUST be four octets and the Type and Type_Data fields MUST NOT 3834 be present. In a Request (1) message, Type indicates the 3835 data being requested. In a Response (2) message, Type MUST 3836 either be NAC or match the type of the data requested. The 3837 following types are defined in RFC 2284: 3839 1 Identity 3840 2 Notification 3841 3 NAK (Response Only) 3842 4 MD5-Challenge 3843 5 One-Time Password (OTP) 3844 6 Generic Token Card 3846 o Type_Data (Variable Length) contains data depending on the Code 3847 and Type. In Requests other than MD5-Challenge, this field 3848 contains a prompt to be displayed to a human user. For NAK, it 3849 contains one octet suggesting the type of authentication the 3850 Initiator would prefer to use. For most other responses, it 3851 contains the authentication code typed by the human user. 3853 Note that since IKE passes an indication of initiator identity in 3854 message 3 of the protocol, EAP based prompts for Identity SHOULD NOT 3855 be used. 3857 4 Conformance Requirements 3859 In order to assure that all implementations of IKEv2 can 3860 interoperate, there are MUST support requirements in addition to 3861 those listed elsewhere. Of course, IKEv2 is a security protocol, and 3862 one of its major functions is to only allow authorized parties to 3863 successfully complete establishment of SAs. So a particular 3864 implementation may be configured with any of a number of restrictions 3865 concerning algorithms and trusted authorities that will prevent 3866 universal interoperability. 3868 IKEv2 is designed to permit minimal implementations that can 3869 interoperate with all compliant implementations. There are a series 3870 of optional features that can easily be ignored by a particular 3871 implementation if it does not support that feature. Those features 3872 include: 3874 Ability to negotiate SAs through a NAT and tunnel the resulting 3875 ESP SA over UDP. 3877 Ability to request (and respond to a request for) a temporary IP 3878 address on the remote end of a tunnel. 3880 Ability to support various types of legacy authentication. 3882 Ability to support window sizes greater than one. 3884 Ability to establish multiple ESP and/or AH SAs within a single 3885 IKE_SA. 3887 Ability to rekey SAs. 3889 To assure interoperability, all implementations MUST be capable of 3890 parsing all payload types (if only to skip over them) and to ignore 3891 payload types that it does not support unless the critical bit is set 3892 in the payload header. If the critical bit is set in an unsupported 3893 payload header, all implementations MUST reject the messages 3894 containing those payloads. 3896 Every implementation MUST be capable of doing four message 3897 IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, 3898 one for ESP and/or AH). Implementations MAY be initiate-only or 3899 respond-only if appropriate for their platform. Every implementation 3900 MUST be capable of responding to an INFORMATIONAL exchange, but a 3901 minimal implementation MAY respond to any INFORMATIONAL message with 3902 an empty INFORMATIONAL reply. A minimal implementation MAY support 3903 the CREATE_CHILD_SA exchange only in so far as to recognize requests 3904 and reject them with a Notify payload of type NO_ADDITIONAL_SAS. A 3905 minimal implementation need not be able to initiate CREATE_CHILD_SA 3906 or INFORMATIONAL exchanges. When an SA expires (based on locally 3907 configured values of either lifetime or octets passed), and 3908 implementation MAY either try to renew it with a CREATE_CHILD_SA 3909 exchange or it MAY delete (close) the old SA and create a new one. If 3910 the responder rejects the CREATE_CHILD_SA request with a 3911 NO_ADDITIONAL_SAS notification, the implementation MUST be capable of 3912 instead closing the old SA and creating a new one. 3914 Implementations are not required to support requesting temporary IP 3915 addresses or responding to such requests. If an implementation does 3916 support issuing such requests, it MUST include a CP payload in 3917 message 3 containing at least a field of type INTERNAL_IP4_ADDRESS or 3918 INTERNAL_IP6_ADDRESS. All other fields are optional. If an 3919 implementation supports responding to such requests, it MUST parse 3920 the CP payload of type CFG_REQUEST in message 3 and recognize a field 3921 of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports 3922 leasing an address of the appropriate type, it MUST return a CP 3923 payload of type CFG_REPLY containing an address of the requested 3924 type. The responder SHOULD include all of the other related 3925 attributes if it has them. 3927 A minimal IPv4 responder implementation will ignore the contents of 3928 the CP payload except to determine that it includes an 3929 INTERNAL_IP4_ADDRESS attribute and will respond with the address and 3930 other related attributes regardless of whether the initiator 3931 requested them. 3933 A minimal IPv4 initiator will generate a CP payload containing only 3934 an INTERNAL_IP4_ADDRESS attribute and will parse the response 3935 ignoring attributes it does not know how to use. The only attribute 3936 it MUST be able to process is INTERNAL_ADDRESS_EXPIRY, which it must 3937 use to bound the lifetime of the SA unless it successfully renews the 3938 lease before it expires. Minimal initiators need not be able to 3939 request lease renewals and minimal responders need not respond to 3940 them. 3942 For an implementation to be called conforming to this specification, 3943 it MUST be possible to configure it to accept the following: 3945 PKIX Certificates containing and signed by RSA keys of size 1024 or 3946 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, 3947 ID_RFC822_ADDR, or ID_DER_ASN1_DN. 3949 Shared key authentication where the ID passes is any of ID_KEY_ID, 3950 ID_FQDN, or ID_RFC822_ADDR. 3952 Authentication where the responder is authenticated using PKIX 3953 Certificates and the initiator is authenticated using shared key 3954 authentication. 3956 5 Security Considerations 3958 Repeated rekeying using CREATE_CHILD_SA without PFS leaves all SAs 3959 vulnerable to cryptanalysis of a single key or overrun of either 3960 endpoint. Implementers should take note of this fact and set a limit 3961 on CREATE_CHILD_SA exchanges between exponentiations. This memo does 3962 not prescribe such a limit. 3964 The strength of a key derived from a Diffie-Hellman exchange using 3965 any of the groups defined here depends on the inherent strength of 3966 the group, the size of the exponent used, and the entropy provided by 3967 the random number generator used. Due to these inputs it is difficult 3968 to determine the strength of a key for any of the defined groups. 3969 Diffie-Hellman group number two, when used with a strong random 3970 number generator and an exponent no less than 200 bits, is sufficient 3971 for use with 3DES. Groups three through five provide greater 3972 security. Group one is for historic purposes only and does not 3973 provide sufficient strength except for use with DES, which is also 3974 for historic use only. Implementations should make note of these 3975 conservative estimates when establishing policy and negotiating 3976 security parameters. 3978 Note that these limitations are on the Diffie-Hellman groups 3979 themselves. There is nothing in IKE which prohibits using stronger 3980 groups nor is there anything which will dilute the strength obtained 3981 from stronger groups (limited by the strength of the other algorithms 3982 negotiated including the prf function). In fact, the extensible 3983 framework of IKE encourages the definition of more groups; use of 3984 elliptical curve groups may greatly increase strength using much 3985 smaller numbers. 3987 It is assumed that all Diffie-Hellman exponents are erased from 3988 memory after use. In particular, these exponents MUST NOT be derived 3989 from long-lived secrets like the seed to a pseudo-random generator 3990 that is not erased after use. 3992 The strength of all keys are limited by the size of the output of the 3993 negotiated prf function. For this reason, a prf function whose output 3994 is less than 128 bits (e.g., 3DES-CBC) MUST NOT be used with this 3995 protocol. 3997 The security of this protocol is critically dependent on the 3998 randomness of the randomly chosen parameters. These should be 3999 generated by a strong random or properly seeded pseudo-random source 4000 (see [RFC1750]). Implementers should take care to ensure that use of 4001 random numbers for both keys and nonces is engineered in a fashion 4002 that does not undermine the security of the keys. 4004 For information on the rationale of many of the cryptographic design 4005 choices in this protocol, see [SIGMA]. 4007 When using pre-shared keys, a critical consideration is how to assure 4008 the randomness of these secrets. The strongest practice is to ensure 4009 that any pre-shared key contain as much randomness as the strongest 4010 key being negotiated. Deriving a shared secret from a password, name, 4011 or other low entropy source is not secure. These sources are subject 4012 to dictionary and social engineering attacks, among others. 4014 The NAT_DETECTION_*_IP notifications contain a hash of the addresses 4015 and ports in an attempt to hide internal IP addresses behind a NAT. 4016 Since the IPv4 address space is only 32 bits, and it is usually very 4017 sparse, it would be possible for an attacker to find out the internal 4018 address used behind the NAT box by trying all possible IP-addresses 4019 and trying to find the matching hash. The port numbers are normally 4020 fixed to 500, and the SPIs can be extracted from the packet. This 4021 reduces the number of hash calculations to 2^32. With an educated 4022 guess of the use of private address space, the number of hash 4023 calculations is much smaller. Designers should therefore not assume 4024 that use of IKE will not leak internal address information. 4026 When using an EAP authentication method that does not generate a 4027 shared key for protecting a subsequent AUTH payload, certain man-in- 4028 the-middle and server impersonation attacks are possible [EAPMITM]. 4029 These vulnerabilities occur when EAP is also used in protocols which 4030 are not protected with a secure tunnel. Since EAP is a general- 4031 purpose authentication protocol, which is often used to provide 4032 single-signon facilities, a deployed IPsec solution which relies on 4033 an EAP authentication method that does not generate a shared key 4034 (also known as a non-key-generating EAP method) can become 4035 compromised due to the deployment of an entirely unrelated 4036 application that also happens to use the same non-key-generating EAP 4037 method, but in an unprotected fashion. Note that this vulnerability 4038 is not limited to just EAP, but can occur in other scenarios where an 4039 authentication infrastructure is reused. For example, if the EAP 4040 mechanism used by IKEv2 utilizes a token authenticator, a man-in-the- 4041 middle attacker could impersonate the web server, intercept the token 4042 authentication exchange, and use it to initiate an IKEv2 connection. 4043 For this reason, use of non-key-generating EAP methods SHOULD be 4044 avoided where possible. Where they are used, it is extremely 4045 important that all usages of these EAP methods SHOULD utilize a 4046 protected tunnel, where the initiator validates the responder's 4047 certificate before initiating the EAP exchange. Implementors SHOULD 4048 describe the vulnerabilities of using non-key-generating EAP methods 4049 in the documentation of their implementations so that the 4050 administrators deploying IPsec solutions are aware of these dangers. 4052 An implementation using EAP MUST also use a public key based 4053 authentication of the server to the client before the EAP exchange 4054 begins, even if the EAP method offers mutual authentication. This 4055 avoids having additional IKEv2 protocol variations and protects the 4056 EAP data from active attackers. 4058 6 IANA Considerations 4060 This document defines a number of new field types and values where 4061 future assignments will be managed by the IANA. 4063 The following registries should be created: 4065 IKEv2 Exchange Types 4066 IKEv2 Payload Types 4067 IKEv2 Transform Types 4068 IKEv2 Transform Attribute Types 4069 IKEv2 Encryption Transform IDs 4070 IKEv2 Pseudo-ramdom Function Transform IDs 4071 IKEv2 Integrity Algorithm Transform IDs 4072 IKEv2 Diffie-Hellman, ECP and EC2N Transform IDs 4073 IKEv2 Identification Payload ID Types 4074 IKEv2 Certification Encodings 4075 IKEv2 Authentication Method 4076 IKEv2 Notification Payload Types 4077 IKEv2 Notification IPCOMP Transform IDs 4078 IKEv2 Security Protocol Identfiers 4079 IKEv2 Traffic Selector Types 4080 IKEv2 Configuration Payload CFG Types 4081 IKEv2 Configuration Payload Attribute Types 4083 Note: when creating a new Transform Type, a new registry for it must 4084 be created. 4086 New allocations to any of those registries may be allocated by expert 4087 review. 4089 7 Acknowledgements 4091 This document is a collaborative effort of the entire IPsec WG. If 4092 there were no limit to the number of authors that could appear on an 4093 RFC, the following, in alphabetical order, would have been listed: 4094 Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt 4095 Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, J. 4096 Ioannidis, Steve Kent, Angelos Keromytis, Tero Kivinen, Hugo 4097 Krawczyk, Andrew Krywaniuk, Radia Perlman, O. Reingold, Michael 4098 Richardson. Many other people contributed to the design. It is an 4099 evolution of IKEv1, ISAKMP, and the IPsec DOI, each of which has its 4100 own list of authors. Hugh Daniel suggested the feature of having the 4101 initiator, in message 3, specify a name for the responder, and gave 4102 the feature the cute name "You Tarzan, Me Jane". David Faucher and 4103 Valery Smyzlov helped refine the design of the traffic selector 4104 negotiation. 4106 8 References 4108 8.1 Normative References 4110 [ADDGROUP] Kivinen, T., and Kojo, M., "More Modular Exponential 4111 (MODP) Diffie-Hellman groups for Internet Key 4112 Exchange (IKE)", RFC 3526, May 2003. 4114 [ADDRIPV6] Hinden, R., and Deering, S., 4115 "Internet Protocol Version 6 (IPv6) Addressing 4116 Architecture", RFC 3513, April 2003. 4118 [Bra97] Bradner, S., "Key Words for use in RFCs to indicate 4119 Requirement Levels", BCP 14, RFC 2119, March 1997. 4121 [EAP] Blunk, L. and Vollbrecht, J., "PPP Extensible 4122 Authentication Protocol (EAP), RFC 2284, March 1998. 4124 [ESPCBC] Pereira, R., Adams, R., "The ESP CBC-Mode Cipher 4125 Algorithms", RFC 2451, November 1998. 4127 [Hutt04] Huttunen, A. et. al., "UDP Encapsulation of IPsec 4128 Packets", draft-ietf-ipsec-udp-encaps-08.txt, February 4129 2004, work in progress. 4131 [RFC2401bis] Kent, S. and Atkinson, R., "Security Architecture 4132 for the Internet Protocol", un-issued Internet 4133 Draft, work in progress. 4135 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing 4136 an IANA Considerations Section in RFCs", BCP 26, RFC 2434, 4137 October 1998. 4139 [RFC3168] Ramakrishnan, K., Floyd, S., and Black, D., 4140 "The Addition of Explicit Congestion Notification (ECN) 4141 to IP", RFC 3168, September 2001. 4143 [RFC3280] Housley, R., Polk, W., Ford, W., Solo, D., "Internet 4144 X.509 Public Key Infrastructure Certificate and 4145 Certificate Revocation List (CRL) Profile", RFC 3280, 4146 April 2002. 4148 [RFC3667] Bradner, S., "IETF Rights in Submissions", BCP 78, 4149 RFC 3667, February 2004. 4151 [RFC3668] Bradner, S., "Intellectual Property Rights in IETF 4152 Technology", BCP 79, RFC 3668, February 2004. 4154 8.2 Informative References 4156 [DES] ANSI X3.106, "American National Standard for Information 4157 Systems-Data Link Encryption", American National Standards 4158 Institute, 1983. 4160 [DH] Diffie, W., and Hellman M., "New Directions in 4161 Cryptography", IEEE Transactions on Information Theory, V. 4162 IT-22, n. 6, June 1977. 4164 [DHCP] R. Droms, "Dynamic Host Configuration Protocol", 4165 RFC2131 4167 [DSS] NIST, "Digital Signature Standard", FIPS 186, National 4168 Institute of Standards and Technology, U.S. Department of 4169 Commerce, May, 1994. 4171 [EAPMITM] Asokan, N., Nierni, V., and Nyberg, K., "Man-in-the-Middle 4172 in Tunneled Authentication Protocols", 4173 http://eprint.iacr.org/2002/163, November 2002. 4175 [HC98] Harkins, D., Carrel, D., "The Internet Key Exchange 4176 (IKE)", RFC 2409, November 1998. 4178 [IDEA] Lai, X., "On the Design and Security of Block Ciphers," 4179 ETH Series in Information Processing, v. 1, Konstanz: 4180 Hartung-Gorre Verlag, 1992 4182 [IKEv2IANA]Richardson, M., "Initial IANA registry contents", 4183 draft-ietf-ipsec-ikev2-iana-00.txt, work in progress. 4185 [IPCOMP] Shacham, A., Monsour, R., Pereira, R., and Thomas, M., "IP 4186 Payload Compression Protocol (IPComp)", RFC 3173, 4187 September 2001. 4189 [KPS03] Kaufman, C., Perlman, R., and Sommerfeld, B., "DoS 4190 protection for UDP-based protocols", ACM Conference on 4191 Computer and Communications Security, October 2003. 4193 [Ker01] Keromytis, A., Sommerfeld, B., "The 'Suggested ID' 4194 Extension for IKE", draft-keromytis-ike-id-00.txt, 2001 4196 [KBC96] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 4197 Hashing for Message Authentication", RFC 2104, February 4198 1997. 4200 [LDAP] M. Wahl, T. Howes, S. Kille., "Lightweight Directory 4201 Access Protocol (v3)", RFC2251 4203 [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, 4204 April 1992. 4206 [MSST98] Maughhan, D., Schertler, M., Schneider, M., and Turner, J. 4207 "Internet Security Association and Key Management Protocol 4208 (ISAKMP)", RFC 2408, November 1998. 4210 [Orm96] Orman, H., "The Oakley Key Determination Protocol", RFC 4211 2412, November 1998. 4213 [PFKEY] McDonald, D., Metz, C., and Phan, B., "PFKEY Key 4214 Management API, Version 2", RFC2367, July 1998. 4216 [PKCS1] Kaliski, B., and J. Staddon, "PKCS #1: RSA Cryptography 4217 Specifications Version 2", September 1998. 4219 [PK01] Perlman, R., and Kaufman, C., "Analysis of the IPsec key 4220 exchange Standard", WET-ICE Security Conference, MIT,2001, 4221 http://sec.femto.org/wetice-2001/papers/radia-paper.pdf. 4223 [Pip98] Piper, D., "The Internet IP Security Domain Of 4224 Interpretation for ISAKMP", RFC 2407, November 1998. 4226 [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote 4227 Authentication Dial In User Service (RADIUS)", RFC2138 4229 [RFC1750] Eastlake, D., Crocker, S., and Schiller, J., "Randomness 4230 Recommendations for Security", RFC 1750, December 1994. 4232 [RFC2401] Kent, S., and Atkinson, R., "Security Architecture for 4233 the Internet Protocol", RFC 2401, November 1998. 4235 [RFC2474] Nichols, K., Blake, S., Baker, F. and Black, D., 4236 "Definition of the Differentiated Services Field (DS 4237 Field) in the IPv4 and IPv6 Headers", RFC 2474, 4238 December 1998. 4240 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. 4241 and Weiss, W., "An Architecture for Differentiated 4242 Services", RFC 2475, December 1998. 4244 [RFC2522] Karn, P., and Simpson, W., "Photuris: Session-Key 4245 Management Protocol", RFC 2522, March 1999. 4247 [RFC2983] Black, D., "Differentiated Services and Tunnels", 4248 RFC 2983, October 2000. 4250 [RFC3715] Aboba, B and Dixon, W., "IPsec-Network Address 4251 Translation (NAT) Compatibility Requirements", 4252 RFC 3715, March 2004. 4254 [RSA] Rivest, R., Shamir, A., and Adleman, L., "A Method for 4255 Obtaining Digital Signatures and Public-Key 4256 Cryptosystems", Communications of the ACM, v. 21, n. 2, 4257 February 1978. 4259 [SHA] NIST, "Secure Hash Standard", FIPS 180-1, National 4260 Institute of Standards and Technology, U.S. Department 4261 of Commerce, May 1994. 4263 [SIGMA] Krawczyk, H., "SIGMA: the `SIGn-and-MAc' Approach to 4264 Authenticated Diffie-Hellman and its Use in the IKE 4265 Protocols", in Advances in Cryptography - CRYPTO 2003 4266 Proceedings, LNCS 2729, Springer, 2003. Available at: 4267 http://www.ee.technion.ac.il/~hugo/sigma.html 4269 [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange 4270 Mechanism for Internet", from IEEE Proceedings of the 4271 1996 Symposium on Network and Distributed Systems 4272 Security. 4274 [X.501] ITU-T Recommendation X.501: Information Technology - 4275 Open Systems Interconnection - The Directory: Models, 4276 1993. 4278 [X.509] ITU-T Recommendation X.509 (1997 E): Information 4279 Technology - Open Systems Interconnection - The 4280 Directory: Authentication Framework, June 1997. 4282 Appendix A: Summary of changes from IKEv1 4284 The goals of this revision to IKE are: 4286 1) To define the entire IKE protocol in a single document, replacing 4287 RFCs 2407, 2408, and 2409 and incorporating subsequent changes to 4288 support NAT Traversal, Extended Authentication, and Remote Address 4289 acquisition. 4291 2) To simplify IKE by replacing the eight different initial exchanges 4292 with a single four message exchange (with changes in authentication 4293 mechanisms affecting only a single AUTH payload rather than 4294 restructuring the entire exchange); 4296 3) To remove the Domain of Interpretation (DOI), Situation (SIT), and 4297 Labeled Domain Identifier fields, and the Commit and Authentication 4298 only bits; 4300 4) To decrease IKE's latency in the common case by making the initial 4301 exchange be 2 round trips (4 messages), and allowing the ability to 4302 piggyback setup of a CHILD_SA on that exchange; 4304 5) To replace the cryptographic syntax for protecting the IKE 4305 messages themselves with one based closely on ESP to simplify 4306 implementation and security analysis; 4308 6) To reduce the number of possible error states by making the 4309 protocol reliable (all messages are acknowledged) and sequenced. This 4310 allows shortening CREATE_CHILD_SA exchanges from 3 messages to 2; 4312 7) To increase robustness by allowing the responder to not do 4313 significant processing until it receives a message proving that the 4314 initiator can receive messages at its claimed IP address, and not 4315 commit any state to an exchange until the initiator can be 4316 cryptographically authenticated; 4318 8) To fix bugs such as the hash problem documented in [draft-ietf- 4319 ipsec-ike-hash-revised-02.txt]; 4321 9) To specify Traffic Selectors in their own payloads type rather 4322 than overloading ID payloads, and making more flexible the Traffic 4323 Selectors that may be specified; 4325 10) To specify required behavior under certain error conditions or 4326 when data that is not understood is received in order to make it 4327 easier to make future revisions in a way that does not break 4328 backwards compatibility; 4329 11) To incorporate ideas from draft-ietf-ipsec-nat-reqts-04.txt to 4330 allow IKE to negotiate through NAT gateways; 4332 12) To simplify and clarify how shared state is maintained in the 4333 presence of network failures and Denial of Service attacks; and 4335 13) To maintain existing syntax and magic numbers to the extent 4336 possible to make it likely that implementations of IKEv1 can be 4337 enhanced to support IKEv2 with minimum effort. 4339 Appendix B: Diffie-Hellman Groups 4341 There are 5 different Diffie-Hellman groups defined for use in IKE. 4342 These groups were generated by Richard Schroeppel at the University 4343 of Arizona. Properties of these primes are described in [Orm96]. 4345 The strength supplied by group one may not be sufficient for the 4346 mandatory-to-implement encryption algorithm and is here for historic 4347 reasons. 4349 Additional Diffie-Hellman groups have been defined in [ADDGROUP]. 4351 B.1 Group 1 - 768 Bit MODP 4353 This group is assigned id 1 (one). 4355 The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } 4356 Its hexadecimal value is: 4358 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 4359 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 4360 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 4361 A63A3620 FFFFFFFF FFFFFFFF 4363 The generator is 2. 4365 B.2 Group 2 - 1024 Bit MODP 4367 This group is assigned id 2 (two). 4369 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. 4370 Its hexadecimal value is: 4372 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 4373 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 4374 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 4375 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 4376 49286651 ECE65381 FFFFFFFF FFFFFFFF 4378 The generator is 2. 4380 B.3 Group 3 - 155 Bit EC2N 4382 This group is assigned id 3 (three). The curve is based on the Galois 4383 Field GF[2^155]. The field size is 155. The irreducible polynomial 4384 for the field is: 4385 u^155 + u^62 + 1. 4386 The equation for the elliptic curve is: 4388 y^2 + xy = x^3 + ax^2 + b. 4390 Field Size: 155 4391 Group Prime/Irreducible Polynomial: 4392 0x0800000000000000000000004000000000000001 4393 Group Generator One: 0x7b 4394 Group Curve A: 0x0 4395 Group Curve B: 0x07338f 4396 Group Order: 0x0800000000000000000057db5698537193aef944 4398 The data in the KE payload when using this group is the value x from 4399 the solution (x,y), the point on the curve chosen by taking the 4400 randomly chosen secret Ka and computing Ka*P, where * is the 4401 repetition of the group addition and double operations, P is the 4402 curve point with x coordinate equal to generator 1 and the y 4403 coordinate determined from the defining equation. The equation of 4404 curve is implicitly known by the Group Type and the A and B 4405 coefficients. There are two possible values for the y coordinate; 4406 either one can be used successfully (the two parties need not agree 4407 on the selection). 4409 B.4 Group 4 - 185 Bit EC2N 4411 This group is assigned id 4 (four). The curve is based on the Galois 4412 Field GF[2^185]. The field size is 185. The irreducible polynomial 4413 for the field is: 4414 u^185 + u^69 + 1. 4416 The equation for the elliptic curve is: 4417 y^2 + xy = x^3 + ax^2 + b. 4419 Field Size: 185 4420 Group Prime/Irreducible Polynomial: 4421 0x020000000000000000000000000000200000000000000001 4422 Group Generator One: 0x18 4423 Group Curve A: 0x0 4424 Group Curve B: 0x1ee9 4425 Group Order: 0x01ffffffffffffffffffffffdbf2f889b73e484175f94ebc 4427 The data in the KE payload when using this group will be identical to 4428 that as when using Oakley Group 3 (three). 4430 Change History (To be removed from RFC) 4432 H.1 Changes from IKEv2-00 to IKEv2-01 February 2002 4434 1) Changed Appendix B to specify the encryption and authentication 4435 processing for IKE rather than referencing ESP. Simplified the format 4436 by removing idiosyncrasies not needed for IKE. 4438 2) Added option for authentication via a shared secret key. 4440 3) Specified different keys in the two directions of IKE messages. 4441 Removed requirement of different cookies in the two directions since 4442 now no longer required. 4444 4) Change the quantities signed by the two ends in AUTH fields to 4445 assure the two parties sign different quantities. 4447 5) Changed reference to AES to AES_128. 4449 6) Removed requirement that Diffie-Hellman be repeated when rekeying 4450 IKE_SA. 4452 7) Fixed typos. 4454 8) Clarified requirements around use of port 500 at the remote end in 4455 support of NAT. 4457 9) Clarified required ordering for payloads. 4459 10) Suggested mechanisms for avoiding DoS attacks. 4461 11) Removed claims in some places that the first phase 2 piggybacked 4462 on phase 1 was optional. 4464 H.2 Changes from IKEv2-01 to IKEv2-02 April 2002 4466 1) Moved the Initiator CERTREQ payload from message 1 to message 3. 4468 2) Added a second optional ID payload in message 3 for the Initiator 4469 to name a desired Responder to support the case where multiple named 4470 identities are served by a single IP address. 4472 3) Deleted the optimization whereby the Diffie-Hellman group did not 4473 need to be specified in phase 2 if it was the same as in phase 1 (it 4474 complicated the design with no meaningful benefit). 4476 4) Added a section on the implications of reusing Diffie-Hellman 4477 expontentials 4478 5) Changed the specification of sequence numbers to being at 0 in 4479 both directions. 4481 6) Many editorial changes and corrections, the most significant being 4482 a global replace of "byte" with "octet". 4484 H.3 Changes from IKEv2-02 to IKEv2-03 October 2002 4486 1) Reorganized the document moving introductory material to the 4487 front. 4489 2) Simplified the specification of Traffic Selectors to allow only 4490 IPv4 and IPv6 address ranges, as was done in the JFK spec. 4492 3) Fixed the problem brought up by David Faucher with the fix 4493 suggested by Valery Smyslov. If Bob needs to narrow the selector 4494 range, but has more than one matching narrower range, then if Alice's 4495 first selector is a single address pair, Bob chooses the range that 4496 encompasses that. 4498 4) To harmonize with the JFK spec, changed the exchange so that the 4499 initial exchange can be completed in four messages even if the 4500 responder must invoke an anti-clogging defense and the initiator 4501 incorrectly anticipates the responder's choice of Diffie-Hellman 4502 group. 4504 5) Replaced the hierarchical SA payload with a simplified version 4505 that only negotiates suites of cryptographic algorithms. 4507 H.4 Changes from IKEv2-03 to IKEv2-04 January 2003 4509 1) Integrated NAT traversal changes (including Appendix A). 4511 2) Moved the anti-clogging token (cookie) from the SPI to a NOTIFY 4512 payload; changed negotiation back to 6 messages when a cookie is 4513 needed. 4515 3) Made capitalization of IKE_SA and CHILD_SA consistent. 4517 4) Changed how IPComp was negotiated. 4519 5) Added usage scenarios. 4521 6) Added configuration payload for acquiring internal addresses on 4522 remote networks. 4524 7) Added negotiation of tunnel vs transport mode. 4526 H.5 Changes from IKEv2-04 to IKEv2-05 February 2003 4528 1) Shortened Abstract 4530 2) Moved NAT Traversal from Appendix to section 2. Moved changes from 4531 IKEv2 to Appendix A. Renumbered sections. 4533 3) Made language more consistent. Removed most references to Phase 1 4534 and Phase 2. 4536 4) Made explicit the requirements for support of NAT Traversal. 4538 5) Added support for Extended Authentication Protocol methods. 4540 6) Added Response bit to message header. 4542 7) Made more explicit the encoding of Diffie-Hellman numbers in key 4543 expansion algorithms. 4545 8) Added ID payloads to AUTH payload computation. 4547 9) Expanded set of defined cryptographic suites. 4549 10) Added text for MUST/SHOULD support for ID payloads. 4551 11) Added new certificate formats and added MUST/SHOULD text. 4553 12) Clarified use of CERTREQ. 4555 13) Deleted "MUST SUPPORT" column in CP payload specification (it was 4556 inconsistent with surrounding text). 4558 14) Extended and clarified Conformance Requirements section, 4559 including specification of a minimal implementation. 4561 15) Added text to specify ECN handling. 4563 H.6 Changes from IKEv2-05 to IKEv2-06 March 2003 4565 1) Changed the suite based crypto negotiation back to ala carte. 4567 2) Eliminated some awkward page breaks, typographical errors, and 4568 other formatting issues. 4570 3) Tightened language describing cryptographic strength. 4572 4) Added references. 4574 5) Added more specific error codes. 4576 6) Added rationale for unintuitive key generation hash with shared 4577 secret based authentication. 4579 7) Changed the computation of the authenticating AUTH payload as 4580 proposed by Hugo Krawczyk. 4582 8) Changed the dashes (-) to underscores (_) in the names of fields 4583 and constants. 4585 H.7 Changes from IKEv2-06 to IKEv2-07 April 2003 4587 1) Added a list of payload types to section 3.2. 4589 2) Clarified use of SET_WINDOW_SIZE Notify payload. 4591 3) Removed references to COOKIE_REQUIRED Notify payload. 4593 4) Specified how to use a prf with a fixed key size. 4595 5) Removed g^ir from data processed by prf+. 4597 6) Strengthened cautions against using passwords as shared keys. 4599 7) Renamed Protocol_id field SECURITY_PROTOCOL_ID when it is not the 4600 Protocol ID from IP, and changed its values for consistency with 4601 IKEv1. 4603 8) Clarified use of ID payload in access control decisions. 4605 9) Gave IDr and TSr their own payload type numbers. 4607 10) Added Intellectual Property rights section. 4609 11) Clarified some issues in NAT Traversal. 4611 H.8 Changes from IKEv2-07 to IKEv2-08 May 2003 4613 1) Numerous editorial corrections and clarifications. 4615 2) Renamed Gateway to Security Gateway. 4617 3) Made explicit that the ability to rekey SAs without restarting IKE 4618 was optional. 4620 4) Removed last references to MUST and SHOULD ciphersuites. 4622 5) Changed examples to "example.com". 4624 6) Changed references to status codes to status types. 4626 7) Simplified IANA Considerations section 4628 8) Updated References 4630 H.9 Changes from IKEv2-08 to IKEv2-09 August 2003 4632 1) Numerous editorial corrections and clarifications. 4634 2) Added REKEY_SA notify payload to the first message of a 4635 CREATE_CHILD_SA exchange if the new exchange was rekeying an existing 4636 SA. 4638 3) Renamed AES_ENCR128 to AES_ENCR and made it take a single 4639 parameter that is the key size (which may be 128, 192, or 256 bits). 4641 4) Clarified when a newly created SA is useable. 4643 5) Added additional text to section 2.23 specifying how to negotiate 4644 NAT Traversal. 4646 6) Replaced specification of ECN handling with a reference to 4647 [RFC2401bis]. 4649 7) Renumbered payloads so that numbers would not collide with IKEv1 4650 payload numbers in hopes of making code implementing both protocols 4651 simpler. 4653 8) Expanded the Transform ID field (also referred to as Diffie- 4654 Hellman group number) from one byte to two bytes. 4656 9) Removed ability to negotiate Diffie-Hellman groups by explicitly 4657 passing parameters. They must now be negotiated using Transform IDs. 4659 10) Renumbered status codes to be contiguous. 4661 11) Specified the meaning of the "Port" fields in Traffic Selectors 4662 when the ICMP protocol is being used. 4664 12) Removed the specification of D-H Group #5 since it is already 4665 specified in [ADDGROUP. 4667 H.10 Changes from IKEv2-09 to IKEv2-10 August 2003 4669 1) Numerous boilerplate and formatting corrections to comply with RFC 4670 Editorial Guidelines and procedures. 4672 2) Fixed five typographical errors. 4674 3) Added a sentence to the end of "Security considerations" 4675 discouraging the use of non-key-generating EAP mechanisms. 4677 H.11 Changes from IKEv2-10 to IKEv2-11 October 2003 4679 1) Added SHOULD NOT language concerning use of non-key-generating EAP 4680 authentication methods and added reference [EAPMITM]. 4682 2) Clarified use of parallel SAs with identical traffic selectors for 4683 purposes of QoS handling. 4685 3) Fixed description of ECN handling to make normative references to 4686 [RFC 2401bis] and [RFC 3168]. 4688 4) Fixed two typos in the description of NAT traversal. 4690 5) Added specific ASN.1 encoding of certificate bundles in section 4691 3.6. 4693 H.12 Changes from IKEv2-11 to IKEv2-12 January 2004 4695 1) Made the values of the one byte IPsec Protocol ID consistent 4696 between payloads and made the naming more nearly consistent. 4698 2) Changed the specification to require that AUTH payloads be 4699 provided in EAP exchanges even when a non-key generating EAP method 4700 is used. This protects against certain obscure cryptographic 4701 threats. 4703 3) Changed all example IP addresses to be within subnet 10. 4705 4) Specified that issues surrounding weak keys and DES key parity 4706 must be addressed in algorithm documents. 4708 5) Removed the unsupported (and probably untrue) claim that Photuris 4709 cookies were given that name because the IETF always supports 4710 proposals involving cookies. 4712 6) Fixed some text that specified that Transform ID was 1 octet while 4713 everywhere else said it was 2 octets. 4715 7) Corrected the ASN.1 specification of the encoding of X.509 4716 certificate bundles. 4718 8) Added an INVALID_SELECTORS error type. 4720 9) Replaced IANA considerations section with a reference to draft- 4721 ietf-ipsec-ikev2-iana-00.txt. 4723 10) Removed 2 obsolete informative references and added one to a 4724 paper on UDP fragmentation problems. 4726 11) 41 Editorial Corrections and Clarifications. 4728 12) 6 Grammatical and Spelling errors fixed. 4730 13) 4 Corrected capitalizations of MAY/MUST/etc. 4732 14) 4 Attempts to make capitalization and use of underscores more 4733 consistent. 4735 H.12 Changes from IKEv2-12 to IKEv2-13 March 2004 4737 1) Updated copyright and intellectual property right sections per RFC 4738 3667. Added normative references to RFC 3667 and RFC 3668. 4740 2) Updated IANA Considerations section and adjusted some assignment 4741 tables to be consistent with the IANA registries document. Added 4742 Michael Richardson to the acknowledgements. 4744 3) Changed the cryptographic formula for computing the AUTH payload 4745 in the case where EAP authentication is used and the EAP algorithm 4746 does not produce a shared key. Clarified the case where it does 4747 produce a shared key. 4749 4) Extended the EAP authentication protocol by two messages so that 4750 the AUTH message is always sent after the success status is received. 4752 5) Updated reference to ESP encapsulation in UDP and made it 4753 normative. 4755 6) Added notification type ESP_TFC_PADDING_NOT_SUPPORTED. 4757 7) Clarified encoding of port number fields in transport selectors in 4758 the cases of ICMP and OPAQUE. 4760 8) Clarified that the length of the integrity checksum is fixed 4761 length and determined by the negotiated integrity algorithm. 4763 9) Added an informative reference to RFC3715 (NAT Compatibility 4764 Requirements). 4766 10) Fixed 2 typos. 4768 Editor's Address 4770 Charlie Kaufman 4771 Microsoft Corporation 4772 1 Microsoft Way 4773 Redmond, WA 98052 4774 1-425-707-3335 4776 charliek@microsoft.com 4778 Full Copyright Statement 4780 Copyright (C) The Internet Society (2004). This document is subject 4781 to the rights, licenses and restrictions contained in BCP 78 and 4782 except as set forth therein, the authors retain all their rights. 4784 This document and the information contained herein are provided on an 4785 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4786 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 4787 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 4788 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 4789 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4790 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4792 Intellectual Property Statement 4794 The IETF takes no position regarding the validity or scope of any 4795 Intellectual Property Rights or other rights that might be claimed to 4796 pertain to the implementation or use of the technology described in 4797 this document or the extent to which any license under such rights 4798 might or might not be available; nor does it represent that it has 4799 made any independent effort to identify any such rights. Information 4800 on the procedures with respect to rights in RFC documents can be 4801 found in BCP 78 and BCP 79. 4803 Copies of IPR disclosures made to the IETF Secretariat and any 4804 assurances of licenses to be made available, or the result of an 4805 attempt made to obtain a general license or permission for the use of 4806 such proprietary rights by implementers or users of this 4807 specification can be obtained from the IETF on-line IPR repository at 4808 http://www.ietf.org/ipr. 4810 The IETF invites any interested party to bring to its attention any 4811 copyrights, patents or patent applications, or other proprietary 4812 rights that may cover technology that may be required to implement 4813 this standard. Please address the information to the IETF at ietf- 4814 ipr@ietf.org. 4816 Acknowledgement 4818 Funding for the RFC Editor function is currently provided by the 4819 Internet Society. 4821 Expiration 4823 This Internet-Draft (draft-ietf-ipsec-ikev2-13.txt) expires in 4824 September 2004.