[要約] RFC 9206は、米国政府が公開したCommercial National Security Algorithm (CNSA) Suite Cryptography for Internet Protocol Security (IPsec) の規定で、国家安全保障アプリケーション向けの暗号アルゴリズムポリシーを定義しています。この文書は、米国国家安全保障局のCNSA SuiteアルゴリズムをIPsecで使用するための規則を指定しており、米国国家安全保障システムの機能、構成、および運用に適用されます。
Independent Submission L. Corcoran
Request for Comments: 9206 M. Jenkins
Category: Informational NSA
ISSN: 2070-1721 February 2022
Commercial National Security Algorithm (CNSA) Suite Cryptography for Internet Protocol Security (IPsec)
インターネットプロトコルセキュリティのためのコマーシャル国家セキュリティアルゴリズム（CNSA）スイート暗号化（IPsec）
Abstract
概要
The United States Government has published the National Security Agency's Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using the United States National Security Agency's CNSA Suite algorithms in Internet Protocol Security (IPsec). It applies to the capabilities, configuration, and operation of all components of US National Security Systems (described in NIST Special Publication 800-59) that employ IPsec. This document is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.
米国政府は、国家セキュリティ代理店の商業全体セキュリティアルゴリズム（CNSA）スイートを発表しており、これは国家セキュリティアプリケーションの暗号化アルゴリズム方針を定義しています。このドキュメントは、インターネットプロトコルセキュリティ（IPsec）で米国国家セキュリティエージェンシーのCNSAスイートアルゴリズムを使用するための規約を指定しています。IPsecを採用した米国国家セキュリティシステム（NIST特別発表800-59に記載されている）のすべてのコンポーネントの機能、構成、および運用に適用されます。この文書は、高価値の情報を処理する他のすべての米国政府システムにも適しています。これらおよび他のシステム展開の開発者および事業者による使用には公に利用可能にされています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。それは情報提供のために公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディタは、この文書をその判断で公開することを選択し、実装または展開の値についてのステートメントを作成しません。RFCエディタによる出版の承認済みの文書は、インターネット規格のレベルレベルの候補ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9206.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9206で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF信頼と文書の著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.
この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。
Table of Contents
目次
1. Introduction
2. Terminology
3. The Commercial National Security Algorithm Suite
4. CNSA-Compliant IPsec Overview
5. IPsec User Interface Suites
5.1. Suite CNSA-GCM-256-ECDH-384
5.2. Suite CNSA-GCM-256-DH-3072
5.3. Suite CNSA-GCM-256-DH-4096
6. IKEv2 Authentication
7. Certificates
8. IKEv2 Security Associations (SAs)
9. The Key Exchange Payload in the IKE_SA_INIT Exchange
10. Generating Key Material for the IKE SA
11. Additional Requirements
12. Guidance for Applications with Long Data-Protection
Requirements
13. Security Considerations
14. IANA Considerations
15. References
15.1. Normative References
15.2. Informative References
Authors' Addresses
This document specifies the conventions for using the United States National Security Agency's (NSA's) Commercial National Security Algorithm (CNSA) Suite algorithms [CNSA] in Internet Protocol Security (IPsec). It defines CNSA-based User Interface suites ("UI suites") describing sets of security configurations for Internet Key Exchange Protocol Version 2 (IKEv2) and IP Encapsulating Security Payload (ESP) protocol use, and specifies certain other constraints with respect to algorithm selection and configuration. It applies to the capabilities, configuration, and operation of all components of US National Security Systems (described in NIST Special Publication 800-59 [SP80059]) that employ IPsec. This document is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.
この文書は、インターネットプロトコルセキュリティ（IPsec）の米国国家セキュリティエージェンショナル（NSA）の商用国家セキュリティアルゴリズム（CNSA）スイートアルゴリズム[CNSA]を使用するための規約を指定します。Internet Key Exchange Protocol Version 2（IKEV2）およびIPカプセル化セキュリティペイロード（ESP）プロトコルの使用方法のセットを記述するCNSAベースのユーザーインターフェイススイート（「UIスイート」）を定義し、アルゴリズムの選択に関する特定の他の制約を指定します。そして構成IPsecを採用した米国国家セキュリティシステムのすべてのコンポーネントの機能、構成、および操作に適用されます。この文書は、高価値の情報を処理する他のすべての米国政府システムにも適しています。これらおよび他のシステム展開の開発者および事業者による使用には公に利用可能にされています。
The reader is assumed to have familiarity with the following:
読者は以下に精通していると想定されています：
* "IP Encapsulating Security Payload (ESP)" [RFC4303]
* 「IPカプセル化セキュリティペイロード（ESP）」[RFC4303]
* "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280]
* 「インターネットX.509公開鍵インフラストラクチャ証明書と証明書失効リスト（CRL）プロファイル」[RFC5280]
* "Internet Key Exchange Protocol Version 2 (IKEv2)" [RFC7296]
* 「インターネットキー交換プロトコルバージョン2（IKEv2）」[RFC7296]
* "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)" [RFC8221]
* 「暗号化アルゴリズムの実装要件と使用ガイダンスセキュリティペイロード（ESP）と認証ヘッダ（AH）」[RFC8221]
* "Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile" [RFC8603]
* 「商業全国セキュリティアルゴリズム（CNSA）スイート証明書および証明書失効リスト（CRL）プロファイル」[RFC8603]
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
AES refers to the Advanced Encryption Standard. ECDSA and ECDH refer to the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) and Elliptic Curve Diffie-Hellman (ECDH), respectively. DH refers to Diffie-Hellman key establishment. RSA refers to an RSA signature.
AESは高度な暗号化規格を指します。ECDSAおよびECDHは、それぞれ楕円曲線デジタル署名アルゴリズム（ECDSA）および楕円曲線Diffie-Hellman（ECDH）の使用を指す。DHはDiffie-Hellmanキー設立を指します。RSAはRSAシグネチャを指します。
The NSA profiles commercial cryptographic algorithms and protocols as part of its mission to support secure, interoperable communications for US Government National Security Systems. To this end, it publishes guidance to both (1) assist with the US Government transition to new algorithms and (2) provide vendors -- and the Internet community in general -- with information concerning their proper use and configuration.
NSAプロファイルは、米国政府の国家セキュリティシステムのための安全な相互運用可能なコミュニケーションを支援するためのその使命の一環として、市販の暗号化アルゴリズムとプロトコルをプロファイルします。この目的のために、（1）新しいアルゴリズムへの米国政府の移行を支援し、（2）将軍政府とインターネットコミュニティを提供する - 適切な使用と構成に関する情報を提供します。
Recently, cryptographic transition plans have become overshadowed by the prospect of the development of a cryptographically relevant quantum computer. The NSA has established the Commercial National Security Algorithm (CNSA) Suite to provide vendors and IT users near-term flexibility in meeting their information assurance interoperability requirements. The purpose behind this flexibility is to avoid vendors and customers making two major transitions in a relatively short timeframe, as we anticipate a need to shift to quantum-resistant cryptography in the near future.
最近、暗号的に関連する量子コンピュータの開発の見通しによって暗号化された遷移計画が隠されてきた。NSAは、製品保証相互運用性の要件を満たす際のベンダーとITユーザーを提供するための市販の国家セキュリティアルゴリズム（CNSA）スイートを設立しました。この柔軟性の背後にある目的は、近い将来に量子抵抗性暗号化に移行する必要があると予想しているため、ベンダーや顧客が比較的短い期間内に2つの大きな遷移を行うのを避けることです。
The NSA is authoring a set of RFCs, including this one, to provide updated guidance concerning the use of certain commonly available commercial algorithms in IETF protocols. These RFCs can be used in conjunction with other RFCs and cryptographic guidance (e.g., NIST Special Publications) to properly protect Internet traffic and data-at-rest for US Government National Security Systems.
NSAは、これを含むRFCのセットを作成しています。これらのRFCは、米国政府の国家セキュリティシステムにとってインターネットトラフィックとデータ同士のデータを適切に保護するために、他のRFCおよび暗号案内（例えば、NIST特別刊行物）と組み合わせて使用することができる。
CNSA-compliant implementations for IPsec MUST use IKEv2 [RFC7296].
IPSecのCNSA準拠の実装はIKEv2 [RFC7296]を使用する必要があります。
Implementing a CNSA-compliant IPsec system requires cryptographic algorithm selection for both the IKEv2 and ESP protocols. The following CNSA requirements apply to IPsec:
CNSA準拠のIPSecシステムの実装には、IKEV2とESPプロトコルの両方の暗号化アルゴリズムの選択が必要です。次のCNSAの要件はIPsecに適用されます。
Encryption:
暗号化：
AES [FIPS197] (with key size 256 bits)
AES [FIPS197]（キーサイズ256ビット付）
Digital Signature:
デジタル署名：
ECDSA [FIPS186] (using the NIST P-384 elliptic curve) RSA [FIPS186] (with a modulus of 3072 bits or larger)
ECDSA [FIPS186]（NIST P-384楕円曲線を使用）RSA [FIPS186]（弾性率3072ビット以上）
Key Establishment:
主要設立：
ECDH [SP80056A] (using the NIST P-384 elliptic curve) DH [RFC3526] (with a prime modulus of 3072 or larger)
ECDH [SP80056A]（NIST P-384楕円曲線を使用）DH [RFC3526]（素数率3072以上）
To facilitate selection of appropriate combinations of compliant algorithms, this document provides CNSA-compliant User Interface suites (UI suites) [RFC4308] to implement IPsec on National Security Systems.
準拠アルゴリズムの適切な組み合わせの選択を容易にするために、この資料は国家セキュリティシステムでIPSecを実装するためにCNSA準拠のユーザーインターフェーススイート（UIスイート）[RFC4308]を提供します。
The approved CNSA hash function for all purposes is SHA-384, as defined in [FIPS180]. However, PRF_HMAC_SHA_512 is specified for the IKEv2 Pseudorandom Function (PRF) instead of PRF_HMAC_SHA_384, due to availability. See Section 8 below.
[FIPS180]で定義されているように、すべての目的のための承認されたCNSAハッシュ関数はSHA-384です。ただし、可用性により、PRF_HMAC_SHA_384の代わりにPRF_HMAC_SHA_512がIKEV2疑似andom関数（PRF）に指定されています。以下のセクション8を参照してください。
For CNSA Suite applications, public key certificates MUST be compliant with the CNSA Suite Certificate and CRL Profile specified in [RFC8603].
CNSAスイートアプリケーションの場合、公開鍵証明書は[RFC8603]で指定されたCNSAスイート証明書およびCRLプロファイルに準拠している必要があります。
Under certain conditions, such as applications having long-lived data-protection requirements, systems that do not comply with the requirements of this document are acceptable; see Section 12.
長寿命のデータ保護要件を持つアプリケーションなどの特定の条件下では、この文書の要件に準拠していないシステムは受け入れられます。セクション12を参照してください。
User Interface (UI) suites [RFC4308] are named suites that cover some typical security policy options for IPsec. Use of UI suites does not change the IPsec protocol in any way. The following UI suites provide cryptographic algorithm choices for ESP [RFC4303] and for IKEv2 [RFC7296]. The selection of a UI suite will depend on the key exchange algorithm. The suite names indicate the Advanced Encryption Standard [FIPS197] mode, AES key length specified for encryption, and the key exchange algorithm.
ユーザーインターフェース（UI）スイート[RFC4308]は、IPsecの典型的なセキュリティポリシーオプションをカバーするSuitesという名前です。UIスイートの使用は、IPSecプロトコルを決して変更しません。次のUIスイートは、ESP [RFC4303]およびIKEV2 [RFC7296]の暗号化アルゴリズムの選択を提供します。UIスイートの選択は、鍵交換アルゴリズムによって異なります。スイート名は、Encryption Standard [FIPS197]モード、暗号化に指定されたAESキー長、および鍵交換アルゴリズムを示します。
Although RSA is also a CNSA-approved key establishment algorithm, only DH and ECDH are specified for key exchange in IKEv2 [RFC7296]. RSA in IPsec is used only for digital signatures. See Section 6.
RSAはCNSA承認の主要確立アルゴリズムでもありますが、IKEV2 [RFC7296]の鍵交換にDHとECDHのみが指定されています。IPSecのRSAはデジタル署名にのみ使用されます。セクション6を参照してください。
ESP requires negotiation of both a confidentiality algorithm and an integrity algorithm. However, algorithms for Authenticated Encryption with Associated Data (AEAD) [RFC5116] do not require a separate integrity algorithm to be negotiated. In particular, since AES-GCM is an AEAD algorithm, ESP implementing AES-GCM MUST either offer no integrity algorithm or indicate the single integrity algorithm NONE (see Section 3.3 of [RFC7296]).
ESPは機密性アルゴリズムと整合性アルゴリズムの両方の交渉を必要とします。ただし、関連データ（AEAD）[RFC5116]を使用した認証された暗号化のためのアルゴリズムは、ネゴシエートするために別の整合性アルゴリズムを必要としません。特に、AES-GCMはAEDアルゴリズムであるため、AES-GCMを実装するESP IMS-GCMは、整合性アルゴリズムを提供しないか、単一の整合性アルゴリズムなしを示している必要があります（[RFC7296]のセクション3.3を参照）。
To be CNSA compliant, IPsec implementations that use the following UI suites MUST use the suite names listed below. 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.
CNSAに準拠するために、次のUIスイートを使用するIPsec実装は、以下にリストされているスイート名を使用する必要があります。IPsec実装は、記述されているスイートのためにここにリストされているものとは異なる名前を使用しないでください。これらの値と一致しないスイートのためにここにリストされている名前を使用してはいけません。これらの要件は相互運用性に必要です。
Transform names are as listed in the IANA "Internet Key Exchange Version 2 (IKEv2) Parameters" registry. Definitions of the transforms are contained in the references specified in that registry.
変換名はIANAの「インターネットキー交換バージョン2（IKEv2）パラメータ」レジストリにリストされています。変換の定義は、そのレジストリに指定されている参照に含まれています。
Other UI suites may be acceptable for CNSA compliance. See Section 8 for details.
他のUIスイートはCNSAコンプライアンスにとって受け入れられるかもしれません。詳細はセクション8を参照してください。
ESP SA: Encryption: ENCR_AES_GCM_16 (with key size 256 bits) Integrity: NONE IKEv2 SA: Encryption: ENCR_AES_GCM_16 (with key size 256 bits) PRF: PRF_HMAC_SHA2_512 Integrity: NONE Diffie-Hellman group: 384-bit random ECP group
ESP SA：暗号化：ENC_AES_GCM_16（キーサイズ256ビット付き）整合性：なしIKEV2 SA：暗号化：ENC_AES_GCM_16（キーサイズ256ビット付）PRF：PRF_HMAC_SHA2_512整合性：なしDIFFIE-HELLMANグループ：384ビットランダムECPグループ
ESP SA: Encryption: ENCR_AES_GCM_16 (with key size 256 bits) Integrity: NONE IKEv2 SA: Encryption: ENCR_AES_GCM_16 (with key size 256 bits) PRF: PRF_HMAC_SHA2_512 Integrity: NONE Diffie-Hellman group: 3072-bit MODP group
ESP SA：暗号化：ENC_AES_GCM_16（キーサイズ256ビット付き）整合性：なしIKEV2 SA：暗号化：ENC_AES_GCM_16（キーサイズ256ビット付）PRF：PRF_HMAC_SHA2_512整合性：なしDiffie-Hellmanグループ：3072ビットMODPグループ
ESP SA: Encryption: ENCR_AES_GCM_16 (with key size 256 bits) Integrity: NONE IKEv2 SA: Encryption: ENCR_AES_GCM_16 (with key size 256 bits) PRF: PRF_HMAC_SHA2_512 Integrity: NONE Diffie-Hellman group: 4096-bit MODP group
ESP SA：暗号化：ENC_AES_GCM_16（キーサイズ256ビット付き）整合性：なしIKEV2 SA：暗号化：ENC_AES_GCM_16（キーサイズ256ビット付）PRF：PRF_HMAC_SHA2_512整合性：なしDIFFIE-HELLMANグループ：4096ビットMODPグループ
Authentication of the IKEv2 Security Association (SA) requires computation of a digital signature. To be CNSA compliant, digital signatures MUST be generated with SHA-384 as defined in [RFC8017] together with either ECDSA-384 as defined in [RFC4754] or RSA with 3072-bit or greater modulus. (For applications with long data-protection requirements, somewhat different rules apply; see Section 12.)
IKEv2セキュリティアソシエーション（SA）の認証はデジタル署名の計算を必要とします。CNSAに準拠するには、[RFC4754]またはRSAで定義されている[RFC8017]または3072ビットまたは大きいモジュラスで定義されているECDSA-384と一緒に[RFC8017]で定義されているSHA-384でデジタル署名を生成する必要があります。（長いデータ保護要件を持つアプリケーションの場合は、幾分異なる規則が適用されます。セクション12を参照）
Initiators and responders MUST be able to verify ECDSA-384 signatures and MUST be able to verify RSA with 3072-bit or 4096-bit modulus and SHA-384 signatures.
イニシエータとレスポンダは、ECDSA-384シグネチャを検証できなければならず、3072ビットまたは4096ビットモジュラスおよびSHA-384シグネチャでRSAを検証できなければなりません。
For CNSA-compliant systems, authentication methods other than ECDSA-384 or RSA MUST NOT be accepted for IKEv2 authentication. A 3072-bit modulus or larger MUST be used for RSA. If the relying party receives a message signed with any authentication method other than an ECDSA-384 or RSA signature, it MUST return an AUTHENTICATION_FAILED notification and stop processing the message. If the relying party receives a message signed with RSA using less than a 3072-bit modulus, it MUST return an AUTHENTICATION_FAILED notification and stop processing the message.
CNSA準拠のシステムの場合、ECDSA-384以外の認証方法またはRSA以外の認証方法は、IKEv2認証のために受け入れられてはいけません。RSAには3072ビットモジュラス以上を使用する必要があります。Reliing PartyがECDSA-384またはRSAシグネチャ以外の認証方法に署名されたメッセージを受信した場合は、認証を返し、メッセージの処理を中止する必要があります。Reliing Partyが3072ビットのモジュラス未満を使用してRSAで署名されたメッセージを受信した場合は、AUTHANCH_FAILED通知を返し、メッセージの処理を中止する必要があります。
To be CNSA compliant, the initiator and responder MUST use X.509 certificates that comply with [RFC8603]. Peer authentication decisions must be based on the Subject or Subject Alternative Name from the certificate that contains the key used to validate the signature in the Authentication Payload as defined in Section 3.8 of [RFC7296], rather than the Identification Data from the Identification Payload that is used to look up policy.
CNSAに準拠するには、イニシエータとレスポンダは[RFC8603]に準拠したX.509証明書を使用する必要があります。ピア認証の決定は、識別ペイロードからの識別データではなく、[RFC7296]のセクション3.8ではなく、認証ペイロード内の署名を検証するために使用される鍵を含む証明書または主題の代替名に基づいている必要があります。ポリシーを検索するために使用されます。
Section 5 specifies three UI suites for ESP and IKEv2 Security Associations. All three use AES-GCM for encryption but differ in the key exchange algorithm. Galois/Counter Mode (GCM) [RFC4106] combines counter (CTR) mode with a secure, parallelizable, and efficient authentication mechanism. Since AES-GCM is an AEAD algorithm, ESP implements AES-GCM with no additional integrity algorithm (see Section 3.3 of [RFC7296]).
セクション5 ESPおよびIKEV2セキュリティアソシエーションの3つのUIスイートを指定します。3つの3つすべての暗号化のためにAES-GCMを使用しますが、鍵交換アルゴリズムが異なります。Galois / Counter Mode（GCM）[RFC4106]は、カウンタ（CTR）モードを安全な、並列化可能、効率的な認証メカニズムで組み合わせます。AES-GCMはAEDアルゴリズムであるため、ESPは追加の完全性アルゴリズムがないAES-GCMを実装しています（[RFC7296]のセクション3.3を参照）。
An initiator proposal SHOULD be constructed from one or more of the following suites:
イニシエータ提案は、次のスイートのうちの1つ以上から構成されます。
* CNSA-GCM-256-ECDH-384 * CNSA-GCM-256-DH-3072 * CNSA-GCM-256-DH-4096
* CNSA-GCM-256-ECDH-384 * CNSA-GCM-256-DH-3072 * CNSA-GCM-256-DH-4096
A responder SHOULD accept proposals constructed from at least one of the three named suites. Other UI suites may result in acceptable proposals (such as those based on PRF_HMAC_SHA2_384); however, these are provided to promote interoperability.
応答者は、3つの3つのスイートのうちの少なくとも1つから構築された提案を受け入れるべきです。他のUIスイートは許容可能な提案（PRF_HMAC_SHA2_384に基づくものなど）をもたらす可能性があります。しかし、これらは相互運用性を促進するために提供されています。
Nonce construction for AES-GCM using a misuse-resistant technique [RFC8452] conforms with the requirements of this document and MAY be used if a Federal Information Processing Standard (FIPS) validated implementation is available.
誤用抵抗性技術を用いたAES - GCMのためのNonce構築[RFC8452]この文書の要件に準拠し、連邦情報処理標準（FIPS）検証された実施が利用可能である場合に使用され得る。
The named UI suites specify PRF_HMAC_SHA2_512 for the IKEv2 SA PRF transform, as PRF_HMAC_SHA2_384 is not listed among required PRF transforms in [RFC8247]; therefore, implementation of the latter is likely to be scarce. The security level of PRF_HMAC_SHA2_512 is comparable, and the difference in performance is negligible. However, SHA-384 is the official CNSA algorithm for computing a condensed representation of information. Therefore, the PRF_HMAC_SHA2_384 transform is CNSA compliant if it is available to the initiator and responder. Any PRF transform other than PRF_HMAC_SHA2_384 or PRF_HMAC_SHA2_512 MUST NOT be used.
PRF_HMAC_SHA2_384は、[RFC8247]で必要なPRF変換の中に表示されていないため、名前付きUIスイートはIKEV2 SA PRF変換のPRF_HMAC_SHA2_512を指定します。したがって、後者の実装は乏しいと思われます。PRF_HMAC_SHA2_512のセキュリティレベルは同等であり、パフォーマンスの違いはごくわずかです。ただし、SHA-384は、情報の凝縮表現を計算するための公式CNSAアルゴリズムです。したがって、PRF_HMAC_SHA2_384変換は、イニシエータとレスポンダが使用できる場合はCNSAに準拠しています。PRF_HMAC_SHA2_384またはPRF_HMAC_SHA2_512以外のPRF変換を使用しないでください。
If none of the proposals offered by the initiator consist solely of transforms based on CNSA algorithms (such as those in the UI suites defined in Section 5), the responder MUST return a Notify payload with the error NO_PROPOSAL_CHOSEN when operating in CNSA-compliant mode.
イニシエータによって提供された提案のいずれもCNSAアルゴリズム（セクション5で定義されているUIスイート内のUIスイートのような）に基づく変換のみである場合、ResponderはCNSA準拠モードで動作するときにエラーNO_PROPOSAL_CHOSENで通知ペイロードを返す必要があります。
The key exchange payload is used to exchange Diffie-Hellman public numbers as part of a Diffie-Hellman key exchange. The CNSA-compliant initiator and responder MUST each generate an ephemeral key pair to be used in the key exchange.
鍵交換ペイロードは、Diffie-Hellman Key Exchangeの一部としてDiffie-Hellmanの公開番号を交換するために使用されます。CNSA準拠のイニシエータとレスポンダはそれぞれ、鍵交換で使用されるべきエフェメラルキーペアを生成しなければなりません。
If the Elliptic Curve Diffie-Hellman (ECDH) key exchange is selected for the SA, the initiator and responder both MUST generate an elliptic curve (EC) key pair using the P-384 elliptic curve. The ephemeral public keys MUST be stored in the key exchange payload as described in [RFC5903].
SAに対して楕円曲線Diffie-Hellman（ECDH）キー交換が選択された場合、イニシエータとレスポンダは両方ともP-384楕円曲線を使用して楕円曲線（EC）キーペアを生成しなければなりません。[RFC5903]の説明に従って、エフェラルの公開鍵を鍵交換ペイロードに保管する必要があります。
If the Diffie-Hellman (DH) key exchange is selected for the SA, the initiator and responder both MUST generate a key pair using the appropriately sized MODP group as described in [RFC3526]. The size of the MODP group will be determined by the selection of either a 3072-bit or greater modulus for the SA.
SAに対してDIFFIE-HELLMAN（DH）キー交換が選択されている場合、イニシエータとレスポンダは両方とも[RFC3526]に記載されているように適切なサイズのMODPグループを使用してキーペアを生成しなければなりません。MODPグループのサイズは、SAのための3072ビットまたはそれ以上のモジュラスの選択によって決定されます。
As noted in Section 7 of [RFC5903], the shared secret result of an ECDH key exchange is the 384-bit x value of the ECDH common value. The shared secret result of a DH key exchange is the number of octets needed to accommodate the prime (e.g., 384 octets for 3072-bit MODP group) with leading zeros as necessary, as described in Section 2.1.2 of [RFC2631].
[RFC5903]のセクション7で述べたように、ECDH鍵交換の共有秘密の結果は、ECDH共通値の384ビットx値です。DH鍵交換の共有秘密の結果は、[RFC2631]のセクション2.1.2で説明されているように、必要に応じて主要なゼロを持つプライム（例えば、3072ビットMODPグループのための384オクテット）を収容するのに必要なオクテットの数です。
IKEv2 allows for the reuse of Diffie-Hellman private keys; see Section 2.12 of [RFC7296]. However, there are security concerns related to this practice. Section 5.6.3.3 of [SP80056A] states that an ephemeral private key MUST be used in exactly one key establishment transaction and MUST be destroyed (zeroized) as soon as possible. Section 5.8 of [SP80056A] states that any shared secret derived from key establishment MUST be destroyed (zeroized) immediately after its use. CNSA-compliant IPsec systems MUST follow the mandates in [SP80056A].
IKEv2はDiffie-Hellman秘密鍵の再利用を可能にします。[RFC7296]のセクション2.12を参照してください。しかし、この慣行に関連するセキュリティ上の懸念があります。[SP80056A]のセクション5.6.3.3は、一時的な秘密鍵が正確に1つの重要な確立トランザクションで使用されなければならず、できるだけ早く破棄されなければならない（ゼロ化）する必要があります。[SP80056A]のセクション5.8は、鍵事業所から派生した共有秘密がその使用の直後に破壊されなければならないと述べています。CNSA準拠のIPSecシステムは[SP80056A]の命令に従う必要があります。
The IPsec protocol AH MUST NOT be used in CNSA-compliant implementations.
IPsecプロトコルAHは、CNSA準拠の実装では使用しないでください。
A Diffie-Hellman group MAY be negotiated for a Child SA as described in Section 1.3 of [RFC7296], allowing peers to employ Diffie-Hellman in the CREATE_CHILD_SA exchange. If a transform of type 4 is specified for an SA for ESP, the value of that transform MUST match the value of the transform used by the IKEv2 SA.
Diffie-Hellmanグループは、[RFC7296]のセクション1.3で説明されているように、子どもSAに対して交渉することができ、PeersはCREATE_CHILD_SA ExchangeでDiffie-Hellmanを使用できるようになります。ESPのSAにタイプ4の変換が指定されている場合、その変換の値はIKEV2 SAによって使用される変換の値と一致しなければなりません。
Per [RFC7296], 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 CNSA-compliant IPsec implementations, the Diffie-Hellman group of the KEi MUST use the same group used in the IKE_INIT_SA.
[RFC7296]（RFC7296]、create_child_sa ExchangeにKEIペイロードが含まれている場合、SAオファーの少なくとも1つには、KEIのDiffie-Hellmanグループを含める必要があります。CNSA準拠のIPsec実装の場合、KEIのDiffie-Hellmanグループは、IKE_INIT_SAで使用されているのと同じグループを使用する必要があります。
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 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 group.
IKEV2の場合、CREATE_CHILD_SAのREKEYは両当事者でサポートされている必要があります。この交換のイニシエータは、新しいDiffie-Hellmanキーを含み得る。含まれている場合は、IKE_INIT_SAで使用されているのと同じグループを使用する必要があります。ExchangeのイニシエータにDiffie-Hellmanキーが含まれている場合、レスポンダはDiffie-Hellmanキーを含めなければならず、同じグループを使用する必要があります。
For CNSA-compliant systems, the IKEv2 authentication method MUST use an end-entity certificate provided by the authenticating party. Identification Payloads (IDi and IDr) in the IKE_AUTH exchanges MUST NOT be used for the IKEv2 authentication method but may be used for policy lookup.
CNSA準拠システムの場合、IKEv2認証方法は認証当事者によって提供されたエンドエンティティ証明書を使用する必要があります。IKE_AUTHの交換の識別ペイロード（IDIとIDR）は、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で1つのスイートのみが指定されている場合、IKEv2実装はその1つのスイートのアルゴリズムのみを提供する必要があります。
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. If more than one suite is specified in the administrative UI, the IKEv2 implementation MUST only offer algorithms of those suites. (Note that although this document does not define a UI suite specifying PRF_HMAC_SHA2_384, a proposal containing such a transform is CNSA compliant.)
管理UIは、オペレータが複数のスイートを指定することを可能にし得る。これを許可する場合は、オペレーターが提供されるか受け入れられるスイートの優先順位を指定できます。管理UIで複数のスイートが指定されている場合、IKEv2実装はそれらのスイートのアルゴリズムのみを提供しなければなりません。（PRF_HMAC_SHA2_384を指定するUIスイートを定義していないが、そのような変換を含む提案はCNSAに準拠していることに注意してください。）
The CNSA mandate is to continue to use current algorithms with increased security parameters, then transition to approved post-quantum resilient algorithms when they are identified. However, some applications have data-in-transit-protection requirements that are long enough that post-quantum resilient protection must be provided now. Lacking approved asymmetric post-quantum resilient confidentiality algorithms, that means approved symmetric techniques must be used as described in this section until approved post-quantum resilient asymmetric algorithms are identified.
CNSAの必須は、セキュリティパラメータが増加した状態で現在のアルゴリズムを使用し続けることであり、識別されたときに承認された承認後の弾力性のあるアルゴリズムに移行することです。ただし、一部のアプリケーションには十分な長さが十分な長さの保護要件を持つものがあります。承認された非対称的な量子弾性機密性のアルゴリズムを欠く、承認された対称技術は、承認された後量子弾性不斉非対称アルゴリズムが識別されるまで、このセクションで説明されているように使用されなければならない。
For new applications, confidentiality and integrity requirements from the sections above MUST be followed, with the addition of a Pre-Shared Key (PSK) mixed in as defined in [RFC8784].
新しいアプリケーションの場合、上記のセクションからの機密性と整合性の要件に従う必要があります。
Installations currently using IKEv1 with PSKs MUST (1) use AES in cipher block chaining mode (AES-CBC) in conjunction with a CNSA-compliant integrity algorithm (e.g., AUTH_HMAC_SHA2_384_192) and (2) transition to IKEv2 with PSKs [RFC8784] as soon as implementations become available.
PSKSを使用してIKEv1を使用しているインストール（1）CNSA準拠の整合性アルゴリズム（例えば、AUT_HMAC_SHA2_384_192）と組み合わせて暗号ブロックチェーン・モード（AES-CBC）でAESを使用する必要があります（例：AUT_HMAC_SHA2_384_192）、PSKS [RFC8784]実装が利用可能になるにつれて。
Specific guidance for systems not compliant with the requirements of this document, including non-GCM modes and PSK length, and PSK randomness, will be defined in solution-specific requirements appropriate to the application. Details of those requirements will depend on the program under which the commercial National Security Systems solution is developed (e.g., an NSA Commercial Solutions for Classified Capability Package).
非GCMモードとPSKの長さ、およびPSKランダム性を含む、この文書の要件に準拠していないシステムの具体的なガイダンスは、アプリケーションに適したソリューション固有の要件で定義されます。これらの要求事項の詳細は、市販の国家セキュリティシステムソリューションが開発されたプログラム（例えば、分類された機能パッケージのためのNSA商用ソリューション）に依存します。
This document inherits all of the security considerations of the IPsec and IKEv2 documents, including [RFC7296], [RFC4303], [RFC4754], and [RFC8221].
この文書は、[RFC7296]、[RFC4303]、[RFC4754]、[RFC8221]を含む、IPSecおよびIKEv2の文書のすべてのセキュリティ上の考慮事項を継承しています。
The security of a system that uses cryptography 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.
暗号化を使用するシステムのセキュリティは、選択された暗号化アルゴリズムの強度とそれらのアルゴリズムと共に使用されるキーの強度によって異なります。セキュリティは、システム全体のセキュリティを迂回するための非暗号化方法がないことを確認するために、システムによって使用されるプロトコルの工学と管理によっても依存します。
When selecting a mode for the AES encryption [RFC5116], be aware that nonce reuse can result in a loss of confidentiality. Nonce reuse is catastrophic for GCM, since it also results in a loss of integrity.
AES暗号化[RFC5116]のモードを選択するときは、NOCEの再利用が機密性が損なわれる可能性があることに注意してください。Nonce ReuseはGCMにとって壊滅的なものです。
IANA has added the UI suites defined in this document to the "Cryptographic Suites for IKEv1, IKEv2, and IPsec" registry located at <https://www.iana.org/assignments/crypto-suites>:
IANAはこのドキュメントで定義されているUIスイートを<https：//www.iana.org/assignments/crypto-suites>にある「IKEv1、IKEv2、およびIPsec」レジストリに「暗号スイート」レジストリに追加しました。
+=======================+===========+
| Identifier | Reference |
+=======================+===========+
| CNSA-GCM-256-ECDH-384 | RFC 9206 |
+-----------------------+-----------+
| CNSA-GCM-256-DH-3072 | RFC 9206 |
+-----------------------+-----------+
| CNSA-GCM-256-DH-4096 | RFC 9206 |
+-----------------------+-----------+
Table 1
表1
[CNSA] Committee for National Security Systems, "Use of Public Standards for Secure Information Sharing", CNSSP 15, October 2016, <https://www.cnss.gov/CNSS/Issuances/Policies.htm>.
[CNSA]国家セキュリティシステムの委員、「安全な情報共有のための公共標準の使用」、CNSSP 15、2016年10月15日、<https：//www.cnss.gov/cnss/issuances/policies.htm>。
[FIPS180] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", Federal Information Processing Standard 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, <https://csrc.nist.gov/publications/detail/fips/180/4/ final>.
[FIPS180]国立標準技術研究所、「安全なハッシュスタンダード（SHS）」、連邦情報処理スタンダード180-4、DOI 10.6028 / NIST.FIPS.180-4、<https：//csrc.nist。GOV /出版物/詳細/ FIPS / 180/4 /最終>。
[FIPS186] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", NIST Federal Information Processing Standard 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013, <https://csrc.nist.gov/publications/detail/fips/186/4/ final>.
[FIPS186]国立標準技術研究所、「Digital Signature Standard（DSS）」、NIST連邦情報処理規格186-4、DOI 10.6028 / NIST.FIPS.186-4、<https：//csrc.nist.GOV /出版物/詳細/ FIPS / 186/4 / FINAL>。
[FIPS197] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", Federal Information Processing Standard 197, DOI 10.6028/NIST.FIPS.197, November 2001, <https://csrc.nist.gov/publications/detail/fips/197/ final>.
[FIPS197]国立標準技術研究所、「高度な暗号化規格（AES）」、連邦情報処理スタンダード197、DOI 10.6028 / NIST.FIPS.197、2001年11月、<https：//csrc.nist.gov/publications/詳細/ FIPS / 197 /最後>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, DOI 10.17487/RFC2631, June 1999, <https://www.rfc-editor.org/info/rfc2631>.
[RFC2631] RESCORLA、E.、「DIFFIE-HELLMANキー契約方法」、RFC 2631、DOI 10.17487 / RFC2631、1999年6月、<https://www.rfc-editor.org/info/rfc2631>。
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, DOI 10.17487/RFC3526, May 2003, <https://www.rfc-editor.org/info/rfc3526>.
[RFC3526] Kivinen、T.およびM. kojo、「インターネット鍵交換（IKE）」、RFC 3526、DOI 10.17487 / RFC3526、DIFI 10.17487 / RFC3526、<https：// www。rfc-editor.org/info/rfc3526>。
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, DOI 10.17487/RFC4106, June 2005, <https://www.rfc-editor.org/info/rfc4106>.
[RFC4106] Viega、J.およびD.Mcgrew、「Galois / Counter Mode（GCM）のIPsecカプセル化セキュリティペイロード（ESP）」、RFC 4106、DOI 10.17487 / RFC4106、2005年6月、<HTTPS：// WWW.rfc-editor.org / info / rfc4106>。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、DOI 10.17487 / RFC4303、2005年12月、<https：//www.rfc-editor.org/info/rfc4303>。
[RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308, DOI 10.17487/RFC4308, December 2005, <https://www.rfc-editor.org/info/rfc4308>.
[RFC4308] Hoffman、P.、「IPSec用暗号スイート」、RFC 4308、DOI 10.17487 / RFC4308、2005年12月、<https：//www.rfc-editor.org/info/rfc4308>。
[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 4754, DOI 10.17487/RFC4754, January 2007, <https://www.rfc-editor.org/info/rfc4754>.
[RFC4754] FU、D.およびJ.Solinas、「IKEおよびIKEV2認証楕円曲線デジタル署名アルゴリズム（ECDSA）」、RFC 4754、DOI 10.17487 / RFC4754、2007年1月、<https：//www.rfc-編集者.ORG / INFO / RFC4754>。
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <https://www.rfc-editor.org/info/rfc5116>.
[RFC5116] MCGREW、D.、「認証済み暗号化のためのインタフェースとアルゴリズム」、RFC 5116、DOI 10.17487 / RFC5116、2008年1月、<https://www.rfc-editor.org/info/rfc5116>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW.Polk、 "Internet X.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル「、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2", RFC 5903, DOI 10.17487/RFC5903, June 2010, <https://www.rfc-editor.org/info/rfc5903>.
[RFC5903] FU、D.およびJ.Solinas、「楕円曲線グループモジュロA＆IKEV2」、RFC 5903、DOI 10.17487 / RFC5903、2010年6月、<https：///www.rfc-編集者.ORG / INFO / RFC5903>。
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7296] Kaufman、C.、Hoffman、P.、NIR、Y.、ERONEN、P.、およびT.Kivinen、「インターネットキー交換プロトコル版2（IKEV2）」、STD 79、RFC 7296、DOI 10.17487 / RFC72962014年10月、<https://www.rfc-editor.org/info/rfc7296>。
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, <https://www.rfc-editor.org/info/rfc8017>.
[RFC8017] MoriAlty、K。、ED。、Kaliski、B.、Jonsson、J.、A. RUSCH、「PKCS＃1：RSA暗号化仕様バージョン2.2」、RFC 8017、DOI 10.17487 / RFC8017、2016年11月、<https://www.rfc-editor.org/info/rfc8017>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B.、RFC 2119キーワードの「大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. Kivinen, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 8221, DOI 10.17487/RFC8221, October 2017, <https://www.rfc-editor.org/info/rfc8221>.
[RFC8221] Wouters、P.、Migaute、D.、Mattsson、J.、NIR、Y.、T.Kivinen、セキュリティペイロード（ESP）および認証ヘッダー（AH）をカプセル化するための暗号化アルゴリズムの実装要件と使用ガイダンス、RFC 8221、DOI 10.17487 / RFC8221、2017年10月、<https：//www.rfc-editor.org/info/rfc8221>。
[RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, "Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 8247, DOI 10.17487/RFC8247, September 2017, <https://www.rfc-editor.org/info/rfc8247>.
[RFC8247] NIR、Y、Kivinen、T.、Wouters、P.、およびD. Migault、「インターネット鍵交換プロトコルバージョン2（IKEV2）」、RFC 8247、DOI 10.17487 / RFC8247、2017年9月、<https://www.rfc-editor.org/info/rfc8247>。
[RFC8603] Jenkins, M. and L. Zieglar, "Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile", RFC 8603, DOI 10.17487/RFC8603, May 2019, <https://www.rfc-editor.org/info/rfc8603>.
[RFC8603] Jenkins、M.およびL.Zieglar、「商業全国セキュリティアルゴリズム（CNSA）スイート証明書および証明書失効リスト（CRL）プロファイル」、RFC 8603、DOI 10.17487 / RFC8603、2019年5月、<https：// www。rfc-editor.org/info/rfc8603>。
[RFC8784] Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov, "Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security", RFC 8784, DOI 10.17487/RFC8784, June 2020, <https://www.rfc-editor.org/info/rfc8784>.
[RFC8784] Fluhrer、S、Kampanakis、P.、McGrew、D.、およびV.SmySlov、「インターネットキー交換プロトコル版2（IKEV2）の「自動鍵交換プロトコルバージョン2（IKEv2）」、RFC 8784、DOI 10.17487/ RFC8784、2020年6月、<https：//www.rfc-editor.org/info/rfc8784>。
[SP80056A] National Institute of Standards and Technology, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography", NIST Special Publication 800-56A, Revision 3, DOI 10.6028/NIST.SP.800-56Ar3, April 2018, <https://csrc.nist.gov/publications/detail/sp/800-56a/rev-3/final>.
[SP80056A]国立標準技術研究所、「離散対数クリプトグラフィーを用いたペアワイズ鍵確立方式の推奨事項」、NIST特殊出版物800-56A、リビジョン3、DOI 10.6028 / NIST.SP.800-56AR3、2018年4月、<https://csrc.nist.gov/publications/detail/sp/800-56A/REV - Final>。
[RFC8452] Gueron, S., Langley, A., and Y. Lindell, "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption", RFC 8452, DOI 10.17487/RFC8452, April 2019, <https://www.rfc-editor.org/info/rfc8452>.
[RFC8452] Gueron、S.、Langley、A。、およびY。Lindell、 "AES-GCM-SIV：Nonce誤用認証暗号化"、RFC 8452、DOI 10.17487 / RFC8452、2019年4月、<HTTPS：// WWW.rfc-editor.org / info / rfc8452>。
[SP80059] National Institute of Standards and Technology, "Guideline for Identifying an Information System as a National Security System", Special Publication 800-59, DOI 10.6028/NIST.SP.800-59, August 2003, <https://csrc.nist.gov/publications/detail/sp/800-59/ final>.
[SP80059]国立標準技術研究所、「国家安全保障システムとしての情報システムを特定するためのガイドライン」、特別出版物800-59、DOI 10.6028 / NIST.SP.800-59、2003年8月、<https：// CSRC.nist.gov /出版物/詳細/ SP / 800-59 / FINAL>。
Authors' Addresses
著者の住所
Laura Corcoran National Security Agency Email: lscorco@nsa.gov
Laura Corcoran National Security Agency Eメール：lscorco@nsa.gov.
Michael Jenkins National Security Agency - Center for Cybersecurity Standards Email: mjjenki@cyber.nsa.gov
Michael Jenkins National Security Agency - サイバーセキュリティ基準センター電子メール：mjjenki@cyber.nsa.gov