--- 1/draft-ietf-ipsecme-rfc7321bis-03.txt 2017-02-15 11:13:11.581985285 -0800 +++ 2/draft-ietf-ipsecme-rfc7321bis-04.txt 2017-02-15 11:13:11.613986049 -0800 @@ -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: August 06, 2017 Red Hat +Expires: August 19, 2017 Red Hat Y. Nir Check Point T. Kivinen INSIDE Secure - February 02, 2017 + February 15, 2017 Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) - draft-ietf-ipsecme-rfc7321bis-03 + draft-ietf-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 August 06, 2017. + This Internet-Draft will expire on August 19, 2017. Copyright Notice Copyright (c) 2017 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 @@ -56,31 +56,31 @@ the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Updating Algorithm Implementation Requirements and Usage Guidance . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3 1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4 - 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 + 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Manual Keying . . . . . . . . . . . . . . . . . . . . . . . . 5 4. ESP Encryption Algorithms . . . . . . . . . . . . . . . . . . 5 5. ESP and AH Authentication Algorithms . . . . . . . . . . . . 7 6. ESP and AH Compression Algorithms . . . . . . . . . . . . . . 9 7. Summary of Changes from RFC 7321 . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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]. @@ -184,36 +184,34 @@ 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. We define some additional terms here: SHOULD+ This term means the same as SHOULD. However, it is likely - that an algorithm marked as SHOULD+ will be promoted at some - future time to be a MUST. + that an algorithm marked as SHOULD+ will be promoted at + some future time to be a MUST. SHOULD- This term means the same as SHOULD. However, an algorithm marked as SHOULD- may be deprecated to a MAY in a future version of this document. - MUST- This term means the same as MUST. However, we expect at some - point that this algorithm will no longer be a MUST in a - future document. Although its status will be determined at a - later time, it is reasonable to expect that if a future - revision of a document alters the status of a MUST- + MUST- This term means the same as MUST. However, we expect at + some point that this algorithm will no longer be a MUST in + a future document. Although its status will be determined + at a later time, it is reasonable to expect that if a + future revision of a document alters the status of a MUST- algorithm, it will remain at least a SHOULD or a SHOULD- level. IoT stands for Internet of Things. - Table 1 - 3. Manual Keying Manual Keying is not to be used as it is inherently dangerous. Without any keying protocol, it does not offer Perfect Forward Secrecy ("PFS") protection. Deployments tend to never be reconfigured with fresh session keys. It also fails to scale and keeping SPI's unique amongst many servers is impractical. This document was written for deploying ESP/AH using IKE ([RFC7296]) and assumes that keying happens using IKEv2. @@ -236,22 +233,20 @@ | ENCR_AES_CBC | MUST | No | [RFC3602][1] | | ENCR_AES_CCM_8 | SHOULD(IoT) | Yes | [RFC4309] | | ENCR_AES_GCM_16 | MUST | Yes | [RFC4106][1] | | ENCR_CHACHA20_POLY1305 | SHOULD | Yes | [RFC7634] | +-------------------------+-------------+---------+--------------+ [1] - This requirement level is for 128-bit and 256-bit keys. 192-bit keys remain at MAY level. (IoT) - This requirement is for interoperability with IoT. Only 128-bit keys are at the given level. - Table 2 - IPsec sessions may have very long life time, and carry multiple packets, so there is a need to move to 256-bit keys in the long term. For that purpose the requirement level for 128 bit keys and 256 bit keys are at MUST (when applicable). In that sense 256 bit keys status has been raised from MAY in RFC7321 to MUST. IANA has allocated codes for cryptographic algorithms that have not been specified by the IETF. Such algorithms are noted as UNSPECIFIED. Usually, the use of theses algorithms is limited to specific cases, and the absence of specification makes @@ -312,41 +307,38 @@ Encryption without authentication MUST NOT be used. As a result, authentication algorithm recommendations in this section are targeting two types of communications: Firstly authenticated only communications without encryption. Such communications can be ESP with NULL encryption or AH communications. Secondly, communications that are encrypted with non AEAD encryption algorithms mentioned above. In this case, they MUST be combined with an authentication algorithm. - +----------------------------+-------------+------------------------+ + +------------------------+------------------+-----------------------+ | Name | Status | Comment | - +----------------------------+-------------+------------------------+ - | AUTH_NONE | MUST / MUST | [RFC7296] AEAD | - | | NOT | | + +------------------------+------------------+-----------------------+ + | AUTH_NONE | MUST / MUST NOT | [RFC7296] AEAD | | AUTH_HMAC_MD5_96 | MUST NOT | [RFC2403][RFC7296] | | AUTH_HMAC_SHA1_96 | MUST- | [RFC2404][RFC7296] | | AUTH_DES_MAC | MUST NOT | [UNSPECIFIED] | | AUTH_KPDK_MD5 | MUST NOT | [UNSPECIFIED] | | AUTH_AES_XCBC_96 | SHOULD | [RFC3566][RFC7296] | | | | (IoT) | | AUTH_AES_128_GMAC | MAY | [RFC4543] | | AUTH_AES_256_GMAC | MAY | [RFC4543] | | AUTH_HMAC_SHA2_256_128 | MUST | [RFC4868] | | AUTH_HMAC_SHA2_512_256 | SHOULD | [RFC4868] | - +----------------------------+-------------+------------------------+ + +------------------------+------------------+-----------------------+ (IoT) - This requirement is for interoperability with IoT - Table 3 - AUTH_NONE has been downgraded from MAY in RFC7321 to MUST NOT. The only reason NULL is acceptable is when authenticated encryption algorithms are selected from Section 4. In all other cases, NULL MUST NOT be selected. As ESP and AH both provides authentication, one may be tempted to combine these protocols to provide authentication. As mentioned by RFC7321, it is NOT RECOMMENDED to use ESP with NULL authentication - with non authenticated encryption - in conjunction with AH; some configurations of this combination of services have been shown to be insecure [PD10]. In addition, NULL authentication cannot be combined with ESP NULL encryption. @@ -393,32 +385,29 @@ | Name | Status | Comment | +----------------+----------+-------------+ | IPCOMP_OUI | MUST NOT | UNSPECIFIED | | IPCOMP_DEFLATE | MAY | [RFC2393] | | IPCOMP_LZS | MAY | [RFC2395] | | IPCOMP_LZJH | MAY | [RFC3051] | +----------------+----------+-------------+ (IoT) - This requirement is for interoperability with IoT - Table 4 - Compression was not mentioned in RFC7321. As it is not widely deployed, it remains optional and at the MAY-level. 7. 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 | @@ -420,22 +409,20 @@ | 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. - Table 5 - 8. 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. 9. IANA Considerations This document has no IANA actions. @@ -456,127 +443,127 @@ 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. 11. References 11.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, + 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, . - [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI - 10.17487/RFC4302, December 2005, + [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, + DOI 10.17487/RFC4302, December 2005, . - [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC - 4303, DOI 10.17487/RFC4303, December 2005, + [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", + RFC 4303, DOI 10.17487/RFC4303, December 2005, . [RFC7321] McGrew, D. and P. Hoffman, "Cryptographic Algorithm 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, - . - 11.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, + Payload Compression Protocol (IPComp)", RFC 2393, + DOI 10.17487/RFC2393, December 1998, . [RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using LZS", RFC 2395, DOI 10.17487/RFC2395, December 1998, . [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, DOI 10.17487/RFC2403, November 1998, . [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November 1998, . [RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher - Algorithm With Explicit IV", RFC 2405, DOI 10.17487/ - RFC2405, November 1998, + Algorithm With Explicit IV", RFC 2405, + DOI 10.17487/RFC2405, November 1998, . [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, DOI 10.17487/RFC2410, November 1998, . [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, DOI 10.17487/RFC2451, November 1998, . [RFC3051] Heath, J. and J. Border, "IP Payload Compression Using ITU-T V.44 Packet Method", RFC 3051, DOI 10.17487/RFC3051, January 2001, . [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, DOI 10.17487/RFC3566, September 2003, . [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher - Algorithm and Its Use with IPsec", RFC 3602, DOI 10.17487/ - RFC3602, September 2003, + Algorithm and Its Use with IPsec", RFC 3602, + DOI 10.17487/RFC3602, September 2003, . [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode - (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC - 4106, DOI 10.17487/RFC4106, June 2005, + (GCM) in IPsec Encapsulating Security Payload (ESP)", + RFC 4106, DOI 10.17487/RFC4106, June 2005, . [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM - Mode with IPsec Encapsulating Security Payload (ESP)", RFC - 4309, DOI 10.17487/RFC4309, December 2005, + Mode with IPsec Encapsulating Security Payload (ESP)", + RFC 4309, DOI 10.17487/RFC4309, December 2005, . [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, DOI 10.17487/RFC4543, May 2006, . [RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and - Authentication Header (AH)", RFC 4835, DOI 10.17487/ - RFC4835, April 2007, + Authentication Header (AH)", RFC 4835, + DOI 10.17487/RFC4835, April 2007, . - [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC- - SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI - 10.17487/RFC4868, May 2007, + [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- + 384, and HMAC-SHA-512 with IPsec", RFC 4868, + DOI 10.17487/RFC4868, May 2007, . [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 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, + . + Authors' Addresses Daniel Migault Ericsson 8400 boulevard Decarie Montreal, QC H4P 2N2 Canada Phone: +1 514-452-2160 Email: daniel.migault@ericsson.com