RFC 6380 - Suite B Profile for Internet Protocol Security (IPsec) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6380
タイトル : RFC 6380 - インターネットプロトコルセキュリティのためのスイートBプロファイル（IPSEC）
翻訳編集 : 自動生成

[要約] RFC 6380は、IPsecにおけるSuite Bプロファイルに関する標準化ドキュメントであり、要約すると以下のようになります。1. RFC 6380は、IPsecにおけるSuite Bセキュリティプロトコルのプロファイルを定義しています。 2. このドキュメントの目的は、Suite Bセキュリティアルゴリズムの使用方法と、それらをサポートするためのIPsecの設定と運用に関するガイドラインを提供することです。 3. Suite Bプロファイルは、政府や軍事組織などのセキュリティ要件を満たすために開発されたものであり、高度な暗号化と認証を提供します。

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)

インターネットプロトコルセキュリティのためのスイートBプロファイル（IPSEC）

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 Suite B Cryptography」のガイドラインを公開しました。これは、国家安全保障アプリケーションの暗号化アルゴリズムポリシーを定義しています。このドキュメントは、IPセキュリティ（IPSEC）でスイート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アルゴリズムに必要な規則の大部分は、他のドキュメントで既に指定されています。この文書は、これらの慣習のソースを参照しています。いくつかの関連する詳細は、Suite Bをサポートすることを選択する開発者を支援するために繰り返されます。

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.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6380で取得できます。

著作権表示

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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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

1. はじめに

This document specifies the conventions for using NSA Suite B Cryptography [SuiteB] in IP Security (IPsec).

このドキュメントは、IPセキュリティ（IPSEC）でNSA Suite B Cryptography [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 Key Exchange（IKE）は、IPSECの自動化されたキー管理を提供し、2つの当事者間で相互認証を実行し、IKEとIPSEC通信の両方を保護するセキュリティ協会（SAS）を確立します。IPSECのスイートB準拠の実装は、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]は、スイートBアルゴリズムで構成されるIPSEC向けの4つの暗号化ユーザーインターフェイススイートのセットを定義します。4つのスイートは、IKEV2およびIPカプセル化セキュリティペイロード（ESP）のオプションを指定します[RFC4303]。IPSECのSuite B準拠の実装は、目的のセキュリティレベルとセキュリティサービスに応じて、これら4つのスイートのいずれかを使用する必要があります。

2. Conventions Used in This Document

2. このドキュメントで使用されている規則

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].

「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。

3. Suite B Requirements

3. スイートBの要件

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には[suiteb]が含まれています。

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で使用される2つの楕円曲線は、2つの異なる名前の下で文献に表示されます。明確にするために、以下の両方の名前を以下にリストします。

      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はすでにこれらのDHグループを[IKEV2IANA]に登録しています。

4. Minimum Levels of Security (minLOS)

4. セキュリティの最小レベル（ミンロス）

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.

Suite Bは、2つのレベルの暗号化セキュリティ、つまり128ビットの最小レベルのセキュリティ（Minlos_128）と192ビットの最小レベルのセキュリティレベル（Minlos_192）を提供します。各レベルは、すべての暗号化アルゴリズムが提供する必要がある最小強度を定義します。

4.1. Non-Signature Primitives

4.1. 非署名プリミティブ

We divide the Suite B non-signature primitives into two columns as shown in Table 1.

表1に示すように、スイートBの非署名プリミティブを2つの列に分けます。

                                  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：スイート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からのみ来なければなりません。

4.2. Suite B IPsec Cryptographic Suites

4.2. スイートB IPSEC暗号スイート

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.

4つのスイートB暗号化ユーザーインターフェイススイート（「UIスイート」）[RFC6379]：Suite-B-GCM-128、Suite-B-GMAC-128、Suite-B-GCM-256またはSuite-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].

- Suite-B-GCM-128の1つ、Suite-B-GMAC-128、Suite-B-GCM-256またはSuite-B-GMAC-256は、Suite B IPSEC準拠の実装[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].

