< draft-ietf-ipsecme-esp-ah-reqts-07.txt   draft-ietf-ipsecme-esp-ah-reqts-08.txt >
Network Working Group D. McGrew Network Working Group D. McGrew
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Obsoletes: 4835 (if approved) P. Hoffman Obsoletes: 4835 (if approved) P. Hoffman
Intended status: Standards Track VPN Consortium Intended status: Standards Track VPN Consortium
Expires: October 20, 2014 April 18, 2014 Expires: November 16, 2014 May 15, 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-07 draft-ietf-ipsecme-esp-ah-reqts-08
Abstract Abstract
This Internet Draft is a standards track proposal to update the This Internet Draft is a standards track proposal to update 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 make use of various cryptographic algorithms to (AH) protocols make 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 October 20, 2014. This Internet-Draft will expire on November 16, 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 30 skipping to change at page 2, line 30
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 . . . . . . . . . . . . . . 5 2.4. AH Authentication Algorithms . . . . . . . . . . . . . . 5
2.5. Summary of Changes . . . . . . . . . . . . . . . . . . . 5 2.5. Summary of Changes from RFC 4835 . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
skipping to change at page 4, line 5 skipping to change at page 4, line 5
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
that an algorithm marked as SHOULD- will be deprecated to a MAY or
worse 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 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 and 256-bit AES MAY be supported for those modes, but the
requirements here are for 128-bit AES. requirements here are for 128-bit AES.
skipping to change at page 5, line 14 skipping to change at page 5, line 10
from Section 2.1, the requirement for NULL encryption is the same as from Section 2.1, the requirement for NULL encryption is the same as
the requirement for the authenticated encryption itself. When using the requirement for the authenticated encryption itself. When using
the encryption from Section 2.2, the requirement for NULL encryption the encryption from Section 2.2, the requirement for NULL encryption
is truly "MAY"; see Section 3 for more detail. 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 from RFC 4835
Old New Old New
Requirement Requirement Algorithm (notes) Requirement Requirement Algorithm (notes)
---- ----------- ----------------- ---- ----------- -----------------
MAY SHOULD+ AES-GCM with a 16 octet ICV [RFC4106] MAY SHOULD+ AES-GCM with a 16 octet ICV [RFC4106]
MAY SHOULD+ AES-GMAC with AES-128 [RFC4543] MAY SHOULD+ AES-GMAC with AES-128 [RFC4543]
MUST- MAY TripleDES-CBC [RFC2451] MUST- MAY TripleDES-CBC [RFC2451]
SHOULD NOT MUST NOT DES-CBC [RFC2405] SHOULD NOT MUST NOT DES-CBC [RFC2405]
SHOULD+ SHOULD AES-XCBC-MAC-96 [RFC3566] SHOULD+ SHOULD AES-XCBC-MAC-96 [RFC3566]
SHOULD MAY AES-CTR [RFC3686] SHOULD MAY AES-CTR [RFC3686]
skipping to change at page 5, line 37 skipping to change at page 5, line 33
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
combination of both of those security services. AH provides only combination of both of those security services. AH provides only
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 Providing both confidentiality and authentication offers the best
confidentiality is not needed, then authentication MAY be provided. security. If confidentiality is not needed, providing authentication
Confidentiality without authentication is not effective [DP07] and can still be useful. Confidentiality without authentication is not
SHOULD NOT be used. We describe each of these cases in more detail effective [DP07] and therefore SHOULD NOT be used. We describe each
below. of these cases in more detail below.
To provide both confidentiality and authentication, an authenticated To provide both confidentiality and authentication, an authenticated
encryption transform from Section 2.1 SHOULD be used in ESP, in encryption transform from Section 2.1 SHOULD be used in ESP, in
conjunction with NULL authentication. Alternatively, an ESP conjunction with NULL authentication. Alternatively, an ESP
encryption transform and ESP authentication transform MAY be used encryption transform and ESP authentication transform MAY be used
together. It is NOT RECOMMENDED to use ESP with NULL authentication together. It is NOT RECOMMENDED to use ESP with NULL authentication
in conjunction with AH; some configurations of this combination of in conjunction with AH; some configurations of this combination of
services have been shown to be insecure [PD10]. services have been shown to be insecure [PD10].
To provide authentication without confidentiality, an authentication To provide authentication without confidentiality, an authentication
skipping to change at page 6, line 33 skipping to change at page 6, line 26
4. Rationale 4. Rationale
This section explains the principles behind the implementation This section explains the principles behind the implementation
requirements described above. requirements described above.
The algorithms listed as MAY-implement are not meant to be endorsed The algorithms listed as MAY-implement are not meant to be endorsed
over other non-standard alternatives. All of the algorithms that over other non-standard alternatives. All of the algorithms that
appeared in [RFC4835] are included in this document, for the sake of appeared in [RFC4835] are included in this document, for the sake of
continuity. In some cases, these algorithms have moved from being continuity. In some cases, these algorithms have moved from being
SHOULD-implement to MAY-implement algorithms. "SHOULD implement" to "MAY implement" algorithms.
4.1. Authenticated Encryption 4.1. Authenticated Encryption
This document encourages the use of authenticated encryption This document encourages the use of authenticated encryption
algorithms because they can provide significant efficiency and algorithms because they can provide significant efficiency and
throughput advantages, and the tight binding between authentication throughput advantages, and the tight binding between authentication
and encryption can be a security advantage [RFC5116]. and encryption can be a security advantage [RFC5116].
AES-GCM [RFC4106] brings significant performance benefits [KKGEGD], AES-GCM [RFC4106] brings significant performance benefits [KKGEGD],
has been incorporated into IPsec recommendations [RFC6379] and has has been incorporated into IPsec recommendations [RFC6379] and has
skipping to change at page 8, line 19 skipping to change at page 8, line 12
algorithm diversity. But the passage of time has eroded the 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 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 block cipher, its security is inadequate at high data rates (see
Section 4.2). Its performance in software and FPGAs is considerably Section 4.2). Its performance in software and FPGAs is considerably
worse than that of AES. Since it would not be possible to use 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, Triple-DES as an alternative to AES in high data rate environments,
or in environments where its performance could not keep up the or in environments where its performance could not keep up the
requirements, the rationale of retaining Triple-DES to provide requirements, the rationale of retaining Triple-DES to provide
algorithm diversity is disappearing. (Of course, this does not algorithm diversity is disappearing. (Of course, this does not
change the rationale of retaining Triple-DES in IPsec implementations change the rationale of retaining Triple-DES in IPsec implementations
for backwards compability.) for backwards compatibility.)
Recent discussions in the IETF have started considering how to make Recent discussions in the IETF have started considering how to make
the selection of a different cipher that could provide algorithm the selection of a different cipher that could provide algorithm
diversity in IPsec and other IETF standards. That work is expected diversity in IPsec and other IETF standards. That work is expected
to take a long time and involve discussions among many participants to take a long time and involve discussions among many participants
and organizations. and organizations.
It is important to bear in mind that it is very highly unlikely that 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 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 less than a terabyte of known plaintext, when AES is used in a
conventional mode of operation). The only reason that algorithm conventional mode of operation). The only reason that algorithm
diversity deserves any consideration is because the problems that diversity deserves any consideration is because the problems that
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 Some of the wording herein was adapted from [RFC4835], the document
document of this document. That RFC itself borrows from earlier that this one obsoletes. That RFC itself borrows from earlier RFCs,
RFCs, notably RFC 4305 and 4307. RFC 4835, RFC 4305, and RFC 4307 notably RFC 4305 and 4307. RFC 4835, RFC 4305, and RFC 4307 were
were authored by Vishwas Manral, Donald Eastlake, and Jeffrey authored by Vishwas Manral, Donald Eastlake, and Jeffrey Schiller
Schiller respectively. respectively.
Thanks are due to Wajdi Feghali, Brian Weis, Cheryl Madson, Dan Thanks are due to Wajdi Feghali, Brian Weis, Cheryl Madson, Dan
Harkins, Paul Wouters, Ran Atkinson, Scott Fluhrer, Tero Kivinen, and Harkins, Paul Wouters, Ran Atkinson, Scott Fluhrer, Tero Kivinen, and
Valery Smyslov for insightful feedback on this draft. Valery Smyslov for insightful feedback on this draft.
[[[ This paragraph exists so that the nits checker doesn't barf. It [[[ This paragraph exists so that the nits checker doesn't barf. It
is to be removed before this is published as an RFC. [RFC2404] is to be removed before this is published as an RFC. [RFC2404]
[RFC2405] [RFC2410] [RFC2451] [RFC3566] [RFC3602] [RFC3686] [RFC4309] [RFC2405] [RFC2410] [RFC2451] [RFC3566] [RFC3602] [RFC3686] [RFC4309]
[RFC4543] ]]] [RFC4543] ]]]
 End of changes. 11 change blocks. 
22 lines changed or deleted 18 lines changed or added

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