Internet Engineering Task Force (IETF) Y. Nir
Request for Comments: 8247 Dell EMC
Obsoletes: 4307 T. Kivinen
Updates: 7296
Category: Standards Track P. Wouters
ISSN: 2070-1721 Red Hat
D. Migault
Ericsson
September 2017
Internet Engineering Task Force (IETF) Y. Nir
Request for Comments: 8247 Dell EMC
Obsoletes: 4307 T. Kivinen
Updates: 7296
Category: Standards Track P. Wouters
ISSN: 2070-1721 Red Hat
D. Migault
Ericsson
September 2017
Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)
Internet密钥交换协议版本2（IKEv2）的算法实现要求和使用指南
Abstract
摘要
The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document updates RFC 7296 and obsoletes RFC 4307 in defining the current algorithm implementation requirements and usage guidance for IKEv2, and does minor cleaning up of the IKEv2 IANA registry. This document does not update the algorithms used for packet encryption using IPsec Encapsulating Security Payload (ESP).
IPsec系列协议利用各种加密算法来提供安全服务。Internet密钥交换（IKE）协议用于协商IPsec安全关联（IPsec SA）参数，例如应使用哪些算法。为了确保不同实现之间的互操作性，有必要指定一组算法实现要求和使用指南，以确保所有实现至少支持一种算法。本文件更新了RFC 7296，淘汰了RFC 4307，定义了IKEv2的当前算法实现要求和使用指南，并对IKEv2 IANA注册表进行了小规模清理。本文档不更新使用IPsec封装安全有效负载（ESP）进行数据包加密的算法。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8247.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8247.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
1.2. Updating Algorithm Implementation Requirements and
Usage Guidance .............................................4
1.3. Updating Algorithm Requirement Levels ......................4
1.4. Document Audience ..........................................5
2. Algorithm Selection .............................................5
2.1. Type 1 - IKEv2 Encryption Algorithm Transforms .............5
2.2. Type 2 - IKEv2 Pseudorandom Function Transforms ............7
2.3. Type 3 - IKEv2 Integrity Algorithm Transforms ..............8
2.4. Type 4 - IKEv2 Diffie-Hellman Group Transforms .............9
2.5. Summary of Changes from RFC 4307 ..........................11
3. IKEv2 Authentication ...........................................11
3.1. IKEv2 Authentication Method ...............................12
3.1.1. Recommendations for RSA Key Length .................13
3.2. Digital Signature Recommendations .........................13
4. Algorithms for Internet of Things ..............................14
5. Security Considerations ........................................15
6. IANA Considerations ............................................15
7. References .....................................................16
7.1. Normative References ......................................16
7.2. Informative References ....................................17
Acknowledgements ..................................................17
Authors' Addresses ................................................19
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
1.2. Updating Algorithm Implementation Requirements and
Usage Guidance .............................................4
1.3. Updating Algorithm Requirement Levels ......................4
1.4. Document Audience ..........................................5
2. Algorithm Selection .............................................5
2.1. Type 1 - IKEv2 Encryption Algorithm Transforms .............5
2.2. Type 2 - IKEv2 Pseudorandom Function Transforms ............7
2.3. Type 3 - IKEv2 Integrity Algorithm Transforms ..............8
2.4. Type 4 - IKEv2 Diffie-Hellman Group Transforms .............9
2.5. Summary of Changes from RFC 4307 ..........................11
3. IKEv2 Authentication ...........................................11
3.1. IKEv2 Authentication Method ...............................12
3.1.1. Recommendations for RSA Key Length .................13
3.2. Digital Signature Recommendations .........................13
4. Algorithms for Internet of Things ..............................14
5. Security Considerations ........................................15
6. IANA Considerations ............................................15
7. References .....................................................16
7.1. Normative References ......................................16
7.2. Informative References ....................................17
Acknowledgements ..................................................17
Authors' Addresses ................................................19
The Internet Key Exchange (IKE) protocol [RFC7296] is used to negotiate the parameters of the IPsec SA, such as the encryption and authentication algorithms and the keys for the protected communications between the two endpoints. The IKE protocol itself is
Internet密钥交换（IKE）协议[RFC7296]用于协商IPsec SA的参数，例如加密和身份验证算法以及两个端点之间受保护通信的密钥。IKE协议本身是
also protected by cryptographic algorithms, which are negotiated between the two endpoints using IKE. Different implementations of IKE may negotiate different algorithms based on their individual local policy. To ensure interoperability, a set of "mandatory-to-implement" IKE cryptographic algorithms is defined.
还受加密算法保护，加密算法在两个端点之间使用IKE进行协商。IKE的不同实现可以基于各自的本地策略协商不同的算法。为了确保互操作性，定义了一组“强制实现”IKE加密算法。
This document describes the parameters of the IKE protocol and updates the IKEv2 specification. It changes the mandatory-to-implement authentication algorithms in Section 4 of [RFC7296] by saying that RSA key lengths of less than 2048 SHOULD NOT be used. It does not describe the cryptographic parameters of the Authentication Header (AH) or ESP protocols.
本文档描述了IKE协议的参数，并更新了IKEv2规范。它改变了[RFC7296]第4节中强制实施认证算法的规定，规定不应使用长度小于2048的RSA密钥。它没有描述身份验证头（AH）或ESP协议的加密参数。
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
When used in the tables in this document, these terms indicate that the listed algorithm MUST, MUST NOT, SHOULD, SHOULD NOT, or MAY be implemented as part of an IKEv2 implementation. Additional terms used in this document are:
在本文件表格中使用时，这些术语表示所列算法必须、不得、应、不应或可能作为IKEv2实现的一部分实现。本文件中使用的其他术语包括：
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+的算法很可能会在将来某个时候被提升为必须的。
SHOULD- This term means the same as SHOULD. However, an algorithm marked as SHOULD- may be deprecated to a MAY in a future version of this document.
应-该术语的含义与应相同。但是，在本文档的未来版本中，标记为“应该”的算法可能会被弃用为“可能”。
MUST- This term means the same as MUST. However, it is expected at some point that this algorithm will no longer be a MUST in a future document. Although its status will be determined at a later time, it is reasonable to expect that if a future revision of a document alters the status of a MUST- algorithm, it will remain at least a SHOULD or a SHOULD- level.
必须-该术语的含义与必须相同。然而，在将来的文档中，该算法将不再是必须的。虽然它的状态将在以后确定，但是可以合理地预期，如果将来的文档修订改变了必须算法的状态，它将至少保持应该或应该级别。
IoT This abbreviation stands for "Internet of Things".
物联网这个缩写代表“物联网”。
The field of cryptography evolves continuously. New, stronger algorithms appear and existing algorithms are found to be less secure than originally thought. Therefore, algorithm implementation requirements and usage guidance need to be updated from time to time to reflect the new reality. The choices for algorithms must be conservative to minimize the risk of algorithm compromise. Algorithms need to be suitable for a wide variety of CPU architectures and device deployments ranging from high-end bulk encryption devices to small low-power IoT devices.
密码学领域不断发展。新的、更强大的算法出现了，而现有的算法被发现不如最初认为的安全。因此，需要不时更新算法实现要求和使用指南，以反映新的现实。算法的选择必须是保守的，以最小化算法妥协的风险。算法需要适合各种CPU架构和设备部署，从高端批量加密设备到小型低功耗物联网设备。
The algorithm implementation requirements and usage guidance may need to change over time to adapt to the changing world. For this reason, the selection of mandatory-to-implement algorithms was removed from the main IKEv2 specification and placed in this separate document.
算法实现要求和使用指南可能需要随着时间的推移而改变，以适应不断变化的世界。因此，从主要的IKEv2规范中删除了实现算法的强制选择，并将其放在单独的文档中。
The mandatory-to-implement algorithm of tomorrow should already be available in most implementations of IKE by the time it is made mandatory. This document attempts to identify and introduce those algorithms for future mandatory-to-implement status. There is no guarantee that the algorithms in use today may become mandatory in the future. Published algorithms are continuously subjected to cryptographic attack and may become too weak or could become completely broken before this document is updated.
当强制执行明天的算法时，它应该已经在大多数IKE实现中可用。本文件试图确定并介绍这些算法，以供未来强制实施状态。目前使用的算法不能保证将来会成为强制性的。已发布的算法会持续受到加密攻击，并且在更新本文档之前可能会变得太弱或完全损坏。
This document provides updated recommendations for the mandatory-to-implement algorithms. As a result, any algorithm listed at the IKEv2 IANA registry not mentioned in this document MAY be implemented. For clarification and consistency with [RFC4307], an algorithm will be denoted here as MAY only when it has been downgraded.
本文件提供了强制执行算法的更新建议。因此，本文件中未提及的IKEv2 IANA注册表中列出的任何算法均可实现。为了澄清并与[RFC4307]保持一致，仅当算法降级时，才会在此处表示为MAY。
Although this document updates the algorithms to keep the IKEv2 communication secure over time, it also aims at providing recommendations so that IKEv2 implementations remain interoperable. IKEv2 interoperability is addressed by an incremental introduction or deprecation of algorithms. In addition, this document also considers the new use cases for IKEv2 deployment, such as Internet of Things (IoT).
尽管本文档更新了算法以保持IKEv2通信的安全性，但它也旨在提供建议，使IKEv2实现保持互操作性。IKEv2互操作性通过增量引入或弃用算法来解决。此外，本文档还考虑了IKEv2部署的新用例，如物联网（IoT）。
It is expected that deprecation of an algorithm is performed gradually. This provides time for various implementations to update their implemented algorithms while remaining interoperable. Unless there are strong security reasons, an algorithm is expected to be downgraded from MUST to MUST- or SHOULD, instead of MUST NOT.
预计将逐步执行算法的弃用。这为各种实现在保持互操作性的同时更新其实现的算法提供了时间。除非有很强的安全性原因，否则一个算法应该从MUST降级到MUST-or-SHOULD，而不是MUST-NOT。
Similarly, an algorithm that has not been mentioned as mandatory-to-implement is expected to be introduced with a SHOULD instead of a MUST.
类似地，一个未被提及为必须实现的算法预计将以“应该”而不是“必须”引入。
The current trend toward Internet of Things and its adoption of IKEv2 requires this specific use case to be taken into account as well. IoT devices are resource-constrained devices and their choice of algorithms are motivated by minimizing the footprint of the code, the computation effort, and the size of the messages to send. This document indicates "(IoT)" when a specified algorithm is specifically listed for IoT devices. Requirement levels that are marked as "IoT" apply to IoT devices and to server-side implementations that might presumably need to interoperate with them, including any general-purpose VPN gateways.
当前物联网的发展趋势及其对IKEv2的采用也需要考虑这个特定的用例。物联网设备是资源受限的设备，它们选择算法的动机是最小化代码占用、计算工作量和要发送的消息大小。当为物联网设备专门列出指定算法时，本文件指出“（物联网）”。标记为“IoT”的需求级别适用于IoT设备和可能需要与之互操作的服务器端实现，包括任何通用VPN网关。
The recommendations of this document mostly target IKEv2 implementers who need to create implementations that meet both high security expectations as well as high interoperability between various vendors and with different versions. Interoperability requires a smooth move to more secure cipher suites. This may differ from a user point of view that may deploy and configure IKEv2 with only the safest cipher suite.
本文档的建议主要针对IKEv2实现者，他们需要创建满足高安全性预期以及不同供应商和不同版本之间的高互操作性的实现。互操作性要求顺利过渡到更安全的密码套件。这可能不同于用户只使用最安全的密码套件部署和配置IKEv2的观点。
This document does not give any recommendations for the use of algorithms, it only gives implementation recommendations regarding implementations. The use of algorithms by a specific user is dictated by their own security policy requirements, which are outside the scope of this document.
本文档没有给出任何关于算法使用的建议，只是给出了有关实现的实现建议。特定用户对算法的使用由其自身的安全策略要求决定，这超出了本文档的范围。
IKEv1 is out of scope of this document. IKEv1 is deprecated and the recommendations of this document must not be considered for IKEv1, as most IKEv1 implementations have been "frozen" and will not be able to update the list of mandatory-to-implement algorithms.
IKEv1不在本文件范围内。IKEv1已被弃用，本文件的建议不得用于IKEv1，因为大多数IKEv1实现已被“冻结”，无法更新强制实现算法的列表。
The algorithms in the table below are negotiated in the Security Association (SA) payload and used for the Encrypted Payload. References to the specification defining these algorithms and the ones in the following subsections are in the IANA registry [IKEV2-IANA]. Some of these algorithms are Authenticated Encryption with Associated Data (AEAD) [RFC5282]. Algorithms that are not AEAD MUST be used in conjunction with one of the integrity algorithms in Section 2.3.
下表中的算法在安全关联（SA）负载中协商，并用于加密负载。IANA注册表[IKEV2-IANA]中提供了定义这些算法的规范以及以下小节中的算法。其中一些算法是关联数据认证加密（AEAD）[RFC5282]。非AEAD的算法必须与第2.3节中的完整性算法结合使用。
+------------------------+----------+-------+---------+
| Name | Status | AEAD? | Comment |
+------------------------+----------+-------+---------+
| ENCR_AES_CBC | MUST | No | (*) |
| ENCR_CHACHA20_POLY1305 | SHOULD | Yes | |
| ENCR_AES_GCM_16 | SHOULD | Yes | (*) |
| ENCR_AES_CCM_8 | SHOULD | Yes | (IoT) |
| ENCR_3DES | MAY | No | |
| ENCR_DES | MUST NOT | No | |
| ENCR_NULL | MUST NOT | No | |
+------------------------+----------+-------+---------+
+------------------------+----------+-------+---------+
| Name | Status | AEAD? | Comment |
+------------------------+----------+-------+---------+
| ENCR_AES_CBC | MUST | No | (*) |
| ENCR_CHACHA20_POLY1305 | SHOULD | Yes | |
| ENCR_AES_GCM_16 | SHOULD | Yes | (*) |
| ENCR_AES_CCM_8 | SHOULD | Yes | (IoT) |
| ENCR_3DES | MAY | No | |
| ENCR_DES | MUST NOT | No | |
| ENCR_NULL | MUST NOT | No | |
+------------------------+----------+-------+---------+
(*) This requirement level is for 128-bit and 256-bit keys. 192-bit keys remain at the MAY level.
（*）此要求级别适用于128位和256位密钥。192位密钥保持在可能的级别。
(IoT) This requirement is for interoperability with IoT. Only 128-bit keys are at the SHOULD level. 192-bit and 256-bit remain at the MAY level.
（物联网）该要求是为了与物联网互操作。只有128位密钥处于应级别。192位和256位保持在可能的水平。
ENCR_AES_CBC is raised from SHOULD+ for 128-bit keys and MAY for 256-bit keys in [RFC4307] to MUST. 192-bit keys remain at the MAY level. ENCR_AES_CBC is the only shared mandatory-to-implement algorithm with RFC 4307 and as a result, it is necessary for interoperability with IKEv2 implementation compatible with RFC 4307.
ENCR_AES_CBC从[RFC4307]中128位密钥的“应+”和256位密钥的“可”提升为“必须”。192位密钥保持在可能的级别。ENCR_AES_CBC是实现RFC 4307算法的唯一共享强制工具，因此，必须与兼容RFC 4307的IKEv2实现实现互操作性。
ENCR_CHACHA20_POLY1305 was not ready to be considered at the time of RFC 4307's publication. It has been recommended by the Crypto Forum Research Group (CFRG) of the IRTF as an alternative to AES-CBC and AES-GCM. It is also being standardized for IPsec for the same reasons. At the time of writing, there were not enough IKEv2 implementations supporting ENCR_CHACHA20_POLY1305 to be able to introduce it at the SHOULD+ level.
在RFC 4307发布时，ENCR_CHACHA20_POLY1305尚未准备好考虑。IRTF的加密论坛研究小组（CFRG）建议将其作为AES-CBC和AES-GCM的替代品。出于同样的原因，IPsec也在对其进行标准化。在撰写本文时，支持ENCR_CHACHA20_POLY1305的IKEv2实现还不足以在“应该+级别”引入它。
ENCR_AES_GCM_16 was not considered in RFC 4307. At the time RFC 4307 was written, AES-GCM was not defined in an IETF document. AES-GCM was defined for ESP in [RFC4106] and later for IKEv2 in [RFC5282]. The main motivation for adopting AES-GCM for ESP is encryption performance compared to AES-CBC. This resulted in AES-GCM being widely implemented for ESP. As the computation load of IKEv2 is relatively small compared to ESP, many IKEv2 implementations have not implemented AES-GCM. For this reason, AES-GCM is not promoted to a greater status than SHOULD. The reason for promotion from MAY to SHOULD is to promote the slightly more secure AEAD method over the traditional encrypt+auth method. Its status is expected to be raised once widely implemented. As the advantage of the shorter (and weaker) Integrity Check Values (ICVs) is minimal, the 8- and 12-octet ICVs remain at the MAY level.
RFC 4307中未考虑ENCR_AES_GCM_16。在编写RFC 4307时，IETF文件中未定义AES-GCM。AES-GCM是在[RFC4106]中为ESP定义的，后来在[RFC5282]中为IKEv2定义的。ESP采用AES-GCM的主要动机是与AES-CBC相比的加密性能。这导致AES-GCM被广泛用于ESP。与ESP相比，IKEv2的计算负载相对较小，因此许多IKEv2实现没有实现AES-GCM。由于这个原因，AES-GCM没有提升到更高的状态。从5月份升级到SHOULD的原因是，与传统的encrypt+auth方法相比，AEAD方法更加安全。一旦广泛实施，其地位有望提高。由于较短（和较弱）完整性检查值（ICV）的优势最小，8和12个八位组ICV保持在5月份的水平。
ENCR_AES_CCM_8 was not considered in RFC 4307. This document considers it as SHOULD be implemented in order to be able to interact with IoT devices. As this case is not a general use case for non-IoT VPNs, its status is expected to remain as SHOULD. The 8-octet size of the ICV is expected to be sufficient for most use cases of IKEv2, as far less packets are exchanged in those cases, and IoT devices want to make packets as small as possible. The SHOULD level is for 128-bit keys, 256-bit keys remains at MAY level.
RFC 4307中未考虑ENCR_AES_CCM_8。本文件认为，为了能够与物联网设备进行交互，应实施物联网。由于这种情况不是非物联网VPN的通用情况，因此其状态预计将保持不变。ICV的8个八位组大小预计足以满足IKEv2的大多数使用情况，因为在这些情况下交换的数据包要少得多，而物联网设备希望使数据包尽可能小。应该级别适用于128位密钥，256位密钥保持在可能的级别。
ENCR_3DES has been downgraded from RFC 4307 MUST- to MAY. All IKEv2 implementations already implement ENCR_AES_CBC, so there is no need to keep support for the much slower ENCR_3DES. In addition, ENCR_CHACHA20_POLY1305 provides a more modern alternative to AES.
ENCR_3DES已从RFC 4307降级至5月。所有IKEv2实现都已经实现了ENCR_AES_CBC，因此没有必要继续支持速度慢得多的ENCR_3DE。此外，ENCR_CHACHA20_POLY1305为AES提供了更现代的替代品。
ENCR_DES can be brute-forced using off-the-shelf hardware. It provides no meaningful security whatsoever and, therefore, MUST NOT be implemented.
ENCR_DES可以使用现成的硬件强制执行。它没有提供任何有意义的安全，因此，决不能实施。
ENCR_NULL was incorrectly specified as MAY in RFC 4307, even when [RFC7296], Section 5 clearly states that it MUST NOT be used. This was fixed and this document now lists ENCR_NULL as MUST NOT.
尽管[RFC7296]第5节明确规定不得使用，但RFC 4307中可能错误地指定了ENCR_NULL。这是固定的，本文档现在列出ENCR_NULL，因为不能。
Transform Type 2 algorithms are pseudorandom functions used to generate pseudorandom values when needed.
变换类型2算法是伪随机函数，用于在需要时生成伪随机值。
+-------------------+----------+---------+
| Name | Status | Comment |
+-------------------+----------+---------+
| PRF_HMAC_SHA2_256 | MUST | |
| PRF_HMAC_SHA2_512 | SHOULD+ | |
| PRF_HMAC_SHA1 | MUST- | |
| PRF_AES128_XCBC | SHOULD | (IoT) |
| PRF_HMAC_MD5 | MUST NOT | |
+-------------------+----------+---------+
+-------------------+----------+---------+
| Name | Status | Comment |
+-------------------+----------+---------+
| PRF_HMAC_SHA2_256 | MUST | |
| PRF_HMAC_SHA2_512 | SHOULD+ | |
| PRF_HMAC_SHA1 | MUST- | |
| PRF_AES128_XCBC | SHOULD | (IoT) |
| PRF_HMAC_MD5 | MUST NOT | |
+-------------------+----------+---------+
(IoT) This requirement is for interoperability with IoT.
（物联网）该要求是为了与物联网互操作。
As no SHA2-based transforms were referenced in RFC 4307, PRF_HMAC_SHA2_256 was not mentioned in RFC 4307. PRF_HMAC_SHA2_256 MUST be implemented in order to replace SHA1 and PRF_HMAC_SHA1.
由于RFC 4307中未引用基于SHA2的转换，因此RFC 4307中未提及PRF_HMAC_SHA2_256。必须实施PRF_HMAC_SHA2_256以替换SHA1和PRF_HMAC_SHA1。
PRF_HMAC_SHA2_512 SHOULD be implemented as a future replacement for PRF_HMAC_SHA2_256 or when stronger security is required. PRF_HMAC_SHA2_512 is preferred over PRF_HMAC_SHA2_384 as the additional overhead of PRF_HMAC_SHA2_512 is negligible.
PRF_HMAC_SHA2_512应作为PRF_HMAC_SHA2_256的未来替代品或在需要更高安全性时实施。PRF_HMAC_SHA2_512优于PRF_HMAC_SHA2_384，因为PRF_HMAC_SHA2_512的额外开销可以忽略不计。
PRF_HMAC_SHA1 has been downgraded from MUST in RFC 4307 to MUST-, as cryptographic attacks against SHA1 are increasing, resulting in an industry-wide trend to deprecate its usage.
PRF_HMAC_SHA1已从RFC 4307中的“必须”降级为“必须”，因为针对SHA1的加密攻击正在增加，导致整个行业都倾向于反对其使用。
PRF_AES128_XCBC is only recommended in the scope of IoT, as Internet of Things deployments tend to prefer AES-based pseudorandom functions in order to avoid implementing SHA2. For the non-IoT VPN deployment, it has been downgraded from SHOULD in RFC 4307 to MAY as it has not seen wide adoption.
PRF_AES128_XCBC仅在物联网范围内推荐，因为物联网部署倾向于使用基于AES的伪随机函数，以避免实施SHA2。对于非物联网VPN部署，由于尚未得到广泛采用，已从RFC 4307中的“应”降级为5月。
PRF_HMAC_MD5 has been downgraded from MAY in RFC 4307 to MUST NOT. Cryptographic attacks against MD5, such as collision attacks mentioned in [TRANSCRIPTION], are resulting in an industry-wide trend to deprecate and remove MD5 (and thus HMAC-MD5) from cryptographic libraries.
PRF_HMAC_MD5已在RFC 4307中从5月降级为不得。针对MD5的加密攻击（如[TRANSCRIPTION]中提到的冲突攻击）导致了一种全行业的趋势，即从加密库中弃用并删除MD5（从而删除HMAC-MD5）。
The algorithms in the table below are negotiated in the SA payload and used for the Encrypted Payload. References to the specification defining these algorithms are in the IANA registry. When an AEAD algorithm (see Section 2.1) is proposed, this algorithm transform type is not in use.
下表中的算法在SA有效负载中协商，并用于加密有效负载。对定义这些算法的规范的引用在IANA注册表中。当提出AEAD算法（见第2.1节）时，不使用该算法变换类型。
+------------------------+----------+---------+
| Name | Status | Comment |
+------------------------+----------+---------+
| AUTH_HMAC_SHA2_256_128 | MUST | |
| AUTH_HMAC_SHA2_512_256 | SHOULD | |
| AUTH_HMAC_SHA1_96 | MUST- | |
| AUTH_AES_XCBC_96 | SHOULD | (IoT) |
| AUTH_HMAC_MD5_96 | MUST NOT | |
| AUTH_DES_MAC | MUST NOT | |
| AUTH_KPDK_MD5 | MUST NOT | |
+------------------------+----------+---------+
+------------------------+----------+---------+
| Name | Status | Comment |
+------------------------+----------+---------+
| AUTH_HMAC_SHA2_256_128 | MUST | |
| AUTH_HMAC_SHA2_512_256 | SHOULD | |
| AUTH_HMAC_SHA1_96 | MUST- | |
| AUTH_AES_XCBC_96 | SHOULD | (IoT) |
| AUTH_HMAC_MD5_96 | MUST NOT | |
| AUTH_DES_MAC | MUST NOT | |
| AUTH_KPDK_MD5 | MUST NOT | |
+------------------------+----------+---------+
(IoT) This requirement is for interoperability with IoT.
（物联网）该要求是为了与物联网互操作。
AUTH_HMAC_SHA2_256_128 was not mentioned in RFC 4307, as no SHA2-based transforms were mentioned. AUTH_HMAC_SHA2_256_128 MUST be implemented in order to replace AUTH_HMAC_SHA1_96.
RFC 4307中未提及AUTH_HMAC_SHA2_256_128，因为未提及基于SHA2的转换。必须实施AUTH_HMAC_SHA2_256_128以替换AUTH_HMAC_SHA1_96。
AUTH_HMAC_SHA2_512_256 SHOULD be implemented as a future replacement of AUTH_HMAC_SHA2_256_128 or when stronger security is required. This value has been preferred over AUTH_HMAC_SHA2_384, as the additional overhead of AUTH_HMAC_SHA2_512 is negligible.
AUTH_HMAC_SHA2_512_256应作为AUTH_HMAC_SHA2_256_128的未来替代品或在需要更高安全性时实施。与AUTH_HMAC_SHA2_384相比，此值更受欢迎，因为AUTH_HMAC_SHA2_512的额外开销可以忽略不计。
AUTH_HMAC_SHA1_96 has been downgraded from MUST in RFC 4307 to MUST-as cryptographic attacks against SHA1 are increasing, resulting in an industry-wide trend to deprecate its usage.
由于针对SHA1的加密攻击不断增加，AUTH_HMAC__SHA1_96已从RFC 4307中的“必须”降级为“必须”，从而导致整个行业都倾向于反对其使用。
AUTH_AES_XCBC_96 is only recommended in the scope of IoT, as Internet of Things deployments tend to prefer AES-based pseudorandom functions in order to avoid implementing SHA2. For the non-IoT VPN deployment, it has been downgraded from SHOULD in RFC 4307 to MAY as it has not been widely adopted.
仅建议在物联网范围内使用AUTH_AES_XCBC_96，因为物联网部署倾向于使用基于AES的伪随机函数，以避免实现SHA2。对于非物联网VPN部署，由于未被广泛采用，已从RFC 4307中的“应”降级为5月。
AUTH_DES_MAC and AUTH_KPDK_MD5 were not mentioned in RFC 4307, so their default statuses were MAY. These have been downgraded to MUST NOT. AUTH_HMAC_MD5_96 is also demoted to MUST NOT. This is because there is an industry-wide trend to deprecate DES and MD5. Note also that MD5 support is being removed from cryptographic libraries in general because its non-HMAC use is known to be subject to collision attacks, for example, as mentioned in [TRANSCRIPTION].
RFC 4307中未提及AUTH_DES_MAC和AUTH_KPDK_MD5，因此它们的默认状态为MAY。这些被降级为不得。AUTH_HMAC_MD5_96也降级为不得。这是因为全行业都有反对DES和MD5的趋势。还请注意，MD5支持通常从加密库中移除，因为已知其非HMAC使用会受到冲突攻击，例如，如[TRANSCRIPTION]中所述。
There are several Modular Exponential (MODP) groups and several Elliptic Curve Cryptography (ECC) groups that are defined for use in IKEv2. These groups are defined in both the base document [RFC7296] and in extension documents and are identified by group number. Note that it is critical to enforce a secure Diffie-Hellman (DH) exchange as this exchange provides keys for the session. If an attacker can retrieve one of the private numbers (a or b) and the complementary public value (g**b or g**a), then the attacker can compute the secret and the keys used and then decrypt the exchange and IPsec SA created inside the IKEv2 SA. Such an attack can be performed off-line on a previously recorded communication, years after the communication happened. This differs from attacks that need to be executed during the authentication that must be performed online and in near real time.
IKEv2中定义了几个模指数（MODP）组和几个椭圆曲线密码（ECC）组。这些组在基础文档[RFC7296]和扩展文档中都有定义，并由组号标识。请注意，强制执行安全的Diffie-Hellman（DH）交换非常重要，因为该交换为会话提供密钥。如果攻击者可以检索其中一个私有号码（a或b）和互补的公共值（g**b或g**a），则攻击者可以计算机密和使用的密钥，然后解密在IKEv2 SA内创建的exchange和IPsec SA。这种攻击可以在先前记录的通信发生数年后离线执行。这与身份验证期间需要执行的攻击不同，身份验证必须在线和近实时执行。
+--------+---------------------------------------------+------------+
| Number | Description | Status |
+--------+---------------------------------------------+------------+
| 14 | 2048-bit MODP Group | MUST |
| 19 | 256-bit random ECP group | SHOULD |
| 5 | 1536-bit MODP Group | SHOULD NOT |
| 2 | 1024-bit MODP Group | SHOULD NOT |
| 1 | 768-bit MODP Group | MUST NOT |
| 22 | 1024-bit MODP Group with 160-bit Prime | MUST NOT |
| | Order Subgroup | |
| 23 | 2048-bit MODP Group with 224-bit Prime | SHOULD NOT |
| | Order Subgroup | |
| 24 | 2048-bit MODP Group with 256-bit Prime | SHOULD NOT |
| | Order Subgroup | |
+--------+---------------------------------------------+------------+
+--------+---------------------------------------------+------------+
| Number | Description | Status |
+--------+---------------------------------------------+------------+
| 14 | 2048-bit MODP Group | MUST |
| 19 | 256-bit random ECP group | SHOULD |
| 5 | 1536-bit MODP Group | SHOULD NOT |
| 2 | 1024-bit MODP Group | SHOULD NOT |
| 1 | 768-bit MODP Group | MUST NOT |
| 22 | 1024-bit MODP Group with 160-bit Prime | MUST NOT |
| | Order Subgroup | |
| 23 | 2048-bit MODP Group with 224-bit Prime | SHOULD NOT |
| | Order Subgroup | |
| 24 | 2048-bit MODP Group with 256-bit Prime | SHOULD NOT |
| | Order Subgroup | |
+--------+---------------------------------------------+------------+
Group 14 or the 2048-bit MODP Group is raised from SHOULD+ in RFC 4307 to MUST as a replacement for the 1024-bit MODP Group. Group 14 is widely implemented and considered secure.
组14或2048位MODP组从RFC 4307中的SHOULD+提升为MUST，以替换1024位MODP组。第14组被广泛实施，并被认为是安全的。
Group 19 or the 256-bit random ECP group was not specified in RFC 4307 as this group was not defined at that time. Group 19 is widely implemented and considered secure and, therefore, has been promoted to the SHOULD level.
RFC 4307中未指定组19或256位随机ECP组，因为当时未定义该组。第19组得到广泛实施，并被认为是安全的，因此，已被提升到应有的水平。
Group 5 or the 1536-bit MODP Group has been downgraded from MAY in RFC 4307 to SHOULD NOT. It was specified earlier, but is now considered to be vulnerable to being broken within the next few years by a nation-state-level attack, so its security margin is considered too narrow.
组5或1536位MODP组已从RFC 4307中的五月降级为不应降级。它在早些时候就被指定了，但现在被认为在未来几年内很容易被国家级攻击破坏，因此其安全范围被认为太窄。
Group 2 or the 1024-bit MODP Group has been downgraded from MUST- in RFC 4307 to SHOULD NOT. It is known to be weak against sufficiently funded attackers using commercially available mass-computing resources, so its security margin is considered too narrow. It is expected in the near future to be downgraded to MUST NOT.
组2或1024位MODP组已从RFC 4307中的“必须”降级为“不应该”。众所周知，它对使用商业上可获得的大规模计算资源的资金充足的攻击者的攻击能力较弱，因此其安全边际被认为太窄。预计在不久的将来，该评级将下调至“不得”。
Group 1 or the 768-bit MODP Group was not mentioned in RFC 4307 and so its status was MAY. It can be broken within hours using cheap off-the-shelf hardware. It provides no security whatsoever. It has, therefore, been downgraded to MUST NOT.
RFC 4307中未提及第1组或768位MODP组，因此其状态为MAY。它可以在几个小时内使用廉价的现成硬件被打破。它没有提供任何安全保障。因此，它被降级为不得。
Groups 22, 23, and 24 are MODP groups with Prime Order Subgroups that are not safe primes. The seeds for these groups have not been publicly released, resulting in reduced trust in these groups. These groups were proposed as alternatives for groups 2 and 14 but never saw wide deployment. It has been shown that group 22 with 1024-bit MODP is too weak and academia have the resources to generate
群22、23和24是具有非安全素数的素数阶子群的MODP群。这些团体的种子尚未公开发行，导致对这些团体的信任度下降。这些小组被提议作为第2组和第14组的替代方案，但从未看到广泛部署。已经证明，具有1024位MODP的组22太弱，学术界有资源生成
malicious values at this size. This has resulted in group 22 to be demoted to MUST NOT. Groups 23 and 24 have been demoted to SHOULD NOT and are expected to be further downgraded in the near future to MUST NOT. Since groups 23 and 24 have small subgroups, the checks specified in the first bullet point of Section 2.2 of "Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2)" [RFC6989] MUST be done when these groups are used.
此大小的恶意值。这导致第22组降级为“不得”。第23组和第24组已降级为“不应该”，预计在不久的将来将进一步降级为“不得”。由于第23组和第24组具有较小的子组，因此在使用这些组时，必须执行“Internet密钥交换协议版本2（IKEv2）的附加Diffie-Hellman测试”[RFC6989]第2.2节第一点中规定的检查。
The following table summarizes the changes from RFC 4307.
下表总结了RFC 4307的变更。
+---------------------+--------------------------+------------+
| Algorithm | RFC 4307 | RFC 8247 |
+---------------------+--------------------------+------------+
| ENCR_3DES | MUST- | MAY |
| ENCR_NULL | MUST NOT (per [Err1937]) | MUST NOT |
| ENCR_AES_CBC | SHOULD+ | MUST |
| ENCR_AES_CTR | SHOULD | MAY(*) |
| PRF_HMAC_MD5 | MAY | MUST NOT |
| PRF_HMAC_SHA1 | MUST | MUST- |
| PRF_AES128_XCBC | SHOULD+ | SHOULD |
| AUTH_HMAC_MD5_96 | MAY | MUST NOT |
| AUTH_HMAC_SHA1_96 | MUST | MUST- |
| AUTH_AES_XCBC_96 | SHOULD+ | SHOULD |
| Group 2 (1024-bit) | MUST- | SHOULD NOT |
| Group 14 (2048-bit) | SHOULD+ | MUST |
+---------------------+--------------------------+------------+
+---------------------+--------------------------+------------+
| Algorithm | RFC 4307 | RFC 8247 |
+---------------------+--------------------------+------------+
| ENCR_3DES | MUST- | MAY |
| ENCR_NULL | MUST NOT (per [Err1937]) | MUST NOT |
| ENCR_AES_CBC | SHOULD+ | MUST |
| ENCR_AES_CTR | SHOULD | MAY(*) |
| PRF_HMAC_MD5 | MAY | MUST NOT |
| PRF_HMAC_SHA1 | MUST | MUST- |
| PRF_AES128_XCBC | SHOULD+ | SHOULD |
| AUTH_HMAC_MD5_96 | MAY | MUST NOT |
| AUTH_HMAC_SHA1_96 | MUST | MUST- |
| AUTH_AES_XCBC_96 | SHOULD+ | SHOULD |
| Group 2 (1024-bit) | MUST- | SHOULD NOT |
| Group 14 (2048-bit) | SHOULD+ | MUST |
+---------------------+--------------------------+------------+
(*) This algorithm is not mentioned in the above sections, so it defaults to MAY.
（*）上述章节未提及此算法，因此默认为MAY。
IKEv2 authentication may involve a signatures verification. Signatures may be used to validate a certificate or to check the signature of the AUTH value. Cryptographic recommendations regarding certificate validation are out of scope of this document. What is mandatory to implement is provided by the PKIX community. This document is mostly concerned with signature verification and generation for the authentication.
IKEv2认证可能涉及签名验证。签名可用于验证证书或检查身份验证值的签名。关于证书验证的加密建议超出了本文档的范围。强制实施的内容由PKIX社区提供。本文档主要涉及签名验证和身份验证的生成。
+--------+---------------------------------------+------------+
| Number | Description | Status |
+--------+---------------------------------------+------------+
| 1 | RSA Digital Signature | MUST |
| 2 | Shared Key Message Integrity Code | MUST |
| 3 | DSS Digital Signature | SHOULD NOT |
| 9 | ECDSA with SHA-256 on the P-256 curve | SHOULD |
| 10 | ECDSA with SHA-384 on the P-384 curve | SHOULD |
| 11 | ECDSA with SHA-512 on the P-521 curve | SHOULD |
| 14 | Digital Signature | SHOULD |
+--------+---------------------------------------+------------+
+--------+---------------------------------------+------------+
| Number | Description | Status |
+--------+---------------------------------------+------------+
| 1 | RSA Digital Signature | MUST |
| 2 | Shared Key Message Integrity Code | MUST |
| 3 | DSS Digital Signature | SHOULD NOT |
| 9 | ECDSA with SHA-256 on the P-256 curve | SHOULD |
| 10 | ECDSA with SHA-384 on the P-384 curve | SHOULD |
| 11 | ECDSA with SHA-512 on the P-521 curve | SHOULD |
| 14 | Digital Signature | SHOULD |
+--------+---------------------------------------+------------+
RSA Digital Signature is widely deployed and, therefore, kept for interoperability. It is expected to be downgraded in the future as its signatures are based on the older RSASSA-PKCS1-v1.5, which is no longer recommended. RSA authentication, as well as other specific authentication methods, are expected to be replaced with the generic Digital Signature method of [RFC7427].
RSA数字签名被广泛部署，因此为了互操作性而保留。由于其签名基于较旧的RSASSA-PKCS1-v1.5（不再推荐），预计未来将降级。RSA认证以及其他特定的认证方法预计将被[RFC7427]的通用数字签名方法所取代。
Shared Key Message Integrity Code is widely deployed and mandatory to implement in the IKEv2 in RFC 7296. The status remains MUST.
共享密钥消息完整性代码被广泛部署，并且必须在RFC 7296中的IKEv2中实现。地位仍然是必须的。
"DSS Digital Signature" (IANA value 3) signatures are bound to SHA-1 and have the same level of security as 1024-bit RSA. They are currently at SHOULD NOT and are expected to be downgraded to MUST NOT in the future.
“DSS数字签名”（IANA值3）签名绑定到SHA-1，具有与1024位RSA相同的安全级别。它们目前处于“不应该”状态，预计未来将降级为“不应该”。
Authentication methods that are based on the Elliptic Curve Digital Signature Algorithm (ECDSA) are also expected to be downgraded as these do not provide hash function agility. Instead, ECDSA (like RSA) is expected to be performed using the generic Digital Signature method. Its status is SHOULD.
基于椭圆曲线数字签名算法（ECDSA）的身份验证方法也将降级，因为这些方法不提供哈希函数灵活性。相反，ECDSA（如RSA）预计将使用通用数字签名方法执行。它的地位是应该的。
Digital Signature [RFC7427] is expected to be promoted as it provides hash function, signature format, and algorithm agility. Its current status is SHOULD.
数字签名[RFC7427]有望得到推广，因为它提供了哈希函数、签名格式和算法灵活性。它的现状是应该的。
+-------------------------------------------+------------+
| Description | Status |
+-------------------------------------------+------------+
| RSA with key length 2048 | MUST |
| RSA with key length 3072 and 4096 | SHOULD |
| RSA with key length between 2049 and 4095 | MAY |
| RSA with key length smaller than 2048 | SHOULD NOT |
+-------------------------------------------+------------+
+-------------------------------------------+------------+
| Description | Status |
+-------------------------------------------+------------+
| RSA with key length 2048 | MUST |
| RSA with key length 3072 and 4096 | SHOULD |
| RSA with key length between 2049 and 4095 | MAY |
| RSA with key length smaller than 2048 | SHOULD NOT |
+-------------------------------------------+------------+
IKEv2 [RFC7296] mandates support for the RSA keys of the bit size 1024 or 2048, but key sizes less than 2048 are updated to SHOULD NOT as there is an industry-wide trend to deprecate key lengths less than 2048 bits. Since these signatures only have value in real time and need no future protection, smaller keys were kept at SHOULD NOT instead of MUST NOT.
IKEv2[RFC7296]强制要求支持位大小为1024或2048的RSA密钥，但小于2048的密钥将更新为“不应”，因为业界普遍倾向于反对长度小于2048位的密钥。由于这些签名只具有实时价值，并且不需要将来的保护，因此较小的密钥保存在SHOULD NOT而不是MUST NOT。
When a Digital Signature authentication method is implemented, the following recommendations are applied for hash functions:
当实施数字签名认证方法时，以下建议适用于哈希函数：
+--------+-------------+----------+---------+
| Number | Description | Status | Comment |
+--------+-------------+----------+---------+
| 1 | SHA1 | MUST NOT | |
| 2 | SHA2-256 | MUST | |
| 3 | SHA2-384 | MAY | |
| 4 | SHA2-512 | SHOULD | |
+--------+-------------+----------+---------+
+--------+-------------+----------+---------+
| Number | Description | Status | Comment |
+--------+-------------+----------+---------+
| 1 | SHA1 | MUST NOT | |
| 2 | SHA2-256 | MUST | |
| 3 | SHA2-384 | MAY | |
| 4 | SHA2-512 | SHOULD | |
+--------+-------------+----------+---------+
When the Digital Signature authentication method is used with RSA signature algorithm, RSASSA-PSS MUST be supported and RSASSA-PKCS1-v1.5 MAY be supported.
当数字签名认证方法与RSA签名算法一起使用时，必须支持RSASSA-PSS，可能支持RSASSA-PKCS1-v1.5。
The following table lists recommendations for authentication methods in [RFC7427] notation. These recommendations are applied only if the Digital Signature authentication method is implemented.
下表列出了[RFC7427]符号中认证方法的建议。这些建议仅在实施数字签名认证方法时适用。
+------------------------------------+----------+---------+
| Description | Status | Comment |
+------------------------------------+----------+---------+
| RSASSA-PSS with SHA-256 | MUST | |
| ecdsa-with-sha256 | SHOULD | |
| sha1WithRSAEncryption | MUST NOT | |
| dsa-with-sha1 | MUST NOT | |
| ecdsa-with-sha1 | MUST NOT | |
| RSASSA-PSS with Empty Parameters | MUST NOT | (*) |
| RSASSA-PSS with Default Parameters | MUST NOT | (*) |
+------------------------------------+----------+---------+
+------------------------------------+----------+---------+
| Description | Status | Comment |
+------------------------------------+----------+---------+
| RSASSA-PSS with SHA-256 | MUST | |
| ecdsa-with-sha256 | SHOULD | |
| sha1WithRSAEncryption | MUST NOT | |
| dsa-with-sha1 | MUST NOT | |
| ecdsa-with-sha1 | MUST NOT | |
| RSASSA-PSS with Empty Parameters | MUST NOT | (*) |
| RSASSA-PSS with Default Parameters | MUST NOT | (*) |
+------------------------------------+----------+---------+
(*) Empty or Default parameters means it is using SHA1, which is at the MUST NOT level.
（*）空参数或默认参数表示它正在使用SHA1，它处于“不得”级别。
Some algorithms in this document are marked for use with the Internet of Things (IoT). There are several reasons why IoT devices prefer a different set of algorithms from regular IKEv2 clients. IoT devices are usually very constrained, meaning that the memory size and CPU power is so limited that these clients only have resources to implement and run one set of algorithms. For example, instead of implementing AES and SHA, these devices typically use AES_XCBC as an integrity algorithm so SHA does not need to be implemented.
本文中的一些算法被标记为用于物联网（IoT）。物联网设备选择与常规IKEv2客户端不同的一组算法有几个原因。物联网设备通常非常受限，这意味着内存大小和CPU功率非常有限，这些客户端只有资源来实现和运行一组算法。例如，这些设备通常使用AES_XCBC作为完整性算法，而不是实现AES和SHA，因此不需要实现SHA。
For example, IEEE Std 802.15.4 [IEEE-802-15-4] devices have a mandatory-to-implement link-level security using AES-CCM with 128-bit keys. The "IEEE Recommended Practice for Transport of Key Management Protocol (KMP) Datagrams" [IEEE-802-15-9] already provides a way to use Minimal IKEv2 [RFC7815] over the 802.15.4 layer to provide link keys for the 802.15.4 layer.
例如，IEEE Std 802.15.4[IEEE-802-15-4]设备必须使用具有128位密钥的AES-CCM实现链路级安全。“IEEE密钥管理协议（KMP）数据报传输推荐规程”[IEEE-802-15-9]已经提供了一种在802.15.4层上使用最小IKEv2[RFC7815]的方法，为802.15.4层提供链路密钥。
These devices might want to use AES-CCM as their IKEv2 algorithm, so they can reuse the hardware implementing it. They cannot use the AES-CBC algorithm, as the hardware quite often does not include support for the AES decryption needed to support the CBC mode. So despite the AES-CCM algorithm requiring AEAD [RFC5282] support, the benefit of reusing the crypto hardware makes AES-CCM the preferred algorithm.
这些设备可能希望使用AES-CCM作为其IKEv2算法，以便可以重用实现该算法的硬件。他们不能使用AES-CBC算法，因为硬件通常不支持支持CBC模式所需的AES解密。因此，尽管AES-CCM算法需要AEAD[RFC5282]支持，但重用加密硬件的好处使AES-CCM成为首选算法。
Another important aspect of IoT devices is that their transfer rates are usually quite low (in the order of tens of kbit/s), and each bit they transmit has an energy consumption cost associated with it and
物联网设备的另一个重要方面是，它们的传输速率通常非常低（以几十kbit/s的顺序），并且它们传输的每一位都有与之相关的能耗成本，并且
shortens their battery life. Therefore, shorter packets are preferred. This is the reason for recommending the 8-octet ICV over the 16-octet ICV.
缩短电池寿命。因此，优选较短的分组。这就是为什么推荐8-八位组ICV而不是16-八位组ICV的原因。
Because different IoT devices will have different constraints, this document cannot specify the one mandatory profile for IoT. Instead, this document points out commonly used algorithms with IoT devices.
由于不同的物联网设备将具有不同的约束，因此本文档无法为物联网指定一个强制配置文件。相反，本文件指出了物联网设备的常用算法。
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 of the protocol used by the system to ensure that there are no non-cryptographic ways to bypass the security of the overall system.
基于密码的系统的安全性取决于所选密码算法的强度以及与这些算法一起使用的密钥的强度。安全性还取决于系统使用的协议工程，以确保没有非加密方式绕过整个系统的安全性。
The Diffie-Hellman Group parameter is the most important one to choose conservatively. Any party capturing all IKE and ESP traffic that (even years later) can break the selected DH group in IKE, can gain access to the symmetric keys used to encrypt all the ESP traffic. Therefore, these groups must be chosen very conservatively. However, specifying an extremely large DH group also puts a considerable load on the device, especially when this is a large VPN gateway or an IoT-constrained device.
Diffie-Hellman群参数是保守选择的最重要参数。捕获所有IKE和ESP流量的任何一方（甚至几年后）都可以破坏IKE中选定的DH组，可以访问用于加密所有ESP流量的对称密钥。因此，这些群体的选择必须非常保守。但是，指定一个非常大的DH组也会给设备带来相当大的负载，特别是当这是一个大型VPN网关或物联网受限的设备时。
This document concerns itself with the selection of cryptographic algorithms for the use of IKEv2, 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 isn't necessarily forever and it is expected that new revisions of this document will be issued from time to time to reflect the current best practice in this area.
本文件涉及选择使用IKEv2的加密算法，特别是选择“强制实施”算法。本文件中确定为“必须实现”或“应该实现”的算法目前尚不存在漏洞，迄今为止的密码研究使我们相信，在可预见的未来，它们可能仍然是安全的。然而，这并不一定是永远的，预计本文件的新修订版将不时发布，以反映该领域的当前最佳实践。
This document renames some of the names in the "Transform Type 1 - Encryption Algorithm Transform IDs" registry of the "Internet Key Exchange Version 2 (IKEv2) Parameters". All the other names have ENCR_ prefix except 3, and all other entries use names in the format of uppercase words separated with underscores except 6. This document changes those names to match others.
本文档重命名了“Internet密钥交换版本2（IKEv2）参数”的“转换类型1-加密算法转换ID”注册表中的一些名称。除3外，所有其他名称都有ENCR_uuu前缀，除6外，所有其他条目都使用大写字母分隔的名称。本文档将更改这些名称以匹配其他名称。
Per this document, IANA has renamed the following entries for the AES-GCM cipher [RFC4106] and the Camellia cipher [RFC5529]:
根据本文件，IANA为AES-GCM密码[RFC4106]和Camellia密码[RFC5529]重命名了以下条目：
+---------------------------------------+----------------------+
| Old name | New name |
+---------------------------------------+----------------------+
| AES-GCM with a 8 octet ICV | ENCR_AES_GCM_8 |
| AES-GCM with a 12 octet ICV | ENCR_AES_GCM_12 |
| AES-GCM with a 16 octet ICV | ENCR_AES_GCM_16 |
| ENCR_CAMELLIA_CCM with an 8-octet ICV | ENCR_CAMELLIA_CCM_8 |
| ENCR_CAMELLIA_CCM with a 12-octet ICV | ENCR_CAMELLIA_CCM_12 |
| ENCR_CAMELLIA_CCM with a 16-octet ICV | ENCR_CAMELLIA_CCM_16 |
+---------------------------------------+----------------------+
+---------------------------------------+----------------------+
| Old name | New name |
+---------------------------------------+----------------------+
| AES-GCM with a 8 octet ICV | ENCR_AES_GCM_8 |
| AES-GCM with a 12 octet ICV | ENCR_AES_GCM_12 |
| AES-GCM with a 16 octet ICV | ENCR_AES_GCM_16 |
| ENCR_CAMELLIA_CCM with an 8-octet ICV | ENCR_CAMELLIA_CCM_8 |
| ENCR_CAMELLIA_CCM with a 12-octet ICV | ENCR_CAMELLIA_CCM_12 |
| ENCR_CAMELLIA_CCM with a 16-octet ICV | ENCR_CAMELLIA_CCM_16 |
+---------------------------------------+----------------------+
In addition, IANA has added this RFC as a reference to both the ESP Reference and IKEv2 Reference columns for ENCR_AES_GCM entries, while keeping the existing references there. Also, IANA has added this RFC as a reference to the ESP Reference column for ENCR_CAMELLIA_CCM entries, while keeping the existing reference there.
此外，IANA已将此RFC添加为ENCR_AES_GCM条目的ESP参考和IKEv2参考列的参考，同时保留现有参考。此外，IANA已将此RFC添加为ENCR_CAMELLIA_CCM条目ESP参考列的参考，同时保留现有参考。
The registry entries currently are:
当前注册表项为：
Number Name ESP Reference IKEv2 Reference
...
18 ENCR_AES_GCM_8 [RFC4106][RFC8247] [RFC5282][RFC8247]
19 ENCR_AES_GCM_12 [RFC4106][RFC8247] [RFC5282][RFC8247]
20 ENCR_AES_GCM_16 [RFC4106][RFC8247] [RFC5282][RFC8247]
...
25 ENCR_CAMELLIA_CCM_8 [RFC5529][RFC8247] -
26 ENCR_CAMELLIA_CCM_12 [RFC5529][RFC8247] -
27 ENCR_CAMELLIA_CCM_16 [RFC5529][RFC8247] -
Number Name ESP Reference IKEv2 Reference
...
18 ENCR_AES_GCM_8 [RFC4106][RFC8247] [RFC5282][RFC8247]
19 ENCR_AES_GCM_12 [RFC4106][RFC8247] [RFC5282][RFC8247]
20 ENCR_AES_GCM_16 [RFC4106][RFC8247] [RFC5282][RFC8247]
...
25 ENCR_CAMELLIA_CCM_8 [RFC5529][RFC8247] -
26 ENCR_CAMELLIA_CCM_12 [RFC5529][RFC8247] -
27 ENCR_CAMELLIA_CCM_16 [RFC5529][RFC8247] -
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, DOI 10.17487/RFC4106, June 2005, <https://www.rfc-editor.org/info/rfc4106>.
[RFC4106]Viega，J.和D.McGrew，“在IPsec封装安全有效载荷（ESP）中使用Galois/计数器模式（GCM）”，RFC 4106，DOI 10.17487/RFC4106，2005年6月<https://www.rfc-editor.org/info/rfc4106>.
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, DOI 10.17487/RFC4307, December 2005, <https://www.rfc-editor.org/info/rfc4307>.
[RFC4307]Schiller，J.“互联网密钥交换版本2（IKEv2）中使用的加密算法”，RFC 4307，DOI 10.17487/RFC4307，2005年12月<https://www.rfc-editor.org/info/rfc4307>.
[RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol", RFC 5282, DOI 10.17487/RFC5282, August 2008, <https://www.rfc-editor.org/info/rfc5282>.
[RFC5282]Black，D.和D.McGrew，“使用互联网密钥交换版本2（IKEv2）协议的加密有效载荷的认证加密算法”，RFC 5282，DOI 10.17487/RFC5282，2008年8月<https://www.rfc-editor.org/info/rfc5282>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7296]Kaufman，C.，Hoffman，P.，Nir，Y.，Eronen，P.，和T.Kivinen，“互联网密钥交换协议版本2（IKEv2）”，STD 79，RFC 7296，DOI 10.17487/RFC72962014年10月<https://www.rfc-editor.org/info/rfc7296>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[Err1937] RFC Errata, Erratum ID 1937, RFC 4307, <https://www.rfc-editor.org/errata/eid1937>.
[Err1937]RFC勘误表，勘误表ID 1937，RFC 4307<https://www.rfc-editor.org/errata/eid1937>.
[IEEE-802-15-4] IEEE, "IEEE Standard for Low-Rate Wireless Personal Area Networks (WPANs)", IEEE Standard 802.15.4, DOI 10.1109/IEEESTD.2016.7460875, 2015, <http://ieeexplore.ieee.org/document/7460875/>.
[IEEE-802-15-4]IEEE，“低速无线个人区域网络（WPAN）的IEEE标准”，IEEE标准802.15.4，DOI 10.1109/IEEESTD.2016.7460875，2015<http://ieeexplore.ieee.org/document/7460875/>.
[IEEE-802-15-9] IEEE, "IEEE Recommended Practice for Transport of Key Management Protocol (KMP) Datagrams", IEEE Standard 802.15.9, DOI 10.1109/IEEESTD.2016.7544442, 2016, <http://ieeexplore.ieee.org/document/7544442/>.
[IEEE-802-15-9]IEEE，“IEEE密钥管理协议（KMP）数据报传输的推荐规程”，IEEE标准802.15.9，DOI 10.1109/IEEESTD.2016.7544222016<http://ieeexplore.ieee.org/document/7544442/>.
[IKEV2-IANA] IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters", <http://www.iana.org/assignments/ikev2-parameters>.
[IKEV2-IANA]IANA，“互联网密钥交换版本2（IKEV2）参数”<http://www.iana.org/assignments/ikev2-parameters>.
[RFC5529] Kato, A., Kanda, M., and S. Kanno, "Modes of Operation for Camellia for Use with IPsec", RFC 5529, DOI 10.17487/RFC5529, April 2009, <https://www.rfc-editor.org/info/rfc5529>.
[RFC5529]Kato，A.，Kanda，M.和S.Kanno，“与IPsec一起使用的茶花的操作模式”，RFC 5529，DOI 10.17487/RFC5529，2009年4月<https://www.rfc-editor.org/info/rfc5529>.
[RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 6989, DOI 10.17487/RFC6989, July 2013, <https://www.rfc-editor.org/info/rfc6989>.
[RFC6989]Sheffer，Y.和S.Fluhrer，“互联网密钥交换协议版本2（IKEv2）的附加Diffie-Hellman测试”，RFC 6989，DOI 10.17487/RFC69892013年7月<https://www.rfc-editor.org/info/rfc6989>.
[RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)", RFC 7427, DOI 10.17487/RFC7427, January 2015, <https://www.rfc-editor.org/info/rfc7427>.
[RFC7427]Kivinen，T.和J.Snyder，“互联网密钥交换版本2（IKEv2）中的签名认证”，RFC 7427，DOI 10.17487/RFC7427，2015年1月<https://www.rfc-editor.org/info/rfc7427>.
[RFC7815] Kivinen, T., "Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation", RFC 7815, DOI 10.17487/RFC7815, March 2016, <https://www.rfc-editor.org/info/rfc7815>.
[RFC7815]Kivinen，T，“最小互联网密钥交换版本2（IKEv2）启动器实现”，RFC 7815，DOI 10.17487/RFC7815，2016年3月<https://www.rfc-editor.org/info/rfc7815>.
[TRANSCRIPTION] Bhargavan, K. and G. Leurent, "Transcript Collision Attacks: Breaking Authentication in TLS, IKE, and SSH", Network and Distributed System Security Symposium (NDSS), DOI 10.14722/ndss.2016.23418, Feb 2016, <https://hal.inria.fr/hal-01244855/>.
[抄本]Bhargavan，K.和G.Leurent，“抄本冲突攻击：破坏TLS、IKE和SSH中的身份验证”，网络和分布式系统安全研讨会（NDSS），DOI 10.14722/NDSS.2016.2341818，2016年2月<https://hal.inria.fr/hal-01244855/>.
Acknowledgements
致谢
RFC 4307 was authored by Jeffrey I. Schiller of the Massachusetts Institute of Technology (MIT). Much of the original text has been copied verbatim.
RFC4307由麻省理工学院（MIT）的杰弗里·席勒（Jeffrey I.Schiller）撰写。原文大部分是逐字复制的。
We would like to thank Paul Hoffman, Yaron Sheffer, John Mattsson, Tommy Pauly, Eric Rescorla, and Pete Resnick for their valuable feedback and reviews.
我们要感谢Paul Hoffman、Yaron Sheffer、John Mattsson、Tommy Pauly、Eric Rescorla和Pete Resnick的宝贵反馈和评论。
Authors' Addresses
作者地址
Yoav Nir Dell EMC 9 Andrei Sakharov Street Haifa 3190500 Israel
以色列海法市安德烈萨哈罗夫街9号Yoav Nir戴尔EMC 3190500
Email: ynir.ietf@gmail.com
Email: ynir.ietf@gmail.com
Tero Kivinen
泰罗基文
Email: kivinen@iki.fi
Email: kivinen@iki.fi
Paul Wouters Red Hat
保罗·沃特斯红帽
Email: pwouters@redhat.com
Email: pwouters@redhat.com
Daniel Migault Ericsson 8275 Trans Canada Route Saint-Laurent, QC H4S 0B6 Canada
Daniel Migault Ericsson 8275跨加拿大路线圣洛朗，加拿大QC H4S 0B6
Phone: +1 514-452-2160
Email: daniel.migault@ericsson.com
Phone: +1 514-452-2160
Email: daniel.migault@ericsson.com