Network Working Group P. Hoffman
Request for Comments: 4894 VPN Consortium
Category: Informational May 2007
Network Working Group P. Hoffman
Request for Comments: 4894 VPN Consortium
Category: Informational May 2007
Use of Hash Algorithms in Internet Key Exchange (IKE) and IPsec
哈希算法在Internet密钥交换（IKE）和IPsec中的使用
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document describes how the IKEv1 (Internet Key Exchange version 1), IKEv2, and IPsec protocols use hash functions, and explains the level of vulnerability of these protocols to the reduced collision resistance of the MD5 and SHA-1 hash algorithms.
本文档描述了IKEv1（Internet密钥交换版本1）、IKEv2和IPsec协议如何使用哈希函数，并解释了这些协议因MD5和SHA-1哈希算法抗冲突性降低而存在的漏洞级别。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Hashes in IKEv1 and IKEv2 . . . . . . . . . . . . . . . . . . 2
3. Hashes in IPsec . . . . . . . . . . . . . . . . . . . . . . . 3
4. PKIX Certificates in IKEv1 and IKEv2 . . . . . . . . . . . . . 3
5. Choosing Cryptographic Functions . . . . . . . . . . . . . . . 3
5.1. Different Cryptographic Functions . . . . . . . . . . . . 4
5.2. Specifying Cryptographic Functions in the Protocol . . . . 4
5.3. Specifying Cryptographic Functions in Authentication . . . 5
6. Suggested Changes . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Suggested Changes for the Protocols . . . . . . . . . . . 6
6.2. Suggested Changes for Implementors . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Informative References . . . . . . . . . . . . . . . . . . . . 8
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Hashes in IKEv1 and IKEv2 . . . . . . . . . . . . . . . . . . 2
3. Hashes in IPsec . . . . . . . . . . . . . . . . . . . . . . . 3
4. PKIX Certificates in IKEv1 and IKEv2 . . . . . . . . . . . . . 3
5. Choosing Cryptographic Functions . . . . . . . . . . . . . . . 3
5.1. Different Cryptographic Functions . . . . . . . . . . . . 4
5.2. Specifying Cryptographic Functions in the Protocol . . . . 4
5.3. Specifying Cryptographic Functions in Authentication . . . 5
6. Suggested Changes . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Suggested Changes for the Protocols . . . . . . . . . . . 6
6.2. Suggested Changes for Implementors . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Informative References . . . . . . . . . . . . . . . . . . . . 8
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 10
Recently, attacks on the collision-resistance properties of MD5 and SHA-1 hash functions have been discovered; [HashAttacks] summarizes the discoveries. The security community is now reexamining how various Internet protocols use hash functions. The goal of this reexamination is to be sure that the current usage is safe in the face of these new attacks, and whether protocols can easily use new hash functions when they become recommended.
最近，发现了对MD5和SHA-1哈希函数的抗冲突特性的攻击；[HashAttacks]总结了这些发现。安全社区现在正在重新检查各种互联网协议如何使用哈希函数。重新检查的目的是确保当前使用在面对这些新攻击时是安全的，以及协议在被推荐时是否可以轻松使用新的哈希函数。
Different protocols use hash functions quite differently. Because of this, the IETF has asked for reviews of all protocols that use hash functions. This document reviews the many ways that three protocols (IKEv1 [IKEv1], IKEv2 [IKEv2], and IPsec [ESP] and [AH]) use hash functions.
不同的协议使用哈希函数的方式完全不同。因此，IETF要求审查所有使用哈希函数的协议。本文档回顾了三种协议（IKEv1[IKEv1]、IKEv2[IKEv2]和IPsec[ESP]和[AH]）使用哈希函数的多种方式。
In this document, "IKEv1" refers to only "Phase 1" of IKEv1 and the agreement process. "IKEv2" refers to the IKE_SA_INIT and IKE_AUTH exchanges. "IPsec" refers to IP encapsulated in either the Authentication Header (AH) or Encapsulating Security Payload (ESP).
在本文件中，“IKEv1”仅指IKEv1的“阶段1”和协议流程。“IKEv2”指IKE_SA_INIT和IKE_AUTH交换。“IPsec”是指封装在身份验证头（AH）或封装安全负载（ESP）中的IP。
Both IKEv1 and IKEv2 can use hash functions as pseudo-random functions (PRFs). The inputs to the PRFs always contain nonce values from both the initiator and the responder that the other party cannot predict in advance. In IKEv1, the length of this nonce is at least 64 bits; in IKEv2, it is at least 128 bits. Because of this, the use of hash functions in IKEv1 and IKEv2 are not susceptible to any known collision-reduction attack.
IKEv1和IKEv2都可以使用哈希函数作为伪随机函数（PRF）。PRF的输入始终包含来自发起方和响应方的nonce值，而另一方无法提前预测。在IKEv1中，该nonce的长度至少为64位；在IKEv2中，它至少是128位。因此，在IKEv1和IKEv2中使用哈希函数不易受到任何已知的冲突减少攻击。
IKEv1 also uses hash functions on the inputs to the PRF. The inputs are a combination of values from both the initiator and responder, and thus the hash function here is not susceptible to any known collision-reduction attack.
IKEv1还对PRF的输入使用哈希函数。输入是来自发起方和响应方的值的组合，因此这里的哈希函数不易受到任何已知的冲突减少攻击。
In IKEv2, hashes are used as integrity protection for all messages after the IKE_SA_INIT Exchange. These hashes are used in Hashed Message Authentication Codes (HMACs). As described in [HMAC-reduction], MD5 used in HMACs is susceptible to forgery, and it is suspected that full SHA-1 used in HMAC is susceptible to forgery. There is no known reason for the person who creates legitimate integrity protection to want to spoof it.
在IKEv2中，哈希用作IKE_SA_INIT交换之后所有消息的完整性保护。这些散列用于散列消息身份验证码（HMAC）。如[HMAC Reduce]所述，HMAC中使用的MD5易被伪造，并且怀疑HMAC中使用的完整SHA-1易被伪造。创建合法完整性保护的人没有已知的理由想要欺骗它。
Both IKEv1 and IKEv2 have authentication modes that use digital signatures. Digital signatures use hashes to make unique digests of the message being signed. With the current known attacks, the only party that can create the two messages that collide is the IKE entity
IKEv1和IKEv2都具有使用数字签名的身份验证模式。数字签名使用散列对被签名的消息进行唯一摘要。在目前已知的攻击中，唯一能够创建两条冲突消息的一方是IKE实体
that generates the message. As shown in [Target-collisions], an attacker can create two different Public Key Infrastructure using X.509 (PKIX) certificates with different identities that have the same signatures.
这就产生了信息。如[Target collisions]所示，攻击者可以使用具有相同签名的不同身份的X.509（PKIX）证书创建两个不同的公钥基础结构。
IKEv1 has two modes, "public key encryption" and "revised public key encryption", that use hashes to identify the public key used. The hash function here is used simply to reduce the size of the identifier. In IKEv2 with public-key certificates, a hash function is used for similar purposes, both for identifying the sender's public key and the trust anchors. Using a collision-reduction attack, an individual could create two public keys that have the same hash value. This is not considered to be a useful attack because the key generator holds both private keys.
IKEv1有两种模式，“公钥加密”和“修改的公钥加密”，它们使用散列来标识所使用的公钥。这里的散列函数只是用来减小标识符的大小。在具有公钥证书的IKEv2中，哈希函数用于类似目的，用于标识发送方的公钥和信任锚。使用冲突减少攻击，个人可以创建两个具有相同哈希值的公钥。这被认为不是一种有用的攻击，因为密钥生成器同时持有两个私钥。
IKEv1 can be used together with Network Access Translator (NAT) traversal support, as described in [NAT-T]; IKEv2 includes this NAT traversal support. In both of these cases, hash functions are used to obscure the IP addresses used by the initiator and/or the responder. The hash function here is not susceptible to any known collision-reduction attack.
IKEv1可以与网络访问转换器（NAT）遍历支持一起使用，如[NAT-T]中所述；IKEv2包括这种NAT遍历支持。在这两种情况下，哈希函数用于隐藏启动器和/或响应程序使用的IP地址。这里的哈希函数不易受到任何已知的冲突减少攻击。
AH uses hash functions for authenticating packets; the same is true for ESP when ESP is using its own authentication. For both uses of IPsec, hash functions are always used in hashed MACs (HMACs). As described in [HMAC-reduction], MD5 used in HMACs is susceptible to forgery, and it is suspected that full SHA-1 used in HMAC is susceptible to forgery. There is no known reason for the person who creates legitimate packet authentication to want to spoof it.
AH使用哈希函数对数据包进行身份验证；当ESP使用自己的身份验证时，ESP也是如此。对于IPsec的两种用途，哈希函数总是在哈希MAC（HMAC）中使用。如[HMAC Reduce]所述，HMAC中使用的MD5易被伪造，并且怀疑HMAC中使用的完整SHA-1易被伪造。创建合法数据包身份验证的人不知道为什么要欺骗它。
Some implementations of IKEv1 and IKEv2 use PKIX certificates for authentication. Any weaknesses in PKIX certificates due to particular ways hash functions are used, or due to weaknesses in particular hash functions used in certificates, will be inherited in IKEv1 and IKEv2 implementations that use PKIX-based authentication.
IKEv1和IKEv2的一些实现使用PKIX证书进行身份验证。由于使用哈希函数的特定方式或由于证书中使用的特定哈希函数的弱点而导致的PKIX证书中的任何弱点都将在使用基于PKIX的身份验证的IKEv1和IKEv2实现中继承。
Recently, there has been more discussion in the IETF about the ability of one party in a protocol to tell the other party which cryptographic functions the first party prefers the second party to use. The discussion was spurred in part by [Deploying]. Although that paper focuses on hash functions, it is relevant to other cryptographic functions as well.
最近，IETF中有更多关于协议中一方告知另一方第一方希望第二方使用哪些加密功能的能力的讨论。讨论的部分原因是[部署]。虽然这篇文章主要讨论散列函数，但它也与其他加密函数相关。
There are (at least) three distinct subtopics related to choosing cryptographic functions in protocols:
有（至少）三个不同的子主题与在协议中选择加密函数有关：
o The ability to pick between different cryptographic functions instead of having just one specified in the protocol
o 能够在不同的加密函数之间进行选择，而不是在协议中只指定一个
o If there are multiple functions, the ability to agree on which function will be used in the main protocol
o 如果有多个功能，则能够就主协议中使用的功能达成一致
o The ability to suggest to the other party which kinds of cryptographic functions should be used in the other party's public key certificates
o 向另一方建议在另一方的公钥证书中应使用哪种加密函数的能力
Protocols that use cryptographic functions can either specify a single function, or can allow different functions. Protocols in the first category are susceptible to attack if the specified function is later found to be too weak for the stated purpose; protocols in the second category can usually avoid such attacks, but at a cost of increased protocol complexity. In the IETF, protocols that allow a choice of cryptographic functions are strongly preferred.
使用加密函数的协议可以指定单个函数，也可以允许不同的函数。如果后来发现指定的功能对于所述目的来说太弱，则第一类协议容易受到攻击；第二类协议通常可以避免此类攻击，但代价是协议复杂性增加。在IETF中，强烈推荐允许选择加密功能的协议。
IKEv1, IKEv2, and IPsec already allow different hash functions in every significant place where hash functions are used (that is, in every place that has any susceptibility to a collision-reduction attack).
IKEv1、IKEv2和IPsec已经允许在使用哈希函数的每个重要位置使用不同的哈希函数（即，在易受冲突减少攻击的每个位置）。
Protocols that allow a choice of cryptographic functions need to have a way for all parties to agree on which function is going to be used. Some protocols, such as secure electronic mail, allow the initiator to simply pick a set of cryptographic functions; if the responder does not understand the functions used, the transmission fails. Other protocols allow for the two parties to agree on which cryptographic functions will be used. This is sometimes called "negotiation", but the term "negotiation" is inappropriate for protocols in which one party (the "proposer") lists all the functions it is willing to use, and the other party (the "chooser") simply picks the ones that will be used.
允许选择加密函数的协议需要有一种方式，以便各方就将要使用的函数达成一致。一些协议，如安全电子邮件，允许发起者简单地选择一组加密功能；如果响应者不理解所使用的功能，则传输失败。其他协议允许双方就使用哪些加密功能达成一致。这有时被称为“协商”，但术语“协商”不适用于协议中一方（“提议者”）列出其愿意使用的所有功能，而另一方（“选择者”）只是选择将要使用的功能。
When a new cryptographic function is introduced, one party may want to tell the other party that they can use the new function. If it is the proposer who wants to use the new function, the situation is easy: the proposer simply adds the new function to its list, possibly
当引入新的加密函数时，一方可能希望告诉另一方他们可以使用新函数。如果是提议者想要使用新函数，情况很简单：提议者可能只是将新函数添加到其列表中
removing other parallel functions that the proposer no longer wants to use.
删除提议人不想再使用的其他并行函数。
On the other hand, if it is the chooser who wants to use the new function and the proposer didn't list it, the chooser may want to signal the proposer that they are capable of using the new function or the chooser may want to say that it is only willing to use the new function. If a protocol wants to handle either of these cases, it has to have a way for the chooser to specify this information to the proposer in its acceptance and/or rejection message.
另一方面，如果是选择者想要使用新函数，而提议者没有列出它，那么选择者可能想向提议者发出信号，表明他们能够使用新函数，或者选择者可能想说它只愿意使用新函数。如果一个协议想要处理这两种情况中的任何一种，它必须有一种方式让选择者在其接受和/或拒绝消息中向提议者指定该信息。
It is not clear from a design standpoint how important it might be to let the chooser specify the additional functions it knows. As long as the proposer offers all the functions it wants to use, there is no reason for the chooser to say "I know one you don't know". The only place where the chooser is able to signal the proposer with different functions is in protocols where listing all the functions might be prohibitive, such as where they would add additional round trips or significant packet length.
从设计的角度来看，让选择器指定它知道的其他函数可能有多重要还不清楚。只要提议者提供了它想要使用的所有函数，选择者就没有理由说“我知道一个你不知道的”。选择器能够用不同功能向提议者发出信号的唯一地方是在协议中，在协议中列出所有功能可能是禁止的，例如，在协议中，它们会增加额外的往返行程或显著的数据包长度。
IKEv1 and IKEv2 allow the proposer to list all functions. Neither allows the chooser to specify which functions that were not proposed it could have used, either in a successful or unsuccessful Security Association (SA) establishment.
IKEv1和IKEv2允许投标人列出所有功能。这两种方法都不允许选择器指定在成功或失败的安全关联（SA）建立中可能使用的未提议的功能。
Passing public key certificates and signatures used in authentication creates additional issues for protocols. When specifying cryptographic functions for a protocol, it is an agreement between the proposer and the chooser. When choosing cryptographic functions for public key certificates, however, the proposer and the chooser are beholden to functions used by the trusted third parties, the certification authorities (CAs). It doesn't really matter what either party wants the other party to use, since the other party is not the one issuing the certificates.
传递用于身份验证的公钥证书和签名会给协议带来额外的问题。当为协议指定加密函数时，它是提议者和选择者之间的协议。然而，当为公钥证书选择加密函数时，提议者和选择者都受制于可信的第三方证书颁发机构（CA）使用的函数。实际上，任何一方希望另一方使用什么并不重要，因为另一方不是颁发证书的人。
In this discussion, the term "certificate" does not necessarily mean a PKIX certificate. Instead, it means any message that binds an identity to a public key, where the message is signed by a trusted third party. This can be non-PKIX certificates or other types of cryptographic identity-binding structures that may be used in the future.
在此讨论中，“证书”一词不一定意味着PKIX证书。相反，它指的是将身份绑定到公钥的任何消息，其中该消息由受信任的第三方签名。这可以是非PKIX证书或将来可能使用的其他类型的加密身份绑定结构。
The question of specifying cryptographic functions is only relevant if one party has multiple certificates or signatures with different cryptographic functions. In this section, the terms "proposer" and "chooser" have a different meaning than in the previous section.
只有当一方拥有具有不同加密功能的多个证书或签名时，指定加密功能的问题才相关。在本节中，“投标人”和“选择人”的含义与前一节中的不同。
Here, both parties act as proposers of the identity they want to use and the certificates with which they are backing up that identity, and both parties are choosers of the other party's identity and certificate.
在这里，双方都作为他们想要使用的身份和他们用来支持该身份的证书的提议者，并且双方都是另一方身份和证书的选择者。
Some protocols allow the proposer to send multiple certificates or signatures, while other protocols only allow the proposer to send a single certificate or signature. Some protocols allow the proposer to send multiple certificates but advise against it, given that certificates can be fairly large (particularly when the CA loads the certificate with lots of information).
一些协议允许投标人发送多个证书或签名，而其他协议仅允许投标人发送单个证书或签名。一些协议允许提议者发送多个证书，但建议不要这样做，因为证书可能相当大（特别是当CA加载带有大量信息的证书时）。
IKEv1 and IKEv2 allow both parties to list all the certificates that they want to use. [PKI4IPsec] proposes to restrict this by saying that all the certificates for a proposer have to have the same identity.
IKEv1和IKEv2允许双方列出他们想要使用的所有证书。[PKI4IPsec]建议限制这一点，即投标人的所有证书必须具有相同的身份。
In investigating how protocols use hash functions, the IETF is looking at (at least) two areas of possible changes to individual protocols: how the IETF might need to change the protocols, and how implementors of current protocols might change what they do. This section describes both of these areas with respect to IKEv1, IKEv2, and IPsec.
在调查协议如何使用散列函数时，IETF正在研究（至少）对单个协议可能进行更改的两个方面：IETF可能需要如何更改协议，以及当前协议的实施者可能如何更改他们的操作。本节介绍了有关IKEv1、IKEv2和IPsec的这两个方面。
Protocols might need to be changed if they rely on the collision-resistance of particular hash functions. They might also need to be changed if they do not allow for the agreement of hash functions because it is expected that the "preferred" hash function for different users will change over time.
如果协议依赖于特定哈希函数的抗冲突性，则可能需要更改协议。如果它们不允许散列函数的一致性，则可能还需要更改它们，因为不同用户的“首选”散列函数将随时间而更改。
IKEv1 and IKEv2 already allow for the agreement of hash functions for both IKE and IPsec, and thus do not need any protocol change.
IKEv1和IKEv2已经允许为IKE和IPsec协商哈希函数，因此不需要任何协议更改。
IKEv1 and IKEv2, when used with public key authentication, already allow each party to send multiple PKIX certificates, and thus do not need any protocol change.
IKEv1和IKEv2在与公钥身份验证一起使用时，已经允许各方发送多个PKIX证书，因此不需要任何协议更改。
There are known weaknesses in PKIX with respect to collision-resistance of some hash functions. Because of this, it is hoped that there will be changes to PKIX fostered by the PKIX Working Group. Some of the changes to PKIX may be usable in IKEv1 and IKEv2 without having to change IKEv1 and IKEv2. Other changes to PKIX may require changes to IKEv1 and IKEv2 in order to incorporate them, but that will not be known until the changes to PKIX are finalized.
PKIX在某些哈希函数的抗冲突性方面存在已知的弱点。因此，希望PKIX工作组推动对PKIX进行修改。PKIX的一些更改可以在IKEv1和IKEv2中使用，而无需更改IKEv1和IKEv2。对PKIX的其他更改可能需要对IKEv1和IKEv2进行更改以合并它们，但在对PKIX的更改最终确定之前，这一点是未知的。
As described in earlier sections, IKE and IPsec themselves are not susceptible to any known collision-reduction attacks on hash functions. Thus, implementors do not need to make changes such as prohibiting the use of MD5 or SHA-1. The mandatory and suggested algorithms for IKEv2 and IPsec are given in [IKEv2Algs] and [IPsecAlgs].
如前几节所述，IKE和IPsec本身不易受到任何已知的哈希函数冲突减少攻击。因此，实现者不需要进行更改，例如禁止使用MD5或SHA-1。[IKEv2Algs]和[IPsecAlgs]中给出了IKEv2和IPsec的强制算法和建议算法。
Note that some IKE and IPsec users will misunderstand the relevance of the known attacks and want to use "stronger" hash functions. Thus, implementors should strongly consider adding support for alternatives, particularly the AES-XCBC-PRF-128 [AES-PRF] and AES-XCBC-MAC-96 [AES-MAC] algorithms, as well as forthcoming algorithms based on the SHA-2 family [SHA2-HMAC].
请注意，一些IKE和IPsec用户会误解已知攻击的相关性，并希望使用“更强”的哈希函数。因此，实现者应该强烈考虑增加对替代方案的支持，特别是AES-XCBC-PRF 128[AES-PRF]和AES-XCBC-MAC-96 [AES-MAC]算法，以及基于SHA-2族[Sa2-HMAC]的即将到来的算法。
Implementations of IKEv1 and IKEv2 that use PKIX certificates for authentication may be susceptible to attacks based on weaknesses in PKIX. It is widely expected that PKIX certificates in the future will use hash functions other than MD5 and SHA-1. Implementors of IKE that allow certificate authentication should strongly consider allowing the use of certificates that are signed with the SHA-256, SHA-384, and SHA-512 hash algorithms. Similarly, those implementors should also strongly consider allowing the sending of multiple certificates for identification.
使用PKIX证书进行身份验证的IKEv1和IKEv2的实现可能容易受到基于PKIX弱点的攻击。人们普遍预计，未来PKIX证书将使用MD5和SHA-1以外的哈希函数。允许证书认证的IKE实现者应强烈考虑允许使用Sha256、Sha-38和Shay-512哈希算法签名的证书。类似地，这些实现者也应该强烈考虑允许发送多个证书来进行身份验证。
This entire document is about the security implications of reduced collision-resistance of common hash algorithms for the IKE and IPsec protocols.
整个文档都是关于IKE和IPsec协议的常见哈希算法抗冲突性降低的安全含义。
The Security Considerations section of [HashAttacks] gives much more detail about the security of hash functions.
[HashAttacks]的安全注意事项部分提供了有关哈希函数安全性的更多详细信息。
[AES-MAC] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.
[AES-MAC]Frankel，S.和H.Herbert，“AES-XCBC-MAC-96算法及其在IPsec中的使用”，RFC 3566，2003年9月。
[AES-PRF] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 4434, February 2006.
[AES-PRF]Hoffman，P.，“互联网密钥交换协议（IKE）的AES-XCBC-PRF-128算法”，RFC 4434，2006年2月。
[AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[AH]Kent，S.，“IP认证头”，RFC 4302，2005年12月。
[Deploying] Bellovin, S. and E. Rescorla, "Deploying a New Hash Algorithm", NDSS '06, February 2006.
[部署]Bellovin，S.和E.Rescorla，“部署新的哈希算法”，NDSS'06，2006年2月。
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[ESP]Kent，S.，“IP封装安全有效负载（ESP）”，RFC 4303，2005年12月。
[HashAttacks] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[HashAttacks]Hoffman，P.和B.Schneier，“对互联网协议中加密哈希的攻击”，RFC 42702005年11月。
[HMAC-reduction] Contini, S. and YL. Yin, "Forgery and Partial Key-Recovery Attacks on HMAC and NMAC Using Hash Collisions", Cryptology ePrint Report 2006/319, September 2006.
[HMAC还原]康蒂尼，S.和YL。Yin，“利用哈希冲突对HMAC和NMAC进行伪造和部分密钥恢复攻击”，密码学ePrint报告2006/319，2006年9月。
[IKEv1] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKEv1]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2]考夫曼，C.，编辑，“因特网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
[IKEv2Algs] Schiller, J., "Cryptographic Algorithms for use in the Internet Key Exchange Version 2", RFC 4307, December 2005.
[IKEv2Algs]Schiller，J.，“互联网密钥交换版本2中使用的加密算法”，RFC 4307，2005年12月。
[IPsecAlgs] Eastlake, D., "Cryptographic Algorithm Implementation Requirements For ESP And AH", RFC 4305, December 2005.
[IPsecAlgs]Eastlake，D.，“ESP和AH的加密算法实现要求”，RFC 4305，2005年12月。
[NAT-T] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
[NAT-T]Kivinen，T.，Swander，B.，Huttunen，A.，和V.Volpe，“IKE内NAT穿越的协商”，RFC 3947，2005年1月。
[PKI4IPsec] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", Work in Progress, April 2007.
[PKI4IPsec]Korver，B.，“IKEv1/ISAKMP、IKEv2和PKIX的互联网IP安全PKI配置文件”，正在进行的工作，2007年4月。
[SHA2-HMAC] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 With IPsec", RFC 4868, May 2007.
[SHA2-HMAC]Kelly，S.和S.Frankel，“在IPsec中使用HMAC-SHA-256、HMAC-SHA-384和HMAC-SHA-512”，RFC 4868，2007年5月。
[Target-collisions] Stevens, M., Lenstra, A., and B. de Weger, "Target Collisions for MD5 and Colliding X.509 Certificates for Different Identities", Cryptology ePrint Report 2006/360, October 2006.
[目标碰撞]Stevens，M.，Lenstra，A.，和B.de Weger，“MD5的目标碰撞和不同身份的X.509证书碰撞”，密码学EPRIT报告2006/360，2006年10月。
Tero Kivinen helped with ideas in the first version of this document. Many participants on the SAAG and IPsec mailing lists contributed ideas in later versions. In particular, suggestions were made by Alfred Hoenes, Michael Richardson, Hugo Krawczyk, Steve Bellovin, David McGrew, Russ Housley, Arjen Lenstra, and Pasi Eronen.
Tero Kivinen在本文件的第一版中提供了一些想法。SAAG和IPsec邮件列表上的许多参与者在以后的版本中提出了自己的想法。特别是，阿尔弗雷德·霍恩斯、迈克尔·理查森、雨果·克劳茨克、史蒂夫·贝洛文、大卫·麦克格鲁、罗斯·霍斯利、阿扬·伦斯特拉和帕西·埃隆提出了建议。
Author's Address
作者地址
Paul Hoffman VPN Consortium 127 Segre Place Santa Cruz, CA 95060 US
美国加利福尼亚州圣克鲁斯塞格雷广场127号保罗·霍夫曼私人有限公司，邮编95060
EMail: paul.hoffman@vpnc.org
EMail: paul.hoffman@vpnc.org
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。