--- 1/draft-ietf-ipsecme-esp-ah-reqts-02.txt 2014-03-31 16:14:41.263858543 -0700 +++ 2/draft-ietf-ipsecme-esp-ah-reqts-03.txt 2014-03-31 16:14:41.291859206 -0700 @@ -1,22 +1,22 @@ Network Working Group D. McGrew Internet-Draft Cisco Systems Obsoletes: 4835 (if approved) W. Feghali Intended status: Standards Track Intel Corp. -Expires: September 4, 2014 P. Hoffman +Expires: October 2, 2014 P. Hoffman VPN Consortium - March 3, 2014 + March 31, 2014 Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) - draft-ietf-ipsecme-esp-ah-reqts-02 + draft-ietf-ipsecme-esp-ah-reqts-03 Abstract This Internet Draft is standards track proposal to update to the Cryptographic Algorithm Implementation Requirements for ESP and AH; it also adds usage guidance to help in the selection of these algorithms. The Encapsulating Security Payload (ESP) and Authentication Header (AH) protocols makes use of various cryptographic algorithms to @@ -39,21 +39,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 September 4, 2014. + This Internet-Draft will expire on October 2, 2014. Copyright Notice Copyright (c) 2014 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 @@ -64,31 +64,31 @@ described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Implementation Requirements . . . . . . . . . . . . . . . . . 4 2.1. ESP Authenticated Encryption (Combined Mode Algorithms) . 4 2.2. ESP Encryption Algorithms . . . . . . . . . . . . . . . . 4 2.3. ESP Authentication Algorithms . . . . . . . . . . . . . . 4 - 2.4. AH Authentication Algorithms . . . . . . . . . . . . . . 4 + 2.4. AH Authentication Algorithms . . . . . . . . . . . . . . 5 2.5. Summary of Changes . . . . . . . . . . . . . . . . . . . 5 3. Usage Guidance . . . . . . . . . . . . . . . . . . . . . . . 5 4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Authenticated Encryption . . . . . . . . . . . . . . . . 6 4.2. Encryption Transforms . . . . . . . . . . . . . . . . . . 6 4.3. Authentication Transforms . . . . . . . . . . . . . . . . 7 - 5. Algorithm Diversity . . . . . . . . . . . . . . . . . . . . . 8 + 5. Algorithm Diversity . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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 @@ -124,88 +124,96 @@ facilitate this, this document identifies such algorithms, as they are known today. There is no guarantee that the algorithms that we believe today may be mandatory in the future will in fact become so. All algorithms known today are subject to cryptographic attack and may be broken in the future. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. + document are to be interpreted as described in [RFC2119]. Following [RFC4835], we define some additional key words: 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, it is likely that an algorithm marked as SHOULD- will be deprecated to a MAY or worse in a future version of this document. - SHOULD NOT+ This term means the same as SHOULD NOT. However, it is - likely that an algorithm marked as SHOULD NOT+ will be deprecated - to a MUST NOT in a future version of this document. - 2. Implementation Requirements This section specifies the cryptographic algorithms that MUST be implemented, and provides guidance about ones that SHOULD or SHOULD NOT be implemented. + In the following sections, all AES modes are for 128-bit AES. 192-bit + and 256-bit AES MAY be supported for those modes, but the + requirements here are for 128-bit AES. + 2.1. ESP Authenticated Encryption (Combined Mode Algorithms) ESP combined mode algorithms provide both confidentiality and authentication services; in cryptographic terms, these are authenticated encryption algorithms [RFC5116]. Authenticated encryption transforms are listed in the ESP encryption transforms IANA registry. Requirement Authenticated Encryption Algorithm ----------- ---------------------------------- - SHOULD+ AES-GCM [RFC4106] + SHOULD+ AES-GCM with a 16 octet ICV [RFC4106] MAY AES-CCM [RFC4309] 2.2. ESP Encryption Algorithms Requirement Encryption Algorithm ----------- -------------------------- MUST NULL [RFC2410] - MUST AES-128-CBC [RFC3602] + MUST AES-CBC [RFC3602] MAY AES-CTR [RFC3686] MAY TripleDES-CBC [RFC2451] - SHOULD NOT+ DES-CBC [RFC2405] + MUST NOT DES-CBC [RFC2405] 2.3. ESP Authentication Algorithms Requirement Authentication Algorithm (notes) ----------- ----------------------------- MUST HMAC-SHA1-96 [RFC2404] - SHOULD+ AES-GMAC [RFC4543] + SHOULD+ AES-GMAC with AES-128 [RFC4543] SHOULD AES-XCBC-MAC-96 [RFC3566] MAY NULL [RFC4303] + Note that the requirement level for NULL authentication depends on + the type of encryption used. When using authenticated encryption + from Section 2.1, the requirement for NULL encryption is the same as + the requirement for the authenticated encryption itself. When using + the encryption from Section 2.2, the requirement for NULL encryption + is truly "MAY"; see Section 3 for more detail. + 2.4. AH Authentication Algorithms + The requirements for AH are the same as for ESP Authentication Algorithms, except that NULL authentication is inapplicable. 2.5. Summary of Changes Old New Requirement Requirement Algorithm (notes) ---- ----------- ----------------- - MAY SHOULD+ AES-GCM [RFC4106] - MAY SHOULD+ AES-GMAC [RFC4543] + MAY SHOULD+ AES-GCM with a 16 octet ICV [RFC4106] + MAY SHOULD+ AES-GMAC with AES-128 [RFC4543] MUST- MAY TripleDES-CBC [RFC2451] SHOULD+ SHOULD AES-XCBC-MAC-96 [RFC3566] SHOULD MAY AES-CTR [RFC3686] 3. Usage Guidance Since ESP and AH can be used in several different ways, this document provides guidance on the best way to utilize these mechanisms. ESP can provide confidentiality, data origin authentication, or the @@ -213,38 +221,38 @@ data origin authentication. Background information on those security services is available [RFC4949]. In the following, we shorten "data origin authentication" to "authentication". Both confidentiality and authentication SHOULD be provided. If confidentiality is not needed, then authentication MAY be provided. Confidentiality without authentication is not effective [DP07] and SHOULD NOT be used. We describe each of these cases in more detail below. - To provide confidentiality and authentication, an authenticated - encryption transform SHOULD be used in ESP, in conjunction with NULL - authentication. Alternatively, an ESP encryption transform and ESP - authentication transform MAY be used together (provided that neither - transform is NULL). If authentication on the IP header is needed in - conjunction with confidentiality of higher-layer data, then AH SHOULD - be used in addition to the transforms recommended above. It is NOT - RECOMMENDED to use ESP with NULL authentication in conjunction with - AH; some configurations of this combination of services have been - shown to be insecure [PD10]. + To provide both confidentiality and authentication, an authenticated + encryption transform from Section 2.1 SHOULD be used in ESP, in + conjunction with NULL authentication. Alternatively, an ESP + encryption transform and ESP authentication transform MAY be used + together. It is NOT RECOMMENDED to use ESP with NULL authentication + in conjunction with AH; some configurations of this combination of + services have been shown to be insecure [PD10]. To provide authentication without confidentiality, an authentication - transform MUST be used in either ESP or AH. It is not possible to - provide effective confidentiality without authentication, because the - lack of authentication undermines the efficacy of encryption - [B96][V02]. An encryption transform MUST NOT be used with a NULL - authentication transform (unless the encryption transform is an - authenticated encryption transform). + transform MUST be used in either ESP or AH. The IPsec community + generally perfers ESP wth NULL encryption over AH, but AH is still + required in some protocols; further, AH is more appropriate when + there are security-sensitive options in the IP header. It is not + possible to provide effective confidentiality without authentication, + because the lack of authentication undermines the efficacy of + encryption [B96][V02]. Therefore, an encryption transform MUST NOT + be used with a NULL authentication transform (unless the encryption + transform is an authenticated encryption transform from Section 2.1). Triple-DES SHOULD NOT be used in any scenario in which multiple gigabytes of data will be encrypted with a single key. As a 64-bit block cipher, it leaks information about plaintexts above that "birthday bound" [M13]. Triple-DES CBC is listed as a MAY implement for the sake of backwards compatibility, but its use is discouraged. 4. Rationale This section explains the principles behind the implementation @@ -284,21 +292,21 @@ The Triple Data Encryption Standard (TDES) is obsolete because of its small block size; as with all 64-bit block ciphers, it SHOULD NOT be used to encrypt more than one gigabyte of data with a single key [M13]. Its key size is smaller than that of the Advanced Encryption Standard (AES), while at the same time its performance and efficiency is worse. Thus, its use in new implementations is discouraged. The Data Encryption Standard (DES) is obsolete because of its small key size and small block size. There have been publicly demonstrated and open-design special-purpose cracking hardware. Therefore, its - use is discouraged. + use is has been changed to MUST NOT in this document. 4.3. Authentication Transforms AES-GMAC provides good security along with performance advantages, even over HMAC-MD5. In addition, it uses the same internal components as AES-GCM and is easy to implement in a way that shares components with that authenticated encryption algorithm. The MD5 hash function has been found to not meet its goal of collision resistance; it is so weak that its use in digital @@ -353,22 +360,23 @@ would be caused if such a flaw were found would be so large. 6. Acknowledgements Much of the wording herein was adapted from [RFC4835], the parent document of this document. That RFC itself borrows from [RFC4305], which borrows in turn from [RFC4307]. RFC4835, RFC4305, and RFC4307 were authored by Vishwas Manral, Donald Eastlake, and Jeffrey Schiller respectively. - Thanks are due to Scott Fluhrer, Dan Harkins, Brian Weis, and Cheryl - Madson for insightful feedback on this draft. + Thanks are due to Brian Weis, Cheryl Madson, Dan Harkins, Paul + Wouters, Ran Atkinson, Scott Fluhrer, Tero Kivinen, and Valery + Smyslov for insightful feedback on this draft. 7. IANA Considerations None. 8. 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