RFC4106 日本語訳

Network Working Group                                           J. Viega
Request for Comments: 4106                         Secure Software, Inc.
Category: Standards Track                                      D. McGrew
                                                     Cisco Systems, Inc.
                                                               June 2005

Viegaがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 4106年の安全なソフトウェアInc.カテゴリ: 標準化過程D.マグリューシスコシステムズInc.2005年6月

                 The Use of Galois/Counter Mode (GCM)
             in IPsec Encapsulating Security Payload (ESP)

セキュリティが有効搭載量であるとカプセル化するIPsecにおけるガロア/カウンタモード(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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(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.

このメモは、発生源認証を秘密性とデータに提供するためにガロア/カウンタMode(GCM)におけるエー・イー・エス(AES)の使用をIPsec Encapsulating Security有効搭載量(超能力)メカニズムと説明します。 このメソッドは、1秒あたり10のギガビットの速度のためのハードウェアと上で効率的に実装して、また、ソフトウェア実行に十分合うことができます。

Table of Contents

目次

   1. Introduction ....................................................2
      1.1. Conventions Used in This Document ..........................2
   2. AES-GCM .........................................................3
   3. ESP Payload Data ................................................3
      3.1. Initialization Vector (IV) .................................3
      3.2. Ciphertext .................................................4
   4. Nonce Format ....................................................4
   5. AAD Construction ................................................5
   6. Integrity Check Value (ICV) .....................................5
   7. Packet Expansion ................................................6
   8. IKE Conventions .................................................6
      8.1. Keying Material and Salt Values ............................6
      8.2. Phase 1 Identifier .........................................6
      8.3. Phase 2 Identifier .........................................7
      8.4. Key Length Attribute .......................................7

1. 序論…2 1.1. このドキュメントで中古のコンベンション…2 2. AES-GCM…3 3. 超能力有効搭載量データ…3 3.1. 初期設定ベクトル(IV)…3 3.2. 暗号文…4 4. 一回だけの形式…4 5. AAD工事…5 6. 保全チェック価値(ICV)…5 7. パケット拡張…6 8. IKEコンベンション…6 8.1. 材料と塩の値を合わせます…6 8.2. 1つの識別子の位相を合わせてください…6 8.3. 2識別子の位相を合わせてください…7 8.4. キー長属性…7

Viega & McGrew              Standards Track                     [Page 1]

RFC 4106                        GCM ESP                        June 2005

ViegaとマグリューStandardsはGCM超能力2005年6月にRFC4106を追跡します[1ページ]。

   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

9. ベクトルをテストしてください…7 10. セキュリティ問題…7 11. 原理を設計してください…8 12. IANA問題…8 13. 承認…9 14. 標準の参照…9 15. 有益な参照…9

1.  Introduction

1. 序論

   This document describes the use of AES in GCM mode (AES-GCM) as an
   IPsec ESP mechanism for confidentiality and data origin
   authentication.  We refer to this method as AES-GCM-ESP.  This
   mechanism is not only efficient and secure, but it also enables
   high-speed implementations in hardware.  Thus, AES-GCM-ESP allows
   IPsec connections that can make effective use of emerging 10-gigabit
   and 40-gigabit network devices.

このドキュメントは、GCMモード(AES-GCM)におけるAESの使用を秘密性とデータ発生源認証のためのIPsec超能力メカニズムと説明します。 私たちはAES-GCM-超能力とこのメソッドを呼びます。 このメカニズムは、効率的であるだけであって安全ではありませんが、また、それはハードウェアの高速実装を可能にします。 したがって、AES-GCM-超能力は現れている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)は高速実装のための都合のよい暗号化メソッドとして現れました。 それをpipelinedされることができるので、Cipher Block Chainingなどの従来の暗号化モード(CBC)とCipher Block Chainingメッセージ立証コード(CBC-MAC)と異なって、高いデータ信号速度で効率的にCTRを実装することができます。 ESP CTRプロトコルは、IPsecと共にこのモードをどのように使用できるかを説明します。超能力[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に関連してデータ発生源認証アルゴリズムの使用を必要とします。 この要件は問題が多いです、高いデータ信号速度のために効率的に標準のデータ発生源認証アルゴリズムのどれかを実装することができないので。 フードの下で安全で、parallelizableであって、効率的な認証機構にCTRモードを結合するので、GCMはこの問題を解決します。

   This document does not cover implementation details of GCM.  Those
   details can be found in [GCM], along with test vectors.

このドキュメントはGCMの実装細部をカバーしていません。 テストベクトルと共に[GCM]でそれらの詳細を見つけることができます。

1.1.  Conventions Used in This Document

1.1. 本書では使用されるコンベンション

   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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?

Viega & McGrew              Standards Track                     [Page 2]

RFC 4106                        GCM ESP                        June 2005

ViegaとマグリューStandardsはGCM超能力2005年6月にRFC4106を追跡します[2ページ]。

2.  AES-GCM

2. AES-GCM

   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は暗号化を認証しました。操作には、4つの入力があります: 追加認証されたデータ(AAD)のための秘密鍵、初期化ベクトル(IV)、平文、および入力。 それは2回の出力、長さが平文と同じである暗号文、および認証タグを持っています。 以下では、私たちは、IV、平文、およびAADが超能力分野からどのように形成されるか、そして、超能力パケットが暗号文と認証タグからどのように形成されるかを説明します。

   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.

また、超能力はIVを定義します。 明快について、私たちはAES-GCM-超能力の文脈の一回だけとAES-GCM IVを呼びます。 一度より同じ一回だけの、そして、主要な組み合わせを使用してはいけません。

   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モードのセキュリティ保証が煙滅するので、静的に構成されたキーを使用するとき、しっかりとこのモードを使用するのは難しい場合があります。 安全のために、実装は、この必要条件が満たされるのを保証するのに、インターネット・キー・エクスチェンジなどの自動化されたかぎ管理システム(IKE)[RFC2409]を使用しなければなりません。

3.  ESP Payload Data

3. 超能力有効搭載量データ

   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.

超能力有効搭載量Dataは暗号文があとに続いた8八重奏の初期化ベクトル(IV)から成ります。 [RFC2406]で定義されるペイロード分野は図1に示されるように構造化されます、ペイロードに関連しているICVと共に。

    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)                   ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 初期設定ベクトル| | (8つの八重奏) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 暗号文(可変)~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 1: ESP Payload Encrypted with AES-GCM.

図1: AES-GCMと共に暗号化された超能力有効搭載量。

3.1.  Initialization Vector (IV)

3.1. 初期設定ベクトル(IV)

   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

AES-GCM-超能力IV分野は8つの八重奏であるに違いありません。 与えられたキーに関しては、IVは繰り返されてはいけません。 これを実装する最も自然な方法がカウンタをもってありますが、ユニークさを保証する何でも使用できます、あれほどです。

Viega & McGrew              Standards Track                     [Page 3]

RFC 4106                        GCM ESP                        June 2005

ViegaとマグリューStandardsはGCM超能力2005年6月にRFC4106を追跡します[3ページ]。

   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.

直線的なフィードバック・シフト・レジスタ(LFSR)。 encrypterがdecrypterで調整しないでユニークさの必要条件を満たすどんなIV世代メソッドも使用できることに注意してください。

3.2.  Ciphertext

3.2. 暗号文

   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への平文入力は、Padding、Pad Length、およびNext Header分野でNext Header分野によって説明された平文データを連結することによって、形成されます。 Ciphertext分野は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使用の長さを隠そうとしない実装。

4.  Nonce Format

4. 一回だけの形式

   The nonce passed to the GCM-AES encryption algorithm has the
   following layout:

GCM-AES暗号化アルゴリズムに通過された一回だけは以下のレイアウトを持っています:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Salt                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Initialization Vector                     |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 塩| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 初期設定ベクトル| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          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.

塩がさばく塩はセキュリティ協会の始めに割り当てられて、次にセキュリティ協会の寿命に一定のままで残っている4八重奏の値です。 塩のSHOULDはそれが選択される前に予測できませんが(すなわち、無作為に選ばれています)、秘密である必要はありません。 私たちはセクション8.1におけるインターネット・キー・エクスチェンジで設立されたSecurity Associationに塩を設定する方法を説明します。

   Initialization Vector
      The IV field is described in Section 3.1.

Vector IVがさばく初期設定はセクション3.1で説明されます。

Viega & McGrew              Standards Track                     [Page 4]

RFC 4106                        GCM ESP                        June 2005

ViegaとマグリューStandardsはGCM超能力2005年6月にRFC4106を追跡します[4ページ]。

5.  AAD Construction

5. AAD工事

   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と(広げられる)の系列Number分野へのデータ保全とデータ発生源の認証を提供します。 AES-GCM Additional Authenticated Data(AAD)分野にそれらの分野を含んでいることによって、これをします。 AADの2つの書式が定義されます: 32ビットの一連番号のためのもの、および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                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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ビットの一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             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               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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ビットの拡張配列番号| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 4: AAD Format with 64-bit Extended Sequence Number

図4: 64ビットの拡張配列番号があるAAD形式

6.  Integrity Check Value (ICV)

6. 保全チェック価値(ICV)

   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 Authentication Tagから成ります。 実装は、等身大の16八重奏がICVであるとサポートしなければならなくて、8か12八重奏がICVsであるとサポートするかもしれなくて、他のICVの長さはサポートしてはいけません。 超能力は、ICVが存在しているのを必要としませんが、AES-GCM-超能力は故意に無の長さのICVを許容しません。 これは無の長さのAuthentication Tagと共に使用される場合GCMが保全保護を全く提供しないからです。

Viega & McGrew              Standards Track                     [Page 5]

RFC 4106                        GCM ESP                        June 2005

ViegaとマグリューStandardsはGCM超能力2005年6月にRFC4106を追跡します[5ページ]。

7.  Packet Expansion

7. パケット拡張

   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、Sequence Number、Padding、Pad Length、およびNext Header分野によって始められた10-13の八重奏を除いて(詰め物の最少量が使用されているなら)。

8.  IKE Conventions

8. IKEコンベンション

   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.

このセクションは材料を合わせて、塩の値を生成するのに使用されるコンベンションについて説明します、AES-GCM-超能力との使用のために、インターネット・キー・エクスチェンジ(IKE)[RFC2409]プロトコルを使用して。 また、AES-GCM超能力を使用することでセキュリティ協会を交渉するのに必要である識別子と属性は定義されます。

8.1.  Keying Material and Salt Values

8.1. 材料と塩の値を合わせます。

   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)を利用します。 KEYMATは、PRFが任意のサイズの合わせることの材料を誘導するのに繰り返しに使用されると呼びました。 材料を合わせるのは関係のない出力ストリングから境界まで抽出されます。

   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-超能力のためのKEYMATのサイズは関連AESキーに必要とされるより長い4つの八重奏であるに違いありません。 合わせることの材料は以下の通り使用されます:

   AES-GCM-ESP with a 128 bit key
      The KEYMAT requested for each AES-GCM key is 20 octets.  The first
      16 octets are the 128-bit AES key, and the remaining four octets
      are used as the salt value in the nonce.

