Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)
draft-mcgrew-ipsec-me-esp-ah-reqts-00

Abstract

This Internet Draft is an individual submission that proposes an 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 provide confidentiality and/or data origin authentication to protected data communications in the IP Security (IPsec) architecture. To ensure interoperability between disparate implementations, the IPsec standard specifies a set of mandatory-to- implement algorithms. This document specifies the current set of mandatory-to-implement algorithms for ESP and AH, specifies algorithms that should be implemented because they may be promoted to mandatory at some future time, and also recommends against the implementation of some obsolete algorithms. Usage guidance is also provided to help the user of ESP and AH best achieve their security goals through appropriate choices of cryptographic algorithms.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

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 April 16, 2013.

Copyright Notice

Copyright (c) 2012 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 Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Requirements Language
• 2. Implementation Requirements
• 2.1. ESP Authenticated Encryption (Combined Mode Algorithms)
• 2.2. ESP Encryption Algorithms
• 2.3. ESP Authentication Algorithms
• 2.4. AH Authentication Algorithms
• 2.5. Summary of Changes
• 3. Usage Guidance
• 4. Rationale
• 4.1. Authenticated Encryption
• 4.2. Encryption Transforms
• 4.3. Authentication Transforms
• 5. Acknowledgements
• 6. IANA Considerations
• 7. Security Considerations
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Authors' Addresses

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

To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms. This ensures that there is at least one algorithm that all implementations will have in common. This document specifies the current set of mandatory-to-implement algorithms for ESP and AH, specifies algorithms that should be implemented because they may be promoted to mandatory at some future time, and also recommends against the implementation of some obsolete algorithms. Usage guidance is also provided to help the user of ESP and AH best achieve their security goals through appropriate choices of mechanisms.

The nature of cryptography is that new algorithms surface continuously and existing algorithms are continuously attacked. An algorithm believed to be strong today may be demonstrated to be weak tomorrow. Given this, the choice of mandatory-to-implement algorithm should be conservative so as to minimize the likelihood of it being compromised quickly. Thought should also be given to performance considerations as many uses of IPsec will be in environments where performance is a concern.

The ESP and AH mandatory-to-implement algorithm(s) may need to change over time to adapt to new developments in cryptography. For this reason, the specification of the mandatory-to-implement algorithms is not included in the main IPsec, ESP, or AH specifications, but is instead placed in this document. Ideally, the mandatory-to-implement algorithm of tomorrow should already be available in most implementations of IPsec by the time it is made mandatory. To 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].

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.

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]
        MAY            AES-CCM [RFC4309]

2.2. ESP Encryption Algorithms

        Requirement    Encryption Algorithm
        -----------    --------------------------
        MUST           NULL [RFC2410] 
        MUST           AES-128-CBC [RFC3602]
        MAY            AES-CTR [RFC3686]
        SHOULD NOT     TripleDES-CBC [RFC2451]
        SHOULD NOT+    DES-CBC [RFC2405] 

2.3. ESP Authentication Algorithms

        Requirement    Authentication Algorithm (notes)
        -----------    -----------------------------
        MUST           HMAC-SHA1-96 [RFC2404]
        SHOULD+        AES-GMAC [RFC4543]
        SHOULD         AES-XCBC-MAC-96 [RFC3566]
        MAY            NULL [RFC4303]
        MAY            HMAC-SHA-256 [RFC4868]
        MAY            HMAC-SHA-384 [RFC4868]
        MAY            HMAC-SHA-512 [RFC4868]
        SHOULD NOT     HMAC-MD5-96 [RFC2403]

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]
      MUST-          SHOULD NOT       TripleDES-CBC [RFC2451]
      SHOULD+        SHOULD           AES-XCBC-MAC-96 [RFC3566] 
      SHOULD         MAY              AES-CTR [RFC3686]
      MAY            SHOULD NOT       HMAC-MD5-96 [RFC2403]

3. Usage Guidance

Since ESP and AH can be used in several different ways, this note provides guidance on the best way to utilize these mechanisms.

ESP can provide confidentiality, data origin authentication, or the combination of both of those security services. AH provides only 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 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).

4. Rationale

This section explains the principles behind the implementation requirements described above.

4.1. Authenticated Encryption

This note encourages the use of authenticated encryption algorithms because they can provide significant efficiency and throughput advantages, and the tight binding between authentication and encryption can be a security advantage [RFC5116].

AES-GCM [RFC4106] brings significant performance benefits [KKGEGD], has been incorporated into IPsec recommendations [RFC6379] and has emerged as the preferred authenticated encryption method in IPsec and other standards.

4.2. Encryption Transforms

Since ESP encryption is optional, support for the "NULL" algorithm is required to maintain consistency with the way services are negotiated. Note that while authentication and encryption can each be "NULL", they MUST NOT both be "NULL" [RFC4301] [H10].

AES Counter Mode (AES-CTR) is an efficient encryption method, but it provides no authentication capability. The AES-GCM authenticated encryption method has all of the advantages of AES-CTR, while also providing authentication. Thus this note moves AES-CTR from a SHOULD to a MAY.

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

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 signatures is highly discouraged [RFC6151]. There have been theoretical results against HMAC-MD5, but that message authentication code does not seem to have a practical vulnerability. Thus, it may not be urgent to remove HMAC-MD5 from the existing protocols; however, since MD5 must not be used for digital signatures, HMAC-MD5 should not be included in new implementations.

SHA-1 has been found to not meet its goal of collision resistance. However, HMAC-SHA-1 does not rely on this property, and HMAC-SHA-1 is believed to be secure.

The HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 are believed to provide a good security margin, and they perform adequately on many platforms. However, these algorithms are listed only as MAY implement in this note, because HMAC-SHA-1 support is widespread and its security is good, AES-GMAC provides good security with better performance, and Authenticated Encryption algorithms do not need any authentication methods.

AES-XCBC has not seen widespread deployment, despite being previously being recommended as a SHOULD+ in RFC4305. Thus this draft lists it only as a SHOULD.

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

6. IANA Considerations

This memo includes no request to IANA.

7. 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 the engineering and administration of the protocol used by the system to ensure that there are no non-cryptographic ways to bypass the security of the overall system.

This document concerns itself with the selection of cryptographic algorithms for the use of ESP and AH, specifically with the selection of mandatory-to-implement algorithms. The algorithms identified in this document as "MUST implement" or "SHOULD implement" are not known to be broken at the current time, and cryptographic research so far leads us to believe that they will likely remain secure into the foreseeable future. However, this is not necessarily forever. We would therefore expect that new revisions of this document will be issued from time to time that reflect the current best practice in this area.

8. References

8.1. Normative References

8.2. Informative References

Authors' Addresses