RFC4543 日本語訳

Network Working Group                                          D. McGrew
Request for Comments: 4543                           Cisco Systems, Inc.
Category: Standards Track                                       J. Viega
                                                            McAfee, Inc.
                                                                May 2006

コメントを求めるワーキンググループD.マグリュー要求をネットワークでつないでください: 4543年のシスコシステムズInc.カテゴリ: 標準化過程J.ViegaマカフィーInc.2006年5月

        The Use of Galois Message Authentication Code (GMAC) in
                            IPsec ESP and AH

ガロアの通報認証の使用はIPsecで超能力をコード化します、そして、(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.

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

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2006).

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

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

McGrew & Viega              Standards Track                     [Page 1]

RFC 4543                GMAC in IPsec ESP and AH                May 2006

マグリューとViega規格がIPsecでRFC4543GMACを追跡する、[1ページ]ああ、超能力と2006年5月

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

1. 序論…2 1.1. このドキュメントで中古のコンベンション…3 2. AES-GMAC…3 3. 超能力におけるAES-GMACの使用…3 3.1. 初期設定ベクトル…4 3.2. 一回だけの形式…4 3.3. AAD工事…5 3.4. 保全チェック価値(ICV)…6 3.5. AES-GCM-超能力に伴う違い…6 3.6. パケット拡張…7 4. 中のAES-GMACの使用、ああ…7 5. IKEコンベンション…8 5.1. 1つの識別子の位相を合わせてください…8 5.2. 2識別子の位相を合わせてください…8 5.3. キー長属性…9 5.4. 材料と塩の値を合わせます…9 6. ベクトルをテストしてください…9 7. セキュリティ問題…10 8. 原理を設計してください…11 9. IANA問題…11 10. 承認…11 11. 参照…12 11.1. 標準の参照…12 11.2. 有益な参照…12 1. 序論

   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.

このドキュメントは、AES-GMACモード(AES-GMAC)の使用を超能力[RFC4303]とAH[RFC4302]でのデータ発生源認証のためのメカニズムと説明します。 私たちはそれぞれENCR_NULL_AUTH_AES_GMACとAUTH_AES_GMACとこれらのメソッドを呼びます。 ENCR_NULL_AUTH_AES_GMACはAESガロア/カウンタModeの仲間です。超能力[RFC4106]。(その超能力は秘密性と同様に認証を提供します)。 ENCR_NULL_AUTH_AES_GMACは秘密性が望まれていない場合のために意図します。 GCMのように、GMACは効率的であって、安全であり、ハードウェアの高速実装に従順です。 ENCR_NULL_AUTH_AES_GMACとAUTH_AES_GMACは、実装の増分費用(実装がAES-GCM-超能力であるという当然のこと)が小さいように、設計されています。

   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]でそれらの詳細を見つけることができます。

McGrew & Viega              Standards Track                     [Page 2]

RFC 4543                GMAC in IPsec ESP and AH                May 2006

マグリューとViega規格がIPsecでRFC4543GMACを追跡する、[2ページ]ああ、超能力と2006年5月

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]で説明されるように本書では解釈されることであるべきですか?

2.  AES-GMAC

2. AES-GMAC

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

   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.

以下では、私たちがAES-GMAC IV入力を一回だけと呼びます、パケットのIV分野とそれを区別するために。 同じ一回だけの、そして、主要な組み合わせは一度より使用されてはいけなくて、以来一回だけの、または、主要な組み合わせを再利用すると、AES-GMACのセキュリティ保証は破壊されます。

   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)(バージョンtwo[RFC4306]かバージョン1のどちらか[RFC2409])を使用しなければなりません。

3.  The Use of AES-GMAC in ESP

3. 超能力におけるAES-GMACの使用

   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.

超能力のためのAES-GMACアルゴリズムは超能力保全アルゴリズムよりむしろ超能力「結合したモード」アルゴリズム(.3セクション3.2[RFC4303]を見る)と定義されます。 それは、暗号化を全く実行しないで、また秘密性を全く提供しないという事実を目立たせるように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.

