Network Working Group V. Manral
Request for Comments: 4835 IP Infusion Inc.
Obsoletes: 4305 April 2007
Category: Standards Track
Network Working Group V. Manral
Request for Comments: 4835 IP Infusion Inc.
Obsoletes: 4305 April 2007
Category: Standards Track
Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)
封装安全有效负载（ESP）和身份验证头（AH）的密码算法实现要求
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Encapsulating Security Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPsec Security Association (SA). To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to-implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time.
IPsec系列协议利用各种加密算法来提供安全服务。封装安全负载（ESP）和身份验证头（AH）提供了两种机制来保护通过IPsec安全关联（SA）发送的数据。为了确保不同实现之间的互操作性，有必要指定一组强制实现算法，以确保所有实现至少有一个可用的算法。本文件定义了ESP和AH算法的当前强制实施集合，并指定了应实施的算法，因为它们可能在未来某个时间升级为强制实施。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3
3. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Encapsulating Security Payload . . . . . . . . . . . . . . 4
3.1.1. ESP Encryption and Authentication Algorithms . . . . . 4
3.1.2. ESP Combined Mode Algorithms . . . . . . . . . . . . . 5
3.2. Authentication Header . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
6. Changes from RFC 2402 and RFC 2406 to RFC 4305 . . . . . . . . 7
7. Changes from RFC 4305 . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3
3. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Encapsulating Security Payload . . . . . . . . . . . . . . 4
3.1.1. ESP Encryption and Authentication Algorithms . . . . . 4
3.1.2. ESP Combined Mode Algorithms . . . . . . . . . . . . . 5
3.2. Authentication Header . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
6. Changes from RFC 2402 and RFC 2406 to RFC 4305 . . . . . . . . 7
7. Changes from RFC 4305 . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
The Encapsulating Security Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPsec Security Association (SA) [RFC4301], [RFC4302]. To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to-implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time.
封装安全有效负载（ESP）和身份验证头（AH）提供了两种机制，用于保护通过IPsec安全关联（SA）[RFC4301]、[RFC4302]发送的数据。为了确保不同实现之间的互操作性，有必要指定一组强制实现算法，以确保所有实现至少有一个可用的算法。本文件定义了ESP和AH算法的当前强制实施集合，并指定了应实施的算法，因为它们可能在未来某个时间升级为强制实施。
The nature of cryptography is that new algorithms surface continuously and existing algorithms are continuously attacked. An algorithm believed to be strong today may be demonstrated to be weak tomorrow. Given this, the choice of mandatory-to-implement algorithm should be conservative so as to minimize the likelihood of it being compromised quickly. Thought should also be given to performance considerations as many uses of IPsec will be in environments where performance is a concern.
密码学的本质是新算法不断出现，现有算法不断受到攻击。今天被认为很强大的算法明天可能会被证明很弱。考虑到这一点，实现算法的强制选择应该是保守的，以便最大限度地降低其快速受损的可能性。还应考虑性能方面的考虑，因为IPsec的许多用途都是在关注性能的环境中使用的。
Finally, we need to recognize that the mandatory-to-implement algorithm(s) may need to change over time to adapt to the changing world. For this reason, the selection of mandatory-to-implement algorithms is not included in the main IPsec, ESP, or AH specifications. It is instead placed in this document. As the choice of algorithm changes, only this document should need to be updated.
最后，我们需要认识到，强制实现算法可能需要随着时间的推移而改变，以适应不断变化的世界。因此，主IPsec、ESP或AH规范中不包括为实现算法而选择的强制选项。而是放在本文档中。随着算法选择的变化，只需更新本文档。
Ideally, the mandatory-to-implement algorithm of tomorrow should already be available in most implementations of IPsec by the time it is made mandatory. To facilitate this, we will attempt to identify such algorithms (as they are known today) in this document. There is no guarantee that the algorithms that we (today) believe may be mandatory in the future will in fact become so. All algorithms known today are subject to cryptographic attack and may be broken in the future.
理想情况下，明天的强制实现算法在强制执行时应该已经在大多数IPsec实现中可用。为了促进这一点，我们将在本文档中尝试识别此类算法（如今天所知）。我们（今天）认为在未来可能是强制性的算法，但不能保证它们实际上会成为强制性的。目前已知的所有算法都会受到加密攻击，将来可能会被破坏。
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]中所述进行解释。
We define some additional terms here:
我们在此定义了一些附加术语：
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, it is likely that an algorithm marked as SHOULD- will be deprecated to a MAY or worse in a future version of this document.
应-该术语的含义与应相同。但是，在本文档的未来版本中，标记为“应该”的算法很可能会被弃用为“可能”或“更糟”。
MUST- This term means the same as MUST. However, we expect that at some point in the future this algorithm will no longer be a MUST.
必须-该术语的含义与必须相同。然而，我们预计在将来的某个时候，这种算法将不再是必须的。
For IPsec implementations to interoperate, they must support one or more security algorithms in common. This section specifies the security algorithm implementation requirements for standards-conformant ESP and AH implementations. The security algorithms actually used for any particular ESP or AH security association are determined by a negotiation mechanism, such as the Internet Key Exchange (IKE [RFC2409], [RFC4306]) or pre-establishment.
为了使IPsec实现能够互操作，它们必须共同支持一个或多个安全算法。本节规定了符合标准的ESP和AH实施的安全算法实施要求。实际用于任何特定ESP或AH安全关联的安全算法由协商机制确定，如互联网密钥交换（IKE[RFC2409]、[RFC4306]）或预建立。
Of course, additional standard and proprietary algorithms beyond those listed below can be implemented.
当然，除了下面列出的以外，还可以实现其他标准和专有算法。
The implementation conformance requirements for security algorithms for ESP are given in the tables below. See Section 2 for definitions of the values in the "Requirement" column.
下表给出了ESP安全算法的实现一致性要求。有关“要求”列中的值定义，请参见第2节。
These tables list encryption and authentication algorithms for the IPsec Encapsulating Security Payload protocol.
这些表列出了IPsec封装安全有效负载协议的加密和身份验证算法。
Requirement Encryption Algorithm (notes)
----------- --------------------------
MUST NULL [RFC2410] (1)
MUST AES-CBC with 128-bit keys [RFC3602]
MUST- TripleDES-CBC [RFC2451]
SHOULD AES-CTR [RFC3686]
SHOULD NOT DES-CBC [RFC2405] (2)
Requirement Encryption Algorithm (notes)
----------- --------------------------
MUST NULL [RFC2410] (1)
MUST AES-CBC with 128-bit keys [RFC3602]
MUST- TripleDES-CBC [RFC2451]
SHOULD AES-CTR [RFC3686]
SHOULD NOT DES-CBC [RFC2405] (2)
Requirement Authentication Algorithm (notes)
----------- -----------------------------
MUST HMAC-SHA1-96 [RFC2404] (3)
SHOULD+ AES-XCBC-MAC-96 [RFC3566]
MAY NULL (1)
MAY HMAC-MD5-96 [RFC2403] (4)
Requirement Authentication Algorithm (notes)
----------- -----------------------------
MUST HMAC-SHA1-96 [RFC2404] (3)
SHOULD+ AES-XCBC-MAC-96 [RFC3566]
MAY NULL (1)
MAY HMAC-MD5-96 [RFC2403] (4)
Notes:
笔记：
(1) Since ESP encryption is optional, support for the "NULL" algorithm is required to maintain consistency with the way services are negotiated. Note that while authentication and encryption can each be "NULL", they MUST NOT both be "NULL" [RFC4301].
(1) 由于ESP加密是可选的，因此需要支持“NULL”算法以保持与服务协商方式的一致性。请注意，虽然身份验证和加密都可以为“NULL”，但它们不能同时为“NULL”[RFC4301]。
(2) DES, with its small key size and publicly demonstrated and open-design special-purpose cracking hardware, is of questionable security for general use.
(2) DES具有较小的密钥大小和公开展示的开放式设计专用破解硬件，对于一般用途而言，其安全性值得怀疑。
(3) Weaknesses have become apparent in SHA-1 [SHA1-COLL]; however, these should not affect the use of SHA1 with HMAC.
(3) SHA-1[SHA1-COLL]的弱点已变得明显；但是，这些不应影响SHA1与HMAC的配合使用。
(4) Weaknesses have become apparent in MD5 [MD5-COLL]; however, these should not affect the use of MD5 with HMAC.
(4) MD5[MD5-COLL]中的弱点已变得明显；但是，这些不应影响MD5与HMAC的配合使用。
As specified in [RFC4303], combined mode algorithms are supported that provide both confidentiality and authentication services. Support of such algorithms will require proper structuring of ESP implementations. Under many circumstances, combined mode algorithms provide significant efficiency and throughput advantages. Although there are no suggested or required combined algorithms at this time, AES-CCM [RFC4309] and AES-GCM [RFC4106] are of interest. AES-CCM has been adopted as the preferred mode in IEEE 802.11 [802.11i], and AES-GCM has been adopted as the preferred mode in IEEE 802.1ae [802.1ae].
如[RFC4303]所述，支持同时提供保密和身份验证服务的组合模式算法。支持这些算法需要ESP实现的适当结构。在许多情况下，组合模式算法提供了显著的效率和吞吐量优势。虽然目前没有建议或要求的组合算法，但AES-CCM[RFC4309]和AES-GCM[RFC4106]值得关注。AES-CCM已被IEEE 802.11[802.11i]采用为首选模式，AES-GCM已被IEEE 802.1ae[802.1ae]采用为首选模式。
The implementation conformance requirements for security algorithms for AH are given below. See Section 2 for definitions of the values in the "Requirement" column. As you would suspect, all of these algorithms are authentication algorithms.
下面给出了AH安全算法的实现一致性要求。有关“要求”列中的值定义，请参见第2节。正如您所怀疑的，所有这些算法都是身份验证算法。
Requirement Algorithm (notes)
----------- ----------------
MUST HMAC-SHA1-96 [RFC2404] (1)
SHOULD+ AES-XCBC-MAC-96 [RFC3566]
MAY HMAC-MD5-96 [RFC2403] (2)
Requirement Algorithm (notes)
----------- ----------------
MUST HMAC-SHA1-96 [RFC2404] (1)
SHOULD+ AES-XCBC-MAC-96 [RFC3566]
MAY HMAC-MD5-96 [RFC2403] (2)
Note:
注:
(1) Weaknesses have become apparent in SHA-1 [SHA1-COLL]; however, these should not affect the use of SHA1 with HMAC.
(1) SHA-1[SHA1-COLL]的弱点已变得明显；但是，这些不应影响SHA1与HMAC的配合使用。
(2) Weaknesses have become apparent in MD5 [MD5-COLL]; however, these should not affect the use of MD5 with HMAC.
(2) MD5[MD5-COLL]中的弱点已变得明显；但是，这些不应影响MD5与HMAC的配合使用。
The security of cryptography-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 and administration of the protocol used by the system to ensure that there are no non-cryptographic ways to bypass the security of the overall system.
基于密码学的系统的安全性取决于所选择的加密算法的强度以及与这些算法一起使用的密钥的强度。安全性还取决于系统使用的协议的工程和管理，以确保没有非加密方式绕过整个系统的安全性。
This document concerns itself with the selection of cryptographic algorithms for the use of ESP and AH, specifically with the selection of mandatory-to-implement algorithms. The algorithms identified in this document as "MUST implement" or "SHOULD implement" are not known to be broken at the current time, and cryptographic research so far leads us to believe that they will likely remain secure into the foreseeable future. However, this is not necessarily forever. We would therefore expect that new revisions of this document will be issued from time to time that reflect the current best practice in this area.
本文件涉及ESP和AH使用的加密算法的选择，特别是强制算法的选择。本文件中确定为“必须实现”或“应该实现”的算法目前尚不存在漏洞，迄今为止的密码研究使我们相信，在可预见的未来，它们可能仍然是安全的。然而，这不一定是永远的。因此，我们期望本文件的新修订将不时发布，以反映这一领域的当前最佳做法。
Much of the wording herein was adapted from RFC 4305, the parent document of this document. RFC 4305 itself borrows text from [RFC4307], "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2", by Jeffrey I. Schiller.
本文件中的大部分措辞均改编自RFC 4305，即本文件的母文件。RFC 4305本身借用了Jeffrey I.Schiller的[RFC4307]“用于Internet密钥交换版本2的加密算法”中的文本。
Thanks to the following people for reporting or responding to reports of the errors in RFC 4305: Paul Hoffman, Stephen Kent, Paul Koning, and Lars Volker. Helpful Last-Call comments were received from Russ Housley, Elwyn Davies, Nicolas Williams, and Alfred Hoenes.
感谢以下人员报告或回复RFC 4305中的错误报告：Paul Hoffman、Stephen Kent、Paul Koning和Lars Volker。来自Russ Housley、Elwyn Davies、Nicolas Williams和Alfred Hoenes的有用的最后通话评论。
[RFC2402] and [RFC2406] defined the IPsec Authentication Header and IPsec Encapsulating Security Payload. Each specified the implementation requirements for cryptographic algorithms for their respective protocols. They have now been replaced with [RFC4302] and [RFC4303], which do not specify cryptographic algorithm implementation requirements, and this document, which specifies such requirements for both [RFC4302] and [RFC4303].
[RFC2402]和[RFC2406]定义了IPsec身份验证头和IPsec封装安全负载。每个协议都规定了各自协议的加密算法的实现要求。它们现在已被[RFC4302]和[RFC4303]所取代，这两个版本未规定密码算法的实现要求，而本文件规定了[RFC4302]和[RFC4303]的此类要求。
The implementation requirements are compared below:
实施要求比较如下：
Old Old New
Req. RFC(s) Requirement Algorithm (notes)
---- ------ ----------- -----------------
MUST 2406 SHOULD NOT DES-CBC [RFC2405] (1)
MUST 2402 2406 MAY HMAC-MD5-96 [RFC2403]
MUST 2402 2406 MUST HMAC-SHA1-96 [RFC2404]
Old Old New
Req. RFC(s) Requirement Algorithm (notes)
---- ------ ----------- -----------------
MUST 2406 SHOULD NOT DES-CBC [RFC2405] (1)
MUST 2402 2406 MAY HMAC-MD5-96 [RFC2403]
MUST 2402 2406 MUST HMAC-SHA1-96 [RFC2404]
Note:
注:
(1) The IETF deprecated the use of single DES years ago and has not included it in any new standard for some time (see IESG note on the first page of [RFC2407]). [RFC4305] represented the first standards-track recognition of that deprecation by specifying that implementations SHOULD NOT provide single DES. The US Government National Institute of Standards and Technology (NIST) has formally recognized the weakness of single DES by a notice published [DES-WDRAW] proposing to withdraw it as a US Government Standard. Triple DES remains approved by both the IETF and NIST.
(1) IETF在几年前就不赞成使用单一DES，并且有一段时间没有将其纳入任何新标准（参见[RFC2407]第一页的IESG注释）。[RFC4305]通过指定实现不应提供单一DES，代表了第一个标准跟踪对该弃用的识别。美国政府国家标准与技术研究所（NIST）发布公告，正式承认单一DES的弱点，建议将其作为美国政府标准撤销。三重DES仍然得到IETF和NIST的批准。
This document obsoletes [RFC4305]. The document incorporates changes for the support for the NULL Authentication Algorithm making the support from a MUST to a MAY. This change is made to make this document consistent with [RFC4301]. Text for SHA-1 collision attacks as well as the future use of AES-GCM and AES-CCM is added.
本文件废除了[RFC4305]。该文档包含了对空身份验证算法支持的更改，使支持从必须变为可能。此更改旨在使本文件与[RFC4301]保持一致。添加了SHA-1碰撞攻击以及AES-GCM和AES-CCM未来使用的文本。
The changed implementation requirement resulting from the above changes is listed below:
由上述变更引起的变更实施要求如下所示：
Old Old New
Req. RFC(s) Requirement Algorithm (notes)
---- ------ ----------- -----------------
MUST 2406 MAY NULL Authentication
MUST 2406 MUST NULL Encryption
SHOULD+ 4305 MUST AES-CBC Encryption
Old Old New
Req. RFC(s) Requirement Algorithm (notes)
---- ------ ----------- -----------------
MUST 2406 MAY NULL Authentication
MUST 2406 MUST NULL Encryption
SHOULD+ 4305 MUST AES-CBC Encryption
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP14, RFC2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP14，RFC2119，1997年3月。
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.
[RFC2403]Madson，C.和R.Glenn，“HMAC-MD5-96在ESP和AH中的使用”，RFC 2403，1998年11月。
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[RFC2404]Madson，C.和R.Glenn，“在ESP和AH中使用HMAC-SHA-1-96”，RFC 2404，1998年11月。
[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.
[RFC2405]Madson，C.和N.Doraswamy，“带显式IV的ESP DES-CBC密码算法”，RFC 2405，1998年11月。
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[RFC2410]Glenn，R.和S.Kent，“空加密算法及其在IPsec中的使用”，RFC 2410，1998年11月。
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[RFC2451]Pereira，R.和R.Adams，“ESP CBC模式密码算法”，RFC 2451，1998年11月。
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.
[RFC3566]Frankel，S.和H.Herbert，“AES-XCBC-MAC-96算法及其在IPsec中的使用”，RFC 3566，2003年9月。
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[RFC3602]Frankel，S.，Glenn，R.，和S.Kelly，“AES-CBC密码算法及其在IPsec中的使用”，RFC 3602，2003年9月。
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.
[RFC3686]Housley，R.，“使用高级加密标准（AES）计数器模式和IPsec封装安全有效负载（ESP）”，RFC 3686，2004年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
[RFC4302]Kent，S.，“IP认证头”，RFC 4302，
December 2005.
2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4305] Eastlake, D., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005.
[RFC4305]Eastlake，D.，“封装安全有效载荷（ESP）和认证头（AH）的密码算法实现要求”，RFC 4305，2005年12月。
[802.11i] "LAN/MAN Specific Requirements Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications", IEEE Standard Medium Access Control (MAC) Security, IEEE Std 802.11i, June 2004.
[802.11i]“局域网/城域网特定要求第11部分：无线媒体访问控制（MAC）和物理层（PHY）规范”，IEEE标准媒体访问控制（MAC）安全，IEEE标准802.11i，2004年6月。
[802.1ae] "Media Access Control (MAC) Security", IEEE Standard Medium Access Control (MAC) Security, IEEE Std 802.1ae, June 2006.
[802.1ae]“媒体访问控制（MAC）安全”，IEEE标准媒体访问控制（MAC）安全，IEEE标准802.1ae，2006年6月。
[DES-WDRAW] "Announcing Proposed Withdrawal of Federal Information Processing Standard (FIPS) for the Data Encryption Standard (DES) and Request for Comments", FIPS Notice Docket No. 040602169-4169-01, July 2004.
[DES-WDRAW]“宣布撤销数据加密标准（DES）的联邦信息处理标准（FIPS）的建议并征求意见”，FIPS公告卷宗号040602169-4169-01，2004年7月。
[MD5-COLL] Klima, V., "Finding MD5 Collisions - a Toy For a Notebook", Cryptology ePrint Archive Medium Report 2005/ 075, March 2005.
[MD5-COLL]Klima，V.，“发现MD5碰撞——笔记本电脑的玩具”，密码学ePrint存档媒体报告2005/075，2005年3月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005.
[RFC4106]Viega，J.和D.McGrew，“在IPsec封装安全有效负载（ESP）中使用Galois/计数器模式（GCM）”，RFC 4106，2005年6月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC43062005年12月。
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.
[RFC4307]Schiller，J.“互联网密钥交换版本2（IKEv2）中使用的加密算法”，RFC 4307，2005年12月。
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, December 2005.
[RFC4309]Housley，R.，“使用高级加密标准（AES）CCM模式和IPsec封装安全有效载荷（ESP）”，RFC 4309，2005年12月。
[SHA1-COLL] Rijmen, V. and E. Oswald, "Update on SHA-1", Cryptology ePrint Archive Report 2005/010, January 2005.
[SHA1-COLL]Rijmen，V.和E.Oswald，“SHA-1的更新”，密码学ePrint档案报告2005/010，2005年1月。
Author's Address
作者地址
Vishwas Manral IP Infusion Inc. Bamankhola, Bansgali, Almora, Uttarakhand 263601 India
印度北部阿莫拉市班斯加利市巴曼霍拉Vishwas Manral IP输液公司，邮编263601
Phone: +91-98456-61911
EMail: vishwas@ipinfusion.com
Phone: +91-98456-61911
EMail: vishwas@ipinfusion.com
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 provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。