Internet Engineering Task Force (IETF) V. Smyslov
Request for Comments: 7619 ELVIS-PLUS
Updates: 4301 P. Wouters
Category: Standards Track Red Hat
ISSN: 2070-1721 August 2015
Internet Engineering Task Force (IETF) V. Smyslov
Request for Comments: 7619 ELVIS-PLUS
Updates: 4301 P. Wouters
Category: Standards Track Red Hat
ISSN: 2070-1721 August 2015
The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2)
Internet密钥交换协议版本2（IKEv2）中的空身份验证方法
Abstract
摘要
This document specifies the NULL Authentication method and the ID_NULL Identification Payload ID Type for Internet Key Exchange Protocol version 2 (IKEv2). This allows two IKE peers to establish single-side authenticated or mutual unauthenticated IKE sessions for those use cases where a peer is unwilling or unable to authenticate or identify itself. This ensures IKEv2 can be used for Opportunistic Security (also known as Opportunistic Encryption) to defend against Pervasive Monitoring attacks without the need to sacrifice anonymity.
本文档规定了Internet密钥交换协议版本2（IKEv2）的空身份验证方法和ID_空标识有效负载ID类型。这允许两个IKE对等方为对等方不愿意或无法对自己进行身份验证或识别的那些用例建立单边验证或相互未验证的IKE会话。这确保了IKEv2可以用于机会主义安全（也称为机会主义加密），以抵御无处不在的监视攻击，而无需牺牲匿名性。
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/rfc7619.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7619.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
2. Using the NULL Authentication Method . . . . . . . . . . . . 4
2.1. Authentication Payload . . . . . . . . . . . . . . . . . 4
2.2. Identification Payload . . . . . . . . . . . . . . . . . 4
2.3. INITIAL_CONTACT Notification . . . . . . . . . . . . . . 5
2.4. Interaction with the Peer Authorization Database (PAD) . 5
2.5. Traffic Selectors . . . . . . . . . . . . . . . . . . . . 6
3. Security Considerations . . . . . . . . . . . . . . . . . . . 7
3.1. Audit Trail and Peer Identification . . . . . . . . . . . 7
3.2. Resource Management and Robustness . . . . . . . . . . . 8
3.3. IKE Configuration Selection . . . . . . . . . . . . . . . 8
3.4. Networking Topology Changes . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Normative References . . . . . . . . . . . . . . . . . . 9
5.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Update of PAD processing in RFC 4301 . . . . . . . . 11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
2. Using the NULL Authentication Method . . . . . . . . . . . . 4
2.1. Authentication Payload . . . . . . . . . . . . . . . . . 4
2.2. Identification Payload . . . . . . . . . . . . . . . . . 4
2.3. INITIAL_CONTACT Notification . . . . . . . . . . . . . . 5
2.4. Interaction with the Peer Authorization Database (PAD) . 5
2.5. Traffic Selectors . . . . . . . . . . . . . . . . . . . . 6
3. Security Considerations . . . . . . . . . . . . . . . . . . . 7
3.1. Audit Trail and Peer Identification . . . . . . . . . . . 7
3.2. Resource Management and Robustness . . . . . . . . . . . 8
3.3. IKE Configuration Selection . . . . . . . . . . . . . . . 8
3.4. Networking Topology Changes . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Normative References . . . . . . . . . . . . . . . . . . 9
5.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Update of PAD processing in RFC 4301 . . . . . . . . 11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
Internet Key Exchange Protocol version 2 (IKEv2), specified in [RFC7296], provides a way for two parties to perform an authenticated key exchange. While the authentication methods used by the peers can be different, there is no method for one or both parties to remain unauthenticated and anonymous. This document extends the authentication methods to support unauthenticated and anonymous IKE sessions.
[RFC7296]中指定的Internet密钥交换协议版本2（IKEv2）为双方提供了一种执行经过身份验证的密钥交换的方法。虽然对等方使用的身份验证方法可能不同，但没有任何方法可以让一方或双方保持未经身份验证和匿名。本文档扩展了身份验证方法，以支持未经身份验证和匿名IKE会话。
In some situations, mutual authentication is undesirable, superfluous, or impossible. The following three examples illustrate these unauthenticated use cases:
在某些情况下，相互认证是不可取的、多余的或不可能的。以下三个示例说明了这些未经验证的用例：
o A user wants to establish an anonymous secure connection to a server. In this situation, the user should be able to authenticate the server without presenting or authenticating to the server with their own identity. This case uses a single-sided authentication of the responder.
o 用户希望建立到服务器的匿名安全连接。在这种情况下，用户应该能够对服务器进行身份验证，而无需使用自己的身份向服务器显示或验证。本例使用响应者的单边身份验证。
o A sensor that periodically wakes up from a suspended state wants to send a measurement (e.g., temperature) to a collecting server. The sensor must be authenticated by the server to ensure authenticity of the measurement, but the sensor does not need to authenticate the server. This case uses a single-sided authentication of the initiator.
o 定期从暂停状态唤醒的传感器希望向采集服务器发送测量值（例如，温度）。传感器必须由服务器进行身份验证，以确保测量的真实性，但传感器不需要对服务器进行身份验证。本例使用启动器的单边身份验证。
o Two peers without any trust relationship wish to defend against widespread pervasive monitoring attacks as described in [RFC7258]. Without a trust relationship, the peers cannot authenticate each other. Opportunistic Security [RFC7435] states that unauthenticated encrypted communication is preferred over cleartext communication. The peers want to use IKE to setup an unauthenticated encrypted connection that gives them protection against pervasive monitoring attacks. An attacker that is able and willing to send packets can still launch a man-in-the-middle (MITM) attack to obtain a copy of the unencrypted communication. This case uses a fully unauthenticated key exchange.
o 如[RFC7258]所述，没有任何信任关系的两个对等方希望防御广泛的普适监视攻击。如果没有信任关系，对等方无法相互验证。机会主义安全[RFC7435]指出，未经验证的加密通信优于明文通信。对等方希望使用IKE建立一个未经验证的加密连接，以保护他们免受无处不在的监视攻击。能够并愿意发送数据包的攻击者仍然可以发起中间人（MITM）攻击以获取未加密通信的副本。此案例使用完全未经验证的密钥交换。
To meet these needs, this document introduces the NULL Authentication method and the ID_NULL ID type. This allows an IKE peer to explicitly indicate that it is unwilling or unable to certify its identity.
为了满足这些需求，本文介绍了NULL身份验证方法和ID\u NULL ID类型。这允许IKE对等方明确表示它不愿意或无法证明其身份。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
In IKEv2, each peer independently selects the method to authenticate itself to the other side. A peer may choose to refrain from authentication by using the NULL Authentication method. If a host's local policy requires that the identity of its peer be (non-null) authenticated, and if that host receives an AUTH payload containing the NULL Authentication method type, it MUST return an AUTHENTICATION_FAILED notification. If an initiator uses the Extensible Authentication Protocol (EAP), the responder MUST NOT use the NULL Authentication method (in conformance with Section 2.16 of [RFC7296]).
在IKEv2中，每个对等方独立地选择向另一方验证自身的方法。对等方可以选择使用空身份验证方法来避免身份验证。如果主机的本地策略要求对其对等方的标识进行（非空）身份验证，并且如果该主机接收到包含空身份验证方法类型的身份验证有效负载，则它必须返回身份验证失败通知。如果发起方使用可扩展认证协议（EAP），响应方不得使用空认证方法（符合[RFC7296]第2.16节）。
NULL authentication affects how the Authentication and the Identification payloads are formed in the IKE_AUTH exchange.
空身份验证会影响身份验证和标识有效负载在IKE_身份验证交换中的形成方式。
NULL authentication still requires a properly formed AUTH payload to be present in the IKE_AUTH exchange messages, as the AUTH payload cryptographically links the IKE_SA_INIT exchange messages with the other messages sent over this IKE Security Association (SA).
空身份验证仍然要求在IKE_AUTH交换消息中存在格式正确的身份验证有效负载，因为身份验证有效负载以加密方式将IKE_SA_INIT交换消息与通过此IKE安全关联（SA）发送的其他消息链接起来。
When using NULL authentication, the content of the AUTH payload is computed using the syntax of pre-shared secret authentication, described in Section 2.15 of [RFC7296]. The value of SK_pi for the initiator and SK_pr for the responder is used as the shared secret for the content of the AUTH payload. Implementers should note this means that authentication keys used by the two peers are different in each direction. This is identical to how the contents of the two last AUTH payloads are generated for the non-key-generating EAP methods (see Section 2.16 of [RFC7296] for details).
使用空身份验证时，使用[RFC7296]第2.15节中描述的预共享秘密身份验证语法计算身份验证有效负载的内容。发起方的SK_pi值和响应方的SK_pr值用作身份验证有效负载内容的共享机密。实现者应该注意，这意味着两个对等方使用的身份验证密钥在每个方向上都是不同的。这与为非密钥生成EAP方法生成最后两个身份验证有效载荷的内容相同（有关详细信息，请参见[RFC7296]的第2.16节）。
The IKEv2 Authentication Method value for NULL Authentication is 13.
空身份验证的IKEv2身份验证方法值为13。
When a remote peer is not authenticated, any ID presented in the Identification Data field of the ID payload cannot be validated. To avoid the need of sending a bogus ID Type with placeholder data, this specification defines a new ID Type, ID_NULL. The Identification Data field of the ID payload for this ID Type MUST be empty.
当远程对等方未通过身份验证时，无法验证ID有效负载的标识数据字段中显示的任何ID。为了避免发送带有占位符数据的虚假ID类型，本规范定义了一个新的ID类型，ID_NULL。此ID类型的ID有效负载的标识数据字段必须为空。
If NULL authentication is in use and anonymity is a concern, then ID_NULL SHOULD be used in the Identification payload. Some examples of cases where a non-null identity type and value with NULL authentication can be used are logging, troubleshooting, and in scenarios where authentication takes place out of band after the IKE SA is created (like in [AUTOVPN]). The content of the Identification payload MUST NOT be used for any trust and policy checking in IKE_AUTH exchange when NULL authentication is employed (see Section 2.4 for details).
如果正在使用空身份验证，并且匿名性是一个问题，那么应该在标识有效负载中使用ID_NULL。可以使用具有空身份验证的非空身份类型和值的一些示例包括日志记录、故障排除以及在创建IKE SA后在带外进行身份验证的场景（如[AUTOVPN]）。当采用空身份验证时，标识有效负载的内容不得用于IKE_身份验证交换中的任何信任和策略检查（有关详细信息，请参阅第2.4节）。
ID_NULL is primarily intended to be used with NULL authentication but could be used in other situations where the content of the Identification payload is not used. For example, ID_NULL could be used when authentication is performed via raw public keys and the identities are the keys themselves. These alternative uses of ID_NULL should be described in their own respective documents.
ID_NULL主要用于NULL身份验证，但也可用于不使用标识有效负载内容的其他情况。例如，当通过原始公钥执行身份验证并且标识是密钥本身时，可以使用ID_NULL。ID_NULL的这些替代用法应在各自的文档中描述。
The IKEv2 Identification Payload ID Type for ID_NULL is 13.
ID_NULL的IKEv2标识有效负载ID类型为13。
The identity of a peer using NULL authentication cannot be used to find existing IKE SAs created by the same peer, as the peer identity is not authenticated. For that reason, the INITIAL_CONTACT notifications MUST NOT be used to delete any other IKE SAs based on the same peer identity without additional verification that the existing IKE SAs with matching identity are actually stale.
使用空身份验证的对等方的标识不能用于查找由同一对等方创建的现有IKE SA，因为对等方标识未经身份验证。因此，在没有进一步验证具有匹配标识的现有IKE SA是否实际过时的情况下，不得使用初始联系人通知删除基于相同对等身份的任何其他IKE SA。
The standard IKE Liveness Check procedure, described in Section 2.4 of [RFC7296], can be used to detect stale IKE SAs created by peers using NULL authentication. Inactive, unauthenticated IKE SAs should be checked periodically. Additionally, the event of creating a new unauthenticated IKE SA can be used to trigger an out-of-order check on existing unauthenticated IKE SAs possibly limited to identical or close-by IP addresses or to identical identities of the just created IKE SA.
[RFC7296]第2.4节中描述的标准IKE活动性检查程序可用于检测对等方使用空身份验证创建的过时IKE SA。应定期检查非活动、未经验证的IKE SA。此外，创建新的未经验证的IKE SA的事件可用于触发对现有未经验证的IKE SA的无序检查，可能仅限于相同或相近的IP地址，或仅限于刚刚创建的IKE SA的相同标识。
Implementations should weigh the resource consumption of sending Liveness Checks against the memory usage of possible orphaned IKE SAs. Implementations may choose to handle situations with thousands of unauthenticated IKE SAs differently from situations with very few such SAs.
实现应该权衡发送活动性检查的资源消耗与可能孤立的IKE SA的内存使用情况。实现可能会选择处理数千个未经验证的IKE SA的情况，与处理此类SA很少的情况不同。
Section 4.4.3 of [RFC4301] defines the Peer Authorization Database (PAD), which provides the link between the Security Policy Database (SPD) and IKEv2. The PAD contains an ordered list of records with
[RFC4301]第4.4.3节定义了对等授权数据库（PAD），它提供了安全策略数据库（SPD）和IKEv2之间的链接。PAD包含一个有序的记录列表，其中包含
peers' identities along with corresponding authentication data and Child SA authorization data. When the IKE SA is being established, the PAD is consulted to determine how the peer should be authenticated and what Child SAs it is authorized to create.
对等方的身份以及相应的身份验证数据和子SA授权数据。在建立IKE SA时，将咨询PAD以确定对等方应如何进行身份验证以及授权其创建哪个子SA。
When using NULL authentication, the peer identity is not authenticated and cannot be trusted. If ID_NULL is used with NULL authentication, there is no ID at all. The processing of the PAD described in Section 4.4.3 of [RFC4301] is updated for NULL authentication as follows.
使用空身份验证时，对等身份未经身份验证，因此不可信任。如果ID_NULL与NULL身份验证一起使用，则根本没有ID。[RFC4301]第4.4.3节中描述的PAD处理更新为空验证，如下所示。
NULL authentication is added as one of the supported authentication methods. This method does not have any authentication data. ID_NULL is included into the list of allowed ID types. The matching rule for ID_NULL consists only of whether this type is used, i.e., no actual ID matching is done as ID_NULL contains no identity data.
空身份验证被添加为受支持的身份验证方法之一。此方法没有任何身份验证数据。ID_NULL包含在允许的ID类型列表中。ID_NULL的匹配规则仅包括是否使用此类型，即，由于ID_NULL不包含标识数据，因此不会进行实际的ID匹配。
When using the NULL Authentication method, those matching rules MUST include matching of a new flag in the SPD entry specifying whether unauthenticated users are allowed to use that entry. That is, each SPD entry needs to be augmented to have a flag specifying whether it can be used with NULL authentication or not, and only those rules that explicitly have that flag turned on can be used with unauthenticated connections.
使用空身份验证方法时，这些匹配规则必须在SPD条目中包含新标志的匹配，该标志指定是否允许未经身份验证的用户使用该条目。也就是说，每个SPD条目都需要增加一个标志来指定它是否可以用于空身份验证，并且只有那些明确启用该标志的规则才能用于未经身份验证的连接。
The specific updates of text in Section 4.4.3 of [RFC4301] are listed in Appendix A.
附录A中列出了[RFC4301]第4.4.3节中文本的具体更新。
Traffic Selectors and narrowing allow two IKE peers to mutually agree on a traffic range for an IPsec SA. An unauthenticated peer must not be allowed to use this mechanism to steal traffic that an IKE peer intended to be for another host. This is especially problematic when supporting anonymous IKE peers behind NAT, as such IKE peers build an IPsec SA using their pre-NAT IP address that is different from the source IP of their IKE packets. A rogue IKE peer could use malicious Traffic Selectors to trick a remote host into giving it IP traffic that the remote host never intended to be sent to remote IKE peers. For example, if the remote host uses 192.0.2.1 as the DNS server, a rogue IKE peer could set its Traffic Selector to 192.0.2.1 in an attempt to receive the remote peer's DNS traffic. Implementations SHOULD restrict and isolate all anonymous IKE peers from each other and itself and only allow it access to itself and possibly its intended network ranges.
流量选择器和缩小允许两个IKE对等方就IPsec SA的流量范围达成一致。不允许未经身份验证的对等方使用此机制窃取IKE对等方打算用于另一主机的通信量。当支持NAT后面的匿名IKE对等方时，这尤其有问题，因为这样的IKE对等方使用其前NAT IP地址（不同于其IKE数据包的源IP）构建IPsec SA。恶意IKE对等方可以使用恶意流量选择器欺骗远程主机，使其提供远程主机从未打算发送给远程IKE对等方的IP流量。例如，如果远程主机使用192.0.2.1作为DNS服务器，恶意IKE对等方可以将其流量选择器设置为192.0.2.1，以尝试接收远程对等方的DNS流量。实现应该限制和隔离所有匿名IKE对等点，使其彼此和自身隔离，并且只允许其访问自身以及可能的预期网络范围。
One method to achieve this is to always assign internal IP addresses to unauthenticated IKE clients, as described in Section 2.19 of [RFC7296]. Implementations may also use other techniques such as internal NAT and connection tracking.
实现这一点的一种方法是始终将内部IP地址分配给未经验证的IKE客户端，如[RFC7296]第2.19节所述。实现还可以使用其他技术，例如内部NAT和连接跟踪。
Implementations MAY force unauthenticated IKE peers to single host-to-host IPsec SAs. When using IPv6, this is not always possible, so implementations MUST be able to assign a full /64 address block to the peer as described in [RFC5739], even if it is not authenticated.
实现可能会强制未经身份验证的IKE对等方使用单主机对主机IPsec SAs。当使用IPv6时，这并不总是可能的，因此实现必须能够按照[RFC5739]中所述将完整/64地址块分配给对等方，即使它没有经过身份验证。
If authenticated IKE sessions are possible for a certain Traffic Selector range between the peers, then unauthenticated IKE SHOULD NOT be allowed for that Traffic Selector range. When mixing authenticated and unauthenticated IKE with the same peer, policy rules should ensure the highest level of security will be used to protect the communication between the two peers. See [RFC7435] for details.
如果对等方之间的某个流量选择器范围可以使用经过身份验证的IKE会话，则该流量选择器范围不允许使用未经身份验证的IKE会话。当将经过身份验证和未经身份验证的IKE与同一对等方混合时，策略规则应确保使用最高级别的安全性来保护两个对等方之间的通信。详见[RFC7435]。
If both peers use NULL authentication, the entire key exchange becomes unauthenticated. This makes the IKE session vulnerable to active MITM attacks.
如果两个对等方都使用空身份验证，则整个密钥交换将变得未经身份验证。这使得IKE会话容易受到主动MITM攻击。
Using an ID Type other than ID_NULL with the NULL Authentication method may compromise the client's anonymity in case of an active MITM attack.
在主动MITM攻击的情况下，使用ID_NULL以外的ID类型和NULL身份验证方法可能会损害客户端的匿名性。
IKE implementations without NULL authentication have always performed mutual authentication and were not designed for use with unauthenticated IKE peers. Implementations might have made assumptions that remote peers are identified. With NULL authentication, these assumptions are no longer valid. Furthermore, the host itself might have made trust assumptions or may not be aware of the network topology changes that resulted from IPsec SAs from unauthenticated IKE peers.
没有空身份验证的IKE实现始终执行相互身份验证，并且设计用于未经身份验证的IKE对等方。实现可能假设远程对等点已被识别。对于空身份验证，这些假设不再有效。此外，主机本身可能做出了信任假设，或者可能不知道未经身份验证的IKE对等方的IPsec SAs导致的网络拓扑更改。
With NULL authentication, an established IKE session is no longer guaranteed to provide a verifiable (authenticated) entity known to the system or network. Any logging of unproven ID payloads that were not authenticated should be clearly marked and treated as "untrusted" and possibly accompanied by logging the remote IP address of the IKE session. Rate limiting of logging might be required to prevent excessive resource consumption causing system damage.
使用空身份验证时，已建立的IKE会话不再保证提供系统或网络已知的可验证（已验证）实体。任何未经验证的未经验证的ID有效载荷的记录都应明确标记并视为“不受信任”，并可能伴随记录IKE会话的远程IP地址。可能需要限制日志记录的速率，以防止过度的资源消耗导致系统损坏。
Section 2.6 of [RFC7296] provides guidance for mitigation of denial-of-service (DoS) attacks by issuing COOKIES in response to resource consumption of half-open IKE SAs. Furthermore, [DDOS-PROTECTION] offers additional countermeasures in an attempt to distinguish attacking IKE packets from legitimate IKE peers.
[RFC7296]的第2.6节提供了通过发布cookie响应半开放IKE SA的资源消耗来缓解拒绝服务（DoS）攻击的指南。此外，[DDOS-PROTECTION]还提供了额外的对策，试图将攻击的IKE数据包与合法的IKE对等方区分开来。
These defense mechanisms do not take into account IKE systems that allow unauthenticated IKE peers. An attacker using NULL authentication is a fully legitimate IKE peer that is only distinguished from authenticated IKE peers by having used NULL authentication.
这些防御机制不考虑允许未经验证的IKE对等方的IKE系统。使用空身份验证的攻击者是完全合法的IKE对等方，仅通过使用空身份验证与经过身份验证的IKE对等方进行区分。
Implementers that implement NULL authentication should ensure their implementation does not make any assumptions that depend on IKE peers being "friendly", "trusted", or "identifiable". While implementations should have been written to account for abusive authenticated clients, any omission or error in handling abusive clients may have gone unnoticed because abusive clients have been a rare or nonexistent problem. When adding support for unauthenticated IKE peers, these implementation omissions and errors will be found and abused by attackers. For example, an unauthenticated IKE peer could send an abusive amount of Liveness probes or Delete requests.
实现空身份验证的实现者应该确保他们的实现不会做出任何依赖于IKE对等点“友好”、“可信”或“可识别”的假设。虽然编写实现时应该考虑滥用身份验证客户端，但在处理滥用客户端时的任何遗漏或错误都可能未被注意到，因为滥用客户端是一个罕见或不存在的问题。在添加对未经验证的IKE对等点的支持时，攻击者将发现并滥用这些实现遗漏和错误。例如，未经身份验证的IKE对等方可能会发送大量的活动性探测或删除请求。
Combining authenticated and unauthenticated IKE peers on a single host can be dangerous, assuming the authenticated IKE peer gains more or different access from unauthenticated peers (otherwise, why not only allow unauthenticated peers). An unauthenticated IKE peer MUST NOT be able to reach resources only meant for authenticated IKE peers and MUST NOT be able to replace the Child SAs of an authenticated IKE peer.
假设经过身份验证的IKE对等方从未经身份验证的对等方获得更多或不同的访问权限（否则，为什么不只允许未经身份验证的对等方），那么在单个主机上组合经过身份验证的和未经身份验证的IKE对等方可能是危险的。未经验证的IKE对等方不能访问仅用于已验证IKE对等方的资源，也不能替换已验证IKE对等方的子SA。
When a host relies on packet filters or firewall software to protect itself, establishing an IKE SA and installing an IPsec SA might accidentally circumvent these packet filters and firewall restrictions, as the Encapsulating Security Payload (ESP, protocol 50) or ESPinUDP (UDP port 4500) packets of the encrypted traffic do not match the packet filters defined for unencrypted traffic. IKE peers supporting unauthenticated IKE MUST pass all decrypted traffic through the same packet filters and security mechanisms as incoming plaintext traffic.
当主机依赖数据包过滤器或防火墙软件来保护自身时，建立IKE SA和安装IPsec SA可能会意外地绕过这些数据包过滤器和防火墙限制，例如封装安全负载（ESP，协议50）或ESPinUDP（UDP端口4500）加密流量的数据包与为未加密流量定义的数据包筛选器不匹配。支持未经身份验证的IKE的IKE对等方必须通过与传入明文通信相同的包过滤器和安全机制传递所有解密的通信。
Per this document, IANA has added a new entry in the "IKEv2 Authentication Method" registry:
根据本文件，IANA在“IKEv2认证方法”注册表中添加了一个新条目：
13 NULL Authentication
13空身份验证
Per this document, IANA has added a new entry in the "IKEv2 Identification Payload ID Types" registry:
根据本文件，IANA在“IKEv2标识有效负载ID类型”注册表中添加了一个新条目：
13 ID_NULL
13 ID_NULL
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 4301，DOI 10.17487/RFC4301，2005年12月<http://www.rfc-editor.org/info/rfc4301>.
[RFC5739] Eronen, P., Laganier, J., and C. Madson, "IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5739, DOI 10.17487/RFC5739, February 2010, <http://www.rfc-editor.org/info/rfc5739>.
[RFC5739]Eronen，P.，Laganier，J.，和C.Madson，“互联网密钥交换协议版本2（IKEv2）中的IPv6配置”，RFC 5739，DOI 10.17487/RFC5739，2010年2月<http://www.rfc-editor.org/info/rfc5739>.
[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, <http://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月<http://www.rfc-editor.org/info/rfc7296>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7258]Farrell，S.和H.Tschofenig，“普遍监控是一种攻击”，BCP 188，RFC 7258，DOI 10.17487/RFC7258，2014年5月<http://www.rfc-editor.org/info/rfc7258>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7435]Dukhovni，V.，“机会主义安全：大部分时间的一些保护”，RFC 7435，DOI 10.17487/RFC7435，2014年12月<http://www.rfc-editor.org/info/rfc7435>.
[AUTOVPN] Sheffer, Y. and Y. Nir, "The AutoVPN Architecture", Work in Progress, draft-sheffer-autovpn-00, February 2014.
[AUTOVPN]Sheffer，Y.和Y.Nir，“AUTOVPN架构”，正在进行的工作，草稿-Sheffer-AUTOVPN-00，2014年2月。
[DDOS-PROTECTION] Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange (IKE) Implementations from Distributed Denial of Service Attacks", Work in Progress, draft-ietf-ipsecme-ddos-protection-02, July 2015.
[DDOS-PROTECTION]Nir，Y.和V.Smyslov，“保护互联网密钥交换（IKE）实施免受分布式拒绝服务攻击”，正在进行的工作，草稿-ietf-ipsecme-DDOS-PROTECTION-022015年7月。
This appendix lists the specific updates of the text in Section 4.4.3 of [RFC4301] that should be followed when implementing NULL authentication.
本附录列出了[RFC4301]第4.4.3节中文本的具体更新，在实施空认证时应遵循这些更新。
A new item is added to the list of supported ID types in Section 4.4.3.1 of [RFC4301]
[RFC4301]第4.4.3.1节中支持的ID类型列表中添加了一个新项
o NULL ID (matches ID type only)
o 空ID（仅与ID类型匹配）
and the following text is added at the end of the section:
并在本节末尾添加以下文本：
Added text: The NULL ID type is defined as having no data. For this name type, the matching function is defined as comparing the ID type only.
添加的文本：空ID类型定义为没有数据。对于此名称类型，匹配函数定义为仅比较ID类型。
A new item is added to the list of authentication data types in Section 4.4.3.2 of [RFC4301]:
[RFC4301]第4.4.3.2节中的认证数据类型列表中添加了一个新项目：
- NULL authentication
- 空身份验证
and the next paragraph is updated as follows:
下一段更新如下：
Old: For authentication based on an X.509 certificate [...] For authentication based on a pre-shared secret, the PAD contains the pre-shared secret to be used by IKE.
旧：对于基于X.509证书的身份验证[…]对于基于预共享密钥的身份验证，PAD包含IKE使用的预共享密钥。
New: For authentication based on an X.509 certificate [...] For authentication based on a pre-shared secret, the PAD contains the pre-shared secret to be used by IKE. For NULL authentication the PAD contains no data.
新：对于基于X.509证书的身份验证[…]对于基于预共享密钥的身份验证，PAD包含IKE使用的预共享密钥。对于空身份验证，PAD不包含任何数据。
In addition, the following text is added at the end of Section 4.4.3.4 of [RFC4301]:
此外，在[RFC4301]第4.4.3.4节末尾添加了以下内容：
Added text: When using the NULL Authentication method, implementations MUST make sure that they do not mix authenticated and unauthenticated SPD rules, i.e., implementations need to keep them separately; for example, by adding a flag in the SPD to tell whether NULL authentication can be used or not for the entry. That is, each SPD entry needs to be augmented to have a flag specifying whether
添加文本：当使用空身份验证方法时，实现必须确保它们不会混合使用经过身份验证和未经身份验证的SPD规则，即，实现需要将它们分开保存；例如，通过在SPD中添加一个标志来告诉条目是否可以使用空身份验证。也就是说，每个SPD条目都需要增加一个标志来指定
it can be used with NULL authentication or not, and only those rules that explicitly have that flag set can be used with unauthenticated connections.
它可以与空身份验证一起使用，也可以不与空身份验证一起使用，只有那些明确设置了该标志的规则才能与未经身份验证的连接一起使用。
Acknowledgments
致谢
The authors would like to thank Yaron Sheffer and Tero Kivinen for their reviews, valuable comments, and contributed text.
作者要感谢亚龙·谢弗和泰罗·基维宁的评论、宝贵的评论和贡献的文本。
Authors' Addresses
作者地址
Valery Smyslov ELVIS-PLUS PO Box 81 Moscow (Zelenograd) 124460 Russian Federation
Valery Smyslov ELVIS-PLUS邮政信箱81莫斯科（Zelenograd）124460俄罗斯联邦
Phone: +7 495 276 0211
Email: svan@elvis.ru
Phone: +7 495 276 0211
Email: svan@elvis.ru
Paul Wouters Red Hat
保罗·沃特斯红帽
Email: pwouters@redhat.com
Email: pwouters@redhat.com