原理: 超能力は有効搭載量分野の中に初期化ベクトルを置くために保全変換に備えません。 暗号化変換だけがIVsを使用すると予想されます。 暗号化変換とGMACを定義するのは、この問題を避けて、GMACがGCMのように同じパイプライン処理の利益を得るのを許容します。

McGrew & Viega              Standards Track                     [Page 3]

RFC 4543                GMAC in IPsec ESP and AH                May 2006

マグリューとViega規格がIPsecでRFC4543GMACを追跡する、[3ページ]ああ、超能力と2006年5月

   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.

すべての超能力がモードを結合したように、それは暗号化変換、または「タイプの1インチの変換」としてIKEv2に登録されます。 いかなる他の超能力暗号化変換(特定の超能力カプセル化の中の)に関連してそれを使用してはいけません。 秘密性が必要で、当時のGCM ESP[RFC4106]SHOULDであるなら、代わりに使用されてください。

3.1.  Initialization Vector

3.1. 初期設定ベクトル

   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と共に、明白な初期設定Vector(IV)はその分野の着手のときに超能力有効搭載量に含まれています。 長い間、IVは8つの八重奏であるに違いありません。 与えられたキーに関しては、IVは繰り返されてはいけません。 この必要条件を満たす最も自然な方法がカウンタを使用することでIVを設定することですが、実装は自由に直線的なフィードバックシフトなどの保証のユニークさが示されるどんな方法(LFSR)にもIV分野をはめ込むことができます。 送付者が受信機で調整しないでユニークさの必要条件を満たすどんなIV世代メソッドも使用できることに注意してください。

3.2.  Nonce Format

3.2. 一回だけの形式

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

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

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

   Initialization Vector
      The IV field is described in Section 3.1.

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

McGrew & Viega              Standards Track                     [Page 4]

RFC 4543                GMAC in IPsec ESP and AH                May 2006

マグリューとViega規格がIPsecでRFC4543GMACを追跡する、[4ページ]ああ、超能力と2006年5月

3.3.  AAD Construction

3.3. AAD工事

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

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ビットの一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 認証された有効搭載量(可変)~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (0-255バイト)を水増しします。| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | パッドの長さ| 次のヘッダー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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ビットの拡張配列番号| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 認証された有効搭載量(可変)~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (0-255バイト)を水増しします。| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | パッドの長さ| 次のヘッダー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

McGrew & Viega              Standards Track                     [Page 5]

RFC 4543                GMAC in IPsec ESP and AH                May 2006

マグリューとViega規格がIPsecでRFC4543GMACを追跡する、[5ページ]ああ、超能力と2006年5月

   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]).

64ビットの拡張配列番号に従った32ビットの一連番号の使用はSAを作成するのに使用されるセキュリティ協会で決定している(SA)管理プロトコルです。 IKEv2[RFC4306]に関しては、これはTransform Type5を通して交渉されます、そして、超能力のためのデフォルトは交渉がないとき64ビットの拡張配列番号を使用する(例えば、.1セクション2.2[RFC4303]を見てください)ことです。

3.4.  Integrity Check Value (ICV)

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

   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 Authentication Tagから成ります。 Authentication Tagに先端を切らせてはいけないので、ICVの長さは16の八重奏です。

3.5.  Differences with AES-GCM-ESP

3.5. AES-GCM-超能力に伴う違い

   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-超能力[RFC4106]の違いを目立たせます。 本質的な相違は本書では、AADがSPI、Sequence Number、および超能力有効搭載量から成って、AES-GCM平文がゼロ・レングスであるということです、AES-GCM-超能力では、AADはSPIとSequence Numberだけから成ります、そして、AES-GCM平文は超能力有効搭載量から成りますが。 これらの違いは図4で例証されます。 この図はExtended Sequence Numberオプションが使用されていない場合を示しています。 そのオプションを運動させるとき、図の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暗号化がある超能力とどんな*同等物も「オフにしなかった」*です。 しかしながら、どちらの場合も実行されたICV計算はGHASH機能[GCM]の構造のために同様です。

