Network Working Group D. McGrew Internet-Draft Cisco Systems Intended status: Informational K. Grewal Expires: August 12, 2010 Intel Corporation February 8, 2010 Updating ESP and AH Algorithm Requirements for Efficiency and Security draft-mcgrew-esp-ah-algo-update-00.txt Abstract This note defines an update to the ESP and AH algorithm requirements that promotes efficiency, security, and interoperability, by recommending the use of the Advanced Encryption Standard (AES) block cipher in the Galois/Counter Mode (GCM) of operation. It is an individual submission, intended as input to future standards track work on IPsec policy. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 12, 2010. Copyright Notice Copyright (c) 2010 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 McGrew & Grewal Expires August 12, 2010 [Page 1] Internet-Draft IPsec Algorithms February 2010 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. McGrew & Grewal Expires August 12, 2010 [Page 2] Internet-Draft IPsec Algorithms February 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Conventions Used In This Document . . . . . . . . . . . . . 4 2. New Algorithm Guidance . . . . . . . . . . . . . . . . . . . . 4 3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Efficiency . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. HMAC-SHA-2 . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Other Algorithms . . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 McGrew & Grewal Expires August 12, 2010 [Page 3] Internet-Draft IPsec Algorithms February 2010 1. Introduction This note describes and motivates a change to the "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", [RFC4835]. This note does not change the required algorithms; rather, it replaces one SHOULD implement algorithm with another algorithm and clarifies that a third algorithm (not mentioned in that RFC) is NOT RECOMMENDED. 1.1. Conventions Used In This Document 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 [RFC2119]. 2. New Algorithm Guidance This memo proposes the following guidance: An ESP implementation SHOULD include AES-128-GCM. The use of HMAC-SHA-256, HMAC-SHA-384, or HMAC-SHA-512 is NOT RECOMMENDED. An AH implementation SHOULD include AES-182-GMAC, and the use of HMAC-SHA-256, HMAC-SHA-384, or HMAC-SHA-512 is NOT RECOMMENDED. This guidance does not apply to uses of HMAC or SHA-2 outside of ESP or AH. 3. Rationale AES in Galois/Counter Mode of operation (AES-GCM) [RFC4106] [RFC4543] [RFC5282] should be recommended for use in ESP and AH, because it provides higher efficiency than currently recommended algorithms with equivalent security, and is required by newer IPsec profiles [RFC4869]. In order for ESP and AH implementations to realize the efficiency benefits that GCM offers, it is important for IPsec to recognize the sufficiency of that algorithm. A major benefit of GCM is smaller circuit size at high data rates. However, this compactness will be squandered if implementations have to additionally include the circuits for less efficient algorithms. Currently, AES in Counter Mode (AES-CTR) [RFC3686] is recommended as a SHOULD in [RFC4835]. AES-CTR is a useful algorithm because it admits efficient high speed implementations. However, it provides no authentication. From RFC3686: McGrew & Grewal Expires August 12, 2010 [Page 4] Internet-Draft IPsec Algorithms February 2010 "With AES-CTR, it is trivial to use a valid ciphertext to forge other (valid to the decryptor) ciphertexts. Thus, it is equally catastrophic to use AES-CTR without a companion authentication function. Implementations MUST use AES-CTR in conjunction with an authentication function, such as HMAC-SHA-1-96 [HMAC-SHA]." Unfortunately, none of the authentication algorithms currently defined for IPsec (HMAC, XCBC-MAC) admit efficient high speed implementations. Thus the need for authentication undermines the efficiency of AES-CTR. An unintended side effect is that users may be tempted to run AES-CTR without authentication for performance reasons, even though the standard says not to do so. AES-GCM was designed specifically to overcome these problems. It is a "combined mode" in the ESP sense [RFC4303], that provides both encryption and authentication. Internally, it combines AES-CTR with an authentication mechanism that can be efficiently implemented at high data rates. At the time that RFC 4835 was published (April 2007), there was not yet a stable normative reference for AES-GCM. This may have motivated the IPsec community to not put too much reliance on that algorithm in its guidelines. But November 2007 saw the publication of "Recommendation for Block Cipher Modes of Operation: Galois/ Counter Mode (GCM) and GMAC" [800-38D], which removes any such concern. An additional change in favor of AES-GCM is its wide adoption by cryptographic hardware and software suppliers. 3.1. Efficiency GCM can be efficiently implemented in hardware, because it can be parallelized or fully pipelined with low latency, and it uses relatively efficient GF(2^128) operations. For more information about performance in hardware, see the analysis of packet-processing and hardware in Section 3 of [MV04]. Efficient software implementations are also possible. With a modest use of memory and a precomputed table, GCM can easily match the performance of other encryption-and-authentication methods. The benchmarks of the popular Crypto++ library show that GCM with a 2Kb table significantly outperforms the combination of HMAC-SHA-1 with any AES encryption mode [DAI]. (For the purposes of comparison, one can consider GCM's authentication component, which is called GMAC when used separately. GMAC can be compared to HMAC-SHA-1, SHA-256 and SHA-512.) When specialized hardware or implementation techniques are available, GCM is typically the most efficient alternative. Kasper and Schwabe McGrew & Grewal Expires August 12, 2010 [Page 5] Internet-Draft IPsec Algorithms February 2010 recently published implementation strategies for modern CPUs that include the most efficient software implementations of any authentication encryption algorithm to date [KS09]. A recent report shows that AES-GCM can outperform the combination of AES-CBC and HMAC-SHA-1 by over 40%, on platforms with cryptographic instructions [AES-NI]. The performance margin over HMAC-SHA-256 or HMAC-SHA-512 would be even greater. 3.2. HMAC-SHA-2 The Secure Hash Standard, version 2 [FIPS-180-2] defines the hash algorithms SHA-256, SHA-384, and SHA-512. These functions are similar to the SHA-1 hash function, but have higher security goals. These functions are unkeyed, but they can be used in the HMAC algorithm [RFC2104] as a keyed message authentication code. The use of the hash function HASH in this manner is denoted HMAC-HASH. This memo suggests that IPsec explicitly put HMAC-SHA-256, HMAC-SHA- 384, and HMAC-SHA-512 in the "NOT RECOMMENDED for ESP or AH" category, because those MACs neither necessary nor sufficient for achieving the goals of efficiency, interoperability, and security. There may be particular circumstances when these algorithms are acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing them. Implications may include, e.g., higher power usage, higher circuit cost, lower performance in software, and incompatibility with implementations that do not, or can not, perform the additional authentication due to their preference for more efficient algorithms. This guidance applies only to the use of these algorithms in ESP and AH; it does not apply to other uses described in [RFC4868]. AES-GCM is preferred over the use of AES-CTR with HMAC-SHA-256 for use in ESP and AH, because the latter combination of algorithms is considerably less efficient, and the former algorithm meets the security requirements. HMAC-SHA-1 is believed to be secure (recall the "No Need for SHA-2" Open Letter [OL]), but as the industry moves away from SHA1, HMAC-SHA-256 may be the first algorithm that comes to mind for some users of IPsec. A transition away from SHA-1 for digital signatures is already underway; many users plan to have that transition completed by the end of 2010 (see "Recommendation for Applications Using Approved Hash Algorithms" [800-107], for example). AES-CBC and HMAC-SHA1 are valuable because those algorithms are widely implemented. This suggests that it makes sense to rely on those algorithms as mandatory-to-implement until the time comes when it becomes necessary or desirable to stop using HMAC-SHA1. AES-GCM could be considered for use as a replacement to this combination of algorithms, when that time comes. McGrew & Grewal Expires August 12, 2010 [Page 6] Internet-Draft IPsec Algorithms February 2010 4. Other Algorithms It may be desirable to revisit the advisability of other algorithms in RFC 4835 such as HMAC-MD5-96. However, these considerations are out of scope of this note. 5. Security Considerations HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 are believed to be secure. The only reason that they are not recommended is because they are less efficient. No discredit to the security of these functions should be inferred from this guidance. Internally, AES-GCM consists of AES-CTR encryption with an authentication component that uses "universal hashing". This authentication method relies solely on well understood mathematical properties of the hash function, rather than any unproven assumptions about cryptographic properties. In particular, AES-GCM makes no cryptographic assumptions other than the suitability of AES as a pseudorandom permutation, an assumption that is also shared by AES- CTR. Authentication using universal hashing is uncomplicated and has been well understood in cryptographic theory for decades. These reasons have given confidence to the use of GCM in several standards, including IEEE 802.1AE Ethernet MAC security, IEEE 1619 Security in Storage, IPsec (ESP, AH, and IKE), and TLS. GCM was in the vanguard of cryptographic standards that use universal hashing for authentication. While there was never any question about the efficacy of universal hash based authentication, some commentators pointed out system security aspects of GCM that are different than those of other algorithms. In particular, special care must be taken to ensure the distinctness all of the nonce values used with a particular GCM or GMAC key. The standards describing the use of GCM in ESP and AH already take these system security properties into consideration; nonetheless, the interested reader can find more background discussion in [MODES]. An analysis of the security of GCM has been published [MV04]; the reader interested in the precise security claims is referred to that document. 6. IANA Considerations This note has no actions for IANA. This section should be removed by the RFC editor before publication as an RFC. McGrew & Grewal Expires August 12, 2010 [Page 7] Internet-Draft IPsec Algorithms February 2010 7. References 7.1. Normative References [800-38D] Dworkin, M., "Special Publication 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.", U.S. National Institute of Standards and Technology (NIST) Special Publication (SP) 800-38D, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005. [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, May 2006. 7.2. Informative References [800-107] "Special Publication 800-107: Recommendation for Applications Using Approved Hash Algorithms", U.S. National Institute of Standards and Technology (NIST) Special Publication (SP) 800-107, 2009. [AES-NI] Kounavis, M., "AES-NI: New Technology for Improving Encryption Efficiency and Enhancing Data Security in the Enterprise Cloud", Intel Developer Forum https:// intel.wingateweb.com/us09/scheduler/ sessions.do?searchGroup=9&searchGroupID=10133& profileItem_id=10004, 2009. [DAI] Dai, W., "Crypto++ 5.6.0 Benchmarks", Web Page Speed Comparison of Popular Crypto Algorithms, 2009, . [FIPS-180-2] "Announcing the SECURE HASH STANDARD", Federal Information Processing Standards (FIPS) 180-2, August 2002, . [KS09] Kasper, E. and P. Schwabe, "Faster and Timing-Attack Resistant AES-GCM", Cryptographic Hardware and Embedded Systems -- CHES 2009 Spinger-Verlag Lecture Notes in McGrew & Grewal Expires August 12, 2010 [Page 8] Internet-Draft IPsec Algorithms February 2010 Computer Science 5745, 2009, . [MODES] "Public Comments on the Draft GCM Specification, and Comments on The Choice Between CWC or GCM", NIST Computer Security Division Modes of Operation Comments, 2009, . [MV04] McGrew, D. and J. Viega, "The Security and Performance of the Galois/Counter Mode (GCM)", Proceedings of INDOCRYPT '04, , December 2004, . [OL] R. Dietz, Editor, "No Need for SHA-2", Open Letter to IPsec WG and Area Directors (email), 2002, . [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007. [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. [RFC4869] Law, L. and J. Solinas, "Suite B Cryptographic Suites for IPsec", RFC 4869, May 2007. [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol", RFC 5282, August 2008. McGrew & Grewal Expires August 12, 2010 [Page 9] Internet-Draft IPsec Algorithms February 2010 Authors' Addresses David A. McGrew Cisco Systems 510 McCarthy Blvd. Milpitas, CA 95035 USA Phone: (408) 525 8651 Email: mcgrew@cisco.com URI: http://www.mindspring.com/~dmcgrew/dam.htm Ken Grewal Intel Corporation 2111 NE 25th Avenue, JF3-232 Hillsboro, OR 97124 USA Email: ken.grewal@intel.com McGrew & Grewal Expires August 12, 2010 [Page 10]