[要約] RFC 4106は、IPsec Encapsulating Security Payload（ESP）でGalois/Counter Mode（GCM）の使用に関する規格です。このRFCの目的は、ESPでGCMを使用することによって、データの機密性と完全性を確保することです。
Network Working Group J. Viega
Request for Comments: 4106 Secure Software, Inc.
Category: Standards Track D. McGrew
Cisco Systems, Inc.
June 2005
The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)
IPsecカプセル化セキュリティペイロード（ESP）でのガロア/カウンターモード（GCM）の使用
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）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（C）The Internet Society（2005）。
Abstract
概要
This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality and data origin authentication. This method can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations.
このメモは、機密性とデータ発信元認証を提供するIPsecカプセル化セキュリティペイロード（ESP）メカニズムとしてのガロア/カウンターモード（GCM）でのAdvanced Encryption Standard（AES）の使用について説明しています。この方法は、毎秒10ギガビット以上の速度でハードウェアに効率的に実装でき、ソフトウェアの実装にも適しています。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. AES-GCM .........................................................3
3. ESP Payload Data ................................................3
3.1. Initialization Vector (IV) .................................3
3.2. Ciphertext .................................................4
4. Nonce Format ....................................................4
5. AAD Construction ................................................5
6. Integrity Check Value (ICV) .....................................5
7. Packet Expansion ................................................6
8. IKE Conventions .................................................6
8.1. Keying Material and Salt Values ............................6
8.2. Phase 1 Identifier .........................................6
8.3. Phase 2 Identifier .........................................7
8.4. Key Length Attribute .......................................7
9. Test Vectors ....................................................7
10. Security Considerations ........................................7
11. Design Rationale ...............................................8
12. IANA Considerations ............................................8
13. Acknowledgements ...............................................9
14. Normative References ...........................................9
15. Informative References .........................................9
This document describes the use of AES in GCM mode (AES-GCM) as an IPsec ESP mechanism for confidentiality and data origin authentication. We refer to this method as AES-GCM-ESP. This mechanism is not only efficient and secure, but it also enables high-speed implementations in hardware. Thus, AES-GCM-ESP allows IPsec connections that can make effective use of emerging 10-gigabit and 40-gigabit network devices.
このドキュメントでは、GCMモードのAES（AES-GCM）を機密性とデータ発信元認証のIPsec ESPメカニズムとして使用する方法について説明します。この方法をAES-GCM-ESPと呼びます。このメカニズムは効率的で安全であるだけでなく、ハードウェアでの高速実装も可能にします。したがって、AES-GCM-ESPを使用すると、新しい10ギガビットおよび40ギガビットネットワークデバイスを効果的に使用できるIPsec接続が可能になります。
Counter mode (CTR) has emerged as the preferred encryption method for high-speed implementations. Unlike conventional encryption modes such as Cipher Block Chaining (CBC) and Cipher Block Chaining Message Authentication Code (CBC-MAC), CTR can be efficiently implemented at high data rates because it can be pipelined. The ESP CTR protocol describes how this mode can be used with IPsec ESP [RFC3686].
カウンターモード（CTR）は、高速実装に適した暗号化方式として登場しました。暗号ブロックチェーン（CBC）や暗号ブロックチェーンメッセージ認証コード（CBC-MAC）などの従来の暗号化モードとは異なり、CTRはパイプライン処理できるため、高いデータレートで効率的に実装できます。 ESP CTRプロトコルは、IPsec ESP [RFC3686]でこのモードを使用する方法を説明しています。
Unfortunately, CTR provides no data origin authentication, and thus the ESP CTR standard requires the use of a data origin authentication algorithm in conjunction with CTR. This requirement is problematic, because none of the standard data origin authentication algorithms can be efficiently implemented for high data rates. GCM solves this problem, because under the hood, it combines CTR mode with a secure, parallelizable, and efficient authentication mechanism.
残念ながら、CTRはデータ発信元認証を提供しないため、ESP CTR標準では、データ発信元認証アルゴリズムをCTRと組み合わせて使用する必要があります。高いデータレートで効率的に実装できる標準のデータ発信元認証アルゴリズムがないため、この要件には問題があります。 GCMはこの問題を解決します。内部的には、CTRモードと安全で並列化可能な効率的な認証メカニズムを組み合わせているためです。
This document does not cover implementation details of GCM. Those details can be found in [GCM], along with test vectors.
このドキュメントでは、GCMの実装の詳細については説明していません。これらの詳細は、テストベクターとともに[GCM]にあります。
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]で説明されているように解釈されます。
GCM is a block cipher mode of operation providing both confidentiality and data origin authentication. The GCM authenticated encryption operation has four inputs: a secret key, an initialization vector (IV), a plaintext, and an input for additional authenticated data (AAD). It has two outputs, a ciphertext whose length is identical to the plaintext, and an authentication tag. In the following, we describe how the IV, plaintext, and AAD are formed from the ESP fields, and how the ESP packet is formed from the ciphertext and authentication tag.
GCMは、機密性とデータ発信元認証の両方を提供するブロック暗号化動作モードです。 GCM認証の暗号化操作には、秘密鍵、初期化ベクトル（IV）、プレーンテキスト、および追加の認証済みデータ（AAD）の入力という4つの入力があります。 2つの出力、長さが平文と同じ暗号文、および認証タグがあります。以下では、IV、平文、およびAADがESPフィールドからどのように形成されるか、およびESPパケットが暗号文と認証タグからどのように形成されるかについて説明します。
ESP also defines an IV. For clarity, we refer to the AES-GCM IV as a nonce in the context of AES-GCM-ESP. The same nonce and key combination MUST NOT be used more than once.
ESPはIVも定義します。明確にするために、AES-GCM-ESPのコンテキストでは、AES-GCM IVをノンスと呼びます。同じノンスとキーの組み合わせを2回以上使用してはなりません。
Because reusing an nonce/key combination destroys the security guarantees of AES-GCM mode, it can be difficult to use this mode securely when using statically configured keys. For safety's sake, implementations MUST use an automated key management system, such as the Internet Key Exchange (IKE) [RFC2409], to ensure that this requirement is met.
nonceとキーの組み合わせを再利用すると、AES-GCMモードのセキュリティ保証が失われるため、静的に構成されたキーを使用する場合、このモードを安全に使用することは困難です。安全のために、実装では、インターネットキー交換（IKE）[RFC2409]などの自動キー管理システムを使用して、この要件が確実に満たされるようにする必要があります。
The ESP Payload Data is comprised of an eight-octet initialization vector (IV), followed by the ciphertext. The payload field, as defined in [RFC2406], is structured as shown in Figure 1, along with the ICV associated with the payload.
ESPペイロードデータは、8オクテットの初期化ベクトル（IV）とそれに続く暗号文で構成されます。 [RFC2406]で定義されているペイロードフィールドは、ペイロードに関連付けられているICVとともに、図1に示すように構成されています。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Ciphertext (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ESP Payload Encrypted with AES-GCM.
図1：AES-GCMで暗号化されたESPペイロード。
The AES-GCM-ESP IV field MUST be eight octets. For a given key, the IV MUST NOT repeat. The most natural way to implement this is with a counter, but anything that guarantees uniqueness can be used, such as a linear feedback shift register (LFSR). Note that the encrypter can use any IV generation method that meets the uniqueness requirement, without coordinating with the decrypter.
AES-GCM-ESP IVフィールドは8オクテットでなければなりません。与えられたキーに対して、IVは繰り返されてはいけません。これを実装する最も自然な方法はカウンターですが、線形フィードバックシフトレジスタ（LFSR）など、一意性を保証するものなら何でも使用できます。暗号化機能は、暗号化解除機能と連携することなく、一意性要件を満たすIV生成方法を使用できることに注意してください。
The plaintext input to AES-GCM is formed by concatenating the plaintext data described by the Next Header field with the Padding, the Pad Length, and the Next Header field. The Ciphertext field consists of the ciphertext output from the AES-GCM algorithm. The length of the ciphertext is identical to that of the plaintext.
AES-GCMへの平文入力は、次のヘッダーフィールドで記述された平文データを、パディング、パッド長、および次のヘッダーフィールドと連結することによって形成されます。暗号文フィールドは、AES-GCMアルゴリズムからの暗号文出力で構成されます。暗号文の長さは平文の長さと同じです。
Implementations that do not seek to hide the length of the plaintext SHOULD use the minimum amount of padding required, which will be less than four octets.
プレーンテキストの長さを隠そうとしない実装は、必要なパディングの最小量を使用する必要があります（SHOULD）、4オクテット未満になります。
The nonce passed to the GCM-AES encryption algorithm has the following layout:
GCM-AES暗号化アルゴリズムに渡されるノンスのレイアウトは次のとおりです。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Salt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Nonce Format
図2：nonce形式
The components of the nonce are as follows:
nonceのコンポーネントは次のとおりです。
Salt The salt field is a four-octet value that is assigned at the beginning of the security association, and then remains constant for the life of the security association. The salt SHOULD be unpredictable (i.e., chosen at random) before it is selected, but need not be secret. We describe how to set the salt for a Security Association established via the Internet Key Exchange in Section 8.1.
ソルトソルトフィールドは、セキュリティアソシエーションの開始時に割り当てられる4オクテットの値であり、セキュリティアソシエーションの存続期間中は一定のままです。ソルトは、選択される前は予測不可能である（つまり、ランダムに選択される）必要がありますが、秘密にする必要はありません。セクション8.1で、インターネットキー交換を介して確立されたセキュリティアソシエーションのソルトを設定する方法について説明します。
Initialization Vector The IV field is described in Section 3.1.
初期化ベクトルIVフィールドについては、セクション3.1で説明します。
The authentication of data integrity and data origin for the SPI and (Extended) Sequence Number fields is provided without encryption. This is done by including those fields in the AES-GCM Additional Authenticated Data (AAD) field. Two formats of the AAD are defined: one for 32-bit sequence numbers, and one for 64-bit extended sequence numbers. The format with 32-bit sequence numbers is shown in Figure 3, and the format with 64-bit extended sequence numbers is shown in Figure 4.
SPIおよび（拡張）シーケンス番号フィールドのデータ整合性とデータ発信元の認証は、暗号化なしで提供されます。これは、AES-GCM追加認証データ（AAD）フィールドにこれらのフィールドを含めることによって行われます。 AADの2つの形式が定義されています。1つは32ビットのシーケンス番号用、もう1つは64ビットの拡張シーケンス番号用です。 32ビットのシーケンス番号を使用したフォーマットを図3に示し、64ビットの拡張シーケンス番号を使用したフォーマットを図4に示します。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: AAD Format with 32-bit Sequence Number
図3：32ビットのシーケンス番号を使用したAAD形式
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64-bit Extended Sequence Number |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: AAD Format with 64-bit Extended Sequence Number
図4：64ビット拡張シーケンス番号を使用したAAD形式
The ICV consists solely of the AES-GCM Authentication Tag. Implementations MUST support a full-length 16-octet ICV, and MAY support 8 or 12 octet ICVs, and MUST NOT support other ICV lengths. Although ESP does not require that an ICV be present, AES-GCM-ESP intentionally does not allow a zero-length ICV. This is because GCM provides no integrity protection whatsoever when used with a zero-length Authentication Tag.
ICVは、AES-GCM認証タグのみで構成されています。実装は、完全長の16オクテットICVをサポートする必要があり、8または12オクテットICVをサポートする場合があり、他のICV長をサポートしてはならない（MUST NOT）。 ESPではICVが存在する必要はありませんが、AES-GCM-ESPでは意図的に長さがゼロのICVを許可していません。これは、長さがゼロの認証タグを使用した場合、GCMが完全性保護を提供しないためです。
The IV adds an additional eight octets to the packet, and the ICV adds an additional 8, 12, or 16 octets. These are the only sources of packet expansion, other than the 10-13 octets taken up by the ESP SPI, Sequence Number, Padding, Pad Length, and Next Header fields (if the minimal amount of padding is used).
IVはパケットに8オクテットを追加し、ICVは8、12、または16オクテットを追加します。これらは、ESP SPI、シーケンス番号、パディング、パッド長、および次のヘッダーフィールド（最小量のパディングが使用されている場合）によって使用される10〜13オクテット以外の、パケット拡張の唯一のソースです。
This section describes the conventions used to generate keying material and salt values, for use with AES-GCM-ESP, using the Internet Key Exchange (IKE) [RFC2409] protocol. The identifiers and attributes needed to negotiate a security association using AES-GCM-ESP are also defined.
このセクションでは、インターネット鍵交換（IKE）[RFC2409]プロトコルを使用して、AES-GCM-ESPで使用するための鍵情報とソルト値を生成するために使用される規則について説明します。 AES-GCM-ESPを使用してセキュリティ結合をネゴシエートするために必要な識別子と属性も定義されています。
IKE makes use of a pseudo-random function (PRF) to derive keying material. The PRF is used iteratively to derive keying material of arbitrary size, called KEYMAT. Keying material is extracted from the output string without regard to boundaries.
IKEは、疑似ランダム関数（PRF）を使用してキー生成情報を導出します。 PRFは、KEYMATと呼ばれる任意のサイズの鍵情報を導出するために繰り返し使用されます。キーイングマテリアルは、境界に関係なく出力文字列から抽出されます。
The size of the KEYMAT for the AES-GCM-ESP MUST be four octets longer than is needed for the associated AES key. The keying material is used as follows:
AES-GCM-ESPのKEYMATのサイズは、関連するAESキーに必要な長さより4オクテット長くなければなりません。キー素材は次のように使用されます。
AES-GCM-ESP with a 128 bit key The KEYMAT requested for each AES-GCM key is 20 octets. The first 16 octets are the 128-bit AES key, and the remaining four octets are used as the salt value in the nonce.
128ビットキーを使用するAES-GCM-ESP各AES-GCMキーに要求されるKEYMATは20オクテットです。最初の16オクテットは128ビットAESキーで、残りの4オクテットはノンスのソルト値として使用されます。
AES-GCM-ESP with a 192 bit key The KEYMAT requested for each AES-GCM key is 28 octets. The first 24 octets are the 192-bit AES key, and the remaining four octets are used as the salt value in the nonce.
192ビットキーを持つAES-GCM-ESP各AES-GCMキーに要求されるKEYMATは28オクテットです。最初の24オクテットは192ビットAESキーで、残りの4オクテットはノンスのソルト値として使用されます。
AES-GCM-ESP with a 256 bit key The KEYMAT requested for each AES GCM key is 36 octets. The first 32 octets are the 256-bit AES key, and the remaining four octets are used as the salt value in the nonce.
256ビットキーのAES-GCM-ESP各AES GCMキーに要求されるKEYMATは36オクテットです。最初の32オクテットは256ビットのAESキーで、残りの4オクテットはノンスのソルト値として使用されます。
This document does not specify the conventions for using AES-GCM for IKE Phase 1 negotiations. For AES-GCM to be used in this manner, a separate specification is needed, and an Encryption Algorithm Identifier needs to be assigned. Implementations SHOULD use an IKE Phase 1 cipher that is at least as strong as AES-GCM. The use of AES CBC [RFC3602] with the same key size used by AES-GCM-ESP is RECOMMENDED.
このドキュメントでは、IKEフェーズ1ネゴシエーションにAES-GCMを使用するための規則を指定していません。この方法でAES-GCMを使用するには、別の仕様が必要であり、暗号化アルゴリズム識別子を割り当てる必要があります。実装では、少なくともAES-GCMと同等の強度のIKEフェーズ1暗号を使用する必要があります（SHOULD）。 AES-GCM-ESPで使用されるのと同じ鍵サイズでAES CBC [RFC3602]を使用することをお勧めします。
For IKE Phase 2 negotiations, IANA has assigned three ESP Transform Identifiers for AES-GCM with an eight-byte explicit IV:
IKEフェーズ2ネゴシエーションの場合、IANAは、8バイトの明示的なIVを使用して、AES-GCMに3つのESP変換識別子を割り当てました。
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。
Because the AES supports three key lengths, the Key Length attribute MUST be specified in the IKE Phase 2 exchange [RFC2407]. The Key Length attribute MUST have a value of 128, 192, or 256.
AESは3つの鍵の長さをサポートするため、IKEフェーズ2交換[RFC2407]で鍵の長さ属性を指定する必要があります。キーの長さ属性には、128、192、または256の値が必要です。
Appendix B of [GCM] provides test vectors that will assist implementers with AES-GCM mode.
[GCM]の付録Bは、AES-GCMモードで実装者を支援するテストベクトルを提供します。
GCM is provably secure against adversaries that can adaptively choose plaintexts, ciphertexts, ICVs, and the AAD field, under standard cryptographic assumptions (roughly, that the output of the underlying cipher, under a randomly chosen key, is indistinguishable from a randomly selected output). Essentially, this means that, if used within its intended parameters, a break of GCM implies a break of the underlying block cipher. The proof of security for GCM is available in [GCM].
GCMは、標準の暗号化の仮定の下で、平文、暗号文、ICV、およびAADフィールドを適応的に選択できる敵対者に対して証明可能に安全です（ランダムに選択されたキーの下での基本的な暗号の出力は、ランダムに選択された出力と区別がつかない）。 。基本的に、これは、意図されたパラメーター内で使用された場合、GCMの破綻は基礎となるブロック暗号の破綻を意味します。 GCMのセキュリティ証明は[GCM]で利用できます。
The most important security consideration is that the IV never repeat for a given key. In part, this is handled by disallowing the use of AES-GCM when using statically configured keys, as discussed in Section 2.
セキュリティに関する最も重要な考慮事項は、指定されたキーに対してIVが繰り返されないことです。セクション2で説明したように、これは部分的に、静的に構成されたキーを使用するときにAES-GCMの使用を禁止することによって処理されます。
When IKE is used to establish fresh keys between two peer entities, separate keys are established for the two traffic flows. If a different mechanism is used to establish fresh keys (one that establishes only a single key to encrypt packets), then there is a high probability that the peers will select the same IV values for some packets. Thus, to avoid counter block collisions, ESP implementations that permit use of the same key for encrypting and decrypting packets with the same peer MUST ensure that the two peers assign different salt values to the security association (SA).
IKEを使用して2つのピアエンティティ間で新しいキーを確立すると、2つのトラフィックフローに対して別々のキーが確立されます。別のメカニズムを使用して新しいキー（パケットを暗号化するための単一のキーのみを確立するメカニズム）を確立する場合、ピアが一部のパケットに対して同じIV値を選択する可能性が高くなります。したがって、カウンターブロックの衝突を回避するために、同じピアでのパケットの暗号化と復号化に同じキーの使用を許可するESP実装は、2つのピアがセキュリティアソシエーション（SA）に異なるソルト値を割り当てることを保証する必要があります。
The other consideration is that, as with any encryption mode, the security of all data protected under a given security association decreases slightly with each message.
他の考慮事項は、他の暗号化モードと同様に、特定のセキュリティアソシエーションで保護されているすべてのデータのセキュリティが、メッセージごとにわずかに低下することです。
To protect against this problem, implementations MUST generate a fresh key before encrypting 2^64 blocks of data with a given key. Note that it is impossible to reach this limit when using 32-bit Sequence Numbers.
この問題から保護するために、実装では、指定されたキーで2 ^ 64ブロックのデータを暗号化する前に、新しいキーを生成する必要があります。 32ビットのシーケンス番号を使用する場合、この制限に到達することはできないことに注意してください。
Note that, for each message, GCM calls the block cipher once for each full 16-octet block in the payload, once for any remaining octets in the payload, and one additional time for computing the ICV.
GCMは、メッセージごとに、ペイロード内の完全な16オクテットブロックごとに1回、ペイロード内の残りのオクテットごとに1回、ICVを計算するためにさらに1回、ブロック暗号を呼び出します。
Clearly, smaller ICV values are more likely to be subject to forgery attacks. Implementations SHOULD use as large a size as reasonable.
明らかに、ICV値が小さいほど、偽造攻撃を受ける可能性が高くなります。実装では、妥当な大きさのサイズを使用する必要があります。
This specification was designed to be as similar to the AES-CCM ESP [CCM-ESP] and AES-CTR ESP [RFC3686] mechanisms as reasonable, while promoting simple, efficient implementations in both hardware and software. We re-use the design and implementation experience from those standards.
この仕様は、AES-CCM ESP [CCM-ESP]およびAES-CTR ESP [RFC3686]メカニズムと同様に合理的に設計されており、ハードウェアとソフトウェアの両方でシンプルで効率的な実装を促進しています。これらの標準の設計と実装の経験を再利用します。
The major difference with CCM is that the CCM ESP mechanism requires an 11-octet nonce, whereas the GCM ESP mechanism requires using a 12-octet nonce. GCM is specially optimized to handle the 12-octet nonce case efficiently. Nonces of other lengths would cause unnecessary, additional complexity and delays, particularly in hardware implementations. The additional octet of nonce is used to increase the size of the salt.
CCMとの主な違いは、CCM ESPメカニズムでは11オクテットナンスが必要なのに対し、GCM ESPメカニズムでは12オクテットナンスを使用する必要があることです。 GCMは、12オクテットのノンスケースを効率的に処理するように特別に最適化されています。他の長さのノンスは、特にハードウェアの実装において、不必要な、さらに複雑な遅延を引き起こします。ノンスの追加のオクテットは、塩のサイズを増やすために使用されます。
IANA has assigned three ESP Transform Identifiers for AES-GCM with an eight-byte explicit IV:
IANAは、8バイトの明示的なIVを使用して、AES-GCMに3つのESP変換識別子を割り当てました。
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。
This work is closely modeled after Russ Housley's AES-CCM transform [CCM-ESP]. Portions of this document are directly copied from that work in progress. We thank Russ for his support of this work.
この作品は、Russ HousleyのAES-CCM変換[CCM-ESP]に基づいて厳密にモデル化されています。このドキュメントの一部は、進行中の作業から直接コピーされます。この作業に対するRussのサポートに感謝します。
Additionally, the GCM mode of operation was originally conceived as an improvement to Carter-Wegman Counter (CWC) mode [CWC], the first unencumbered block cipher mode capable of supporting high-speed authenticated encryption.
さらに、GCMの動作モードは、もともとは、高速認証暗号化をサポートできる最初の障害のないブロック暗号モードであるCarter-Wegman Counter（CWC）モード[CWC]の改善として考えられました。
[GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of Operation (GCM)", Submission to NIST. http:// csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/ gcm-spec.pdf, January 2004.
[GCM] McGrew、D.およびJ. Viega、「ガロア/カウンター操作モード（GCM）」、NISTへの提出。 http：// csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/ gcm-spec.pdf、2004年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月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケント、S。、およびR.アトキンソン、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407] Piper、D。、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、RFC 2407、1998年11月。
[RFC3602] Frankel, S., Glenn, R. and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[RFC3602]フランケルS.、グレンR.、S。ケリー、「AES-CBC暗号アルゴリズムとIPsecでのその使用」、RFC 3602、2003年9月。
[CCM-ESP] Housley, R., "Using AES CCM Mode With IPsec ESP", Work In Progress.
[CCM-ESP] Housley、R。、「IPsec ESPでのAES CCMモードの使用」、作業中。
[CWC] Kohno, T., Viega, J. and D. Whiting, "CWC: A high-performance conventional authenticated encryption mode", Fast Software Encryption. http://eprint.iacr.org/ 2003/106.pdf, February 2004.
[CWC]河野徹、Viega、J。、およびD.ホワイティング、「CWC：高性能の従来の認証済み暗号化モード」、高速ソフトウェア暗号化。 http://eprint.iacr.org/ 2003 / 106.pdf、2004年2月。
[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月。
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.
[RFC3686] Housley、R。、「IPsecカプセル化セキュリティペイロード（ESP）でのAdvanced Encryption Standard（AES）カウンターモードの使用」、RFC 3686、2004年1月。
Authors' Addresses
著者のアドレス
John Viega Secure Software, Inc. 4100 Lafayette Center Dr., Suite 100 Chantilly, VA 20151 US
John Viega Secure Software、Inc. 4100 Lafayette Center Dr.、Suite 100 Chantilly、VA 20151米国
Phone: (703) 814 4402 EMail: viega@securesoftware.com
電話：（703）814 4402メール：viega@securesoftware.com
David A. McGrew Cisco Systems, Inc. 510 McCarthy Blvd. Milpitas, CA 95035 US
David A. McGrew Cisco Systems、Inc. 510 McCarthy Blvd.ミルピタス、CA 95035 US
Phone: (408) 525 8651
EMail: mcgrew@cisco.com
URI: http://www.mindspring.com/~dmcgrew/dam.htm
Full Copyright Statement
Copyright (C) The Internet Society (2005).
Copyright（C）The Internet Society（2005）。
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 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.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネットエンジニアリングおよびインターネットエンジニアリングタスクフォースは、すべての保証を明示的または明示的に提供します。ここに含まれる情報の使用により、商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害されないという保証を含みますが、これに限定されるものではありません。
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に情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。