4305
PROPOSED STANDARD
Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) (Obsoleted)
Authors: D. Eastlake 3rd
Date: December 2005
Area: sec
Working Group: ipsec
Stream: IETF
Abstract
The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Encapsulating Security Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPsec Security Association (SA). To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to-implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time. [STANDARDS-TRACK]
RFC 4305
Obsoleted by: 4835 PROPOSED STANDARD
Errata Exist
Network Working Group D. Eastlake 3rd
Request for Comments: 4305 Motorola Laboratories
Obsoletes: <a href="./rfc2404">2404</a>, <a href="./rfc2406">2406</a> December 2005
Category: Standards Track
<span class="h1">Cryptographic Algorithm Implementation Requirements for</span>
<span class="h1">Encapsulating Security Payload (ESP) and Authentication Header (AH)</span>
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The IPsec series of protocols makes use of various cryptographic
algorithms in order to provide security services. The Encapsulating
Security Payload (ESP) and the Authentication Header (AH) provide two
mechanisms for protecting data being sent over an IPsec Security
Association (SA). To ensure interoperability between disparate
implementations, it is necessary to specify a set of mandatory-to-
implement algorithms to ensure that there is at least one algorithm
that all implementations will have available. This document defines
the current set of mandatory-to-implement algorithms for ESP and AH
as well as specifying algorithms that should be implemented because
they may be promoted to mandatory at some future time.
<span class="grey">Eastlake Standards Track [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc4305">RFC 4305</a> Cryptographic Algorithms for ESP & AH December 2005</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Requirements Terminology ........................................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Algorithm Selection .............................................<a href="#page-3">3</a>
<a href="#section-3.1">3.1</a>. Encapsulating Security Payload .............................<a href="#page-3">3</a>
<a href="#section-3.1.1">3.1.1</a>. ESP Encryption and Authentication Algorithms ........<a href="#page-4">4</a>
<a href="#section-3.1.2">3.1.2</a>. ESP Combined Mode Algorithms ........................<a href="#page-4">4</a>
<a href="#section-3.2">3.2</a>. Authentication Header ......................................<a href="#page-5">5</a>
<a href="#section-4">4</a>. Security Considerations .........................................<a href="#page-5">5</a>
<a href="#section-5">5</a>. Acknowledgement .................................................<a href="#page-5">5</a>
<a href="#section-6">6</a>. Changes from <a href="./rfc2402">RFC 2402</a> and 2406 ..................................<a href="#page-6">6</a>
<a href="#section-7">7</a>. Normative References ............................................<a href="#page-6">6</a>
<a href="#section-8">8</a>. Informative References ..........................................<a href="#page-7">7</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Encapsulating Security Payload (ESP) and the Authentication
Header (AH) provide two mechanisms for protecting data being sent
over an IPsec Security Association (SA) [<a href="#ref-IPsec" title=""Security Architecture for the Internet Protocol"">IPsec</a>, <a href="#ref-ESP" title=""IP Encapsulating Security Payload (ESP)"">ESP</a>, <a href="#ref-AH" title=""IP Authentication Header"">AH</a>]. To ensure
interoperability between disparate implementations, it is necessary
to specify a set of mandatory-to-implement algorithms to ensure that
there is at least one algorithm that all implementations will have
available. This document defines the current set of mandatory-to-
implement algorithms for ESP and AH as well as specifying algorithms
that should be implemented because they may be promoted to mandatory
at some future time.
The nature of cryptography is that new algorithms surface
continuously and existing algorithms are continuously attacked. An
algorithm believed to be strong today may be demonstrated to be weak
tomorrow. Given this, the choice of mandatory-to-implement algorithm
should be conservative so as to minimize the likelihood of it being
compromised quickly. Thought should also be given to performance
considerations as many uses of IPsec will be in environments where
performance is a concern.
Finally, we need to recognize that the mandatory-to-implement
algorithm(s) may need to change over time to adapt to the changing
world. For this reason, the selection of mandatory-to-implement
algorithms is not included the main IPsec, ESP, or AH specifications.
It is instead placed in this document. As the choice of algorithm
changes, only this document should need to be updated.
Ideally, the mandatory-to-implement algorithm of tomorrow should
already be available in most implementations of IPsec by the time it
is made mandatory. To facilitate this, we will attempt to identify
such algorithms (as they are known today) in this document. There is
<span class="grey">Eastlake Standards Track [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc4305">RFC 4305</a> Cryptographic Algorithms for ESP & AH December 2005</span>
no guarantee that the algorithms we believe today may be mandatory in
the future will in fact become so. All algorithms known today are
subject to cryptographic attack and may be broken in the future.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Requirements Terminology</span>
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
"MAY" that appear in this document are to be interpreted as described
in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
We define some additional terms here:
SHOULD+ This term means the same as SHOULD. However, it is
likely that an algorithm marked as SHOULD+ will be
promoted at some 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.
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.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Algorithm Selection</span>
For IPsec implementations to interoperate, they must support one or
more security algorithms in common. This section specifies the
security algorithm implementation requirements for standards-
conformant ESP and AH implementations. The security algorithms
actually used for any particular ESP or AH security association are
determined by a negotiation mechanism, such as the Internet Key
Exchange (IKE [<a href="./rfc2409" title=""The Internet Key Exchange (IKE)"">RFC2409</a>, <a href="#ref-IKEv2" title=""Internet Key Exchange (IKEv2) Protocol"">IKEv2</a>]) or pre-establishment.
Of course, additional standard and proprietary algorithms beyond
those listed below can be implemented.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Encapsulating Security Payload</span>
The implementation conformance requirements for security algorithms
for ESP are given in the tables below. See <a href="#section-2">Section 2</a> for definitions
of the values in the "Requirement" column.
<span class="grey">Eastlake Standards Track [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc4305">RFC 4305</a> Cryptographic Algorithms for ESP & AH December 2005</span>
<span class="h4"><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a>. ESP Encryption and Authentication Algorithms</span>
These tables list encryption and authentication algorithms for the
IPsec Encapsulating Security Payload protocol.
Requirement Encryption Algorithm (notes)
----------- --------------------
MUST NULL (1)
MUST- TripleDES-CBC [<a href="./rfc2451">RFC2451</a>]
SHOULD+ AES-CBC with 128-bit keys [<a href="./rfc3602" title=""The AES-CBC Cipher Algorithm and Its Use with IPsec"">RFC3602</a>]
SHOULD AES-CTR [<a href="./rfc3686" title=""Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)"">RFC3686</a>]
SHOULD NOT DES-CBC [<a href="./rfc2405" title=""The ESP DES-CBC Cipher Algorithm With Explicit IV"">RFC2405</a>] (3)
Requirement Authentication Algorithm (notes)
----------- ------------------------
MUST HMAC-SHA1-96 [<a href="./rfc2404" title=""The Use of HMAC-SHA-1-96 within ESP and AH"">RFC2404</a>]
MUST NULL (1)
SHOULD+ AES-XCBC-MAC-96 [<a href="./rfc3566" title=""The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec"">RFC3566</a>]
MAY HMAC-MD5-96 [<a href="./rfc2403" title=""The Use of HMAC-MD5-96 within ESP and AH"">RFC2403</a>] (2)
Notes:
(1) Since ESP encryption and authentication are optional, support for
the two "NULL" algorithms is required to maintain consistency
with the way these services are negotiated. Note that while
authentication and encryption can each be "NULL", they MUST NOT
both be "NULL".
(2) Weaknesses have become apparent in MD5; however, these should not
affect the use of MD5 with HMAC.
(3) DES, with its small key size and publicly demonstrated and open-
design special-purpose cracking hardware, is of questionable
security for general use.
<span class="h4"><a class="selflink" id="section-3.1.2" href="#section-3.1.2">3.1.2</a>. ESP Combined Mode Algorithms</span>
As specified in [<a href="#ref-ESP" title=""IP Encapsulating Security Payload (ESP)"">ESP</a>], combined mode algorithms are supported that
provide both confidentiality and authentication services. Support of
such algorithms will require proper structuring of ESP
implementations. Under many circumstances, combined mode algorithms
provide significant efficiency and throughput advantages. Although
there are no suggested or required combined algorithms at this time,
AES-CCM [<a href="#ref-CCM" title=""Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)"">CCM</a>], which has been adopted as the preferred mode for
security in IEEE 802.11 [<a href="#ref-802.11i" title="IEEE Std 802.11i">802.11i</a>], is expected to be of interest in
the near future.
<span class="grey">Eastlake Standards Track [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc4305">RFC 4305</a> Cryptographic Algorithms for ESP & AH December 2005</span>
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Authentication Header</span>
The implementation conformance requirements for security algorithms
for AH are given below. See <a href="#section-2">Section 2</a> for definitions of the values
in the "Requirement" column. As you would suspect, all of these
algorithms are authentication algorithms.
Requirement Algorithm (notes)
----------- ---------
MUST HMAC-SHA1-96 [<a href="./rfc2404" title=""The Use of HMAC-SHA-1-96 within ESP and AH"">RFC2404</a>]
SHOULD+ AES-XCBC-MAC-96 [<a href="./rfc3566" title=""The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec"">RFC3566</a>]
MAY HMAC-MD5-96 [<a href="./rfc2403" title=""The Use of HMAC-MD5-96 within ESP and AH"">RFC2403</a>] (1)
Note:
(1) Weaknesses have become apparent in MD5; however, these should not
affect the use of MD5 with HMAC.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
The security of cryptographic-based systems depends on both the
strength of the cryptographic algorithms chosen and the strength of
the keys used with those algorithms. The security also depends on
the engineering and administration of the protocol used by the system
to ensure that there are no non-cryptographic ways to bypass the
security of the overall system.
This document concerns itself with the selection of cryptographic
algorithms for the use of ESP and AH, specifically with the selection
of mandatory-to-implement algorithms. The algorithms identified in
this document as "MUST implement" or "SHOULD implement" are not known
to be broken at the current time, and cryptographic research so far
leads us to believe that they will likely remain secure into the
foreseeable future. However, this is not necessarily forever. We
would therefore expect that new revisions of this document will be
issued from time to time that reflect the current best practice in
this area.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Acknowledgement</span>
Much of the wording herein was adapted from <a href="./rfc4307">RFC 4307</a>, "Cryptographic
Algorithms for Use in the Internet Key Exchange Version 2", by
Jeffrey I. Schiller.
<span class="grey">Eastlake Standards Track [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc4305">RFC 4305</a> Cryptographic Algorithms for ESP & AH December 2005</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Changes from <a href="./rfc2402">RFC 2402</a> and 2406</span>
[<a id="ref-RFC2402">RFC2402</a>] and [<a href="./rfc2406" title=""IP Encapsulating Security Payload (ESP)"">RFC2406</a>] defined the IPsec Authentication Header and
IPsec Encapsulating Security Payload. Each specified the
implementation requirements for cryptographic algorithms for their
respective protocols. They have now been replaced with [<a href="#ref-AH" title=""IP Authentication Header"">AH</a>] and
[<a href="#ref-ESP" title=""IP Encapsulating Security Payload (ESP)"">ESP</a>], which do not specify cryptographic algorithm implementation
requirements, and this document, which specifies such requirements
for both [<a href="#ref-AH" title=""IP Authentication Header"">AH</a>] and [<a href="#ref-ESP" title=""IP Encapsulating Security Payload (ESP)"">ESP</a>].
The implementation requirements are compared below:
Old Old New
Req. RFC(s) Requirement Algorithm (notes)
--- ------ ----------- ---------
MUST 2406 SHOULD NOT DES-CBC [<a href="./rfc2405" title=""The ESP DES-CBC Cipher Algorithm With Explicit IV"">RFC2405</a>] (1)
MUST 2402 2406 MAY HMAC-MD5-96 [<a href="./rfc2403" title=""The Use of HMAC-MD5-96 within ESP and AH"">RFC2403</a>]
MUST 2402 2406 MUST HMAC-SHA1-96 [<a href="./rfc2404" title=""The Use of HMAC-SHA-1-96 within ESP and AH"">RFC2404</a>]
Note:
(1) The IETF deprecated the use of single DES years ago and has not
included it in any new standard for some time (see IESG note on
the first page of [<a href="./rfc2407" title=""The Internet IP Security Domain of Interpretation for ISAKMP"">RFC2407</a>]). But this document represents the
first standards-track recognition of that deprecation by
specifying that implementations SHOULD NOT provide single DES.
The US Government National Institute of Standards and Technology
(NIST) has formally recognized the weakness of single DES by a
notice published in the 26 July 2004 US Government Federal
Register (Docket No. 040602169-4169-01) proposing to withdraw it
as a US Government Standard. Triple DES remains approved by both
the IETF and NIST.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Normative References</span>
[<a id="ref-AH">AH</a>] Kent, S., "IP Authentication Header", <a href="./rfc4302">RFC 4302</a>, December
2005.
[<a id="ref-ESP">ESP</a>] Kent, S., "IP Encapsulating Security Payload (ESP)", <a href="./rfc4303">RFC</a>
<a href="./rfc4303">4303</a>, December 2005.
[<a id="ref-IPsec">IPsec</a>] Kent, S., "Security Architecture for the Internet
Protocol", <a href="./rfc4301">RFC 4301</a>, December 2005.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
<span class="grey">Eastlake Standards Track [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc4305">RFC 4305</a> Cryptographic Algorithms for ESP & AH December 2005</span>
[<a id="ref-RFC2403">RFC2403</a>] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
ESP and AH", <a href="./rfc2403">RFC 2403</a>, November 1998.
[<a id="ref-RFC2404">RFC2404</a>] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", <a href="./rfc2404">RFC 2404</a>, November 1998.
[<a id="ref-RFC2405">RFC2405</a>] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
Algorithm With Explicit IV", <a href="./rfc2405">RFC 2405</a>, November 1998.
[<a id="ref-RFC3566">RFC3566</a>] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96
Algorithm and Its Use With IPsec", <a href="./rfc3566">RFC 3566</a>, September
2003.
[<a id="ref-RFC3602">RFC3602</a>] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", <a href="./rfc3602">RFC 3602</a>, September
2003.
[<a id="ref-RFC3686">RFC3686</a>] Housley, R., "Using Advanced Encryption Standard (AES)
Counter Mode With IPsec Encapsulating Security Payload
(ESP)", <a href="./rfc3686">RFC 3686</a>, January 2004.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Informative References</span>
[<a id="ref-802.11i">802.11i</a>] LAN/MAN Specific Requirements Part 11: Wireless Medium
Access Control (MAC) and physical layer (PHY)
specifications: Medium Access Control (MAC) Security
Enhancements, IEEE Std 802.11i, June 2004.
[<a id="ref-JIS">JIS</a>] Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", <a href="./rfc4307">RFC 4307</a>,
December 2005.
[<a id="ref-CCM">CCM</a>] Housley, R., "Using Advanced Encryption Standard (AES)
Counter Mode With IPsec Encapsulating Security Payload
(ESP)", <a href="./rfc3686">RFC 3686</a>, January 2004.
[<a id="ref-IKEv2">IKEv2</a>] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", <a href="./rfc4306">RFC 4306</a>, December 2005.
[<a id="ref-RFC791">RFC791</a>] Postel, J., "Internet Protocol", STD 5, <a href="./rfc791">RFC 791</a>,
September 1981.
[<a id="ref-RFC2402">RFC2402</a>] Kent, S. and R. Atkinson, "IP Authentication Header", <a href="./rfc2402">RFC</a>
<a href="./rfc2402">2402</a>, November 1998.
[<a id="ref-RFC2406">RFC2406</a>] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", <a href="./rfc2406">RFC 2406</a>, November 1998.
<span class="grey">Eastlake Standards Track [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc4305">RFC 4305</a> Cryptographic Algorithms for ESP & AH December 2005</span>
[<a id="ref-RFC2407">RFC2407</a>] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", <a href="./rfc2407">RFC 2407</a>, November 1998.
[<a id="ref-RFC2409">RFC2409</a>] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", <a href="./rfc2409">RFC 2409</a>, November 1998.
Author's Address
Donald E. Eastlake 3rd
Motorola Laboratories
155 Beaver Street
Milford, MA 01757 USA
Phone: +1-508-786-7554 (w)
+1-508-634-2066 (h)
EMail: [email protected]
<span class="grey">Eastlake Standards Track [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc4305">RFC 4305</a> Cryptographic Algorithms for ESP & AH December 2005</span>
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
[email protected].
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Eastlake Standards Track [Page 9]
Annotations
Select text to annotate