Internet Engineering Task Force (IETF) D. McGrew
Request for Comments: 7321 Cisco Systems
Obsoletes: 4835 P. Hoffman
Category: Standards Track VPN Consortium
ISSN: 2070-1721 August 2014
Internet Engineering Task Force (IETF) D. McGrew
Request for Comments: 7321 Cisco Systems
Obsoletes: 4835 P. Hoffman
Category: Standards Track VPN Consortium
ISSN: 2070-1721 August 2014
Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)
封装安全有效负载（ESP）和身份验证头（AH）的密码算法实现要求和使用指南
Abstract
摘要
This document updates the Cryptographic Algorithm Implementation Requirements for the Encapsulating Security Payload (ESP) and Authentication Header (AH). It also adds usage guidance to help in the selection of these algorithms.
本文档更新了封装安全有效负载（ESP）和身份验证头（AH）的加密算法实现要求。它还添加了使用指南，以帮助选择这些算法。
ESP and AH protocols make use of various cryptographic algorithms to provide confidentiality and/or data origin authentication to protected data communications in the IP Security (IPsec) architecture. To ensure interoperability between disparate implementations, the IPsec standard specifies a set of mandatory-to-implement algorithms. This document specifies the current set of mandatory-to-implement algorithms for ESP and AH, specifies algorithms that should be implemented because they may be promoted to mandatory at some future time, and also recommends against the implementation of some obsolete algorithms. Usage guidance is also provided to help the user of ESP and AH best achieve their security goals through appropriate choices of cryptographic algorithms.
ESP和AH协议利用各种加密算法为IP安全（IPsec）体系结构中受保护的数据通信提供机密性和/或数据源身份验证。为了确保不同实现之间的互操作性，IPsec标准指定了一组强制实现算法。本文件规定了为ESP和AH实施算法的当前强制集合，规定了应实施的算法，因为这些算法可能在未来某个时间升级为强制算法，还建议不要实施一些过时的算法。还提供了使用指南，以帮助ESP和AH的用户通过选择适当的加密算法来最好地实现其安全目标。
This document obsoletes RFC 4835.
本文件淘汰了RFC 4835。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7321.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7321.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Implementation Requirements . . . . . . . . . . . . . . . . . 4
2.1. ESP Authenticated Encryption (Combined Mode Algorithms) . 4
2.2. ESP Encryption Algorithms . . . . . . . . . . . . . . . . 4
2.3. ESP Authentication Algorithms . . . . . . . . . . . . . . 5
2.4. AH Authentication Algorithms . . . . . . . . . . . . . . 5
2.5. Summary of Changes from RFC 4835 . . . . . . . . . . . . 5
3. Usage Guidance . . . . . . . . . . . . . . . . . . . . . . . 5
4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Authenticated Encryption . . . . . . . . . . . . . . . . 7
4.2. Encryption Transforms . . . . . . . . . . . . . . . . . . 7
4.3. Authentication Transforms . . . . . . . . . . . . . . . . 7
5. Algorithm Diversity . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Implementation Requirements . . . . . . . . . . . . . . . . . 4
2.1. ESP Authenticated Encryption (Combined Mode Algorithms) . 4
2.2. ESP Encryption Algorithms . . . . . . . . . . . . . . . . 4
2.3. ESP Authentication Algorithms . . . . . . . . . . . . . . 5
2.4. AH Authentication Algorithms . . . . . . . . . . . . . . 5
2.5. Summary of Changes from RFC 4835 . . . . . . . . . . . . 5
3. Usage Guidance . . . . . . . . . . . . . . . . . . . . . . . 5
4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Authenticated Encryption . . . . . . . . . . . . . . . . 7
4.2. Encryption Transforms . . . . . . . . . . . . . . . . . . 7
4.3. Authentication Transforms . . . . . . . . . . . . . . . . 7
5. Algorithm Diversity . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
The Encapsulating Security Payload (ESP) [RFC4303] and the Authentication Header (AH) [RFC4302] are the mechanisms for applying cryptographic protection to data being sent over an IPsec Security Association (SA) [RFC4301].
封装安全有效负载（ESP）[RFC4303]和身份验证头（AH）[RFC4302]是对通过IPsec安全关联（SA）[RFC4301]发送的数据应用加密保护的机制。
To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms. This ensures that there is at least one algorithm that all implementations will have in common. This document specifies the current set of mandatory-to-implement algorithms for ESP and AH, specifies algorithms that should be implemented because they may be promoted to mandatory at some future time, and also recommends against the implementation of some obsolete algorithms. Usage guidance is also provided to help the user of ESP and AH best achieve their security goals through appropriate choices of mechanisms.
为了确保不同实现之间的互操作性，有必要指定一组强制实现算法。这确保了至少有一个算法是所有实现的共同点。本文件规定了为ESP和AH实施算法的当前强制集合，规定了应实施的算法，因为这些算法可能在未来某个时间升级为强制算法，还建议不要实施一些过时的算法。还提供了使用指南，以帮助ESP和AH的用户通过适当的机制选择，最好地实现其安全目标。
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.
密码学的本质是新算法不断出现，现有算法不断受到攻击。今天被认为很强大的算法明天可能会被证明很弱。考虑到这一点，实现算法的强制选择应该是保守的，以便最大限度地降低其快速受损的可能性。还应考虑性能方面的考虑，因为IPsec的许多使用都是在性能受到关注的环境中进行的。
The ESP and AH mandatory-to-implement algorithm(s) may need to change over time to adapt to new developments in cryptography. For this reason, the specification of the mandatory-to-implement algorithms is not included in the main IPsec, ESP, or AH specifications, but is instead placed in this document. 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, this document identifies such algorithms, as they are known today. There is no guarantee that the algorithms that we predict will be mandatory in the future will actually be so. All algorithms known today are subject to cryptographic attack and may be broken in the future.
实现算法所必需的ESP和AH可能需要随着时间的推移而改变，以适应密码学的新发展。因此，主要IPsec、ESP或AH规范中未包含强制实现算法的规范，而是放在本文档中。理想情况下，明天的强制实现算法在强制执行时应该已经在大多数IPsec实现中可用。为了促进这一点，本文件确定了这些算法，正如今天所知。我们预测的算法在未来将是强制性的，但这并不能保证这些算法实际上是强制性的。目前已知的所有算法都会受到加密攻击，将来可能会被破坏。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
We define some additional keywords here:
我们在这里定义了一些额外的关键字：
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.
必须-该术语的含义与必须相同。然而，我们预计在将来的某个时候，这种算法将不再是必须的。
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+这个词的意思与SHOULD相同。然而，标记为SHOULD+的算法很可能会在将来某个时候被提升为必须的。
This section specifies the cryptographic algorithms that MUST be implemented, and provides guidance about ones that SHOULD or SHOULD NOT be implemented.
本节指定了必须实现的加密算法，并提供了关于应该或不应该实现的加密算法的指导。
In the following sections, all AES modes are for 128-bit AES. 192-bit and 256-bit AES MAY be supported for those modes, but the requirements here are for 128-bit AES.
在以下部分中，所有AES模式均适用于128位AES。这些模式可能支持192位和256位AES，但此处的要求适用于128位AES。
ESP combined mode algorithms provide both confidentiality and authentication services; in cryptographic terms, these are authenticated encryption algorithms [RFC5116]. Authenticated encryption transforms are listed in the ESP encryption transforms IANA registry.
ESP组合模式算法提供保密和认证服务；在密码术语中，这些是经过身份验证的加密算法[RFC5116]。已验证的加密转换列在ESP encryption transforms IANA注册表中。
Requirement Authenticated Encryption Algorithm
----------- ----------------------------------
SHOULD+ AES-GCM with a 16 octet ICV [RFC4106]
MAY AES-CCM [RFC4309]
Requirement Authenticated Encryption Algorithm
----------- ----------------------------------
SHOULD+ AES-GCM with a 16 octet ICV [RFC4106]
MAY AES-CCM [RFC4309]
Requirement Encryption Algorithm
----------- --------------------------
MUST NULL [RFC2410]
MUST AES-CBC [RFC3602]
MAY AES-CTR [RFC3686]
MAY TripleDES-CBC [RFC2451]
MUST NOT DES-CBC [RFC2405]
Requirement Encryption Algorithm
----------- --------------------------
MUST NULL [RFC2410]
MUST AES-CBC [RFC3602]
MAY AES-CTR [RFC3686]
MAY TripleDES-CBC [RFC2451]
MUST NOT DES-CBC [RFC2405]
Requirement Authentication Algorithm (notes)
----------- -----------------------------
MUST HMAC-SHA1-96 [RFC2404]
SHOULD+ AES-GMAC with AES-128 [RFC4543]
SHOULD AES-XCBC-MAC-96 [RFC3566]
MAY NULL [RFC4303]
Requirement Authentication Algorithm (notes)
----------- -----------------------------
MUST HMAC-SHA1-96 [RFC2404]
SHOULD+ AES-GMAC with AES-128 [RFC4543]
SHOULD AES-XCBC-MAC-96 [RFC3566]
MAY NULL [RFC4303]
Note that the requirement level for NULL authentication depends on the type of encryption used. When using authenticated encryption from Section 2.1, the requirement for NULL encryption is the same as the requirement for the authenticated encryption itself. When using the encryption from Section 2.2, the requirement for NULL encryption is truly "MAY"; see Section 3 for more detail.
请注意，空身份验证的要求级别取决于所使用的加密类型。当使用第2.1节中的认证加密时，空加密的要求与认证加密本身的要求相同。当使用第2.2节中的加密时，空加密的要求确实是“可能”；详见第3节。
The requirements for AH are the same as for ESP Authentication Algorithms, except that NULL authentication is inapplicable.
AH的要求与ESP身份验证算法的要求相同，只是空身份验证不适用。
The following is a summary of the changes from RFC 4835.
以下是RFC 4835的变更摘要。
Old New
Requirement Requirement Algorithm (notes)
---- ----------- -----------------
MAY SHOULD+ AES-GCM with a 16 octet ICV [RFC4106]
MAY SHOULD+ AES-GMAC with AES-128 [RFC4543]
MUST- MAY TripleDES-CBC [RFC2451]
SHOULD NOT MUST NOT DES-CBC [RFC2405]
SHOULD+ SHOULD AES-XCBC-MAC-96 [RFC3566]
SHOULD MAY AES-CTR [RFC3686]
Old New
Requirement Requirement Algorithm (notes)
---- ----------- -----------------
MAY SHOULD+ AES-GCM with a 16 octet ICV [RFC4106]
MAY SHOULD+ AES-GMAC with AES-128 [RFC4543]
MUST- MAY TripleDES-CBC [RFC2451]
SHOULD NOT MUST NOT DES-CBC [RFC2405]
SHOULD+ SHOULD AES-XCBC-MAC-96 [RFC3566]
SHOULD MAY AES-CTR [RFC3686]
Since ESP and AH can be used in several different ways, this document provides guidance on the best way to utilize these mechanisms.
由于ESP和AH可以以几种不同的方式使用，因此本文件提供了利用这些机制的最佳方式的指南。
ESP can provide confidentiality, data origin authentication, or the combination of both of those security services. AH provides only data origin authentication. Background information on those security services is available [RFC4949]. In the following, we shorten "data origin authentication" to "authentication".
ESP可以提供机密性、数据源身份验证或这两种安全服务的组合。AH仅提供数据源身份验证。有关这些安全服务的背景信息可参见[RFC4949]。在下文中，我们将“数据源身份验证”缩短为“身份验证”。
Providing both confidentiality and authentication offers the best security. If confidentiality is not needed, providing authentication can still be useful. Confidentiality without authentication is not effective [DP07] and therefore SHOULD NOT be used. We describe each of these cases in more detail below.
同时提供机密性和身份验证可以提供最佳的安全性。如果不需要保密，提供身份验证仍然是有用的。未经认证的保密性无效[DP07]，因此不应使用。我们将在下文中详细描述每一种情况。
To provide both confidentiality and authentication, an authenticated encryption transform from Section 2.1 SHOULD be used in ESP, in conjunction with NULL authentication. Alternatively, an ESP encryption transform and ESP authentication transform MAY be used together. It is NOT RECOMMENDED to use ESP with NULL authentication in conjunction with AH; some configurations of this combination of services have been shown to be insecure [PD10].
为了提供机密性和身份验证，ESP中应使用第2.1节中的经过身份验证的加密转换以及空身份验证。或者，可以同时使用ESP加密转换和ESP身份验证转换。不建议将带有空身份验证的ESP与AH结合使用；这种服务组合的某些配置已被证明是不安全的[PD10]。
To provide authentication without confidentiality, an authentication transform MUST be used in either ESP or AH. The IPsec community generally prefers ESP with NULL encryption over AH. AH is still required in some protocols and operational environments when there are security-sensitive options in the IP header, such as source routing headers; ESP inherently cannot protect those IP options. It is not possible to provide effective confidentiality without authentication, because the lack of authentication undermines the trustworthiness of encryption [B96][V02]. Therefore, an encryption transform MUST NOT be used with a NULL authentication transform (unless the encryption transform is an authenticated encryption transform from Section 2.1).
要在不保密的情况下提供身份验证，必须在ESP或AH中使用身份验证转换。IPsec社区通常更喜欢使用空加密的ESP而不是AH。在某些协议和操作环境中，当IP报头中存在安全敏感选项（如源路由报头）时，仍然需要AH；ESP本身无法保护这些IP选项。没有身份验证就不可能提供有效的保密性，因为缺乏身份验证会破坏加密的可信度[B96][V02]。因此，加密转换不得与空身份验证转换一起使用（除非加密转换是第2.1节中的身份验证加密转换）。
Triple-DES SHOULD NOT be used in any scenario in which multiple gigabytes of data will be encrypted with a single key. As a 64-bit block cipher, it leaks information about plaintexts above that "birthday bound" [M13]. Triple-DES CBC is listed as a MAY implement for the sake of backwards compatibility, but its use is discouraged.
在任何情况下都不应使用三重DES，在这种情况下，使用一个密钥对多个GB的数据进行加密。作为一种64位分组密码，它会泄露“生日界限”上方的明文信息[M13]。为了向后兼容，Triple-DES CBC被列为一种可能的实现，但不鼓励使用它。
This section explains the principles behind the implementation requirements described above.
本节解释了上述实施要求背后的原则。
The algorithms listed as "MAY implement" are not meant to be endorsed over other non-standard alternatives. All of the algorithms that appeared in [RFC4835] are included in this document, for the sake of continuity. In some cases, these algorithms have moved from being "SHOULD implement" to "MAY implement".
列为“可能实现”的算法并不意味着要优于其他非标准替代方案。为了保持连续性，[RFC4835]中出现的所有算法都包含在本文档中。在某些情况下，这些算法已经从“应该实现”变为“可能实现”。
This document encourages the use of authenticated encryption algorithms because they can provide significant efficiency and throughput advantages, and the tight binding between authentication and encryption can be a security advantage [RFC5116].
本文档鼓励使用经过身份验证的加密算法，因为它们可以提供显著的效率和吞吐量优势，并且身份验证和加密之间的紧密绑定可以是一种安全优势[RFC5116]。
AES-GCM [RFC4106] brings significant performance benefits [KKGEGD], has been incorporated into IPsec recommendations [RFC6379], and has emerged as the preferred authenticated encryption method in IPsec and other standards.
AES-GCM[RFC4106]带来了显著的性能优势[KKGEGD]，已被纳入IPsec建议[RFC6379]，并已成为IPsec和其他标准中首选的身份验证加密方法。
Since ESP encryption is optional, support for the "NULL" algorithm is required to maintain consistency with the way services are negotiated. Note that while authentication and encryption can each be "NULL", they MUST NOT both be "NULL" [RFC4301] [H10].
由于ESP加密是可选的，因此需要支持“NULL”算法以保持与服务协商方式的一致性。请注意，虽然身份验证和加密都可以为“NULL”，但它们不能同时为“NULL”[RFC4301][H10]。
AES Counter Mode (AES-CTR) is an efficient encryption method, but it provides no authentication capability. The AES-GCM authenticated encryption method has all of the advantages of AES-CTR, while also providing authentication. Thus, this document moves AES-CTR from a SHOULD to a MAY.
AES计数器模式（AES-CTR）是一种有效的加密方法，但它不提供身份验证功能。AES-GCM认证加密方法具有AES-CTR的所有优点，同时还提供认证。因此，本文件将AES-CTR从“应该”移至“可能”。
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 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 Standard (AES), while at the same time its performance and efficiency are worse. Thus, its use in new implementations is discouraged.
三重数据加密标准（TDES）因其较小的块大小而过时；与所有64位分组密码一样，它不应用于用单个密钥加密超过1GB的数据[M13]。它的密钥大小小于高级加密标准（AES），同时其性能和效率也较差。因此，不鼓励在新的实现中使用它。
The Data Encryption Standard (DES) is obsolete because of its small key size and small block size. There have been publicly demonstrated and open-design special-purpose cracking hardware. Therefore, its use is has been changed to MUST NOT in this document.
数据加密标准（DES）因其密钥大小和块大小小而过时。已经有公开展示和开放设计的专用破解硬件。因此，在本文件中，其用途已更改为不得。
AES-GMAC provides good security along with performance advantages, even over HMAC-MD5. In addition, it uses the same internal components as AES-GCM and is easy to implement in a way that shares components with that authenticated encryption algorithm.
AES-GMAC提供了良好的安全性和性能优势，甚至优于HMAC-MD5。此外，它使用与AES-GCM相同的内部组件，并且易于实现，与经过身份验证的加密算法共享组件。
The MD5 hash function has been found to not meet its goal of collision resistance; it is so weak that its use in digital signatures is highly discouraged [RFC6151]. There have been theoretical results against HMAC-MD5, but that message authentication
MD5哈希函数已被发现不符合其抗冲突的目标；它是如此之弱，以至于它在数字签名中的使用是非常不受欢迎的[RFC6151]。已有针对HMAC-MD5的理论结果，但消息身份验证
code does not seem to have a practical vulnerability. Thus, it may not be urgent to remove HMAC-MD5 from the existing protocols.
代码似乎没有实际的漏洞。因此，从现有协议中删除HMAC-MD5可能并不迫切。
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 believed to be secure.
已经发现SHA-1没有达到其抗碰撞的目标。然而，HMAC-SHA-1不依赖于该财产，HMAC-SHA-1被认为是安全的。
HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 are believed to provide a good security margin, and they perform adequately on many platforms. However, these algorithms are not recommended for implementation in this document, because HMAC-SHA-1 support is widespread and its security is good, AES-GMAC provides good security with better performance, and Authenticated Encryption algorithms do not need any authentication methods.
HMAC-SHA-256、HMAC-SHA-384和HMAC-SHA-512被认为提供了良好的安全余量，并且它们在许多平台上都有足够的性能。但是，由于HMAC-SHA-1支持广泛且安全性良好，AES-GMAC提供了良好的安全性和更好的性能，并且认证加密算法不需要任何认证方法，因此本文档不建议实施这些算法。
AES-XCBC has not seen widespread deployment, despite being previously recommended as a SHOULD+ in RFC 4835. Thus, this document lists it only as a SHOULD.
AES-XCBC并没有得到广泛的部署，尽管之前在RFC4835中被推荐为“应+”。因此，本文件仅将其列为“应”。
When the AES cipher was first adopted, it was decided to continue encouraging the implementation of Triple-DES, in order to provide 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 block cipher, its security is inadequate at high data rates (see Section 4.2). Its performance in software and Field-Programmable Gate Arrays (FPGAs) is considerably 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, or in environments where its performance could not keep up the requirements, the rationale of retaining Triple-DES to provide algorithm diversity is disappearing. (Of course, this does not change the rationale of retaining Triple-DES in IPsec implementations for backwards compatibility.)
首次采用AES密码时，决定继续鼓励实现三重DES，以提供算法多样性。但随着时间的推移，三重DES作为AES替代品的可行性逐渐降低。由于它是64位分组密码，因此在高数据速率下其安全性不足（见第4.2节）。它在软件和现场可编程门阵列（FPGA）中的性能比AES差得多。由于在高数据速率环境中，或在其性能无法满足要求的环境中，不可能使用三重DES作为AES的替代方案，因此保留三重DES以提供算法多样性的原理正在消失。（当然，这不会改变在IPsec实现中保留三重DES以实现向后兼容性的基本原理。）
Recent discussions in the IETF have started considering how to make the selection of a different cipher that could provide algorithm diversity in IPsec and other IETF standards. That work is expected to take a long time and involve discussions among many participants and organizations.
IETF最近的讨论已经开始考虑如何选择不同的密码，以在IPsec和其他IETF标准中提供算法多样性。这项工作预计需要很长时间，需要许多参与者和组织进行讨论。
It is important to bear in mind that it is very unlikely that 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 conventional mode of operation). The only reason that algorithm diversity deserves any consideration is because there would be large problems if such a flaw were found.
重要的是要记住，在AES中不太可能发现可利用的缺陷（例如，当在常规操作模式中使用AES时，所需的已知明文少于1 TB的缺陷）。算法多样性值得考虑的唯一原因是，如果发现这样的缺陷，将会有很大的问题。
Some of the wording herein was adapted from [RFC4835], the document that this one obsoletes. That RFC itself borrows from earlier RFCs, notably RFC 4305 and 4307. RFC 4835, RFC 4305, and RFC 4307 were authored by Vishwas Manral, Donald Eastlake, and Jeffrey Schiller respectively.
本文中的一些措辞是从[RFC4835]改编而来的，该文件已经过时。该RFC本身借鉴了早期的RFC，尤其是RFC 4305和4307。RFC4835、RFC4305和RFC4307分别由Vishwas Manral、Donald Eastlake和Jeffrey Schiller编写。
Thanks are due to Wajdi Feghali, Brian Weis, Cheryl Madson, Dan Harkins, Paul Wouters, Ran Atkinson, Scott Fluhrer, Tero Kivinen, and Valery Smyslov for insightful feedback on this document.
感谢Wajdi Feghali、Brian Weis、Cheryl Madson、Dan Harkins、Paul Wouters、Ran Atkinson、Scott Fluhrer、Tero Kivinen和Valery Smyslov对本文件的深刻反馈。
The security of a system that uses cryptography 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 to date leads us to believe that they will likely remain secure into the foreseeable future. However, this is not necessarily forever. Therefore, we expect that revisions of that document will be issued from time to time to reflect the current best practice in this area.
本文件涉及ESP和AH使用的加密算法的选择，特别是强制算法的选择。本文件中确定为“必须实现”或“应该实现”的算法目前尚不存在漏洞，迄今为止的密码研究使我们相信，在可预见的未来，它们可能仍然安全。然而，这不一定是永远的。因此，我们期望该文件的修订将不时印发，以反映这一领域目前的最佳做法。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[B96] Bellovin, S., "Problem areas for the IP security protocols", Proceedings of the Sixth Usenix Unix Security Symposium, 1996.
[B96]Bellovin，S.，“IP安全协议的问题领域”，第六届Usenix Unix安全研讨会论文集，1996年。
[DP07] Degabriele, J. and K. Paterson, "Attacking the IPsec Standards in Encryption-only Configurations", IEEE Symposium on Privacy and Security, 2007.
[DP07]Degabriele，J.和K.Paterson，“在仅加密配置中攻击IPsec标准”，IEEE隐私和安全研讨会，2007年。
[H10] Hoban, A., "Using Intel AES New Instructions and PCLMULQDQ to Significantly Improve IPSec Performance on Linux", Intel White Paper, August 2010.
[H10]Hoban，A.“使用英特尔AES新指令和PCLMULQDQ显著提高Linux上的IPSec性能”，英特尔白皮书，2010年8月。
[KKGEGD] Kounavis, M., Kang, X., Grewal, K., Eszenyi, M., Gueron, S., and D. Durham, "Encrypting the Internet", SIGCOMM, 2010.
[KKGEGD]Kounanis，M.，Kang，X.，Grewal，K.，Eszenyi，M.，Gueron，S.，和D.Durham，“加密互联网”，SIGCOMM，2010年。
[M13] McGrew, D., "Impossible plaintext cryptanalysis and probable-plaintext collision attacks of 64-bit block cipher modes", IACR ePrint, 2012.
[M13]McGrew，D.，“不可能的明文密码分析和64位分组密码模式的可能明文冲突攻击”，IACR ePrint，2012年。
[PD10] Paterson, K. and J. Degabriele, "On the (in)security of IPsec in MAC-then-encrypt configurations", CCS '10, ACM Conference on Computer and Communications Security, 2010.
[PD10]Paterson，K.和J.Degabriele，“关于MAC加密配置中IPsec的（in）安全”，CCS'10，计算机和通信安全ACM会议，2010年。
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[RFC2404]Madson，C.和R.Glenn，“在ESP和AH中使用HMAC-SHA-1-96”，RFC 2404，1998年11月。
[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.
[RFC2405]Madson，C.和N.Doraswamy，“带显式IV的ESP DES-CBC密码算法”，RFC 2405，1998年11月。
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[RFC2410]Glenn，R.和S.Kent，“空加密算法及其在IPsec中的使用”，RFC 2410，1998年11月。
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[RFC2451]Pereira，R.和R.Adams，“ESP CBC模式密码算法”，RFC 2451，1998年11月。
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.
[RFC3566]Frankel，S.和H.Herbert，“AES-XCBC-MAC-96算法及其在IPsec中的使用”，RFC 3566，2003年9月。
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[RFC3602]Frankel，S.，Glenn，R.，和S.Kelly，“AES-CBC密码算法及其在IPsec中的使用”，RFC 3602，2003年9月。
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.
[RFC3686]Housley，R.，“使用高级加密标准（AES）计数器模式和IPsec封装安全有效负载（ESP）”，RFC 3686，2004年1月。
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005.
[RFC4106]Viega，J.和D.McGrew，“在IPsec封装安全有效负载（ESP）中使用Galois/计数器模式（GCM）”，RFC 4106，2005年6月。
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, December 2005.
[RFC4309]Housley，R.，“使用高级加密标准（AES）CCM模式和IPsec封装安全有效载荷（ESP）”，RFC 4309，2005年12月。
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, May 2006.
[RFC4543]McGrew，D.和J.Viega，“Galois消息认证码（GMAC）在IPsec ESP和AH中的使用”，RFC 4543，2006年5月。
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007.
[RFC4835]Manral，V.“封装安全有效载荷（ESP）和身份验证头（AH）的密码算法实现要求”，RFC 4835，2007年4月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC4949]Shirey，R.，“互联网安全术语表，第2版”，RFC 49492007年8月。
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, January 2008.
[RFC5116]McGrew，D.“认证加密的接口和算法”，RFC 5116，2008年1月。
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March 2011.
[RFC6151]Turner，S.和L.Chen，“MD5消息摘要和HMAC-MD5算法的更新安全注意事项”，RFC 61512011年3月。
[RFC6379] Law, L. and J. Solinas, "Suite B Cryptographic Suites for IPsec", RFC 6379, October 2011.
[RFC6379]Law，L.和J.Solinas，“用于IPsec的套件B加密套件”，RFC 6379，2011年10月。
[V02] Vaudenay, S., "Security Flaws Induced by CBC Padding - Applications to SSL, IPSEC, WTLS ...", EUROCRYPT, 2002.
[V02]Vaudenay，S.，“CBC填充引起的安全缺陷-SSL、IPSEC、WTLS的应用…”，EUROCRYPT，2002年。
Authors' Addresses
作者地址
David McGrew Cisco Systems
思科系统公司
EMail: mcgrew@cisco.com
EMail: mcgrew@cisco.com
Paul Hoffman VPN Consortium
保罗·霍夫曼VPN联盟
EMail: paul.hoffman@vpnc.org
EMail: paul.hoffman@vpnc.org