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