--- 1/draft-ietf-ipsecme-rfc7321bis-02.txt 2017-02-02 09:13:45.418648186 -0800 +++ 2/draft-ietf-ipsecme-rfc7321bis-03.txt 2017-02-02 09:13:45.450648944 -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 03, 2017 Red Hat +Expires: August 06, 2017 Red Hat Y. Nir Check Point T. Kivinen INSIDE Secure - January 30, 2017 + February 02, 2017 Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) - draft-ietf-ipsecme-rfc7321bis-02 + draft-ietf-ipsecme-rfc7321bis-03 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 03, 2017. + This Internet-Draft will expire on August 06, 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,21 +56,21 @@ 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 . . . . . . . . . . . . . . . . . . . . 4 + 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 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 @@ -114,29 +114,25 @@ mandatory. This document attempts to identify and introduce those algorithms for future mandatory-to-implement status. There is no guarantee that the algorithms in use today may become mandatory in the future. Published algorithms are continuously subjected to cryptographic attack and may become too weak or could become completely broken before this document is updated. This document only provides recommendations for the mandatory-to- implement algorithms and algorithms too weak that are recommended not to be implemented. As a result, any algorithm listed at the IPsec - IANA registry not mentioned in this document MAY be implemented. As - [RFC7321] omitted most of the algorithms mentioned by the IPsec IANA - repository, which makes it difficult to define whether non mentioned - algorithms are optional to implement or must not be implemented as - they are too weak. This document provides explicit guidance for all - of them. It is expected that this document will be updated over time - and next versions will only mention algorithms which status has - evolved. For clarification when an algorithm has been mentioned in - [RFC7321], this document states explicitly the update of the status. + IANA registry not mentioned in this document MAY be implemented. It + is expected that this document will be updated over time and next + versions will only mention algorithms which status has evolved. For + clarification when an algorithm has been mentioned in [RFC7321], this + document states explicitly the update of the status. Although this document updates the algorithms to keep the AH/ESP communication secure over time, it also aims at providing recommendations so that AH/ESP implementations remain interoperable. AH/ESP interoperability is addressed by an incremental introduction or deprecation of algorithms. In addition, this document also considers the new use cases for AH/ESP deployment, such as Internet of Things (IoT). It is expected that deprecation of an algorithm is performed @@ -146,21 +142,21 @@ downgraded from MUST to MUST- or SHOULD, instead of MUST NOT. Similarly, an algorithm that has not been mentioned as mandatory-to- implement is expected to be introduced with a SHOULD instead of a MUST. The current trend toward Internet of Things and its adoption of AH/ ESP requires this specific use case to be taken into account as well. IoT devices are resource constrained devices and their choice of algorithms are motivated by minimizing the footprint of the code, the computation effort and the size of the messages to send. This - document indicates "[IoT]" when a specified algorithm is specifically + document indicates "(IoT)" when a specified algorithm is specifically listed for IoT devices. Requirement levels that are marked as "IoT" apply to IoT devices and to server-side implementations that might presumably need to interoperate with them, including any general- purpose VPN gateways. 1.3. Document Audience The recommendations of this document mostly target AH/ESP implementers as implementations need to meet both high security expectations as well as high interoperability between various vendors @@ -179,71 +175,82 @@ IKEv2 parameters. IKEv1 is out of scope of this document. IKEv1 is deprecated and the recommendations of this document must not be considered for IKEv1, nor IKEv1 parameters be considered by this document. The IANA registry for Internet Key Exchange Version 2 (IKEv2) Parameters contains some entries that are not for use with ESP or AH. This document does not modify the status of those algorithms. 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]. - Following [RFC4835], we define some additional key words: + We define some additional terms here: - MUST- This term means the same as MUST. However, we expect that at - some point in the future this algorithm will no longer be a MUST. 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. + 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- + 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 (RFC7298) and + document was written for deploying ESP/AH using IKE ([RFC7296]) and assumes that keying happens using IKEv2. If manual keying is used anyway, ENCR_AES_CBC MUST be used, and ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 MUST NOT be used as these algorithms require IKE. 4. ESP Encryption Algorithms - +-------------------------+------------+---------+---------------+ + +-------------------------+-------------+---------+--------------+ | Name | Status | AEAD | Comment | - +-------------------------+------------+---------+---------------+ + +-------------------------+-------------+---------+--------------+ | ENCR_DES_IV64 | MUST NOT | No | UNSPECIFIED | | ENCR_DES | MUST NOT | No | [RFC2405] | | ENCR_3DES | SHOULD NOT | No | [RFC2451] | | ENCR_BLOWFISH | MUST NOT | No | [RFC2451] | | ENCR_3IDEA | MUST NOT | No | UNSPECIFIED | | ENCR_DES_IV32 | MUST NOT | No | UNSPECIFIED | | ENCR_NULL | MUST | No | [RFC2410] | | ENCR_AES_CBC | MUST | No | [RFC3602][1] | - | ENCR_AES_CCM_8 | SHOULD | Yes | [RFC4309]IoT] | + | 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 MUST level. - 192-bit and 256-bit keys are at the MAY level. + 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 1 + 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 @@ -288,25 +295,25 @@ devices. As this case is not a general use case for VPNs, its status is expected to remain as SHOULD. ENCR_AES_GCM_16 status has been updated from SHOULD+ to MUST in order to favor the use of authenticated encryption and AEAD algorithms. ENCR_AES_GCM_16 has been widely implemented for ESP due to its increased performance and key longevity compared to ENCR_AES_CBC. ENCR_CHACHA20_POLY1305 was not ready to be considered at the time of RFC7321. It has been recommended by the CRFG and others as an - alternative to ENCR_AES_XCBC and ENCR_AES_GCM_*. It is also being - standardized for ESP for the same reasons. At the time of writing, - there are not enough ESP implementations of ENCR_CHACHA20_POLY1305 to - be able to introduce it at the SHOULD+ level. Its status has been - set to SHOULD and is expected to become MUST in the long term. + alternative to AES-CBC and AES-GCM. It is also being standardized + for ESP for the same reasons. At the time of writing, there are not + enough ESP implementations of ENCR_CHACHA20_POLY1305 to be able to + introduce it at the SHOULD+ level. Its status has been set to SHOULD + and is expected to become MUST in the long term. 5. ESP and AH Authentication Algorithms 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 @@ -315,30 +322,30 @@ +----------------------------+-------------+------------------------+ | Name | Status | Comment | +----------------------------+-------------+------------------------+ | AUTH_NONE | MUST / MUST | [RFC7296] AEAD | | | NOT | | | 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] | + | | | (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 + (IoT) - This requirement is for interoperability with IoT - Table 2 + 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 @@ -384,23 +391,23 @@ +----------------+----------+-------------+ | 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 + (IoT) - This requirement is for interoperability with IoT - Table 3 + 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 @@ -413,21 +420,21 @@ | 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 4 + 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.