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 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.

Table of Contents

1.  Introduction
    1.1.  Conventions Used In This Document
2.  New Algorithm Guidance
3.  Rationale
    3.1.  Efficiency
    3.2.  HMAC-SHA-2
4.  Other Algorithms
5.  Security Considerations
6.  IANA Considerations
7.  References
    7.1.  Normative References
    7.2.  Informative References
§  Authors' Addresses

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] (Manral, V., “Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH),” April 2007.). 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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

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] (Viega, J. and D. McGrew, “The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP),” June 2005.) [RFC4543] (McGrew, D. and J. Viega, “The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH,” May 2006.) [RFC5282] (Black, D. and D. McGrew, “Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol,” August 2008.) 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] (Law, L. and J. Solinas, “Suite B Cryptographic Suites for IPsec,” May 2007.).

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] (Housley, R., “Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP),” January 2004.) is recommended as a SHOULD in [RFC4835] (Manral, V., “Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH),” April 2007.). AES-CTR is a useful algorithm because it admits efficient high speed implementations. However, it provides no authentication. From RFC3686:

"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] (Kent, S., “IP Encapsulating Security Payload (ESP),” December 2005.), 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] (Dworkin, M., “Special Publication 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.,” .), 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] (McGrew, D. and J. Viega, “The Security and Performance of the Galois/Counter Mode (GCM),” December 2004.).

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] (Dai, W., “Crypto++ 5.6.0 Benchmarks,” 2009.). (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 recently published implementation strategies for modern CPUs that include the most efficient software implementations of any authentication encryption algorithm to date [KS09] (Kasper, E. and P. Schwabe, “Faster and Timing-Attack Resistant AES-GCM,” 2009.). 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] (Kounavis, M., “AES-NI: New Technology for Improving Encryption Efficiency and Enhancing Data Security in the Enterprise Cloud,” 2009.). 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] (, “Announcing the SECURE HASH STANDARD,” August 2002.) 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] (Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” February 1997.) 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] (Kelly, S. and S. Frankel, “Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec,” May 2007.).

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] (R. Dietz, Editor, “No Need for SHA-2,” 2002.)), 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] (, “Special Publication 800-107: Recommendation for Applications Using Approved Hash Algorithms,” 2009.), 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.

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] (, “Public Comments on the Draft GCM Specification, and Comments on The Choice Between CWC or GCM,” 2009.).

An analysis of the security of GCM has been published [MV04] (McGrew, D. and J. Viega, “The Security and Performance of the Galois/Counter Mode (GCM),” December 2004.); 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.

7.  References

7.1. Normative References

7.2. Informative References

Authors' Addresses