[要約] RFC 4106は、IPsecのESPにおいて、Galois/Counter Mode (GCM) を用いたAES認証付き暗号アルゴリズム (AES-GCM) の使用方法を規定しています。暗号化と整合性認証を同時に効率よく行うことができ、特に 10 Gbps 以上の高速ネットワーク環境に適しています。128、192、256 ビットの鍵長をサポートし、パケット形式やノンス構成を含む具体的な実装仕様を定義しています。
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) における Galois/Counter Mode (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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを規定し、改善に向けた議論と提案を求めるものです。このプロトコルの標準化状態およびステータスについては、「Internet Official Protocol Standards」（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 Encapsulating Security Payload (ESP) メカニズムとしての、Galois/Counter Mode (GCM) における Advanced Encryption Standard (AES) の使用について説明します。この手法は、10 Gbps 以上の速度のハードウェアで効率的に実装でき、ソフトウェア実装にも適しています。
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.
本ドキュメントでは、機密性とデータ発信元認証のための IPsec ESP メカニズムとして GCM モードの AES (AES-GCM) を使用する方法について説明します。この手法を 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をノンス（nonce）と呼びます。同じノンスと鍵の組み合わせを2回以上使用してはなりません（MUST NOT）。
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.
ノンスと鍵の組み合わせを再利用するとAES-GCMモードのセキュリティ保証が損なわれるため、静的に設定された鍵を使用する場合、このモードを安全に使用することは困難です。安全のために、実装はこの要件が確実に満たされるように、Internet Key Exchange (IKE) [RFC2409] などの自動鍵管理システムを使用しなければなりません（MUST）。
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オクテットでなければなりません（MUST）。特定の鍵に対して、IVは繰り返してはなりません（MUST NOT）。これを実装する最も自然な方法はカウンターですが、線形フィードバックシフトレジスタ（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への平文入力は、Next Headerフィールドで記述された平文データに、Padding、Pad Length、およびNext Headerフィールドを連結することによって形成されます。暗号文フィールドは、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.
平文の長さを隠す必要がない実装では、必要な最小限のパディング（4オクテット未満）を使用すべきです（SHOULD）。
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：ノンスの形式
The components of the nonce are as follows:
ノンスの構成要素は以下の通りです。
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.
Salt：ソルトフィールドは4オクテットの値で、セキュリティアソシエーション（SA）の開始時に割り当てられ、SAの存続期間中は一定に保たれます。ソルトは選択される前は予測不可能（つまりランダムに選択される）であるべきですが（SHOULD）、秘密である必要はありません。セクション8.1で、Internet Key Exchangeを介して確立されたSAのソルトを設定する方法を説明します。
Initialization Vector The IV field is described in Section 3.1.
Initialization Vector：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 をサポートしなければならず (MUST)、8 または 12 オクテットの ICV をサポートしてもよいですが (MAY)、それ以外の ICV 長をサポートしてはなりません (MUST NOT)。ESP では ICV の存在は必須ではありませんが、AES-GCM-ESP では意図的に長さ 0 の ICV を許可していません。これは、長さ 0 の認証タグを使用した場合、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、シーケンス番号、Padding、Pad Length、および Next Header フィールドによって使用される 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.
本セクションでは、Internet Key Exchange (IKE) [RFC2409] プロトコルを使用して、AES-GCM-ESP で使用するための鍵材料とソルト値を生成するために使用される規則について説明します。AES-GCM-ESP を使用してセキュリティアソシエーション（SA）をネゴシエートするために必要な識別子と属性も定義されています。
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 オクテット長くなければなりません（MUST）。鍵材料は以下のように使用されます。
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]を使用することが推奨されます（RECOMMENDED）。
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] で鍵長属性（Key Length attribute）を指定しなければなりません（MUST）。鍵長属性は128、192、または256の値を持つ必要があります（MUST）。
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).
2つのピアエンティティ間で新しい鍵を確立するためにIKEが使用される場合、2つのトラフィックフローに対して別々の鍵が確立されます。新しい鍵を確立するために別のメカニズム（パケットの暗号化に単一の鍵のみを確立するもの）が使用される場合、ピアが一部のパケットに対して同じIV値を選択する可能性が高くなります。したがって、カウンターブロックの衝突を回避するために、同じピアとのパケットの暗号化および復号に同じ鍵の使用を許可するESP実装は、2つのピアがセキュリティアソシエーション（SA）に異なるソルト値を割り当てることを確実にしなければなりません（MUST）。
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.
もう1つの考慮事項は、他の暗号化モードと同様に、特定のSAで保護されているすべてのデータのセキュリティが、メッセージごとにわずかに低下することです。
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ブロックのデータを暗号化する前に新しい鍵を生成しなければなりません（MUST）。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値が小さいほど偽造攻撃を受けやすくなります。実装では、妥当な範囲でできるだけ大きなサイズを使用すべきです（SHOULD）。
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オクテットのノンスのケースを効率的に処理するように特別に最適化されています。他の長さのノンスは、特にハードウェア実装において、不必要な複雑さと遅延を引き起こします。ノンスの追加の1オクテットは、ソルトのサイズを増やすために使用されます。
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. and 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] Kent, S. and R. Atkinson、「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] Frankel, S., Glenn, R. and S. Kelly、「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] Kohno, T., Viega, J. and D. Whiting、「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. and 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 Eメール: 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.htmFull Copyright Statement
電話: (408) 525 8651 Eメール: mcgrew@cisco.com URI: http://www.mindspring.com/~dmcgrew/dam.htm著作権表示全文
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.
この文書とここに含まれる情報は「現状のまま」で提供され、寄稿者、その代表組織またはスポンサー（もしあれば）、Internet Society、および Internet Engineering Task Force は、明示的か黙示的かを問わず、ここに含まれる情報の使用がいかなる権利も侵害しないという保証や、商品性または特定の目的への適合性に関する黙示の保証を含め、いかなる保証も行いません。
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 は、本標準を実装するために必要となる可能性がある技術を対象とする著作権、特許、特許出願、その他の所有権について、関係者からの情報提供を呼びかけています。情報は IETF (ietf-ipr@ietf.org) までお寄せください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor 機能の資金は、現在 Internet Society から提供されています。