Internet Engineering Task Force (IETF) K. Burgin
Request for Comments: 6380 National Security Agency
Category: Informational M. Peck
ISSN: 2070-1721 The MITRE Corporation
October 2011
Internet Engineering Task Force (IETF) K. Burgin
Request for Comments: 6380 National Security Agency
Category: Informational M. Peck
ISSN: 2070-1721 The MITRE Corporation
October 2011
Suite B Profile for Internet Protocol Security (IPsec)
用于Internet协议安全（IPsec）的套件B配置文件
Abstract
摘要
The United States Government has published guidelines for "NSA Suite B Cryptography" dated July, 2005, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using Suite B cryptography in IP Security (IPsec).
美国政府于2005年7月发布了“NSA套件B加密”指南，该指南定义了国家安全应用的加密算法政策。本文档指定了在IP安全（IPsec）中使用Suite B加密的约定。
Since many of the Suite B algorithms are used in other environments, the majority of the conventions needed for the Suite B algorithms are already specified in other documents. This document references the source of these conventions, with some relevant detail repeated to aid developers who choose to support Suite B.
由于许多套件B算法用于其他环境，套件B算法所需的大多数约定已在其他文档中指定。本文档引用了这些约定的来源，并重复了一些相关细节，以帮助选择支持SuiteB的开发人员。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6380.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6380.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................3
3. Suite B Requirements ............................................3
4. Minimum Levels of Security (minLOS) .............................4
4.1. Non-Signature Primitives ...................................4
4.2. Suite B IPsec Cryptographic Suites .........................4
4.3. Suite B IKEv2 Authentication ...............................5
4.4. Digital Signatures and Certificates ........................6
5. Suite B Security Associations (SAs) for IKEv2 and IPsec .........6
6. The Key Exchange Payload in the IKE_SA_INIT Exchange ............7
7. Generating Keying Material for the IKE SA .......................7
8. Additional Requirements .........................................7
9. Security Considerations .........................................8
10. References .....................................................9
10.1. Normative References ......................................9
10.2. Informative References ...................................10
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................3
3. Suite B Requirements ............................................3
4. Minimum Levels of Security (minLOS) .............................4
4.1. Non-Signature Primitives ...................................4
4.2. Suite B IPsec Cryptographic Suites .........................4
4.3. Suite B IKEv2 Authentication ...............................5
4.4. Digital Signatures and Certificates ........................6
5. Suite B Security Associations (SAs) for IKEv2 and IPsec .........6
6. The Key Exchange Payload in the IKE_SA_INIT Exchange ............7
7. Generating Keying Material for the IKE SA .......................7
8. Additional Requirements .........................................7
9. Security Considerations .........................................8
10. References .....................................................9
10.1. Normative References ......................................9
10.2. Informative References ...................................10
This document specifies the conventions for using NSA Suite B Cryptography [SuiteB] in IP Security (IPsec).
本文档规定了在IP安全（IPsec）中使用NSA Suite B加密[SuiteB]的约定。
IP Security (IPsec) provides confidentiality, data integrity, access control, and data source authentication to IP datagrams. The Internet Key Exchange (IKE) provides an automated key management for IPsec, performing mutual authentication between two parties and establishing security associations (SAs) that protects both IKE and IPsec communications. Suite B compliant implementations for IPsec MUST use IKEv2 [RFC5996].
IP安全（IPsec）为IP数据报提供机密性、数据完整性、访问控制和数据源身份验证。Internet密钥交换（IKE）为IPsec提供自动密钥管理，在双方之间执行相互身份验证，并建立保护IKE和IPsec通信的安全关联（SA）。与套件B兼容的IPsec实现必须使用IKEv2[RFC5996]。
[RFC6379] defines a set of four cryptographic user interface suites for IPsec that are comprised of Suite B algorithms. The four suites specify options for IKEv2 and for the IP Encapsulating Security Payload (ESP), [RFC4303]. Suite B compliant implementations for IPsec MUST use one of these four suites depending upon the desired security level and security services.
[RFC6379]为IPsec定义了一组四个加密用户界面套件，这些套件由套件B算法组成。这四个套件为IKEv2和IP封装安全有效负载（ESP）指定了选项[RFC4303]。与套件B兼容的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]中所述进行解释。
Suite B requires that key establishment and signature algorithms be based upon Elliptic Curve Cryptography and that the encryption algorithm be AES [FIPS197]. Suite B includes [SuiteB]:
套件B要求密钥建立和签名算法基于椭圆曲线加密，加密算法为AES[FIPS197]。套房B包括[套房B]：
Encryption: Advanced Encryption Standard (AES) (key sizes of 128 and 256 bits)
加密：高级加密标准（AES）（密钥大小为128和256位）
Digital Signature Elliptic Curve Digital Signature Algorithm (ECDSA) [FIPS186-3] (using the curves with 256- and 384-bit prime moduli)
数字签名椭圆曲线数字签名算法（ECDSA）[FIPS186-3]（使用256位和384位素数模的曲线）
Key Exchange Elliptic Curve Diffie-Hellman (ECDH) [SP800-56A], (using the curves with 256- and 384-bit prime moduli)
密钥交换椭圆曲线Diffie-Hellman（ECDH）[SP800-56A]，（使用带256位和384位素数模的曲线）
Hashes SHA-256 and SHA-384 [FIPS180-3]
哈希SHA-256和SHA-384[FIPS180-3]
The two elliptic curves used in Suite B appear in the literature under two different names. For the sake of clarity, we list both names below:
套件B中使用的两条椭圆曲线在文献中以两个不同的名称出现。为了清楚起见，我们在下面列出了这两个名称：
Curve NIST name SECG name IANA assigned DH group #
-----------------------------------------------------------------
P-256 nistp256 secp256r1 19
P-384 nistp384 secp384r1 20
Curve NIST name SECG name IANA assigned DH group #
-----------------------------------------------------------------
P-256 nistp256 secp256r1 19
P-384 nistp384 secp384r1 20
IANA has already registered these DH groups in [IKEV2IANA].
IANA已经在[IKEV2IANA]中注册了这些DH组。
Suite B provides for two levels of cryptographic security, namely a 128-bit minimum level of security (minLOS_128) and a 192-bit minimum level of security (minLOS_192). Each level defines a minimum strength that all cryptographic algorithms must provide.
套件B提供两种加密安全级别，即128位最低安全级别（minLOS_128）和192位最低安全级别（minLOS_192）。每个级别定义了所有加密算法必须提供的最小强度。
We divide the Suite B non-signature primitives into two columns as shown in Table 1.
我们将Suite B非签名原语分为两列，如表1所示。
Column 1 Column 2
+-------------------+------------------+
Encryption | AES-128 | AES-256 |
+-------------------+------------------+
Key Agreement | ECDH on P-256 | ECDH on P-384 |
+-------------------+------------------+
Hash for PRF/MAC | SHA256 | SHA384 |
+-------------------+------------------+
Column 1 Column 2
+-------------------+------------------+
Encryption | AES-128 | AES-256 |
+-------------------+------------------+
Key Agreement | ECDH on P-256 | ECDH on P-384 |
+-------------------+------------------+
Hash for PRF/MAC | SHA256 | SHA384 |
+-------------------+------------------+
Table 1: Suite B Cryptographic Non-Signature Primitives
表1:Suite B加密非签名原语
At the 128-bit minimum level of security:
在128位最低安全级别：
- the non-signature primitives MUST either come exclusively from Column 1 or exclusively from Column 2.
- 非签名原语必须完全来自第1列或第2列。
At the 192-bit minimum level of security:
在192位最低安全级别：
- the non-signature primitives MUST come exclusively from Column 2.
- 非签名原语必须完全来自第2列。
Each system MUST specify a security level of a minimum of 128 bits or 192 bits. The security level determines which suites from [RFC6379] are allowed.
每个系统必须指定至少128位或192位的安全级别。安全级别决定允许使用[RFC6379]中的哪些套件。
The four Suite B cryptographic user interface suites ("UI suites") [RFC6379]: Suite-B-GCM-128, Suite-B-GMAC-128, Suite-B-GCM-256 or Suite-B-GMAC-256, satisfy the requirements of Section 3.
四个套件B加密用户界面套件（“UI套件”）[RFC6379]：套件B-GCM-128、套件B-GMAC-128、套件B-GCM-256或套件B-GMAC-256满足第3节的要求。
At the 128-bit minimum level of security:
在128位最低安全级别：
- one of Suite-B-GCM-128, Suite-B-GMAC-128, Suite-B-GCM-256 or Suite-B-GMAC-256 MUST be used by Suite B IPsec compliant implementations [RFC6379].
- 符合套件B IPsec的实施必须使用套件B-GCM-128、套件B-GMAC-128、套件B-GCM-256或套件B-GMAC-256中的一种[RFC6379]。
At the 192-bit minimum level of security:
在192位最低安全级别：
- one of Suite-B-GCM-256 or Suite-B-GMAC-256 MUST be used by Suite B IPsec compliant implementations [RFC6379].
- 套件B IPsec兼容实施必须使用套件B-GCM-256或套件B-GMAC-256中的一个[RFC6379]。
Digital signatures using ECDSA MUST be used for authentication by Suite B compliant implementations. [RFC4754] defines two digital signature algorithms: ECDSA-256 and ECDSA-384. Following the direction of RFC 4754, ECDSA-256 represents an instantiation of the ECDSA algorithm using the P-256 curve and the SHA-256 hash function. ECDSA-384 represents an instantiation of the ECDSA algorithm using the P-384 curve and the SHA-384 hash function.
使用ECDSA的数字签名必须用于符合Suite B的实现的身份验证。[RFC4754]定义了两种数字签名算法：ECDSA-256和ECDSA-384。按照RFC 4754的指示，ECDSA-256表示使用P-256曲线和SHA-256哈希函数的ECDSA算法的实例。ECDSA-384表示使用P-384曲线和SHA-384哈希函数的ECDSA算法的实例。
If configured at a minimum level of security of 128 bits, a system MUST use either ECDSA-256 or ECDSA-384 for IKE authentication. It is allowable for one party to authenticate with ECDSA-256 and the other party to authenticate with ECDSA-384. This flexibility will allow interoperability between an initiator and a responder that have different sizes of ECDSA authentication keys.
如果以128位的最低安全级别配置，则系统必须使用ECDSA-256或ECDSA-384进行IKE身份验证。允许一方使用ECDSA-256进行身份验证，另一方使用ECDSA-384进行身份验证。这种灵活性将允许具有不同大小ECDSA身份验证密钥的启动器和响应程序之间的互操作性。
Initiators and responders in a system configured at a minimum level of security of 128 bits MUST be able to verify ECDSA-256 signatures and SHOULD be able to verify ECDSA-384 signatures.
以128位最低安全级别配置的系统中的启动器和响应程序必须能够验证ECDSA-256签名，并且应该能够验证ECDSA-384签名。
If configured at a minimum level of security of 192 bits, ECDSA-384 MUST be used by both parties for IKEv2 authentication.
如果配置为192位的最低安全级别，双方必须使用ECDSA-384进行IKEv2身份验证。
Initiators and responders in a system configured at a minimum level of security of 192 bits MUST be able to verify ECDSA-384 signatures.
在配置为192位最低安全级别的系统中，启动器和响应程序必须能够验证ECDSA-384签名。
For Suite B compliant systems, authentication methods other than ECDSA-256 and ECDSA-384 MUST NOT be used for IKEv2 authentication. If a relying party receives a message signed with any other authentication method, it MUST return an AUTHENTICATION_FAILED notification and stop processing the message.
对于与套件B兼容的系统，IKEv2身份验证不得使用ECDSA-256和ECDSA-384以外的身份验证方法。如果依赖方收到使用任何其他身份验证方法签名的消息，则它必须返回身份验证失败通知并停止处理该消息。
The initiator and responder, at both minimum levels of security, MUST each use an X.509 certificate that complies with the "Suite B Certificate and Certificate Revocation List (CRL) Profile" [RFC5759] and that contains an elliptic curve public key with the key usage bit set for digital signature.
在两个最低安全级别上，启动器和响应程序必须各自使用符合“套件B证书和证书吊销列表（CRL）配置文件”[RFC5759]的X.509证书，该证书包含椭圆曲线公钥，密钥使用位设置为数字签名。
The four suites in [RFC6379] specify options for ESP [RFC4303] and IKEv2 [RFC5996]. The four suites are differentiated by cryptographic algorithm strength and a choice of whether ESP is to provide both confidentiality and integrity or integrity only. The suite names are based upon the AES mode ("GCM" or "GMAC") and the AES key length specified for ESP ("128" or "256"). Suites with "GCM" in their name MUST be used when ESP integrity protection and encryption are both needed. Suites with "GMAC" in their name MUST be used only when there is no need for ESP encryption.
[RFC6379]中的四个套件指定了ESP[RFC4303]和IKEv2[RFC5996]的选项。这四个套件的区别在于加密算法的强度以及ESP是提供机密性和完整性还是仅提供完整性的选择。套件名称基于AES模式（“GCM”或“GMAC”）和为ESP指定的AES密钥长度（“128”或“256”）。当同时需要ESP完整性保护和加密时，必须使用名称中带有“GCM”的套件。只有在不需要ESP加密时，才能使用名称中带有“GMAC”的套件。
An initiator in a system configured at a minimum level of security of 128 bits MUST offer one or more of the four suites: Suite-B-GCM-128, Suite-B-GMAC-128, Suite-B-GCM-256, or Suite-B-GMAC-256 [RFC6379]. Suite-B-GCM-128 and Suite-B-GMAC-128, if offered, MUST appear in the IKEv2 and IPsec SA payloads before any offerings of Suite-B-GCM-256 and Suite-B-GMAC-256.
以128位最低安全级别配置的系统中的启动器必须提供四个套件中的一个或多个套件：套件B-GCM-128、套件B-GMAC-128、套件B-GCM-256或套件B-GMAC-256[RFC6379]。Suite-B-GCM-128和Suite-B-GMAC-128（如果提供）必须出现在任何Suite-B-GCM-256和Suite-B-GMAC-256产品之前的IKEv2和IPsec SA有效载荷中。
A responder in a system configured at a minimum level of security of 128 bits MUST support one or both of the two suites Suite-B-GCM-128 or Suite-B-GMAC-128 and SHOULD support one or both of the two suites Suite-B-GCM-256 or Suite-B-GMAC-256. The responder MUST accept one of the Suite B UI suites. If none of the four suites are offered, the responder MUST return a Notify payload with the error "NO_PROPOSAL_CHOSEN" when operating in Suite B compliant mode.
以128位的最低安全级别配置的系统中的响应程序必须支持两个套件Suite-B-GCM-128或Suite-B-GMAC-128中的一个或两个套件，并且应支持两个套件套件Suite-B-GCM-256或Suite-B-GMAC-256中的一个或两个套件。响应者必须接受其中一个套件B UI套件。如果四个套件均未提供，则在套件B兼容模式下运行时，响应者必须返回带有错误“NO_PROPOSAL_Selected”的Notify有效负载。
An initiator in a system configured at a minimum level of security of 192 bits MUST offer either one or both suites: Suite-B-GCM-256 or Suite-B-GMAC-256.
以192位最低安全级别配置的系统中的启动器必须提供一个或两个套件：套件B-GCM-256或套件B-GMAC-256。
A responder configured in a system at a minimum level of security of 192 bits MUST choose one of Suite-B-GCM-256 or Suite-B-GMAC-256. If neither suite is offered, the responder MUST return a Notify payload with the error "NO_PROPOSAL_CHOSEN".
在最低安全级别为192位的系统中配置的响应程序必须选择Suite-B-GCM-256或Suite-B-GMAC-256中的一个。如果两个套件都没有提供，响应者必须返回一个Notify有效负载，并返回错误“NO_PROPOSAL_selected”。
A Suite B IPsec compliant initiator and responder MUST each generate an ephemeral elliptic curve key pair to be used in the elliptic curve Diffie-Hellman (ECDH) key exchange. If the 256-bit random ECP group for Transform Type 4 is selected, each side MUST generate an EC key pair using the P-256 elliptic curve [SP800-57]. If the 384-bit random ECP group for Transform Type 4 is selected, each side MUST generate an EC key pair using the P-384 elliptic curve [SP800-57]. The ephemeral public keys MUST be stored in the key exchange payload as in [RFC5903].
与Suite B IPsec兼容的启动器和响应程序必须各自生成一个临时椭圆曲线密钥对，用于椭圆曲线Diffie-Hellman（ECDH）密钥交换。如果选择转换类型4的256位随机ECP组，则每侧必须使用P-256椭圆曲线生成EC密钥对[SP800-57]。如果选择转换类型4的384位随机ECP组，则每侧必须使用P-384椭圆曲线生成EC密钥对[SP800-57]。临时公钥必须存储在密钥交换有效负载中，如[RFC5903]所示。
The ECDH shared secret established during the key exchange consists of the x value of the ECDH common value [RFC5903]. The x value is 256 or 384 bits when using the P-256 or P-384 curve, respectively.
密钥交换期间建立的ECDH共享密钥由ECDH公共值[RFC5903]的x值组成。使用P-256或P-384曲线时，x值分别为256或384位。
IKEv2 [RFC5996] allows for the reuse of Diffie-Hellman ephemeral keys. Section 5.6.4.3 of NIST SP800-56A states that an ephemeral private key MUST be used in exactly one key establishment transaction and MUST be zeroized after its use. Section 5.8 of SP800-56A states that the Diffie-Hellman shared secret MUST be zeroized immediately after its use. Suite B compliant IPsec systems MUST follow the mandates in SP800-56A.
IKEv2[RFC5996]允许重用Diffie-Hellman临时密钥。NIST SP800-56A第5.6.4.3节规定，临时私钥必须在一次密钥建立交易中使用，并且在使用后必须归零。SP800-56A第5.8节规定，Diffie-Hellman共享机密在使用后必须立即归零。与套件B兼容的IPsec系统必须遵守SP800-56A中的规定。
If using PRF-HMAC-SHA-256, SKEYSEED, SK_d, SK_pi, and SK_pr MUST each be generated to be 256 bits long per RFC 5996 ([RFC5996], Section 2.14). If using PRF-HMAC-SHA-384, SKEYSEED, SK_d, SK_pi and SK_pr MUST each be generated to be 384 bits long. SK_ai and SK_ar MUST be 256 or 384 bits long if using HMAC-SHA-256-128 or HMAC-SHA-384-192, respectively. SK_ei and SK_er MUST be 128 or 256 bits long if the key length attribute for AES_ENC_CBC is set to 128 or 256, respectively.
如果使用PRF-HMAC-SHA-256，则根据RFC 5996（[RFC5996]，第2.14节），SKYSEED、SK_d、SK_pi和SK_pr必须分别生成256位长。如果使用PRF-HMAC-SHA-384，则必须生成长度为384位的SKYSEED、SKU d、SKU pi和SKU pr。如果分别使用HMAC-SHA-256-128或HMAC-SHA-384-192，则SK_ai和SK_ar的长度必须为256或384位。如果AES_ENC_CBC的密钥长度属性分别设置为128或256，则SK_ei和SK_er的长度必须为128或256位。
AH is not supported in Suite B compliant implementations.
与套件B兼容的实现中不支持AH。
Per [RFC5996], although ESP does not directly include a Diffie-Hellman exchange, a Diffie-Hellman group MAY be negotiated for the Child SA. This allows the peers to employ Diffie-Hellman in the CREATE_CHILD_SA exchange. If a transform Type 4 is specified for an SA for ESP, the value of the transform MUST match that of the transform used by the IKE SA.
根据[RFC5996]，尽管ESP不直接包括Diffie-Hellman交换，但可以为子SA协商Diffie-Hellman组。这允许对等方在CREATE_CHILD_SA交换中使用Diffie Hellman。如果为ESP的SA指定了转换类型4，则转换的值必须与IKE SA使用的转换的值匹配。
Per RFC 5996, if a CREATE_CHILD_SA exchange includes a KEi payload, at least one of the SA offers MUST include the Diffie-Hellman group of the KEi. For Suite B IPsec compliant implementations, the Diffie-Hellman group of the KEi MUST use the same random ECP group used in the IKE_INIT_SA.
根据RFC 5996，如果CREATE_CHILD_SA交换包含KEi有效负载，则至少一个SA提供必须包含KEi的Diffie Hellman组。对于符合Suite B IPsec的实现，KEi的Diffie Hellman组必须使用与IKE_INIT_SA中使用的相同的随机ECP组。
For IKEv2, rekeying of the CREATE_CHILD_SA MUST be supported by both parties. The initiator of this exchange MAY include a new Diffie-Hellman key; if it is included, it MUST use the same random ECP group used in the IKE_INIT_SA. If the initiator of the exchange includes a Diffie-Hellman key, the responder MUST include a Diffie-Hellman key, and it MUST use the same random ECP group.
对于IKEv2，双方必须支持对CREATE_CHILD_SA进行密钥更新。此交换的发起方可能包括一个新的Diffie-Hellman密钥；如果包含，则必须使用IKE_INIT_SA中使用的相同随机ECP组。如果交换的发起方包含Diffie-Hellman密钥，则响应方必须包含Diffie-Hellman密钥，并且必须使用相同的随机ECP组。
Suite B IPsec compliant systems MUST support IKEv2 and MUST NOT use IKEv1 between a Suite B compliant initiator and responder. To accommodate backward compatibility, a Suite B IPsec compliant system can be configured to use IKEv1 so long as only IKEv2 is used between a Suite B compliant initiator and responder. However, when IKEv1 is being used, the system is not being operated in a Suite B compliant mode.
与套件B IPsec兼容的系统必须支持IKEv2，并且不得在与套件B兼容的启动器和响应程序之间使用IKEv1。为了适应向后兼容性，可以将符合Suite B IPsec的系统配置为使用IKEv1，只要在符合Suite B的启动器和响应程序之间仅使用IKEv2。但是，当使用IKEv1时，系统未在符合套件B的模式下运行。
IKEv2 does not specify how Identification Payloads (IDi and IDr) in the IKE_AUTH exchanges are used for policy lookup. For Suite B compliant systems, the IKEv2 authentication method MUST NOT use the Identification Payloads for policy lookup. Instead, the authentication method MUST use an end-entity found in the end-entity certificate provided by the authenticating party.
IKEv2未指定如何使用IKE_身份验证交换中的标识有效负载（IDi和IDr）进行策略查找。对于与套件B兼容的系统，IKEv2身份验证方法不得将标识有效负载用于策略查找。相反，身份验证方法必须使用在身份验证方提供的最终实体证书中找到的最终实体。
The administrative user interface (UI) for a system that conforms to this profile MUST allow the operator to specify a single suite. If only one suite is specified in the administrative UI, the IKEv2 implementation MUST only offer algorithms for that one suite.
符合此配置文件的系统的管理用户界面（UI）必须允许操作员指定单个套件。如果在管理UI中只指定了一个套件，则IKEv2实现必须只为该套件提供算法。
The administrative UI MAY allow the operator to specify more than one suite; if it allows this, it MUST allow the operator to specify a preferred order for the suites that are to be offered or accepted. The preferred order MUST follow the direction provided in Section 4. If more than one suite is specified in the administrative UI, the IKEv2 implementation MUST only offer algorithms for those suites.
管理UI允许操作员指定多个套件；如果允许，则必须允许操作员指定要提供或接受的套件的首选订单。首选订单必须遵循第4节中提供的指示。如果在管理UI中指定了多个套件，则IKEv2实现必须仅为这些套件提供算法。
This document discusses security requirements throughout, and it inherits the security considerations of [RFC4303], [RFC4754], [RFC5759], and [RFC5996].
本文档始终讨论安全需求，并继承了[RFC4303]、[RFC4754]、[RFC5759]和[RFC5996]的安全注意事项。
[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月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 4754, January 2007.
[RFC4754]Fu，D.和J.Solinas，“使用椭圆曲线数字签名算法（ECDSA）的IKE和IKEv2认证”，RFC 4754，2007年1月。
[RFC5759] Solinas, J. and L. Zieglar, "Suite B Certificate and Certificate Revocation List (CRL) Profile", RFC 5759, January 2010.
[RFC5759]Solinas，J.和L.Zieglar，“套件B证书和证书撤销列表（CRL）配置文件”，RFC 5759，2010年1月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[RFC6379] Law, L. and J. Solinas, "Suite B Cryptographic Suites for IPsec", RFC 6379, October 2011.
[RFC6379]Law，L.和J.Solinas，“用于IPsec的套件B加密套件”，RFC 6379，2011年10月。
[FIPS180-3] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-3, October 2008.
[FIPS180-3]国家标准与技术研究所，“安全哈希标准”，FIPS PUB 180-3，2008年10月。
[FIPS186-3] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 186-3, June 2009.
[FIPS186-3]国家标准与技术研究所，“数字签名标准（DSS）”，FIPS PUB 186-3，2009年6月。
[FIPS197] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001.
[FIPS197]国家标准与技术研究所，“高级加密标准（AES）”，FIPS PUB 197，2001年11月。
[SP800-56A] National Institute of Standards and Technology, "Recommendation for Pair-wise Key Establishment Schemes Using Discrete Logarithm Cryptography", NIST Special Publication 800-56A, March 2007.
[SP800-56A]美国国家标准与技术研究所，“使用离散对数加密的成对密钥建立方案的建议”，NIST特别出版物800-56A，2007年3月。
[SP800-57] National Institute of Standards and Technology, "Recommendation for Key Management - Part 1", NIST Special Publication 800-57, March 2007.
[SP800-57]国家标准与技术研究所，“关键管理建议-第1部分”，NIST特别出版物800-57，2007年3月。
[IKEV2IANA] "Internet Key Exchange Version 2 (IKEv2) Parameters", <http://www.iana.org>.
[IKEV2IANA]“互联网密钥交换版本2（IKEv2）参数”<http://www.iana.org>.
[SuiteB] U.S. National Security Agency, "NSA Suite B Cryptography", January 2009, <http://www.nsa.gov/ia/programs/suiteb_cryptography/>.
[SuiteB]美国国家安全局，“NSA套件B加密”，2009年1月<http://www.nsa.gov/ia/programs/suiteb_cryptography/>.
[RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2", RFC 5903, June 2010.
[RFC5903]Fu，D.和J.Solinas，“IKE和IKEv2的模素数的椭圆曲线群（ECP群）”，RFC 5903，2010年6月。
Authors' Addresses
作者地址
Kelley W. Burgin National Security Agency
凯利·W·伯金国家安全局
EMail: kwburgi@tycho.ncsc.mil
EMail: kwburgi@tycho.ncsc.mil
Michael A. Peck The MITRE Corporation
迈克尔·A·佩克米特尔公司
EMail: mpeck@mitre.org
EMail: mpeck@mitre.org