draft-ietf-ipsecme-esp-ah-reqts-05.txt   draft-ietf-ipsecme-esp-ah-reqts-06.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 13, 2014 April 11, 2014 Expires: October 20, 2014 April 18, 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-05 draft-ietf-ipsecme-esp-ah-reqts-06
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 34
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.
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 October 20, 2014.
This Internet-Draft will expire on October 13, 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 38 skipping to change at page 2, line 39
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 . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . . . . . 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 39 skipping to change at page 3, line 41
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. 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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this 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.
skipping to change at page 7, line 50 skipping to change at page 7, line 50
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 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 RFC4305. Thus this draft lists it being recommended as a SHOULD+ in RFC 4835. 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
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
skipping to change at page 8, line 37 skipping to change at page 8, line 37
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 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 earlier
which borrows in turn from [RFC4307]. RFC4835, RFC4305, and RFC4307 RFCs, notably RFC 4305 and 4307. RFC 4835, RFC 4305, and RFC 4307
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 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.
7. IANA Considerations [[[ 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. 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.
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
skipping to change at page 10, line 17 skipping to change at page 10, line 21
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 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
Requirements for Encapsulating Security Payload (ESP) and ESP and AH", RFC 2404, November 1998.
Authentication Header (AH)", RFC 4305, December 2005.
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the [RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
Internet Key Exchange Version 2 (IKEv2)", RFC 4307, Algorithm With Explicit IV", RFC 2405, November 1998.
December 2005.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", RFC 2410, November 1998.
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, November 1998.
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm
and Its Use With IPsec", RFC 3566, September 2003.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602, September
2003.
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES)
Counter Mode With IPsec Encapsulating Security Payload
(ESP)", RFC 3686, January 2004.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec Encapsulating Security Payload (ESP)", RFC
4106, June 2005.
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
Mode with IPsec Encapsulating Security Payload (ESP)", RFC
4309, December 2005.
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message
Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543,
May 2006.
[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)", RFC 4835, April 2007. Authentication Header (AH)", RFC 4835, April 2007.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
4949, August 2007. 4949, August 2007.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, January 2008. Encryption", RFC 5116, January 2008.
skipping to change at page 11, line 4 skipping to change at page 11, line 30
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
13600 Dulles Technology Drive
Herndon, Virginia 20171
USA
Phone: 408 525 8651
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. 17 change blocks. 
22 lines changed or deleted 53 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/