idnits 2.17.1 draft-ietf-ipsecme-rfc4307bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 04, 2016) is 3035 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 281 == Missing Reference: 'IoT' is mentioned on line 324, but not defined == Missing Reference: 'IKEv2' is mentioned on line 350, but not defined ** Obsolete normative reference: RFC 4307 (Obsoleted by RFC 8247) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Nir 3 Internet-Draft Check Point 4 Intended status: Standards Track T. Kivinen 5 Expires: July 07, 2016 INSIDE Secure 6 P. Wouters 7 Red Hat 8 D. Migault 9 Ericsson 10 January 04, 2016 12 Algorithm Implementation Requirements and Usage Guidance for IKEv2 13 draft-ietf-ipsecme-rfc4307bis-02 15 Abstract 17 The IPsec series of protocols makes use of various cryptographic 18 algorithms in order to provide security services. The Internet Key 19 Exchange protocol provides a mechanism to negotiate which algorithms 20 should be used in any given Security Association. To ensure 21 interoperability between different implementations, it is necessary 22 to specify a set of algorithm implementation requirements and Usage 23 guidance to ensure that there is at least one algorithm that all 24 implementations will have available. This document defines the 25 current algorithm implementation requirements and usage guidance of 26 IKEv2. This document does not update the algorithms used for packet 27 encryption using IPsec Encapsulated Security Payload (ESP) 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on July 07, 2016. 46 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Updating Algorithm Implementation Requirements and Usage 64 Guidance . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3 66 1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4 67 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 68 3. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Type 1 - IKEv2 Encryption Algorithm Transforms . . . . . 5 70 3.2. Type 2 - IKEv2 Pseudo-random Function Transforms . . . . 6 71 3.3. Type 3 - IKEv2 Integrity Algorithm Transforms . . . . . . 7 72 3.4. Type 4 - IKEv2 Diffie-Hellman Group Transforms . . . . . 8 73 4. IKEv2 Authentication . . . . . . . . . . . . . . . . . . . . 9 74 4.1. IKEv2 Authentication Method . . . . . . . . . . . . . . . 9 75 4.2. Digital Signature Recommendation . . . . . . . . . . . . 10 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 81 8.2. Informative References . . . . . . . . . . . . . . . . . 12 83 1. Introduction 84 The Internet Key Exchange protocol [RFC7296] is used to negotiate the 85 IPsec parameters, such as encryption algorithms and keys, for 86 protected communications between two endpoints. The IKEv2 protocol 87 itself is also protected by encryption, which is also negotiated 88 between the two endpoints. Negotiation is performed by IKEv2 itself. 89 This document describes the encryption parameters of the IKE 90 protocol, not the encryption parameters of the ESP (IPsec) protocol. 91 Different implementations of IKEv2 may negotiate different encryption 92 algorithms based on their individual local policy. To ensure 93 interoperability, a set of "mandatory-to-implement" IKEv2 encryption 94 algorithms is defined. 96 1.1. Updating Algorithm Implementation Requirements and Usage Guidance 98 The field of cryptography evolves continiously. New stronger 99 algorithms appear and existing algorithms are found to be less secure 100 then originally thought. Therefore, algorithm implementation 101 requirements and usage guidance need to be updated from time to time 102 to reflect the new reality. The choices for algorithms must be 103 conservative to minimize the risk of algorithm compromised. 104 Algorithms need to be suitable for a wide variety of CPU 105 architectures and device deployments ranging from high end bulk 106 encryption devices to small low-power IoT devices. 108 The algorithm implementation requirements and usage guidance may need 109 to change over time to adapt to the changing world. For this reason, 110 the selection of mandatory-to-implement algorithms was removed from 111 the main IKEv2 specification and placed in this document. 113 1.2. Updating Algorithm Requirement Levels 115 Ideally, the mandatory-to-implement algorithm of tomorrow should 116 already be available in most implementations of IKE by the time it is 117 made mandatory. To facilitate this, this document attempts to 118 identify those algorithms for future mandatory-to-implement. There 119 is no guarantee that the algorithms in use today may become mandatory 120 in the future. Published algorithms are continiously subjected to 121 cryptographic attack and may become too weak or could become 122 completely broken before this document is updated. 124 This document only provides recommendations for the mandatory-to- 125 implement algorithms or algorithms too weak that are recommended not 126 to be implemented. As a result, any algorithm not mentioned in this 127 document MAY be implemented. For clarification and consistency with 128 [RFC4307] an algorithm will be set to MAY only when it has been 129 downgraded. 131 Although this document updates the algorithms in order to keep the 132 IKEv2 communication secure over time, it also aims at providing 133 recommendations so that IKEv2 implementations remain interoperable. 134 IKEv2 interoperability is addressed by an incremental introduction or 135 deprecation of algorithms. In addition, this document also considers 136 the new use cases for IKEv2 deployment, such as Internet of Things 137 (IoT). 139 It is expected that deprecation of an algorithm is performed 140 gradually. This provides time for various implementations to update 141 their implemented algorithms while remaining interoperable. Unless 142 there are strong security reasons, an algorithm is expected to be 143 downgraded from MUST to MUST- or SHOULD, instead of MUST NOT. 144 Similarly, an algorithm that has not been mentioned as mandatory-to- 145 implement is expected to be introduced with a SHOULD instead of a 146 MUST. 148 The current trend toward Internet of Things and its adoption of IKEv2 149 requires this specific use case to be taken into account as well. 150 IoT devices are resource constrainted devices and their choice of 151 algorithms are motivated by minimizing the fooprint of the code, the 152 computation effort and the size of the messages to send. This 153 document indicates IoT when a specified algorithm is specifically 154 listed for IoT devices. 156 1.3. Document Audience 158 The recommendations of this document target IKEv2 implementers. In 159 other words, the recommendations should not be considered for IKEv2 160 configuration, as a preference for some algorithms. [PAUL: I don't 161 understand this. Clearly MTI are good default choices?] 163 IKEv1 is out of scope of this document. IKEv1 is deprecated and the 164 recommendations of this document must not be considered for IKEv1. 166 2. Conventions Used in This Document 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in [RFC2119]. 172 We define some additional terms here: 174 SHOULD+ This term means the same as SHOULD. However, it is likely 175 that an algorithm marked as SHOULD+ will be promoted at some 176 future time to be a MUST. 177 SHOULD- This term means the same as SHOULD. However, an algorithm 178 marked as SHOULD- may be deprecated to a MAY in a future 179 version of this document. 180 MUST- This term means the same as MUST. However, we expect at 181 some point that this algorithm will no longer be a MUST in a 182 future document. Although its status will be determined at 183 a later time, it is reasonable to expect that if a future 184 revision of a document alters the status of a MUST- 185 algorithm, it will remain at least a SHOULD or a SHOULD-. 186 IoT stands for Internet of Things. 188 Table 1 190 3. Algorithm Selection 192 3.1. Type 1 - IKEv2 Encryption Algorithm Transforms 194 The algorithms in the below table are negotiated in the SA payload 195 and used in the ENCR payload. References to the specifications 196 defining these algorithms and the ones in the following subsections 197 are in the IANA registry [IKEV2-IANA]. Some of these algorithms are 198 Authenticated Encryption with Associated Data (AEAD - [RFC5282]). 199 Algorithms that are not AEAD MUST be used in conjunction with an 200 integrity algorithms in Section 3.3. 202 +-----------------------------+----------+-------+----------+ 203 | Name | Status | AEAD? | Comment | 204 +-----------------------------+----------+-------+----------+ 205 | ENCR_AES_CBC | MUST- | No | [1] | 206 | ENCR_CHACHA20_POLY1305 | SHOULD | Yes | | 207 | AES-GCM with a 16 octet ICV | SHOULD | Yes | [1] | 208 | ENCR_AES_CCM_8 | SHOULD | Yes | [1][IoT] | 209 | ENCR_3DES | MAY | No | | 210 | ENCR_DES | MUST NOT | No | | 211 +-----------------------------+----------+-------+----------+ 213 [1] - This requirement level is for 128-bit keys. 256-bit keys are at 214 MAY. 192-bit keys can safely be ignored. [IoT] - This requirement is 215 for interoperability with IoT. 217 Table 2 219 ENCR_AES_CBC is raised from SHOULD+ in RFC4307. It is the only 220 shared mandatory-to-implement algorithm with RFC4307 and as a result 221 is necessary for interoperability with IKEv2 implementation 222 compatible with RFC4307. 224 ENCR_CHACHA20_POLY1305 was not ready to be considered at the time of 225 RFC4307. It has been recommended by the CRFG and others as an 226 alternative to AES and AES-GCM. It is also being standarized for 227 IPsec for the same reasons. At the time of writing, there were not 228 enough IKEv2 implementations of ENCR_CHACHA20_POLY1305 to be able to 229 introduce it at the SHOULD+ level. 231 AES-GCM with a 16 octet ICV was not considered as in RFC4307. At the 232 time RFC4307 was written, AES-GCM was not defined in an IETF 233 document. AES-GCM was defined for ESP in [RFC4106] and later for 234 IKEv2 in [RFC5282]. The main motivation for adopting AES-GCM for ESP 235 is encryption performance as well as key longevity - compared to AES- 236 CBC for example. This resulted in AES-GCM widely implemented for 237 ESP. As the load of IKEv2 is expected to remain relatively small, 238 many IKEv2 implementations do not include AES-GCM. In addition to 239 its former MAY, this document does not promote AES-GCM to a greater 240 status than SHOULD so to preserve interoperability between IKEv2 241 implementations. [PAUL: I dont follow the reasoning, as we could 242 have AES and AES-GCM at MUST level] This document considers AES-GCM 243 as mandatory to implement to promote the slightly more secure AEAD 244 method over the traditional encrypt+auth method. Its status is 245 expected to be raised once widely deployed. 247 ENCR_AES_CCM_8 was not considered in RFC4307. This document 248 considers it SHOULD be implemented in order to be able to interact 249 with Internet of Things devices. As this case is not a general use 250 case for VPNs, its status is expected to remain to SHOULD. The size 251 of the ICV is expected to be sufficient for most use cases of IKEv2, 252 as far less packets are exchanged on the IKE_SA compared to the IPsec 253 SA. When implemented, ENCR_AES_CCM_8 MUST be implemented for key 254 length 128 and MAY be implemented for key length 256. 256 ENCR_3DES has been downgraded from RFC4307 MUST-. All IKEv2 257 implementation already implement ENCR_AES_CBC, so there is no need to 258 keep ENCR_3DES. In addition, ENCR_CHACHA20_POLY1305 provides a more 259 modern alternative to AES. [PAUL: removed 'efficient' as we said 260 above encryption efficiency at the IKE level hardly matters] 262 ENCR_DES can be brute-forced using of-the-shelves hardware. It 263 provides no meaningful security whatsoever and therefor MUST NOT be 264 implemented. 266 3.2. Type 2 - IKEv2 Pseudo-random Function Transforms 268 Transform Type 2 Algorithms are pseudo-random functions used to 269 generate random values when needed. 271 In general, if you can trust an algorithm as INTEG algorithm, you can 272 and should also use it as the PRF. When using an AEAD cipher, the 273 choice is PRF is open, and picking one of the SHA2 variants is 274 recommended. 276 +-------------------+---------+---------+ 277 | Name | Status | Comment | 278 +-------------------+---------+---------+ 279 | PRF_HMAC_SHA2_256 | MUST | | 280 | PRF_HMAC_SHA2_512 | SHOULD+ | | 281 | PRF_HMAC_SHA1 | MUST- | [1] | 282 | PRF_AES128_CBC | SHOULD | [IoT] | 283 +-------------------+---------+---------+ 285 [IoT] - This requirement is for interoperability with IoT 287 Table 3 289 PRF_HMAC_SHA2_256 was not mentioned in RFC4307, as no SHA2 based 290 authentication was mentioned. PRF_HMAC_SHA2_256 MUST be implemented 291 in order to replace SHA1 and PRF_HMAC_SHA1. 293 PRF_HMAC_SHA2_512 SHOULD be implemented as as a future replacement of 294 SHA2_256 or when stronger security is required. PRF_HMAC_SHA2_512 is 295 preferred over PRF_HMAC_SHA2_384, as the overhead of 296 PRF_HMAC_SHA2_512 is negligible. 298 PRF_HMAC_SHA1_96 has been downgraded from MUST in RFC4307. There is 299 an industry-wide trend to deprecate its usage. 301 PRF_AES128_CBC is only recommended in the scope of IoT, as Internet 302 of Things deployments tend to prefer AES based pseudo-random 303 functions in order to avoid implementing SHA2. For the wide VPN 304 deployment, as it has not been widely adopted, it has been downgraded 305 from SHOULD in RFC4307 to MAY. 307 3.3. Type 3 - IKEv2 Integrity Algorithm Transforms 309 The algorithms in the below table are negotiated in the SA payload 310 and used in the ENCR payload. References to the specifications 311 defining these algorithms are in the IANA registry. When an AEAD 312 algorithm (see Section 3.1) is proposed, this algorithm transform 313 type is not in use. 315 +------------------------+--------+---------+ 316 | Name | Status | Comment | 317 +------------------------+--------+---------+ 318 | AUTH_HMAC_SHA2_256_128 | MUST | | 319 | AUTH_HMAC_SHA2_512_256 | SHOULD | | 320 | AUTH_HMAC_SHA1_96 | SHOULD | | 321 | AUTH_AES_XCBC_96 | SHOULD | [IoT] | 322 +------------------------+--------+---------+ 324 [IoT] - This requirement is for interoperability with IoT 326 Table 4 328 AUTH_HMAC_SHA2_256_128 was not mentioned in RFC4307, as no SHA2 based 329 authentication was mentioned. AUTH_HMAC_SHA2_256_128 MUST be 330 implemented in order to replace AUTH_HMAC_SHA1_96. 332 AUTH_HMAC_SHA2_512_256 SHOULD be implemented as as a future 333 replacement of AUTH_HMAC_SHA2_256_128 or when stronger security is 334 required. This value has been preferred to AUTH_HMAC_SHA2_384, as 335 the overhead of AUTH_HMAC_SHA2_512 is negligible. 337 AUTH_HMAC_SHA1_96 has been downgraded from MUST in RFC4307. There is 338 an industry-wide trend to deprecate its usage. 340 AUTH_AES-XCBC is only recommended in the scope of IoT, as Internet of 341 Things deployments tend to prefer AES based pseudo-random functions 342 in order to avoid implementing SHA2. For the wide VPN deployment, as 343 it has not been widely adopted, it has been downgraded from SHOULD in 344 RFC4307 to MAY. 346 3.4. Type 4 - IKEv2 Diffie-Hellman Group Transforms 348 There are several Modular Exponential (MODP) groups and several 349 Elliptic Curve groups (ECC) that are defined for use in IKEv2. They 350 are defined in both the [IKEv2] base document and in extensions 351 documents. They are identified by group number. 353 +--------+--------------------------+------------+ 354 | Number | Description | Status | 355 +--------+--------------------------+------------+ 356 | 14 | 2048-bit MODP Group | MUST | 357 | 19 | 256-bit random ECP group | SHOULD | 358 | 5 | 1536-bit MODP Group | SHOULD NOT | 359 | 2 | 1024-bit MODP Group | SHOULD NOT | 360 | 1 | 768-bit MODP Group | MUST NOT | 361 | TBD | Curve25519 | MAY | 362 +--------+--------------------------+------------+ 364 Table 5 366 Group 14 or 2048-bit MODP Group is raised from SHOULD+ in RFC4307 as 367 a replacement for 1024-bit MODP Group. Group 14 is widely 368 implemented and considered secure 370 Group 19 or 256-bit random ECP group was not specified in RFC4307. 371 Group 19 is widely implemented and considered secure 372 Group 5 or 1536-bit MODP Group is downgrade from MUST- to SHOULD NOT. 373 It was specified earlier, but now considered to be vulnerable to be 374 broken within the next few years by a nation state level attack, so 375 its security margin is considered too narrow. 377 Group 2 or 1024-bit MODP Group is downgrade from MUST- to SHOULD NOT. 378 It was specified earlier, but now it is known to be weak against 379 sufficiently funded attackers using commercially available mass- 380 computing resources, so its security margin is considered too narrow. 381 It is expected in the near future to be downgraded to MUST NOT. 383 Group 1 or 768-bit MODP Group can be broken within hours using cheap 384 of-the-shelves hardware. It provides no security whatsoever. 386 Curve25519 has been designed with performance and security in mind 387 and have been recommended by CFRG. At the time of writing, the IKEv2 388 specification is still at the draft status. This document specifies 389 it as to encourage its implementation and deployment. If it gets 390 widely implemented then it most likely will be upgraded to SHOULD or 391 even MUST in the future. 393 4. IKEv2 Authentication 395 IKEv2 authentication may involve a signatures verification. 396 Signatures may be used to validate a certificate or to check the 397 signature of the AUTH value. Cryptographic recommendations regarding 398 certificate validation are out of scope of this document as what 399 mandatory implementations are provided by the PKIX WG. This document 400 is mostly concerned on signature verification and generation for the 401 authentication. 403 4.1. IKEv2 Authentication Method 405 +----------+-----------------------+----------+---------------------+ 406 | Number | Description | Status | Comment | 407 +----------+-----------------------+----------+---------------------+ 408 | 1 | RSA Digital Signature | MUST | With keys length | 409 | | | | 2048 | 410 | 1 | RSA Digital Signature | SHOULD | With keys length | 411 | | | | 3072/4096 | 412 | 1 | RSA Digital Signature | MUST NOT | With keys length | 413 | | | | lower than 2048 | 414 | 3 | DSS Digital Signature | MAY | | 415 | 9 | ECDSA with SHA-256 on | SHOULD | | 416 | | the P-256 curve | | | 417 | 10 | ECDSA with SHA-384 on | SHOULD | | 418 | | the P-384 curve | | | 419 | 11 | ECDSA with SHA-512 on | SHOULD | | 420 | | the P-521 curve | | | 421 | 14 | Digital Signature | SHOULD | | 422 +----------+-----------------------+----------+---------------------+ 424 Table 6 426 RSA Digital Signature is mostly kept for interoperability. It is 427 expected to be downgraded in the future as signatures are based on 428 RSASSA-PKCS1-v1.5, not any more recommemded. Instead, more robust 429 use of RSA is expected to be performed via the Digital Signature 430 method. 432 ECDSA family are also expected to be downgraded as it does not 433 provide hash function agility. Instead ECDSA is expected to be 434 performed using the generic Digital Signature method. 436 DSS Digital Signature is bound to SHA-1 and thus is expected to be 437 downgraded to MUST NOT in the future. 439 Digital Signature is expected to be promoted as it provides hash 440 function, signature format and algorithm agility. 442 [MGLT: Do we have any recommendation for the authentication based on 443 PSK?] 445 4.2. Digital Signature Recommendation 447 Recommended methods: RSA (MUST), ECDSA (SHOULD), Ed25519 (MAY), 448 Ed25519ph(MAY), Ed448(MAY), Ed448ph(MAY)? 450 Here are the recommendations when a hash function is involved in a 451 signature. 453 +--------+----------------------+----------+---------+ 454 | Number | Description | Status | Comment | 455 +--------+----------------------+----------+---------+ 456 | 1 | SHA1 | MUST | | 457 | 2 | SHA2-256 | MUST | | 458 | 3 | SHA2-384 | MAY | | 459 | 4 | SHA2-512 | SHOULD | | 460 | | Other hash functions | MUST NOT | | 461 +--------+----------------------+----------+---------+ 463 Table 7 465 With the use of Digital Signature, RSASSA-PKCS1-v1.5 MAY be 466 implemented, and RSASSA-PSS MUST be implemented. 468 RSA keys MUST be greater or equal than 20148 bits. 470 5. Security Considerations 472 The security of cryptographic-based systems depends on both the 473 strength of the cryptographic algorithms chosen and the strength of 474 the keys used with those algorithms. The security also depends on 475 the engineering of the protocol used by the system to ensure that 476 there are no non-cryptographic ways to bypass the security of the 477 overall system. 479 The Diffie-Hellman Groups parameter is the most important one to 480 choose conservatively. Any party capturing all traffic that can 481 break the selected DH group can retroactively gain access to the 482 symmetric keys used to encrypt all the IPsec data. However, 483 specifying extremely large DH group also puts a considerable load on 484 the device, especially when this is a large VPN gateway or an IoT 485 constrained device. 487 This document concerns itself with the selection of cryptographic 488 algorithms for the use of IKEv2, specifically with the selection of 489 "mandatory-to-implement" algorithms. The algorithms identified in 490 this document as "MUST implement" or "SHOULD implement" are not known 491 to be broken at the current time, and cryptographic research so far 492 leads us to believe that they will likely remain secure into the 493 foreseeable future. However, this isn't necessarily forever and it 494 is expected that new revisions of this document will be issued from 495 time to time to reflect the current best practice in this area. 497 6. IANA Considerations 499 This document makes no requests of IANA. 501 7. Acknowledgements 503 The first version of this document was RFC 4307 by Jeffrey I. 504 Schiller of the Massachusetts Institute of Technology (MIT). Much of 505 the original text has been copied verbatim. 507 We would like to thanks Paul Hoffman, Yaron Sheffer and Tommy Pauly 508 for their valuable feed backs. 510 8. References 512 8.1. Normative References 514 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 515 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 516 RFC2119, March 1997, 517 . 519 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 520 (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 521 4106, DOI 10.17487/RFC4106, June 2005, 522 . 524 [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the 525 Internet Key Exchange Version 2 (IKEv2)", RFC 4307, DOI 526 10.17487/RFC4307, December 2005, 527 . 529 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 530 Kivinen, "Internet Key Exchange Protocol Version 2 531 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 532 2014, . 534 [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption 535 Algorithms with the Encrypted Payload of the Internet Key 536 Exchange version 2 (IKEv2) Protocol", RFC 5282, DOI 537 10.17487/RFC5282, August 2008, 538 . 540 8.2. Informative References 542 [IKEV2-IANA] 543 , "Internet Key Exchange Version 2 (IKEv2) Parameters", , 544 . 546 Authors' Addresses 548 Yoav Nir 549 Check Point Software Technologies Ltd. 550 5 Hasolelim st. 551 Tel Aviv 6789735 552 Israel 554 EMail: ynir.ietf@gmail.com 556 Tero Kivinen 557 INSIDE Secure 558 Eerikinkatu 28 559 HELSINKI FI-00180 560 FI 562 EMail: kivinen@iki.fi 563 Paul Wouters 564 Red Hat 566 EMail: pwouters@redhat.com 568 Daniel Migault 569 Ericsson 570 8400 boulevard Decarie 571 Montreal, QC H4P 2N2 572 Canada 574 Phone: +1 514-452-2160 575 EMail: daniel.migault@ericsson.com