Internet Engineering Task Force D. McGrew
Internet-Draft Cisco Systems
Intended status: Standards Track W. Feghali
Expires: September 12, 2013 Intel Corp.
March 11, 2013
Cryptographic Algorithm Implementation Requirements and Usage Guidance
for Encapsulating Security Payload (ESP) and Authentication Header (AH)
draft-ietf-ipsecme-esp-ah-reqts-00
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
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 September 12, 2013.
McGrew & Feghali Expires September 12, 2013 [Page 1]
Internet-Draft Requirements and Guidance for ESP and AH March 2013
Copyright Notice
Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Document History . . . . . . . . . . . . . . . . . . . . . 4
2. Implementation Requirements . . . . . . . . . . . . . . . . . 5
2.1. ESP Authenticated Encryption (Combined Mode Algorithms) . 5
2.2. ESP Encryption Algorithms . . . . . . . . . . . . . . . . 5
2.3. ESP Authentication Algorithms . . . . . . . . . . . . . . 5
2.4. AH Authentication Algorithms . . . . . . . . . . . . . . . 5
2.5. Summary of Changes . . . . . . . . . . . . . . . . . . . . 5
3. Usage Guidance . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Authenticated Encryption . . . . . . . . . . . . . . . . . 8
4.2. Encryption Transforms . . . . . . . . . . . . . . . . . . 8
4.3. Authentication Transforms . . . . . . . . . . . . . . . . 9
5. Algorithm Diversity . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
McGrew & Feghali Expires September 12, 2013 [Page 2]
Internet-Draft Requirements and Guidance for ESP and AH March 2013
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:
McGrew & Feghali Expires September 12, 2013 [Page 3]
Internet-Draft Requirements and Guidance for ESP and AH March 2013
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.
1.2. Document History
This is the initial version of this draft. It is based on an earlier
individual submission [draft-mcgrew-ipsec-me-esp-ah-reqts], and
incorporates feedback provided during the last IPsec ME meeting at
IETF85. Triple-DES is now a MAY (instead of SHOULD NOT) and HMAC-MD5
is now ignored (instead of a SHOULD NOT), and "MAY" is no longer
called out, except for algorithms that were previously listed as
SHOULD, SHOULD+, or MUST.
This revision also adds a section discussing algorithm diversity, and
references to new work on the selection of future cryptographic
standards [draft-mcgrew-standby-cipher] and technical work showing
the insecurity of 64-bit block ciphers (such as the Triple-DES
algorithm) used to encrypt more than a gigabyte of data [M13].
McGrew & Feghali Expires September 12, 2013 [Page 4]
Internet-Draft Requirements and Guidance for ESP and AH March 2013
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]
MAY 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]
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
McGrew & Feghali Expires September 12, 2013 [Page 5]
Internet-Draft Requirements and Guidance for ESP and AH March 2013
Old New
Requirement Requirement Algorithm (notes)
---- ----------- -----------------
MAY SHOULD+ AES-GCM [RFC4106]
MAY SHOULD+ AES-GMAC [RFC4543]
MUST- MAY TripleDES-CBC [RFC2451]
SHOULD+ SHOULD AES-XCBC-MAC-96 [RFC3566]
SHOULD MAY AES-CTR [RFC3686]
McGrew & Feghali Expires September 12, 2013 [Page 6]
Internet-Draft Requirements and Guidance for ESP and AH March 2013
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).
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.
McGrew & Feghali Expires September 12, 2013 [Page 7]
Internet-Draft Requirements and Guidance for ESP and AH March 2013
4. Rationale
This section explains the principles behind the implementation
requirements described above.
The algorithms listed as MAY-implement are not meant to be endorsed
over other non-standard alternatives. All of the algorithms that
appeared in [RFC4835] are included in this note, for the sake of
continuity. In some cases, these algorithms have moved from being
SHOULD-implement to MAY-implement algorithms.
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
[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.
McGrew & Feghali Expires September 12, 2013 [Page 8]
Internet-Draft Requirements and Guidance for ESP and AH March 2013
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.
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 not recommended for
implementation 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.
McGrew & Feghali Expires September 12, 2013 [Page 9]
Internet-Draft Requirements and Guidance for ESP and AH March 2013
5. Algorithm Diversity
When the AES cipher was first adopted, it was decided to continue
encouraging the implementation of Triple-DES, in order to provide
algorithm diversity. But the passage of time has eroded the
viability of Triple-DES as an alternative to AES. As it is a 64-bit
block cipher, its security is inadequate at high data rates (see
Section 4.2). Its performance in software and FPGAs is considerably
worse than that of AES. Since it would not be possible to use
Triple-DES as an alternative to AES in high data rate environments,
or in environments where its performance could not keep up the
requirements, the rationale of retaining Triple-DES to provide
algorithm diversity is disappearing. (Of course, this does not
change the rationale of retaining Triple-DES in IPsec implementations
for backwards compability.)
It may be prudent to begin considering the selection of a different
cipher that could provide algorithm diversity in IPsec and other IETF
standards. There are many important criteria to consider, which are
out of scope for this note. These issues have been taken up in
recent work [draft-mcgrew-standby-cipher].
It is important to bear in mind that it is very highly unlikely that
an exploitable flaw will be found in AES (e.g., a flaw that required
less than a terabyte of known plaintext, when AES is used in a
conventional mode of operation). The only reason that algorithm
diversity deserves any consideration is because the problems that
would be caused if such a flaw were found would be so large.
McGrew & Feghali Expires September 12, 2013 [Page 10]
Internet-Draft Requirements and Guidance for ESP and AH March 2013
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.
McGrew & Feghali Expires September 12, 2013 [Page 11]
Internet-Draft Requirements and Guidance for ESP and AH March 2013
7. IANA Considerations
This memo includes no request to IANA.
McGrew & Feghali Expires September 12, 2013 [Page 12]
Internet-Draft Requirements and Guidance for ESP and AH March 2013
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
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.
McGrew & Feghali Expires September 12, 2013 [Page 13]
Internet-Draft Requirements and Guidance for ESP and AH March 2013
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
ESP and AH", 1998.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", 1998.
[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
Algorithm With Explicit IV", 1998.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", 1998.
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm
and Its Use With IPsec", 2003.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", 2003.
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES)
Counter Mode With IPsec Encapsulating Security Payload
(ESP)", 2004.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec Encapsulating Security Payload (ESP)",
2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", 2005.
[RFC4302] Kent, S., "IP Authentication Header", 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload", 2005.
9.2. Informative References
[B96] Bellovin, S., "Problem areas for the IP security protocols
(Proceedings of the Sixth Usenix Unix Security
Symposium)", 1996.
[DP07] Degabriele, J. and K. Paterson, "Attacking the IPsec
Standards in Encryption-only Configurations (IEEE
McGrew & Feghali Expires September 12, 2013 [Page 14]
Internet-Draft Requirements and Guidance for ESP and AH March 2013
Symposium on Privacy and Security)", 2007.
[H10] Hoban, A., "Using Intel AES New Instructions and PCLMULQDQ
to Significantly Improve IPSec Performance on Linux",
2010.
[KKGEGD] Kounavis, M., Kang, X., Grewal, K., Eszenyi, M., Gueron,
S., and D. Durham, "Encrypting the Internet (SIGCOMM)",
2010.
[M13] McGrew, D., "Impossible plaintext cryptanalysis and
probable-plaintext collision attacks of 64-bit block
cipher modes", 2012.
[PD10] Paterson, K. and J. Degabriele, "On the (in)security of
IPsec in MAC-then-encrypt configurations (ACM Conference
on Computer and Communications Security, ACM CCS)", 2010.
[RFC4305] Eastlake, D., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)".
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", 2005.
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
Mode with IPsec Encapsulating Security Payload (ESP)",
2005.
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)".
[RFC4949] Shirley, R., "Internet Security Glossary, Version 2",
2007.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", 2008.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
2011.
[RFC6379] Law, L. and J. Solinas, "Suite B Cryptographic Suites for
IPsec", 2011.
[V02] Vaudenay, S., "Security Flaws Induced by CBC Padding -
Applications to SSL, IPSEC, WTLS ... (EUROCRYPT)", 2002.
McGrew & Feghali Expires September 12, 2013 [Page 15]
Internet-Draft Requirements and Guidance for ESP and AH March 2013
[draft-mcgrew-ipsec-me-esp-ah-reqts]
McGrew, D., "Cryptographic Algorithm Implementation
Requirements and Usage Guidance for Encapsulating Security
Payload (ESP) and Authentication Header (AH)", 2012.
[draft-mcgrew-standby-cipher]
McGrew, D., Grieco, A., and Y. Sheffer, "Selection of
Future Cryptographic Standards", 2013.
McGrew & Feghali Expires September 12, 2013 [Page 16]
Internet-Draft Requirements and Guidance for ESP and AH March 2013
Authors' Addresses
David McGrew
Cisco Systems
13600 Dulles Technology Drive
Herndon, Virginia 20171
USA
Phone: 408 525 8651
Email: mcgrew@cisco.com
Wajdi Feghali
Intel Corp.
75 Reed Road
Hudson, Massachusetts
USA
Phone:
Email: wajdi.k.feghali@intel.com
McGrew & Feghali Expires September 12, 2013 [Page 17]
