[要約] RFC 4543は、ネットワーク層のセキュリティプロトコルであるIPsecのESPおよびAHにおいて、暗号化（機密性）を伴わずに高速なデータ起源認証と完全性保証を提供するGMACの利用仕様を定義しています。暗号化が不要な環境において、AES-GCMと同じ効率的なパイプライン処理やハードウェア並列処理を活用し、10Gbps以上の高速通信にも適した認証機能を提供します。
Network Working Group D. McGrew
Request for Comments: 4543 Cisco Systems, Inc.
Category: Standards Track J. Viega
McAfee, Inc.
May 2006
The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH
IPsec ESP および AH における Galois Message Authentication Code (GMAC) の利用
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 (2006).
Copyright（C）The Internet Society（2006）。
Abstract
概要
This memo describes the use of the Advanced Encryption Standard (AES) Galois Message Authentication Code (GMAC) as a mechanism to provide data origin authentication, but not confidentiality, within the IPsec Encapsulating Security Payload (ESP) and Authentication Header (AH). GMAC is based on the Galois/Counter Mode (GCM) of operation, and 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）と認証ヘッダー（AH）内でデータ起源認証を提供するが、機密性は提供しないメカニズムとしてのAdvanced Encryption Standard（AES）ガロアメッセージ認証コード（GMAC）の使用について説明します。 GMACはガロア/カウンターモード（GCM）の動作に基づいており、ハードウェアに10ギガビット/秒以上の速度で効率的に実装でき、ソフトウェアの実装にも適しています。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. AES-GMAC ........................................................3
3. The Use of AES-GMAC in ESP ......................................3
3.1. Initialization Vector ......................................4
3.2. Nonce Format ...............................................4
3.3. AAD Construction ...........................................5
3.4. Integrity Check Value (ICV) ................................6
3.5. Differences with AES-GCM-ESP ...............................6
3.6. Packet Expansion ...........................................7
4. The Use of AES-GMAC in AH .......................................7
5. IKE Conventions .................................................8
5.1. Phase 1 Identifier .........................................8
5.2. Phase 2 Identifier .........................................8
5.3. Key Length Attribute .......................................9
5.4. Keying Material and Salt Values ............................9
6. Test Vectors ....................................................9
7. Security Considerations ........................................10
8. Design Rationale ...............................................11
9. IANA Considerations ............................................11
10. Acknowledgements ..............................................11
11. References ....................................................12
11.1. Normative References .....................................12
11.2. Informative References ...................................12
This document describes the use of AES-GMAC mode (AES-GMAC) as a mechanism for data origin authentication in ESP [RFC4303] and AH [RFC4302]. We refer to these methods as ENCR_NULL_AUTH_AES_GMAC and AUTH_AES_GMAC, respectively. ENCR_NULL_AUTH_AES_GMAC is a companion to the AES Galois/Counter Mode ESP [RFC4106], which provides authentication as well as confidentiality. ENCR_NULL_AUTH_AES_GMAC is intended for cases in which confidentiality is not desired. Like GCM, GMAC is efficient and secure, and is amenable to high-speed implementations in hardware. ENCR_NULL_AUTH_AES_GMAC and AUTH_AES_GMAC are designed so that the incremental cost of implementation, given an implementation is AES-GCM-ESP, is small.
このドキュメントでは、ESP [RFC4303] および AH [RFC4302] でのデータ起源認証のメカニズムとしての AES-GMAC モード (AES-GMAC) の使用について説明します。これらのメソッドをそれぞれ ENCR_NULL_AUTH_AES_GMAC および AUTH_AES_GMAC と呼びます。ENCR_NULL_AUTH_AES_GMAC は、認証と機密性を提供する AES Galois/Counter Mode ESP [RFC4106] のコンパニオンです。ENCR_NULL_AUTH_AES_GMAC は、機密性が望まれない場合を対象としています。GCM と同様に、GMAC は効率的で安全であり、ハードウェアでの高速実装に適しています。ENCR_NULL_AUTH_AES_GMAC と AUTH_AES_GMAC は、既存の AES-GCM-ESP 実装がある場合、追加の実装コストが小さくなるように設計されています。
This document does not cover implementation details of GCM or GMAC. Those details can be found in [GCM], along with test vectors.
このドキュメントでは、GCM または GMAC の実装の詳細については扱っていません。これらの詳細は、テストベクトルとともに [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] で説明されているように解釈されるものとします。
GMAC is a block cipher mode of operation providing data origin authentication. It is defined in terms of the GCM authenticated encryption operation as follows. 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. GMAC is the special case of GCM in which the plaintext has a length of zero. The (zero-length) ciphertext output is ignored, of course, so that the only output of the function is the Authentication Tag. In the following, we describe how the GMAC IV and AAD are formed from the ESP and AH fields, and how the ESP and AH packets are formed from the Authentication Tag.
GMAC は、データ起源認証を提供するブロック暗号の動作モードです。これは、以下のように GCM の認証付き暗号化操作を用いて定義されます。GCM の認証付き暗号化操作には、秘密鍵、初期化ベクトル (IV)、平文、および追加の認証データ (AAD) の4つの入力があります。接着、平文と同一の長さの暗号文と、認証タグの2つが出力されます。GMAC は、平文の長さがゼロである GCM の特殊なケースです。もちろん、（長さゼロの）暗号文出力は無視されるため、この関数の唯一の出力は認証タグとなります。以下では、GMAC の IV および AAD が ESP および AH フィールドからどのように構成されるか、また ESP および AH パケットが認証タグからどのように構成されるかについて説明します。
Below we refer to the AES-GMAC IV input as a nonce, in order to distinguish it from the IV fields in the packets. The same nonce and key combination MUST NOT be used more than once, since reusing a nonce/key combination destroys the security guarantees of AES-GMAC.
以下では、パケット内の IV フィールドと区別するために、AES-GMAC の IV 入力をノンスと呼びます。ノンスと鍵の組み合わせを再利用すると AES-GMAC のセキュリティ保証が損なわれるため、同じノンスと鍵の組み合わせを複数回使用してはなりません (MUST NOT)。
Because of this restriction, it can be difficult to use this mode securely when using statically configured keys. For the sake of good security, implementations MUST use an automated key management system, such as the Internet Key Exchange (IKE) (either version two [RFC4306] or version one [RFC2409]), to ensure that this requirement is met.
この制限のため、静的に設定された鍵を使用する場合、このモードを安全に使用することは困難です。セキュリティを確保するために、実装はこの要件が満たされることを保証する、Internet Key Exchange (IKE)（バージョン2 [RFC4306] またはバージョン1 [RFC2409] のいずれか）などの自動鍵管理システムを使用しなければなりません (MUST)。
The AES-GMAC algorithm for ESP is defined as an ESP "combined mode" algorithm (see Section 3.2.3 of [RFC4303]), rather than an ESP integrity algorithm. It is called ENCR_NULL_AUTH_AES_GMAC to highlight the fact that it performs no encryption and provides no confidentiality.
ESP用のAES-GMACアルゴリズムは、ESP整合性アルゴリズムではなく、ESPの「結合モード」アルゴリズム（[RFC4303]のセクション3.2.3を参照）として定義されています。暗号化を実行せず、機密性も提供しないという事実を強調するために、ENCR_NULL_AUTH_AES_GMACと呼ばれています。
Rationale: ESP makes no provision for integrity transforms to place an initialization vector within the Payload field; only encryption transforms are expected to use IVs. Defining GMAC as an encryption transform avoids this issue, and allows GMAC to benefit from the same pipelining as does GCM.
設計根拠：ESPは、整合性変換がペイロードフィールド内に初期化ベクトルを配置することを規定していません。暗号化変換のみがIVを使用することが想定されています。GMACを暗号化変換として定義することでこの問題が回避され、GMACがGCMと同様のパイプライン処理の恩恵を受けられるようになります。
Like all ESP combined modes, it is registered in IKEv2 as an encryption transform, or "Type 1" transform. It MUST NOT be used in conjunction with any other ESP encryption transform (within a particular ESP encapsulation). If confidentiality is desired, then GCM ESP [RFC4106] SHOULD be used instead.
すべてのESP結合モードと同様に、暗号化変換または「Type 1」変換としてIKEv2に登録されます。特定のESPカプセル化内において、他のいかなるESP暗号化変換とも組み合わせて使用してはなりません (MUST NOT)。機密性が必要な場合は、代わりにGCM ESP [RFC4106]を使用すべきです (SHOULD)。
With ENCR_NULL_AUTH_AES_GMAC, an explicit Initialization Vector (IV) is included in the ESP Payload, at the outset of that field. The IV MUST be eight octets long. For a given key, the IV MUST NOT repeat. The most natural way to meet this requirement is to set the IV using a counter, but implementations are free to set the IV field in any way that guarantees uniqueness, such as a linear feedback shift register (LFSR). Note that the sender can use any IV generation method that meets the uniqueness requirement without coordinating with the receiver.
ENCR_NULL_AUTH_AES_GMACでは、明示的な初期化ベクトル (IV) がESPペイロードの先頭に含まれます。IVは8オクテットでなければなりません (MUST)。特定の鍵に対して、IVは繰り返してはなりません (MUST NOT)。この要件を満たす最も自然な方法は、カウンタを用いてIVを設定することですが、実装は、線形フィードバックシフトレジスタ (LFSR) など、一意性を保証するいかなる方法でも自由にIVフィールドを設定できます。送信者は、受信者と調整することなく、一意性要件を満たす任意のIV生成方法を使用できることに注意してください。
The nonce passed to the AES-GMAC authentication algorithm has the following layout:
AES-GMAC認証アルゴリズムに渡されるノンスのレイアウトは以下のとおりです。
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 1: Nonce Format
図1：ノンスのフォーマット
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 5.4.
ソルト（Salt）：ソルトフィールドは、セキュリティアソシエーションの開始時に割り当てられる4オクテットの値であり、セキュリティアソシエーションの有効期間中、一定のままとなります。ソルトは選択される前は予測不可能である（すなわち、ランダムに選択される）べきですが (SHOULD)、秘密にする必要はありません。Internet Key Exchangeを介して確立されたセキュリティアソシエーションにおけるソルトの設定方法については、セクション5.4で説明します。
Initialization Vector The IV field is described in Section 3.1.
初期化ベクトル (IV)：IVフィールドについてはセクション3.1で説明します。
Data integrity and data origin authentication are provided for the SPI, (Extended) Sequence Number, Authenticated Payload, Padding, Pad Length, and Next Header fields. This is done by including those fields in the AES-GMAC 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 2, and the format with 64-bit extended sequence numbers is shown in Figure 3.
SPI、（拡張）シーケンス番号、認証対象ペイロード、パディング、パッド長、および次ヘッダー（Next Header）フィールドに対して、データの整合性とデータ起源認証が提供されます。これは、これらのフィールドをAES-GMACの追加認証データ (AAD) フィールドに含めることによって行われます。AADには2つのフォーマットが定義されています。1つは32ビットシーケンス番号用、もう1つは64ビット拡張シーケンス番号用です。32ビットシーケンス番号のフォーマットを図2に、64ビット拡張シーケンス番号のフォーマットを図3に示します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authenticated Payload (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (0-255 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: AAD Format with 32-bit Sequence Number
図2：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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authenticated Payload (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (0-255 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: AAD Format with 64-bit Extended Sequence Number
図3：64ビット拡張シーケンス番号を用いたAADのフォーマット
The use of 32-bit sequence numbers vs. 64-bit extended sequence numbers is determined by the security association (SA) management protocol that is used to create the SA. For IKEv2 [RFC4306] this is negotiated via Transform Type 5, and the default for ESP is to use 64-bit extended sequence numbers in the absence of negotiation (e.g., see Section 2.2.1 of [RFC4303]).
32ビットシーケンス番号と64ビット拡張シーケンス番号のどちらを使用するかは、SAの作成に使用されるセキュリティアソシエーション (SA) 管理プロトコルによって決定されます。IKEv2 [RFC4306] では、これはTransform Type 5を介してネゴシエートされ、ESPのデフォルトは、ネゴシエーションがない場合は64ビット拡張シーケンス番号を使用することです（たとえば、[RFC4303]のセクション2.2.1を参照）。
The ICV consists solely of the AES-GMAC Authentication Tag. The Authentication Tag MUST NOT be truncated, so the length of the ICV is 16 octets.
ICVは、AES-GMACの認証タグのみで構成されます。認証タグを切り詰めてはならず (MUST NOT)、そのためICVの長さは16オクテットとなります。
In this section, we highlight the differences between this specification and AES-GCM-ESP [RFC4106]. The essential difference is that in this document, the AAD consists of the SPI, Sequence Number, and ESP Payload, and the AES-GCM plaintext is zero-length, while in AES-GCM-ESP, the AAD consists only of the SPI and Sequence Number, and the AES-GCM plaintext consists of the ESP Payload. These differences are illustrated in Figure 4. This figure shows the case in which the Extended Sequence Number option is not used. When that option is exercised, the Sequence Number field in the figure would be replaced with the Extended Sequence Number.
このセクションでは、本仕様とAES-GCM-ESP [RFC4106]の違いを明らかにします。本質的な違いは、本文書ではAADがSPI、シーケンス番号、およびESPペイロードで構成され、AES-GCMの平文の長さがゼロであるのに対し、AES-GCM-ESPではAADがSPIおよびシーケンス番号のみで構成され、AES-GCMの平文がESPペイロードで構成される点です。これらの違いを図4に示します。この図は、拡張シーケンス番号オプションが使用されていない場合を示しています。このオプションが使用される場合、図の「Sequence Number」フィールドは「Extended Sequence Number」に置き換えられます。
Importantly, ENCR_NULL_AUTH_AES_GMAC is *not* equivalent to AES-GCM-ESP with encryption "turned off". However, the ICV computations performed in both cases are similar because of the structure of the GHASH function [GCM].
重要な点として、ENCR_NULL_AUTH_AES_GMACは暗号化が「オフ」にされたAES-GCM-ESPと等価では*ありません*。しかし、GHASH関数 [GCM] の構造により、両方のケースで実行されるICV計算は類似しています。
+-> +-----------------------+ <-+
AES-GCM-ESP | | SPI | |
AAD -------+ +-----------------------+ |
| | Sequence Number | |
+-> +-----------------------+ |
| Authentication | |
| IV | |
+->+-> +-----------------------+ +
AES-GCM-ESP | | | |
Plaintext -+ ~ ESP Payload ~ |
| | | |
| +-----------+-----+-----+ |
| | Padding | PL | NH | |
+----> +-----------+-----+-----+ <-+
|
ENCR_NULL_AUTH_AES_GMAC AAD --+
Figure 4: Differences between ENCR_NULL_AUTH_AES_GMAC and AES-GCM-ESP
図4：ENCR_NULL_AUTH_AES_GMACとAES-GCM-ESPの違い
The IV adds an additional eight octets to the packet and the ICV adds an additional 16 octets. These are the only sources of packet expansion, other than the 10-13 bytes 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は16オクテットを追加します。これらは、ESP SPI、シーケンス番号、パディング、パッド長、および次のヘッダーフィールド（最小量のパディングが使用されている場合）によって使用される10〜13バイト以外の、パケット拡張の唯一のソースです。
In AUTH_AES_GMAC, the AH Authentication Data field consists of the IV and the Authentication Tag, as shown in Figure 5. Unlike the usual AH case, the Authentication Data field contains both an input to the authentication algorithm (the IV) and the output of the authentication algorithm (the tag). No padding is required in the Authentication Data field, because its length is a multiple of 64 bits.
AUTH_AES_GMACでは、図5に示すように、AHのAuthentication Data（認証データ）フィールドはIVと認証タグで構成されます。通常のAHのケースとは異なり、Authentication Dataフィールドには、認証アルゴリズムへの入力（IV）と認証アルゴリズムの出力（タグ）の両方が含まれます。Authentication Dataフィールドの長さは64ビットの倍数であるため、パディングは不要です。
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 (IV) |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Integrity Check Value (ICV) (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: The AUTH_AES_GMAC Authentication Data Format
図5：AUTH_AES_GMAC認証データのフォーマット
The IV is as described in Section 3.1. The Integrity Check Value (ICV) is as described in Section 3.4.
IVはセクション3.1で説明したとおりです。整合性チェック値（ICV）はセクション3.4で説明されています。
The GMAC Nonce input is formed as described in Section 3.2. The GMAC AAD input consists of the authenticated data as defined in Section 3.1 of [RFC4302]. These values are provided as to that algorithm, along with the secret key, and the resulting authentication tag given as output is used to form the ICV.
GMACのノンス（Nonce）入力は、セクション3.2で説明されているように構成されます。GMACのAAD入力は、[RFC4302]のセクション3.1で定義されている認証データで構成されます。これらの値は、秘密鍵とともにそのアルゴリズムに提供され、出力として得られる結果の認証タグがICVを構成するために使用されます。
This section describes the conventions used to generate keying material and salt values for use with ENCR_NULL_AUTH_AES_GMAC and AUTH_AES_GMAC using the Internet Key Exchange (IKE) versions one [RFC2409] and two [RFC4306].
このセクションでは、Internet Key Exchange (IKE) バージョン1 [RFC2409] およびバージョン2 [RFC4306] を使用して、ENCR_NULL_AUTH_AES_GMACおよびAUTH_AES_GMACで使用する鍵生成素材 (keying material) とソルト値を生成するために使用される規則について説明します。
This document does not specify the conventions for using AES-GMAC for IKE Phase 1 negotiations. For AES-GMAC to be used in this manner, a separate specification would be needed, and an Encryption Algorithm Identifier would need to be assigned. Implementations SHOULD use an IKE Phase 1 cipher that is at least as strong as AES-GMAC. The use of AES-CBC [RFC3602] with the same AES key size as used by ENCR_NULL_AUTH_AES_GMAC or AUTH_AES_GMAC is RECOMMENDED.
本文書では、IKEフェーズ1ネゴシエーションでAES-GMACを使用するための規則については規定していません。AES-GMACをこの方法で使用するには、別の仕様が必要となり、暗号化アルゴリズム識別子を割り当てる必要があります。実装は、少なくともAES-GMACと同等の強度を持つIKEフェーズ1暗号を使用すべきです (SHOULD)。ENCR_NULL_AUTH_AES_GMACまたはAUTH_AES_GMACで使用されるものと同じAES鍵サイズでAES-CBC [RFC3602]を使用することが推奨されます (RECOMMENDED)。
For IKE Phase 2 negotiations, IANA has assigned identifiers as described in Section 9.
IKEフェーズ2ネゴシエーションの場合、IANAはセクション9で説明されているように識別子を割り当てています。
AES-GMAC can be used with any of the three AES key lengths. The way that the key length is indicated is different for AH and ESP.
AES-GMACは、3つのAESキー長のいずれでも使用できます。キーの長さが示される方法は、AHとESPで異なります。
For AH, each key length has its own separate integrity transform identifier and algorithm name (Section 9). The IKE Key Length attribute MUST NOT be used with these identifiers. This transform MUST NOT be used with ESP.
AHの場合、各鍵長には独自の整合性変換識別子とアルゴリズム名が割り当てられています（セクション9）。IKEのKey Length属性をこれらの識別子とともに使用してはなりません (MUST NOT)。また、この変換をESPで使用してはなりません (MUST NOT)。
For ESP, there is a single encryption transform identifier (which represents the combined transform) (Section 9). The IKE Key Length attribute MUST be used with each use of this identifier to indicate the key length. The Key Length attribute MUST have a value of 128, 192, or 256.
ESPの場合、単一の暗号化変換識別子（結合変換を表す）が存在します（セクション9）。鍵長を示すために、この識別子を使用するたびにIKEのKey Length属性を使用しなければなりません (MUST)。Key Length属性の値は128、192、または256でなければなりません (MUST)。
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 ENCR_NULL_AUTH_AES_GMAC and AUTH_AES_GMAC MUST be four octets longer than is needed for the associated AES key. The keying material is used as follows:
ENCR_NULL_AUTH_AES_GMACおよびAUTH_AES_GMACに対するKEYMATのsizeは、関連するAES鍵に必要な長さよりも4オクテット長くなければなりません (MUST)。鍵生成素材は以下のように使用されます。
ENCR_NULL_AUTH_AES_GMAC with a 128-bit key and AUTH_AES_128_GMAC The KEYMAT requested for each AES-GMAC 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ビット鍵のENCR_NULL_AUTH_AES_GMACおよびAUTH_AES_128_GMAC：各AES-GMAC鍵に対して要求されるKEYMATは20オクテットです。最初の16オクテットは128ビットのAES鍵であり、残りの4オクテットはノンスのソルト値として使用されます。
ENCR_NULL_AUTH_AES_GMAC with a 192-bit key and AUTH_AES_192_GMAC The KEYMAT requested for each AES-GMAC 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ビット鍵のENCR_NULL_AUTH_AES_GMACおよびAUTH_AES_192_GMAC：各AES-GMAC鍵に対して要求されるKEYMATは28オクテットです。最初の24オクテットは192ビットのAES鍵であり、残りの4オクテットはノンスのソルト値として使用されます。
ENCR_NULL_AUTH_AES_GMAC with a 256-bit key and AUTH_AES_256_GMAC The KEYMAT requested for each AES-GMAC 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ビット鍵のENCR_NULL_AUTH_AES_GMACおよびAUTH_AES_256_GMAC：各AES-GMAC鍵に対して要求されるKEYMATは36オクテットです。最初の32オクテットは256ビットのAES鍵であり、残りの4オクテットはノンスのソルト値として使用されます。
Appendix B of [GCM] provides test vectors that will assist implementers with AES-GMAC.
[GCM] の付録Bでは、実装者がAES-GMACを実装するのを支援するテストベクトルが提供されています。
Since the authentication coverage is different between AES-GCM-ESP and this specification (see Figure 4), it is worth pointing out that both specifications are secure. In ENCR_NULL_AUTH_AES_GMAC, the IV is not included in either the plaintext or the additional authenticated data. This does not adversely affect security, because the IV field only provides an input to the GMAC IV, which is not required to be authenticated (see [GCM]). In AUTH_AES_GMAC, the IV is included in the additional authenticated data. This fact has no adverse effect on security; it follows from the property that GMAC is secure even against attacks in which the adversary can manipulate both the IV and the message. Even an adversary with these powerful capabilities cannot forge an authentication tag for any message (other than one that was submitted to the chosen-message oracle). Since such an adversary could easily choose messages that contain the IVs with which they correspond, there are no security problems with the inclusion of the IV in the AAD.
AES-GCM-ESPと本仕様では認証の対象範囲が異なるため（図4を参照）、両方の仕様が安全であることを指摘する価値があります。ENCR_NULL_AUTH_AES_GMACでは、IVは平文にも追加の認証データ（AAD）にも含まれていません。これは、IVフィールドがGMACのIVへの入力のみを提供し、IV自体は認証される必要がないため、セキュリティに悪影響を及ぼしません（[GCM]を参照）。AUTH_AES_GMACでは、IVは追加の認証データに含まれています。この事実はセキュリティに悪影響を及ぼしません。これは、攻撃者がIVとメッセージの両方を操作できる攻撃に対してもGMACが安全であるという特性に基づいています。これほど強力な能力を持つ攻撃者であっても、任意のメッセージ（選択メッセージオラクルに送信されたメッセージを除く）に対する認証タグを偽造することはできません。このような攻撃者は、対応するIVを含むメッセージを容易に選択できるため、AADにIVを含めることによるセキュリティ上の問題はありません。
GMAC is provably secure against adversaries that can adaptively choose plaintexts, 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 GMAC implies a break of the underlying block cipher. The proof of security is available in [GCMP].
GMACは、標準的な暗号の仮定（大まかには、ランダムに選択された鍵の下での基礎となる暗号の出力が、ランダムに選択された出力と区別できないこと）の下で、平文、ICV、およびAADフィールドを適応的に選択できる攻撃者に対して、証明可能安全（provably secure）です。本質的にこれは、意図されたパラメータ内で使用される場合、GMACの安全性の崩壊は基礎となるブロック暗号の崩壊を意味します。安全性の証明は [GCMP] で入手可能です。
The most important security consideration is that the IV never repeats for a given key. In part, this is handled by disallowing the use of AES-GMAC when using statically configured keys, as discussed in Section 2.
最も重要なセキュリティ上の考慮事項は、特定の鍵に対してIVが決して重複しないことです。部分的には、これはセクション2で議論したように、静的に設定された鍵を使用する場合にAES-GMACの使用を禁止することによって対処されます。
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 protect 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 or AH implementations that permit use of the same key for protecting packets with the same peer MUST ensure that the two peers assign different salt values to the security association (SA).
IKEを使用して2つのピアエンティティ間で新しいキーを確立すると、2つのトラフィックフローに対して別々のキーが確立されます。新しいキーを確立するために別のメカニズムを使用する場合、1つのキーだけを確立してパケットを保護するメカニズムの場合、ピアが一部のパケットに対して同じIV値を選択する可能性が高くなります。したがって、カウンターブロックの衝突を回避するために、同じピアでパケットを保護するために同じキーの使用を許可するESPまたはAH実装は、2つのピアがセキュリティアソシエーション（SA）に異なるソルト値を割り当てることを保証する必要があります。
The other consideration is that, as with any block cipher mode of operation, 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 processing 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, GMAC calls the block cipher only once.
各メッセージについて、GMACはブロック暗号を1回だけ呼び出すことに注意してください。
This specification was designed to be as similar to AES-GCM-ESP [RFC4106] as possible. We re-use the design and implementation experience from that specification. We include all three AES key sizes since AES-GCM-ESP supports all of those sizes, and the larger key sizes provide future users with more high-security options.
この仕様は、AES-GCM-ESP [RFC4106]にできるだけ類似するように設計されています。その仕様の設計と実装の経験を再利用します。 AES-GCM-ESPはこれらすべてのサイズをサポートしているため、3つのAESキーサイズすべてが含まれています。また、キーサイズが大きいほど、将来のユーザーにより高いセキュリティオプションが提供されます。
IANA has assigned the following IKEv2 parameters. For the use of AES GMAC in AH, the following integrity (type 3) transform identifiers have been assigned:
IANAは、次のIKEv2パラメータを割り当てています。 AHでAES GMACを使用するために、次の整合性（タイプ3）変換識別子が割り当てられています。
"9" for AUTH_AES_128_GMAC
AUTH_AES_128_GMACの場合は「9」
"10" for AUTH_AES_192_GMAC
AUTH_AES_192_GMACの場合は「10」
"11" for AUTH_AES_256_GMAC
AUTH_AES_256_GMACの場合は「11」
For the use of AES-GMAC in ESP, the following encryption (type 1) transform identifier has been assigned:
ESPでAES-GMACを使用するために、次の暗号化（タイプ1）変換識別子が割り当てられています。
"21" for ENCR_NULL_AUTH_AES_GMAC
ENCR_NULL_AUTH_AES_GMACの場合は「21」
Our discussions with Fabio Maino and David Black significantly improved this specification, and Tero Kivinen provided us with useful comments. Steve Kent provided guidance on ESP interactions. This work is closely modeled after AES-GCM, which itself is closely modeled after Russ Housley's AES-CCM transform [RFC4309]. Additionally, the GCM mode of operation was originally conceived as an improvement to the CWC mode [CWC] in which Doug Whiting and Yoshi Kohno participated. We express our thanks to Fabio, David, Tero, Steve, Russ, Doug, and Yoshi.
Fabio MainoおよびDavid Blackとの議論によって本仕様は大幅に改善され、Tero Kivinenからは有益なコメントを提供していただきました。Steve KentからはESPの相互作用に関するガイダンスをいただきました。本作はAES-GCMを緊密にモデル化しており、それ自体はRuss HousleyによるAES-CCM変換 [RFC4309] をモデルにしています。また、GCMの動作モードは、もともとDoug WhitingとYoshi Kohnoが参加したCWCモード [CWC] の改良として考案されたものです。Fabio、David、Tero、Steve、Russ、Doug、そしてYoshiに感謝の意を表します。
[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, "The Galois/Counter Mode of Operation (GCM)", Submission to 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月。
[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月。
[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]河野T.、Viega、J。、およびD. Whiting、「CWC：高性能の従来の認証済み暗号化モード」、高速ソフトウェア暗号化。 http://eprint.iacr.org/2003/106.pdf、2004年2月。
[GCMP] McGrew, D. and J. Viega, "The Security and Performance of the Galois/Counter Mode (GCM)", Proceedings of INDOCRYPT '04, http://eprint.iacr.org/2004/193, December 2004.
[GCMP] McGrew、D。およびJ. Viega、「セキュリティとガロア/カウンターモード（GCM）のパフォーマンス」、INDOCRYPT '04の議事録、http：//eprint.iacr.org/2004/193、2004年12月。
[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月。
[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、「IPsecカプセル化セキュリティペイロード（ESP）でのガロア/カウンターモード（GCM）の使用」、RFC 4106、2005年6月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4306] Kaufman, C., "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月。
Authors' Addresses
著者の連絡先
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
John Viega McAfee, Inc. 1145 Herndon Parkway, Suite 500 Herndon, VA 20170
John Viega McAfee、Inc. 1145 Herndon Parkway、Suite 500 Herndon、VA 20170
EMail: viega@list.org
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2006).
Copyright（C）The Internet Society（2006）。
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.
このドキュメントとここに含まれる情報は「現状のまま」で提供され、寄稿者、その代理またはスポンサー（もしあれば）組織、The 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（ietf-ipr@ietf.org）に送付してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポート活動（IASA）によって提供されます。