Internet Engineering Task Force (IETF) Y. Sheffer
Request for Comments: 6989 Porticor
Updates: 5996 S. Fluhrer
Category: Standards Track Cisco
ISSN: 2070-1721 July 2013
Internet Engineering Task Force (IETF) Y. Sheffer
Request for Comments: 6989 Porticor
Updates: 5996 S. Fluhrer
Category: Standards Track Cisco
ISSN: 2070-1721 July 2013
Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2)
Internet密钥交换协议版本2（IKEv2）的附加Diffie-Hellman测试
Abstract
摘要
This document adds a small number of mandatory tests required for the secure operation of the Internet Key Exchange Protocol version 2 (IKEv2) with elliptic curve groups. No change is required to IKE implementations that use modular exponential groups, other than a few rarely used so-called Digital Signature Algorithm (DSA) groups. This document updates the IKEv2 protocol, RFC 5996.
本文档添加了少量必需的测试，以确保具有椭圆曲线组的Internet密钥交换协议版本2（IKEv2）的安全运行。除了少数很少使用的所谓数字签名算法（DSA）组之外，使用模块化指数组的IKE实现不需要更改。本文件更新了IKEv2协议RFC 5996。
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/rfc6989.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6989.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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 ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Group Membership Tests ..........................................3
2.1. Sophie Germain Prime MODP Groups ...........................3
2.2. MODP Groups with Small Subgroups ...........................3
2.3. Elliptic Curve Groups ......................................4
2.4. Transition .................................................4
2.5. Protocol Behavior ..........................................5
3. Side-Channel Attacks ............................................5
4. Security Considerations .........................................6
4.1. DH Key Reuse and Multiple Peers ............................6
4.2. DH Key Reuse: Variants .....................................7
4.3. Groups Not Covered by This RFC .............................7
4.4. Behavior upon Test Failure .................................7
5. IANA Considerations .............................................8
6. Acknowledgements ................................................8
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References .....................................9
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Group Membership Tests ..........................................3
2.1. Sophie Germain Prime MODP Groups ...........................3
2.2. MODP Groups with Small Subgroups ...........................3
2.3. Elliptic Curve Groups ......................................4
2.4. Transition .................................................4
2.5. Protocol Behavior ..........................................5
3. Side-Channel Attacks ............................................5
4. Security Considerations .........................................6
4.1. DH Key Reuse and Multiple Peers ............................6
4.2. DH Key Reuse: Variants .....................................7
4.3. Groups Not Covered by This RFC .............................7
4.4. Behavior upon Test Failure .................................7
5. IANA Considerations .............................................8
6. Acknowledgements ................................................8
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References .....................................9
IKEv2 [RFC5996] consists of the establishment of a shared secret using the Diffie-Hellman (DH) protocol, followed by authentication of the two peers. Existing implementations typically use modular exponential (MODP) DH groups, such as those defined in [RFC3526].
IKEv2[RFC5996]包括使用Diffie-Hellman（DH）协议建立共享秘密，然后对两个对等方进行身份验证。现有实现通常使用模块化指数（MODP）DH组，如[RFC3526]中定义的组。
IKEv2 does not require that any tests be performed by a peer receiving a public Diffie-Hellman key from the other peer. This is fine for the common case of MODP groups. For other DH groups, when peers reuse DH values across multiple IKE sessions, the lack of tests by the recipient results in a potential vulnerability (see Section 4.1 for more details). In particular, this is true for Elliptic Curve (EC) groups, whose use is becoming ever more popular. This document defines such tests for several types of DH groups.
IKEv2不要求从另一个对等方接收公共Diffie-Hellman密钥的对等方执行任何测试。对于MODP组的常见情况，这是很好的。对于其他DH组，当对等方在多个IKE会话中重用DH值时，接收方缺乏测试会导致潜在的漏洞（有关更多详细信息，请参阅第4.1节）。特别是，对于椭圆曲线（EC）群，这是正确的，它的使用变得越来越流行。本文件规定了几种DH组的此类试验。
In addition, this document describes another potential attack related to the reuse of DH keys: a timing attack. This additional material is taken from [RFC2412].
此外，本文档还描述了与DH密钥重用相关的另一种潜在攻击：定时攻击。此附加材料取自[RFC2412]。
This document updates [RFC5996] by adding security requirements that apply to many of the protocol's implementations.
本文档通过添加适用于许多协议实现的安全要求来更新[RFC5996]。
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]中所述进行解释。
This section describes the tests that need to be performed by IKE peers receiving a Key Exchange (KE) payload. The tests are RECOMMENDED for all implementations but only REQUIRED for those that reuse DH private keys (as defined in [RFC5996], Section 2.12). The tests apply to the recipient of a KE payload and describe how it should check the received payload. They are listed here according to the DH group being used.
本节描述接收密钥交换（KE）负载的IKE对等方需要执行的测试。建议对所有实现进行测试，但仅对重用DH私钥的实现进行测试（如[RFC5996]第2.12节所定义）。测试适用于KE有效载荷的接收者，并描述其应如何检查接收到的有效载荷。此处根据所使用的DH组列出了它们。
These are currently the most commonly used groups; all these groups have the property that (p-1)/2 is also prime; this section applies to any such MODP group. Each recipient MUST verify that the peer's public value r is in the legal range (1 < r < p-1). According to [Menezes], Section 2.2, even with this check there remains the possibility of leaking a single bit of the secret exponent when DH keys are reused; this amount of leakage is insignificant.
这些是目前最常用的群体；所有这些群都具有（p-1）/2也是素数的性质；本节适用于任何此类MODP组。每个接收者必须验证对等者的公共价值r是否在合法范围内（1<r<p-1）。根据[Menezes]第2.2节，即使使用此检查，在重复使用DH密钥时仍有可能泄漏机密指数的单个位；这一泄漏量微不足道。
See Section 5 for the specific groups covered by this section.
有关本节所涵盖的特定群体，请参见第5节。
[RFC5114] defines modular exponential groups with small subgroups; these are modular exponential groups with comparatively small subgroups, and all have (p-1)/2 composite. Section 2.1 of [Menezes] describes some informational leakage from a small-subgroup attack on these groups if the DH private value is reused.
[RFC5114]定义了具有小子群的模指数群；这些是具有相对较小子群的模指数群，并且都具有（p-1）/2复合群。[Menezes]的第2.1节描述了在重用DH私有值的情况下，小子组攻击对这些组造成的一些信息泄漏。
This leakage can be prevented if the recipient performs a test on the peer's public value; however, this test is expensive (approximately as expensive as what reusing DH private values saves). In addition, the NIST standard ([NIST-800-56A], Section 5.6.2.4) requires that test; hence, anyone needing to conform to that standard will need to implement the test anyway.
如果接收方对对等方的公共价值进行测试，则可以防止这种泄漏；然而，这个测试是昂贵的（大约和重用DH私有值所节省的费用一样昂贵）。此外，NIST标准（[NIST-800-56A]，第5.6.2.4节）要求进行该试验；因此，任何需要符合该标准的人都需要实施测试。
Because of the above, the IKE implementation MUST choose between one of the following two options:
由于上述原因，IKE实现必须在以下两个选项中选择一个：
o It MUST check both that the peer's public value is in range (1 < r < p-1) and that r^q = 1 mod p (where q is the size of the subgroup, as listed in the RFC defining the group). DH private values MAY then be reused. This option is appropriate if conformance to [NIST-800-56A] is required.
o 它必须检查对等方的公共值是否在范围内（1<r<p-1），以及r^q=1 mod p（其中q是子组的大小，如定义组的RFC中所列）。然后可以重用DH私有值。如果要求符合[NIST-800-56A]，则此选项适用。
o It MUST NOT reuse DH private values (that is, the DH private value for each DH exchange MUST be generated from a fresh output of a cryptographically secure random number generator), and it MUST check that the peer's public value is in range (1 < r < p-1). This option is more appropriate if conformance to [NIST-800-56A] is not required.
o 它不能重用DH私有值（即，每个DH交换的DH私有值必须由加密安全随机数生成器的新输出生成），并且必须检查对等方的公共值是否在范围内（1<r<p-1）。如果不要求符合[NIST-800-56A]，则该选项更合适。
See Section 5 for the specific groups covered by this section.
有关本节所涵盖的特定群体，请参见第5节。
IKEv2 can be used with elliptic curve groups defined over a field GF(p) [RFC5903] [RFC5114]. According to [Menezes], Section 2.3, there is some informational leakage possible. A receiving peer MUST check that its peer's public value is valid; that is, the x and y parameters from the peer's public value satisfy the curve equation, y^2 = x^3 + ax + b mod p (where for groups 19, 20, and 21, a=-3 (mod p), and all other values of a, b, and p for the group are listed in the RFC defining the group).
IKEv2可用于域GF（p）[RFC5903][RFC5114]上定义的椭圆曲线群。根据[Menezes]第2.3节，可能存在一些信息泄漏。接收对等方必须检查其对等方的公共值是否有效；也就是说，对等方公共值的x和y参数满足曲线方程y^2=x^3+ax+b mod p（其中对于组19、20和21，a=-3（mod p），以及组的所有其他a、b和p值都列在定义组的RFC中）。
We note that an additional check to ensure that the public value is not the point at infinity is not needed, because IKE (see Section 7 of [RFC5903]) does not allow for encoding this value.
我们注意到，不需要额外检查以确保公共值不是无穷远处的点，因为IKE（参见[RFC5903]第7节）不允许对该值进行编码。
See Section 5 for the specific groups covered by this section.
有关本节所涵盖的特定群体，请参见第5节。
Existing implementations of IKEv2 with Elliptic Curve Diffie-Hellman (ECDH) groups may be modified to include the tests described in the current document, even if they do not reuse DH keys. The tests can be considered as sanity checks and will prevent the code having to handle inputs that it may not have been designed to handle.
可以修改带有椭圆曲线Diffie-Hellman（ECDH）组的IKEv2的现有实现，以包括当前文档中描述的测试，即使它们不重用DH密钥。这些测试可以被视为健全性检查，并将防止代码必须处理其可能未设计用于处理的输入。
ECDH implementations that do reuse DH keys MUST be enhanced to include the above tests.
必须增强重用DH密钥的ECDH实现，以包括上述测试。
The recipient of a DH public key that fails one of the above tests must assume that the sender is either truly malicious or has a bug in its implementation. The behavior defined below attempts to balance resistance to attackers that are trying to disrupt the IKE exchange, against the need to help a badly implemented peer by providing useful error indications.
未通过上述测试之一的DH公钥的接收者必须假设发送者是真正的恶意的，或者在其实现中存在缺陷。下面定义的行为试图平衡对试图破坏IKE交换的攻击者的抵抗，以及通过提供有用的错误指示来帮助实现较差的对等方的需要。
If this error happens during the IKE_SA_INIT exchange, then the recipient MUST drop the message that contains an invalid KE payload and MUST NOT use that message when creating the IKE security association (SA).
如果此错误在IKE_SA_INIT交换期间发生，则收件人必须删除包含无效KE负载的消息，并且在创建IKE安全关联（SA）时不得使用该消息。
If the implementation employs the DoS-resistant behavior proposed in Section 2.4 of [RFC5996], it may simply ignore the erroneous request or response message, and continue waiting for a later message containing a legitimate KE payload.
如果实现采用了[RFC5996]第2.4节中提出的抗DoS行为，则它可以忽略错误的请求或响应消息，并继续等待包含合法有效负载的后续消息。
If DoS-resistant behavior is not implemented and the invalid KE payload was in the IKE_SA_INIT request, the implementation MAY send an INVALID_SYNTAX error notification back and remove the in-progress IKE SA; if the invalid KE payload was in the IKE_SA_INIT response, then the implementation MAY simply delete the half-created IKE SA and re-initiate the exchange.
如果未实现DoS抵抗行为，并且IKE_SA_INIT请求中存在无效的KE有效负载，则实现可能会发回无效的_语法错误通知，并删除正在进行的IKE SA；如果无效的KE有效负载在IKE_SA_INIT响应中，那么实现可以简单地删除半创建的IKE SA并重新启动交换。
If the invalid KE payload is received during the CREATE_CHILD_SA exchange (or any other exchange after the IKE SA has been established) and the invalid KE payload is in the request message, the Responder MUST reply with an INVALID_SYNTAX error notification and drop the IKE SA. If the invalid KE payload is in a response, the Initiator getting this reply MUST immediately delete the IKE SA by sending an IKE SA Delete notification as a new exchange. In this case, the sender evidently has an implementation bug, and dropping the IKE SA makes it easier to detect.
如果在CREATE_CHILD_SA交换（或建立IKE SA后的任何其他交换）期间接收到无效的KE有效负载，并且请求消息中存在无效的KE有效负载，则响应者必须回复无效的_语法错误通知，并丢弃IKE SA。如果响应中存在无效的KE有效负载，则获得此响应的发起方必须通过将IKE SA delete通知作为新交换发送来立即删除IKE SA。在这种情况下，发送方显然有一个实现错误，删除IKE SA使其更容易检测。
In addition to the small-subgroup attack, there is also a potential timing attack on IKE peers when they are reusing Diffie-Hellman secret values. This is a side-channel attack, which means that it may or may not be a vulnerability in certain cases, depending on implementation details and the threat model.
除了小子组攻击之外，当IKE对等方重用Diffie-Hellman秘密值时，还存在对它们的潜在定时攻击。这是一种侧通道攻击，这意味着它在某些情况下可能是漏洞，也可能不是漏洞，具体取决于实施细节和威胁模型。
The remainder of this section is quoted from [RFC2412], Section 5, with a few minor clarifications. This attack still applies to IKEv2 implementations, and both to MODP groups and ECDH groups. We also note that more efficient countermeasures are available for EC groups represented in projective form, but these are outside the scope of the current document.
本节剩余部分引自[RFC2412]第5节，并进行了一些小澄清。此攻击仍然适用于IKEv2实现，以及MODP组和ECDH组。我们还注意到，对于以投射形式表示的EC组，可以使用更有效的对策，但这些不在当前文档的范围内。
Timing attacks that are capable of recovering the exponent value used in Diffie-Hellman calculations have been described by Paul Kocher [Kocher]. In order to nullify the attack, implementors must take pains to obscure the sequence of operations involved in carrying out modular exponentiations.
Paul Kocher[Kocher]描述了能够恢复Diffie-Hellman计算中使用的指数值的定时攻击。为了消除攻击，实现者必须尽力掩盖执行模幂运算所涉及的操作序列。
One potential method to foil these timing attacks is to use a "blinding factor". In this method, a group element, r, is chosen at random, and its multiplicative inverse modulo p is computed, which we'll call r_inv. r_inv can be computed by the Extended Euclidean Method, using r and p as inputs. When an exponent x is chosen, the value r_inv^x is also calculated. Then, when calculating (g^y)^x, the implementation will calculate this sequence:
挫败这些定时攻击的一个潜在方法是使用“致盲因子”。在这种方法中，随机选择一个组元素r，并计算其乘法逆模p，我们称之为r_inv。r_inv可以通过扩展欧几里德方法计算，使用r和p作为输入。选择指数x时，还将计算值r_inv^x。然后，在计算（g^y）^x时，实现将计算以下序列：
A = r*g^y
B = A^x = (r*g^y)^x = (r^x)(g^(xy))
C = B*r_inv^x = (r^x)(r^(-1*x))(g^(xy)) = g^(xy)
A = r*g^y
B = A^x = (r*g^y)^x = (r^x)(g^(xy))
C = B*r_inv^x = (r^x)(r^(-1*x))(g^(xy)) = g^(xy)
The blinding factor is only necessary if the exponent x is used more than 100 times.
仅当指数x使用超过100次时，才需要盲因子。
This entire document is concerned with the IKEv2 security protocol and the need to harden it in some cases.
整个文档都与IKEv2安全协议有关，并且在某些情况下需要加强该协议。
This section describes one variant of the attack prevented by the tests defined above.
本节描述了通过上述测试防止的攻击的一种变体。
Suppose that IKE peer Alice maintains IKE security associations with peers Bob and Eve. Alice uses the same secret ECDH key for both SAs, which is allowed with some restrictions. If Alice does not implement these tests, Eve will be able to send a malformed public key, which would allow her to efficiently determine Alice's private key (as described in Section 2 of [Menezes]). Since the key is shared, Eve will be able to obtain Alice's shared IKE SA key with Bob.
假设IKE对等方Alice与对等方Bob和Eve保持IKE安全关联。Alice对两个SA使用相同的秘密ECDH密钥，这是允许的，但有一些限制。如果Alice没有实现这些测试，Eve将能够发送格式错误的公钥，这将允许她有效地确定Alice的私钥（如[Menezes]第2节所述）。由于密钥是共享的，Eve将能够获得Alice与Bob共享的IKE SA密钥。
Private DH keys can be reused in different ways, with subtly different security implications. For example:
私有DH密钥可以以不同的方式重用，具有细微不同的安全含义。例如：
1. DH keys are reused for multiple connections (IKE SAs) to the same peer and for connections to different peers.
1. DH密钥可用于同一对等方的多个连接（IKE SA）和不同对等方的连接。
2. DH keys are reused for multiple connections to the same peer (e.g., when the peer is identified by its IP address) but not for different peers.
2. DH密钥用于同一对等方的多个连接（例如，当对等方通过其IP地址标识时），但不用于不同的对等方。
3. DH keys are reused only when they had not been used to complete an exchange, e.g., when the peer replies with an INVALID_KE_PAYLOAD notification.
3. DH密钥只有在未用于完成交换时才被重用，例如，当对等方回复无效的_KE_负载通知时。
Both the small-subgroup attack and the timing attack described in this document apply at least to options #1 and #2.
本文档中描述的小子组攻击和定时攻击至少适用于选项1和选项2。
There are a number of group types that are not specifically addressed by this RFC. A document that defines such a group MUST describe the tests required by that group.
本RFC未明确说明许多组类型。定义此类组的文件必须描述该组所需的测试。
One specific type of group would be an even-characteristic elliptic curve group. Now, these curves have cofactors greater than 1; this leads to a possibility of some information leakage. There are several ways to address this information leakage, such as performing a test analogous to the test in Section 2.2 or adjusting the ECDH operation to avoid this leakage (such as Elliptic Curve Cryptography Cofactor Diffie-Hellman (ECC CDH), where the shared secret really is hxyG). Because the appropriate test depends on how the group is defined, we cannot document it in advance.
一种特殊类型的群是偶数特征椭圆曲线群。现在，这些曲线的辅因子大于1；这可能导致某些信息泄漏。有几种方法可以解决此信息泄漏问题，例如执行与第2.2节中的测试类似的测试或调整ECDH操作以避免此泄漏（例如椭圆曲线加密辅助因子Diffie Hellman（ECC CDH），其中共享秘密实际上是hxyG）。因为适当的测试取决于如何定义组，所以我们不能提前记录它。
The behavior recommended in Section 2.5 is in line with generic error treatment during the IKE_SA_INIT exchange, per Section 2.21.1 of [RFC5996]. The sender is not required to send back an error notification, and the recipient cannot depend on this notification because it is unauthenticated and may in fact have been sent by an attacker trying to launch a DoS attack on the connection. Thus, the notification is only useful to debug implementation errors.
根据[RFC5996]第2.21.1节，第2.5节中建议的行为符合IKE_SA_INIT交换期间的一般错误处理。发送方不需要发回错误通知，接收方也不能依赖此通知，因为此通知未经验证，实际上可能是由试图对连接发起DoS攻击的攻击者发送的。因此，该通知仅对调试实现错误有用。
On the other hand, the error notification is secure in the sense that no secret information is leaked. All IKEv2 Diffie-Hellman groups are publicly known, and none of the tests defined here depend on any private key. In fact, the tests can all be performed by an eavesdropper.
另一方面，错误通知是安全的，因为不会泄露任何机密信息。所有IKEv2 Diffie-Hellman组都是公开的，这里定义的测试都不依赖于任何私钥。事实上，这些测试都可以由窃听者执行。
The situation when the failure occurs in the CREATE_CHILD_SA exchange is different, since everything is protected by an IKE SA. The peers are authenticated, and error notifications can be relied on. See Section 2.21.3 of [RFC5996] for more details on error handling in this case.
在CREATE_CHILD_SA交换中发生故障的情况有所不同，因为所有内容都受到IKE SA的保护。对等点经过身份验证，可以依赖错误通知。有关这种情况下错误处理的更多详细信息，请参见[RFC5996]第2.21.3节。
IANA has added a column named "Recipient Tests" to the Transform Type 4 - Diffie-Hellman Group Transform IDs registry for IKEv2 [IANA-IKEv2-Registry].
IANA在IKEv2的转换类型4-Diffie-Hellman组转换ID注册表[IANA-IKEv2-registry]中添加了一个名为“收件人测试”的列。
This column has been initially populated as follows.
此列最初填充如下。
+------------------------------------+-----------------------+
| Number | Recipient Tests |
+------------------------------------+-----------------------+
| 1, 2, 5, 14, 15, 16, 17, 18 | RFC 6989, Section 2.1 |
| 22, 23, 24 | RFC 6989, Section 2.2 |
| 19, 20, 21, 25, 26, 27, 28, 29, 30 | RFC 6989, Section 2.3 |
+------------------------------------+-----------------------+
+------------------------------------+-----------------------+
| Number | Recipient Tests |
+------------------------------------+-----------------------+
| 1, 2, 5, 14, 15, 16, 17, 18 | RFC 6989, Section 2.1 |
| 22, 23, 24 | RFC 6989, Section 2.2 |
| 19, 20, 21, 25, 26, 27, 28, 29, 30 | RFC 6989, Section 2.3 |
+------------------------------------+-----------------------+
Groups 27-30 are defined in [RFC6954].
[RFC6954]中定义了第27-30组。
Future documents that define new DH groups for IKEv2 are REQUIRED to provide this information for each new group, possibly by referring to the current document.
为IKEv2定义新DH组的未来文件需要为每个新组提供此信息，可能需要参考当前文件。
We would like to thank Dan Harkins, who initially raised this issue on the IPsec mailing list. Thanks to Tero Kivinen and Rene Struik for their useful comments. Much of the text in Section 3 is taken from [RFC2412], and we would like to thank its author, Hilarie Orman.
我们要感谢Dan Harkins，他最初在IPsec邮件列表中提出了这个问题。感谢Tero Kivinen和Rene Struik的有用评论。第3节中的大部分文字摘自[RFC2412]，我们要感谢其作者Hilarie Orman。
The document was originally prepared using the lyx2rfc tool, created by Nico Williams.
该文档最初是使用Nico Williams创建的lyx2rfc工具编写的。
[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月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[IANA-IKEv2-Registry] IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters", <http://www.iana.org/assignments/ikev2-parameters/>.
[IANA-IKEv2-Registry]IANA，“互联网密钥交换版本2（IKEv2）参数”<http://www.iana.org/assignments/ikev2-parameters/>.
[Kocher] Kocher, P., "Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems", December 1996, <http://www.cryptography.com/timingattack/paper.html>.
[Kocher]Kocher，P.，“对Diffie Hellman、RSA、DSS和其他系统实施的定时攻击”，1996年12月<http://www.cryptography.com/timingattack/paper.html>.
[Menezes] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In Diffie-Hellman Key Agreement Protocols", December 2008, <http://www.cacr.math.uwaterloo.ca/techreports/2008/ cacr2008-24.pdf>.
[Menezes]Menezes，A.和B.Ustaoglu，“关于在Diffie-Hellman密钥协议协议中重用临时密钥”，2008年12月<http://www.cacr.math.uwaterloo.ca/techreports/2008/ cacr2008-24.pdf>。
[NIST-800-56A] National Institute of Standards and Technology (NIST), "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised)", NIST PUB 800-56A, March 2007.
[NIST-800-56A]美国国家标准与技术研究所（NIST），“使用离散对数加密技术的成对密钥建立方案的建议（修订版）”，NIST PUB 800-56A，2007年3月。
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[RFC2412]Orman，H.，“奥克利密钥确定协议”，RFC 2412，1998年11月。
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[RFC3526]Kivinen，T.和M.Kojo，“互联网密钥交换（IKE）的更多模指数（MODP）Diffie-Hellman群”，RFC 3526，2003年5月。
[RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman Groups for Use with IETF Standards", RFC 5114, January 2008.
[RFC5114]Lepinski，M.和S.Kent，“与IETF标准一起使用的其他Diffie-Hellman组”，RFC 5114，2008年1月。
[RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2", RFC 5903, June 2010.
[RFC5903]Fu，D.和J.Solinas，“IKE和IKEv2的模素数的椭圆曲线群（ECP群）”，RFC 5903，2010年6月。
[RFC6954] Merkle, J. and M. Lochter, "Using the Elliptic Curve Cryptography (ECC) Brainpool Curves for the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 6954, July 2013.
[RFC6954]Merkle，J.和M.Lochter，“互联网密钥交换协议版本2（IKEv2）使用椭圆曲线加密（ECC）脑池曲线”，RFC 69542013年7月。
Authors' Addresses
作者地址
Yaron Sheffer Porticor
亚龙谢弗波蒂科酒店
EMail: yaronf.ietf@gmail.com
EMail: yaronf.ietf@gmail.com
Scott Fluhrer Cisco Systems 1414 Massachusetts Ave. Boxborough, MA 01719 USA
Scott Fluhrer思科系统公司美国马萨诸塞州博克斯伯勒马萨诸塞大道1414号01719
EMail: sfluhrer@cisco.com
EMail: sfluhrer@cisco.com