KEYMATがそれぞれのAES-GCMキーのために要求した128ビットのキーがあるAES-GCM-超能力は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.

KEYMATがそれぞれのAES-GCMキーのために要求した192ビットのキーがあるAES-GCM-超能力は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.

KEYMATがそれぞれのAES GCMキーのために要求した256ビットのキーがあるAES-GCM-超能力は36の八重奏です。 最初の32の八重奏が256ビットのAESキーです、そして、残っている4つの八重奏が塩の値として一回だけで使用されます。

8.2.  Phase 1 Identifier

8.2. フェーズ1識別子

   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

このドキュメントはIKE Phase1交渉にAES-GCMを使用するのにコンベンションを指定しません。 AES-GCMがこの様に使用されるのに、別々の仕様が必要です、そして、Encryption Algorithm Identifierは割り当てられる必要があります。 実装SHOULDはIKEを使用します。

Viega & McGrew              Standards Track                     [Page 6]

RFC 4106                        GCM ESP                        June 2005

ViegaとマグリューStandardsはGCM超能力2005年6月にRFC4106を追跡します[6ページ]。

   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.

AES-GCMと少なくとも同じくらい強い1つの暗号の位相を合わせてください。 同じ主要なサイズがAES-GCM-超能力によって使用されているAES CBC[RFC3602]の使用はRECOMMENDEDです。