McGrew & Viega              Standards Track                     [Page 6]

RFC 4543                GMAC in IPsec ESP and AH                May 2006

マグリューとViega規格がIPsecでRFC4543GMACを追跡する、[6ページ]ああ、超能力と2006年5月

                     +-> +-----------------------+ <-+
      AES-GCM-ESP    |   |          SPI          |   |
          AAD -------+   +-----------------------+   |
                     |   |    Sequence Number    |   |
                     +-> +-----------------------+   |
                         |    Authentication     |   |
                         |          IV           |   |
                  +->+-> +-----------------------+   +
      AES-GCM-ESP |      |                       |   |
       Plaintext -+      ~       ESP Payload     ~   |
                  |      |                       |   |
                  |      +-----------+-----+-----+   |
                  |      | Padding   |  PL | NH  |   |
                  +----> +-----------+-----+-----+ <-+
                                                     |
                       ENCR_NULL_AUTH_AES_GMAC AAD --+

+->+-----------------------+ <-+、AES-GCM-超能力| | SPI| | AAD-------+ +-----------------------+ | | | 一連番号| | +->+-----------------------+ | | 認証| | | IV| | +>+>+-----------------------+ + AES-GCM-超能力| | | | 平文-+~超能力有効搭載量~| | | | | | +-----------+-----+-----+ | | | 詰め物| PL| ニューハンプシャー| | +---->+-----------+-----+-----+ <-+| ENCR_ヌル_AUTH_AES_GMAC AAD--+

   Figure 4: Differences between ENCR_NULL_AUTH_AES_GMAC and AES-GCM-ESP

図4: ENCR_ヌル_AUTH_AES_GMACとAES-GCM-超能力の違い

3.6.  Packet Expansion

3.6. パケット拡張

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

4.  The Use of AES-GMAC in AH

4. 中のAES-GMACの使用、ああ。

   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では、AH Authentication Data分野は図5に示されるようにIVとAuthentication Tagから成ります。 普通のAHケースと異なって、Authentication Data分野は認証アルゴリズムへの入力(IV)と認証アルゴリズムの出力(タグ)の両方を含んでいます。 長さが64ビットの倍数であるので、水増しはAuthentication Data分野で必要ではありません。

McGrew & Viega              Standards Track                     [Page 7]

RFC 4543                GMAC in IPsec ESP and AH                May 2006

マグリューとViega規格がIPsecでRFC4543GMACを追跡する、[7ページ]ああ、超能力と2006年5月

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

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 初期設定ベクトル(IV)| | (8つの八重奏) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 保全Check Value(ICV)(16の八重奏)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       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で説明されるようにあります。 Integrity Check Value(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を形成するのに使用されるので与えられた結果として起こる認証タグと共に。

5.  IKE Conventions

5. IKEコンベンション

   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].

このセクションはENCR_NULL_AUTH_AES_GMACとの使用のための値を材料を合わせて、塩に生成して、_インターネット・キー・エクスチェンジ(IKE)バージョン1を使用するAES_GMAC[RFC2409]と2[RFC4306]をAUTHに生成するのにおいて中古のコンベンションについて説明します。

5.1.  Phase 1 Identifier

5.1. フェーズ1識別子

   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 Phase1交渉にAES-GMACを使用するのにコンベンションを指定しません。 AES-GMACがこの様に使用されるのに、別々の仕様が必要でしょう、そして、Encryption Algorithm Identifierは割り当てられる必要があるでしょう。 実装SHOULDはAES-GMACと少なくとも同じくらい強いIKE Phase1暗号を使用します。 ENCR_NULL_AUTH_AES_GMACかAUTH_AES_GMACによって使用される同じAESの主要なサイズがあるAES-CBC[RFC3602]の使用はRECOMMENDEDです。

