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

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/