8.3.  Phase 2 Identifier

8.3. フェーズ2識別子

   For IKE Phase 2 negotiations, IANA has assigned three ESP Transform
   Identifiers for AES-GCM with an eight-byte explicit IV:

IKE Phase2交渉のために、IANAは8バイトの明白なIVと共にAES-GCMのための3超能力Transform Identifiersを割り当てました:

      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.

18 8八重奏ICVとAES-GCMのために。 19 12八重奏ICVとAES-GCMのために。 そして、16八重奏ICVとAES-GCMのための20。

8.4.  Key Length Attribute

8.4. キー長属性

   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 Phase2交換[RFC2407]でKey Length属性を指定しなければなりません。 Key Length属性に、128、192、または256の値がなければなりません。

9.  Test Vectors

9. テストベクトル

   Appendix B of [GCM] provides test vectors that will assist
   implementers with AES-GCM mode.

[GCM]の付録Bはimplementersを補助するテストベクトルにAES-GCMモードを提供します。

10.  Security Considerations

10. セキュリティ問題

   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は適応型に平文、暗号文、ICVs、およびAAD分野を選ぶことができる敵を証明可能に機密保護することです、標準の暗号の仮定で(およそ、基本的な暗号の出力が手当たりしだいに選ばれたキーの下でaから区別がつかないのが手当たりしだいに出力を選択しました)。 本質的には、これは、意図しているパラメタの中で使用されるなら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に与えられたキーのために決して繰り返されないということです。 一部、これは静的に構成されたキーを使用するときAES-GCMの使用を禁じることによって、扱われます、セクション2で議論するように。

   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