5.2.  Phase 2 Identifier

5.2. フェーズ2識別子

   For IKE Phase 2 negotiations, IANA has assigned identifiers as
   described in Section 9.

IKE Phase2交渉のために、IANAはセクション9で説明されるように識別子を割り当てました。

McGrew & Viega              Standards Track                     [Page 8]

RFC 4543                GMAC in IPsec ESP and AH                May 2006

マグリューとViega規格がIPsecでRFC4543GMACを追跡する、[8ページ]ああ、超能力と2006年5月

5.3.  Key Length Attribute

5.3. キー長属性

   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.

3つのAESキー長のいずれと共にもAES-GMACを使用できます。 AHと超能力において、キー長が示される方法は異なっています。

   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属性を使用してはいけません。 超能力と共にこの変換を使用してはいけません。

   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.

超能力のために、ただ一つの暗号化変換識別子(結合した変換を表します)(セクション9)があります。 キー長を示すのにこの識別子の各使用と共にIKE Key Length属性を使用しなければなりません。 Key Length属性に、128、192、または256の値がなければなりません。

5.4.  Keying Material and Salt Values

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

   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 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 MUSTのための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.

128ビットのキーがあるAES_GMACとAUTH_AES_128_GMAC KEYMATがそれぞれのAES-GMACキーのために要求したENCR_NULL_AUTH_は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ビットのキーがあるAES_GMACとAUTH_AES_192_GMAC KEYMATがそれぞれのAES-GMACキーのために要求したENCR_NULL_AUTH_は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ビットのキーがあるAES_GMACとAUTH_AES_256_GMAC KEYMATがそれぞれのAES-GMACキーのために要求したENCR_NULL_AUTH_は36の八重奏です。 最初の32の八重奏が256ビットのAESキーです、そして、残っている4つの八重奏が塩の値として一回だけで使用されます。

6.  Test Vectors

6. テストベクトル

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

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

McGrew & Viega              Standards Track                     [Page 9]

RFC 4543                GMAC in IPsec ESP and AH                May 2006

マグリューとViega規格がIPsecでRFC4543GMACを追跡する、[9ページ]ああ、超能力と2006年5月

7.  Security Considerations

7. セキュリティ問題

   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-超能力とこの仕様の間で異なっているので(図4を見てください)、両方の仕様が安全であると指摘する価値があります。 ENCR_NULL_AUTH_では、AES_GMAC、IVは平文か追加認証されたデータのどちらかに含まれていません。 これはセキュリティに悪影響を与えません、IV分野がGMAC IV(認証される必要はない)に入力を供給するだけであるので([GCM]を見てください)。 AUTH_AES_では、GMAC、IVは追加認証されたデータに含まれています。 この事実は悪影響を全くセキュリティに及ぼしません。 特性から、GMACが敵がIVとメッセージの両方を操ることができる攻撃に対してさえ安全であるということになります。 これらの強力な能力がある敵さえどんなメッセージ(選ばれたメッセージ神託に提出されたものを除いた)のためにも認証タグを鍛造できません。 そのような敵が容易に彼らが対応するIVsを含むメッセージを選ぶことができたので、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は規格の下で暗号の適応型に平文を選ぶことができる敵、ICVs、および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に与えられたキーのために決して繰り返されないということです。 一部、これは静的に構成されたキーを使用するときAES-GMACの使用を禁じることによって、扱われます、セクション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 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回の交通の流れのために設立されます。 異なったメカニズムが新鮮なキー、パケットを保護するために単一のキーだけを設立するものを証明するのに使用されるなら、同輩がいくつかのパケットのために同じIV値を選択するという高い確率があります。 したがって、可能にするカウンタブロック衝突、超能力または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.

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

McGrew & Viega              Standards Track                    [Page 10]

RFC 4543                GMAC in IPsec ESP and AH                May 2006