- Suite-B-GCM-256またはSuite-B-GMAC-256の1つは、スイートB IPSEC準拠の実装[RFC6379]で使用する必要があります。

4.3. Suite B IKEv2 Authentication

4.3. スイートB IKEV2認証

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を使用したデジタル署名は、スイートB準拠の実装による認証に使用する必要があります。[RFC4754]は、ECDSA-256とECDSA-384の2つのデジタル署名アルゴリズムを定義しています。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ビットの最小レベルのセキュリティで構成されている場合、システムはIKE認証にECDSA-256またはECDSA-384を使用する必要があります。1つの当事者が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準拠システムの場合、ECDSA-256およびECDSA-384以外の認証方法をIKEV2認証に使用してはなりません。頼っている当事者が他の認証方法で署名されたメッセージを受信した場合、Authentication_Failed通知を返し、メッセージの処理を停止する必要があります。

4.4. Digital Signatures and Certificates

4.4. デジタル署名と証明書

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.

イニシエーターとレスポンダーは、両方の最低レベルのセキュリティで、それぞれ「Suite B証明書および証明書取消リスト（CRL）プロファイル」に準拠したX.509証明書を使用する必要があります[RFC5759]。デジタル署名に設定されたキー使用ビット。

5. Suite B Security Associations (SAs) for IKEv2 and IPsec

5. IKEV2およびIPSECのスイートBセキュリティ協会（SAS）

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]の4つのスイートは、ESP [RFC4303]およびIKEV2 [RFC5996]のオプションを指定します。4つのスイートは、暗号化アルゴリズムの強度と、ESPが機密性と完全性または完全性の両方を提供するかどうかの選択によって区別されます。スイート名は、AESモード（「GCM」または「GMAC」）とESP（「128」または「256」）に指定されたAESキーの長さに基づいています。ESP整合性の保護と暗号化が必要な場合は、「GCM」の名前が付いたスイートを使用する必要があります。名前に「GMAC」を持つスイートは、ESP暗号化が不要な場合にのみ使用する必要があります。

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ビットの最小レベルのセキュリティで構成されたシステム内のイニシエーターは、4つのスイートのうち1つ以上を提供する必要があります：Suite-B-GCM-128、Suite-B-GMAC-128、Suite-B-GCM-256、またはSuite-B-GCM-256、またはSuite-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ビットの最低レベルのセキュリティで構成されたシステムのレスポンダーは、2つのスイートSuite-B-GCM-128またはSuite-B-GMAC-128の1つまたは両方をサポートする必要があり、2つのスイートスイートの1つまたは両方をサポートする必要があります。-b-gcm-256またはsuite-b-gmac-256。レスポンダーは、スイートB UIスイートの1つを受け入れる必要があります。4つのスイートが提供されていない場合、レスポンダーは、スイートBコンプライアントモードで操作するときにエラー「no_proposal_chosen」を使用して通知ペイロードを返す必要があります。

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ビットの最小レベルのセキュリティで構成されたシステムのイニシエーターは、Suite-B-GCM-256またはSuite-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のいずれかを選択する必要があります。どちらのスイートも提供されていない場合、レスポンダーはエラー「no_proposal_chosen」で通知ペイロードを返す必要があります。

6. The Key Exchange Payload in the IKE_SA_INIT Exchange

6. IKE_SA_INIT Exchangeのキーエクスチェンジペイロード

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].

スイートB IPSEC準拠のイニシエーターとレスポンダーは、それぞれ、楕円曲線Diffie-Hellman（ECDH）キー交換で使用される短命の楕円曲線キーペアを生成する必要があります。変換タイプ4の256ビットランダムECPグループが選択されている場合、各側はP-256楕円曲線[SP800-57]を使用してECキーペアを生成する必要があります。変換タイプ4の384ビットランダムECPグループが選択されている場合、各側はP-384楕円曲線[SP800-57]を使用してECキーペアを生成する必要があります。はかないパブリックキーは、[RFC5903]のように、キーエクスチェンジペイロードに保存する必要があります。

