draft-ietf-ipsecme-esp-ah-reqts-10.txt   rfc7321.txt 
Network Working Group D. McGrew Internet Engineering Task Force (IETF) D. McGrew
Internet-Draft Cisco Systems Request for Comments: 7321 Cisco Systems
Obsoletes: 4835 (if approved) P. Hoffman Obsoletes: 4835 P. Hoffman
Intended status: Standards Track VPN Consortium Category: Standards Track VPN Consortium
Expires: November 17, 2014 May 16, 2014 ISSN: 2070-1721 August 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-10
Abstract Abstract
This Internet Draft is a standards track proposal to update the This document updates the Cryptographic Algorithm Implementation
Cryptographic Algorithm Implementation Requirements for ESP and AH; Requirements for the Encapsulating Security Payload (ESP) and
it also adds usage guidance to help in the selection of these Authentication Header (AH). It also adds usage guidance to help in
algorithms. the selection of these algorithms.
The Encapsulating Security Payload (ESP) and Authentication Header ESP and AH protocols make use of various cryptographic algorithms to
(AH) protocols make use of various cryptographic algorithms to
provide confidentiality and/or data origin authentication to provide confidentiality and/or data origin authentication to
protected data communications in the IP Security (IPsec) protected data communications in the IP Security (IPsec)
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.
This document obsoletes RFC 4835. This document obsoletes RFC 4835.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at http://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference http://www.rfc-editor.org/info/rfc7321.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 17, 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
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . 5
2.4. AH Authentication Algorithms . . . . . . . . . . . . . . 5 2.4. AH Authentication Algorithms . . . . . . . . . . . . . . 5
2.5. Summary of Changes from RFC 4835 . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . 7
4.2. Encryption Transforms . . . . . . . . . . . . . . . . . . 6 4.2. Encryption Transforms . . . . . . . . . . . . . . . . . . 7
4.3. Authentication Transforms . . . . . . . . . . . . . . . . 7 4.3. Authentication Transforms . . . . . . . . . . . . . . . . 7
5. Algorithm Diversity . . . . . . . . . . . . . . . . . . . . . 8 5. Algorithm Diversity . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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 3, line 22 skipping to change at page 3, line 29
against the implementation of some obsolete algorithms. Usage against the implementation of some obsolete algorithms. Usage
guidance is also provided to help the user of ESP and AH best achieve guidance is also provided to help the user of ESP and AH best achieve
their security goals through appropriate choices of mechanisms. their security goals through appropriate choices of mechanisms.
The nature of cryptography is that new algorithms surface The nature of cryptography is that new algorithms surface
continuously and existing algorithms are continuously attacked. An continuously and existing algorithms are continuously attacked. An
algorithm believed to be strong today may be demonstrated to be weak algorithm believed to be strong today may be demonstrated to be weak
tomorrow. Given this, the choice of mandatory-to-implement algorithm tomorrow. Given this, the choice of mandatory-to-implement algorithm
should be conservative so as to minimize the likelihood of it being should be conservative so as to minimize the likelihood of it being
compromised quickly. Thought should also be given to performance compromised quickly. Thought should also be given to performance
considerations as many uses of IPsec will be in environments where considerations, as many uses of IPsec will be in environments where
performance is a concern. performance is a concern.
The ESP and AH mandatory-to-implement algorithm(s) may need to change The ESP and AH mandatory-to-implement algorithm(s) may need to change
over time to adapt to new developments in cryptography. For this over time to adapt to new developments in cryptography. For this
reason, the specification of the mandatory-to-implement algorithms is reason, the specification of the mandatory-to-implement algorithms is
not included in the main IPsec, ESP, or AH specifications, but is not included in the main IPsec, ESP, or AH specifications, but is
instead placed in this document. Ideally, the mandatory-to-implement instead placed in this document. Ideally, the mandatory-to-implement
algorithm of tomorrow should already be available in most algorithm of tomorrow should already be available in most
implementations of IPsec by the time it is made mandatory. To implementations of IPsec by the time it is made mandatory. To
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. predict will be mandatory in the future will actually be so. All
All algorithms known today are subject to cryptographic attack and algorithms known today are subject to cryptographic attack and may be
may be broken in the future. 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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
Following [RFC4835], we define some additional key words: We define some additional keywords here:
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.
2. Implementation Requirements 2. Implementation Requirements
skipping to change at page 6, line 28 skipping to change at page 6, line 47
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".
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
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 document moves AES-CTR from a providing authentication. Thus, this document moves AES-CTR from a
SHOULD 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. are 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 has been changed to MUST NOT in this document. 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
skipping to change at page 7, line 37 skipping to change at page 8, line 11
collision resistance; it is so weak that its use in digital collision resistance; it is so weak that its use in digital
signatures is highly discouraged [RFC6151]. There have been signatures is highly discouraged [RFC6151]. There have been
theoretical results against HMAC-MD5, but that message authentication theoretical results against HMAC-MD5, but that message authentication
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 HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 are believed to provide
provide a good security margin, and they perform adequately on many 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 document, because HMAC-SHA-1 support is implementation in this document, because HMAC-SHA-1 support is
widespread and its security is good, AES-GMAC provides good security widespread and its security is good, AES-GMAC provides good security
with better performance, and Authenticated Encryption algorithms do with better performance, and Authenticated Encryption algorithms do
not need any 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 RFC 4835. Thus this draft lists it recommended as a SHOULD+ in RFC 4835. Thus, this document 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
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 Field-Programmable
worse than that of AES. Since it would not be possible to use Gate Arrays (FPGAs) is considerably worse than that of AES. Since it
Triple-DES as an alternative to AES in high data rate environments, would not be possible to use Triple-DES as an alternative to AES in
or in environments where its performance could not keep up the high data rate environments, or in environments where its performance
requirements, the rationale of retaining Triple-DES to provide could not keep up the requirements, the rationale of retaining
algorithm diversity is disappearing. (Of course, this does not Triple-DES to provide algorithm diversity is disappearing. (Of
change the rationale of retaining Triple-DES in IPsec implementations course, this does not change the rationale of retaining Triple-DES in
for backwards compatibility.) IPsec implementations 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 unlikely that an
an exploitable flaw will be found in AES (e.g., a flaw that required 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 there would be large
would be caused if such a flaw were found would be so large. problems if such a flaw were found.
6. Acknowledgements 6. Acknowledgements
Some of the wording herein was adapted from [RFC4835], the document Some of the wording herein was adapted from [RFC4835], the document
that this one obsoletes. That RFC itself borrows from earlier RFCs, that this one obsoletes. That RFC itself borrows from earlier RFCs,
notably RFC 4305 and 4307. RFC 4835, RFC 4305, and RFC 4307 were notably RFC 4305 and 4307. RFC 4835, RFC 4305, and RFC 4307 were
authored by Vishwas Manral, Donald Eastlake, and Jeffrey Schiller authored by Vishwas Manral, Donald Eastlake, and Jeffrey 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 document.
[[[ This paragraph exists so that the nits checker doesn't barf. It
is to be removed before this is published as an RFC. [RFC2404]
[RFC2405] [RFC2410] [RFC2451] [RFC3566] [RFC3602] [RFC3686] [RFC4309]
[RFC4543] ]]]
7. IANA Considerations
None.
8. Security Considerations 7. 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.
This document concerns itself with the selection of cryptographic This document concerns itself with the selection of cryptographic
algorithms for the use of ESP and AH, specifically with the selection algorithms for the use of ESP and AH, specifically with the selection
of mandatory-to-implement algorithms. The algorithms identified in of mandatory-to-implement algorithms. The algorithms identified in
this document as "MUST implement" or "SHOULD implement" are not known this document as "MUST implement" or "SHOULD implement" are not known
to be broken at the current time, and cryptographic research so far to be broken at the current time, and cryptographic research to date
leads us to believe that they will likely remain secure into the leads us to believe that they will likely remain secure into the
foreseeable future. However, this is not necessarily forever. We foreseeable future. However, this is not necessarily forever.
would therefore expect that new revisions of this document will be Therefore, we expect that revisions of that document will be issued
issued from time to time that reflect the current best practice in from time to time to reflect the current best practice in this area.
this area.
9. References 8. References
9.1. Normative References 8.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.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005. 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005. 4303, December 2005.
9.2. Informative References 8.2. Informative References
[B96] Bellovin, S., "Problem areas for the IP security protocols [B96] Bellovin, S., "Problem areas for the IP security
(Proceedings of the Sixth Usenix Unix Security protocols", 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. Intel White Paper, August 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", IACR ePrint, 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", CCS '10, ACM
on Computer and Communications Security, ACM CCS)", 2010. Conference on Computer and Communications Security, 2010.
[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", RFC 2404, November 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", RFC 2405, November 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", RFC 2410, November 1998. Its Use With IPsec", RFC 2410, November 1998.
skipping to change at page 11, line 31 skipping to change at page 11, line 35
Encryption", RFC 5116, January 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",
RFC 6151, March 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", RFC 6379, October 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.
Authors' Addresses Authors' Addresses
David McGrew David McGrew
Cisco Systems Cisco Systems
Email: mcgrew@cisco.com EMail: mcgrew@cisco.com
Paul Hoffman Paul Hoffman
VPN Consortium VPN Consortium
Email: paul.hoffman@vpnc.org EMail: paul.hoffman@vpnc.org
 End of changes. 40 change blocks. 
89 lines changed or deleted 85 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/