Network Working Group J. Schiller
Request for Comments: 4307 Massachusetts Institute of Technology
Category: Standards Track December 2005
Network Working Group J. Schiller
Request for Comments: 4307 Massachusetts Institute of Technology
Category: Standards Track December 2005
Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)
Internet密钥交换版本2（IKEv2）中使用的加密算法
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 Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE (RFC 2409) and IKEv2) provide a mechanism to negotiate which algorithms should be used in any given association. However, 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 algorithms that are mandatory to implement as part of IKEv2, as well as algorithms that should be implemented because they may be promoted to mandatory at some future time.
IPsec系列协议利用各种加密算法来提供安全服务。因特网密钥交换（IKE（RFC 2409）和IKEv2）提供了一种机制来协商在任何给定关联中应该使用哪些算法。然而，为了确保不同实现之间的互操作性，有必要指定一组强制实现算法，以确保所有实现至少有一个可用的算法。本文档定义了作为IKEv2一部分必须实现的当前算法集，以及应该实现的算法，因为它们可能在将来某个时候被提升为必须实现的算法。
The Internet Key Exchange protocol provides for the negotiation of cryptographic algorithms between both endpoints of a cryptographic
Internet密钥交换协议提供加密协议的两个端点之间的加密算法协商
association. Different implementations of IPsec and IKE may provide different algorithms. However, the IETF desires that all implementations should have some way to interoperate. In particular, this requires that IKE define a set of mandatory-to-implement algorithms because IKE itself uses such algorithms as part of its own negotiations. This requires that some set of algorithms be specified as "mandatory-to-implement" for IKE.
协会IPsec和IKE的不同实现可能提供不同的算法。然而，IETF希望所有实现都有某种互操作方式。特别是，这要求IKE定义一组强制算法来实现算法，因为IKE本身使用这些算法作为其自身协商的一部分。这要求将某些算法集指定为IKE的“强制实现”。
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 was removed from the main IKEv2 specification and placed in this document. As the choice of algorithm changes, only this document should need to be updated.
最后，我们需要认识到，强制实现算法可能需要随着时间的推移而改变，以适应不断变化的世界。因此，从主要的IKEv2规范中删除了实现算法的强制选择，并将其放在本文档中。随着算法选择的变化，只需更新本文档。
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 those algorithms (that are known today) in this document. There is no guarantee that the algorithms we believe today 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实现中可用。为了促进这一点，我们将尝试在本文中确定这些算法（今天已知）。我们认为今天的算法在未来可能是强制性的，但我们不能保证这些算法事实上会成为强制性的。目前已知的所有算法都会受到加密攻击，将来可能会被破坏。
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear 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, an algorithm marked as SHOULD- may be deprecated to a MAY in a future version of this document.
应-该术语的含义与应相同。但是，在本文档的未来版本中，标记为“应该”的算法可能会被弃用为“可能”。
MUST- This term means the same as MUST. However, we expect at some point that this algorithm will no longer be a MUST in a future document. Although its status will be determined at a later time, it is reasonable to expect that if a future revision of a document alters the status of a MUST-algorithm, it will remain at least a SHOULD or a SHOULD-.
必须-该术语的含义与必须相同。然而，我们希望在将来的文档中不再需要这种算法。尽管其状态将在稍后确定，但可以合理地预期，如果未来的文档修订更改了MUST算法的状态，它将至少保持为SHOULD或SHOULD-。
The IKEv2 Encrypted Payload requires both a confidentiality algorithm and an integrity algorithm. For confidentiality, implementations MUST- implement 3DES-CBC and SHOULD+ implement AES-128-CBC. For integrity, HMAC-SHA1 MUST be implemented.
IKEv2加密的有效负载需要保密算法和完整性算法。为了保密，实施必须-实施3DES-CBC，并应+实施AES-128-CBC。为了完整性，必须实施HMAC-SHA1。
There are several Modular Exponential (MODP) groups that are defined for use in IKEv2. They are defined in both the [IKEv2] base document and in the MODP extensions document. They are identified by group number. Any groups not listed here are considered as "MAY be implemented".
IKEv2中定义了几个模块指数（MODP）组。它们在[IKEv2]基础文档和MODP扩展文档中都有定义。它们由组号标识。此处未列出的任何组被视为“可能实施”。
Group Number Bit Length Status Defined 2 1024 MODP Group MUST- [RFC2409] 14 2048 MODP Group SHOULD+ [RFC3526]
组号位长度状态定义2 1024 MODP组必须-[RFC2409]14 2048 MODP组应+[RFC3526]
IKEv2 defines several possible algorithms for Transfer Type 1 (encryption). These are defined below with their implementation status.
IKEv2为传输类型1（加密）定义了几种可能的算法。这些定义及其实施状态如下。
Name Number Defined In Status RESERVED 0 ENCR_3DES 3 [RFC2451] MUST-ENCR_NULL 11 [RFC2410] MAY ENCR_AES_CBC 12 [AES-CBC] SHOULD+ ENCR_AES_CTR 13 [AES-CTR] SHOULD
状态保留0 ENCR_3DES 3[RFC2451]必须-ENCR_NULL 11[RFC2410]中定义的名称编号可能会ENCR_AES_CBC 12[AES-CBC]应该+ENCR_AES_CTR 13[AES-CTR]应该
Transfer Type 2 Algorithms are pseudo-random functions used to generate random values when needed.
传输类型2算法是伪随机函数，用于在需要时生成随机值。
Name Number Defined In Status RESERVED 0 PRF_HMAC_MD5 1 [RFC2104] MAY PRF_HMAC_SHA1 2 [RFC2104] MUST PRF_AES128_CBC 4 [AESPRF] SHOULD+
状态保留0 PRF_HMAC_MD5 1[RFC2104]中定义的名称编号可能PRF_HMAC_SHA1 2[RFC2104]必须PRF_AES128_CBC 4[AESPRF]应+
Transfer Type 3 Algorithms are Integrity algorithms used to protect data against tampering.
传输类型3算法是用于保护数据免受篡改的完整性算法。
Name Number Defined In Status NONE 0 AUTH_HMAC_MD5_96 1 [RFC2403] MAY AUTH_HMAC_SHA1_96 2 [RFC2404] MUST AUTH_AES_XCBC_96 5 [AES-MAC] SHOULD+
状态NONE 0中定义的名称编号身份验证\u HMAC\u MD5\u 96 1[RFC2403]可以身份验证\u HMAC\u SHA1\u 96 2[RFC2404]必须身份验证\u AES\u XCBC\u 96 5[AES-MAC]应该+
The security of cryptographic-based systems depends on both the strength of the cryptographic algorithms chosen and the strength of the keys used with those algorithms. The security also depends on the engineering of the protocol used by the system to ensure that there are no non-cryptographic ways to bypass the security of the overall system.
基于密码的系统的安全性取决于所选密码算法的强度以及与这些算法一起使用的密钥的强度。安全性还取决于系统使用的协议工程，以确保没有非加密方式绕过整个系统的安全性。
This document concerns itself with the selection of cryptographic algorithms for the use of IKEv2, specifically with the selection of "mandatory-to-implement" algorithms. The algorithms identified in this document as "MUST implement" or "SHOULD implement" are not known to be broken at the current time, and cryptographic research so far leads us to believe that they will likely remain secure into the foreseeable future. However, this isn't necessarily forever. 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.
本文件涉及选择使用IKEv2的加密算法，特别是选择“强制实施”算法。本文件中确定为“必须实现”或“应该实现”的算法目前尚不存在漏洞，迄今为止的密码研究使我们相信，在可预见的未来，它们可能仍然是安全的。然而，这并不一定是永远的。因此，我们期望本文件的新修订将不时发布，以反映这一领域的当前最佳做法。
[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月。
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2]考夫曼，C.，编辑，“因特网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
[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月。
[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月。
[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月。
[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月。
[AES-CBC] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[AES-CBC]Frankel，S.，Glenn，R.，和S.Kelly，“AES-CBC密码算法及其在IPsec中的使用”，RFC 3602，2003年9月。
[AES-CTR] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.
[AES-CTR]Housley，R.，“使用高级加密标准（AES）计数器模式和IPsec封装安全有效载荷（ESP）”，RFC 3686，2004年1月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[AESPRF] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 3664, January 2004.
[AESPRF]Hoffman，P.，“互联网密钥交换协议（IKE）的AES-XCBC-PRF-128算法”，RFC 3664，2004年1月。
[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月。
[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月。
Author's Address
作者地址
Jeffrey I. Schiller Massachusetts Institute of Technology Room W92-190 77 Massachusetts Avenue Cambridge, MA 02139-4307 USA
Jeffrey I.Schiller麻省理工学院W92-190室美国马萨诸塞州剑桥市马萨诸塞大道77号02139-4307
Phone: +1 (617) 253-0161
EMail: jis@mit.edu
Phone: +1 (617) 253-0161
EMail: jis@mit.edu
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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编辑功能的资金目前由互联网协会提供。