7. Generating Keying Material for the IKE SA

7. IKE SAのキーイング材料を生成します

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共通値のx値[RFC5903]で構成されています。X値は、それぞれP-256またはP-384曲線を使用する場合、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 Erephemeral Keysの再利用が可能になります。NIST SP800-56Aのセクション5.6.4.3は、一時的な秘密鍵は正確に1つのキー設立トランザクションで使用され、使用後にゼロ化する必要があると述べています。SP800-56Aのセクション5.8は、Diffie-Hellmanの共有秘密を使用した直後にゼロ化する必要があると述べています。Suite 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を使用する場合、SKEYSEED、SK_D、SK_PI、およびSK_PRは、それぞれRFC 5996あたり256ビット（[RFC5996]、セクション2.14）に生成する必要があります。PRF-HMAC-SHA-384を使用する場合、SKEYSEED、SK_D、SK_PI、SK_PRの長さは384ビットに生成する必要があります。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ビットでなければなりません。

8. Additional Requirements

8. 追加の要件

AH is not supported in Suite B compliant implementations.

AHは、スイートB準拠の実装ではサポートされていません。

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 Exchangeは直接含まれていませんが、Diffie-HellmanグループはChild SAのために交渉される場合があります。これにより、ピアはcreate_child_sa Exchangeで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 ExchangeにKEIペイロードが含まれている場合、少なくとも1つのSAオファーにはKEIのdiffie-hellmanグループが含まれている必要があります。スイート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をサポートする必要があり、Suite Bコンプライアントイニシエーターとレスポンダーの間でIKEV1を使用しないでください。後方互換性に対応するために、スイートBコンプライアントイニシエーターとレスポンダーの間でIKEV2のみが使用される限り、IKEV1を使用するようにスイートB IPSEC準拠システムを構成できます。ただし、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_AUTH交換の識別ペイロード（IDIおよびIDR）がポリシー検索にどのように使用されるかを指定していません。Suite 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で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. 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実装はこれらのスイートのアルゴリズムのみを提供する必要があります。

9. Security Considerations

9. セキュリティに関する考慮事項

This document discusses security requirements throughout, and it inherits the security considerations of [RFC4303], [RFC4754], [RFC5759], and [RFC5996].

この文書は、全体を通してセキュリティ要件について説明し、[RFC4303]、[RFC4754]、[RFC5759]、および[RFC5996]のセキュリティ上の考慮事項を継承しています。

10. References

10. 参考文献

10.1. Normative References

10.1. 引用文献

[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。、「セキュリティペイロードのカプセル化（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、「IkeおよびIKEV2認証楕円曲線デジタル署名アルゴリズム（ECDSA）」、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、「Suite 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、「Internet Key Exchange Protocolバージョン2（IKEV2）」、RFC 5996、2010年9月。

[RFC6379] Law, L. and J. Solinas, "Suite B Cryptographic Suites for IPsec", RFC 6379, October 2011.

[RFC6379] Law、L。and 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]国立標準技術研究所、「Secure Hash Standard」、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]国立標準技術研究所、「Digital Signature Standard（DSS）」、Fips Pub 186-3、2009年6月。

[FIPS197] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001.

[FIPS197]国立標準技術研究所、「Advanced Encryption Standard（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 Special Publication 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 Special Publication 800-57、2007年3月。

10.2. Informative References

10.2. 参考引用

[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 Suite B Cryptography」、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、「Elliptic Curveグループは、IKEおよびIKEV2のプライム（ECPグループ）を測定します」、RFC 5903、2010年6月。

Authors' Addresses

著者のアドレス

Kelley W. Burgin National Security Agency

ケリー・W・バージン国家安全保障局

   EMail: kwburgi@tycho.ncsc.mil

Michael A. Peck The MITRE Corporation

マイケル・A・ペック・ザ・マイター・コーポレーション

   EMail: mpeck@mitre.org