idnits 2.17.1 draft-ietf-lwig-ikev2-minimal-05.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 (November 23, 2015) is 3039 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CERTREQ' is mentioned on line 283, but not defined == Missing Reference: 'IPSECARCH' is mentioned on line 537, but not defined == Missing Reference: 'IDNA' is mentioned on line 1193, but not defined == Missing Reference: 'EAI' is mentioned on line 1198, but not defined == Missing Reference: 'PKCS1' is mentioned on line 1311, 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 November 23, 2015 5 Expires: May 26, 2016 7 Minimal IKEv2 Initiator Implementation 8 draft-ietf-lwig-ikev2-minimal-05.txt 10 Abstract 12 This document describes a minimal initiator version of the Internet 13 Key Exchange version 2 (IKEv2) protocol for constrained nodes. IKEv2 14 is a component of IPsec used for performing mutual authentication and 15 establishing and maintaining Security Associations (SAs). IKEv2 16 includes several optional features, which are not needed in minimal 17 implementations. This document describes what is required from the 18 minimal implementation, and also describes various optimizations 19 which can be done. The protocol described here is interoperable with 20 a full IKEv2 implementation using shared secret authentication (IKEv2 21 does not require the use of certificate authentication). This 22 minimal initiator implementation can only talk to a full IKEv2 23 implementation acting as responder, thus two minimal initiator 24 implementations cannot talk to each other. 26 This document does not update or modify RFC 7296, but provides more 27 compact description of the minimal version of the protocol. If this 28 document and RFC 7296 conflicts then RFC 7296 is the authoritative 29 description. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on May 26, 2016. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 This document may contain material from IETF Documents or IETF 64 Contributions published or made publicly available before November 65 10, 2008. The person(s) controlling the copyright in some of this 66 material may not have granted the IETF Trust the right to allow 67 modifications of such material outside the IETF Standards Process. 68 Without obtaining an adequate license from the person(s) controlling 69 the copyright in such materials, this document may not be modified 70 outside the IETF Standards Process, and derivative works of it may 71 not be created outside the IETF Standards Process, except to format 72 it for publication as an RFC or to translate it into languages other 73 than English. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4 79 2. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . 5 80 2.1. Initial Exchange . . . . . . . . . . . . . . . . . . . . 5 81 2.2. Other Exchanges . . . . . . . . . . . . . . . . . . . . . 11 82 2.3. Generating Keying Material . . . . . . . . . . . . . . . 11 83 3. Conformance Requirements . . . . . . . . . . . . . . . . . . 12 84 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 90 8.2. Informative References . . . . . . . . . . . . . . . . . 14 91 Appendix A. Header and Payload Formats . . . . . . . . . . . . . 14 92 A.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . 25 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 The Internet Protocol Suite is increasingly used on small devices 118 with severe constraints on power, memory, and processing resources. 119 This document describes a minimal IKEv2 implementation designed for 120 use on such constrained nodes that is interoperable with Internet Key 121 Exchange Protocol Version 2 (IKEv2) [RFC7296]. 123 A minimal IKEv2 implementation only supports the initiator end of the 124 protocol. It only supports the initial IKE_SA_INIT and IKE_AUTH 125 exchanges and does not initiate any other exchanges. It also replies 126 with empty (or error) message to all incoming requests. 128 This means that most of the optional features of IKEv2 are left out: 129 NAT Traversal, IKE SA rekey, Child SA rekey, Multiple Child SAs, 130 Deleting Child / IKE SAs, Configuration payloads, EAP authentication, 131 COOKIEs etc. 133 Some optimizations can be done because of the limited set of 134 supported features, and this text should not be considered for 135 generic IKEv2 implementations (for example Message IDs can be done as 136 specified because minimal implementation is only sending out 137 IKE_SA_INIT and IKE_AUTH request, and do not send any other request). 139 This document is intended to be stand-alone, meaning everything 140 needed to implement IKEv2 is copied here except the description of 141 the cryptographic algorithms. The IKEv2 specification has lots of 142 background information and rationale which has been omitted from this 143 document. 145 Numerous additional numeric values from IANA registries have been 146 omitted from this document, only those which are of interest for a 147 minimal implementation are listed in this document. 149 The main body of this document describes how to use the shared secret 150 authentication in IKEv2, as it is easiest to implement. In some 151 cases that is not enough and Appendix B.2 describes how to use Raw 152 Public keys instead of shared secret authentication. 154 For more information check the full IKEv2 specification in RFC 7296 155 [RFC7296] and [IKEV2IANA]. 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in [RFC2119]. The term 160 "Constrained Node" is defined in the Terminology for Constrained-Node 161 Networks document [RFC7228]. 163 1.1. Use Cases 165 One use case for this kind of minimal implementation is in small 166 devices doing machine-to-machine communication. In such environments 167 the node initiating connections can be very small and the other end 168 of the communication channel is some kind of larger device. 170 An example of the small initiating node could be a remote garage door 171 opener device, i.e., a device having buttons which open and close a 172 garage door, and which connects to the home area network server over 173 wireless link. 175 Another example of such a device is some kind of sensor device, for 176 example a room temperature sensor, which sends periodic temperature 177 data to some centralized node. 179 Those devices are usually sleeping for a long time, and only wake up 180 because of user interaction or periodically. The data transfer is 181 always initiated from that sleeping node when they wake up and after 182 they send packets there might be ACKs or other packets coming back 183 before they go back to sleep. If some data needs to be transferred 184 from a server node to the small device, it can be implemented by 185 polling, i.e. the small node periodically polls for the server to see 186 if it for example has some configuration changes or similar. While 187 the device is sleeping it will not maintain the IKEv2 SA. That is, 188 it will always create the IKEv2 SA again when it wakes up. This 189 means there is no need to do liveness checks for the server, as after 190 the device wakes up again the minimal implementation will start from 191 the beginning again. 193 2. Exchanges 195 2.1. Initial Exchange 197 All IKEv2 communications consist of pairs of messages: a request and 198 a response. The pair is called an "exchange", and is sometimes 199 called a "request/response pair". Every request requires a response. 201 For every pair of IKEv2 messages, the initiator is responsible for 202 retransmission in the event of a timeout. The responder MUST never 203 retransmit a response unless it receives a retransmission of the 204 request. 206 IKEv2 is a reliable protocol: the initiator MUST retransmit a request 207 until it either receives a corresponding response or deems the IKE SA 208 to have failed. A retransmission from the initiator MUST be bitwise 209 identical to the original request. Retransmission times MUST 210 increase exponentially. 212 IKEv2 is run over UDP port 500. All IKEv2 implementations MUST be 213 able to send, receive, and process IKEv2 messages that are up to 1280 214 octets long. An implementation MUST accept incoming requests even if 215 the source port is not 500, and MUST respond to the address and port 216 from which the request was received. 218 The minimal implementation of IKEv2 only uses the first two 219 exchanges, called IKE_SA_INIT and IKE_AUTH. These are used to create 220 the IKE SA and the first Child SA. In addition to those messages, a 221 minimal IKEv2 implementation needs to understand the CREATE_CHILD_SA 222 request enough to generate an CREATE_CHILD_SA response containing the 223 NO_ADDITIONAL_SAS error notify. It needs to understand the 224 INFORMATIONAL request enough to generate an empty INFORMATIONAL 225 response to it. There is no requirement to be able to respond to any 226 other requests. 228 All messages following the IKE_SA_INIT exchange are cryptographically 229 protected using the cryptographic algorithms and keys negotiated in 230 the IKE_SA_INIT exchange. 232 Every IKEv2 message contains a Message ID as part of its fixed 233 header. This Message ID is used to match up requests and responses, 234 and to identify retransmissions of messages. 236 Minimal implementations only need to support the role of initiator, 237 so so it typically only sends an IKE_SA_INIT request which, when 238 answered, is followed by an IKE_AUTH. As those messages have fixed 239 Message IDs (0 and 1) it does not need to keep track of its own 240 Message IDs for outgoing requests after that. 242 Minimal implementations can also optimize Message ID handling of the 243 incoming requests, as they do not need to protect incoming requests 244 against replays. This is possible because minimal implementations 245 will only return error or empty notification replies to incoming 246 requests. This means that any of those incoming requests do not have 247 any effect on the minimal implementation, thus processing them again 248 does not cause any harm. Because of this a minimal implementation 249 can always answer to request coming in, with the same Message ID than 250 what the request had and then forget the request/response pair 251 immediately. This means there is no need to keep track of Message 252 IDs of the incoming requests. 254 In the following descriptions, the payloads contained in the message 255 are indicated by the names listed below. 257 Notation Payload 258 ----------------------------------------- 259 AUTH Authentication 260 CERTREQ Certificate Request 261 D Delete 262 HDR IKE header (not a payload) 263 IDi Identification - Initiator 264 IDr Identification - Responder 265 KE Key Exchange 266 Ni, Nr Nonce 267 N Notify 268 SA Security Association 269 SK Encrypted and Authenticated 270 TSi Traffic Selector - Initiator 271 TSr Traffic Selector - Responder 273 The initial exchanges are as follows: 275 Initiator Responder 276 ------------------------------------------------------------------- 277 HDR(SPIi=xxx, SPIr=0, IKE_SA_INIT, 278 Flags: Initiator, Message ID=0), 279 SAi1, KEi, Ni --> 281 <-- HDR(SPIi=xxx, SPIr=yyy, IKE_SA_INIT, 282 Flags: Response, Message ID=0), 283 SAr1, KEr, Nr, [CERTREQ] 285 HDR contains the Security Parameter Indexes (SPIs), version numbers, 286 and flags of various sorts. Each endpoint chooses one of the two 287 SPIs and MUST choose them so as to be unique identifiers of an IKE 288 SA. An SPI value of zero is special: it indicates that the remote 289 SPI value is not yet known by the sender. 291 Incoming IKEv2 packets are mapped to an IKE SA using only the 292 packet's SPI, not using (for example) the source IP address of the 293 packet. 295 The SAi1 payload states the cryptographic algorithms the initiator 296 supports for the IKE SA. The KEi and KEr payload contain Diffie- 297 Hellman values and Ni and Nr are the nonces. The SAr1 contains the 298 chosen cryptographic suite from initiator's offered choices. A 299 minimal implementation using shared secrets will ignore the CERTREQ 300 payload. 302 Minimal implementation will most likely support exactly one set of 303 cryptographic algorithms, meaning the SAi1 payload will be static. 304 It needs to check that the SAr1 received matches the proposal it 305 sent. 307 At this point in the negotiation, each party can generate SKEYSEED, 308 from which all keys are derived for that IKE SA. 310 SKEYSEED = prf(Ni | Nr, g^ir) 312 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } 313 = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) 315 prf+ (K,S) = T1 | T2 | T3 | T4 | ... 317 where: 318 T1 = prf (K, S | 0x01) 319 T2 = prf (K, T1 | S | 0x02) 320 T3 = prf (K, T2 | S | 0x03) 321 T4 = prf (K, T3 | S | 0x04) 322 ... 324 (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, 325 SK_pi, and SK_pr are taken in order from the generated bits of the 326 prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman 327 exchange. g^ir is represented as a string of octets in big endian 328 order padded with zeros if necessary to make it the length of the 329 modulus. Ni and Nr are the nonces, stripped of any headers. 331 The SK_d is used for deriving new keys for the Child SAs. The SK_ai 332 and SK_ar are used as a key to the integrity protection algorithm for 333 authenticating the component messages of subsequent exchanges. The 334 SK_ei and SK_er are used for encrypting (and of course decrypting) 335 all subsequent exchanges. The SK_pi and SK_pr are used when 336 generating an AUTH payload. The lengths of SK_d, SK_pi, and SK_pr 337 MUST be the preferred key length of the PRF agreed upon. 339 A separate SK_e and SK_a is computed for each direction. The keys 340 used to protect messages from the original initiator are SK_ai and 341 SK_ei. The keys used to protect messages in the other direction are 342 SK_ar and SK_er. The notation SK { ... } indicates that these 343 payloads are encrypted and integrity protected using that direction's 344 SK_e and SK_a. 346 Initiator Responder 347 ------------------------------------------------------------------- 348 HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, 349 Flags: Initiator, Message ID=1), 350 SK {IDi, AUTH, SAi2, TSi, TSr, 351 N(INITIAL_CONTACT)} --> 353 <-- HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags: 354 Response, Message ID=1), 355 SK {IDr, AUTH, SAr2, TSi, TSr} 357 The initiator asserts its identity with the IDi payload, proves 358 knowledge of the secret corresponding to IDi and integrity protects 359 the contents of the first message using the AUTH payload. The 360 responder asserts its identity with the IDr payload, authenticates 361 its identity and protects the integrity of the second message with 362 the AUTH payload. 364 As minimal implementation usually has only one host where it 365 connects, and that means it has only one shared secret. This means 366 it does not need to care about IDr payload that much. If the other 367 end sends AUTH payload which initiator can verify using the shared 368 secret it has, then it knows the other end is the peer it was 369 configured to talk to. 371 In the IKE_AUTH request, the initiator sends the SA offer(s) in the 372 SAi2 payload, and the proposed Traffic Selectors for the Child SA in 373 the TSi and TSr payloads. The responder replies with the accepted 374 offer in an SAr2 payload, and with the selected Traffic Selectors. 375 The selected Traffic Selectors may be a subset of what the initiator 376 proposed. 378 In the minimal implementation both SA payloads and TS payloads are 379 going to be mostly static. The SA payload will have the SPI value 380 used in the Encapsulating Security Payload (ESP), but the algorithms 381 are most likely going to be the one and only supported set. The TS 382 payloads on the initiator end will most likely say from any to any, 383 i.e. full wildcard ranges, or from the local IP to the remote IP. In 384 the wildcard case the responder quite often narrows the range down to 385 the one IP address pair. Using a single IP address pair as the 386 Traffic Selectors when sending the IKE_AUTH request will simplify 387 processing as the responder will either accept the IP address pair or 388 return an error. If wildcard ranges are used, there is a possibility 389 that the responder will narrow the Traffic Selector range to range 390 that is not acceptable by the initiator. 392 The IKE_AUTH (and IKE_SA_INIT) responses may contain multiple status 393 notification payloads which can be ignored by minimal 394 implementations. There can also be Vendor ID, Certificate, 395 Certificate Request or Configuration payloads, but any payload 396 unknown to minimal implementations can simply be skipped over 397 (response messages cannot have critical unsupported payloads). 399 The exchange above includes N(INITIAL_CONTACT) notification in the 400 request as that is quite commonly sent by a minimal implementation. 401 It indicates to the other end that the initiator does not have any 402 other IKE SAs between it and the responder, and if there is any left 403 from previous runs those can be deleted by the responder. As minimal 404 implementations delete IKE SAs without sending IKE SA delete 405 requests, this will help the responder to clean up leftover state. 407 When using shared secret authentication, the peers are authenticated 408 by having each calculating a MAC over a block of data: 410 For the initiator: 411 AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), 412 ) 413 For the responder: 414 AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), 415 ) 417 The string "Key Pad for IKEv2" is 17 ASCII characters without null 418 termination. The implementation can precalculate the inner prf and 419 only store the output of it. This is possible because a minimal 420 IKEv2 implementation usually only supports one PRF. 422 In following 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 signs the first message (IKE_SA_INIT request), starting 428 with the first octet of the first SPI in the header and ending with 429 the last octet of the last payload in that first message. Appended 430 to this (for purposes of computing the signature) are the responder's 431 nonce Nr, and the value prf(SK_pi, IDi'). 433 For the responder, the octets to be signed start with the first octet 434 of the first SPI in the header of the second message (IKE_SA_INIT 435 response) and end with the last octet of the last payload in that 436 second message. Appended to this are the initiator's nonce Ni, and 437 the value prf(SK_pr, IDr'). 439 The initiator's signed octets can be described as: 441 InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI 442 RealIKEHDR = SPIi | SPIr | . . . | Length 443 RealMessage1 = RealIKEHDR | RestOfMessage1 444 NonceRPayload = PayloadHeader | NonceRData 445 InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload 446 RestOfInitIDPayload = IDType | RESERVED | InitIDData 447 MACedIDForI = prf(SK_pi, RestOfInitIDPayload) 449 The responder's signed octets can be described as: 451 ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR 452 RealIKEHDR = SPIi | SPIr | . . . | Length 453 RealMessage2 = RealIKEHDR | RestOfMessage2 454 NonceIPayload = PayloadHeader | NonceIData 455 ResponderIDPayload = PayloadHeader | RestOfRespIDPayload 456 RestOfRespIDPayload = IDType | RESERVED | RespIDData 457 MACedIDForR = prf(SK_pr, RestOfRespIDPayload) 459 Note that all of the payloads inside the RestOfMessageX are included 460 under the signature, including any payload types not listed in this 461 document. 463 The initiator might also get an unauthenticated response back having 464 a notification payload with an error code inside. As that error code 465 will be unauthenticated and may be faked, there is no need to do 466 anything for those. A minimal implementation can simply ignore those 467 errors, and retransmit its request until it times out and if that 468 happens then the IKE SA (and Child SA) creation failed. 470 The responder might also reply with an IKE_AUTH response packet which 471 does not contain the payloads needed to set up a Child SA (SAr2, TSi 472 and TSr), but instead contain AUTH payload and an error. Minimal 473 implementation that do not support the CREATE_CHILD_SA exchange 474 cannot recover from this scenario. It can delete the IKE SA and 475 start over from the beginning (which might fail again if this is a 476 configuration error, or it might succeed if this was temporal 477 failure). 479 2.2. Other Exchanges 481 Minimal implementations MUST be able to reply to INFORMATIONAL 482 requests by sending back an empty INFORMATIONAL response: 484 Minimal implementation Other end 485 ------------------------------------------------------------------- 486 <-- HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL, 487 Flags: none, Message ID=m), 488 SK {...} 490 HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL, 491 Flags: Initiator | Response, 492 Message ID=m), 493 SK {} --> 495 Minimal implementations MUST be able to reply to incoming 496 CREATE_CHILD_SA requests. A typical implementation will reject the 497 CREATE_CHILD_SA exchanges by sending a NO_ADDITIONAL_SAS error notify 498 back: 500 Minimal implementation Other end 501 ------------------------------------------------------------------- 502 <-- HDR(SPIi=xxx, SPIy=yyy, CREATE_CHILD_SA, 503 Flags: none, Message ID=m), 504 SK {...} 506 HDR(SPIi=xxx, SPIr=yyy, CREATE_CHILD_SA, 507 Flags: Initiator | Response, Message ID=m), 508 SK {N(NO_ADDITIONAL_SAS)} --> 510 Note that INFORMATIONAL and CREATE_CHILD_SA requests might contain 511 unsupported critical payloads, in which case a compliant 512 implementation MUST ignore the request, and send a response message 513 back having the UNSUPPORTED_CRITICAL_PAYLOAD notification. That 514 notification payload data contains a one-octet payload type of the 515 unsupported critical payload. 517 2.3. Generating Keying Material 519 The keying material for the Child SA created by the IKE_AUTH exchange 520 is generated as follows: 522 KEYMAT = prf+(SK_d, Ni | Nr) 524 Where Ni and Nr are the nonces from the IKE_SA_INIT exchange. 526 A single CHILD_SA negotiation may result in multiple Security 527 Associations. ESP and AH SAs exist in pairs (one in each direction), 528 so two SAs are created in a single Child SA negotiation for them. 529 The keying material for each Child SA MUST be taken from the expanded 530 KEYMAT using the following rules: 532 o All keys for SAs carrying data from the initiator to the responder 533 are taken before SAs going from the responder to the initiator. 535 o If an IPsec protocol requires multiple keys, the order in which 536 they are taken from the SA's keying material needs to be described 537 in the protocol's specification. For ESP and AH, [IPSECARCH] 538 defines the order, namely: the encryption key (if any) MUST be 539 taken from the first bits and the integrity key (if any) MUST be 540 taken from the remaining bits. 542 Each cryptographic algorithm takes a fixed number of bits of keying 543 material specified as part of the algorithm, or negotiated in SA 544 payloads. 546 3. Conformance Requirements 548 For an implementation to be called conforming to RFC 7296 549 specification, it MUST be possible to configure it to accept the 550 following: 552 o Public Key Infrastructure using X.509 (PKIX) Certificates 553 containing and signed by RSA keys of size 1024 or 2048 bits, where 554 the ID passed is any of ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR, or 555 ID_DER_ASN1_DN. 557 o Shared key authentication where the ID passed is any of ID_KEY_ID, 558 ID_FQDN, or ID_RFC822_ADDR. 560 o Authentication where the responder is authenticated using PKIX 561 Certificates and the initiator is authenticated using shared key 562 authentication. 564 This document only supports the second bullet, it does not support 565 PKIX certificates at all. As full RFC 7296 responders must also 566 support that shared key authentication, this allows a minimal 567 implementation to be able to interoperate with all RFC 7296 compliant 568 implementations. 570 PKIX certificates are left out from the minimal implementation as 571 those would add quite a lot of complexity to the implementation. The 572 actual code changes needed in the IKEv2 protocol are small, but the 573 certificate validation code would be more complex than the whole 574 minimal IKEv2 implementation itself. If public key based 575 authentication is needed for scalability reasons, then raw public 576 keys would probably be the best compromise (see Appendix B.2). 578 4. Implementation Status 580 This document describes a minimal implementation written by the 581 author of this document. The minimal implementation supported the 582 base IKE_SA_INIT and IKE_AUTH exchanges, and successfully 583 interoperated with a full IKEv2 server. This minimal implementation 584 was presented in the Interconnecting Smart Objects with Internet 585 Workshop in Prague March 2011 ([Kiv11]). This implementation was 586 written as proof of concept in perl. 588 There was another proof of concept implementation written in python, 589 which also interoperated with a full IKEv2 server. 591 Both implementations were written just for demonstration purposes, 592 and included fixed configuration built in to the code, and both also 593 implemented ESP, ICMP and IP layers to the level that was needed to 594 send and receive one ICMP echo packet. Both implementations were 595 about 1000 lines of code excluding cryptographic libraries but 596 including ESP, ICMP and IP layers. 598 5. Security Considerations 600 As this implements same protocol as RFC 7296 this means all security 601 considerations from it also apply to this document. 603 6. IANA Considerations 605 There is no new IANA considerations in this document. 607 7. Acknowledgements 609 Most of the content of this document is copied from the RFC 7296. 611 8. References 613 8.1. Normative References 615 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 616 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 617 RFC2119, March 1997, 618 . 620 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 621 Kivinen, "Internet Key Exchange Protocol Version 2 622 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 623 2014, . 625 8.2. Informative References 627 [I-D.kivinen-ipsecme-oob-pubkey] 628 Kivinen, T., Wouters, P., and H. Tschofenig, "Generic Raw 629 Public Key Support for IKEv2", draft-kivinen-ipsecme-oob- 630 pubkey-14 (work in progress), October 2015. 632 [IKEV2IANA] 633 "Internet Key Exchange Version 2 (IKEv2) Parameters", 634 . 636 [Kiv11] Kivinen, T., "IKEv2 and Smart Objects", March 2011, 637 . 640 [MODES] National Institute of Standards and Technology, U.S. 641 Department of Commerce, "Recommendation for Block Cipher 642 Modes of Operation", SP 800-38A, 2001. 644 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 645 Housley, R., and W. Polk, "Internet X.509 Public Key 646 Infrastructure Certificate and Certificate Revocation List 647 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 648 . 650 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 651 Constrained-Node Networks", RFC 7228, DOI 10.17487/ 652 RFC7228, May 2014, 653 . 655 [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication 656 Method in the Internet Key Exchange Protocol Version 2 657 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, 658 . 660 Appendix A. Header and Payload Formats 662 This appendix describes actual packet payload formats. This is 663 required to make the document self contained. The descriptions are 664 mostly copied from the RFC7296 and more information can be found from 665 there. 667 Various payload contains RESERVED fields and those MUST be sent as 668 zero and MUST be ignored on receipt. 670 All multi-octet fields representing integers are laid out in big 671 endian order (also known as "most significant byte first", or 672 "network byte order"). 674 A.1. The IKE Header 676 Each IKEv2 message begins with the IKE header, denoted HDR in this 677 document. Following the header are one or more IKE payloads each 678 identified by a "Next Payload" field in the preceding payload. 679 Payloads are identified in the order in which they appear in an IKE 680 message by looking in the "Next Payload" field in the IKE header, and 681 subsequently according to the "Next Payload" field in the IKE payload 682 itself until a "Next Payload" field of zero indicates that no 683 payloads follow. If a payload of type "Encrypted" is found, that 684 payload is decrypted and its contents parsed as additional payloads. 685 An Encrypted payload MUST be the last payload in a packet and an 686 Encrypted payload MUST NOT contain another Encrypted payload. 688 The format of the IKE header is shown in Figure 1. 690 1 2 3 691 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 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | IKE SA Initiator's SPI | 694 | | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | IKE SA Responder's SPI | 697 | | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Next Payload | MjVer | MnVer | Exchange Type | Flags | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | Message ID | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Length | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 Figure 1: IKE Header Format 708 o Initiator's SPI (8 octets) - A value chosen by the initiator to 709 identify a unique IKE Security Association. This value MUST NOT 710 be zero. 712 o Responder's SPI (8 octets) - A value chosen by the responder to 713 identify a unique IKE Security Association. This value MUST be 714 zero in the first message of an IKE initial exchange. 716 o Next Payload (1 octet) - Indicates the type of payload that 717 immediately follows the header. The format and value of each 718 payload are defined below. 720 o Major Version (4 bits) - Indicates the major version of the IKE 721 protocol in use. Implementations based on this version of IKE 722 MUST set the major version to 2 and MUST drop the messages with a 723 higher major version number. 725 o Minor Version (4 bits) - Indicates the minor version of the IKE 726 protocol in use. Implementations based on this version of IKE 727 MUST set the minor version to 0. They MUST ignore the minor 728 version number of received messages. 730 o Exchange Type (1 octet) - Indicates the type of exchange being 731 used. This constrains the payloads sent in each message in an 732 exchange. 734 Exchange Type Value 735 ---------------------------------- 736 IKE_SA_INIT 34 737 IKE_AUTH 35 738 CREATE_CHILD_SA 36 739 INFORMATIONAL 37 741 o Flags (1 octet) - Indicates specific options that are set for the 742 message. Presence of options is indicated by the appropriate bit 743 in the flags field being set. The bits are as follows: 745 +-+-+-+-+-+-+-+-+ 746 |X|X|R|V|I|X|X|X| 747 +-+-+-+-+-+-+-+-+ 749 In the description below, a bit being 'set' means its value is 750 '1', while 'cleared' means its value is '0'. 'X' bits MUST be 751 cleared when sending and MUST be ignored on receipt. 753 * R (Response) - This bit indicates that this message is a 754 response to a message containing the same Message ID. This bit 755 MUST be cleared in all request messages and MUST be set in all 756 responses. An IKEv2 endpoint MUST NOT generate a response to a 757 message that is marked as being a response. 759 * V (Version) - This bit indicates that the transmitter is 760 capable of speaking a higher major version number of the 761 protocol than the one indicated in the major version number 762 field. Implementations of IKEv2 MUST clear this bit when 763 sending and MUST ignore it in incoming messages. 765 * I (Initiator) - This bit MUST be set in messages sent by the 766 original initiator of the IKE SA and MUST be cleared in 767 messages sent by the original responder. It is used by the 768 recipient to determine which eight octets of the SPI were 769 generated by the recipient. This bit changes to reflect who 770 initiated the last rekey of the IKE SA. 772 o Message ID (4 octets, unsigned integer) - Message identifier used 773 to control retransmission of lost packets and matching of requests 774 and responses. It is essential to the security of the protocol 775 because it is used to prevent message replay attacks. 777 o Length (4 octets, unsigned integer) - Length of the total message 778 (header + payloads) in octets. 780 A.2. Generic Payload Header 782 Each IKE payload begins with a generic payload header, shown in 783 Figure 2. Figures for each payload below will include the generic 784 payload header, but for brevity, the description of each field will 785 be omitted. 787 1 2 3 788 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 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | Next Payload |C| RESERVED | Payload Length | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 Figure 2: Generic Payload Header 795 The Generic Payload Header fields are defined as follows: 797 o Next Payload (1 octet) - Identifier for the payload type of the 798 next payload in the message. If the current payload is the last 799 in the message, then this field will be 0. This field provides a 800 "chaining" capability whereby additional payloads can be added to 801 a message by appending each one to the end of the message and 802 setting the "Next Payload" field of the preceding payload to 803 indicate the new payload's type. An Encrypted payload, which must 804 always be the last payload of a message, is an exception. It 805 contains data structures in the format of additional payloads. In 806 the header of an Encrypted payload, the Next Payload field is set 807 to the payload type of the first contained payload (instead of 0); 808 conversely, the Next Payload field of the last contained payload 809 is set to zero). The payload type values needed for minimal 810 implementations are listed here. 812 Next Payload Type Notation Value 813 -------------------------------------------------- 814 No Next Payload 0 815 Security Association SA 33 816 Key Exchange KE 34 817 Identification - Initiator IDi 35 818 Identification - Responder IDr 36 819 Certificate CERT 37 820 Certificate Request CERTREQ 38 821 Authentication AUTH 39 822 Nonce Ni, Nr 40 823 Notify N 41 824 Delete D 42 825 Traffic Selector - Initiator TSi 44 826 Traffic Selector - Responder TSr 45 827 Encrypted and Authenticated SK 46 829 o Critical (1 bit) - MUST be set to zero if the sender wants the 830 recipient to skip this payload if it does not understand the 831 payload type code in the Next Payload field of the previous 832 payload. MUST be set to one if the sender wants the recipient to 833 reject this entire message if it does not understand the payload 834 type. MUST be ignored by the recipient if the recipient 835 understands the payload type code. MUST be set to zero for 836 payload types defined in this document. Note that the critical 837 bit applies to the current payload rather than the "next" payload 838 whose type code appears in the first octet. 840 o Payload Length (2 octets, unsigned integer) - Length in octets of 841 the current payload, including the generic payload header. 843 A.3. Security Association Payload 845 The Security Association payload, denoted SA in this document, is 846 used to negotiate attributes of a Security Association. 848 An SA payload consists of one or more proposals. Each proposal 849 includes one protocol. Each protocol contains one or more transforms 850 -- each specifying a cryptographic algorithm. Each transform 851 contains zero or more attributes (attributes are needed only if the 852 Transform ID does not completely specify the cryptographic algorithm, 853 currently only attribute is key length attribute for variable length 854 ciphers, meaning there is exactly zero or one attribute). 856 The responder MUST choose a single suite, which may be any subset of 857 the SA proposal following the rules below. 859 Each proposal contains one protocol. If a proposal is accepted, the 860 SA response MUST contain the same protocol. Each IPsec protocol 861 proposal contains one or more transforms. Each transform contains a 862 Transform Type. The accepted cryptographic suite MUST contain 863 exactly one transform of each type included in the proposal. For 864 example: if an ESP proposal includes transforms ENCR_3DES, ENCR_AES 865 w/keysize 128, ENCR_AES w/keysize 256, AUTH_HMAC_MD5, and 866 AUTH_HMAC_SHA, the accepted suite MUST contain one of the ENCR_ 867 transforms and one of the AUTH_ transforms. Thus, six combinations 868 are acceptable. 870 Minimal implementation can create very simple SA proposal, i.e. 871 include one proposal, which contains exactly one transform for each 872 transform type. It is important to only include one Diffie-Hellman 873 group in proposal, so there is no need to do INVALID_KE_PAYLOAD 874 processing in responses. 876 When parsing an SA, an implementation MUST check that the total 877 Payload Length is consistent with the payload's internal lengths and 878 counts. Proposals, Transforms, and Attributes each have their own 879 variable-length encodings. They are nested such that the Payload 880 Length of an SA includes the combined contents of the SA, Proposal, 881 Transform, and Attribute information. The length of a Proposal 882 includes the lengths of all Transforms and Attributes it contains. 883 The length of a Transform includes the lengths of all Attributes it 884 contains. 886 Each Proposal/Protocol structure is followed by one or more transform 887 structures. The number of different transforms is generally 888 determined by the Protocol. AH generally has two transforms: 889 Extended Sequence Numbers (ESNs) and an integrity check algorithm. 890 ESP generally has three: ESN, an encryption algorithm, and an 891 integrity check algorithm. IKEv2 generally has four transforms: a 892 Diffie-Hellman group, an integrity check algorithm, a PRF algorithm, 893 and an encryption algorithm. For each Protocol, the set of 894 permissible transforms is assigned Transform ID numbers, which appear 895 in the header of each transform. 897 If there are multiple transforms with the same Transform Type, the 898 proposal is an OR of those transforms. If there are multiple 899 transforms with different Transform Types, the proposal is an AND of 900 the different groups. 902 A given transform MAY have one or more Attributes. Attributes are 903 necessary when the transform can be used in more than one way, as 904 when an encryption algorithm has a variable key size. The transform 905 would specify the algorithm and the attribute would specify the key 906 size. To propose alternate values for an attribute (for example, 907 multiple key sizes for the AES encryption algorithm), an 908 implementation MUST include multiple transforms with the same 909 Transform Type each with a single Attribute. 911 1 2 3 912 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 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | Next Payload |C| RESERVED | Payload Length | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | | 917 ~ ~ 918 | | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 Figure 3: Security Association Payload 923 o Proposals (variable) - One or more proposal substructures. 925 A.3.1. Proposal Substructure 927 1 2 3 928 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 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | 0 (last) or 2 | RESERVED | Proposal Length | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | Proposal Num | Protocol ID | SPI Size |Num Transforms| 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 ~ SPI (variable) ~ 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | | 937 ~ ~ 938 | | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 Figure 4: Proposal Substructure 943 o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the 944 last Proposal Substructure in the SA. 946 o Proposal Length (2 octets, unsigned integer) - Length of this 947 proposal, including all transforms and attributes that follow. 949 o Proposal Num (1 octet) - When a proposal is made, the first 950 proposal in an SA payload MUST be 1, and subsequent proposals MUST 951 be one more than the previous proposal. When a proposal is 952 accepted, the proposal number in the SA payload MUST match the 953 number on the proposal sent that was accepted. 955 o Protocol ID (1 octet) - Specifies the IPsec protocol identifier 956 for the current negotiation. 958 Protocol Protocol ID 959 ----------------------------------- 960 IKE 1 961 AH 2 962 ESP 3 964 o SPI Size (1 octet) - For an initial IKE SA negotiation, this field 965 MUST be zero; the SPI is obtained from the outer header. During 966 subsequent negotiations, it is equal to the size, in octets, of 967 the SPI of the corresponding protocol (8 for IKE, 4 for ESP and 968 AH). 970 o Num Transforms (1 octet) - Specifies the number of transforms in 971 this proposal. 973 o SPI (variable) - The sending entity's SPI. When the SPI Size 974 field is zero, this field is not present in the Security 975 Association payload. 977 o Transforms (variable) - One or more transform substructures. 979 A.3.2. Transform Substructure 981 1 2 3 982 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 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | 0 (last) or 3 | RESERVED | Transform Length | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 |Transform Type | RESERVED | Transform ID | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | | 989 ~ Transform Attributes ~ 990 | | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 Figure 5: Transform Substructure 995 o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the 996 last Transform Substructure in the Proposal. 998 o Transform Length - The length (in octets) of the Transform 999 Substructure including Header and Attributes. 1001 o Transform Type (1 octet) - The type of transform being specified 1002 in this transform. Different protocols support different 1003 Transform Types. For some protocols, some of the transforms may 1004 be optional. If a transform is optional and the initiator wishes 1005 to propose that the transform be omitted, no transform of the 1006 given type is included in the proposal. If the initiator wishes 1007 to make use of the transform optional to the responder, it 1008 includes a transform substructure with Transform ID = 0 as one of 1009 the options. 1011 o Transform ID (2 octets) - The specific instance of the Transform 1012 Type being proposed. 1014 The relevant Transform Type values are listed below. For more 1015 information see [RFC7296]. 1017 Description Trans. Used In 1018 Type 1019 ------------------------------------------------------------------ 1020 Encryption Algorithm (ENCR) 1 IKE and ESP 1021 Pseudorandom Function (PRF) 2 IKE 1022 Integrity Algorithm (INTEG) 3 IKE, AH, optional in ESP 1023 Diffie-Hellman group (D-H) 4 IKE, optional in AH & ESP 1024 Extended Sequence Numbers (ESN) 5 AH and ESP 1026 For Transform Type 1 (Encryption Algorithm), the relevant Transform 1027 IDs are listed below. 1029 Name Number 1030 --------------------------- 1031 ENCR_AES_CBC 12 1032 ENCR_AES-CCM_8 14 1034 For Transform Type 2 (Pseudorandom Function), the relevant Transform 1035 IDs are listed below. 1037 Name Number 1038 ---------------------------------- 1039 PRF_HMAC_SHA1 2 1041 For Transform Type 3 (Integrity Algorithm), relevant Transform IDs 1042 are listed below. 1044 Name Number 1045 --------------------------- 1046 AUTH_HMAC_SHA1_96 2 1047 AUTH_AES_XCBC_96 5 1049 For Transform Type 4 (Diffie-Hellman group), relevant Transform IDs 1050 are listed below. 1052 Name Number 1053 ------------------------- 1054 1536-bit MODP 5 1055 2048-bit MODP 14 1057 For Transform Type 5 (Extended Sequence Numbers), relevant Transform 1058 IDs are listed below. 1060 Name Number 1061 -------------------------------------------- 1062 No Extended Sequence Numbers 0 1063 Extended Sequence Numbers 1 1065 Note that an initiator who supports ESNs will usually include two ESN 1066 transforms, with values "0" and "1", in its proposals. A proposal 1067 containing a single ESN transform with value "1" means that using 1068 normal (non-extended) sequence numbers is not acceptable. 1070 A.3.3. Valid Transform Types by Protocol 1072 The number and type of transforms that accompany an SA payload are 1073 dependent on the protocol in the SA itself. An SA payload proposing 1074 the establishment of an SA has the following mandatory and optional 1075 Transform Types. A compliant implementation MUST understand all 1076 mandatory and optional types for each protocol it supports (though it 1077 need not accept proposals with unacceptable suites). A proposal MAY 1078 omit the optional types if the only value for them it will accept is 1079 NONE. 1081 Protocol Mandatory Types Optional Types 1082 --------------------------------------------------- 1083 IKE ENCR, PRF, INTEG, D-H 1084 ESP ENCR, ESN INTEG, D-H 1085 AH INTEG, ESN D-H 1087 A.3.4. Transform Attributes 1089 Transform type 1 (Encryption Algorithm) transforms might include one 1090 transform attribute: Key Length. 1092 1 2 3 1093 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 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 |1| Attribute Type | Attribute Value | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 Figure 6: Data Attributes 1099 o Attribute Type (15 bits) - Unique identifier for each type of 1100 attribute (see below). 1102 o Attribute Value - Value of the attribute associated with the 1103 attribute type. 1105 Attribute Type Value 1106 ---------------------------- 1107 Key Length (in bits) 14 1109 The Key Length attribute specifies the key length in bits (MUST use 1110 network byte order) for certain transforms as follows: 1112 o The Key Length attribute MUST NOT be used with transforms that use 1113 a fixed-length key. 1115 o Some transforms specify that the Key Length attribute MUST be 1116 always included. For example ENCR_AES_CBC. 1118 A.4. Key Exchange Payload 1120 1 2 3 1121 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 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 | Next Payload |C| RESERVED | Payload Length | 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 | Diffie-Hellman Group Num | RESERVED | 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 | | 1128 ~ Key Exchange Data ~ 1129 | | 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 Figure 7: Key Exchange Payload Format 1134 A Key Exchange payload is constructed by copying one's Diffie-Hellman 1135 public value into the "Key Exchange Data" portion of the payload. 1136 The length of the Diffie-Hellman public value for modular 1137 exponentiation group (MODP) groups MUST be equal to the length of the 1138 prime modulus over which the exponentiation was performed, prepending 1139 zero bits to the value if necessary. 1141 The Diffie-Hellman Group Num identifies the Diffie-Hellman group in 1142 which the Key Exchange Data was computed. This Diffie-Hellman Group 1143 Num MUST match a Diffie-Hellman group specified in a proposal in the 1144 SA payload that is sent in the same message 1146 A.5. Identification Payloads 1148 The Identification payloads, denoted IDi and IDr in this document, 1149 allow peers to assert an identity to one another. When using the 1150 ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 1151 does not require this address to match the address in the IP header 1152 of IKEv2 packets, or anything in the TSi/TSr payloads. The contents 1153 of IDi/IDr are used purely to fetch the policy and authentication 1154 data related to the other party. In minimal implementation it might 1155 be easiest to always use KEY_ID type. This allows the ID payload to 1156 be static. Using IP address has problems in environments where IP 1157 addresses are dynamically allocated. 1159 1 2 3 1160 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 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 | Next Payload |C| RESERVED | Payload Length | 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 | ID Type | RESERVED | 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1166 | | 1167 ~ Identification Data ~ 1168 | | 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 Figure 8: Identification Payload Format 1173 o ID Type (1 octet) - Specifies the type of Identification being 1174 used. 1176 o Identification Data (variable length) - Value, as indicated by the 1177 Identification Type. The length of the Identification Data is 1178 computed from the size in the ID payload header. 1180 The following table lists the assigned semantics for the 1181 Identification Type field. 1183 ID Type Value 1184 ------------------------------------------------------------------- 1185 ID_IPV4_ADDR 1 1186 A single four (4) octet IPv4 address. 1188 ID_FQDN 2 1189 A fully-qualified domain name string. An example of an ID_FQDN 1190 is "example.com". The string MUST NOT contain any terminators 1191 (e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII; 1192 for an "internationalized domain name", the syntax is as defined 1193 in [IDNA], for example "xn--tmonesimerkki-bfbb.example.net". 1195 ID_RFC822_ADDR 3 1196 A fully-qualified RFC 822 email address string. An example of a 1197 ID_RFC822_ADDR is "jsmith@example.com". The string MUST NOT 1198 contain any terminators. Because of [EAI], implementations would 1199 be wise to treat this field as UTF-8 encoded text, not as 1200 pure ASCII. 1202 ID_IPV6_ADDR 5 1203 A single sixteen (16) octet IPv6 address. 1205 ID_KEY_ID 11 1206 An opaque octet stream that may be used to pass vendor- 1207 specific information necessary to do certain proprietary 1208 types of identification. Minimal implementation might use 1209 this type to send out serial number or similar device 1210 specific unique static identification data for the device. 1212 A.6. Certificate Payload 1214 1 2 3 1215 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 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 | Next Payload |C| RESERVED | Payload Length | 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 | Cert Encoding | | 1220 +-+-+-+-+-+-+-+-+ | 1221 ~ Certificate Data ~ 1222 | | 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1225 Figure 9: Certificate Payload Format 1227 o Certificate Encoding (1 octet) - This field indicates the type of 1228 certificate or certificate-related information contained in the 1229 Certificate Data field. 1231 Certificate Encoding Value 1232 ---------------------------------------------------- 1233 X.509 Certificate - Signature 4 1234 Raw Public Key TBD 1236 o Certificate Data (variable length) - Actual encoding of 1237 certificate data. The type of certificate is indicated by the 1238 Certificate Encoding field. 1240 The syntax of the types above are: 1242 o "X.509 Certificate - Signature" contains a DER-encoded X.509 1243 certificate whose public key is used to validate the sender's AUTH 1244 payload. Note that with this encoding, if a chain of certificates 1245 needs to be sent, multiple CERT payloads are used, only the first 1246 of which holds the public key used to validate the sender's AUTH 1247 payload. 1249 o "Raw Public Key" contains a raw public key. In essence the 1250 Certificate Payload contains the SubjectPublicKeyInfo part of the 1251 PKIX certificate (See Section 4.1.2.7 of [RFC5280]). This is 1252 quite simple ASN.1 object which contains mostly static parts 1253 before the actual public key values. See 1254 [I-D.kivinen-ipsecme-oob-pubkey] for more information. 1256 A.7. Certificate Request Payload 1258 1 2 3 1259 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 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 | Next Payload |C| RESERVED | Payload Length | 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 | Cert Encoding | | 1264 +-+-+-+-+-+-+-+-+ | 1265 ~ Certification Authority ~ 1266 | | 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1269 Figure 10: Certificate Request Payload Format 1271 o Certificate Encoding (1 octet) - Contains an encoding of the type 1272 or format of certificate requested. 1274 o Certification Authority (variable length) - Contains an encoding 1275 of an acceptable certification authority for the type of 1276 certificate requested. 1278 The Certificate Encoding field has the same values as those defined 1279 certificate payload. The Certification Authority field contains an 1280 indicator of trusted authorities for this certificate type. The 1281 Certification Authority value is a concatenated list of SHA-1 hashes 1282 of the public keys of trusted Certification Authorities (CAs). Each 1283 is encoded as the SHA-1 hash of the Subject Public Key Info element 1284 (see Section 4.1.2.7 of [RFC5280]) from each Trust Anchor 1285 certificate. The 20-octet hashes are concatenated and included with 1286 no other formatting. 1288 A.8. Authentication Payload 1290 1 2 3 1291 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 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 | Next Payload |C| RESERVED | Payload Length | 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 | Auth Method | RESERVED | 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1297 | | 1298 ~ Authentication Data ~ 1299 | | 1300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1302 Figure 11: Authentication Payload Format 1304 o Auth Method (1 octet) - Specifies the method of authentication 1305 used. 1307 Mechanism Value 1308 ----------------------------------------------------------------- 1309 RSA Digital Signature 1 1310 Using an RSA private key with RSASSA-PKCS1-v1_5 signature 1311 scheme specified in [PKCS1], see [RFC7296] Section 2.15 for 1312 details. 1314 Shared Key Message Integrity Code 2 1315 Computed as specified earlier using the shared key associated 1316 with the identity in the ID payload and the negotiated PRF. 1318 o Authentication Data (variable length) - see Section 2.1. 1320 A.9. Nonce Payload 1321 1 2 3 1322 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 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 | Next Payload |C| RESERVED | Payload Length | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 | | 1327 ~ Nonce Data ~ 1328 | | 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 Figure 12: Nonce Payload Format 1333 o Nonce Data (variable length) - Contains the random data generated 1334 by the transmitting entity. 1336 The size of the Nonce Data MUST be between 16 and 256 octets, 1337 inclusive. Nonce values MUST NOT be reused. 1339 A.10. Notify Payload 1341 The Notify payload, denoted N in this document, is used to transmit 1342 informational data, such as error conditions and state transitions, 1343 to an IKE peer. A Notify payload may appear in a response message 1344 (usually specifying why a request was rejected), in an INFORMATIONAL 1345 Exchange (to report an error not in an IKE request), or in any other 1346 message to indicate sender capabilities or to modify the meaning of 1347 the request. 1349 1 2 3 1350 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 1351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1352 | Next Payload |C| RESERVED | Payload Length | 1353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1354 | Protocol ID | SPI Size | Notify Message Type | 1355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1356 | | 1357 ~ Security Parameter Index (SPI) ~ 1358 | | 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1360 | | 1361 ~ Notification Data ~ 1362 | | 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 Figure 13: Notify Payload Format 1367 o Protocol ID (1 octet) - If this notification concerns an existing 1368 SA whose SPI is given in the SPI field, this field indicates the 1369 type of that SA. If the SPI field is empty, this field MUST be 1370 sent as zero and MUST be ignored on receipt. 1372 o SPI Size (1 octet) - Length in octets of the SPI as defined by the 1373 IPsec protocol ID or zero if no SPI is applicable. For a 1374 notification concerning the IKE SA, the SPI Size MUST be zero and 1375 the field must be empty. 1377 o Notify Message Type (2 octets) - Specifies the type of 1378 notification message. 1380 o SPI (variable length) - Security Parameter Index. 1382 o Notification Data (variable length) - Status or error data 1383 transmitted in addition to the Notify Message Type. Values for 1384 this field are type specific. 1386 A.10.1. Notify Message Types 1388 Notification information can be error messages specifying why an SA 1389 could not be established. It can also be status data that a process 1390 managing an SA database wishes to communicate with a peer process. 1392 Types in the range 0 - 16383 are intended for reporting errors. An 1393 implementation receiving a Notify payload with one of these types 1394 that it does not recognize in a response MUST assume that the 1395 corresponding request has failed entirely. Unrecognized error types 1396 in a request and status types in a request or response MUST be 1397 ignored, and they should be logged. 1399 Notify payloads with status types MAY be added to any message and 1400 MUST be ignored if not recognized. They are intended to indicate 1401 capabilities, and as part of SA negotiation, are used to negotiate 1402 non-cryptographic parameters. 1404 NOTIFY messages: error types Value 1405 ------------------------------------------------------------------- 1406 UNSUPPORTED_CRITICAL_PAYLOAD 1 1407 Indicates that the one-octet payload type included in the 1408 Notification Data field is unknown. 1410 INVALID_SYNTAX 7 1411 Indicates the IKE message that was received was invalid because 1412 some type, length, or value was out of range or because the 1413 request was rejected for policy reasons. To avoid a DoS 1414 attack using forged messages, this status may only be 1415 returned for and in an encrypted packet if the Message ID and 1416 cryptographic checksum were valid. To avoid leaking information 1417 to someone probing a node, this status MUST be sent in response 1418 to any error not covered by one of the other status types. 1419 To aid debugging, more detailed error information should be 1420 written to a console or log. 1422 NO_PROPOSAL_CHOSEN 14 1423 None of the proposed crypto suites was acceptable. This can be 1424 sent in any case where the offered proposals are not acceptable 1425 for the responder. 1427 NO_ADDITIONAL_SAS 35 1428 Specifies that the node is unwilling to accept any more Child 1429 SAs. 1431 NOTIFY messages: status types Value 1432 ------------------------------------------------------------------- 1433 INITIAL_CONTACT 16384 1434 Asserts that this IKE SA is the only IKE SA currently active 1435 between the authenticated identities. 1437 A.11. Traffic Selector Payload 1439 Traffic Selector (TS) payloads allow endpoints to communicate some of 1440 the information from their SPD to their peers. TS payloads specify 1441 the selection criteria for packets that will be forwarded over the 1442 newly set up SA. 1444 1 2 3 1445 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 1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1447 | Next Payload |C| RESERVED | Payload Length | 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 | Number of TSs | RESERVED | 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 | | 1452 ~ ~ 1453 | | 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 Figure 14: Traffic Selectors Payload Format 1458 o Number of TSs (1 octet) - Number of Traffic Selectors being 1459 provided. 1461 o Traffic Selectors (variable length) - One or more individual 1462 Traffic Selectors. 1464 The length of the Traffic Selector payload includes the TS header and 1465 all the Traffic Selectors. 1467 There is no requirement that TSi and TSr contain the same number of 1468 individual Traffic Selectors. Thus, they are interpreted as follows: 1469 a packet matches a given TSi/TSr if it matches at least one of the 1470 individual selectors in TSi, and at least one of the individual 1471 selectors in TSr. 1473 Two TS payloads appear in each of the messages in the exchange that 1474 creates a Child SA pair. Each TS payload contains one or more 1475 Traffic Selectors. Each Traffic Selector consists of an address 1476 range (IPv4 or IPv6), a port range, and an IP protocol ID. 1478 The first of the two TS payloads is known as TSi (Traffic Selector- 1479 initiator). The second is known as TSr (Traffic Selector-responder). 1480 TSi specifies the source address of traffic forwarded from (or the 1481 destination address of traffic forwarded to) the initiator of the 1482 Child SA pair. TSr specifies the destination address of the traffic 1483 forwarded to (or the source address of the traffic forwarded from) 1484 the responder of the Child SA pair. 1486 IKEv2 allows the responder to choose a subset of the traffic proposed 1487 by the initiator. 1489 When the responder chooses a subset of the traffic proposed by the 1490 initiator, it narrows the Traffic Selectors to some subset of the 1491 initiator's proposal (provided the set does not become the null set). 1493 If the type of Traffic Selector proposed is unknown, the responder 1494 ignores that Traffic Selector, so that the unknown type is not 1495 returned in the narrowed set. 1497 To enable the responder to choose the appropriate range, if the 1498 initiator has requested the SA due to a data packet, the initiator 1499 SHOULD include as the first Traffic Selector in each of TSi and TSr a 1500 very specific Traffic Selector including the addresses in the packet 1501 triggering the request. If the initiator creates the Child SA pair 1502 not in response to an arriving packet, but rather, say, upon startup, 1503 then there may be no specific addresses the initiator prefers for the 1504 initial tunnel over any other. In that case, the first values in TSi 1505 and TSr can be ranges rather than specific values. 1507 As minimal implementations might only support one SA, the traffic 1508 selectors will usually be from initiator's IP address to responders 1509 IP address (i.e. no port or protocol selectors and only one range). 1511 A.11.1. Traffic Selector 1513 1 2 3 1514 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 1515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1516 | TS Type |IP Protocol ID | Selector Length | 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1518 | Start Port | End Port | 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 | | 1521 ~ Starting Address ~ 1522 | | 1523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1524 | | 1525 ~ Ending Address ~ 1526 | | 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 Figure 15: Traffic Selector 1531 o TS Type (one octet) - Specifies the type of Traffic Selector. 1533 o IP protocol ID (1 octet) - Value specifying an associated IP 1534 protocol ID (such as UDP, TCP, and ICMP). A value of zero means 1535 that the protocol ID is not relevant to this Traffic Selector -- 1536 the SA can carry all protocols. 1538 o Selector Length - Specifies the length of this Traffic Selector 1539 substructure including the header. 1541 o Start Port (2 octets, unsigned integer) - Value specifying the 1542 smallest port number allowed by this Traffic Selector. For 1543 protocols for which port is undefined (including protocol 0), or 1544 if all ports are allowed, this field MUST be zero. 1546 o End Port (2 octets, unsigned integer) - Value specifying the 1547 largest port number allowed by this Traffic Selector. For 1548 protocols for which port is undefined (including protocol 0), or 1549 if all ports are allowed, this field MUST be 65535. 1551 o Starting Address - The smallest address included in this Traffic 1552 Selector (length determined by TS Type). 1554 o Ending Address - The largest address included in this Traffic 1555 Selector (length determined by TS Type). 1557 The following table lists values for the Traffic Selector Type field 1558 and the corresponding Address Selector Data. 1560 TS Type Value 1561 ------------------------------------------------------------------- 1562 TS_IPV4_ADDR_RANGE 7 1564 A range of IPv4 addresses, represented by two four-octet 1565 values. The first value is the beginning IPv4 address 1566 (inclusive) and the second value is the ending IPv4 address 1567 (inclusive). All addresses falling between the two specified 1568 addresses are considered to be within the list. 1570 TS_IPV6_ADDR_RANGE 8 1572 A range of IPv6 addresses, represented by two sixteen-octet 1573 values. The first value is the beginning IPv6 address 1574 (inclusive) and the second value is the ending IPv6 address 1575 (inclusive). All addresses falling between the two specified 1576 addresses are considered to be within the list. 1578 A.12. Encrypted Payload 1580 The Encrypted payload, denoted SK{...} in this document, contains 1581 other payloads in encrypted form. 1583 1 2 3 1584 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 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 | Next Payload |C| RESERVED | Payload Length | 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1588 | Initialization Vector | 1589 | (length is block size for encryption algorithm) | 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1591 ~ Encrypted IKE Payloads ~ 1592 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1593 | | Padding (0-255 octets) | 1594 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 1595 | | Pad Length | 1596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1597 ~ Integrity Checksum Data ~ 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 Figure 16: Encrypted Payload Format 1602 o Next Payload - The payload type of the first embedded payload. 1603 Note that this is an exception in the standard header format, 1604 since the Encrypted payload is the last payload in the message and 1605 therefore the Next Payload field would normally be zero. But 1606 because the content of this payload is embedded payloads and there 1607 was no natural place to put the type of the first one, that type 1608 is placed here. 1610 o Payload Length - Includes the lengths of the header, 1611 initialization vector (IV), Encrypted IKE payloads, Padding, Pad 1612 Length, and Integrity Checksum Data. 1614 o Initialization Vector - For CBC mode ciphers, the length of the 1615 initialization vector (IV) is equal to the block length of the 1616 underlying encryption algorithm. Senders MUST select a new 1617 unpredictable IV for every message; recipients MUST accept any 1618 value. The reader is encouraged to consult [MODES] for advice on 1619 IV generation. In particular, using the final ciphertext block of 1620 the previous message is not considered unpredictable. For modes 1621 other than CBC, the IV format and processing is specified in the 1622 document specifying the encryption algorithm and mode. 1624 o IKE payloads are as specified earlier in this section. This field 1625 is encrypted with the negotiated cipher. 1627 o Padding MAY contain any value chosen by the sender, and MUST have 1628 a length that makes the combination of the payloads, the Padding, 1629 and the Pad Length to be a multiple of the encryption block size. 1630 This field is encrypted with the negotiated cipher. 1632 o Pad Length is the length of the Padding field. The sender SHOULD 1633 set the Pad Length to the minimum value that makes the combination 1634 of the payloads, the Padding, and the Pad Length a multiple of the 1635 block size, but the recipient MUST accept any length that results 1636 in proper alignment. This field is encrypted with the negotiated 1637 cipher. 1639 o Integrity Checksum Data is the cryptographic checksum of the 1640 entire message starting with the Fixed IKE header through the Pad 1641 Length. The checksum MUST be computed over the encrypted message. 1642 Its length is determined by the integrity algorithm negotiated. 1644 Appendix B. Useful Optional Features 1646 There are some optional features of IKEv2, which might be useful for 1647 minimal implementations in some scenarios. Such features include Raw 1648 public keys authentication, and sending IKE SA delete notification. 1650 B.1. IKE SA Delete Notification 1652 In some scenarios, a minimal implementation device creates an IKE SA, 1653 sends one or few packets, perhaps gets some packets back, and then 1654 the device goes back to sleep forgetting the IKE SA. In such 1655 scenarios it would be nice for the minimal implementation to send the 1656 IKE SA delete notification to tell the other end that the IKE SA is 1657 going away, so it can free the resources. 1659 Deleting the IKE SA can be done by sending one packet with a fixed 1660 Message ID, and with only one payload inside the encrypted payload. 1661 The other end will send back an empty response: 1663 Initiator Responder 1664 ------------------------------------------------------------------- 1665 HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL, 1666 Flags: Initiator, Message ID=2), 1667 SK {D} --> 1669 <-- HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL, 1670 Flags: Response, Message ID=2), 1671 SK {} 1673 The delete payload format is: 1675 1 2 3 1676 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 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1678 | Next Payload |C| RESERVED | Payload Length | 1679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1680 | Protocol ID | SPI Size | Num of SPIs | 1681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1682 | | 1683 ~ Security Parameter Index(es) (SPI) ~ 1684 | | 1685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1687 Figure 17: Delete Payload Format 1689 o Protocol ID (1 octet) - Must be 1 for an IKE SA. 1691 o SPI Size (1 octet) - Length in octets of the SPI as defined by the 1692 protocol ID. It MUST be zero for IKE (SPI is in message header). 1694 o Num of SPIs (2 octets, unsigned integer) - The number of SPIs 1695 contained in the Delete payload. This MUST be zero for IKE. 1697 o Security Parameter Index(es) (variable length) - Identifies the 1698 specific Security Association(s) to delete. The length of this 1699 field is determined by the SPI Size and Num of SPIs fields. This 1700 field is empty for the IKE SA delete. 1702 B.2. Raw Public Keys 1704 In some scenarios the shared secret authentication is not safe 1705 enough, as anybody who knows the secret can impersonate the server. 1706 If the shared secret is printed on the side of the device, then 1707 anybody who gets physical access to the device can read it. In such 1708 environments, public key authentication allows stronger 1709 authentication with minimal operational overhead. Certificate 1710 support is quite complex, and minimal implementations do not usually 1711 have need for them. Using Raw Public Keys is much simpler, and it 1712 scales similar to certificates. The fingerprint of the Raw Public 1713 Key can still be distributed by, for example, printing it on the side 1714 of the device allowing setup similar to using a shared secret. 1716 Raw Public Keys can also be used in a "leap of faith" or baby duck 1717 style initial setup, where the device imprints itself to the first 1718 device it sees when it boots up the first time. After that initial 1719 connection it stores the fingerprint of the Raw Public Key of the 1720 server in its own configuration and verifies that it never changes 1721 (unless a "reset to factory settings" or similar command is issued). 1723 This changes the initial IKE_AUTH payloads as follows: 1725 Initiator Responder 1726 ------------------------------------------------------------------- 1727 HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, 1728 Flags: Initiator, Message ID=1), 1729 SK {IDi, CERT, AUTH, SAi2, TSi, TSr, 1730 N(INITIAL_CONTACT)} --> 1732 <-- HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags: 1733 Response, Message ID=1), 1734 SK {IDr, CERT, AUTH, SAr2, TSi, TSr} 1736 The CERT payloads contains the Raw Public Keys used to sign the hash 1737 of the InitiatorSignedOctects/ResponderSignedOctects when generating 1738 an AUTH payload. Minimal implementations should use SHA-1 as the 1739 hash function as that is the "SHOULD" support algorithm specified in 1740 RFC 7296, so it is the most likely one that is supported by all 1741 devices. 1743 Note, that RFC 7296 already obsoleted the old Raw RSA Key method, and 1744 More Raw Public Keys for IKEv2 ([I-D.kivinen-ipsecme-oob-pubkey]) 1745 adds a new format to allow using any types of Raw Public Keys with 1746 IKEv2. This document only specifies how to use the new format. 1748 In these setups it might be possible that authenticating the server 1749 is not needed at all. If a minimal device is sending, for example, 1750 sensor information to the server, the server wants to verify that the 1751 sensor is who it claims to be using raw public keys, but the sensor 1752 does not really care who the server is. In such cases the NULL 1753 authentication method ([RFC7619]) would be useful, as it allows 1754 devices to do one-way authentication. 1756 Author's Address 1758 Tero Kivinen 1759 INSIDE Secure 1760 Eerikinkatu 28 1761 HELSINKI FI-00180 1762 FI 1764 Email: kivinen@iki.fi