idnits 2.17.1 draft-mglt-ipsecme-rfc7321bis-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 1, 2016) is 2794 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 220 == Missing Reference: 'IoT' is mentioned on line 374, but not defined == Missing Reference: 'UNSPECIFIED' is mentioned on line 305, but not defined ** Obsolete normative reference: RFC 7321 (Obsoleted by RFC 8221) -- Obsolete informational reference (is this intentional?): RFC 2393 (Obsoleted by RFC 3173) -- Obsolete informational reference (is this intentional?): RFC 4835 (Obsoleted by RFC 7321) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Migault 3 Internet-Draft J. Mattsson 4 Obsoletes: 7321 (if approved) Ericsson 5 Intended status: Standards Track P. Wouters 6 Expires: March 5, 2017 Red Hat 7 Y. Nir 8 Check Point 9 T. Kivinen 10 INSIDE Secure 11 September 1, 2016 13 Cryptographic Algorithm Implementation Requirements and Usage Guidance 14 for Encapsulating Security Payload (ESP) and Authentication Header (AH) 15 draft-mglt-ipsecme-rfc7321bis-02 17 Abstract 19 This document updates the Cryptographic Algorithm Implementation 20 Requirements for ESP and AH. The goal of these document is to enable 21 ESP and AH to benefit from cryptography that is up to date while 22 making IPsec interoperable. 24 This document obsoletes RFC 7321 on the cryptographic recommendations 25 only. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on March 5, 2017. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Updating Algorithm Implementation Requirements and Usage 63 Guidance . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3 65 1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4 66 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 67 3. ESP Encryption Algorithms . . . . . . . . . . . . . . . . . . 5 68 4. ESP and AH Authentication Algorithms . . . . . . . . . . . . 7 69 5. ESP and AH Compression Algorithms . . . . . . . . . . . . . . 8 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 75 9.2. Informative References . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 78 1. Introduction 80 The Encapsulating Security Payload (ESP) [RFC4303] and the 81 Authentication Header (AH) [RFC4302] are the mechanisms for applying 82 cryptographic protection to data being sent over an IPsec Security 83 Association (SA) [RFC4301]. 85 This document provides guidance and recommendations so that ESP and 86 AH can be used with a cryptographic algorithms that are up to date. 87 The challenge of such document is to make sure that over the time 88 IPsec implementations can use secure and up-to-date cryptographic 89 algorithms while keeping IPsec interoperable. 91 1.1. Updating Algorithm Implementation Requirements and Usage Guidance 93 The field of cryptography evolves continuously. New stronger 94 algorithms appear and existing algorithms are found to be less secure 95 then originally thought. Therefore, algorithm implementation 96 requirements and usage guidance need to be updated from time to time 97 to reflect the new reality. The choices for algorithms must be 98 conservative to minimize the risk of algorithm compromise. 99 Algorithms need to be suitable for a wide variety of CPU 100 architectures and device deployments ranging from high end bulk 101 encryption devices to small low-power IoT devices. 103 The algorithm implementation requirements and usage guidance may need 104 to change over time to adapt to the changing world. For this reason, 105 the selection of mandatory-to-implement algorithms was removed from 106 the main IKEv2 specification and placed in a separate document. 108 1.2. Updating Algorithm Requirement Levels 110 The mandatory-to-implement algorithm of tomorrow should already be 111 available in most implementations of AH/ESP by the time it is made 112 mandatory. This document attempts to identify and introduce those 113 algorithms for future mandatory-to-implement status. There is no 114 guarantee that the algorithms in use today may become mandatory in 115 the future. Published algorithms are continuously subjected to 116 cryptographic attack and may become too weak or could become 117 completely broken before this document is updated. 119 This document only provides recommendations for the mandatory-to- 120 implement algorithms or algorithms too weak that are recommended not 121 to be implemented. As a result, any algorithm listed at the IPsec 122 IANA registry not mentioned in this document MAY be implemented. As 123 [RFC7321] omitted most of the algorithms mentioned by the IPsec IANA 124 repository, which makes it difficult to define whether non mentioned 125 algorithms are optional to implement or must not be implemented as 126 they are too weak. This document provides explicit guidance for all 127 of them. It is expected that this document will be updated over time 128 and next versions will only mention algorithms which status has 129 evolved. For clarification when an algorithm has been mentioned in 130 [RFC7321], this document states explicitly the update of the status. 132 Although this document updates the algorithms to keep the AH/ESP 133 communication secure over time, it also aims at providing 134 recommendations so that AH/ESP implementations remain interoperable. 135 AH/ESP interoperability is addressed by an incremental introduction 136 or deprecation of algorithms. In addition, this document also 137 considers the new use cases for AH/ESP deployment, such as Internet 138 of Things (IoT). 140 It is expected that deprecation of an algorithm is performed 141 gradually. This provides time for various implementations to update 142 their implemented algorithms while remaining interoperable. Unless 143 there are strong security reasons, an algorithm is expected to be 144 downgraded from MUST to MUST- or SHOULD, instead of MUST NOT. 146 Similarly, an algorithm that has not been mentioned as mandatory-to- 147 implement is expected to be introduced with a SHOULD instead of a 148 MUST. 150 The current trend toward Internet of Things and its adoption of AH/ 151 ESP requires this specific use case to be taken into account as well. 152 IoT devices are resource constrained devices and their choice of 153 algorithms are motivated by minimizing the footprint of the code, the 154 computation effort and the size of the messages to send. This 155 document indicates "[IoT]" when a specified algorithm is specifically 156 listed for IoT devices. Requirement levels that are marked as "IoT" 157 apply to IoT devices and to server-side implementations that might 158 presumably need to interoperate with them, including any general- 159 purpose VPN gateways. 161 1.3. Document Audience 163 The recommendations of this document mostly target AH/ESP 164 implementers as implementations need to meet both high security 165 expectations as well as high interoperability between various vendors 166 and with different versions. Interoperability requires a smooth move 167 to more secure cipher suites. This may differ from a user point of 168 view that may deploy and configure AH/ESP with only the safest cipher 169 suite. 171 This document does not give any recommendations for the use of 172 algorithms, it only gives implementation recommendations for 173 implementations. The use of algorithms by users is dictated by the 174 security policy requirements for that specific user, and are outside 175 the scope of this document. 177 The algorithms considered here are listed by the IANA as part of the 178 IKEv2 parameters. IKEv1 is out of scope of this document. IKEv1 is 179 deprecated and the recommendations of this document must not be 180 considered for IKEv1, nor IKEv1 parameters be considered by this 181 document. 183 The IANA registry for Internet Key Exchange Version 2 (IKEv2) 184 Parameters contains some entries that are not for use with ESP or AH. 185 This document does not modify the status of those algorithms. 187 2. Requirements Language 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 191 "OPTIONAL" in this document are to be interpreted as described in 192 [RFC2119]. 194 Following [RFC4835], we define some additional key words: 196 MUST- This term means the same as MUST. However, we expect that at 197 some point in the future this algorithm will no longer be a MUST. 198 SHOULD+ This term means the same as SHOULD. However, it is likely 199 that an algorithm marked as SHOULD+ will be promoted at some 200 future time to be a MUST. 202 3. ESP Encryption Algorithms 204 +-------------------------+------------+--------+-------------------+ 205 | Name | Status | AEAD | Comment | 206 +-------------------------+------------+--------+-------------------+ 207 | ENCR_DES_IV64 | MUST NOT | No | UNSPECIFIED | 208 | ENCR_DES | MUST NOT | No | [RFC2405] | 209 | ENCR_3DES | SHOULD NOT | No | [RFC2451] | 210 | ENCR_BLOWFISH | MUST NOT | No | [RFC2451] | 211 | ENCR_3IDEA | MUST NOT | No | UNSPECIFIED | 212 | ENCR_DES_IV32 | MUST NOT | No | UNSPECIFIED | 213 | ENCR_NULL | MUST | No | [RFC2410] | 214 | ENCR_AES_CBC | MUST | No | [RFC3602][1] | 215 | ENCR_AES_CCM_8 | SHOULD | Yes | [RFC4309][1][IoT] | 216 | ENCR_AES_GCM_16 | MUST | Yes | [RFC4106][1] | 217 | ENCR_CHACHA20_POLY1305 | SHOULD | Yes | [RFC7634] | 218 +-------------------------+------------+--------+-------------------+ 220 [1] - This requirement level is for 128-bit keys. 256-bit keys are at 221 SHOULD. 192-bit keys can safely be ignored. [IoT] - This 222 requirement is for interoperability with IoT. 224 IPsec sessions may have very long life time, and carry multiple 225 packets, so there is a need to move 256-bit keys in the long term. 226 For that purpose requirement level is for 128 bit keys and 256 bit 227 keys are at SHOULD (when applicable). In that sense 256 bit keys 228 status has been raised from MAY in RFC7321 to SHOULD. 230 IANA has allocated codes for cryptographic algorithms that have not 231 been specified by the IETF. Such algorithms are noted as 232 UNSPECIFIED. Usually, the use of theses algorithms is limited to 233 specific cases, and the absence of specification makes 234 interoperability difficult for IPsec communications. These 235 algorithms were not been mentioned in [RFC7321] and this document 236 clarify that such algorithms MUST NOT be implemented for IPsec 237 communications. 239 Similarly IANA also allocated code points for algorithms that are not 240 expected to be used to secure IPsec communications. Such algorithms 241 are noted as Non IPsec. As a result, these algorithms MUST NOT be 242 implemented. 244 Various older and not well tested and never widely implemented 245 ciphers have been changed to MUST NOT. 247 ENCR_3DES status has been downgraded from MAY in RFC7321 to SHOULD 248 NOT. ENCR_CHACHA20_POLY1305 is a more modern approach alternative 249 for ENCR_3DES than ENCR_AES_CBC and so it expected to be favored to 250 replace ENCR_3DES. 252 ENCR_BLOWFISH has been downgraded to MUST NOT as it has been 253 deprecated for years by TWOFISH, which is not standarized for ESP and 254 therefor not listed in this document. Some implementations support 255 TWOFISH using a private range number. 257 ENCR_NULL status was set to MUST in [RFC7321] and remains a MUST to 258 enable the use of ESP with only authentication which is preferred 259 over AH due to NAT traversal. ENCR_NULL is expected to remain MUST 260 by protocol requirements. 262 ENCR_AES_CBC status remains to MUST. ENCR_AES_CBC MUST be 263 implemented in order to enable interoperability between 264 implementation that followed RFC7321. However, there is a trend for 265 the industry to move to AEAD encryption, and the overhead of 266 ENCR_AES_CBC remains quite large so it is expected to be replaced by 267 AEAD algorithms in the long term. 269 ENCR_AES_CCM_8 status was set to MAY in [RFC7321] and has been raised 270 from MAY to SHOULD in order to interact with Internet of Things 271 devices. As this case is not a general use case for VPNs, its status 272 is expected to remain as SHOULD. 274 ENCR_AES_GCM_16 status has been updated from SHOULD+ to MUST in order 275 to favor the use of authenticated encryption and AEAD algorithms. 276 ENCR_AES_GCM_16 has been widely implemented for ESP due to its 277 increased performance and key longevity compared to ENCR_AES_CBC. 279 ENCR_CHACHA20_POLY1305 was not ready to be considered at the time of 280 RFC7321. It has been recommended by the CRFG and others as an 281 alternative to ENCR_AES_XCBC and ENCR_AES_GCM_*. It is also being 282 standardized for ESP for the same reasons. At the time of writing, 283 there are not enough ESP implementations of ENCR_CHACHA20_POLY1305 to 284 be able to introduce it at the SHOULD+ level. Its status has been 285 set to SHOULD and is expected to become MUST in the long term. 287 4. ESP and AH Authentication Algorithms 289 Encryption without authentication MUST NOT be used. As a result, 290 authentication algorithm recommendations in this section are 291 targeting two types of communications: Firstly authenticated only 292 communications without encryption. Such communications can be ESP 293 with NULL encryption or AH communications. Secondly, communications 294 that are encrypted with non AEAD encryption algorithms mentioned 295 above. In this case, they MUST be combined with an authentication 296 algorithm. 298 +------------------------+------------------+-----------------------+ 299 | Name | Status | Comment | 300 +------------------------+------------------+-----------------------+ 301 | AUTH_NONE | MUST / MUST NOT | [RFC7296] AEAD | 302 | AUTH_HMAC_MD5_96 | MUST NOT | [RFC2403][RFC7296] | 303 | AUTH_HMAC_SHA1_96 | MUST- | [RFC2404][RFC7296] | 304 | AUTH_DES_MAC | MUST NOT | [UNSPECIFIED] | 305 | AUTH_KPDK_MD5 | MUST NOT | [UNSPECIFIED] | 306 | AUTH_AES_XCBC_96 | SHOULD | [RFC3566][RFC7296] | 307 | | | [IoT] | 308 | AUTH_AES_128_GMAC | MAY | [RFC4543] | 309 | AUTH_AES_256_GMAC | MAY | [RFC4543] | 310 | AUTH_HMAC_SHA2_256_128 | MUST | [RFC4868] | 311 | AUTH_HMAC_SHA2_512_256 | SHOULD | [RFC4868] | 312 +------------------------+------------------+-----------------------+ 314 [IoT] - This requirement is for interoperability with IoT 316 AUTH_NONE has been downgraded from MAY in RFC7321 to MUST NOT. The 317 only reason NULL is acceptable is when authenticated encryption 318 algorithms are selected from Section 3. In all other case, NULL MUST 319 NOT be selected. As ESP and AH provides both authentication, one may 320 be tempted to combine these protocol to provide authentication. As 321 mentioned by RFC7321, it is NOT RECOMMENDED to use ESP with NULL 322 authentication - with non authenticated encryption - in conjunction 323 with AH; some configurations of this combination of services have 324 been shown to be insecure [PD10]. In addition, NULL authentication 325 cannot be combined with ESP NULL encryption. 327 AUTH_HMAC_MD5_96 and AUTH_KPDK_MD5 were not mentioned in RFC7321. As 328 MD5 is known to be vulnerable to collisions, these algorithms MUST 329 NOT be used. 331 AUTH_HMAC_SHA1_96 has been downgraded from MUST in RFC7321 to MUST- 332 as there is an industry-wide trend to deprecate its usage. 334 AUTH_DES_MAC was not mentioned in RFC7321. As DES is known to be 335 vulnerable, it MUST NOT be used. 337 AUTH_AES_XCBC_96 is only recommended in the scope of IoT, as Internet 338 of Things deployments tend to prefer AES based HMAC functions in 339 order to avoid implementing SHA2. For the wide VPN deployment, as it 340 has not been widely adopted, it has been downgraded from SHOULD to 341 MAY. 343 AUTH_AES_128_GMAC status has been downgraded from SHOULD+ to MAY. 344 Along with AUTH_AES_192_GMAC and AUTH_AES_256_GMAC, these algorithms 345 should only be used for AH not for ESP. If using ENCR_NULL, 346 AUTH_HMAC_SHA2_256_128 is recommended for integrity. If using GMAC 347 without authentication, ENCR_NULL_AUTH_AES_GMAC is recommended. 348 Therefore, these ciphers are kept at MAY. 350 AUTH_HMAC_SHA2_256_128 was not mentioned in RFC7321, as no SHA2 based 351 authentication was mentioned. AUTH_HMAC_SHA2_256_128 MUST be 352 implemented in order to replace AUTH_HMAC_SHA1_96. Note that due to 353 a long standing common implementation bug of this algorithm that 354 truncates the hash at 96-bits instead of 128-bits, it is recommended 355 that implementations prefer AUTH_HMAC_SHA2_512_256 over 356 AUTH_HMAC_SHA2_256_128 if they implement AUTH_HMAC_SHA2_512_256. 358 AUTH_HMAC_SHA2_512_256 SHOULD be implemented as a future replacement 359 of AUTH_HMAC_SHA2_256_128 or when stronger security is required. 360 This value has been preferred to AUTH_HMAC_SHA2_384, as the 361 additional overhead of AUTH_HMAC_SHA2_512 is negligible. 363 5. ESP and AH Compression Algorithms 365 +----------------+----------+-------------+ 366 | Name | Status | Comment | 367 +----------------+----------+-------------+ 368 | IPCOMP_OUI | MUST NOT | UNSPECIFIED | 369 | IPCOMP_DEFLATE | MAY | [RFC2393] | 370 | IPCOMP_LZS | MAY | [RFC2395] | 371 | IPCOMP_LZJH | MAY | [RFC3051] | 372 +----------------+----------+-------------+ 374 [IoT] - This requirement is for interoperability with IoT 376 Compression was not mentioned in RFC7321. As it is not widely 377 deployed, it remains optional and at the MAY-level. 379 6. Acknowledgements 381 Some of the wording in this document was adapted from [RFC7321], the 382 document that this one obsoletes, which was written by D. McGrew and 383 P. Hoffman. 385 7. IANA Considerations 387 This document has no IANA actions. 389 8. Security Considerations 391 The security of a system that uses cryptography depends on both the 392 strength of the cryptographic algorithms chosen and the strength of 393 the keys used with those algorithms. The security also depends on 394 the engineering and administration of the protocol used by the system 395 to ensure that there are no non-cryptographic ways to bypass the 396 security of the overall system. 398 This document concerns itself with the selection of cryptographic 399 algorithms for the use of ESP and AH, specifically with the selection 400 of mandatory-to-implement algorithms. The algorithms identified in 401 this document as "MUST implement" or "SHOULD implement" are not known 402 to be broken at the current time, and cryptographic research to date 403 leads us to believe that they will likely remain secure into the 404 foreseeable future. However, this is not necessarily forever. 405 Therefore, we expect that revisions of that document will be issued 406 from time to time to reflect the current best practice in this area. 408 9. References 410 9.1. Normative References 412 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 413 Requirement Levels", BCP 14, RFC 2119, 414 DOI 10.17487/RFC2119, March 1997, 415 . 417 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 418 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 419 December 2005, . 421 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 422 DOI 10.17487/RFC4302, December 2005, 423 . 425 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 426 RFC 4303, DOI 10.17487/RFC4303, December 2005, 427 . 429 [RFC7321] McGrew, D. and P. Hoffman, "Cryptographic Algorithm 430 Implementation Requirements and Usage Guidance for 431 Encapsulating Security Payload (ESP) and Authentication 432 Header (AH)", RFC 7321, DOI 10.17487/RFC7321, August 2014, 433 . 435 [RFC7634] Nir, Y., "ChaCha20, Poly1305, and Their Use in the 436 Internet Key Exchange Protocol (IKE) and IPsec", RFC 7634, 437 DOI 10.17487/RFC7634, August 2015, 438 . 440 9.2. Informative References 442 [PD10] Paterson, K. and J. Degabriele, "On the (in)security of 443 IPsec in MAC-then-encrypt configurations (ACM Conference 444 on Computer and Communications Security, ACM CCS)", 2010. 446 [RFC2393] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP 447 Payload Compression Protocol (IPComp)", RFC 2393, 448 DOI 10.17487/RFC2393, December 1998, 449 . 451 [RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using 452 LZS", RFC 2395, DOI 10.17487/RFC2395, December 1998, 453 . 455 [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within 456 ESP and AH", RFC 2403, DOI 10.17487/RFC2403, November 457 1998, . 459 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 460 ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November 461 1998, . 463 [RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher 464 Algorithm With Explicit IV", RFC 2405, 465 DOI 10.17487/RFC2405, November 1998, 466 . 468 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 469 Its Use With IPsec", RFC 2410, DOI 10.17487/RFC2410, 470 November 1998, . 472 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 473 Algorithms", RFC 2451, DOI 10.17487/RFC2451, November 474 1998, . 476 [RFC3051] Heath, J. and J. Border, "IP Payload Compression Using 477 ITU-T V.44 Packet Method", RFC 3051, DOI 10.17487/RFC3051, 478 January 2001, . 480 [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm 481 and Its Use With IPsec", RFC 3566, DOI 10.17487/RFC3566, 482 September 2003, . 484 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 485 Algorithm and Its Use with IPsec", RFC 3602, 486 DOI 10.17487/RFC3602, September 2003, 487 . 489 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 490 (GCM) in IPsec Encapsulating Security Payload (ESP)", 491 RFC 4106, DOI 10.17487/RFC4106, June 2005, 492 . 494 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 495 Mode with IPsec Encapsulating Security Payload (ESP)", 496 RFC 4309, DOI 10.17487/RFC4309, December 2005, 497 . 499 [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message 500 Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, 501 DOI 10.17487/RFC4543, May 2006, 502 . 504 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 505 Requirements for Encapsulating Security Payload (ESP) and 506 Authentication Header (AH)", RFC 4835, 507 DOI 10.17487/RFC4835, April 2007, 508 . 510 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 511 384, and HMAC-SHA-512 with IPsec", RFC 4868, 512 DOI 10.17487/RFC4868, May 2007, 513 . 515 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 516 Kivinen, "Internet Key Exchange Protocol Version 2 517 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 518 2014, . 520 Authors' Addresses 522 Daniel Migault 523 Ericsson 524 8400 boulevard Decarie 525 Montreal, QC H4P 2N2 526 Canada 528 Phone: +1 514-452-2160 529 Email: daniel.migault@ericsson.com 531 John Mattsson 532 Ericsson AB 533 SE-164 80 Stockholm 534 Sweden 536 Email: john.mattsson@ericsson.com 538 Paul Wouters 539 Red Hat 541 Email: pwouters@redhat.com 543 Yoav Nir 544 Check Point Software Technologies Ltd. 545 5 Hasolelim st. 546 Tel Aviv 6789735 547 Israel 549 Email: ynir.ietf@gmail.com 551 Tero Kivinen 552 INSIDE Secure 553 Eerikinkatu 28 554 HELSINKI FI-00180 555 FI 557 Email: kivinen@iki.fi