idnits 2.17.1 draft-ietf-ipsecme-rfc7321bis-06.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 (June 19, 2017) is 2502 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 275 == Missing Reference: 'UNSPECIFIED' is mentioned on line 359, but not defined ** Obsolete normative reference: RFC 7321 (Obsoleted by RFC 8221) -- Obsolete informational reference (is this intentional?): RFC 2393 (Obsoleted by RFC 3173) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Wouters 3 Internet-Draft Red Hat 4 Obsoletes: 7321 (if approved) D. Migault 5 Intended status: Standards Track J. Mattsson 6 Expires: December 21, 2017 Ericsson 7 Y. Nir 8 Check Point 9 T. Kivinen 10 INSIDE Secure 11 June 19, 2017 13 Cryptographic Algorithm Implementation Requirements and Usage Guidance 14 for Encapsulating Security Payload (ESP) and Authentication Header (AH) 15 draft-ietf-ipsecme-rfc7321bis-06 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. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 21, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Updating Algorithm Implementation Requirements and Usage 62 Guidance . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3 64 1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4 65 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 66 3. Manual Keying . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Encryption must be Authenticated . . . . . . . . . . . . . . 5 68 5. ESP Encryption Algorithms . . . . . . . . . . . . . . . . . . 6 69 6. ESP and AH Authentication Algorithms . . . . . . . . . . . . 8 70 7. ESP and AH Compression Algorithms . . . . . . . . . . . . . . 9 71 8. Summary of Changes from RFC 7321 . . . . . . . . . . . . . . 10 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 73 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 77 12.2. Informative References . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 The Encapsulating Security Payload (ESP) [RFC4303] and the 83 Authentication Header (AH) [RFC4302] are the mechanisms for applying 84 cryptographic protection to data being sent over an IPsec Security 85 Association (SA) [RFC4301]. 87 This document provides guidance and recommendations so that ESP and 88 AH can be used with a cryptographic algorithms that are up to date. 89 The challenge of such document is to make sure that over the time 90 IPsec implementations can use secure and up-to-date cryptographic 91 algorithms while keeping IPsec interoperable. 93 1.1. Updating Algorithm Implementation Requirements and Usage Guidance 95 The field of cryptography evolves continuously. New stronger 96 algorithms appear and existing algorithms are found to be less secure 97 than originally thought. Therefore, algorithm implementation 98 requirements and usage guidance need to be updated from time to time 99 to reflect the new reality. The choices for algorithms must be 100 conservative to minimize the risk of algorithm compromise. 101 Algorithms need to be suitable for a wide variety of CPU 102 architectures and device deployments ranging from high end bulk 103 encryption devices to small low-power IoT devices. 105 The algorithm implementation requirements and usage guidance may need 106 to change over time to adapt to the changing world. For this reason, 107 the selection of mandatory-to-implement algorithms was removed from 108 the main IKEv2 specification and placed in a separate document. 110 1.2. Updating Algorithm Requirement Levels 112 The mandatory-to-implement algorithm of tomorrow should already be 113 available in most implementations of AH/ESP by the time it is made 114 mandatory. This document attempts to identify and introduce those 115 algorithms for future mandatory-to-implement status. There is no 116 guarantee that the algorithms in use today may become mandatory in 117 the future. Published algorithms are continuously subjected to 118 cryptographic attack and may become too weak or could become 119 completely broken before this document is updated. 121 This document only provides recommendations for the mandatory-to- 122 implement algorithms and algorithms too weak that are recommended not 123 to be implemented. As a result, any algorithm listed at the IPsec 124 IANA registry not mentioned in this document MAY be implemented. It 125 is expected that this document will be updated over time and next 126 versions will only mention algorithms which status has evolved. For 127 clarification when an algorithm has been mentioned in [RFC7321], this 128 document states explicitly the update of the status. 130 Although this document updates the algorithms to keep the AH/ESP 131 communication secure over time, it also aims at providing 132 recommendations so that AH/ESP implementations remain interoperable. 133 AH/ESP interoperability is addressed by an incremental introduction 134 or deprecation of algorithms. In addition, this document also 135 considers the new use cases for AH/ESP deployment, such as Internet 136 of Things (IoT). 138 It is expected that deprecation of an algorithm is performed 139 gradually. This provides time for various implementations to update 140 their implemented algorithms while remaining interoperable. Unless 141 there are strong security reasons, an algorithm is expected to be 142 downgraded from MUST to MUST- or SHOULD, instead of MUST NOT. 143 Similarly, an algorithm that has not been mentioned as mandatory-to- 144 implement is expected to be introduced with a SHOULD instead of a 145 MUST. 147 The current trend toward Internet of Things and its adoption of AH/ 148 ESP requires this specific use case to be taken into account as well. 149 IoT devices are resource constrained devices and their choice of 150 algorithms are motivated by minimizing the footprint of the code, the 151 computation effort and the size of the messages to send. This 152 document indicates "(IoT)" when a specified algorithm is specifically 153 listed for IoT devices. Requirement levels that are marked as "IoT" 154 apply to IoT devices and to server-side implementations that might 155 presumably need to interoperate with them, including any general- 156 purpose VPN gateways. 158 1.3. Document Audience 160 The recommendations of this document mostly target AH/ESP 161 implementers as implementations need to meet both high security 162 expectations as well as high interoperability between various vendors 163 and with different versions. Interoperability requires a smooth move 164 to more secure cipher suites. This may differ from a user point of 165 view that may deploy and configure AH/ESP with only the safest cipher 166 suite. 168 This document does not give any recommendations for the use of 169 algorithms, it only gives implementation recommendations for 170 implementations. The use of algorithms by users is dictated by the 171 security policy requirements for that specific user, and are outside 172 the scope of this document. 174 The algorithms considered here are listed by the IANA as part of the 175 IKEv2 parameters. IKEv1 is out of scope of this document. IKEv1 is 176 deprecated and the recommendations of this document must not be 177 considered for IKEv1, nor IKEv1 parameters be considered by this 178 document. 180 The IANA registry for Internet Key Exchange Version 2 (IKEv2) 181 Parameters contains some entries that are not for use with ESP or AH. 182 This document does not modify the status of those algorithms. 184 2. Requirements Language 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 188 "OPTIONAL" in this document are to be interpreted as described in 189 [RFC2119]. 191 We define some additional terms here: 193 SHOULD+ This term means the same as SHOULD. However, it is likely 194 that an algorithm marked as SHOULD+ will be promoted at 195 some future time to be a MUST. 196 SHOULD- This term means the same as SHOULD. However, an algorithm 197 marked as SHOULD- may be deprecated to a MAY in a future 198 version of this document. 199 MUST- This term means the same as MUST. However, we expect at 200 some point that this algorithm will no longer be a MUST in 201 a future document. Although its status will be determined 202 at a later time, it is reasonable to expect that if a 203 future revision of a document alters the status of a MUST- 204 algorithm, it will remain at least a SHOULD or a SHOULD- 205 level. 206 IoT stands for Internet of Things. 208 3. Manual Keying 210 Manual Keying SHOULD NOT be used as it is inherently dangerous. 211 Without any secure keying protocol such a IKE, IPsec does not offer 212 Perfect Forward Secrecy ("PFS") protection and there is no entity to 213 ensure refreshing of session keys, tracking SPI uniqueness and 214 ensuring nonces, IVs and counters are never re-used. This document 215 was written for deploying ESP/AH using IKE ([RFC7296]) and assumes 216 that keying happens using IKE version 2 or higher. 218 If Manual Keying is used regardless, Counter Mode algorithms such as 219 ENCR_AES_CTR, ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 220 MUST NOT be used as it is incompatible with a secure and persistent 221 handling of the counter, as explained in the Security Considerations 222 Section of [RFC3686]. This particularly applies to IoT devices that 223 have no state across reboots. As of publication date of this 224 document, ENCR_AES_CBC is the only Mandatory-To-Implement encryption 225 algorithm suitable for Manual Keying. 227 4. Encryption must be Authenticated 229 Encryption without authentication is not effective and MUST NOT be 230 used. IPsec offers three ways to provide both encryption and 231 authentication: 233 o ESP with an AEAD cipher 234 o ESP with a non-AEAD cipher + authentication 235 o ESP with a non-AEAD cipher + AH with authentication 236 The fastest and most modern method is to use ESP with a combined mode 237 cipher such as an AEAD cipher that handles encryption/decryption and 238 authentication in a single step. In this case, the AEAD cipher is 239 set as the encryption algorithm and the authentication algorithm is 240 set to none. Examples of this are ENCR_AES_GCM_16 and 241 ENCR_CHACHA20_POLY1305. 243 A more traditional approach is to use ESP with an encryption and an 244 authentication algorithm. This approach is slower, as the data has 245 to be processed twice, once for encryption/decryption and once for 246 authentication. An example of this is ENCR_AES_CBC combined with 247 AUTH_HMAC_SHA2_512_256. 249 The last method that can be used is ESP+AH. This method is NOT 250 RECOMMENDED. It is the slowest method and also takes up more octets 251 due to the double header of ESP+AH, resulting in a smaller effective 252 MTU for the encrypted data. With this method, ESP is only used for 253 confidentiality without an authentication algorithm and a second 254 IPsec protocol of type AH is used for authentication. An example of 255 this is ESP with ENCR_AES_CBC with AH with AUTH_HMAC_SHA2_512_256. 257 5. ESP Encryption Algorithms 259 +-------------------------+-------------+---------+--------------+ 260 | Name | Status | AEAD | Comment | 261 +-------------------------+-------------+---------+--------------+ 262 | ENCR_DES_IV64 | MUST NOT | No | UNSPECIFIED | 263 | ENCR_DES | MUST NOT | No | [RFC2405] | 264 | ENCR_3DES | SHOULD NOT | No | [RFC2451] | 265 | ENCR_BLOWFISH | MUST NOT | No | [RFC2451] | 266 | ENCR_3IDEA | MUST NOT | No | UNSPECIFIED | 267 | ENCR_DES_IV32 | MUST NOT | No | UNSPECIFIED | 268 | ENCR_NULL | MUST | No | [RFC2410] | 269 | ENCR_AES_CBC | MUST | No | [RFC3602][1] | 270 | ENCR_AES_CCM_8 | SHOULD(IoT) | Yes | [RFC4309] | 271 | ENCR_AES_GCM_16 | MUST | Yes | [RFC4106][1] | 272 | ENCR_CHACHA20_POLY1305 | SHOULD | Yes | [RFC7634] | 273 +-------------------------+-------------+---------+--------------+ 275 [1] - This requirement level is for 128-bit and 256-bit keys. 276 192-bit keys remain at MAY level. (IoT) - This requirement is for 277 interoperability with IoT. Only 128-bit keys are at the given level. 279 IPsec sessions may have very long life time, and carry multiple 280 packets, so there is a need to move to 256-bit keys in the long term. 281 For that purpose the requirement level for 128 bit keys and 256 bit 282 keys are at MUST (when applicable). In that sense 256 bit keys 283 status has been raised from MAY in RFC7321 to MUST. 285 IANA has allocated codes for cryptographic algorithms that have not 286 been specified by the IETF. Such algorithms are noted as 287 UNSPECIFIED. Usually, the use of theses algorithms is limited to 288 specific cases, and the absence of specification makes 289 interoperability difficult for IPsec communications. These 290 algorithms were not been mentioned in [RFC7321] and this document 291 clarify that such algorithms MUST NOT be implemented for IPsec 292 communications. 294 Similarly IANA also allocated code points for algorithms that are not 295 expected to be used to secure IPsec communications. Such algorithms 296 are noted as Non IPsec. As a result, these algorithms MUST NOT be 297 implemented. 299 Various older and not well tested and never widely implemented 300 ciphers have been changed to MUST NOT. 302 ENCR_3DES status has been downgraded from MAY in RFC7321 to SHOULD 303 NOT. ENCR_CHACHA20_POLY1305 is a more modern approach alternative 304 for ENCR_3DES than ENCR_AES_CBC and so it expected to be favored to 305 replace ENCR_3DES. 307 ENCR_BLOWFISH has been downgraded to MUST NOT as it has been 308 deprecated for years by TWOFISH, which is not standarized for ESP and 309 therefore not listed in this document. Some implementations support 310 TWOFISH using a private range number. 312 ENCR_NULL status was set to MUST in [RFC7321] and remains a MUST to 313 enable the use of ESP with only authentication which is preferred 314 over AH due to NAT traversal. ENCR_NULL is expected to remain MUST 315 by protocol requirements. 317 ENCR_AES_CBC status remains at MUST. ENCR_AES_CBC MUST be 318 implemented in order to enable interoperability between 319 implementations that followed RFC7321. However, there is a trend for 320 the industry to move to AEAD encryption, and the overhead of 321 ENCR_AES_CBC remains quite large so it is expected to be replaced by 322 AEAD algorithms in the long term. 324 ENCR_AES_CCM_8 status was set to MAY in [RFC7321] and has been raised 325 from MAY to SHOULD in order to interact with Internet of Things 326 devices. As this case is not a general use case for VPNs, its status 327 is expected to remain as SHOULD. 329 ENCR_AES_GCM_16 status has been updated from SHOULD+ to MUST in order 330 to favor the use of authenticated encryption and AEAD algorithms. 331 ENCR_AES_GCM_16 has been widely implemented for ESP due to its 332 increased performance and key longevity compared to ENCR_AES_CBC. 334 ENCR_CHACHA20_POLY1305 was not ready to be considered at the time of 335 RFC7321. It has been recommended by the CRFG and others as an 336 alternative to AES-CBC and AES-GCM. It is also being standardized 337 for ESP for the same reasons. At the time of writing, there are not 338 enough ESP implementations of ENCR_CHACHA20_POLY1305 to be able to 339 introduce it at the SHOULD+ level. Its status has been set to SHOULD 340 and is expected to become MUST in the long term. 342 6. ESP and AH Authentication Algorithms 344 Authentication algorithm recommendations in this section are 345 targeting two types of communications: 347 o Authenticated only communications without encryption, such as ESP 348 with NULL encryption or AH communications. 349 o Communications that are encrypted with non-AEAD algorithm which 350 MUST be combined with an authentication algorithm. 352 +------------------------+------------------+-----------------------+ 353 | Name | Status | Comment | 354 +------------------------+------------------+-----------------------+ 355 | AUTH_NONE | MUST / MUST NOT | [RFC7296] AEAD | 356 | AUTH_HMAC_MD5_96 | MUST NOT | [RFC2403][RFC7296] | 357 | AUTH_HMAC_SHA1_96 | MUST- | [RFC2404][RFC7296] | 358 | AUTH_DES_MAC | MUST NOT | [UNSPECIFIED] | 359 | AUTH_KPDK_MD5 | MUST NOT | [UNSPECIFIED] | 360 | AUTH_AES_XCBC_96 | SHOULD | [RFC3566][RFC7296] | 361 | | | (IoT) | 362 | AUTH_AES_128_GMAC | MAY | [RFC4543] | 363 | AUTH_AES_256_GMAC | MAY | [RFC4543] | 364 | AUTH_HMAC_SHA2_256_128 | MUST | [RFC4868] | 365 | AUTH_HMAC_SHA2_512_256 | SHOULD | [RFC4868] | 366 +------------------------+------------------+-----------------------+ 368 (IoT) - This requirement is for interoperability with IoT 370 AUTH_NONE has been downgraded from MAY in RFC7321 to MUST NOT. The 371 only case where AUTH_NONE is acceptable is when authenticated 372 encryption algorithms are selected from Section 5. In all other 373 cases, AUTH_NONE MUST NOT be selected. As ESP and AH both provide 374 authentication, one may be tempted to combine these protocols to 375 provide authentication. As mentioned by RFC7321, it is NOT 376 RECOMMENDED to use ESP with NULL authentication - with non 377 authenticated encryption - in conjunction with AH; some 378 configurations of this combination of services have been shown to be 379 insecure [PD10]. In addition, AUTH_NONE authentication cannot be 380 combined with ESP NULL encryption. 382 AUTH_HMAC_MD5_96 and AUTH_KPDK_MD5 were not mentioned in RFC7321. As 383 MD5 is known to be vulnerable to collisions, these algorithms MUST 384 NOT be used. 386 AUTH_HMAC_SHA1_96 has been downgraded from MUST in RFC7321 to MUST- 387 as there is an industry-wide trend to deprecate its usage. 389 AUTH_DES_MAC was not mentioned in RFC7321. As DES is known to be 390 vulnerable, it MUST NOT be used. 392 AUTH_AES_XCBC_96 is set as SHOULD only in the scope of IoT, as 393 Internet of Things deployments tend to prefer AES based HMAC 394 functions in order to avoid implementing SHA2. For the wide VPN 395 deployment, as it has not been widely adopted, it has been downgraded 396 from SHOULD to MAY. 398 AUTH_AES_128_GMAC status has been downgraded from SHOULD+ to MAY. 399 Along with AUTH_AES_192_GMAC and AUTH_AES_256_GMAC, these algorithms 400 should only be used for AH and not for ESP. If using ENCR_NULL, 401 AUTH_HMAC_SHA2_256_128 is recommended for integrity. If using AES- 402 GMAC in ESP without authentication, ENCR_NULL_AUTH_AES_GMAC is 403 recommended. Therefore, these ciphers are kept at MAY. 405 AUTH_HMAC_SHA2_256_128 was not mentioned in RFC7321, as no SHA2 based 406 authentication was mentioned. AUTH_HMAC_SHA2_256_128 MUST be 407 implemented in order to replace AUTH_HMAC_SHA1_96. Note that due to 408 a long standing common implementation bug of this algorithm that 409 truncates the hash at 96-bits instead of 128-bits, it is recommended 410 that implementations prefer AUTH_HMAC_SHA2_512_256 over 411 AUTH_HMAC_SHA2_256_128 if they implement AUTH_HMAC_SHA2_512_256. 413 AUTH_HMAC_SHA2_512_256 SHOULD be implemented as a future replacement 414 of AUTH_HMAC_SHA2_256_128 or when stronger security is required. 415 This value has been preferred to AUTH_HMAC_SHA2_384, as the 416 additional overhead of AUTH_HMAC_SHA2_512 is negligible. 418 7. ESP and AH Compression Algorithms 420 +----------------+----------+-------------+ 421 | Name | Status | Comment | 422 +----------------+----------+-------------+ 423 | IPCOMP_OUI | MUST NOT | UNSPECIFIED | 424 | IPCOMP_DEFLATE | MAY | [RFC2393] | 425 | IPCOMP_LZS | MAY | [RFC2395] | 426 | IPCOMP_LZJH | MAY | [RFC3051] | 427 +----------------+----------+-------------+ 429 (IoT) - This requirement is for interoperability with IoT 431 Compression was not mentioned in RFC7321. As it is not widely 432 deployed, it remains optional and at the MAY-level. 434 8. Summary of Changes from RFC 7321 436 The following table summarizes the changes from RFC 7321. 438 RFC EDITOR: PLEASE REMOVE THIS PARAGRAPH AND REPLACE XXXX IN THE 439 TABLE BELOW WITH THE NUMBER OF THIS RFC 441 +-------------------+----------+-----------------+ 442 | Algorithm | RFC 7321 | RFC XXXX | 443 +-------------------+----------+-----------------+ 444 | ENCR_AES_GCM_16 | SHOULD+ | MUST | 445 | ENCR_AES_CCM_8 | MAY | SHOULD | 446 | ENCR_AES_CTR | MAY | (*) | 447 | ENCR_3DES | MAY | SHOULD NOT | 448 | AUTH_HMAC_SHA1_96 | MUST | MUST- | 449 | AUTH_AES_128_GMAC | SHOULD+ | MAY | 450 | AUTH_NONE | MAY | MUST / MUST NOT | 451 +-------------------+----------+-----------------+ 453 (*) This algorithm is not mentioned in the above sections, so it 454 defaults to MAY. 456 9. Acknowledgements 458 Some of the wording in this document was adapted from [RFC7321], the 459 document that this one obsoletes, which was written by D. McGrew and 460 P. Hoffman. 462 10. IANA Considerations 464 This document has no IANA actions. 466 11. Security Considerations 468 The security of a system that uses cryptography depends on both the 469 strength of the cryptographic algorithms chosen and the strength of 470 the keys used with those algorithms. The security also depends on 471 the engineering and administration of the protocol used by the system 472 to ensure that there are no non-cryptographic ways to bypass the 473 security of the overall system. 475 This document concerns itself with the selection of cryptographic 476 algorithms for the use of ESP and AH, specifically with the selection 477 of mandatory-to-implement algorithms. The algorithms identified in 478 this document as "MUST implement" or "SHOULD implement" are not known 479 to be broken at the current time, and cryptographic research to date 480 leads us to believe that they will likely remain secure into the 481 foreseeable future. However, this is not necessarily forever. 482 Therefore, we expect that revisions of that document will be issued 483 from time to time to reflect the current best practice in this area. 485 12. References 487 12.1. Normative References 489 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 490 Requirement Levels", BCP 14, RFC 2119, 491 DOI 10.17487/RFC2119, March 1997, 492 . 494 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 495 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 496 December 2005, . 498 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 499 DOI 10.17487/RFC4302, December 2005, 500 . 502 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 503 RFC 4303, DOI 10.17487/RFC4303, December 2005, 504 . 506 [RFC7321] McGrew, D. and P. Hoffman, "Cryptographic Algorithm 507 Implementation Requirements and Usage Guidance for 508 Encapsulating Security Payload (ESP) and Authentication 509 Header (AH)", RFC 7321, DOI 10.17487/RFC7321, August 2014, 510 . 512 12.2. Informative References 514 [PD10] Paterson, K. and J. Degabriele, "On the (in)security of 515 IPsec in MAC-then-encrypt configurations (ACM Conference 516 on Computer and Communications Security, ACM CCS)", 2010. 518 [RFC2393] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP 519 Payload Compression Protocol (IPComp)", RFC 2393, 520 DOI 10.17487/RFC2393, December 1998, 521 . 523 [RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using 524 LZS", RFC 2395, DOI 10.17487/RFC2395, December 1998, 525 . 527 [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within 528 ESP and AH", RFC 2403, DOI 10.17487/RFC2403, November 529 1998, . 531 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 532 ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November 533 1998, . 535 [RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher 536 Algorithm With Explicit IV", RFC 2405, 537 DOI 10.17487/RFC2405, November 1998, 538 . 540 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 541 Its Use With IPsec", RFC 2410, DOI 10.17487/RFC2410, 542 November 1998, . 544 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 545 Algorithms", RFC 2451, DOI 10.17487/RFC2451, November 546 1998, . 548 [RFC3051] Heath, J. and J. Border, "IP Payload Compression Using 549 ITU-T V.44 Packet Method", RFC 3051, DOI 10.17487/RFC3051, 550 January 2001, . 552 [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm 553 and Its Use With IPsec", RFC 3566, DOI 10.17487/RFC3566, 554 September 2003, . 556 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 557 Algorithm and Its Use with IPsec", RFC 3602, 558 DOI 10.17487/RFC3602, September 2003, 559 . 561 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 562 Counter Mode With IPsec Encapsulating Security Payload 563 (ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004, 564 . 566 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 567 (GCM) in IPsec Encapsulating Security Payload (ESP)", 568 RFC 4106, DOI 10.17487/RFC4106, June 2005, 569 . 571 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 572 Mode with IPsec Encapsulating Security Payload (ESP)", 573 RFC 4309, DOI 10.17487/RFC4309, December 2005, 574 . 576 [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message 577 Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, 578 DOI 10.17487/RFC4543, May 2006, 579 . 581 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 582 384, and HMAC-SHA-512 with IPsec", RFC 4868, 583 DOI 10.17487/RFC4868, May 2007, 584 . 586 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 587 Kivinen, "Internet Key Exchange Protocol Version 2 588 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 589 2014, . 591 [RFC7634] Nir, Y., "ChaCha20, Poly1305, and Their Use in the 592 Internet Key Exchange Protocol (IKE) and IPsec", RFC 7634, 593 DOI 10.17487/RFC7634, August 2015, 594 . 596 Authors' Addresses 598 Paul Wouters 599 Red Hat 601 Email: pwouters@redhat.com 603 Daniel Migault 604 Ericsson 605 8400 boulevard Decarie 606 Montreal, QC H4P 2N2 607 Canada 609 Phone: +1 514-452-2160 610 Email: daniel.migault@ericsson.com 612 John Mattsson 613 Ericsson AB 614 SE-164 80 Stockholm 615 Sweden 617 Email: john.mattsson@ericsson.com 618 Yoav Nir 619 Check Point Software Technologies Ltd. 620 5 Hasolelim st. 621 Tel Aviv 6789735 622 Israel 624 Email: ynir.ietf@gmail.com 626 Tero Kivinen 627 INSIDE Secure 628 Eerikinkatu 28 629 HELSINKI FI-00180 630 FI 632 Email: kivinen@iki.fi