< draft-ietf-ipsecme-esp-ah-reqts-00.txt   draft-ietf-ipsecme-esp-ah-reqts-01.txt >
Internet Engineering Task Force D. McGrew Network Working Group D. McGrew
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track W. Feghali Intended status: Standards Track W. Feghali
Expires: September 12, 2013 Intel Corp. Expires: March 10, 2014 Intel Corp.
March 11, 2013 P. Hoffman
VPN Consortium
September 06, 2013
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-00 draft-ietf-ipsecme-esp-ah-reqts-01
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 1, line 34 skipping to change at page 1, line 36
architecture. To ensure interoperability between disparate architecture. To ensure interoperability between disparate
implementations, the IPsec standard specifies a set of mandatory-to- implementations, the IPsec standard specifies a set of mandatory-to-
implement algorithms. This document specifies the current set of implement algorithms. This document specifies the current set of
mandatory-to-implement algorithms for ESP and AH, specifies mandatory-to-implement algorithms for ESP and AH, specifies
algorithms that should be implemented because they may be promoted to algorithms that should be implemented because they may be promoted to
mandatory at some future time, and also recommends against the mandatory at some future time, and also recommends against the
implementation of some obsolete algorithms. Usage guidance is also implementation of some obsolete algorithms. Usage guidance is also
provided to help the user of ESP and AH best achieve their security provided to help the user of ESP and AH best achieve their security
goals through appropriate choices of cryptographic algorithms. goals through appropriate choices of cryptographic algorithms.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 March 10, 2014.
This Internet-Draft will expire on September 12, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Document History . . . . . . . . . . . . . . . . . . . . . 4 2. Implementation Requirements . . . . . . . . . . . . . . . . . 4
2. Implementation Requirements . . . . . . . . . . . . . . . . . 5 2.1. ESP Authenticated Encryption (Combined Mode Algorithms) . 4
2.1. ESP Authenticated Encryption (Combined Mode Algorithms) . 5 2.2. ESP Encryption Algorithms . . . . . . . . . . . . . . . . 4
2.2. ESP Encryption Algorithms . . . . . . . . . . . . . . . . 5 2.3. ESP Authentication Algorithms . . . . . . . . . . . . . . 4
2.3. ESP Authentication Algorithms . . . . . . . . . . . . . . 5 2.4. AH Authentication Algorithms . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Authenticated Encryption . . . . . . . . . . . . . . . . 6
4.1. Authenticated Encryption . . . . . . . . . . . . . . . . . 8 4.2. Encryption Transforms . . . . . . . . . . . . . . . . . . 6
4.2. Encryption Transforms . . . . . . . . . . . . . . . . . . 8 4.3. Authentication Transforms . . . . . . . . . . . . . . . . 7
4.3. Authentication Transforms . . . . . . . . . . . . . . . . 9 5. Algorithm Diversity . . . . . . . . . . . . . . . . . . . . . 7
5. Algorithm Diversity . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
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
Association (SA) [RFC4301]. Association (SA) [RFC4301].
To ensure interoperability between disparate implementations, it is To ensure interoperability between disparate implementations, it is
necessary to specify a set of mandatory-to-implement algorithms. necessary to specify a set of mandatory-to-implement algorithms.
skipping to change at page 4, line 20 skipping to change at page 4, line 13
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 SHOULD NOT+ This term means the same as SHOULD NOT. However, it is
likely that an algorithm marked as SHOULD NOT+ will be deprecated likely that an algorithm marked as SHOULD NOT+ will be deprecated
to a MUST NOT in a future version of this document. 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].
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.
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 [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-128-CBC [RFC3602]
MAY AES-CTR [RFC3686] MAY AES-CTR [RFC3686]
MAY TripleDES-CBC [RFC2451] MAY TripleDES-CBC [RFC2451]
SHOULD NOT+ DES-CBC [RFC2405] SHOULD 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 [RFC4543]
SHOULD AES-XCBC-MAC-96 [RFC3566] SHOULD AES-XCBC-MAC-96 [RFC3566]
MAY NULL [RFC4303] MAY NULL [RFC4303]
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
Requirement Requirement Algorithm (notes) Old New
---- ----------- ----------------- Requirement Requirement Algorithm (notes)
MAY SHOULD+ AES-GCM [RFC4106] ---- ----------- -----------------
MAY SHOULD+ AES-GMAC [RFC4543] MAY SHOULD+ AES-GCM [RFC4106]
MUST- MAY TripleDES-CBC [RFC2451] MAY SHOULD+ AES-GMAC [RFC4543]
SHOULD+ SHOULD AES-XCBC-MAC-96 [RFC3566] MUST- MAY TripleDES-CBC [RFC2451]
SHOULD MAY AES-CTR [RFC3686] SHOULD+ SHOULD AES-XCBC-MAC-96 [RFC3566]
SHOULD MAY AES-CTR [RFC3686]
3. Usage Guidance 3. Usage Guidance
Since ESP and AH can be used in several different ways, this note 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 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.
skipping to change at page 8, line 12 skipping to change at page 6, line 22
"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
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 note, 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 note encourages the use of authenticated encryption algorithms This document encourages the use of authenticated encryption
because they can provide significant efficiency and throughput algorithms because they can provide significant efficiency and
advantages, and the tight binding between authentication and throughput advantages, and the tight binding between authentication
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
emerged as the preferred authenticated encryption method in IPsec and emerged as the preferred authenticated encryption method in IPsec and
other standards. other standards.
4.2. Encryption Transforms 4.2. Encryption Transforms
Since ESP encryption is optional, support for the "NULL" algorithm is Since ESP encryption is optional, support for the "NULL" algorithm is
required to maintain consistency with the way services are required to maintain consistency with the way services are
negotiated. Note that while authentication and encryption can each negotiated. Note that while authentication and encryption can each
be "NULL", they MUST NOT both be "NULL" [RFC4301] [H10]. be "NULL", they MUST NOT both be "NULL" [RFC4301] [H10].
AES Counter Mode (AES-CTR) is an efficient encryption method, but it AES Counter Mode (AES-CTR) is an efficient encryption method, but it
provides no authentication capability. The AES-GCM authenticated provides no authentication capability. The AES-GCM authenticated
encryption method has all of the advantages of AES-CTR, while also encryption method has all of the advantages of AES-CTR, while also
providing authentication. Thus this note moves AES-CTR from a SHOULD providing authentication. Thus this document moves AES-CTR from a
to a MAY. SHOULD to a MAY.
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
skipping to change at page 9, line 26 skipping to change at page 7, line 38
code does not seem to have a practical vulnerability. Thus, it may code does not seem to have a practical vulnerability. Thus, it may
not be urgent to remove HMAC-MD5 from the existing protocols. not be urgent to remove HMAC-MD5 from the existing protocols.
SHA-1 has been found to not meet its goal of collision resistance. 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 However, HMAC-SHA-1 does not rely on this property, and HMAC-SHA-1 is
believed to be secure. believed to be secure.
The HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 are believed to 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 provide a good security margin, and they perform adequately on many
platforms. However, these algorithms are not recommended for platforms. However, these algorithms are not recommended for
implementation in this note, because HMAC-SHA-1 support is widespread implementation in this document, because HMAC-SHA-1 support is
and its security is good, AES-GMAC provides good security with better widespread and its security is good, AES-GMAC provides good security
performance, and Authenticated Encryption algorithms do not need any with better performance, and Authenticated Encryption algorithms do
authentication methods. not need any authentication methods.
AES-XCBC has not seen widespread deployment, despite being previously AES-XCBC has not seen widespread deployment, despite being previously
being recommended as a SHOULD+ in RFC4305. Thus this draft lists it being recommended as a SHOULD+ in RFC4305. Thus this draft lists it
only as a SHOULD. only as a SHOULD.
5. Algorithm Diversity 5. Algorithm Diversity
When the AES cipher was first adopted, it was decided to continue When the AES cipher was first adopted, it was decided to continue
encouraging the implementation of Triple-DES, in order to provide encouraging the implementation of Triple-DES, in order to provide
algorithm diversity. But the passage of time has eroded the algorithm diversity. But the passage of time has eroded the
skipping to change at page 10, line 21 skipping to change at page 8, line 14
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 compability.)
It may be prudent to begin considering the selection of a different Recent discussions in the IETF have started considering how to make
cipher that could provide algorithm diversity in IPsec and other IETF the selection of a different cipher that could provide algorithm
standards. There are many important criteria to consider, which are diversity in IPsec and other IETF standards. That work is expected
out of scope for this note. These issues have been taken up in to take a long time and involve discussions among many participants
recent work [draft-mcgrew-standby-cipher]. 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
skipping to change at page 12, line 7 skipping to change at page 8, line 40
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 Scott Fluhrer, Dan Harkins, Brian Weis, and Cheryl
Madson for insightful feedback on this draft. Madson for insightful feedback on this draft.
7. IANA Considerations 7. IANA Considerations
This memo includes no request to IANA. 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
the engineering and administration of the protocol used by the system the engineering and administration of the protocol used by the system
to ensure that there are no non-cryptographic ways to bypass the to ensure that there are no non-cryptographic ways to bypass the
security of the overall system. security of the overall system.
skipping to change at page 14, line 13 skipping to change at page 9, line 24
this area. this area.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
ESP and AH", 1998. ESP and AH", RFC 2403, November 1998.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", 1998. ESP and AH", RFC 2404, November 1998.
[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher [RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
Algorithm With Explicit IV", 1998. Algorithm With Explicit IV", RFC 2405, November 1998.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", 1998. Its Use With IPsec", RFC 2410, November 1998.
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm
and Its Use With IPsec", 2003. and Its Use With IPsec", RFC 3566, September 2003.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", 2003. Algorithm and Its Use with IPsec", RFC 3602, September
2003.
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES)
Counter Mode With IPsec Encapsulating Security Payload Counter Mode With IPsec Encapsulating Security Payload
(ESP)", 2004. (ESP)", RFC 3686, January 2004.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec Encapsulating Security Payload (ESP)", (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC
2005. 4106, June 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", 2005. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload", 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
9.2. Informative References 9.2. Informative References
[B96] Bellovin, S., "Problem areas for the IP security protocols [B96] Bellovin, S., "Problem areas for the IP security protocols
(Proceedings of the Sixth Usenix Unix Security (Proceedings of the Sixth Usenix Unix Security
Symposium)", 1996. Symposium)", 1996.
[DP07] Degabriele, J. and K. Paterson, "Attacking the IPsec [DP07] Degabriele, J. and K. Paterson, "Attacking the IPsec
Standards in Encryption-only Configurations (IEEE Standards in Encryption-only Configurations (IEEE
Symposium on Privacy and Security)", 2007. Symposium on Privacy and Security)", 2007.
[H10] Hoban, A., "Using Intel AES New Instructions and PCLMULQDQ [H10] Hoban, A., "Using Intel AES New Instructions and PCLMULQDQ
to Significantly Improve IPSec Performance on Linux", to Significantly Improve IPSec Performance on Linux ",
2010. 2010.
[KKGEGD] Kounavis, M., Kang, X., Grewal, K., Eszenyi, M., Gueron, [KKGEGD] Kounavis, M., Kang, X., Grewal, K., Eszenyi, M., Gueron,
S., and D. Durham, "Encrypting the Internet (SIGCOMM)", S., and D. Durham, "Encrypting the Internet (SIGCOMM)",
2010. 2010.
[M13] McGrew, D., "Impossible plaintext cryptanalysis and [M13] McGrew, D., "Impossible plaintext cryptanalysis and
probable-plaintext collision attacks of 64-bit block probable-plaintext collision attacks of 64-bit block
cipher modes", 2012. cipher modes ", 2012.
[PD10] Paterson, K. and J. Degabriele, "On the (in)security of [PD10] Paterson, K. and J. Degabriele, "On the (in)security of
IPsec in MAC-then-encrypt configurations (ACM Conference IPsec in MAC-then-encrypt configurations (ACM Conference
on Computer and Communications Security, ACM CCS)", 2010. on Computer and Communications Security, ACM CCS)", 2010.
[RFC4305] Eastlake, D., "Cryptographic Algorithm Implementation [RFC4305] Eastlake, D., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)". Authentication Header (AH)", RFC 4305, December 2005.
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", 2005. Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
December 2005.
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
Mode with IPsec Encapsulating Security Payload (ESP)", Mode with IPsec Encapsulating Security Payload (ESP)", RFC
2005. 4309, December 2005.
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation [RFC4835] Manral, V., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)". Authentication Header (AH)", RFC 4835, April 2007.
[RFC4949] Shirley, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
2007. 4949, August 2007.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", 2008. Encryption", RFC 5116, January 2008.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms", for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
2011. RFC 6151, March 2011.
[RFC6379] Law, L. and J. Solinas, "Suite B Cryptographic Suites for [RFC6379] Law, L. and J. Solinas, "Suite B Cryptographic Suites for
IPsec", 2011. IPsec", RFC 6379, October 2011.
[V02] Vaudenay, S., "Security Flaws Induced by CBC Padding - [V02] Vaudenay, S., "Security Flaws Induced by CBC Padding -
Applications to SSL, IPSEC, WTLS ... (EUROCRYPT)", 2002. Applications to SSL, IPSEC, WTLS ... (EUROCRYPT)", 2002.
[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.
Authors' Addresses Authors' Addresses
David McGrew David McGrew
Cisco Systems Cisco Systems
13600 Dulles Technology Drive 13600 Dulles Technology Drive
Herndon, Virginia 20171 Herndon, Virginia 20171
USA USA
Phone: 408 525 8651 Phone: 408 525 8651
Email: mcgrew@cisco.com Email: mcgrew@cisco.com
Wajdi Feghali Wajdi Feghali
Intel Corp. Intel Corp.
75 Reed Road 75 Reed Road
Hudson, Massachusetts Hudson, Massachusetts
USA USA
Phone:
Email: wajdi.k.feghali@intel.com Email: wajdi.k.feghali@intel.com
Paul Hoffman
VPN Consortium
Email: paul.hoffman@vpnc.org
 End of changes. 42 change blocks. 
122 lines changed or deleted 101 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/