Network Working Group P. Hoffman
Request for Comments: 4109 VPN Consortium
Updates: 2409 May 2005
Category: Standards Track
Network Working Group P. Hoffman
Request for Comments: 4109 VPN Consortium
Updates: 2409 May 2005
Category: Standards Track
Algorithms for Internet Key Exchange version 1 (IKEv1)
Internet密钥交换第1版（IKEv1）的算法
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 required and suggested algorithms in the original Internet Key Exchange version 1 (IKEv1) specification do not reflect the current reality of the IPsec market requirements. The original specification allows weak security and suggests algorithms that are thinly implemented. This document updates RFC 2409, the original specification, and is intended for all IKEv1 implementations deployed today.
原始Internet密钥交换版本1（IKEv1）规范中要求的和建议的算法没有反映IPsec市场需求的当前现实。最初的规范允许较弱的安全性，并建议使用实现较少的算法。本文档更新了原始规范RFC 2409，适用于今天部署的所有IKEv1实现。
The original IKEv1 definition, [RFC2409], has a set of MUST-level and SHOULD-level requirements that do not match the needs of IPsec users. This document updates RFC 2409 by changing the algorithm requirements defined there.
最初的IKEv1定义[RFC2409]有一组必须级别和应该级别的要求，与IPsec用户的需求不匹配。本文件通过更改RFC 2409中定义的算法要求来更新RFC 2409。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、建议、可和可选时，应按照[RFC2119]中的说明进行解释。
RFC 2409 has the following MUST-level and SHOULD-level requirements:
RFC 2409具有以下必须级别和应级别要求：
o DES for encryption MUST be supported. o MD5 and SHA-1 for hashing and HMAC functions MUST be supported. o Pre-shared secrets for authentication MUST be supported. o Diffie-Hellman MODP group 1 (discrete log 768 bits) MUST be supported. o TripleDES for encryption SHOULD be supported. o Tiger for hashing SHOULD be supported. o DSA and RSA for authentication with signatures SHOULD be supported. o RSA for authentication with encryption SHOULD be supported. o Diffie-Hellman MODP group 2 (discrete log 1024 bits) SHOULD be supported.
o 必须支持用于加密的DES。o必须支持用于哈希和HMAC函数的MD5和SHA-1。o必须支持用于身份验证的预共享机密。o必须支持Diffie-Hellman MODP组1（离散日志768位）。o应支持用于加密的三元组。o应支持用于哈希的Tiger。o应支持使用签名进行身份验证的DSA和RSA。o应支持使用加密进行身份验证的RSA。o应支持Diffie-Hellman MODP组2（离散日志1024位）。
RFC 2409 gives two conflicting requirement levels for Diffie-Hellman MODP groups with elliptic curves. Section 4 of that specification says that "IKE implementations ... MAY support ECP and EC2N groups", but Sections 6.3 and 6.4 say that MODP groups 3 and 4 for EC2N groups SHOULD be supported.
RFC 2409给出了具有椭圆曲线的Diffie-Hellman MODP群的两个相互冲突的要求级别。该规范的第4节说“IKE实现……可能支持ECP和EC2N组”，但第6.3节和第6.4节说应该支持EC2N组的MODP组3和4。
The new requirements for IKEv1 are listed here. Note that some of the requirements are the same as those in RFC 2409, whereas others are changed.
此处列出了IKEv1的新要求。请注意，一些要求与RFC 2409中的要求相同，而其他要求则有所更改。
o TripleDES for encryption MUST be supported. o AES-128 in CBC mode [RFC3602] for encryption SHOULD be supported. o SHA-1 for hashing and HMAC functions MUST be supported. o Pre-shared secrets for authentication MUST be supported. o AES-128 in XCBC mode for PRF functions ([RFC3566] and [RFC3664]) SHOULD be supported. o Diffie-Hellman MODP group 2 (discrete log 1024 bits) MUST be supported.
o 必须支持用于加密的三元组。o应支持CBC模式[RFC3602]下用于加密的AES-128。o必须支持哈希和HMAC函数的SHA-1。o必须支持用于身份验证的预共享机密。o应支持用于PRF功能（[RFC3566]和[RFC3664]）的XCBC模式下的AES-128。o必须支持Diffie-Hellman MODP组2（离散日志1024位）。
o Diffie-Hellman MODP group 14 (discrete log 2048 bits) [RFC3526] SHOULD be supported. o RSA for authentication with signatures SHOULD be supported.
o 应支持Diffie-Hellman MODP组14（离散日志2048位）[RFC3526]。o应支持使用签名进行身份验证的RSA。
If additional updates are made to IKEv1 in the future, then it is very likely that implementation of AES-128 in CBC mode for encryption will become mandatory.
如果将来对IKEv1进行额外更新，则很可能强制在CBC模式下实施AES-128进行加密。
The other algorithms that were listed at MUST-level and SHOULD-level in RFC 2409 are now MAY-level. This includes DES for encryption, MD5 and Tiger for hashing, Diffie-Hellman MODP group 1, Diffie-Hellman MODP groups with elliptic curves, DSA for authentication with signatures, and RSA for authentication with encryption.
RFC 2409中列出的“必须级别”和“应该级别”的其他算法现在是“可能级别”。这包括用于加密的DES、用于散列的MD5和Tiger、Diffie-Hellman MODP组1、具有椭圆曲线的Diffie-Hellman MODP组、用于签名身份验证的DSA以及用于加密身份验证的RSA。
DES for encryption, MD5 for hashing, and Diffie-Hellman MODP group 1 are dropped to MAY due to cryptographic weakness.
加密的DES、散列的MD5和Diffie-Hellman MODP组1由于加密弱点而被删除到五月。
Tiger for hashing, Diffie-Hellman MODP groups with elliptic curves, DSA for authentication with signatures, and RSA for authentication with encryption are dropped due to lack of any significant deployment and interoperability.
由于缺乏任何重要的部署和互操作性，用于哈希的Tiger、带有椭圆曲线的Diffie-Hellman MODP组、用于带有签名的身份验证的DSA以及用于带有加密的身份验证的RSA都被删除。
Algorithm RFC 2409 This document
------------------------------------------------------------------
DES for encryption MUST MAY (crypto weakness)
TripleDES for encryption SHOULD MUST
AES-128 for encryption N/A SHOULD
MD5 for hashing and HMAC MUST MAY (crypto weakness)
SHA1 for hashing and HMAC MUST MUST
Tiger for hashing SHOULD MAY (lack of deployment)
AES-XCBC-MAC-96 for PRF N/A SHOULD
Pre-shared secrets MUST MUST
RSA with signatures SHOULD SHOULD
DSA with signatures SHOULD MAY (lack of deployment)
RSA with encryption SHOULD MAY (lack of deployment)
D-H Group 1 (768) MUST MAY (crypto weakness)
D-H Group 2 (1024) SHOULD MUST
D-H Group 14 (2048) N/A SHOULD
D-H elliptic curves SHOULD MAY (lack of deployment)
Algorithm RFC 2409 This document
------------------------------------------------------------------
DES for encryption MUST MAY (crypto weakness)
TripleDES for encryption SHOULD MUST
AES-128 for encryption N/A SHOULD
MD5 for hashing and HMAC MUST MAY (crypto weakness)
SHA1 for hashing and HMAC MUST MUST
Tiger for hashing SHOULD MAY (lack of deployment)
AES-XCBC-MAC-96 for PRF N/A SHOULD
Pre-shared secrets MUST MUST
RSA with signatures SHOULD SHOULD
DSA with signatures SHOULD MAY (lack of deployment)
RSA with encryption SHOULD MAY (lack of deployment)
D-H Group 1 (768) MUST MAY (crypto weakness)
D-H Group 2 (1024) SHOULD MUST
D-H Group 14 (2048) N/A SHOULD
D-H elliptic curves SHOULD MAY (lack of deployment)
This document is all about security. All the algorithms that are either MUST-level or SHOULD-level in the "new algorithm requirements" section of this document are believed to be robust and secure at the time of this writing.
这份文件是关于安全的。在撰写本文时，本文件“新算法要求”一节中的所有算法都被认为是健壮和安全的。
[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月。
[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月。
[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月。
[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月。
[RFC3664] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 3664, January 2004.
[RFC3664]Hoffman，P.，“互联网密钥交换协议（IKE）的AES-XCBC-PRF-128算法”，RFC 3664，2004年1月。
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 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编辑功能的资金目前由互联网协会提供。