--- 1/draft-mglt-ipsecme-rfc7321bis-03.txt 2016-09-09 15:18:53.297720725 -0700 +++ 2/draft-mglt-ipsecme-rfc7321bis-04.txt 2016-09-09 15:18:53.329721536 -0700 @@ -1,25 +1,25 @@ Network Working Group D. Migault Internet-Draft J. Mattsson Obsoletes: 7321 (if approved) Ericsson Intended status: Standards Track P. Wouters -Expires: March 5, 2017 Red Hat +Expires: March 13, 2017 Red Hat Y. Nir Check Point T. Kivinen INSIDE Secure - September 1, 2016 + September 9, 2016 Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) - draft-mglt-ipsecme-rfc7321bis-03 + draft-mglt-ipsecme-rfc7321bis-04 Abstract This document updates the Cryptographic Algorithm Implementation Requirements for ESP and AH. The goal of these document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable. This document obsoletes RFC 7321 on the cryptographic recommendations only. @@ -32,21 +32,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 5, 2017. + This Internet-Draft will expire on March 13, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -60,26 +60,27 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Updating Algorithm Implementation Requirements and Usage Guidance . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3 1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. ESP Encryption Algorithms . . . . . . . . . . . . . . . . . . 5 4. ESP and AH Authentication Algorithms . . . . . . . . . . . . 7 5. ESP and AH Compression Algorithms . . . . . . . . . . . . . . 8 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 - 9.2. Informative References . . . . . . . . . . . . . . . . . 10 + 6. Summary of Changes from RFC 7321 . . . . . . . . . . . . . . 9 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 + 10.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction The Encapsulating Security Payload (ESP) [RFC4303] and the Authentication Header (AH) [RFC4302] are the mechanisms for applying cryptographic protection to data being sent over an IPsec Security Association (SA) [RFC4301]. This document provides guidance and recommendations so that ESP and @@ -370,31 +370,53 @@ | IPCOMP_DEFLATE | MAY | [RFC2393] | | IPCOMP_LZS | MAY | [RFC2395] | | IPCOMP_LZJH | MAY | [RFC3051] | +----------------+----------+-------------+ [IoT] - This requirement is for interoperability with IoT Compression was not mentioned in RFC7321. As it is not widely deployed, it remains optional and at the MAY-level. -6. Acknowledgements +6. Summary of Changes from RFC 7321 + + The following table summarizes the changes from RFC 7321. + + RFC EDITOR: PLEASE REMOVE THIS PARAGRAPH AND REPLACE XXXX IN THE + TABLE BELOW WITH THE NUMBER OF THIS RFC + + +-------------------+----------+-----------------+ + | Algorithm | RFC 7321 | RFC XXXX | + +-------------------+----------+-----------------+ + | ENCR_AES_GCM_16 | SHOULD+ | MUST | + | ENCR_AES_CCM_8 | MAY | SHOULD | + | ENCR_AES_CTR | MAY | (*) | + | ENCR_3DES | MAY | SHOULD NOT | + | AUTH_HMAC_SHA1_96 | MUST | MUST- | + | AUTH_AES_128_GMAC | SHOULD+ | MAY | + | AUTH_NONE | MAY | MUST / MUST NOT | + +-------------------+----------+-----------------+ + + (*) This algorithm is not mentioned in the above sections, so it + defaults to MAY. + +7. Acknowledgements Some of the wording in this document was adapted from [RFC7321], the document that this one obsoletes, which was written by D. McGrew and P. Hoffman. -7. IANA Considerations +8. IANA Considerations This document has no IANA actions. -8. Security Considerations +9. Security Considerations The security of a system that uses cryptography depends on both the strength of the cryptographic algorithms chosen and the strength of the keys used with those algorithms. The security also depends on the engineering and administration of the protocol used by the system to ensure that there are no non-cryptographic ways to bypass the security of the overall system. This document concerns itself with the selection of cryptographic algorithms for the use of ESP and AH, specifically with the selection @@ -396,26 +418,27 @@ to ensure that there are no non-cryptographic ways to bypass the security of the overall system. This document concerns itself with the selection of cryptographic algorithms for the use of ESP and AH, specifically with the selection of mandatory-to-implement algorithms. The algorithms identified in this document as "MUST implement" or "SHOULD implement" are not known to be broken at the current time, and cryptographic research to date leads us to believe that they will likely remain secure into the foreseeable future. However, this is not necessarily forever. + Therefore, we expect that revisions of that document will be issued from time to time to reflect the current best practice in this area. -9. References +10. References -9.1. Normative References +10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . @@ -431,21 +454,21 @@ Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 7321, DOI 10.17487/RFC7321, August 2014, . [RFC7634] Nir, Y., "ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec", RFC 7634, DOI 10.17487/RFC7634, August 2015, . -9.2. Informative References +10.2. Informative References [PD10] Paterson, K. and J. Degabriele, "On the (in)security of IPsec in MAC-then-encrypt configurations (ACM Conference on Computer and Communications Security, ACM CCS)", 2010. [RFC2393] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 2393, DOI 10.17487/RFC2393, December 1998, .