[要約] RFC 5282は、IKEv2プロトコルの暗号化ペイロードで認証された暗号化アルゴリズムの使用に関するものです。その目的は、IKEv2セッションのセキュリティを向上させるために、認証と暗号化を組み合わせることです。
Network Working Group D. Black
Request for Comments: 5282 EMC
Updates: 4306 D. McGrew
Category: Standards Track August 2008
Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol
Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2（IKEv2）Protocol
Status of This Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
概要
An authenticated encryption algorithm combines encryption and integrity into a single operation; such algorithms may also be referred to as combined modes of an encryption cipher or as combined mode algorithms. This document describes the use of authenticated encryption algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) protocol.
認証された暗号化アルゴリズムは、暗号化と整合性を1つの操作に結合します。このようなアルゴリズムは、暗号化暗号の複合モードまたは複合モードアルゴリズムとも呼ばれます。このドキュメントでは、インターネットキーエクスチェンジバージョン2（IKEv2）プロトコルの暗号化ペイロードでの認証済み暗号化アルゴリズムの使用について説明します。
The use of two specific authenticated encryption algorithms with the IKEv2 Encrypted Payload is also described; these two algorithms are the Advanced Encryption Standard (AES) in Galois/Counter Mode (AES GCM) and AES in Counter with CBC-MAC Mode (AES CCM). Additional documents may describe the use of other authenticated encryption algorithms with the IKEv2 Encrypted Payload.
IKEv2暗号化ペイロードでの2つの特定の認証済み暗号化アルゴリズムの使用についても説明します。これらの2つのアルゴリズムは、ガロア/カウンターモード（AES GCM）のAdvanced Encryption Standard（AES）とCBC-MACモードのカウンター（AES CCM）のAESです。その他のドキュメントでは、IKEv2暗号化ペイロードでの他の認証済み暗号化アルゴリズムの使用について説明している場合があります。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Structure of this Document ......................................4
3. IKEv2 Encrypted Payload Data ....................................4
3.1. AES GCM and AES CCM Initialization Vector (IV) .............6
3.2. AES GCM and AES CCM Ciphertext (C) Construction ............6
4. AES GCM and AES CCM Nonce (N) Format ............................7
5. IKEv2 Associated Data (A) .......................................8
5.1. Associated Data (A) Construction ...........................8
5.2. Data Integrity Coverage ....................................8
6. AES GCM and AES CCM Encrypted Payload Expansion .................9
7. IKEv2 Conventions for AES GCM and AES CCM .......................9
7.1. Keying Material and Salt Values ............................9
7.2. IKEv2 Identifiers .........................................10
7.3. Key Length ................................................10
8. IKEv2 Algorithm Selection ......................................11
9. Test Vectors ...................................................11
10. RFC 5116 AEAD_* Algorithms ....................................11
10.1. AES GCM Algorithms with 8- and 12-octet ICVs .............12
10.1.1. AEAD_AES_128_GCM_8 ................................12
10.1.2. AEAD_AES_256_GCM_8 ................................12
10.1.3. AEAD_AES_128_GCM_12 ...............................12
10.1.4. AEAD_AES_256_GCM_12 ...............................12
10.2. AES CCM Algorithms with an 11-octet Nonce ................13
10.2.1. AEAD_AES_128_CCM_SHORT ............................13
10.2.2. AEAD_AES_256_CCM_SHORT ............................14
10.2.3. AEAD_AES_128_CCM_SHORT_8 ..........................14
10.2.4. AEAD_AES_256_CCM_SHORT_8 ..........................14
10.2.5. AEAD_AES_128_CCM_SHORT_12 .........................14
10.2.6. AEAD_AES_256_CCM_SHORT_12 .........................14
10.3. AEAD_* Algorithms and IKEv2 ..............................15
11. Security Considerations .......................................15
12. IANA Considerations ...........................................16
13. Acknowledgments ...............................................16
14. References ....................................................17
14.1. Normative References .....................................17
14.2. Informative References ...................................17
An authenticated encryption algorithm combines encryption and integrity into a single operation on plaintext data to produce ciphertext that includes an integrity check [RFC5116]. The integrity check may be an Integrity Check Value (ICV) that is logically distinct from the encrypted data, or the integrity check may be incorporated into the encrypted data that is produced. Authenticated encryption algorithms may also be referred to as combined modes of operation of a block cipher or as combined mode algorithms.
認証された暗号化アルゴリズムは、暗号化と整合性をプレーンテキストデータに対する単一の操作に組み合わせて、整合性チェックを含む暗号文を生成します[RFC5116]。整合性チェックは、暗号化されたデータと論理的に異なる整合性チェック値（ICV）にすることも、生成される暗号化されたデータに整合性チェックを組み込むこともできます。認証された暗号化アルゴリズムは、ブロック暗号の複合動作モードまたは複合モードアルゴリズムとも呼ばれます。
An Authenticated Encryption with Associated Data (AEAD) algorithm also provides integrity protection for additional data that is associated with the plaintext, but which is left unencrypted. This document describes the use of AEAD algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) protocol. The use of two specific AEAD algorithms with the IKEv2 Encrypted Payload is also described; the two algorithms are the Advanced Encryption Standard (AES) in Galois/Counter Mode (AES GCM) [GCM] and AES in Counter with CBC-MAC Mode (AES CCM) [CCM].
Authenticated Encryption with Associated Data（AEAD）アルゴリズムは、プレーンテキストに関連付けられているが暗号化されないままになっている追加データの整合性保護も提供します。このドキュメントでは、インターネットキーエクスチェンジバージョン2（IKEv2）プロトコルの暗号化ペイロードでのAEADアルゴリズムの使用について説明します。 IKEv2暗号化ペイロードでの2つの特定のAEADアルゴリズムの使用についても説明します。 2つのアルゴリズムは、ガロア/カウンターモードのAdvanced Encryption Standard（AES）（AES GCM）[GCM]とCBC-MACモードのカウンターのAES（AES CCM）[CCM]です。
Version 1 of the Internet Key Exchange protocol (IKEv1) [RFC2409] is based on the Internet Security Association and Key Management Protocol (ISAKMP) [RFC2408]. The E (Encryption) bit in the ISAKMP header specifies that all payloads following the header are encrypted, but any data integrity verification of those payloads is handled by a separate Hash Payload or Signature Payload (see Sections 3.1, 3.11, and 3.12 of [RFC2408]). This separation of encryption from data integrity protection prevents the use of authenticated encryption with IKEv1, thus limiting initial specifications of AES combined mode usage for IPsec to the Encapsulating Security Payload (ESP) [RFC2406]. The current version of ESP is version 3, ESPv3 [RFC4303].
バージョン1のインターネットキー交換プロトコル（IKEv1）[RFC2409]は、インターネットセキュリティアソシエーションおよびキー管理プロトコル（ISAKMP）[RFC2408]に基づいています。 ISAKMPヘッダーのE（暗号化）ビットは、ヘッダーに続くすべてのペイロードが暗号化されることを指定しますが、それらのペイロードのデータ整合性検証は、個別のハッシュペイロードまたは署名ペイロードによって処理されます（[RFC2408のセクション3.1、3.11、3.12を参照] ]）。このように暗号化をデータ整合性保護から分離することで、IKEv1での認証済み暗号化の使用が防止され、IPsecのAES複合モードの使用の初期仕様がカプセル化セキュリティペイロード（ESP）に制限されます[RFC2406]。 ESPの現在のバージョンはバージョン3、ESPv3 [RFC4303]です。
Version 2 of the Internet Key Exchange Protocol (IKEv2) [RFC4306] employs an Encrypted Payload that is based on the design of ESP. The IKEv2 Encrypted Payload associates encryption and data integrity protection in a fashion that makes it possible to use AEAD algorithms.
インターネットキーエクスチェンジプロトコル（IKEv2）のバージョン2 [RFC4306]は、ESPの設計に基づく暗号化されたペイロードを採用しています。 IKEv2暗号化ペイロードは、AEADアルゴリズムの使用を可能にする方法で暗号化とデータ整合性保護を関連付けます。
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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The symbols or variables that designate authenticated encryption and decryption operation inputs and outputs (K, N, P, A, and C) are defined in [RFC5116]. The SK_* symbols or variables that designate specific IKEv2 keys are defined in [RFC4306].
認証された暗号化および復号化操作の入力と出力（K、N、P、A、およびC）を指定するシンボルまたは変数は、[RFC5116]で定義されています。特定のIKEv2キーを指定するSK_ *シンボルまたは変数は、[RFC4306]で定義されています。
This document is based on the RFCs that describe the usage of AES GCM [RFC4106] and AES CCM [RFC4309] with ESP; hence, the introductory material and specification of the modes in those documents are not repeated here. The structure of this document follows the structure of those documents; many sections of this document indicate which sections of those two documents correspond, and call out any significant differences that implementers should be aware of. Significant portions of the text of this document have been adapted from those two documents.
このドキュメントは、ESPでのAES GCM [RFC4106]およびAES CCM [RFC4309]の使用法を説明するRFCに基づいています。したがって、これらのドキュメントの紹介資料およびモードの仕様はここでは繰り返されません。このドキュメントの構造は、これらのドキュメントの構造に従います。このドキュメントの多くのセクションは、これらの2つのドキュメントのどのセクションが対応するかを示し、実装者が知っておくべき重要な違いがあれば説明します。このドキュメントのテキストの重要な部分は、これら2つのドキュメントから改作されています。
This document is based on the authenticated encryption interfaces, notation, and terminology described in [RFC5116]. An important departure from [RFC4106] and [RFC4309] is that these two RFCs describe separate ciphertext and integrity check outputs of the encryption operation, whereas [RFC5116] specifies a single ciphertext (C) output that includes an integrity check. The latter more general approach encompasses authenticated encryption algorithms that produce a single, expanded ciphertext output into which the integrity check is incorporated, rather than producing separate ciphertext and integrity check outputs.
このドキュメントは、[RFC5116]で説明されている認証済みの暗号化インターフェース、表記法、および用語に基づいています。 [RFC4106]および[RFC4309]との重要な違いは、これらの2つのRFCが暗号化操作の個別の暗号文と整合性チェックの出力を記述しているのに対し、[RFC5116]は整合性チェックを含む単一の暗号文（C）出力を指定していることです。後者のより一般的なアプローチは、個別の暗号文と整合性チェックの出力を生成するのではなく、整合性チェックが組み込まれた単一の拡張暗号文出力を生成する認証済み暗号化アルゴリズムを含みます。
For AES GCM and AES CCM, the [RFC5116] ciphertext (C) output of authenticated encryption consists of the [RFC4106] or [RFC4309] ciphertext output concatenated with the [RFC4106] or [RFC4309] Integrity Check Value (ICV) output. This document does not modify the AES GCM or AES CCM authenticated encryption algorithms specified in [RFC4106] and [RFC4309].
AES GCMおよびAES CCMの場合、認証済み暗号化の[RFC5116]暗号文（C）出力は、[RFC4106]または[RFC4309]暗号文出力と[RFC4106]または[RFC4309]整合性チェック値（ICV）出力を連結して構成されます。このドキュメントは、[RFC4106]と[RFC4309]で指定されているAES GCMまたはAES CCM認証の暗号化アルゴリズムを変更しません。
This section is based on [RFC5116] and Section 3.14 of [RFC4306].
このセクションは、[RFC5116]と[RFC4306]のセクション3.14に基づいています。
For the use of authenticated encryption algorithms with the IKEv2 Encrypted Payload, this section updates Section 3.14 of [RFC4306] by replacing Figure 21 and the text that follows it (through the end of that section) with the contents of this section. In addition, Section 3.14 of [RFC4306] is also updated to allow the use of a single authenticated encryption algorithm instead of a block cipher and a separate integrity check algorithm. In contrast, Sections 3.1 and 3.2 of this document are specific to the AES GCM and AES CCM algorithms and hence do not update [RFC4306]. The updates to [RFC4306] made by this document have no effect when authenticated encryption algorithms are neither proposed nor used.
IKEv2暗号化ペイロードで認証された暗号化アルゴリズムを使用する場合、このセクションでは、[RFC4306]のセクション3.14を更新し、図21とそれに続くテキスト（そのセクションの最後まで）をこのセクションの内容に置き換えます。また、[RFC4306]のセクション3.14も更新され、ブロック暗号と個別の整合性チェックアルゴリズムの代わりに、単一の認証済み暗号化アルゴリズムを使用できるようになりました。対照的に、このドキュメントのセクション3.1と3.2は、AES GCMおよびAES CCMアルゴリズムに固有であり、[RFC4306]を更新しません。このドキュメントで行われた[RFC4306]の更新は、認証された暗号化アルゴリズムが提案も使用もされていない場合には効果がありません。
The IKEv2 Encrypted Payload Data structure applies to all
authenticated encryption algorithms, and it is the same structure
that is used with ESP. When an authenticated encryption algorithm is
used, the IKEv2 Encrypted Payload is composed of the payload header
fields, followed by an Initialization Vector (IV) field and a
Ciphertext (C) field that includes an integrity check as shown in
Figure 1.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Initialization Vector !
! (length is specified by authenticated encryption algorithm) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Ciphertext ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. IKEv2 Encrypted Payload Data for Authenticated Encryption
図1.認証された暗号化のためのIKEv2暗号化ペイロードデータ
The Next Payload, C bit, and Payload Length fields are unchanged from [RFC4306].
Next Payload、Cビット、およびPayload Lengthフィールドは[RFC4306]から変更されていません。
The contents of the Initialization Vector (IV) field are specified by the authenticated encryption algorithm; see Sections 3.1 and 4 (below) for AES GCM and AES CCM.
初期化ベクトル（IV）フィールドの内容は、認証された暗号化アルゴリズムによって指定されます。 AES GCMおよびAES CCMについては、セクション3.1および4（下記）を参照してください。
The Ciphertext field is the output of an authenticated encryption operation (see Section 2.1 of [RFC5116]) on the following inputs:
Ciphertextフィールドは、次の入力に対する認証された暗号化操作（[RFC5116]のセクション2.1を参照）の出力です。
o The secret key (K) is the cipher key obtained from the SK_ei or SK_er key, whichever is appropriate, see [RFC4306]. The authenticated encryption algorithm describes how to obtain the cipher key from SK_ei or SK_er; for AES GCM and AES CCM, see Section 7.1 (below).
o 秘密鍵（K）は、SK_eiまたはSK_erのどちらか適切な方から得られた暗号鍵です。[RFC4306]を参照してください。認証された暗号化アルゴリズムは、SK_eiまたはSK_erから暗号鍵を取得する方法を記述します。 AES GCMおよびAES CCMについては、セクション7.1（下記）を参照してください。
o The nonce (N) is specified by the authenticated encryption algorithm; for AES GCM and AES CCM, see Section 4 (below). When decrypting an Encrypted Payload, a receiver constructs the nonce based on the IV in the Encrypted Payload, using rules that are specific to the authenticated encryption algorithm; see Sections 3.1 and 4 (below) for AES GCM and AES CCM.
o ナンス（N）は、認証された暗号化アルゴリズムによって指定されます。 AES GCMおよびAES CCMについては、セクション4（下記）を参照してください。暗号化されたペイロードを復号化するとき、受信者は、認証された暗号化アルゴリズムに固有のルールを使用して、暗号化されたペイロードのIVに基づいてナンスを構築します。 AES GCMおよびAES CCMについては、セクション3.1および4（下記）を参照してください。
o The plaintext (P) consists of the concatenation of the IKE Payloads to be encrypted with the Padding (if any) and the Pad Length, as shown in Figure 2 (below). The plaintext structure in Figure 2 applies to all encryption algorithms used with the IKEv2 Encrypted Payload, and is unchanged from [RFC4306].
o プレーンテキスト（P）は、図2（下）に示すように、パディング（存在する場合）およびパッド長で暗号化されるIKEペイロードの連結で構成されます。図2の平文構造は、IKEv2暗号化ペイロードで使用されるすべての暗号化アルゴリズムに適用され、[RFC4306]から変更されていません。
o The associated data (A) is described in Section 5 (below).
o 関連データ（A）については、セクション5（下記）で説明します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IKE Payloads to be Encrypted ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ! Padding (0-255 octets) !
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
! ! Pad Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. IKEv2 Encrypted Payload Plaintext (P)
図2. IKEv2暗号化ペイロードプレーンテキスト（P）
The IKE Payloads are as specified in [RFC4306].
IKEペイロードは[RFC4306]で指定されています。
Padding MAY contain any value chosen by the sender.
パディングには、送信者が選択した値を含めることができます。
Pad Length is the number of octets in the Padding field. There are no alignment requirements on the length of the Padding field; the recipient MUST accept any amount of Padding up to 255 octets.
Pad Lengthは、Paddingフィールドのオクテット数です。 Paddingフィールドの長さに関する配置要件はありません。受信者は、255オクテットまでの任意の量のパディングを受け入れる必要があります。
The ciphertext output of authenticated encryption algorithms, as defined by [RFC5116], incorporates data that allows checks on the integrity and authenticity of the ciphertext and associated data. Thus, there is no need for a separate Integrity Check Value (ICV) field in the IKEv2 Encrypted Payload Data structure.
[RFC5116]で定義されている認証済み暗号化アルゴリズムの暗号文出力には、暗号文と関連データの整合性と信頼性をチェックできるデータが組み込まれています。したがって、IKEv2暗号化ペイロードデータ構造に個別の整合性チェック値（ICV）フィールドは必要ありません。
This section is based on Section 3.1 of [RFC4106] and Section 3.1 of [RFC4309]. The Initialization Vector requirements are common to AES GCM and AES CCM, and are the same as the requirements for ESP.
このセクションは、[RFC4106]のセクション3.1および[RFC4309]のセクション3.1に基づいています。初期化ベクトルの要件はAES GCMとAES CCMに共通であり、ESPの要件と同じです。
The Initialization Vector (IV) MUST be eight octets. The IV MUST be chosen by the encryptor in a manner that ensures that the same IV value is used only once for a given key. The encryptor MAY generate the IV in any manner that ensures uniqueness. Common approaches to IV generation include incrementing a counter for each packet and linear feedback shift registers (LFSRs).
初期化ベクトル（IV）は8オクテットでなければなりません。 IVは、同じIV値が特定のキーに対して1回だけ使用されることを保証する方法で、暗号化によって選択されなければなりません（MUST）。暗号化機能は、一意性を保証する任意の方法でIVを生成できます（MAY）。 IV生成への一般的なアプローチには、各パケットのカウンターのインクリメントと線形フィードバックシフトレジスタ（LFSR）が含まれます。
This section is based on Section 6 of [RFC4106] and Section 3.1 of [RFC4309] with generalizations to match the interfaces specified in [RFC5116]. The constructions for AES GCM and AES CCM are different, but in each case, the construction is the same as for ESP.
このセクションは、[RFC4106]のセクション6と[RFC4309]のセクション3.1に基づいており、[RFC5116]で指定されているインターフェースと一致するように一般化されています。 AES GCMとAES CCMの構成は異なりますが、どちらの場合もESPの構成と同じです。
For AES GCM and AES CCM, the Ciphertext field consists of the output of the authenticated encryption algorithm. (Note that this field incorporates integrity check data.)
AES GCMおよびAES CCMの場合、Ciphertextフィールドは、認証された暗号化アルゴリズムの出力で構成されます。 （このフィールドには整合性チェックデータが組み込まれていることに注意してください。）
The AES GCM ICV consists solely of the AES GCM Authentication Tag. Implementations MUST support a full-length 16 octet ICV, MAY support 8 or 12 octet ICVs, and MUST NOT support other ICV lengths.
AES GCM ICVは、AES GCM認証タグのみで構成されています。実装は、フルレングスの16オクテットICVをサポートする必要があり、8または12オクテットのICVをサポートする場合があり、他のICV長をサポートしてはならない（MUST NOT）。
AES CCM provides an encrypted ICV. Implementations MUST support ICV sizes of 8 octets and 16 octets. Implementations MAY also support 12 octet ICVs and MUST NOT support other ICV lengths.
AES CCMは暗号化されたICVを提供します。実装では、8オクテットと16オクテットのICVサイズをサポートする必要があります。実装は、12オクテットのICVもサポートする場合があり、他のICVの長さをサポートしてはならない（MUST NOT）。
Specific authenticated encryption algorithms MAY use different nonce formats, but they SHOULD use the default nonce format specified in this section.
特定の認証済み暗号化アルゴリズムは異なるノンスフォーマットを使用する場合がありますが、このセクションで指定されているデフォルトのノンスフォーマットを使用する必要があります（SHOULD）。
The default nonce format uses partially implicit nonces (see Section 3.2.1 of [RFC5116]) as follows:
デフォルトのnonce形式は、次のように部分的に暗黙のnonce（[RFC5116]のセクション3.2.1を参照）を使用します。
o The implicit portion of the nonce is the salt that is part of the IKEv2 Keying Material shared by the encryptor and decryptor (see Section 7.1); the salt is not included in the IKEv2 Encrypted Payload.
o nonceの暗黙の部分は、暗号化機能と復号化機能（セクション7.1を参照）が共有するIKEv2 Keying Materialの一部であるソルトです。ソルトはIKEv2暗号化ペイロードに含まれていません。
o The explicit portion of the nonce is the IV that is included in the IKEv2 Encrypted Payload.
o nonceの明示的な部分は、IKEv2暗号化ペイロードに含まれるIVです。
When this default nonce format is used, both the encryptor and decryptor construct the nonce by concatenating the salt with the IV, in that order.
このデフォルトのnonce形式が使用される場合、暗号化機能と復号化機能の両方が、ソルトをIVとこの順序で連結してnonceを構築します。
For the use of AES GCM with the IKEv2 Encrypted Payload, this default nonce format MUST be used and a 12 octet nonce MUST be used. Note that this format matches the one specified in Section 4 of [RFC4106], providing compatibility between the use of AES GCM in IKEv2 and ESP. All of the requirements of Section 4 of [RFC4106] apply to the use of AES GCM with the IKEv2 Encrypted Payload.
IKEv2暗号化ペイロードでAES GCMを使用するには、このデフォルトのノンスフォーマットを使用する必要があり、12オクテットナンスを使用する必要があります。この形式は[RFC4106]のセクション4で指定されている形式と一致し、IKEv2でのAES GCMの使用とESPの使用の間に互換性があることに注意してください。 [RFC4106]のセクション4のすべての要件は、IKEv2暗号化ペイロードでのAES GCMの使用に適用されます。
For the use of AES CCM with the IKEv2 Encrypted Payload, this default nonce format MUST be used and an 11 octet nonce MUST be used. Note that this format matches the one specified in Section 4 of [RFC4309], providing compatibility between the use of AES CCM in IKEv2 and ESP. All of the requirements of Section 4 of [RFC4309] apply to the use of AES CCM with the IKEv2 Encrypted Payload.
IKEv2暗号化ペイロードでAES CCMを使用するには、このデフォルトのノンスフォーマットを使用する必要があり、11オクテットナンスを使用する必要があります。この形式は[RFC4309]のセクション4で指定された形式と一致し、IKEv2でのAES CCMの使用とESPの使用との互換性を提供することに注意してください。 [RFC4309]のセクション4のすべての要件は、IKEv2暗号化ペイロードでのAES CCMの使用に適用されます。
This section is based on Section 5 of [RFC4106] and Section 5 of [RFC4309], both of which refer to associated data as Additional Authenticated Data (AAD). The associated data construction described in this section applies to all authenticated encryption algorithms, but differs from the construction used with ESP because IKEv2 requires different data integrity coverage.
このセクションは、[RFC4106]のセクション5と[RFC4309]のセクション5に基づいています。どちらも、関連するデータを追加認証データ（AAD）と呼んでいます。このセクションで説明する関連するデータ構造は、すべての認証済み暗号化アルゴリズムに適用されますが、IKEv2は異なるデータ整合性カバレッジを必要とするため、ESPで使用される構造とは異なります。
The associated data (A) MUST consist of the partial contents of the IKEv2 message, starting from the first octet of the Fixed IKE Header through the last octet of the Payload Header of the Encrypted Payload (i.e., the fourth octet of the Encrypted Payload), as shown in Figure 3. This includes any payloads that are between the Fixed IKE Header and the Encrypted Payload.
関連データ（A）は、固定IKEヘッダーの最初のオクテットから暗号化ペイロードのペイロードヘッダーの最後のオクテット（つまり、暗号化ペイロードの4番目のオクテット）までのIKEv2メッセージの部分的なコンテンツで構成する必要があります。 、図3に示すように、これには、固定IKEヘッダーと暗号化されたペイロードの間にあるペイロードが含まれます。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IKEv2 Header ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Unencrypted IKE Payloads ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. IKEv2 Encrypted Payload Associated Data (A) for Authenticated Encryption
図3.認証された暗号化のためのIKEv2暗号化ペイロード関連データ（A）
The Initialization Vector and Ciphertext fields shown in Figure 1 (above) MUST NOT be included in the associated data.
図1（上記）に示されている初期化ベクトルおよび暗号文フィールドは、関連するデータに含めてはなりません（MUST NOT）。
The data integrity coverage of the IKEv2 Encrypted Payload encompasses the entire IKEv2 message that contains the Encrypted Payload. When an authenticated encryption algorithm is used with the Encrypted Payload, this coverage is realized as follows:
IKEv2暗号化ペイロードのデータ整合性の範囲には、暗号化ペイロードを含むIKEv2メッセージ全体が含まれます。認証された暗号化アルゴリズムが暗号化されたペイロードとともに使用される場合、このカバレッジは次のように実現されます。
1. The associated data (A) covers the portion of the IKEv2 message starting from the first octet of the Fixed IKE Header through the last octet of the Payload Header of the Encrypted Payload (fourth octet of the Encrypted Payload). This includes any Payloads between the Fixed IKE Header and the Encrypted Payload. The Encrypted Payload is always the last payload in an IKEv2 message [RFC4306].
1. 関連データ（A）は、固定IKEヘッダーの最初のオクテットから暗号化ペイロードのペイロードヘッダーの最後のオクテット（暗号化ペイロードの4番目のオクテット）までのIKEv2メッセージの部分をカバーしています。これには、固定IKEヘッダーと暗号化されたペイロードの間のペイロードが含まれます。暗号化されたペイロードは、常にIKEv2メッセージ[RFC4306]の最後のペイロードです。
2. The IV is an input to the authenticated encryption algorithm's integrity check. A successful integrity check at the receiver verifies that the correct IV was used, providing data integrity coverage for the IV.
2. IVは、認証された暗号化アルゴリズムの整合性チェックへの入力です。受信側での整合性チェックが成功すると、正しいIVが使用されていることが確認され、IVのデータ整合性が保証されます。
3. The plaintext (IKE Payloads, Padding and Pad Length) is covered by the authenticated encryption algorithm's integrity check.
3. 平文（IKEペイロード、パディング、パッド長）は、認証された暗号化アルゴリズムの整合性チェックによってカバーされます。
The expansion described in Section 7 of [RFC4106] and Section 6 of [RFC4309] applies to the use of the AES GCM and AES CCM combined modes with the IKEv2 Encrypted Payload. See Section 7 of [RFC4106] and Section 6 of [RFC4309].
[RFC4106]のセクション7と[RFC4309]のセクション6で説明されている拡張は、IKEv2暗号化ペイロードでのAES GCMとAES CCMの複合モードの使用に適用されます。 [RFC4106]のセクション7と[RFC4309]のセクション6を参照してください。
This section describes the conventions used to generate keying material and salt values for use with AES GCM and AES CCM using the IKEv2 [RFC4306] protocol. The identifiers and attributes needed to use AES GCM and AES CCM with the IKEv2 Encrypted Payload are also specified.
このセクションでは、IKEv2 [RFC4306]プロトコルを使用してAES GCMおよびAES CCMで使用するための鍵情報とソルト値を生成するために使用される規則について説明します。 IKEv2暗号化ペイロードでAES GCMおよびAES CCMを使用するために必要な識別子と属性も指定されています。
This section is based on Section 8.1 of [RFC4106] and Section 7.1 of [RFC4309]. The Keying Material and Salt Values for AES GCM and AES CCM are different, but have the same structure as the Keying Material and Salt Values used with ESP.
このセクションは、[RFC4106]のセクション8.1および[RFC4309]のセクション7.1に基づいています。 AES GCMとAES CCMのキー素材とソルト値は異なりますが、ESPで使用されるキー素材とソルト値と同じ構造です。
IKEv2 makes use of a Pseudo-Random Function (PRF) to derive keying material. The PRF is used iteratively to derive keying material of arbitrary size, from which keying material for specific uses is extracted without regard to PRF output boundaries; see Section 2.14 of [RFC4306].
IKEv2は、疑似ランダム関数（PRF）を使用して、キー情報を導出します。 PRFは反復的に使用され、任意のサイズの鍵情報を導出します。そこから、PRF出力境界に関係なく、特定の用途の鍵情報が抽出されます。 [RFC4306]のセクション2.14を参照してください。
This subsection describes how the key derivation specified in Section 2.14 of [RFC4306] is used to obtain keying material for AES GCM and AES CCM. When AES GCM or AES CCM is used with the IKEv2 Encrypted Payload, the SK_ai and SK_ar integrity protection keys are not used; each key MUST be treated as having a size of zero (0) octets. The size of each of the SK_ei and SK_er encryption keys includes additional salt bytes. The size and format of each of the SK_ei and SK_er encryption keys MUST be:
このサブセクションでは、[RFC4306]のセクション2.14で指定された鍵の派生を使用して、AES GCMおよびAES CCMの鍵情報を取得する方法について説明します。 AES GCMまたはAES CCMがIKEv2暗号化ペイロードとともに使用される場合、SK_aiおよびSK_ar整合性保護キーは使用されません。各キーはゼロ（0）オクテットのサイズを持つものとして扱われなければなりません（MUST）。 SK_eiおよびSK_er暗号化キーのそれぞれのサイズには、追加のソルトバイトが含まれます。 SK_eiおよびSK_er暗号化キーのそれぞれのサイズとフォーマットは、次のようにする必要があります。
o For AES GCM, each encryption key has the size and format of the "KEYMAT requested" material specified in Section 8.1 of [RFC4106] for the AES key size being used. For example, if the AES key size is 128 bits, each encryption key is 20 octets, consisting of a 16-octet AES cipher key followed by 4 octets of salt.
o AES GCMの場合、各暗号化キーには、使用されるAESキーサイズについて[RFC4106]のセクション8.1で指定された「KEYMATリクエスト済み」マテリアルのサイズとフォーマットが含まれますたとえば、AESキーのサイズが128ビットの場合、各暗号化キーは16オクテットのAES暗号キーとそれに続く4オクテットのソルトで構成される20オクテットです。
o For AES CCM, each key has the size and format of the "KEYMAT requested" material specified in Section 7.1 of [RFC4309] for the AES key size being used. For example, if the AES key size is 128 bits, each encryption key is 19 octets, consisting of a 16-octet AES cipher key followed by 3 octets of salt.
o AES CCMの場合、各キーには、[RFC4309]のセクション7.1で指定されている「KEYMATリクエスト済み」の素材のサイズとフォーマットが使用されているAESキーのサイズに対応しています。たとえば、AESキーのサイズが128ビットの場合、各暗号化キーは19オクテットで、16オクテットのAES暗号キーとそれに続く3オクテットのソルトで構成されます。
This section is unique to the IKEv2 Encrypted Payload usage of AES GCM and AES CCM. It reuses the identifiers used to negotiate ESP usage of AES GCM and AES CCM.
このセクションは、AES GCMおよびAES CCMのIKEv2暗号化ペイロードの使用に固有のものです。 AES GCMとAES CCMのESP使用をネゴシエートするために使用される識別子を再利用します。
The following identifiers, previously allocated by IANA, are used to negotiate the use of AES GCM and AES CCM as the Encryption (ENCR) Transform for IKEv2 (i.e., for use with the IKEv2 Encrypted Payload):
IANAによって以前に割り当てられた次の識別子は、IKEv2の暗号化（ENCR）変換としてのAES GCMおよびAES CCMの使用を交渉するために使用されます（つまり、IKEv2暗号化ペイロードで使用するため）。
14 for AES CCM with an 8-octet ICV;
15 for AES CCM with a 12-octet ICV;
16 for AES CCM with a 16-octet ICV;
18 for AES GCM with an 8-octet ICV; 19 for AES GCM with a 12-octet ICV; and 20 for AES GCM with a 16-octet ICV.
8オクテットICVのAES GCMの場合は18。 12オクテットICVのAES GCMの場合は19。 16オクテットのICVを備えたAES GCMの場合は20。
A 16-octet ICV size SHOULD be used with IKEv2, as the higher level of security that it provides by comparison to smaller ICV sizes is appropriate to IKEv2's key exchange and related functionality.
16オクテットのICVサイズは、IKEv2で使用する必要があります。これは、小さいICVサイズと比較して提供されるより高いレベルのセキュリティが、IKEv2のキー交換および関連機能に適しているためです。
In general, the use of 12-octet ICVs (values 15 and 19) is NOT RECOMMENDED in order to reduce the number of options for ICV size. If an ICV size larger than 8 octets is appropriate, 16-octet ICVs SHOULD be used.
一般に、ICVサイズのオプションの数を減らすために、12オクテットのICV（値15および19）の使用は推奨されません。 8オクテットより大きいICVサイズが適切な場合、16オクテットのICVを使用する必要があります（SHOULD）。
This section is based on Section 8.4 of [RFC4106] and Section 7.4 of [RFC4309]. The Key Length requirements are common to AES GCM and AES CCM and are identical to the key length requirements for ESP.
このセクションは、[RFC4106]のセクション8.4および[RFC4309]のセクション7.4に基づいています。キー長の要件はAES GCMとAES CCMに共通であり、ESPのキー長の要件と同じです。
Because the AES supports three key lengths, the Key Length attribute MUST be specified when any of the identifiers for AES GCM or AES CCM, specified in Section 7.2 of this document, is used. The Key Length attribute MUST have a value of 128, 192, or 256. The use of the value 192 is NOT RECOMMENDED. If an AES key larger than 128 bits is appropriate, a 256-bit AES key SHOULD be used. This reduces the number of options for AES key length.
AESは3つのキー長をサポートするため、このドキュメントのセクション7.2で指定されているAES GCMまたはAES CCMのいずれかの識別子を使用する場合は、キー長属性を指定する必要があります。キーの長さ属性には、128、192、または256の値が必要です。値192の使用は推奨されません。 128ビットより大きいAESキーが適切な場合は、256ビットのAESキーを使用する必要があります（SHOULD）。これにより、AESキーの長さのオプションの数が減ります。
This section applies to the use of any authenticated encryption algorithm with the IKEv2 Encrypted Payload and is unique to that usage.
このセクションは、IKEv2暗号化ペイロードでの認証済み暗号化アルゴリズムの使用に適用され、その使用に固有です。
IKEv2 (Section 3.3.3 of [RFC4306]) specifies that both an encryption algorithm and an integrity checking algorithm are required for an IKE SA (Security Association). This document updates [RFC4306] to require that when an authenticated encryption algorithm is selected as the encryption algorithm for any SA (IKE or ESP), an integrity algorithm MUST NOT be selected for that SA. This document further updates [RFC4306] to require that if all of the encryption algorithms in any proposal are authenticated encryption algorithms, then the proposal MUST NOT propose any integrity transforms.
IKEv2（[RFC4306]のセクション3.3.3）では、IKE SA（セキュリティアソシエーション）に暗号化アルゴリズムと整合性チェックアルゴリズムの両方が必要であることを指定しています。このドキュメントでは、[RFC4306]を更新して、認証された暗号化アルゴリズムがSA（IKEまたはESP）の暗号化アルゴリズムとして選択されている場合、そのSAに対して整合性アルゴリズムを選択してはならない（MUST NOT）ようにしています。このドキュメントはさらに、[RFC4306]を更新して、提案内のすべての暗号化アルゴリズムが認証済み暗号化アルゴリズムである場合、提案は整合性変換を提案してはならないことを要求します。
See Section 9 of [RFC4106] and Section 8 of [RFC4309] for references that provide AES GCM and AES CCM test vectors.
AES GCMおよびAES CCMテストベクトルを提供するリファレンスについては、[RFC4106]のセクション9および[RFC4309]のセクション8を参照してください。
This section adds new algorithms to the AEAD_* algorithm framework defined in [RFC5116] to encompass the usage of AES GCM and AES CCM with IKEv2. An AEAD_* algorithm does not have any attributes or parameters; each AEAD_* algorithm identifier defined in this document completely specifies the AES key size and the ICV size to be used (e.g., AEAD_AES_128_GCM uses a 128-bit AES key and a 16-octet ICV).
このセクションでは、[RFC5116]で定義されているAEAD_ *アルゴリズムフレームワークに新しいアルゴリズムを追加して、IKEv2でのAES GCMおよびAES CCMの使用を網羅します。 AEAD_ *アルゴリズムには、属性やパラメーターはありません。このドキュメントで定義されている各AEAD_ *アルゴリズム識別子は、使用するAESキーサイズとICVサイズを完全に指定します（たとえば、AEAD_AES_128_GCMは128ビットAESキーと16オクテットICVを使用します）。
AEAD_* algorithm coverage of the AES GCM and AES CCM authenticated encryption algorithms used with IKEv2 requires specification of eight additional AEAD_* algorithms beyond the four algorithms specified in [RFC5116]:
IKEv2で使用されるAES GCMおよびAES CCM認証の暗号化アルゴリズムのAEAD_ *アルゴリズムカバレッジでは、[RFC5116]で指定されている4つのアルゴリズムに加えて、8つの追加のAEAD_ *アルゴリズムを指定する必要があります。
o Four AEAD_* algorithms are specified to allow 8- and 12-octet ICVs to be used with the AES GCM and AEAD_* algorithms specified in [RFC5116].
o [RFC5116]で指定されているAES GCMおよびAEAD_ *アルゴリズムで8オクテットと12オクテットのICVを使用できるように、4つのAEAD_ *アルゴリズムが指定されています。
o The version of AES CCM used with IPsec (see [RFC4309]) uses an 11-octet nonce instead of the 12-octet nonce used by the version of AES CCM specified in [RFC5116]. Six AEAD_* algorithms are specified for this short nonce version of AES CCM.
o IPsecで使用されるAES CCMのバージョン（[RFC4309]を参照）は、[RFC5116]で指定されたバージョンのAES CCMで使用される12オクテットナンスの代わりに11オクテットナンスを使用します。この短いノンスバージョンのAES CCMには、6つのAEAD_ *アルゴリズムが指定されています。
This document recommends against the use of 192-bit AES keys, and therefore does not specify AEAD_* algorithms for 192-bit AES keys.
このドキュメントでは、192ビットAESキーの使用を推奨していないため、192ビットAESキーのAEAD_ *アルゴリズムを指定していません。
The following four AEAD_* algorithms are identical to the AEAD_* algorithms specified in [RFC5116], except that an 8-octet ICV is used instead of a 16-octet ICV.
次の4つのAEAD_ *アルゴリズムは、[RFC5116]で指定されているAEAD_ *アルゴリズムと同じですが、16オクテットICVの代わりに8オクテットICVが使用されます。
This algorithm is identical to AEAD_AES_128_GCM (see Section 5.1 of [RFC5116]), except that the tag length, t, is 8, and an authentication tag with a length of 8 octets (64 bits) is used.
このアルゴリズムはAEAD_AES_128_GCM（[RFC5116]のセクション5.1を参照）と同じですが、タグ長tが8であり、長さが8オクテット（64ビット）の認証タグが使用される点が異なります。
An AEAD_AES_128_GCM_8 ciphertext is exactly 8 octets longer than its corresponding plaintext.
AEAD_AES_128_GCM_8暗号文は、対応する平文よりも正確に8オクテット長くなります。
This algorithm is identical to AEAD_AES_256_GCM (see Section 5.2 of [RFC5116]), except that the tag length, t, is 8, and an authentication tag with a length of 8 octets (64 bits) is used.
このアルゴリズムはAEAD_AES_256_GCM（[RFC5116]のセクション5.2を参照）と同じですが、タグの長さtが8であり、長さが8オクテット（64ビット）の認証タグが使用される点が異なります。
An AEAD_AES_256_GCM_8 ciphertext is exactly 8 octets longer than its corresponding plaintext.
AEAD_AES_256_GCM_8暗号文は、対応する平文よりも正確に8オクテット長くなります。
This algorithm is identical to AEAD_AES_128_GCM (see Section 5.1 of [RFC5116]), except that the tag length, t, is 12, and an authentication tag with a length of 12 octets (64 bits) is used.
このアルゴリズムはAEAD_AES_128_GCM（[RFC5116]のセクション5.1を参照）と同じですが、タグの長さtが12であり、長さが12オクテット（64ビット）の認証タグが使用される点が異なります。
An AEAD_AES_128_GCM_12 ciphertext is exactly 12 octets longer than its corresponding plaintext.
AEAD_AES_128_GCM_12暗号文は、対応する平文よりも正確に12オクテット長くなります。
This algorithm is identical to AEAD_AES_256_GCM (see Section 5.2 of [RFC5116], except that the tag length, t, is 12 and an authentication tag with a length of 12 octets (64 bits) is used.
このアルゴリズムはAEAD_AES_256_GCMと同じです（[RFC5116]のセクション5.2を参照）。ただし、タグの長さtは12であり、長さが12オクテット（64ビット）の認証タグが使用されます。
An AEAD_AES_256_GCM_12 ciphertext is exactly 12 octets longer than its corresponding plaintext.
AEAD_AES_256_GCM_12暗号文は、対応する平文よりも正確に12オクテット長くなります。
The following four AEAD algorithms employ the AES CCM algorithms with an 11 octet nonce as specified in [RFC4309].
次の4つのAEADアルゴリズムは、[RFC4309]で指定されているように、11オクテットのナンスを持つAES CCMアルゴリズムを採用しています。
The AEAD_AES_128_CCM_SHORT authenticated encryption algorithm is identical to the AEAD_AES_128_CCM algorithm (see Section 5.3 of [RFC5116]), except that it uses a nonce that is one octet shorter. AEAD_AES_128_CCM_SHORT works as specified in [CCM]. It uses AES-128 as the block cipher by providing the key, nonce, associated data, and plaintext to that mode of operation. The formatting and counter generation function are as specified in Appendix A of [CCM], and the values of the parameters identified in that appendix are as follows:
AEAD_AES_128_CCM_SHORT認証済み暗号化アルゴリズムは、AEAD_AES_128_CCMアルゴリズム（[RFC5116]のセクション5.3を参照）と同じですが、1オクテット短いノンスを使用します。 AEAD_AES_128_CCM_SHORTは、[CCM]の指定どおりに機能します。その動作モードにキー、ノンス、関連データ、プレーンテキストを提供することにより、ブロック暗号としてAES-128を使用します。フォーマットおよびカウンター生成関数は、[CCM]の付録Aで指定されているとおりであり、その付録で識別されているパラメーターの値は次のとおりです。
the nonce length n is 11,
ノンス長nは11
the tag length t is 16, and
タグの長さtは16であり、
the value of q is 3.
qの値は3です。
An authentication tag with a length of 16 octets (128 bits) is used. The AEAD_AES_128_CCM_SHORT ciphertext consists of the ciphertext output of the CCM encryption operation concatenated with the authentication tag output of the CCM encryption operation. Test cases are provided in [CCM]. The input and output lengths are as follows:
16オクテット（128ビット）の長さの認証タグが使用されます。 AEAD_AES_128_CCM_SHORT暗号文は、CCM暗号化操作の認証テキスト出力と連結されたCCM暗号化操作の暗号文出力で構成されます。テストケースは[CCM]で提供されます。入力と出力の長さは次のとおりです。
K_LEN is 16 octets,
K_LENは16オクテットです。
P_MAX is 2^24 - 1 octets,
P_MAXは2 ^ 24-1オクテット、
A_MAX is 2^64 - 1 octets,
A_MAXは2 ^ 64-1オクテット、
N_MIN and N_MAX are both 11 octets, and
N_MINとN_MAXはどちらも11オクテットであり、
C_MAX is 2^24 + 15 octets.
C_MAXは2 ^ 24 + 15オクテットです。
An AEAD_AES_128_CCM_SHORT ciphertext is exactly 16 octets longer than its corresponding plaintext.
AEAD_AES_128_CCM_SHORT暗号文は、対応する平文よりも正確に16オクテット長くなります。
This algorithm is identical to AEAD_AES_128_CCM_SHORT, but with the following differences:
このアルゴリズムはAEAD_AES_128_CCM_SHORTと同じですが、次の点が異なります。
K_LEN is 32 octets, instead of 16, and
K_LENは16ではなく32オクテットであり、
AES-256 CCM is used instead of AES-128 CCM.
AES-128 CCMの代わりにAES-256 CCMが使用されます。
An AEAD_AES_256_CCM_SHORT ciphertext is exactly 16 octets longer than its corresponding plaintext.
AEAD_AES_256_CCM_SHORT暗号文は、対応する平文よりも正確に16オクテット長くなります。
This algorithm is identical to AEAD_AES_128_CCM_SHORT, except that the tag length, t, is 8, and an authentication tag with a length of 8 octets (64 bits) is used.
このアルゴリズムはAEAD_AES_128_CCM_SHORTと同じですが、タグの長さtが8であり、長さが8オクテット（64ビット）の認証タグが使用される点が異なります。
An AEAD_AES_128_CCM_SHORT_8 ciphertext is exactly 8 octets longer than its corresponding plaintext.
AEAD_AES_128_CCM_SHORT_8暗号文は、対応する平文よりも正確に8オクテット長くなります。
This algorithm is identical to AEAD_AES_256_CCM_SHORT, except that the tag length, t, is 8, and an authentication tag with a length of 8 octets (64 bits) is used.
このアルゴリズムは、タグ長tが8であり、長さが8オクテット（64ビット）の認証タグが使用されることを除いて、AEAD_AES_256_CCM_SHORTと同じです。
An AEAD_AES_256_CCM_SHORT_8 ciphertext is exactly 8 octets longer than its corresponding plaintext.
AEAD_AES_256_CCM_SHORT_8暗号文は、対応する平文よりも正確に8オクテット長くなります。
This algorithm is identical to AEAD_AES_128_CCM_SHORT, except that the tag length, t, is 12, and an authentication tag with a length of 12 octets (64 bits) is used.
このアルゴリズムは、タグ長tが12であり、長さが12オクテット（64ビット）の認証タグが使用されることを除いて、AEAD_AES_128_CCM_SHORTと同じです。
An AEAD_AES_128_CCM_SHORT_12 ciphertext is exactly 12 octets longer than its corresponding plaintext.
AEAD_AES_128_CCM_SHORT_12暗号文は、対応する平文よりも正確に12オクテット長くなります。
This algorithm is identical to AEAD_AES_256_CCM_SHORT, except that the tag length, t, is 12, and an authentication tag with a length of 8 octets (64 bits) is used.
このアルゴリズムはAEAD_AES_256_CCM_SHORTと同じですが、タグの長さtが12であり、長さが8オクテット（64ビット）の認証タグが使用される点が異なります。
An AEAD_AES_256_CCM_SHORT_12 ciphertext is exactly 12 octets longer than its corresponding plaintext.
AEAD_AES_256_CCM_SHORT_12暗号文は、対応する平文よりも正確に12オクテット長くなります。
The following table lists the AES CCM and AES GCM AEAD_* algorithms that can be negotiated by IKEv2 and provides the IKEv2 Encryption (ENCR) Transform Identifier and Key Length Attribute combination that is used to negotiate each algorithm.
次の表に、IKEv2でネゴシエートできるAES CCMおよびAES GCM AEAD_ *アルゴリズムをリストし、各アルゴリズムのネゴシエーションに使用されるIKEv2暗号化（ENCR）変換識別子とキー長属性の組み合わせを示します。
+--------------------------+------------------+-------------+
| AEAD algorithm | ENCR Identifier | Key Length |
+--------------------------+------------------+-------------+
| AEAD_AES_128_GCM | 20 | 128 |
| AEAD_AES_256_GCM | 20 | 256 |
| AEAD_AES_128_GCM_8 | 18 | 128 |
| AEAD_AES_256_GCM_8 | 18 | 256 |
| AEAD_AES_128_GCM_12 | 19 | 128 |
| AEAD_AES_256_GCM_12 | 19 | 256 |
| AEAD_AES_128_CCM_SHORT | 16 | 128 |
| AEAD_AES_256_CCM_SHORT | 16 | 256 |
| AEAD_AES_128_CCM_SHORT_8 | 14 | 128 |
| AEAD_AES_256_CCM_SHORT_8 | 14 | 256 |
| AEAD_AES_128_CCM_SHORT_12| 15 | 128 |
| AEAD_AES_256_CCM_SHORT_12| 15 | 256 |
+--------------------------+------------------+-------------+
Each of the above AEAD_* algorithms is identical to the algorithm designated by the combination of the IKEv2 ENCR Identifier and Key Length Attribute shown on the same line of the table.
上記の各AEAD_ *アルゴリズムは、表の同じ行に表示されているIKEv2 ENCR識別子とキー長属性の組み合わせで指定されたアルゴリズムと同じです。
For authenticated encryption security considerations, see the entirety of [RFC5116], not just its security considerations section; there are important security considerations that are discussed outside the security considerations section of that document.
認証された暗号化のセキュリティに関する考慮事項については、[RFC5116]の全体を参照してください。セキュリティに関する考慮事項のセクションだけではありません。そのドキュメントのセキュリティに関する考慮事項のセクション外で説明されている重要なセキュリティに関する考慮事項があります。
The security considerations for the use of AES GCM and AES CCM with ESP apply to the use of these algorithms with the IKEv2 Encrypted Payload, see Section 10 of [RFC4106] and Section 9 of [RFC4309]. Use of AES GCM and AES CCM with IKEv2 does not create additional security considerations beyond those for the use of AES GCM and AES CCM with ESP.
AES GCMおよびESPでのAES CCMの使用に関するセキュリティ上の考慮事項は、IKEv2暗号化ペイロードでのこれらのアルゴリズムの使用に適用されます。[RFC4106]のセクション10および[RFC4309]のセクション9を参照してください。 IKEv2でAES GCMおよびAES CCMを使用しても、ESPでAES GCMおよびAES CCMを使用する場合を超えるセキュリティ上の考慮事項は作成されません。
For IKEv2 security considerations, see Section 5 of [RFC4306].
IKEv2のセキュリティに関する考慮事項については、[RFC4306]のセクション5をご覧ください。
The Encryption Transform identifiers specified in Section 7.2 have been previously assigned by IANA for use with ESP. This document extends their usage to IKEv2 for the Encrypted Payload. No IANA actions are required for this usage extension.
セクション7.2で指定された暗号化変換識別子は、ESAで使用するためにIANAによって以前に割り当てられています。このドキュメントでは、暗号化ペイロードの使用をIKEv2に拡張しています。この使用法の拡張にIANAアクションは必要ありません。
IANA has added the following entries to the Authenticated Encryption with Associated Data (AEAD) Parameters Registry:
IANAは、関連データを伴う認証済み暗号化（AEAD）パラメータレジストリに次のエントリを追加しました。
+--------------------------+----------------+--------------------+
| Name | Reference | Numeric Identifier |
+--------------------------+----------------+--------------------+
| AEAD_AES_128_GCM_8 | Section 10.1.1 | 5 |
| AEAD_AES_256_GCM_8 | Section 10.1.2 | 6 |
| AEAD_AES_128_GCM_12 | Section 10.1.3 | 7 |
| AEAD_AES_256_GCM_12 | Section 10.1.4 | 8 |
| AEAD_AES_128_CCM_SHORT | Section 10.2.1 | 9 |
| AEAD_AES_256_CCM_SHORT | Section 10.2.2 | 10 |
| AEAD_AES_128_CCM_SHORT_8 | Section 10.2.3 | 11 |
| AEAD_AES_256_CCM_SHORT_8 | Section 10.2.4 | 12 |
| AEAD_AES_128_CCM_SHORT_12| Section 10.2.5 | 13 |
| AEAD_AES_256_CCM_SHORT_12| Section 10.2.6 | 14 |
+--------------------------+----------------+--------------------+
An IANA registration of an AEAD algorithm does not constitute an endorsement of that algorithm or its security.
AEADアルゴリズムのIANA登録は、そのアルゴリズムまたはそのセキュリティの推奨を構成するものではありません。
See Section 13 of [RFC4106] and Section 12 of [RFC4309] for AES GCM and AES CCM acknowledgments.
AES GCMとAES CCMの承認については、[RFC4106]のセクション13と[RFC4309]のセクション12を参照してください。
Also, we thank Charlie Kaufman, Pasi Eronen, Tero Kivinen, Steve Kent, and Alfred Hoenes for their comprehensive reviews of this document.
また、このドキュメントの包括的なレビューを提供してくれたCharlie Kaufman、Pasi Eronen、Tero Kivinen、Steve Kent、およびAlfred Hoenesにも感謝します。
This document was originally prepared using 2-Word-v2.0.template.dot, created by Joe Touch.
このドキュメントは、ジョータッチが作成した2-Word-v2.0.template.dotを使用して最初に作成されました。
[CCM] Dworkin, M., "NIST Special Publication 800-38C: The CCM Mode for Authentication and Confidentiality", U.S. National Institute of Standards and Technology, <http://csrc.nist.gov/publications/nistpubs/800-38C/ SP800-38C.pdf>, updated July 2007.
[CCM] Dworkin、M。、「NIST Special Publication 800-38C：The CCM Mode for Authentication and Confidentiality」、米国国立標準技術研究所、<http://csrc.nist.gov/publications/nistpubs/800- 38C / SP800-38C.pdf>、2007年7月更新。
[GCM] Dworkin, M., "NIST Special Publication 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.", U.S. National Institute of Standards and Technology, November 2007, <http://csrc.nist.gov/publications/nistpubs/800-38D/ SP-800-38D.pdf>, November 2007.
[GCM] Dworkin、M。、「NIST Special Publication 800-38D：Recommendation for Block Cipher Modes of Operation：Galois / Counter Mode（GCM）and GMAC。」、米国国立標準技術研究所、2007年11月、<http： //csrc.nist.gov/publications/nistpubs/800-38D/ SP-800-38D.pdf>、2007年11月。
[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月。
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005.
[RFC4106] Viega、J。およびD. McGrew、「The Use of Galois / Counter Mode（GCM）in IPsec Encapsulating Security Payload（ESP）」、RFC 4106、2005年6月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C。、編、「インターネットキーエクスチェンジ（IKEv2）プロトコル」、RFC 4306、2005年12月。
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, December 2005.
[RFC4309] Housley、R。、「IPsecカプセル化セキュリティペイロード（ESP）でのAdvanced Encryption Standard（AES）CCMモードの使用」、RFC 4309、2005年12月。
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, January 2008.
[RFC5116] McGrew、D。、「認証された暗号化のためのインターフェースとアルゴリズム」、RFC 5116、2008年1月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケント、S。、およびR.アトキンソン、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[RFC2408] Maughan、D.、Schertler、M.、Schneider、M。、およびJ. Turner、「Internet Security Association and Key Management Protocol（ISAKMP）」、RFC 2408、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D。およびD. Carrel、「インターネットキーエクスチェンジ（IKE）」、RFC 2409、1998年11月。
Author's Addresses
著者のアドレス
David L. Black EMC Corporation 176 South Street Hopkinton, MA 10748
デビッドL.ブラックEMCコーポレーション176サウスストリートホプキントン、MA 10748
Phone: +1 (508) 293-7953
EMail: black_david@emc.com
David A. McGrew Cisco Systems, Inc. 510 McCarthy Blvd. Milpitas, CA 95035
David A. McGrew Cisco Systems、Inc. 510 McCarthy Blvd.ミルピタス、カリフォルニア95035
Phone: +1 (408) 525-8651
EMail: mcgrew@cisco.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The IETF Trust (2008).
Copyright（C）IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントは、BCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネット社会、IETFトラスト、およびインターネットエンジニアリングタスクフォースはすべてを否認します。明示または黙示を問わず、ここに含まれる情報の使用が商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害しないことを保証するものではありません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に対して行われたIPR開示のコピー、および使用可能にされるライセンスの保証、または一般ライセンスを取得する試みの結果、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得できるhttp://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。