idnits 2.17.1 draft-ietf-lwig-ikev2-minimal-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 32 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 2015) is 3328 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CERTREQ' is mentioned on line 264, but not defined == Missing Reference: 'IPSECARCH' is mentioned on line 517, but not defined == Missing Reference: 'MD5' is mentioned on line 975, but not defined == Missing Reference: 'SHA' is mentioned on line 976, but not defined == Missing Reference: 'ADDGROUP' is mentioned on line 997, but not defined == Missing Reference: 'IDNA' is mentioned on line 1135, but not defined == Missing Reference: 'EAI' is mentioned on line 1140, but not defined == Missing Reference: 'PKCS1' is mentioned on line 1251, but not defined Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Light-Weight Implementation Guidance (lwig) T. Kivinen 3 Internet-Draft INSIDE Secure 4 Intended status: Informational March 2015 5 Expires: September 12, 2015 7 Minimal IKEv2 8 draft-ietf-lwig-ikev2-minimal-02.txt 10 Abstract 12 This document describes minimal version of the Internet Key Exchange 13 version 2 (IKEv2) protocol. IKEv2 is a component of IPsec used for 14 performing mutual authentication and establishing and maintaining 15 Security Associations (SAs). IKEv2 includes several optional 16 features, which are not needed in minimal implementations. This 17 document describes what is required from the minimal implementation, 18 and also describes various optimizations which can be done. The 19 protocol described here is compliant with full IKEv2 with exception 20 that this document describes mainly shared secret authentication 21 (IKEv2 requires support for certificate authentication in addition to 22 shared secret authentication). 24 This document does not update or modify RFC 7296, but provides more 25 compact description of the minimal version of the protocol. If this 26 document and RFC 7296 conflicts then RFC 7296 is the authoritative 27 description. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 43 This document may contain material from IETF Documents or IETF 44 Contributions published or made publicly available before November 45 10, 2008. The person(s) controlling the copyright in some of this 46 material may not have granted the IETF Trust the right to allow 47 modifications of such material outside the IETF Standards Process. 48 Without obtaining an adequate license from the person(s) controlling 49 the copyright in such materials, this document may not be modified 50 outside the IETF Standards Process, and derivative works of it may 51 not be created outside the IETF Standards Process, except to format 52 it for publication as an RFC or to translate it into languages other 53 than English. 55 This Internet-Draft will expire on September 12, 2015. 57 Copyright Notice 59 Copyright (c) 2015 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 64 license-info) in effect on the date of publication of this document. 65 Please review these documents carefully, as they describe your rights 66 and restrictions with respect to this document. Code Components 67 extracted from this document must include Simplified BSD License text 68 as described in Section 4.e of the Trust Legal Provisions and are 69 provided without warranty as described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 74 1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2.1. Initial Exchange . . . . . . . . . . . . . . . . . . . . . 4 77 2.2. Other Exchanges . . . . . . . . . . . . . . . . . . . . . 9 78 2.3. Generating Keying Material . . . . . . . . . . . . . . . . 10 79 3. Conformance Requirements . . . . . . . . . . . . . . . . . . . 11 80 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 82 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 85 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 86 Appendix A. Header and Payload Formats . . . . . . . . . . . . . . 12 87 Appendix A.1. The IKE Header . . . . . . . . . . . . . . . . . 12 88 Appendix A.2. Generic Payload Header . . . . . . . . . . . . . 14 89 Appendix A.3. Security Association Payload . . . . . . . . . . 16 90 Appendix A.3.1. Proposal Substructure . . . . . . . . . . . . 17 91 Appendix A.3.2. Transform Substructure . . . . . . . . . . . 18 92 Appendix A.3.3. Valid Transform Types by Protocol . . . . . . 20 93 Appendix A.3.4. Transform Attributes . . . . . . . . . . . . 21 94 Appendix A.4. Key Exchange Payload . . . . . . . . . . . . . . 21 95 Appendix A.5. Identification Payloads . . . . . . . . . . . . . 22 96 Appendix A.6. Certificate Payload . . . . . . . . . . . . . . . 23 97 Appendix A.7. Certificate Request Payload . . . . . . . . . . . 24 98 Appendix A.8. Authentication Payload . . . . . . . . . . . . . 24 99 Appendix A.9. Nonce Payload . . . . . . . . . . . . . . . . . . 25 100 Appendix A.10. Notify Payload . . . . . . . . . . . . . . . . . 25 101 Appendix A.10.1. Notify Message Types . . . . . . . . . . . . 26 102 Appendix A.11. Traffic Selector Payload . . . . . . . . . . . . 27 103 Appendix A.11.1. Traffic Selector . . . . . . . . . . . . . . 29 104 Appendix A.12. Encrypted Payload . . . . . . . . . . . . . . . . 30 105 Appendix B. Useful Optional Features . . . . . . . . . . . . . . . 31 106 Appendix B.1. IKE SA Delete Notification . . . . . . . . . . . 31 107 Appendix B.2. Raw Public Keys . . . . . . . . . . . . . . . . . 32 108 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33 110 1. Introduction 112 This document tells what minimal IKEv2 implementation could look 113 like. Minimal IKEv2 implementation only supports initiator end of 114 the protocol. It only supports the initial IKE_SA_INIT and IKE_AUTH 115 exchanges and does not initiate any other exchanges. It also replies 116 with empty (or error) message to all incoming requests. 118 This means that most of the optional features of IKEv2 are left out: 119 NAT Traversal, IKE SA rekey, Child SA Rekey, Multiple Child SAs, 120 Deleting Child / IKE SAs, Configuration payloads, EAP authentication, 121 COOKIEs etc. 123 Some optimizations can be done because of limited set of supported 124 features, and this text should not be considered for generic IKEv2 125 implementations (for example Message IDs can be done as specified as 126 implementation is only sending out IKE_SA_INIT and IKE_AUTH request, 127 and do not ever send any other request). 129 This document should be stand-alone, meaning everything needed to 130 implement IKEv2 is copied here except the description of the 131 cryptographic algorithms. The IKEv2 specification has lots of 132 background information and rationale which has been omitted from this 133 document. 135 Numerous additional numeric values from IANA registries have been 136 omitted from this document, only those which are of interest for 137 minimal implementation are listed in this document. 139 The main body of this document describes how to use the shared secret 140 authentication in the IKEv2, as it is easiest to implement. In some 141 cases that is not enough and the [raw-public-keys] describes how to 142 use Raw Public keys instead of shared secret authentication. 144 For more information check the full IKEv2 specification in RFC 7296 145 [RFC7296] and [IKEV2IANA]. 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [RFC2119]. 151 1.1. Use Cases 152 One use case for this kind of minimal implementation is in small 153 devices doing machine to machine communication. In such environments 154 the node initiating connections is usually very small and the other 155 end of the communication channel is some kind of larger device. 157 An example of the small initiating node could be an remote garage 158 door opener device. I.e. device having buttons which open and close 159 garage door, and which connects to the home area network server over 160 wireless link. 162 Another example of the such device is some kind of sensor device, for 163 example room temperature sensor, which sends periodic temperature 164 data to some centralized node. 166 Those devices are usually sleeping long times, and only wakes up 167 because of user interaction or periodically. The data transfer is 168 always initiated from the sleeping node and after they send packets 169 there might be ACKs or other packets coming back before they go back 170 to sleep. If some data needs to be transferred from server node to 171 the small device, it can be implemented by polling, i.e. small node 172 periodically polls for the server to see if it for example have some 173 configuration changes or similar. 175 2. Exchanges 177 2.1. Initial Exchange 179 All IKEv2 communications consist of pairs of messages: a request and 180 a response. The pair is called an "exchange", and is sometimes 181 called a "request/response pair". Every request requires a response. 183 For every pair of IKEv2 messages, the initiator is responsible for 184 retransmission in the event of a timeout. The responder MUST never 185 retransmit a response unless it receives a retransmission of the 186 request. 188 IKEv2 is a reliable protocol: the initiator MUST retransmit a request 189 until it either receives a corresponding response or deems the IKE SA 190 to have failed. A retransmission from the initiator MUST be bitwise 191 identical to the original request. Retransmission times MUST 192 increase exponentially. 194 IKEv2 is run over UDP port 500. All IKEv2 implementations MUST be 195 able to send, receive, and process IKEv2 messages that are up to 1280 196 octets long. An implementation MUST accept incoming requests even if 197 the source port is not 500, and MUST respond to the address and port 198 from which the request was received. 200 The minimal implementation of IKEv2 only uses first two exchanges 201 called IKE_SA_INIT and IKE_AUTH. Those are used to create the IKE SA 202 and the first child SA. In addition to those messages minimal IKEv2 203 implementation need to understand CREATE_CHILD_SA request so it can 204 reply with CREATE_CHILD_SA error response saying NO_ADDITIONAL_SAS to 205 it, and understand INFORMATIONAL request so much, it can reply with 206 empty INFORMATIONAL response to it. There is no requirement to be 207 able to respond to any other requests. 209 All messages following the IKE_SA_INIT exchange are cryptographically 210 protected using the cryptographic algorithms and keys negotiated in 211 the IKE_SA_INIT exchange. 213 Every IKEv2 message contains a Message ID as part of its fixed 214 header. This Message ID is used to match up requests and responses, 215 and to identify retransmissions of messages. 217 Minimal implementation need only support of being initiator, so it 218 does not ever need to send any other request as one IKE_SA_INIT, and 219 one IKE_AUTH message. As those messages have fixed Message IDs (0 220 and 1) it does not need to keep track of its own Message IDs for 221 outgoing requests after that. 223 Minimal implementations can also optimize Message ID handling of the 224 incoming requests, as they do not need to protect incoming requests 225 against replays. This is possible because minimal implementation 226 will only return error or empty notifications replies to incoming 227 requests. This means that any of those incoming requests do not have 228 any effect on the minimal implementation, thus processing them again 229 does not cause any harm. Because of this the minimal implementation 230 can always answer to request coming in, with the same Message ID than 231 what the request had and then forget the request/response pair 232 immediately. This means there is no need to keep any kind of track 233 of Message IDs of the incoming requests. 235 In the following descriptions, the payloads contained in the message 236 are indicated by names as listed below. 238 Notation Payload 239 ----------------------------------------- 240 AUTH Authentication 241 CERTREQ Certificate Request 242 D Delete 243 HDR IKE header (not a payload) 244 IDi Identification - Initiator 245 IDr Identification - Responder 246 KE Key Exchange 247 Ni, Nr Nonce 248 N Notify 249 SA Security Association 250 SK Encrypted and Authenticated 251 TSi Traffic Selector - Initiator 252 TSr Traffic Selector - Responder 254 The initial exchanges are as follows: 256 Initiator Responder 257 ------------------------------------------------------------------- 258 HDR(SPIi=xxx, SPIr=0, IKE_SA_INIT, 259 Flags: Initiator, Message ID=0), 260 SAi1, KEi, Ni --> 262 <-- HDR(SPIi=xxx, SPIr=yyy, IKE_SA_INIT, 263 Flags: Response, Message ID=0), 264 SAr1, KEr, Nr, [CERTREQ] 266 HDR contains the Security Parameter Indexes (SPIs), version numbers, 267 and flags of various sorts. Each endpoint chooses one of the two 268 SPIs and MUST choose them so as to be unique identifiers of an IKE 269 SA. An SPI value of zero is special: it indicates that the remote SPI 270 value is not yet known by the sender. 272 Incoming IKEv2 packets are mapped to an IKE SA only using the 273 packet's SPI, not using (for example) the source IP address of the 274 packet. 276 The SAi1 payload states the cryptographic algorithms the initiator 277 supports for the IKE SA. The KEi and KEr payload contain Diffie- 278 Hellman values and Ni and Nr are the nonces. The SAr1 contains 279 chosen cryptographic suite from initiator's offered choices. Minimal 280 implementation using shared secrets will ignore the CERTREQ payload. 282 Minimal implementation will most likely support exactly one set of 283 cryptographic algorithms, meaning the SAi1 payload will be static. 284 It needs to check that the SAr1 received matches the proposal it 285 sent. 287 At this point in the negotiation, each party can generate SKEYSEED, 288 from which all keys are derived for that IKE SA. 290 SKEYSEED = prf(Ni | Nr, g^ir) 292 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } 293 = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) 295 prf+ (K,S) = T1 | T2 | T3 | T4 | ... 297 where: 298 T1 = prf (K, S | 0x01) 299 T2 = prf (K, T1 | S | 0x02) 300 T3 = prf (K, T2 | S | 0x03) 301 T4 = prf (K, T3 | S | 0x04) 302 ... 304 (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, 305 SK_pi, and SK_pr are taken in order from the generated bits of the 306 prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman 307 exchange. g^ir is represented as a string of octets in big endian 308 order padded with zeros if necessary to make it the length of the 309 modulus. Ni and Nr are the nonces, stripped of any headers. 311 The SK_d is used for deriving new keys for the Child SAs. The SK_ai 312 and SK_ar are used as a key to the integrity protection algorithm for 313 authenticating the component messages of subsequent exchanges. The 314 SK_ei and SK_er are used for encrypting (and of course decrypting) 315 all subsequent exchanges. The SK_pi and SK_pr are used when 316 generating an AUTH payload. The lengths of SK_d, SK_pi, and SK_pr 317 MUST be the preferred key length of the PRF agreed upon. 319 A separate SK_e and SK_a is computed for each direction. The keys 320 used to protect messages from the original initiator are SK_ai and 321 SK_ei. The keys used to protect messages in the other direction are 322 SK_ar and SK_er. The notation SK { ... } indicates that these 323 payloads are encrypted and integrity protected using that direction's 324 SK_e and SK_a. 326 Initiator Responder 327 ------------------------------------------------------------------- 328 HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, 329 Flags: Initiator, Message ID=1), 330 SK {IDi, AUTH, SAi2, TSi, TSr, 331 N(INITIAL_CONTACT)} --> 333 <-- HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags: 334 Response, Message ID=1), 335 SK {IDr, AUTH, SAr2, TSi, TSr} 337 The initiator asserts its identity with the IDi payload, proves 338 knowledge of the secret corresponding to IDi and integrity protects 339 the contents of the first message using the AUTH payload. The 340 responder asserts its identity with the IDr payload, authenticates 341 its identity and protects the integrity of the second message with 342 the AUTH payload. 344 As minimal implementation usually has only one host where it 345 connects, and that means it has only one shared secret. This means 346 it does not need to care about IDr payload that much. If the other 347 end sends AUTH payload which initiator can verify using the shared 348 secret it has, then it knows the other end is the peer it was 349 configured to talk to. 351 In the IKE_AUTH initiator sends SA offer(s) in the SAi2 payload, and 352 the proposed Traffic Selectors for the proposed Child SA in the TSi 353 and TSr payloads. The responder replies with the accepted offer in 354 an SAr2 payload, and selected Traffic Selectors. The selected 355 Traffic Selectors may be a subset of what the initiator proposed. 357 In the minimal implementation both SA payloads and TS payloads are 358 going to be mostly static. The SA payload will have the SPI value 359 used in the ESP, but the algorithms are most likely going to be the 360 one and only supported set. The TS payloads on the initiator end 361 will most likely say from any to any, i.e. full wildcard ranges, or 362 from the local IP to the remote IP. In the wildcard case the server 363 quite often narrow the range down to the one IP address pair. Using 364 single IP address pair as a traffic selectors when sending IKE_AUTH 365 will simplify processing as then server will either accept that pair 366 or return error. If wildcard ranges are used, there is possibility 367 that server narrows the range to some other range than what was 368 intended. 370 The IKE_AUTH (and IKE_SA_INIT) responses may contain multiple status 371 notification payloads which can be ignored by minimal implementation. 372 There can also be Vendor ID, Certificate, Certificate Request or 373 Configuration payloads, but any payload unknown to minimal 374 implementation can simply be skipped over (response messages cannot 375 have critical unsupported payloads). 377 The exchange above includes N(INITIAL_CONTACT) notification in the 378 request as that is quite commonly sent by the minimal implementation. 379 It indicates to the other end that the initiator does not have any 380 other IKE SAs between them, and if there is any left from previous 381 runs they can be deleted. As minimal implementation does not delete 382 IKE SAs by sending IKE SA delete, this will help server to clean up 383 leftover state. 385 When using shared secret authentication, the peers are authenticated 386 by having each calculating a MAC over a block of data: 388 For the initiator: 389 AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), 390 ) 391 For the responder: 392 AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), 393 ) 395 The string "Key Pad for IKEv2" is 17 ASCII characters without null 396 termination. The implementation can precalculate the inner prf and 397 only store the output of it. This is possible because minimal IKEv2 398 implementation usually only supports one PRF. 400 The initiator signs the first message (IKE_SA_INIT request), starting 401 with the first octet of the first SPI in the header and ending with 402 the last octet of the last payload in that first message. Appended 403 to this (for purposes of computing the signature) are the responder's 404 nonce Nr, and the value prf(SK_pi, IDi'). 406 For the responder, the octets to be signed start with the first octet 407 of the first SPI in the header of the second message (IKE_SA_INIT 408 response) and end with the last octet of the last payload in that 409 second message. Appended to this are the initiator's nonce Ni, and 410 the value prf(SK_pr, IDr'). 412 In these calculations, IDi' and IDr' are the entire ID payloads 413 excluding the fixed header and the Ni, and Nr are only the value, not 414 the payload containing it. Note that neither the nonce Ni/Nr nor the 415 value prf(SK_pr, IDr')/prf(SK_pi, IDi') are transmitted. 417 The initiator's signed octets can be described as: 419 InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI 420 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR 421 RealIKEHDR = SPIi | SPIr | . . . | Length 422 RealMessage1 = RealIKEHDR | RestOfMessage1 423 NonceRPayload = PayloadHeader | NonceRData 424 InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload 425 RestOfInitIDPayload = IDType | RESERVED | InitIDData 426 MACedIDForI = prf(SK_pi, RestOfInitIDPayload) 428 The responder's signed octets can be described as: 430 ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR 431 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR 432 RealIKEHDR = SPIi | SPIr | . . . | Length 433 RealMessage2 = RealIKEHDR | RestOfMessage2 434 NonceIPayload = PayloadHeader | NonceIData 435 ResponderIDPayload = PayloadHeader | RestOfRespIDPayload 436 RestOfRespIDPayload = IDType | RESERVED | RespIDData 437 MACedIDForR = prf(SK_pr, RestOfRespIDPayload) 439 Note that all of the payloads inside the RestOfMessageX are included 440 under the signature, including any payload types not listed in this 441 document. 443 The initiator might also get unauthenticated response back having 444 notification payload with error code inside. As that error code will 445 be unauthenticated and may be faked, there is no need to do anything 446 for those. Minimal implementation can simply ignore those errors, 447 and retransmit its request until it times out and if that happens 448 then the IKE SA (and Child SA) creation failed. 450 Responder might also reply with IKE_AUTH response packet which do not 451 contain payloads needed to set up Child SA (SAr2, TSi and TSr), but 452 contains AUTH payload and an error. As minimal implementation 453 probably do not support multiple SAs nor sending the CREATE_CHILD_SA 454 exchanges the IKE SA is useless for initiator. It can delete the IKE 455 SA and start over from the beginning (which might fail again if this 456 is configuration error, or it might succeed if this was temporal 457 failure). 459 2.2. Other Exchanges 461 Minimal implementation MUST be able to reply to INFORMATIONAL request 462 by sending empty response back: 464 Initiator Responder 465 ------------------------------------------------------------------- 466 <-- HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL, 467 Flags: none, Message ID=m), 468 SK {...} 470 HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL, 471 Flags: Initiator | Response, 472 Message ID=m), 473 SK {} --> 475 Minimal implementation also MUST be able to reply to incoming 476 CREATE_CHILD_SA requests. Typical implementation will reject the 477 CREATE_CHILD_SA exchanges by sending NO_ADDITIONAL_SAS error notify 478 back: 480 Initiator Responder 481 ------------------------------------------------------------------- 482 <-- HDR(SPIi=xxx, SPIy=yyy, CREATE_CHILD_SA, 483 Flags: none, Message ID=m), 484 SK {...} 486 HDR(SPIi=xxx, SPIr=yyy, CREATE_CHILD_SA, 487 Flags: Initiator | Response, Message ID=m), 488 SK {N(NO_ADDITIONAL_SAS)} --> 490 Note, that INFORMATIONAL and CREATE_CHILD_SA requests might contain 491 unsupported critical payloads, in which case complient implementation 492 MUST ignore the request, and send response message back having the 493 UNSUPPORTED_CRITICAL_PAYLOAD notification. That notification payload 494 data contains one-octet payload type of the unsupported critical 495 payload. 497 2.3. Generating Keying Material 499 Keying material for Child SA created by the IKE_AUTH exchange is 500 generated as follows: 502 KEYMAT = prf+(SK_d, Ni | Nr) 504 Where Ni and Nr are the nonces from the IKE_SA_INIT exchange. 506 A single CHILD_SA negotiation may result in multiple Security 507 Associations. ESP and AH SAs exist in pairs (one in each direction), 508 so two SAs are created in a single Child SA negotiation for them. 509 The keying material for each Child SA MUST be taken from the expanded 510 KEYMAT using the following rules: 512 o All keys for SAs carrying data from the initiator to the responder 513 are taken before SAs going from the responder to the initiator. 515 o If an IPsec protocol requires multiple keys, the order in which 516 they are taken from the SA's keying material needs to be described 517 in the protocol's specification. For ESP and AH, [IPSECARCH] 518 defines the order, namely: the encryption key (if any) MUST be 519 taken from the first bits and the integrity key (if any) MUST be 520 taken from the remaining bits. 522 Each cryptographic algorithm takes a fixed number of bits of keying 523 material specified as part of the algorithm, or negotiated in SA 524 payloads. 526 3. Conformance Requirements 528 For an implementation to be called conforming to RFC 7296 529 specification, it MUST be possible to configure it to accept the 530 following: 532 o Public Key Infrastructure using X.509 (PKIX) Certificates 533 containing and signed by RSA keys of size 1024 or 2048 bits, where 534 the ID passed is any of ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR, or 535 ID_DER_ASN1_DN. 537 o Shared key authentication where the ID passed is any of ID_KEY_ID, 538 ID_FQDN, or ID_RFC822_ADDR. 540 o Authentication where the responder is authenticated using PKIX 541 Certificates and the initiator is authenticated using shared key 542 authentication. 544 This document only supports the second bullet, it does not support 545 PKIX certificates at all. As full RFC7296 responders must also 546 support that shared key authentication, this allows minimal 547 implementation to be able to interoperate with all RFC 7296 compliant 548 implementations. 550 PKIX certificates are left out from the minimal implementation as 551 those would add quite a lot of complexity to the implementation. The 552 actual code changes needed in the IKEv2 protocol are small, but the 553 certificate validation code would be more complex than the whole 554 minimal IKEv2 implementation itself. If public key based 555 authentication is needed for scalability reasons, then raw public 556 keys would probably be the best compromize (see [raw-public-keys]). 558 4. Security Considerations 560 As this implements same protocol as RFC 7296 this means all security 561 considerations from it also apply to this document. 563 5. IANA Considerations 565 There is no new IANA considerations in this document. 567 6. Acknowledgements 569 Most of the contents of this document is copied from the RFC 7296. 571 7. References 573 7.1. Normative References 575 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 576 Requirement Levels", BCP 14, RFC 2119, March 1997. 578 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P. and T. 579 Kivinen, "Internet Key Exchange Protocol Version 2 580 (IKEv2)", STD 79, RFC 7296, October 2014. 582 7.2. Informative References 584 [I-D.ietf-ipsecme-oob-pubkey] 585 Kivinen, T, Wouters, P and H Tschofenig, "More Raw Public 586 Keys for IKEv2", Internet-Draft draft-ietf-ipsecme-oob- 587 pubkey-00, April 2013. 589 [IKEV2IANA] 590 "Internet Key Exchange Version 2 (IKEv2) Parameters", , 591 . 593 [MODES] National Institute of Standards and Technology, U.S. 594 Department of Commerce, "Recommendation for Block Cipher 595 Modes of Operation", SP 800-38A, 2001. 597 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 598 Housley, R. and W. Polk, "Internet X.509 Public Key 599 Infrastructure Certificate and Certificate Revocation List 600 (CRL) Profile", RFC 5280, May 2008. 602 Appendix A. Header and Payload Formats 604 This appendix describes actual packet payload formats. This is 605 required to make the document self contained. The descriptions are 606 mostly copied from the RFC7296 and more information can be found from 607 there. 609 Various payload contains RESERVED fields and those MUST be sent as 610 zero and MUST be ignored on receipt. 612 All multi-octet fields representing integers are laid out in big 613 endian order (also known as "most significant byte first", or 614 "network byte order"). 616 Appendix A.1. The IKE Header 617 Each IKEv2 message begins with the IKE header, denoted HDR in this 618 document. Following the header are one or more IKE payloads each 619 identified by a "Next Payload" field in the preceding payload. 620 Payloads are identified in the order in which they appear in an IKE 621 message by looking in the "Next Payload" field in the IKE header, and 622 subsequently according to the "Next Payload" field in the IKE payload 623 itself until a "Next Payload" field of zero indicates that no 624 payloads follow. If a payload of type "Encrypted" is found, that 625 payload is decrypted and its contents parsed as additional payloads. 626 An Encrypted payload MUST be the last payload in a packet and an 627 Encrypted payload MUST NOT contain another Encrypted payload. 629 The format of the IKE header is shown in Figure 1. 631 1 2 3 632 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 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | IKE SA Initiator's SPI | 635 | | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | IKE SA Responder's SPI | 638 | | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Next Payload | MjVer | MnVer | Exchange Type | Flags | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | Message ID | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | Length | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 Figure 1: IKE Header Format 649 o Initiator's SPI (8 octets) - A value chosen by the initiator to 650 identify a unique IKE Security Association. This value MUST NOT 651 be zero. 653 o Responder's SPI (8 octets) - A value chosen by the responder to 654 identify a unique IKE Security Association. This value MUST be 655 zero in the first message of an IKE initial exchange. 657 o Next Payload (1 octet) - Indicates the type of payload that 658 immediately follows the header. The format and value of each 659 payload are defined below. 661 o Major Version (4 bits) - Indicates the major version of the IKE 662 protocol in use. Implementations based on this version of IKE 663 MUST set the major version to 2 and MUST drop the messages with a 664 higher major version number. 666 o Minor Version (4 bits) - Indicates the minor version of the IKE 667 protocol in use. Implementations based on this version of IKE 668 MUST set the minor version to 0. They MUST ignore the minor 669 version number of received messages. 671 o Exchange Type (1 octet) - Indicates the type of exchange being 672 used. This constrains the payloads sent in each message in an 673 exchange. 675 Exchange Type Value 676 ---------------------------------- 677 IKE_SA_INIT 34 678 IKE_AUTH 35 679 CREATE_CHILD_SA 36 680 INFORMATIONAL 37 682 o Flags (1 octet) - Indicates specific options that are set for the 683 message. Presence of options is indicated by the appropriate bit 684 in the flags field being set. The bits are as follows: 686 +-+-+-+-+-+-+-+-+ 687 |X|X|R|V|I|X|X|X| 688 +-+-+-+-+-+-+-+-+ 690 In the description below, a bit being 'set' means its value is '1', 691 while 'cleared' means its value is '0'. 'X' bits MUST be cleared when 692 sending and MUST be ignored on receipt. 694 * R (Response) - This bit indicates that this message is a response 695 to a message containing the same Message ID. This bit MUST be 696 cleared in all request messages and MUST be set in all responses. 697 An IKEv2 endpoint MUST NOT generate a response to a message that 698 is marked as being a response. 700 * V (Version) - This bit indicates that the transmitter is capable 701 of speaking a higher major version number of the protocol than the 702 one indicated in the major version number field. Implementations 703 of IKEv2 MUST clear this bit when sending and MUST ignore it in 704 incoming messages. 706 * I (Initiator) - This bit MUST be set in messages sent by the 707 original initiator of the IKE SA and MUST be cleared in messages 708 sent by the original responder. It is used by the recipient to 709 determine which eight octets of the SPI were generated by the 710 recipient. This bit changes to reflect who initiated the last 711 rekey of the IKE SA. 713 o Message ID (4 octets, unsigned integer) - Message identifier used 714 to control retransmission of lost packets and matching of requests 715 and responses. It is essential to the security of the protocol 716 because it is used to prevent message replay attacks. 718 o Length (4 octets, unsigned integer) - Length of the total message 719 (header + payloads) in octets. 721 Appendix A.2. Generic Payload Header 722 Each IKE payload begins with a generic payload header, shown in 723 Figure 2. Figures for each payload below will include the generic 724 payload header, but for brevity, the description of each field will 725 be omitted. 727 1 2 3 728 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 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | Next Payload |C| RESERVED | Payload Length | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 Figure 2: Generic Payload Header 735 The Generic Payload Header fields are defined as follows: 737 o Next Payload (1 octet) - Identifier for the payload type of the 738 next payload in the message. If the current payload is the last 739 in the message, then this field will be 0. This field provides a 740 "chaining" capability whereby additional payloads can be added to 741 a message by appending each one to the end of the message and 742 setting the "Next Payload" field of the preceding payload to 743 indicate the new payload's type. An Encrypted payload, which must 744 always be the last payload of a message, is an exception. It 745 contains data structures in the format of additional payloads. In 746 the header of an Encrypted payload, the Next Payload field is set 747 to the payload type of the first contained payload (instead of 0); 748 conversely, the Next Payload field of the last contained payload 749 is set to zero). The payload type values needed for minimal 750 implementations are listed here. 752 Next Payload Type Notation Value 753 -------------------------------------------------- 754 No Next Payload 0 755 Security Association SA 33 756 Key Exchange KE 34 757 Identification - Initiator IDi 35 758 Identification - Responder IDr 36 759 Certificate CERT 37 760 Certificate Request CERTREQ 38 761 Authentication AUTH 39 762 Nonce Ni, Nr 40 763 Notify N 41 764 Delete D 42 765 Traffic Selector - Initiator TSi 44 766 Traffic Selector - Responder TSr 45 767 Encrypted and Authenticated SK 46 768 o Critical (1 bit) - MUST be set to zero if the sender wants the 769 recipient to skip this payload if it does not understand the 770 payload type code in the Next Payload field of the previous 771 payload. MUST be set to one if the sender wants the recipient to 772 reject this entire message if it does not understand the payload 773 type. MUST be ignored by the recipient if the recipient 774 understands the payload type code. MUST be set to zero for 775 payload types defined in this document. Note that the critical 776 bit applies to the current payload rather than the "next" payload 777 whose type code appears in the first octet. 779 o Payload Length (2 octets, unsigned integer) - Length in octets of 780 the current payload, including the generic payload header. 782 Appendix A.3. Security Association Payload 784 The Security Association payload, denoted SA in this document, is 785 used to negotiate attributes of a Security Association. 787 An SA payload consists of one or more proposals. Each proposal 788 includes one protocol. Each protocol contains one or more transforms 789 -- each specifying a cryptographic algorithm. Each transform 790 contains zero or more attributes (attributes are needed only if the 791 Transform ID does not completely specify the cryptographic algorithm, 792 currently only attribute is key length attribute for variable length 793 ciphers, meaning there is exactly zero or one attribute). 795 The responder MUST choose a single suite, which may be any subset of 796 the SA proposal following the rules below. 798 Each proposal contains one protocol. If a proposal is accepted, the 799 SA response MUST contain the same protocol. Each IPsec protocol 800 proposal contains one or more transforms. Each transform contains a 801 Transform Type. The accepted cryptographic suite MUST contain 802 exactly one transform of each type included in the proposal. For 803 example: if an ESP proposal includes transforms ENCR_3DES, ENCR_AES w 804 /keysize 128, ENCR_AES w/keysize 256, AUTH_HMAC_MD5, and 805 AUTH_HMAC_SHA, the accepted suite MUST contain one of the ENCR_ 806 transforms and one of the AUTH_ transforms. Thus, six combinations 807 are acceptable. 809 Minimal implementation can create very simple SA proposal, i.e. 810 include one proposal, which contains exactly one transform for each 811 transform type. It is important to only include one Diffie-Hellman 812 group in proposal, so there is no need to do INVALID_KE_PAYLOAD 813 processing in responses. 815 When parsing an SA, an implementation MUST check that the total 816 Payload Length is consistent with the payload's internal lengths and 817 counts. Proposals, Transforms, and Attributes each have their own 818 variable-length encodings. They are nested such that the Payload 819 Length of an SA includes the combined contents of the SA, Proposal, 820 Transform, and Attribute information. The length of a Proposal 821 includes the lengths of all Transforms and Attributes it contains. 822 The length of a Transform includes the lengths of all Attributes it 823 contains. 825 Each Proposal/Protocol structure is followed by one or more transform 826 structures. The number of different transforms is generally 827 determined by the Protocol. AH generally has two transforms: 828 Extended Sequence Numbers (ESNs) and an integrity check algorithm. 829 ESP generally has three: ESN, an encryption algorithm, and an 830 integrity check algorithm. IKEv2 generally has four transforms: a 831 Diffie-Hellman group, an integrity check algorithm, a PRF algorithm, 832 and an encryption algorithm. For each Protocol, the set of 833 permissible transforms is assigned Transform ID numbers, which appear 834 in the header of each transform. 836 If there are multiple transforms with the same Transform Type, the 837 proposal is an OR of those transforms. If there are multiple 838 transforms with different Transform Types, the proposal is an AND of 839 the different groups. 841 A given transform MAY have one or more Attributes. Attributes are 842 necessary when the transform can be used in more than one way, as 843 when an encryption algorithm has a variable key size. The transform 844 would specify the algorithm and the attribute would specify the key 845 size. To propose alternate values for an attribute (for example, 846 multiple key sizes for the AES encryption algorithm), an 847 implementation MUST include multiple transforms with the same 848 Transform Type each with a single Attribute. 850 1 2 3 851 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 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Next Payload |C| RESERVED | Payload Length | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | | 856 ~ ~ 857 | | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 Figure 3: Security Association Payload 862 o Proposals (variable) - One or more proposal substructures. 864 Appendix A.3.1. Proposal Substructure 865 1 2 3 866 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 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | 0 (last) or 2 | RESERVED | Proposal Length | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | Proposal Num | Protocol ID | SPI Size |Num Transforms| 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 ~ SPI (variable) ~ 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | | 875 ~ ~ 876 | | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 Figure 4: Proposal Substructure 881 o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the 882 last Proposal Substructure in the SA. 884 o Proposal Length (2 octets, unsigned integer) - Length of this 885 proposal, including all transforms and attributes that follow. 887 o Proposal Num (1 octet) - When a proposal is made, the first 888 proposal in an SA payload MUST be 1, and subsequent proposals MUST 889 be one more than the previous proposal. When a proposal is 890 accepted, the proposal number in the SA payload MUST match the 891 number on the proposal sent that was accepted. 893 o Protocol ID (1 octet) - Specifies the IPsec protocol identifier 894 for the current negotiation. 896 Protocol Protocol ID 897 ----------------------------------- 898 IKE 1 899 AH 2 900 ESP 3 902 o SPI Size (1 octet) - For an initial IKE SA negotiation, this field 903 MUST be zero; the SPI is obtained from the outer header. During 904 subsequent negotiations, it is equal to the size, in octets, of 905 the SPI of the corresponding protocol (8 for IKE, 4 for ESP and 906 AH). 908 o Num Transforms (1 octet) - Specifies the number of transforms in 909 this proposal. 911 o SPI (variable) - The sending entity's SPI. When the SPI Size field 912 is zero, this field is not present in the Security Association 913 payload. 915 o Transforms (variable) - One or more transform substructures. 917 Appendix A.3.2. Transform Substructure 918 1 2 3 919 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 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | 0 (last) or 3 | RESERVED | Transform Length | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 |Transform Type | RESERVED | Transform ID | 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | | 926 ~ Transform Attributes ~ 927 | | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 Figure 5: Transform Substructure 932 o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the 933 last Transform Substructure in the Proposal. 935 o Transform Length - The length (in octets) of the Transform 936 Substructure including Header and Attributes. 938 o Transform Type (1 octet) - The type of transform being specified 939 in this transform. Different protocols support different 940 Transform Types. For some protocols, some of the transforms may 941 be optional. If a transform is optional and the initiator wishes 942 to propose that the transform be omitted, no transform of the 943 given type is included in the proposal. If the initiator wishes 944 to make use of the transform optional to the responder, it 945 includes a transform substructure with Transform ID = 0 as one of 946 the options. 948 o Transform ID (2 octets) - The specific instance of the Transform 949 Type being proposed. 951 The relevant Transform Type values are listed below. 953 Description Trans. Used In 954 Type 955 ------------------------------------------------------------------ 956 Encryption Algorithm (ENCR) 1 IKE and ESP 957 Pseudorandom Function (PRF) 2 IKE 958 Integrity Algorithm (INTEG) 3 IKE, AH, optional in ESP 959 Diffie-Hellman group (D-H) 4 IKE, optional in AH & ESP 960 Extended Sequence Numbers (ESN) 5 AH and ESP 962 For Transform Type 1 (Encryption Algorithm), the relevant Transform 963 IDs are listed below. 965 Name Number Defined In 966 --------------------------------------------------- 967 ENCR_3DES 3 (RFC2451) 968 ENCR_AES_CBC 12 (RFC3602) 970 For Transform Type 2 (Pseudorandom Function), the relevant Transform 971 IDs are listed below. 973 Name Number Defined In 974 ------------------------------------------------------ 975 PRF_HMAC_MD5 1 (RFC2104), [MD5] 976 PRF_HMAC_SHA1 2 (RFC2104), [SHA] 978 For Transform Type 3 (Integrity Algorithm), relevant Transform IDs 979 are listed below. 981 Name Number Defined In 982 ---------------------------------------- 983 NONE 0 984 AUTH_HMAC_MD5_96 1 (RFC2403) 985 AUTH_HMAC_SHA1_96 2 (RFC2404) 986 AUTH_AES_XCBC_96 5 (RFC3566) 988 For Transform Type 4 (Diffie-Hellman group), relevant Transform IDs 989 are listed below. 991 Name Number Defined In 992 ---------------------------------------- 993 NONE 0 994 768-bit MODP 1 Appendix B 995 1024-bit MODP 2 Appendix B 996 1536-bit MODP 5 [ADDGROUP] 997 2048-bit MODP 14 [ADDGROUP] 999 For Transform Type 5 (Extended Sequence Numbers), relevant Transform 1000 IDs are listed below. 1002 Name Number 1003 -------------------------------------------- 1004 No Extended Sequence Numbers 0 1005 Extended Sequence Numbers 1 1007 Note that an initiator who supports ESNs will usually include two ESN 1008 transforms, with values "0" and "1", in its proposals. A proposal 1009 containing a single ESN transform with value "1" means that using 1010 normal (non-extended) sequence numbers is not acceptable. 1012 Appendix A.3.3. Valid Transform Types by Protocol 1014 The number and type of transforms that accompany an SA payload are 1015 dependent on the protocol in the SA itself. An SA payload proposing 1016 the establishment of an SA has the following mandatory and optional 1017 Transform Types. A compliant implementation MUST understand all 1018 mandatory and optional types for each protocol it supports (though it 1019 need not accept proposals with unacceptable suites). A proposal MAY 1020 omit the optional types if the only value for them it will accept is 1021 NONE. 1023 Protocol Mandatory Types Optional Types 1024 --------------------------------------------------- 1025 IKE ENCR, PRF, INTEG, D-H 1026 ESP ENCR, ESN INTEG, D-H 1027 AH INTEG, ESN D-H 1029 Appendix A.3.4. Transform Attributes 1031 Transform type 1 (Encryption Algorithm) transforms might include one 1032 transform attribute: Key Length. 1034 1 2 3 1035 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 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 |1| Attribute Type | Attribute Value | 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 Figure 6: Data Attributes 1041 o Attribute Type (15 bits) - Unique identifier for each type of 1042 attribute (see below). 1044 o Attribute Value - Value of the attribute associated with the 1045 attribute type. 1047 Attribute Type Value 1048 ---------------------------- 1049 Key Length (in bits) 14 1051 The Key Length attribute specifies the key length in bits (MUST use 1052 network byte order) for certain transforms as follows: 1054 o The Key Length attribute MUST NOT be used with transforms that use 1055 a fixed-length key. 1057 o Some transforms specify that the Key Length attribute MUST be 1058 always included. For example ENCR_AES_CBC. 1060 Appendix A.4. Key Exchange Payload 1062 1 2 3 1063 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 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | Next Payload |C| RESERVED | Payload Length | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | Diffie-Hellman Group Num | RESERVED | 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | | 1070 ~ Key Exchange Data ~ 1071 | | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 Figure 7: Key Exchange Payload Format 1076 A Key Exchange payload is constructed by copying one's Diffie-Hellman 1077 public value into the "Key Exchange Data" portion of the payload. 1078 The length of the Diffie-Hellman public value for modular 1079 exponentiation group (MODP) groups MUST be equal to the length of the 1080 prime modulus over which the exponentiation was performed, prepending 1081 zero bits to the value if necessary. 1083 The Diffie-Hellman Group Num identifies the Diffie-Hellman group in 1084 which the Key Exchange Data was computed. This Diffie-Hellman Group 1085 Num MUST match a Diffie-Hellman group specified in a proposal in the 1086 SA payload that is sent in the same message 1088 Appendix A.5. Identification Payloads 1090 The Identification payloads, denoted IDi and IDr in this document, 1091 allow peers to assert an identity to one another. When using the 1092 ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 1093 does not require this address to match the address in the IP header 1094 of IKEv2 packets, or anything in the TSi/TSr payloads. The contents 1095 of IDi/IDr are used purely to fetch the policy and authentication 1096 data related to the other party. In minimal implementation it might 1097 be easiest to always use KEY_ID type. This allows the ID payload to 1098 be static. Using IP address has problems in environments where IP 1099 addresses are dynamically allocated. 1101 1 2 3 1102 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 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 | Next Payload |C| RESERVED | Payload Length | 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 | ID Type | RESERVED | 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 | | 1109 ~ Identification Data ~ 1110 | | 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 Figure 8: Identification Payload Format 1115 o ID Type (1 octet) - Specifies the type of Identification being 1116 used. 1118 o Identification Data (variable length) - Value, as indicated by the 1119 Identification Type. The length of the Identification Data is 1120 computed from the size in the ID payload header. 1122 The following table lists the assigned semantics for the 1123 Identification Type field. 1125 ID Type Value 1126 ------------------------------------------------------------------- 1127 ID_IPV4_ADDR 1 1128 A single four (4) octet IPv4 address. 1130 ID_FQDN 2 1131 A fully-qualified domain name string. An example of an ID_FQDN 1132 is "example.com". The string MUST NOT contain any terminators 1133 (e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII; 1134 for an "internationalized domain name", the syntax is as defined 1135 in [IDNA], for example "xn--tmonesimerkki-bfbb.example.net". 1137 ID_RFC822_ADDR 3 1138 A fully-qualified RFC 822 email address string. An example of a 1139 ID_RFC822_ADDR is "jsmith@example.com". The string MUST NOT 1140 contain any terminators. Because of [EAI], implementations would 1141 be wise to treat this field as UTF-8 encoded text, not as 1142 pure ASCII. 1144 ID_IPV6_ADDR 5 1145 A single sixteen (16) octet IPv6 address. 1147 ID_KEY_ID 11 1148 An opaque octet stream that may be used to pass vendor- 1149 specific information necessary to do certain proprietary 1150 types of identification. Minimal implementation might use 1151 this type to send out serial number or similar device 1152 specific unique static identification data for the device. 1154 Appendix A.6. Certificate Payload 1156 1 2 3 1157 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 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 | Next Payload |C| RESERVED | Payload Length | 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1161 | Cert Encoding | | 1162 +-+-+-+-+-+-+-+-+ | 1163 ~ Certificate Data ~ 1164 | | 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 Figure 9: Certificate Payload Format 1169 o Certificate Encoding (1 octet) - This field indicates the type of 1170 certificate or certificate-related information contained in the 1171 Certificate Data field. 1173 Certificate Encoding Value 1174 ---------------------------------------------------- 1175 X.509 Certificate - Signature 4 1176 Raw Public Key TBD 1177 o Certificate Data (variable length) - Actual encoding of 1178 certificate data. The type of certificate is indicated by the 1179 Certificate Encoding field. 1181 The syntax of the types above are: 1183 o "X.509 Certificate - Signature" contains a DER-encoded X.509 1184 certificate whose public key is used to validate the sender's AUTH 1185 payload. Note that with this encoding, if a chain of certificates 1186 needs to be sent, multiple CERT payloads are used, only the first 1187 of which holds the public key used to validate the sender's AUTH 1188 payload. 1190 o "Raw Public Key" contains a raw public key. In essence the 1191 Certificate Payload contains the SubjectPublicKeyInfo part of the 1192 PKIX certificate (See Section 4.1.2.7 of [RFC5280]). This is quite 1193 simple ASN.1 object which contains mostly static parts before the 1194 actual public key values. See [I-D.ietf-ipsecme-oob-pubkey] for 1195 more information. 1197 Appendix A.7. Certificate Request Payload 1199 1 2 3 1200 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 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 | Next Payload |C| RESERVED | Payload Length | 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 | Cert Encoding | | 1205 +-+-+-+-+-+-+-+-+ | 1206 ~ Certification Authority ~ 1207 | | 1208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 Figure 10: Certificate Request Payload Format 1212 o Certificate Encoding (1 octet) - Contains an encoding of the type 1213 or format of certificate requested. 1215 o Certification Authority (variable length) - Contains an encoding 1216 of an acceptable certification authority for the type of 1217 certificate requested. 1219 The Certificate Encoding field has the same values as those defined 1220 certificate payload. The Certification Authority field contains an 1221 indicator of trusted authorities for this certificate type. The 1222 Certification Authority value is a concatenated list of SHA-1 hashes 1223 of the public keys of trusted Certification Authorities (CAs). Each 1224 is encoded as the SHA-1 hash of the Subject Public Key Info element 1225 (see Section 4.1.2.7 of [RFC5280]) from each Trust Anchor 1226 certificate. The 20-octet hashes are concatenated and included with 1227 no other formatting. 1229 Appendix A.8. Authentication Payload 1230 1 2 3 1231 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 1232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 | Next Payload |C| RESERVED | Payload Length | 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1235 | Auth Method | RESERVED | 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1237 | | 1238 ~ Authentication Data ~ 1239 | | 1240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 Figure 11: Authentication Payload Format 1244 o Auth Method (1 octet) - Specifies the method of authentication 1245 used. 1247 Mechanism Value 1248 ----------------------------------------------------------------- 1249 RSA Digital Signature 1 1250 Using an RSA private key with RSASSA-PKCS1-v1_5 signature 1251 scheme specified in [PKCS1], see [RFC7296] Section 2.15 for 1252 details. 1254 Shared Key Message Integrity Code 2 1255 Computed as specified earlier using the shared key associated 1256 with the identity in the ID payload and the negotiated PRF. 1258 o Authentication Data (variable length) - see [initial-exchange]. 1260 Appendix A.9. Nonce Payload 1262 1 2 3 1263 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 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 | Next Payload |C| RESERVED | Payload Length | 1266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1267 | | 1268 ~ Nonce Data ~ 1269 | | 1270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 Figure 12: Nonce Payload Format 1274 o Nonce Data (variable length) - Contains the random data generated 1275 by the transmitting entity. 1277 The size of the Nonce Data MUST be between 16 and 256 octets, 1278 inclusive. Nonce values MUST NOT be reused. 1280 Appendix A.10. Notify Payload 1281 The Notify payload, denoted N in this document, is used to transmit 1282 informational data, such as error conditions and state transitions, 1283 to an IKE peer. A Notify payload may appear in a response message 1284 (usually specifying why a request was rejected), in an INFORMATIONAL 1285 Exchange (to report an error not in an IKE request), or in any other 1286 message to indicate sender capabilities or to modify the meaning of 1287 the request. 1289 1 2 3 1290 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 1291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1292 | Next Payload |C| RESERVED | Payload Length | 1293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1294 | Protocol ID | SPI Size | Notify Message Type | 1295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1296 | | 1297 ~ Security Parameter Index (SPI) ~ 1298 | | 1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1300 | | 1301 ~ Notification Data ~ 1302 | | 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1305 Figure 13: Notify Payload Format 1307 o Protocol ID (1 octet) - If this notification concerns an existing 1308 SA whose SPI is given in the SPI field, this field indicates the 1309 type of that SA. If the SPI field is empty, this field MUST be 1310 sent as zero and MUST be ignored on receipt. 1312 o SPI Size (1 octet) - Length in octets of the SPI as defined by the 1313 IPsec protocol ID or zero if no SPI is applicable. For a 1314 notification concerning the IKE SA, the SPI Size MUST be zero and 1315 the field must be empty. 1317 o Notify Message Type (2 octets) - Specifies the type of 1318 notification message. 1320 o SPI (variable length) - Security Parameter Index. 1322 o Notification Data (variable length) - Status or error data 1323 transmitted in addition to the Notify Message Type. Values for 1324 this field are type specific. 1326 Appendix A.10.1. Notify Message Types 1328 Notification information can be error messages specifying why an SA 1329 could not be established. It can also be status data that a process 1330 managing an SA database wishes to communicate with a peer process. 1332 Types in the range 0 - 16383 are intended for reporting errors. An 1333 implementation receiving a Notify payload with one of these types 1334 that it does not recognize in a response MUST assume that the 1335 corresponding request has failed entirely. Unrecognized error types 1336 in a request and status types in a request or response MUST be 1337 ignored, and they should be logged. 1339 Notify payloads with status types MAY be added to any message and 1340 MUST be ignored if not recognized. They are intended to indicate 1341 capabilities, and as part of SA negotiation, are used to negotiate 1342 non-cryptographic parameters. 1344 NOTIFY messages: error types Value 1345 ------------------------------------------------------------------- 1346 UNSUPPORTED_CRITICAL_PAYLOAD 1 1347 Indicates that the one-octet payload type included in the 1348 Notification Data field is unknown. 1350 INVALID_SYNTAX 7 1351 Indicates the IKE message that was received was invalid because 1352 some type, length, or value was out of range or because the 1353 request was rejected for policy reasons. To avoid a DoS 1354 attack using forged messages, this status may only be 1355 returned for and in an encrypted packet if the Message ID and 1356 cryptographic checksum were valid. To avoid leaking information 1357 to someone probing a node, this status MUST be sent in response 1358 to any error not covered by one of the other status types. 1359 To aid debugging, more detailed error information should be 1360 written to a console or log. 1362 NO_PROPOSAL_CHOSEN 14 1363 None of the proposed crypto suites was acceptable. This can be 1364 sent in any case where the offered proposals are not acceptable 1365 for the responder. 1367 NO_ADDITIONAL_SAS 35 1368 Specifies that the node is unwilling to accept any more Child 1369 SAs. 1371 NOTIFY messages: status types Value 1372 ------------------------------------------------------------------- 1373 INITIAL_CONTACT 16384 1374 Asserts that this IKE SA is the only IKE SA currently active 1375 between the authenticated identities. 1377 Appendix A.11. Traffic Selector Payload 1379 Traffic Selector (TS) payloads allow endpoints to communicate some of 1380 the information from their SPD to their peers. TS payloads specify 1381 the selection criteria for packets that will be forwarded over the 1382 newly set up SA. 1384 1 2 3 1385 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 1386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1387 | Next Payload |C| RESERVED | Payload Length | 1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 | Number of TSs | RESERVED | 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1391 | | 1392 ~ ~ 1393 | | 1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 Figure 14: Traffic Selectors Payload Format 1398 o Number of TSs (1 octet) - Number of Traffic Selectors being 1399 provided. 1401 o Traffic Selectors (variable length) - One or more individual 1402 Traffic Selectors. 1404 The length of the Traffic Selector payload includes the TS header and 1405 all the Traffic Selectors. 1407 There is no requirement that TSi and TSr contain the same number of 1408 individual Traffic Selectors. Thus, they are interpreted as follows: 1409 a packet matches a given TSi/TSr if it matches at least one of the 1410 individual selectors in TSi, and at least one of the individual 1411 selectors in TSr. 1413 Two TS payloads appear in each of the messages in the exchange that 1414 creates a Child SA pair. Each TS payload contains one or more 1415 Traffic Selectors. Each Traffic Selector consists of an address 1416 range (IPv4 or IPv6), a port range, and an IP protocol ID. 1418 The first of the two TS payloads is known as TSi (Traffic Selector- 1419 initiator). The second is known as TSr (Traffic Selector-responder). 1420 TSi specifies the source address of traffic forwarded from (or the 1421 destination address of traffic forwarded to) the initiator of the 1422 Child SA pair. TSr specifies the destination address of the traffic 1423 forwarded to (or the source address of the traffic forwarded from) 1424 the responder of the Child SA pair. 1426 IKEv2 allows the responder to choose a subset of the traffic proposed 1427 by the initiator. 1429 When the responder chooses a subset of the traffic proposed by the 1430 initiator, it narrows the Traffic Selectors to some subset of the 1431 initiator's proposal (provided the set does not become the null set). 1432 If the type of Traffic Selector proposed is unknown, the responder 1433 ignores that Traffic Selector, so that the unknown type is not 1434 returned in the narrowed set. 1436 To enable the responder to choose the appropriate range, if the 1437 initiator has requested the SA due to a data packet, the initiator 1438 SHOULD include as the first Traffic Selector in each of TSi and TSr a 1439 very specific Traffic Selector including the addresses in the packet 1440 triggering the request. If the initiator creates the Child SA pair 1441 not in response to an arriving packet, but rather, say, upon startup, 1442 then there may be no specific addresses the initiator prefers for the 1443 initial tunnel over any other. In that case, the first values in TSi 1444 and TSr can be ranges rather than specific values. 1446 As minimal implementations might only support one SA, the traffic 1447 selectors will usually be from initiator's IP address to responders 1448 IP address (i.e. no port or protocol selectors and only one range). 1450 Appendix A.11.1. Traffic Selector 1452 1 2 3 1453 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 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 | TS Type |IP Protocol ID | Selector Length | 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1457 | Start Port | End Port | 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 | | 1460 ~ Starting Address ~ 1461 | | 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 | | 1464 ~ Ending Address ~ 1465 | | 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1468 Figure 15: Traffic Selector 1470 o TS Type (one octet) - Specifies the type of Traffic Selector. 1472 o IP protocol ID (1 octet) - Value specifying an associated IP 1473 protocol ID (such as UDP, TCP, and ICMP). A value of zero means 1474 that the protocol ID is not relevant to this Traffic Selector -- 1475 the SA can carry all protocols. 1477 o Selector Length - Specifies the length of this Traffic Selector 1478 substructure including the header. 1480 o Start Port (2 octets, unsigned integer) - Value specifying the 1481 smallest port number allowed by this Traffic Selector. For 1482 protocols for which port is undefined (including protocol 0), or 1483 if all ports are allowed, this field MUST be zero. 1485 o End Port (2 octets, unsigned integer) - Value specifying the 1486 largest port number allowed by this Traffic Selector. For 1487 protocols for which port is undefined (including protocol 0), or 1488 if all ports are allowed, this field MUST be 65535. 1490 o Starting Address - The smallest address included in this Traffic 1491 Selector (length determined by TS Type). 1493 o Ending Address - The largest address included in this Traffic 1494 Selector (length determined by TS Type). 1496 The following table lists values for the Traffic Selector Type field 1497 and the corresponding Address Selector Data. 1499 TS Type Value 1500 ------------------------------------------------------------------- 1501 TS_IPV4_ADDR_RANGE 7 1503 A range of IPv4 addresses, represented by two four-octet 1504 values. The first value is the beginning IPv4 address 1505 (inclusive) and the second value is the ending IPv4 address 1506 (inclusive). All addresses falling between the two specified 1507 addresses are considered to be within the list. 1509 TS_IPV6_ADDR_RANGE 8 1511 A range of IPv6 addresses, represented by two sixteen-octet 1512 values. The first value is the beginning IPv6 address 1513 (inclusive) and the second value is the ending IPv6 address 1514 (inclusive). All addresses falling between the two specified 1515 addresses are considered to be within the list. 1517 Appendix A.12. Encrypted Payload 1519 The Encrypted payload, denoted SK{...} in this document, contains 1520 other payloads in encrypted form. 1522 1 2 3 1523 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 1524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 | Next Payload |C| RESERVED | Payload Length | 1526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 | Initialization Vector | 1528 | (length is block size for encryption algorithm) | 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1530 ~ Encrypted IKE Payloads ~ 1531 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1532 | | Padding (0-255 octets) | 1533 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 1534 | | Pad Length | 1535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 ~ Integrity Checksum Data ~ 1537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 Figure 16: Encrypted Payload Format 1541 o Next Payload - The payload type of the first embedded payload. 1542 Note that this is an exception in the standard header format, 1543 since the Encrypted payload is the last payload in the message and 1544 therefore the Next Payload field would normally be zero. But 1545 because the content of this payload is embedded payloads and there 1546 was no natural place to put the type of the first one, that type 1547 is placed here. 1549 o Payload Length - Includes the lengths of the header, 1550 initialization vector (IV), Encrypted IKE payloads, Padding, Pad 1551 Length, and Integrity Checksum Data. 1553 o Initialization Vector - For CBC mode ciphers, the length of the 1554 initialization vector (IV) is equal to the block length of the 1555 underlying encryption algorithm. Senders MUST select a new 1556 unpredictable IV for every message; recipients MUST accept any 1557 value. The reader is encouraged to consult [MODES] for advice on 1558 IV generation. In particular, using the final ciphertext block of 1559 the previous message is not considered unpredictable. For modes 1560 other than CBC, the IV format and processing is specified in the 1561 document specifying the encryption algorithm and mode. 1563 o IKE payloads are as specified earlier in this section. This field 1564 is encrypted with the negotiated cipher. 1566 o Padding MAY contain any value chosen by the sender, and MUST have 1567 a length that makes the combination of the payloads, the Padding, 1568 and the Pad Length to be a multiple of the encryption block size. 1569 This field is encrypted with the negotiated cipher. 1571 o Pad Length is the length of the Padding field. The sender SHOULD 1572 set the Pad Length to the minimum value that makes the combination 1573 of the payloads, the Padding, and the Pad Length a multiple of the 1574 block size, but the recipient MUST accept any length that results 1575 in proper alignment. This field is encrypted with the negotiated 1576 cipher. 1578 o Integrity Checksum Data is the cryptographic checksum of the 1579 entire message starting with the Fixed IKE header through the Pad 1580 Length. The checksum MUST be computed over the encrypted message. 1581 Its length is determined by the integrity algorithm negotiated. 1583 Appendix B. Useful Optional Features 1585 There are some optional features of IKEv2, which might be useful for 1586 minimal implementations in some scenarios. Such features include Raw 1587 public keys authentication, and sending IKE SA delete notification. 1589 Appendix B.1. IKE SA Delete Notification 1590 In some scenarios the minimal implementation device creates IKE SA, 1591 sends one or few packets, perhaps gets some packets back, and then 1592 device goes back to sleep forgetting the IKE SA. In such scenarios 1593 it would be nice for the minimal implementation to send the IKE SA 1594 delete notification to tell the other end that the IKE SA is going 1595 away, so it can free the resources. 1597 Deleting the IKE SA can be done using by sending one packet with 1598 fixed Message ID, and with only one payload inside the encrypted 1599 payload. The other end will send back an empty response: 1601 Initiator Responder 1602 ------------------------------------------------------------------- 1603 HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL, 1604 Flags: Initiator, Message ID=2), 1605 SK {D} --> 1607 <-- HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL, 1608 Flags: Response, Message ID=2), 1609 SK {} 1611 The delete payload format is: 1613 1 2 3 1614 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 1615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1616 | Next Payload |C| RESERVED | Payload Length | 1617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1618 | Protocol ID | SPI Size | Num of SPIs | 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1620 | | 1621 ~ Security Parameter Index(es) (SPI) ~ 1622 | | 1623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1625 Figure 17: Delete Payload Format 1627 o Protocol ID (1 octet) - Must be 1 for an IKE SA. 1629 o SPI Size (1 octet) - Length in octets of the SPI as defined by the 1630 protocol ID. It MUST be zero for IKE (SPI is in message header). 1632 o Num of SPIs (2 octets, unsigned integer) - The number of SPIs 1633 contained in the Delete payload. This MUST be zero for IKE. 1635 o Security Parameter Index(es) (variable length) - Identifies the 1636 specific Security Association(s) to delete. The length of this 1637 field is determined by the SPI Size and Num of SPIs fields. This 1638 field is empty for the IKE SA delete. 1640 Appendix B.2. Raw Public Keys 1641 In some scenarios the shared secret authentication is not safe 1642 enough, as anybody who knows the secret can impersonate himself of 1643 being the server. If the shared secret is printed on the side of the 1644 device, then anybody who gets physical access to the device can read 1645 it. In such environments public key authentication allows stronger 1646 authentication with minimal operational overhead. Certificate 1647 support is quite complex, and minimal implementations do not usually 1648 have need for them. Using Raw Public Keys is much simpler, and it 1649 allows similar scalability than certificates. The fingerprint of the 1650 Raw Public Key can still be distributed by for example printing it on 1651 the side of the device allowing similar setup than using shared 1652 secret. 1654 Raw Public Keys can also be used in leap of faith or baby duck style 1655 initial setup, where the device imprints itself to the first device 1656 it sees when it first time boots up. After that initial connection 1657 it stores the fingerprint of the Raw Public Key of the server to its 1658 own configuration and verifies that it never changes (unless reset to 1659 factory setting or similar command is issued). 1661 This changes the initial IKE_AUTH payloads as follows: 1663 Initiator Responder 1664 ------------------------------------------------------------------- 1665 HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, 1666 Flags: Initiator, Message ID=1), 1667 SK {IDi, CERT, AUTH, SAi2, TSi, TSr, 1668 N(INITIAL_CONTACT)} --> 1670 <-- HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags: 1671 Response, Message ID=1), 1672 SK {IDr, CERT, AUTH, SAr2, TSi, TSr} 1674 The CERT payloads contains the Raw Public Keys used the sign the hash 1675 of the InitiatorSignedOctects/ResponderSignedOctects when generating 1676 AUTH payload. Minimal implementations should use SHA-1 as the hash 1677 function as that is the SHOULD support algorithm specified in the 1678 RFC7296, so it is the most likely one that is supported by all 1679 devices. 1681 Note, that the RFC7296 already obsoleted the old Raw RSA Key method, 1682 and More Raw Public Keys for IKEv2 ([I-D.ietf-ipsecme-oob-pubkey]) 1683 adds new format to allow any types of Raw Public Keys to IKEv2. This 1684 document only specifies how to use the new format. 1686 Author's Address 1688 Tero Kivinen 1689 INSIDE Secure 1690 Eerikinkatu 28 1691 HELSINKI, FI-00180 1692 FI 1694 Email: kivinen@iki.fi