マグリューとViega規格がIPsecでRFC4543GMACを追跡する、[10ページ]ああ、超能力と2006年5月

   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ビットのSequence民数記を使用するときにはこの限界に達するのが不可能であることに注意してください。

   Note that, for each message, GMAC calls the block cipher only once.

GMACが一度だけ各メッセージに関してブロック暗号を呼ぶことに注意してください。

8.  Design Rationale

8. デザイン原理

   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-超能力と同様の[RFC4106]になるように設計されました。 私たちはその仕様から設計と実装経験を再使用します。 AES-GCM-超能力がそれらのサイズのすべてをサポートするので、私たちはすべての3つのAESの主要なサイズを入れます、そして、より大きい主要なサイズは高いより安全なオプションを将来のユーザに提供します。

9.  IANA Considerations

9. IANA問題

   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:

超能力におけるAES-GMACの使用において、以下の暗号化(1をタイプする)変換識別子を割り当ててあります:

      "21" for ENCR_NULL_AUTH_AES_GMAC

「ENCR_ヌル_AUTH_AES_GMACのための21インチ」

10.  Acknowledgements

10. 承認

   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.

ファビオMainoとデヴィッドBlackとの議論はこの仕様をかなり改良しました、そして、Tero Kivinenは役に立つコメントを私たちに提供しました。 スティーブ・ケントは超能力相互作用で指導を提供しました。 この仕事は密接にAES-GCM[RFC4309]に倣われます。(ラスHousleyのAES-CCMが変形した後にAES-GCMはそれ自体で密接にモデル化されます)。 さらに、GCM運転モードは元々、ダグ・ホワイティングとYoshi河野が参加したCWCモード[CWC]への改良として発想されました。 私たちはファビオ、デヴィッド、Tero、スティーブ、ラス、ダグ、およびYoshiに感謝します。

McGrew & Viega              Standards Track                    [Page 11]

RFC 4543                GMAC in IPsec ESP and AH                May 2006

マグリューとViega規格がIPsecでRFC4543GMACを追跡する、[11ページ]ああ、超能力と2006年5月

11.  References

11. 参照

11.1.  Normative References

11.1. 引用規格

   [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月。

   [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月。

11.2.  Informative References

11.2. 有益な参照

   [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月。

   [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] マグリュー、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]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 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.マグリュー、「セキュリティ有効搭載量(超能力)を要約するIPsecにおけるガロア/カウンタモード(GCM)の使用」、RFC4106、2005年6月。

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302, December
              2005.

[RFC4302] ケント、S.、「IP認証ヘッダー」、RFC4302、2005年12月。

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
              4303, December 2005.

[RFC4303]ケント、S.、「セキュリティ有効搭載量(超能力)を要約するIP」、RFC4303、2005年12月。

   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
              4306, December 2005.

[RFC4306] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、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がセキュリティ有効搭載量(超能力)を要約しているエー・イー・エス(AES)立方センチメートルモードを使用します」、RFC4309、2005年12月。

McGrew & Viega              Standards Track                    [Page 12]

RFC 4543                GMAC in IPsec ESP and AH                May 2006

マグリューとViega規格がIPsecでRFC4543GMACを追跡する、[12ページ]ああ、超能力と2006年5月

Authors' Addresses

作者のアドレス

   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

   John Viega
   McAfee, Inc.
   1145 Herndon Parkway, Suite 500
   Herndon, VA 20170

ハーンドンパークウェイ、ジョンViegaマカフィーInc.1145Suite500ハーンドン、ヴァージニア 20170

   EMail: viega@list.org

メール: viega@list.org

McGrew & Viega              Standards Track                    [Page 13]

RFC 4543                GMAC in IPsec ESP and AH                May 2006

マグリューとViega規格がIPsecでRFC4543GMACを追跡する、[13ページ]ああ、超能力と2006年5月

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

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

このドキュメントは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 provided by the IETF
   Administrative Support Activity (IASA).

RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

McGrew & Viega              Standards Track                    [Page 14]

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