IKEが2つの同輩実体の間の新鮮なキーを証明するのに使用されるとき、別々のキーは2回の交通の流れのために設立されます。 異なったメカニズムが新鮮なキー(パケットを暗号化するために単一のキーだけを設立するもの)を証明するのに使用されるなら、同輩がいくつかのパケットのために同じIV値を選択するという高い確率があります。 したがって、カウンタを避けるには、衝突、超能力を妨げてください。

Viega & McGrew              Standards Track                     [Page 7]

RFC 4106                        GCM ESP                        June 2005

ViegaとマグリューStandardsはGCM超能力2005年6月にRFC4106を追跡します[7ページ]。

   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人の同輩がセキュリティ協会(SA)に異なった塩の値を配属するのを確実にしなければなりません。

   The other consideration is that, as with any encryption mode, the
   security of all data protected under a given security association
   decreases slightly with each message.

もう片方の考慮は与えられたセキュリティ協会の下に保護されたすべてのデータのセキュリティがどんな暗号化モードのようにもわずかに各メッセージで下がるということです。

   To protect against this problem, implementations MUST generate a
   fresh key before encrypting 2^64 blocks of data with a given key.
   Note that it is impossible to reach this limit when using 32-bit
   Sequence Numbers.

この問題から守るために、与えられたキーで2^64ブロックのデータを暗号化する前に、実装は新鮮なキーを生成しなければなりません。 32ビットのSequence民数記を使用するときにはこの限界に達するのが不可能であることに注意してください。

   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八重奏のブロックにブロック暗号を呼ぶことに注意してください、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は妥当であるのと同じくらい大きいサイズを使用します。

11.  Design Rationale

11. デザイン原理

   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-超能力]と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八重奏の一回だけのケースを扱うために最適化されます。 他の長さの一回だけは不要で、追加している複雑さと特にハードウェア実装の遅れを引き起こすでしょう。 一回だけの追加八重奏は、塩のサイズを増強するのに使用されます。

12.  IANA Considerations

12. IANA問題

   IANA has assigned three ESP Transform Identifiers for AES-GCM with an
   eight-byte explicit IV:

IANAはAES-GCMのために8バイトの明白なIVと共に3超能力Transform Identifiersを割り当てました:

      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.

18 8八重奏ICVとAES-GCMのために。 19 12八重奏ICVとAES-GCMのために。 そして、16八重奏ICVとAES-GCMのための20。

