Network Working Group P. Hoffman
Request for Comments: 4308 VPN Consortium
Category: Standards Track December 2005
Network Working Group P. Hoffman
Request for Comments: 4308 VPN Consortium
Category: Standards Track December 2005
Cryptographic Suites for IPsec
IPsec加密套件
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, Internet Key Exchange (IKE), and IKEv2 protocols rely on security algorithms to provide privacy and authentication between the initiator and responder. There are many such algorithms available, and two IPsec systems cannot interoperate unless they are using the same algorithms. This document specifies optional suites of algorithms and attributes that can be used to simplify the administration of IPsec when used in manual keying mode, with IKEv1 or with IKEv2.
IPsec、Internet密钥交换（IKE）和IKEv2协议依靠安全算法在发起方和响应方之间提供隐私和身份验证。有许多这样的算法可用，两个IPsec系统不能互操作，除非它们使用相同的算法。本文档指定了可选的算法套件和属性，当使用IKEv1或IKEv2在手动键控模式下使用时，这些算法套件和属性可用于简化IPsec的管理。
This document is a companion to IPsec [RFC2401] and its two key exchange protocols, IKE [RFC2409] and IKEv2 [IKEv2]. Like most security protocols, IPsec, IKE, and IKEv2 allow users to chose which cryptographic algorithms they want to use to meet their security needs.
本文档是IPsec[RFC2401]及其两个密钥交换协议IKE[RFC2409]和IKEv2[IKEv2]的配套文件。与大多数安全协议一样，IPsec、IKE和IKEv2允许用户选择要使用哪些加密算法来满足其安全需求。
Implementation experience with IPsec in manual key mode and with IKE has shown that there are so many choices for typical system administrators to make that it is difficult to achieve interoperability without careful pre-agreement. Because of this, the IPsec Working Group agreed that there should be a small number of named suites that cover typical security policies. These suites may be presented in the administrative interface of the IPsec system. These suites, often called "UI suites" ("user interface suites"), are optional and do not prevent implementers from allowing individual selection of the security algorithms.
在手动密钥模式下使用IPsec和IKE的实施经验表明，对于典型的系统管理员来说，有太多的选择，如果没有仔细的预先协商，很难实现互操作性。因此，IPsec工作组一致认为，应该有少量涵盖典型安全策略的命名套件。这些套件可以显示在IPsec系统的管理界面中。这些套件通常称为“UI套件”（“用户界面套件”），是可选的，不会阻止实现者允许单独选择安全算法。
Although the UI suites listed here are optional to implement, this document is on the standards track because implementers who call particular suites by the names used here have to conform to the suites listed in this document. These suites should not be considered extensions to IPsec, IKE, and IKEv2, but instead administrative methods for describing sets of configurations.
尽管此处列出的UI套件是可选的，但本文档仍处于标准轨道上，因为按此处使用的名称调用特定套件的实现者必须符合本文档中列出的套件。这些套件不应被视为IPsec、IKE和IKEv2的扩展，而是用于描述配置集的管理方法。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“应该”、“不应该”和“可能”应按照[RFC2119]中所述进行解释。
This section lists optional, non-mandatory suites that may be presented to system administrators to ease the burden of choosing among the many options in IPsec systems. These suites cannot cover all of the options that an administrator needs to select. Instead, they give values for a subset of the options.
本节列出了可选的、非强制性的套件，这些套件可提供给系统管理员，以减轻在IPsec系统中选择众多选项的负担。这些套件不能涵盖管理员需要选择的所有选项。相反，它们为选项的子集提供值。
Note that these UI suites are simply collections of values for some options in IPsec. Use of UI suites does not change the IPsec, IKE, or IKEv2 protocols in any way. Specifically, the transform substructure in IKE and IKEv2 must be used to give the value for each specified option regardless of whether or not UI suites are used.
请注意，这些UI套件只是IPsec中某些选项的值的集合。使用UI套件不会以任何方式更改IPsec、IKE或IKEv2协议。具体而言，无论是否使用UI套件，IKE和IKEv2中的变换子结构都必须用于为每个指定选项提供值。
Implementations that use UI suites SHOULD also provide a management interface for specifying values for individual cryptographic options. That is, it is unlikely that UI suites are a complete solution for matching the security policies of many IPsec users, and therefore an interface that gives a more complete set of options should be used as well.
使用UI套件的实现还应提供一个管理界面，用于指定各个加密选项的值。也就是说，UI套件不太可能是匹配许多IPsec用户的安全策略的完整解决方案，因此也应该使用提供更完整选项集的界面。
IPsec implementations that use these UI suites SHOULD use the suite names listed here. IPsec implementations SHOULD NOT use names different than those listed here for the suites that are described, and MUST NOT use the names listed here for suites that do not match these values. These requirements are necessary for interoperability.
使用这些UI套件的IPsec实现应使用此处列出的套件名称。IPsec实现不应使用与此处列出的用于所述套件的名称不同的名称，也不得使用此处列出的用于与这些值不匹配的套件的名称。这些要求对于互操作性是必要的。
Note that the suites listed here are for use of IPsec in virtual private networks. Other uses of IPsec will probably want to define their own suites and give them different names.
请注意，此处列出的套件用于在虚拟专用网络中使用IPsec。IPsec的其他用途可能需要定义自己的套件并给它们不同的名称。
Additional suites can be defined by RFCs. The strings used to identify UI suites are registered by IANA.
其他套件可由RFC定义。用于标识UI套件的字符串由IANA注册。
This suite matches the commonly used corporate VPN security used in IKEv1 at the time of this document's publication.
此套件与本文档发布时IKEv1中使用的常用企业VPN安全性相匹配。
IPsec:
Protocol Encapsulating Security Payload (ESP) [RFC2406]
ESP encryption TripleDES in CBC mode [RFC2451]
ESP integrity HMAC-SHA1-96 [RFC2404]
IPsec:
Protocol Encapsulating Security Payload (ESP) [RFC2406]
ESP encryption TripleDES in CBC mode [RFC2451]
ESP integrity HMAC-SHA1-96 [RFC2404]
IKE and IKEv2:
Encryption TripleDES in CBC mode [RFC2451]
Pseudo-random function HMAC-SHA1 [RFC2104]
Integrity HMAC-SHA1-96 [RFC2404]
Diffie-Hellman group 1024-bit Modular Exponential (MODP) [RFC2409]
IKE and IKEv2:
Encryption TripleDES in CBC mode [RFC2451]
Pseudo-random function HMAC-SHA1 [RFC2104]
Integrity HMAC-SHA1-96 [RFC2404]
Diffie-Hellman group 1024-bit Modular Exponential (MODP) [RFC2409]
Rekeying of Phase 2 (for IKE) or the CREATE_CHILD_SA (for IKEv2) MUST be supported by both parties in this suite. The initiator of this exchange MAY include a new Diffie-Hellman key; if it is included, it MUST be of type 1024-bit MODP. If the initiator of the exchange includes a Diffie-Hellman key, the responder MUST include a Diffie-Hellman key, and it MUST of type 1024-bit MODP.
第2阶段（针对IKE）或创建子阶段（针对IKEv2）的密钥更新必须得到本套件中双方的支持。此交换的发起方可能包括一个新的Diffie-Hellman密钥；如果包含，则必须为1024位MODP类型。如果交换的发起方包含Diffie-Hellman密钥，则响应方必须包含Diffie-Hellman密钥，并且必须为1024位MODP类型。
This suite is what many people expect the commonly used corporate VPN security that will be used within a few years of the time this document's publication.
许多人都希望在本文档发布后的几年内使用通用的企业VPN安全性。
IPsec:
Protocol ESP [RFC2406]
ESP encryption AES with 128-bit keys in CBC mode [AES-CBC]
ESP integrity AES-XCBC-MAC-96 [AES-XCBC-MAC]
IPsec:
Protocol ESP [RFC2406]
ESP encryption AES with 128-bit keys in CBC mode [AES-CBC]
ESP integrity AES-XCBC-MAC-96 [AES-XCBC-MAC]
IKE and IKEv2:
Encryption AES with 128-bit keys in CBC mode [AES-CBC]
Pseudo-random function AES-XCBC-PRF-128 [AES-XCBC-PRF-128]
Integrity AES-XCBC-MAC-96 [AES-XCBC-MAC]
Diffie-Hellman group 2048-bit MODP [RFC3526]
IKE and IKEv2:
Encryption AES with 128-bit keys in CBC mode [AES-CBC]
Pseudo-random function AES-XCBC-PRF-128 [AES-XCBC-PRF-128]
Integrity AES-XCBC-MAC-96 [AES-XCBC-MAC]
Diffie-Hellman group 2048-bit MODP [RFC3526]
Rekeying of Phase 2 (for IKE) or the CREATE_CHILD_SA (for IKEv2) MUST be supported by both parties in this suite. The initiator of this exchange MAY include a new Diffie-Hellman key; if it is included, it MUST be of type 2048-bit MODP. If the initiator of the exchange includes a Diffie-Hellman key, the responder MUST include a Diffie-Hellman key, and it MUST of type 2048-bit MODP.
第2阶段（针对IKE）或创建子阶段（针对IKEv2）的密钥更新必须得到本套件中双方的支持。此交换的发起方可能包括一个新的Diffie-Hellman密钥；如果包含，则必须为2048位MODP类型。如果交换的发起方包含Diffie-Hellman密钥，则响应方必须包含Diffie-Hellman密钥，并且必须为2048位MODP类型。
IKEv1 has two security parameters that do not appear in IKEv2, namely, the lifetime of the Phase 1 and Phase 2 security associations (SAs). Systems that use IKEv1 with either the VPN-A or VPN-B suites MUST use an SA lifetime of 86400 seconds (1 day) for Phase 1 and an SA lifetime of 28800 seconds (8 hours) for Phase 2.
IKEv1有两个未出现在IKEv2中的安全参数，即阶段1和阶段2安全关联（SA）的生存期。将IKEv1与VPN-A或VPN-B套件一起使用的系统在第一阶段必须使用86400秒（1天）的SA生存期，在第二阶段必须使用28800秒（8小时）的SA生存期。
Much of the text and ideas in this document came from earlier versions of the IKEv2 document edited by Charlie Kaufman. Other text and ideas were contributed by other members of the IPsec Working Group.
本文档中的大部分文本和思想来自于Charlie Kaufman编辑的IKEv2文档的早期版本。IPsec工作组的其他成员提供了其他文本和想法。
This document inherits all of the security considerations of the IPsec, IKE, and IKEv2 documents.
本文档继承了IPsec、IKE和IKEv2文档的所有安全注意事项。
Some of the security options specified in these suites may be found in the future to have properties significantly weaker than those that were believed at the time this document was produced.
这些套件中指定的某些安全选项在将来可能会发现其属性明显弱于本文档生成时所认为的属性。
IANA has created and will maintain a registry called, "Cryptographic Suites for IKEv1, IKEv2, and IPsec". The registry consists of a text string and an RFC number that lists the associated transforms. New entries can be added to the registry only after RFC publication and approval by an expert designated by the IESG.
IANA已经创建并将维护一个名为“IKEv1、IKEv2和IPsec加密套件”的注册表。注册表由一个文本字符串和一个列出关联转换的RFC编号组成。只有在RFC发布并经IESG指定的专家批准后，才能将新条目添加到注册表中。
The initial values for the new registry are:
新注册表的初始值为：
Identifier Defined in VPN-A RFC 4308 VPN-B RFC 4308
VPN-A RFC 4308 VPN-B RFC 4308中定义的标识符
[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-XCBC-MAC] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.
[AES-XCBC-MAC]Frankel，S.和H.Herbert，“AES-XCBC-MAC-96算法及其与IPsec的使用”，RFC 3566，2003年9月。
[AES-XCBC-PRF-128] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 3664, January 2004.
[AES-XCBC-PRF-128]Hoffman，P.，“互联网密钥交换协议（IKE）的AES-XCBC-PRF-128算法”，RFC 3664，2004年1月。
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2]考夫曼，C.，编辑，“因特网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
[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月。
[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月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，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月。
[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月。
[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月。
[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月。
[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月。
Author's Address
作者地址
Paul Hoffman VPN Consortium 127 Segre Place Santa Cruz, CA 95060 USA
美国加利福尼亚州圣克鲁斯塞格雷广场127号保罗·霍夫曼VPN联盟，邮编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编辑功能的资金目前由互联网协会提供。