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

URL : https://tools.ietf.org/html/rfc6380
タイトル : RFC 6380 - インターネットプロトコルセキュリティ（IPsec）のための組曲の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)

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）の中にスイート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アルゴリズムのために必要な規則の大半は、すでに他の文書で指定されています。この文書では、いくつかの関連の詳細は、スイート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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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で取得することができます。

著作権表示

著作権（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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.

この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さ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

1. はじめに

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

この文書では、IPセキュリティ（IPsec）の中NSAスイート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データグラムに機密性、データの整合性、アクセス制御、およびデータ・ソースの認証を提供します。インターネット鍵交換（IKE）IKEとIPsecの両方の通信を保護両当事者と確立セキュリティアソシエーション（SA）との間で相互認証を行い、IPsecのための自動化キー管理を提供します。 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のスイート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].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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)

鍵交換楕円曲線ディフィ - ヘルマン（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つの楕円曲線は、二つの異なる名前で文献に現れます。明確にするために、我々は、以下の両方の名前をリスト：

      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グループを登録しています。

4. Minimum Levels of Security (minLOS)

セキュリティの4最小レベル（minLOS）

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）2つのレベルを提供します。各レベルは、すべての暗号化アルゴリズムを提供しなければならない最低限の強度を規定します。

4.1. Non-Signature Primitives

4.1. 非署名プリミティブ

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

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

                                  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]：スイート-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-GCM-128、スイート-B-GMAC-128のいずれか、スイート-B-GCM-256またはスイート-B-GMAC-256は、スイート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].

- スイート-B-GCM-256またはスイート-B-GMAC-256のいずれかは、スイート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準拠した実装での認証に使用しなければなりません。 ECDSA-256およびECDSA-384：[RFC4754]は、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のいずれかを使用しなければなりません。一方の当事者がECDSA-384での認証にECDSA-256と他のパーティで認証することが許容されます。この柔軟性は、イニシエータと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.

イニシエータとレスポンダは、セキュリティの両方の最小レベルで、それぞれ、「スイートBの証明書と証明書失効リスト（CRL）プロファイル」[RFC5759]に準拠したX.509証明書を使用する必要があり、それが持つ楕円曲線公開鍵を含みますキー使用ビットは、デジタル署名のために設定します。

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

IKEv2のとIPsec 5.スイートBセキュリティアソシエーション（SA）

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」とのスイートを使用しなければなりません。 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.

または、スイート-B-GCM-256、スイート-B-GMAC-128、スイート-B-GCM-128：128ビットのセキュリティの最小レベルで構成されたシステムにおいて、イニシエータは、4つのスイートの一つ以上を提供しなければなりませんスイート-B-GMAC-256 [RFC6379]。スイート-B-GCM-128およびスイート-B-GMAC-128は、提供されている場合、スイート-B-GCM-256およびスイート-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ビットのセキュリティの最小レベルで構成されたシステムにおける応答は、1つまたは2つのスイートスイート-B-GCM-128またはスイート-B-GMAC-128の両方をサポートしなければならない1つまたは2つのスイートスイートの両方をサポートすべきです-B-GCM-256またはスイート-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.

スイート-B-GCM-256またはスイート-B-GMAC-256：192ビットのセキュリティの最小レベルで構成されたシステムにおいて、イニシエータは、一方または両方のスイートを提供しなければなりません。

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ビットのセキュリティの最小レベルでシステムに設定レスポンダはスイート-B-GCM-256またはスイート-B-GMAC-256のいずれかを選択しなければなりません。どちらのスイートが提供されている場合は、レスポンダはエラー「NO_PROPOSAL_CHOSEN」との通知ペイロードを返さなければなりません。

6. The Key Exchange Payload in the IKE_SA_INIT Exchange

6. IKE_SA_INIT交換で鍵交換ペイロードは、

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準拠イニシエータとレスポンダは、各楕円曲線ディフィ - ヘルマン（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

IKE SA 7.生成鍵材料

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]はディフィー - ヘルマンエフェメラルキーの再使用を可能にします。 NIST SP800-56Aのセクション5.6.4.3ははかない、秘密鍵は正確に一つの鍵確立トランザクションで使用する必要があり、その使用後にゼロ化しなければならないと述べています。 SP800-56Aのセクション5.8には、ディフィー・ヘルマン共有秘密は、その使用後すぐにゼロ化しなければならないと述べています。スイート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（[RFC5996]、セクション2.14）当たり256ビットであるように生成されなければなりません。 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_、えー、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.

ESPは、直接のDiffie-Hellman交換が含まれていないが当たり[RFC5996]、のDiffie-Hellmanグループは、子SAのために交渉されるかもしれません。これは、ピアがCREATE_CHILD_SA交換にディフィー・ヘルマンを採用することができます。変換タイプ4は、ESPのためのSAのために指定されている場合は、変換の値は、変換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ペイロード圭ののDiffie-Hellmanグループを含まなければならないSAの提供のうちの少なくとも1つを含む場合。スイートBのIPsec準拠の実装のため啓のの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を使用してはなりません。後方互換性に対応するために、スイートBのIPsec準拠のシステムがあれば、唯一のIKEv2は、スイートB準拠イニシエータとレスポンダとの間で使用されるのIKEv1を使用するように構成することができます。 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）は、ポリシールックアップに使用される方法を指定しません。スイート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の実装はその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は、オペレータが複数のスイートを指定することを可能にします。それがこれを許可している場合、それは、オペレータが提供または受け入れられるスイートの優先順位を指定できるようにしなければなりません。複数のスイートは、管理UIで指定されている場合は、セクション4で提供さ方向に従わなければならない優先順位は、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.

[RFC4303]ケント、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]フー、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.チーグラー、 "スイート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]カウフマン、C.、ホフマン、P.、ニール、Y.、およびP. Eronen、 "インターネット鍵交換プロトコルバージョン2（IKEv2の）"、RFC 5996、2010年9月。

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

[RFC6379]法、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.

、NIST特別出版800-56A、2007年3月[SP800-56A]米国国立標準技術研究所、「離散対数暗号を使用してペアワイズ鍵確立スキームのための勧告」。

[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スイート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]フー、D.およびJ. Solinas、 "楕円曲線グループIKE及びIKEv2のためのプライム（ECPグループ）モジュロ"、RFC 5903、2010年6月。

Authors' Addresses

著者のアドレス

Kelley W. Burgin National Security Agency

ケリーW. Burgin国家安全保障局

EMail: kwburgi@tycho.ncsc.mil

メールアドレス：kwburgi@tycho.ncsc.mil

Michael A. Peck The MITRE Corporation

マイケルA.ペックザ・MITRE社

EMail: mpeck@mitre.org

メールアドレス：mpeck@mitre.org