Viega & McGrew              Standards Track                     [Page 8]

RFC 4106                        GCM ESP                        June 2005

ViegaとマグリューStandardsはGCM超能力2005年6月にRFC4106を追跡します[8ページ]。

13.  Acknowledgements

13. 承認

   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.

ラスHousleyのAES-CCMが[CCM-超能力]を変えた後にこの仕事は密接にモデル化されます。 このドキュメントの一部がその処理中の作業から直接コピーされます。 私たちは彼のこの仕事のサポートについてラスに感謝します。

   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運転モードは元々、カーター-ウェッグマンCounter(CWC)モード[CWC](高速認証された暗号化をサポートすることができる最初の邪魔されないブロック暗号モード)への改良として発想されました。

14.  Normative References

14. 引用規格

   [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] NIST. http://csrc.nist.gov/CryptoToolkit/モード/proposedmodes/gcm/gcm-spec.pdf、2004年1月までのマグリューとD.とJ.Viega、「ガロア/カウンタ運転モード(GCM)」Submission。

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [RFC2406]  Kent, S. and R. Atkinson, "IP Encapsulating Security
              Payload (ESP)", RFC 2406, November 1998.

[RFC2406]ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。

   [RFC2407]  Piper, D., "The Internet IP Security Domain of
              Interpretation for ISAKMP", RFC 2407, November 1998.

[RFC2407]パイパー、D.、「ISAKMPのための解釈のインターネットIPセキュリティー領域」、RFC2407、1998年11月。

   [RFC3602]  Frankel, S., Glenn, R. and S. Kelly, "The AES-CBC Cipher
              Algorithm and Its Use with IPsec", RFC 3602, September
              2003.

[RFC3602] フランケル、S.、グレン、R.、およびS.ケリー、「AES-CBCはIPsecと共にアルゴリズムとその使用を解きます」、RFC3602、2003年9月。

15.  Informative References

15. 有益な参照

   [CCM-ESP]  Housley, R., "Using AES CCM Mode With IPsec ESP", Work In
              Progress.

[立方センチメートル超能力]Housley、R.、「IPsecがあるAES立方センチメートルモードを使用する、超能力、」 仕事進行中です。

   [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.ホワイティング、「CWC:」 「高い性能従来の認証された暗号化モード」、Fast Software Encryption 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]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 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が、セキュリティが有効搭載量(超能力)であるとカプセル化しているエー・イー・エス(AES)カウンタモードを使用します」、RFC3686、2004年1月。

Viega & McGrew              Standards Track                     [Page 9]

RFC 4106                        GCM ESP                        June 2005

ViegaとマグリューStandardsはGCM超能力2005年6月にRFC4106を追跡します[9ページ]。

Authors' Addresses

作者のアドレス

   John Viega
   Secure Software, Inc.
   4100 Lafayette Center Dr., Suite 100
   Chantilly, VA  20151
   US

ジョンViegaの安全なソフトウェアInc.4100ラファイエットセンタースイート100シャンティイ、ヴァージニア20151博士(米国)

   Phone: (703) 814 4402
   EMail: viega@securesoftware.com

以下に電話をしてください。 (703) 814 4402はメールされます: viega@securesoftware.com

   David A. McGrew
   Cisco Systems, Inc.
   510 McCarthy Blvd.
   Milpitas, CA  95035
   US

デヴィッドA.マグリューシスコシステムズInc.510マッカーシーBlvd. ミルピタス、カリフォルニア95035米国

   Phone: (408) 525 8651
   EMail: mcgrew@cisco.com
   URI:   http://www.mindspring.com/~dmcgrew/dam.htm

以下に電話をしてください。 (408) 525 8651はメールされます: mcgrew@cisco.com ユリ: http://www.mindspring.com/~dmcgrew/dam.htm

Viega & McGrew              Standards Track                    [Page 10]

RFC 4106                        GCM ESP                        June 2005

ViegaとマグリューStandardsはGCM超能力2005年6月にRFC4106を追跡します[10ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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 ipr@ietf.org のIETFに情報を扱ってください。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Viega & McGrew              Standards Track                    [Page 11]

Viegaとマグリュー標準化過程[11ページ]