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