[要約] RFC 4543は、IPsec ESPおよびAHでGalois Message Authentication Code（GMAC）の使用に関するガイドラインです。このRFCの目的は、IPsecでのGMACの適切な使用方法を提供することです。
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でのガロアメッセージ認証コード（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
1. Introduction
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入力をノンスと呼びます。 nonceとキーの組み合わせを再利用するとAES-GMACのセキュリティ保証が失われるため、同じnonceとキーの組み合わせを複数回使用してはなりません（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.
この制限のため、静的に構成されたキーを使用する場合、このモードを安全に使用することは困難です。セキュリティを確保するために、実装では、インターネットキーエクスチェンジ（IKE）（バージョン2 [RFC4306]またはバージョン1 [RFC2409]）などの自動キー管理システムを使用して、この要件が満たされるようにする必要があります。
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結合モードと同様に、暗号化トランスフォームまたは「タイプ1」トランスフォームとしてIKEv2に登録されます。他のESP暗号化トランスフォーム（特定のESPカプセル化内）と組み合わせて使用してはなりません（MUST NOT）。機密性が必要な場合は、代わりにGCM ESP [RFC4106]を使用する必要があります。
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オクテットでなければなりません。与えられたキーに対して、IVは繰り返されてはいけません。この要件を満たす最も自然な方法は、カウンターを使用してIVを設定することですが、実装は、線形フィードバックシフトレジスタ（LFSR）などの一意性を保証する方法でIVフィールドを自由に設定できます。送信側は、受信側と調整することなく、一意性要件を満たすIV生成方法を使用できることに注意してください。
The nonce passed to the AES-GMAC authentication algorithm has the following layout:
AES-GMAC認証アルゴリズムに渡されるnonceのレイアウトは次のとおりです。
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：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 5.4.
ソルトソルトフィールドは、セキュリティアソシエーションの開始時に割り当てられる4オクテットの値であり、セキュリティアソシエーションの存続期間中は一定のままです。ソルトは、選択される前は予測不可能である（つまり、ランダムに選択される）必要がありますが、秘密にする必要はありません。セクション5.4で、インターネットキー交換を介して確立されたセキュリティアソシエーションにソルトを設定する方法について説明します。
Initialization Vector The IV field is described in Section 3.1.
初期化ベクトル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、（拡張）シーケンス番号、認証済みペイロード、パディング、パッド長、次のヘッダーの各フィールドには、データ整合性とデータ発信元認証が用意されています。これは、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]の場合、これは変換タイプ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認証タグのみで構成されています。認証タグは切り詰められてはならないため、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に示します。この図は、拡張シーケンス番号オプションが使用されていない場合を示しています。このオプションを実行すると、図の[シーケンス番号]フィールドが[拡張シーケンス番号]に置き換えられます。
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認証データフィールドはIVと認証タグで構成されます。通常のAHの場合とは異なり、認証データフィールドには認証アルゴリズムへの入力（IV）と認証アルゴリズム（タグ）。その長さが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].
このセクションでは、インターネットキーエクスチェンジ（IKE）バージョン1 [RFC2409]および2 [RFC4306]を使用して、ENCR_NULL_AUTH_AES_GMACおよびAUTH_AES_GMACで使用するキーマテリアルとソルト値を生成するために使用される規則について説明します。
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]を使用することをお勧めします。
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キーの長さ属性は、これらの識別子と一緒に使用してはなりません。この変換は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キーの長さ属性を使用して、キーの長さを示す必要があります。キーの長さ属性には、128、192、または256の値が必要です。
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のサイズは、関連するAESキーに必要な長さより4オクテット長くなければなりません。キー素材は次のように使用されます。
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.
ENCR_NULL_AUTH_AES_GMACと128ビットキーおよび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.
ENCR_NULL_AUTH_AES_GMACと192ビットのキーおよび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.
ENCR_NULL_AUTH_AES_GMACと256ビットキーおよび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はプレーンテキストにも追加の認証済みデータにも含まれていません。 IVフィールドはGMAC 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フィールドを適応的に選択できる敵対者に対して確実に安全です（ランダムに選択されたキーの下での基礎となる暗号の出力は、ランダムに選択された出力と区別できません）。基本的に、これは、意図したパラメーター内で使用された場合、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ブロックのデータを処理する前に、新しいキーを生成する必要があります。 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の動作モードは、元々、ダグホワイティングと河野義が参加した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.および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月。
[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.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネットエンジニアリングおよびインターネットエンジニアリングタスクフォースは、すべての保証を明示的または明示的に提供します。ここに含まれる情報の使用により、商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害されないという保証を含みますが、これに限定されるものではありません。
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 provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポート活動（IASA）によって提供されます。