RFC4309 日本語訳

Network Working Group                                         R. Housley
Request for Comments: 4309                                Vigil Security
Category: Standards Track                                  December 2005

Housleyがコメントのために要求するワーキンググループR.をネットワークでつないでください: 4309年の不寝番セキュリティカテゴリ: 標準化過程2005年12月

           Using Advanced Encryption Standard (AES) CCM Mode
            with IPsec Encapsulating Security Payload (ESP)

IPsecが、セキュリティが有効搭載量であるとカプセル化しているエー・イー・エス(AES)立方センチメートルモードを使用します。(超能力)

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 document describes the use of Advanced Encryption Standard (AES)
   in Counter with CBC-MAC (CCM) Mode, with an explicit initialization
   vector (IV), as an IPsec Encapsulating Security Payload (ESP)
   mechanism to provide confidentiality, data origin authentication, and
   connectionless integrity.

このドキュメントは、秘密性、データ発生源認証、およびコネクションレスな保全を提供するためにCBC-MAC(CCM)モード、明白な初期化ベクトル(IV)でCounterにおけるエー・イー・エス(AES)の使用をIPsec Encapsulating Security有効搭載量(超能力)メカニズムと説明します。

Table of Contents

目次

   1. Introduction ....................................................2
      1.1. Conventions Used in This Document ..........................2
   2. AES CCM Mode ....................................................2
   3. ESP Payload .....................................................4
      3.1. Initialization Vector (IV) .................................4
      3.2. Encrypted Payload ..........................................4
      3.3. Authentication Data ........................................5
   4. Nonce Format ....................................................5
   5. AAD Construction ................................................6
   6. Packet Expansion ................................................7
   7. IKE Conventions .................................................7
      7.1. Keying Material and Salt Values ............................7
      7.2. Phase 1 Identifier .........................................8
      7.3. Phase 2 Identifier .........................................8
      7.4. Key Length Attribute .......................................8
   8. Test Vectors ....................................................8
   9. Security Considerations .........................................8
   10. Design Rationale ...............................................9

1. 序論…2 1.1. このドキュメントで中古のコンベンション…2 2. AES立方センチメートルモード…2 3. 超能力有効搭載量…4 3.1. 初期設定ベクトル(IV)…4 3.2. 有効搭載量を暗号化します…4 3.3. 認証データ…5 4. 一回だけの形式…5 5. AAD工事…6 6. パケット拡張…7 7. IKEコンベンション…7 7.1. 材料と塩の値を合わせます…7 7.2. 1つの識別子の位相を合わせてください…8 7.3. 2識別子の位相を合わせてください…8 7.4. キー長属性…8 8. ベクトルをテストしてください…8 9. セキュリティ問題…8 10. 原理を設計してください…9

Housley                     Standards Track                     [Page 1]

RFC 4309           Using AEC CCM Mode with IPsec ESP       December 2005

超能力2005年12月にIPsecがあるAEC立方センチメートルモードを使用するHousley標準化過程[1ページ]RFC4309

   11. IANA Considerations ...........................................11
   12. Acknowledgements ..............................................11
   13. References ....................................................11
      13.1. Normative References .....................................11
      13.2. Informative References ...................................12

11. IANA問題…11 12. 承認…11 13. 参照…11 13.1. 標準の参照…11 13.2. 有益な参照…12

1.  Introduction

1. 序論

   The Advanced Encryption Standard (AES) [AES] is a block cipher, and
   it can be used in many different modes.  This document describes the
   use of AES in CCM (Counter with CBC-MAC) mode (AES CCM), with an
   explicit initialization vector (IV), as an IPsec Encapsulating
   Security Payload (ESP) [ESP] mechanism to provide confidentiality,
   data origin authentication, and connectionless integrity.

エー・イー・エス(AES)[AES]はブロック暗号です、そして、多くの異なったモードでそれは使用できます。 このドキュメントは、秘密性、データ発生源認証、およびコネクションレスな保全を提供するために明白な初期化ベクトル(IV)でCCM(CBC-MACに対抗する)モード(AES CCM)におけるAESの使用をIPsec Encapsulating Security有効搭載量(超能力)[超能力]メカニズムと説明します。

   This document does not provide an overview of IPsec.  However,
   information about how the various components of IPsec and the way in
   which they collectively provide security services is available in
   [ARCH] and [ROAD].

このドキュメントはIPsecの概要を提供しません。 しかしながら、IPsecの様々な部品とそれらがセキュリティー・サービスをまとめて提供する方法がどう利用可能なコネ[ARCH]と[ROAD]であるかの情報。

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

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[STDWORDS]で説明されるように本書では解釈されることであるべきですか?

2.  AES CCM Mode

2. AES立方センチメートルモード

   CCM is a generic authenticate-and-encrypt block cipher mode [CCM].
   In this specification, CCM is used with the AES [AES] block cipher.

CCMによるジェネリックがブロック暗号モード[CCM]を認証して、暗号化するということです。 この仕様では、CCMはAES[AES]ブロック暗号と共に使用されます。

   AES CCM has two parameters:

AES CCMには、2つのパラメタがあります:

      M  M indicates the size of the integrity check value (ICV).  CCM
         defines values of 4, 6, 8, 10, 12, 14, and 16 octets; However,
         to maintain alignment and provide adequate security, only the
         values that are a multiple of four and are at least eight are
         permitted.  Implementations MUST support M values of 8 octets
         and 16 octets, and implementations MAY support an M value of 12
         octets.

M Mは保全チェック価値(ICV)のサイズを示します。 CCMは4、6、8、10、12、14の値、および16の八重奏を定義します。 しかしながら、8は、整列を維持して、十分な安全性、4の倍数である唯一の値を提供して、少なくとも提供するようになるように受入れられます。 実装は、Mが8つの八重奏と16の八重奏の値であるとサポートしなければなりません、そして、実装は12の八重奏のM値をサポートするかもしれません。

      L  L indicates the size of the length field in octets.  CCM
         defines values of L between 2 octets and 8 octets.  This
         specification only supports L = 4.  Implementations MUST
         support an L value of 4 octets, which accommodates a full
         Jumbogram [JUMBO]; however, the length includes all of the
         encrypted data, which also includes the ESP Padding, Pad
         Length, and Next Header fields.

L Lは八重奏における、長さの分野のサイズを示します。 CCMは2つの八重奏と8つの八重奏の間でLの値を定義します。 この仕様は、Lが=4であるとサポートするだけです。 実装は、Lが4つの八重奏の値であるとサポートしなければなりません。(それは、完全なJumbogram[JUMBO]を収容します)。 しかしながら、長さは暗号化されたデータのすべてを含んでいます。(また、データは超能力Padding、Pad Length、およびNext Header分野を含んでいます)。

Housley                     Standards Track                     [Page 2]

RFC 4309           Using AEC CCM Mode with IPsec ESP       December 2005

超能力2005年12月にIPsecがあるAEC立方センチメートルモードを使用するHousley標準化過程[2ページ]RFC4309

   There are four inputs to CCM originator processing:

CCM創始者処理への4つの入力があります:

      key
         A single key is used to calculate the ICV using CBC-MAC and to
         perform payload encryption using counter mode.  AES supports
         key sizes of 128 bits, 192 bits, and 256 bits.  The default key

主要なA単一のキーは、CBC-MACを使用することでICVについて計算して、カウンタモードを使用することでペイロード暗号化を実行するのに使用されます。 AESは128ビット、192ビット、および256ビットの主要なサイズをサポートします。 デフォルトキー

         size is 128 bits, and implementations MUST support this key
         size.  Implementations MAY also support key sizes of 192 bits
         and 256 bits.

サイズは128ビットです、そして、実装はこの主要なサイズをサポートしなければなりません。 また、実装は192ビットと256ビットの主要なサイズをサポートするかもしれません。

      nonce
         The size of the nonce depends on the value selected for the
         parameter L.  It is 15-L octets.  Implementations MUST support
         a nonce of 11 octets.  The construction of the nonce is
         described in Section 4.

一回だけのサイズはパラメタL.のために選択された値に依存します。一回だけ、Itは15-L八重奏です。 実装は11の八重奏の一回だけをサポートしなければなりません。 一回だけの工事はセクション4で説明されます。

      payload
         The payload of the ESP packet.  The payload MUST NOT be longer
         than 4,294,967,295 octets, which is the maximum size of a
         Jumbogram [JUMBO]; however, the ESP Padding, Pad Length, and
         Next Header fields are also part of the payload.

超能力パケットのペイロードのペイロード。 ペイロードは42億9496万7295の八重奏より長いはずがありません(Jumbogram[JUMBO]の最大サイズです)。 しかしながら、また、超能力Padding、Pad Length、およびNext Header分野はペイロードの一部です。

      AAD
         CCM provides data integrity and data origin authentication for
         some data outside the payload.  CCM does not allow additional
         authenticated data (AAD) to be longer than
         18,446,744,073,709,551,615 octets.  The ICV is computed from
         the ESP header, Payload, and ESP trailer fields, which is
         significantly smaller than the CCM-imposed limit.  The
         construction of the AAD described in Section 5.

AAD CCMはペイロードの外におけるいくつかのデータのための発生源認証をデータ保全とデータに提供します。 CCMは、追加認証されたデータ(AAD)が1844京6744兆737億955万1615の八重奏より長いのを許容しません。 ICVは超能力ヘッダー、有効搭載量、および超能力トレーラ分野から計算されます(CCMによって課された限界よりかなり小さいです)。 セクション5で説明されたAADの構造。

   AES CCM requires the encryptor to generate a unique per-packet value
   and to communicate this value to the decryptor.  This per-packet
   value is one of the component parts of the nonce, and it is referred
   to as the initialization vector (IV).  The same IV and key
   combination MUST NOT be used more than once.  The encryptor can
   generate the IV in any manner that ensures uniqueness.  Common
   approaches to IV generation include incrementing a counter for each
   packet and linear feedback shift registers (LFSRs).

AES CCMは、1パケットあたり1つのユニークな値を生成して、この値をdecryptorに伝えるために暗号化する人を必要とします。 この1パケットあたりの値は一回だけのコンポーネントの部品の1つです、そして、それは初期化ベクトル(IV)と呼ばれます。 一度より同じIVと主要な組み合わせを使用してはいけません。 暗号化する人はユニークさを確実にするどんな方法でもIVを生成することができます。 IV世代への一般的なアプローチは、各パケットと直線的なフィードバック・シフト・レジスタ(LFSRs)のためにカウンタを増加するのを含んでいます。

   AES CCM employs counter mode for encryption.  As with any stream
   cipher, reuse of the same IV value with the same key is catastrophic.
   An IV collision immediately leaks information about the plaintext in
   both packets.  For this reason, it is inappropriate to use this CCM
   with statically configured keys.  Extraordinary measures would be
   needed to prevent reuse of an IV value with the static key across

AES CCMは暗号化のためのカウンタモードを使います。 どんなストリーム暗号のようにも、同じキーによる同じIV価値の再利用は壊滅的です。 IV衝突はすぐに、両方のパケットで平文に関して情報を漏らします。 この理由で、静的に構成されたキーがあるこのCCMを使用するのは不適当です。 並はずれた測定が、静的なキーが直径であることのIV価値の再利用を防ぐのに必要でしょう。

Housley                     Standards Track                     [Page 3]

RFC 4309           Using AEC CCM Mode with IPsec ESP       December 2005

超能力2005年12月にIPsecがあるAEC立方センチメートルモードを使用するHousley標準化過程[3ページ]RFC4309

   power cycles.  To be safe, implementations MUST use fresh keys with
   AES CCM.  The Internet Key Exchange (IKE) [IKE] protocol or IKEv2
   [IKEv2] can be used to establish fresh keys.

パワーは循環します。 安全に、なるように、実装はAES CCMがある新鮮なキーを使用しなければなりません。 新鮮なキーを証明するのに、インターネット・キー・エクスチェンジ(IKE)[IKE]プロトコルかIKEv2[IKEv2]を使用できます。

3.  ESP Payload

3. 超能力有効搭載量

   The ESP payload is composed of the IV followed by the ciphertext.
   The payload field, as defined in [ESP], is structured as shown in
   Figure 1.

超能力ペイロードは暗号文があとに続いたIVで構成されます。 [超能力]で定義されるペイロード分野は図1に示されるように構造化されます。

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Initialization Vector                     |
      |                            (8 octets)                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                  Encrypted Payload (variable)                 ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                 Authentication Data (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 CCM

図1。 AES立方センチメートルで暗号化された超能力有効搭載量

3.1.  Initialization Vector (IV)

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

   The AES CCM IV field MUST be eight octets.  The IV MUST be chosen by
   the encryptor in a manner that ensures that the same IV value is used
   only once for a given key.  The encryptor can generate the IV in any
   manner that ensures uniqueness.  Common approaches to IV generation
   include incrementing a counter for each packet and linear feedback
   shift registers (LFSRs).

AES CCM IV分野は8つの八重奏であるに違いありません。 暗号化する人は同じIV値が与えられたキーに一度だけ使用されるのを確実にする方法でIVを選ばなければなりません。 暗号化する人はユニークさを確実にするどんな方法でもIVを生成することができます。 IV世代への一般的なアプローチは、各パケットと直線的なフィードバック・シフト・レジスタ(LFSRs)のためにカウンタを増加するのを含んでいます。

   Including the IV in each packet ensures that the decryptor can
   generate the key stream needed for decryption, even when some
   datagrams are lost or reordered.

各パケットにIVを含んでいるのは、decryptorが復号化に必要である主要なストリームを生成することができるのを確実にします、いくつかのデータグラムが失われているか、または再命令されると。

3.2.  Encrypted Payload

3.2. 暗号化された有効搭載量

    The encrypted payload contains the ciphertext.

暗号化されたペイロードは暗号文を含んでいます。

    AES CCM mode does not require plaintext padding.  However, ESP does
    require padding to 32-bit word-align the authentication data.  The
    Padding, Pad Length, and Next Header fields MUST be concatenated

AES CCMモードは平文詰め物を必要としません。 しかしながら、超能力は、32ビットにそっと歩くのを必要とします。認証データを単語で並べてください。 Padding、Pad Length、およびNext Header分野を連結しなければなりません。

Housley                     Standards Track                     [Page 4]

RFC 4309           Using AEC CCM Mode with IPsec ESP       December 2005

超能力2005年12月にIPsecがあるAEC立方センチメートルモードを使用するHousley標準化過程[4ページ]RFC4309

    with the plaintext before performing encryption, as described in
    [ESP].  When padding is required, it MUST be generated and checked
    in accordance with the conventions specified in [ESP].

[超能力]で説明されるように暗号化を実行する前の平文で。 詰め物が必要であるときに、[超能力]で指定されたコンベンションによると、それを生成されて、チェックしなければなりません。

3.3.  Authentication Data

3.3. 認証データ

   AES CCM provides an encrypted ICV.  The ICV provided by CCM is
   carried in the Authentication Data fields without further encryption.
   Implementations MUST support ICV sizes of 8 octets and 16 octets.
   Implementations MAY also support ICV 12 octets.

AES CCMは暗号化されたICVを提供します。 CCMによって提供されたICVはAuthentication Data分野でさらなる暗号化なしで運ばれます。 実装は8つの八重奏と16の八重奏のサイズをICVにサポートしなければなりません。 また、実装はICV12に八重奏をサポートするかもしれません。

4.  Nonce Format

4. 一回だけの形式

   Each packet conveys the IV that is necessary to construct the
   sequence of counter blocks used by counter mode to generate the key
   stream.  The AES counter block is 16 octets.  One octet is used for
   the CCM Flags, and 4 octets are used for the block counter, as
   specified by the CCM L parameter.  The remaining octets are the
   nonce.  These octets occupy the second through the twelfth octets in
   the counter block.  Figure 2 shows the format of the nonce.

各パケットは主要なストリームを生成するのにカウンタモードで使用されるカウンタブロックの系列を構成するのに必要なIVを運びます。 AESカウンタブロックは16の八重奏です。 1つの八重奏がCCM Flagsに使用されます、そして、4つの八重奏がブロックカウンタに使用されます、CCM Lパラメタによって指定されるように。 残っている八重奏は一回だけです。 これらの八重奏はカウンタブロックにおける12番目の八重奏で2番目を占領します。 図2は一回だけの書式を示しています。

       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 24 bits.  As the name implies, it contains
         an unpredictable value.  It MUST be assigned at the beginning
         of the security association.  The salt value need not be
         secret, but it MUST NOT be predictable prior to the beginning
         of the security association.

塩がさばく塩は24ビットです。 名前が含意するように、それは予測できない値を含んでいます。 セキュリティ協会の始めにそれを割り当てなければなりません。 塩の値は秘密である必要はありませんが、それはセキュリティ協会の始まりの前に予測できるはずがありません。

      Initialization Vector The IV field is 64 bits.  As described in
         Section 3.1, the IV MUST be chosen by the encryptor in a manner
         that ensures that the same IV value is used only once for a
         given key.

Vector IVがさばく初期設定は64ビットです。 セクションで説明されて、3.1、IVが選ばなければならないように、同じIV値が与えられたキーに一度だけ使用されるのを確実にする方法で暗号化する人によって選ばれてください。

Housley                     Standards Track                     [Page 5]

RFC 4309           Using AEC CCM Mode with IPsec ESP       December 2005

超能力2005年12月にIPsecがあるAEC立方センチメートルモードを使用するHousley標準化過程[5ページ]RFC4309

   This construction permits each packet to consist of up to:

この工事は以下のことのために成る各パケットの起きるのを許します。

         2^32 blocks  =  4,294,967,296 blocks
                      = 68,719,476,736 octets

42億9496万7296 2^32ブロック=ブロックが687億1947万6736の八重奏と等しいです。

   This construction provides more key stream for each packet than is
   needed to handle any IPv6 Jumbogram [JUMBO].

この工事は各パケットのためのどんなIPv6 Jumbogram[JUMBO]も扱うのが必要であるより主要なストリームを提供します。

5.  AAD Construction

5. AAD工事

   The data integrity and data origin authentication for the Security
   Parameters Index (SPI) and (Extended) Sequence Number fields is
   provided without encrypting them.  Two formats 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.

それらを暗号化しないで、Security Parameters Index(SPI)と(広げられる)の系列Number分野のためのデータ保全とデータ発生源認証を提供します。 2つの書式が定義されます: 32ビットの一連番号のためのものと64ビットの拡張配列番号のためのもの。 32ビットの一連番号がある書式は図3に示されます、そして、64ビットの拡張配列番号がある書式は図4に示されます。

   Sequence Numbers are conveyed canonical network byte order.  Extended
   Sequence Numbers are conveyed canonical network byte order, placing
   the high-order 32 bits first and the low-order 32 bits second.
   Canonical network byte order is fully described in RFC 791, Appendix
   B.

系列民数記は運ばれた正準なネットワークバイトオーダーです。 拡張Sequence民数記は2番目に、正準なネットワークバイトオーダー、最初に、高位を32ビット置いて、および下位の32ビット伝えられます。 Appendix B、正準なネットワークバイトオーダーはRFC791で完全に説明されます。

       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形式

Housley                     Standards Track                     [Page 6]

RFC 4309           Using AEC CCM Mode with IPsec ESP       December 2005

超能力2005年12月にIPsecがあるAEC立方センチメートルモードを使用するHousley標準化過程[6ページ]RFC4309

6.  Packet Expansion

6. パケット拡張

   The initialization vector (IV) and the integrity check value (ICV)
   are the only sources of packet expansion.  The IV always adds 8
   octets to the front of the payload.  The ICV is added at the end of
   the payload, and the CCM parameter M determines the size of the ICV.
   Implementations MUST support M values of 8 octets and 16 octets, and
   implementations MAY also support an M value of 12 octets.

初期化ベクトル(IV)と保全チェック価値(ICV)はパケット拡張の唯一の源です。 IVはいつもペイロードの前部に8つの八重奏を加えます。 ICVはペイロードの端で加えられます、そして、CCMパラメタMはICVのサイズを決定します。 実装は、Mが8つの八重奏と16の八重奏の値であるとサポートしなければなりません、そして、また、実装は12の八重奏のM値をサポートするかもしれません。

7.  IKE Conventions

7. IKEコンベンション

   This section describes the conventions used to generate keying
   material and salt values for use with AES CCM using the Internet Key
   Exchange (IKE) [IKE] protocol.  The identifiers and attributes needed
   to negotiate a security association that uses AES CCM are also
   defined.

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

7.1.  Keying Material and Salt Values

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

   As previously described, implementations MUST use fresh keys with AES
   CCM.  IKE can be used to establish fresh keys.  This section
   describes the conventions for obtaining the unpredictable salt value
   for use in the nonce from IKE.  Note that this convention provides a
   salt value that is secret as well as unpredictable.

以前に説明されるように、実装はAES CCMがある新鮮なキーを使用しなければなりません。 新鮮なキーを証明するのにIKEを使用できます。 このセクションは、IKEから予測できない塩の値を一回だけにおける使用に得るためにコンベンションについて説明します。 このコンベンションが秘密の、そして、予測できない塩の値を提供することに注意してください。

   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 KEYMAT MUST be three octets longer than is needed for the
   associated AES key.  The keying material is used as follows:

サイズ、KEYMAT MUSTでは、関連AESキーに必要とされるより長い3つの八重奏になってください。 合わせることの材料は以下の通り使用されます:

      AES CCM with a 128-bit key
         The KEYMAT requested for each AES CCM key is 19 octets.  The
         first 16 octets are the 128-bit AES key, and the remaining
         three octets are used as the salt value in the counter block.

KEYMATがそれぞれのAES CCMキーのために要求した128ビットのキーがあるAES CCMは19の八重奏です。 最初の16の八重奏が128ビットのAESキーです、そして、残っている3つの八重奏が塩の値としてカウンタブロックで使用されます。

      AES CCM with a 192-bit key
         The KEYMAT requested for each AES CCM key is 27 octets.  The
         first 24 octets are the 192-bit AES key, and the remaining
         three octets are used as the salt value in the counter block.

KEYMATがそれぞれのAES CCMキーのために要求した192ビットのキーがあるAES CCMは27の八重奏です。 最初の24の八重奏が192ビットのAESキーです、そして、残っている3つの八重奏が塩の値としてカウンタブロックで使用されます。

      AES CCM with a 256-bit key
         The KEYMAT requested for each AES CCM key is 35 octets.  The
         first 32 octets are the 256-bit AES key, and the remaining
         three octets are used as the salt value in the counter block.

KEYMATがそれぞれのAES CCMキーのために要求した256ビットのキーがあるAES CCMは35の八重奏です。 最初の32の八重奏が256ビットのAESキーです、そして、残っている3つの八重奏が塩の値としてカウンタブロックで使用されます。

Housley                     Standards Track                     [Page 7]

RFC 4309           Using AEC CCM Mode with IPsec ESP       December 2005

超能力2005年12月にIPsecがあるAEC立方センチメートルモードを使用するHousley標準化過程[7ページ]RFC4309

7.2.  Phase 1 Identifier

7.2. フェーズ1識別子

   This document does not specify the conventions for using AES CCM for
   IKE Phase 1 negotiations.  For AES CCM to be used in this manner, a
   separate specification is needed, and an Encryption Algorithm
   Identifier needs to be assigned.

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

7.3.  Phase 2 Identifier

7.3. フェーズ2識別子

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

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

      14 for AES CCM with an 8-octet ICV;
      15 for AES CCM with a 12-octet ICV; and
      16 for AES CCM with a 16-octet ICV.

14 8八重奏のICVがあるAES立方センチメートルのために。 15 12八重奏のICVがあるAES立方センチメートルのために。 そして、16八重奏のICVがあるAES立方センチメートルのための16。

7.4.  Key Length Attribute

7.4. キー長属性

   Because the AES supports three key lengths, the Key Length attribute
   MUST be specified in the IKE Phase 2 exchange [DOI].  The Key Length
   attribute MUST have a value of 128, 192, or 256.

AESが3つのキー長をサポートするので、IKE Phase2交換[DOI]でKey Length属性を指定しなければなりません。 Key Length属性に、128、192、または256の値がなければなりません。

8.  Test Vectors

8. テストベクトル

   Section 8 of [CCM] provides test vectors that will assist
   implementers with AES CCM mode.

[CCM]のセクション8はimplementersを補助するテストベクトルにAES CCMモードを提供します。

9.  Security Considerations

9. セキュリティ問題

   AES CCM employs counter (CTR) mode for confidentiality.  If a counter
   value is ever used for more that one packet with the same key, then
   the same key stream will be used to encrypt both packets, and the
   confidentiality guarantees are voided.

AES CCMは秘密性にカウンタ(CTR)モードを使います。 対価が今までに以上に使用されると、同じ主要で、次に、同じ主要なストリームがあるその1つのパケットが両方のパケットを暗号化するのに使用されるでしょう、そして、秘密性保証は欠如します。

   What happens if the encryptor XORs the same key stream with two
   different packet plaintexts?  Suppose two packets are defined by two
   plaintext byte sequences P1, P2, P3 and Q1, Q2, Q3, then both are
   encrypted with key stream K1, K2, K3.  The two corresponding
   ciphertexts are:

同じくらいが合わせる暗号化する人XORsが2つの異なったパケット平文であふれるなら、何が起こりますか? 2つのパケットが2平文のバイト列のP1、P2、P3、およびQ1によって定義されて、次に、Q2(Q3)が主要なストリームK1、ケーツー(K3)と共にともに暗号化されると仮定してください。 2つの対応する暗号文は以下の通りです。

      (P1 XOR K1), (P2 XOR K2), (P3 XOR K3)

(P1 XOR K1)、(P2 XORケーツー)(P3 XOR K3)

      (Q1 XOR K1), (Q2 XOR K2), (Q3 XOR K3)

(Q1 XOR K1)、(Q2 XORケーツー)(Q3 XOR K3)

   If both of these two ciphertext streams are exposed to an attacker,
   then a catastrophic failure of confidentiality results, because:

これらの2つの暗号文ストリームの両方が攻撃者に暴露されるなら秘密性の突発故障が結果として生じる、:

Housley                     Standards Track                     [Page 8]

RFC 4309           Using AEC CCM Mode with IPsec ESP       December 2005

超能力2005年12月にIPsecがあるAEC立方センチメートルモードを使用するHousley標準化過程[8ページ]RFC4309

      (P1 XOR K1) XOR (Q1 XOR K1) = P1 XOR Q1
      (P2 XOR K2) XOR (Q2 XOR K2) = P2 XOR Q2
      (P3 XOR K3) XOR (Q3 XOR K3) = P3 XOR Q3

P2 XOR Q2(P3 XOR K3)P1 XOR Q1(P2 XORケーツー)(P1 XOR K1)XOR(Q1 XOR K1)=XOR(Q2 XORケーツー)=XOR(Q3 XOR K3)はP3 XOR Q3と等しいです。

   Once the attacker obtains the two plaintexts XORed together, it is
   relatively straightforward to separate them.  Thus, using any stream
   cipher, including AES CTR, to encrypt two plaintexts under the same
   key stream leaks the plaintext.

一緒にXORed、攻撃者がいったん2つの平文を得ると、それらを切り離すのは比較的簡単です。 したがって、同じ主要なストリームの下で2つの平文を暗号化するのにAES CTRを含むどんなストリーム暗号も使用すると、平文は漏らされます。

   Therefore, AES CCM should not be used with statically configured
   keys.  Extraordinary measures would be needed to prevent the reuse of
   a counter block value with the static key across power cycles.  To be
   safe, implementations MUST use fresh keys with AES CCM.  The IKE
   [IKE] protocol can be used to establish fresh keys.

したがって、静的に構成されたキーと共にAES CCMを使用するべきではありません。 並はずれた測定が、パワーサイクルの向こう側に静的なキーによるカウンタブロック価値の再利用を防ぐのに必要でしょう。 安全に、なるように、実装はAES CCMがある新鮮なキーを使用しなければなりません。 新鮮なキーを証明するのにIKE[IKE]プロトコルを使用できます。

   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

IKEが2つの同輩実体の間の新鮮なキーを証明するのに使用されるとき、別々のキーは2回の交通の流れのために設立されます。 aであるなら、異なったメカニズムは新鮮なキーを証明するのに使用されて、1つはそれです。

   establishes only a single key to encrypt packets, then there is a
   high probability that the peers will select the same IV values for
   some packets.  Thus, to avoid counter block collisions, ESP
   implementations that permit use of the same key for encrypting and
   decrypting packets with the same peer MUST ensure that the two peers
   assign different salt values to the security association (SA).

パケットを暗号化するために単一のキーだけを設立して、次に、同輩がいくつかのパケットのために同じIV値を選択するという高い確率があります。 したがって、カウンタブロック衝突を避けるために、同じキーの同じ同輩と共にパケットを暗号化して、解読する使用を可能にする超能力実装は、2人の同輩がセキュリティ協会(SA)に異なった塩の値を配属するのを確実にしなければなりません。

   Regardless of the mode used, AES with a 128-bit key is vulnerable to
   the birthday attack after 2^64 blocks are encrypted with a single
   key.  Since ESP with Extended Sequence Numbers allows for up to 2^64
   packets in a single SA, there is real potential for more than 2^64
   blocks to be encrypted with one key.  Implementations SHOULD generate
   a fresh key before 2^64 blocks are encrypted with the same key, or
   implementations SHOULD make use of the longer AES key sizes.  Note
   that ESP with 32-bit Sequence Numbers will not exceed 2^64 blocks
   even if all of the packets are maximum-length Jumbograms.

使用されるモードにかかわらず、2^64ブロックが単一のキーで暗号化された後に128ビットのキーがあるAESは誕生日の攻撃に被害を受け易いです。 Extended Sequence民数記がある超能力が2^まで独身のSAの64のパケットを許容するので、2^64が妨げる以上が1個のキーで暗号化される本当の可能性があります。 2^64ブロックが同じキーで暗号化される前に実装SHOULDが新鮮なキーを生成するか、または実装SHOULDは、より長いAES主要なサイズを利用します。 32ビットのSequence民数記がある超能力がパケットのすべてが最大の長さのJumbogramsであっても2^64ブロックを超えないことに注意してください。

10.  Design Rationale

10. デザイン原理

   In the development of this specification, the use of the ESP sequence
   number field instead of an explicit IV field was considered.  This
   section documents the rationale for the selection of an explicit IV.
   This selection is not a cryptographic security issue, as either
   approach will prevent counter block collisions.

この仕様の開発では、明白なIV分野の代わりに超能力一連番号分野の使用は考えられました。 このセクションは明白なIVの選択のために原理を記録します。 アプローチがカウンタブロック衝突を防ぐので、この選択は暗号の安全保障問題ではありません。

   The use of the explicit IV does not dictate the manner that the
   encryptor uses to assign the per-packet value in the counter block.
   This is desirable for several reasons.

明白なIVの使用は暗号化する人がカウンタブロックで1パケットあたりの値を割り当てるのに使用する方法を決めません。 これはいくつかの理由で望ましいです。

Housley                     Standards Track                     [Page 9]

RFC 4309           Using AEC CCM Mode with IPsec ESP       December 2005

超能力2005年12月にIPsecがあるAEC立方センチメートルモードを使用するHousley標準化過程[9ページ]RFC4309

      1.  Only the encryptor can ensure that the value is not used for
      more than one packet, so there is no advantage to selecting a
      mechanism that allows the decryptor to determine whether counter
      block values collide.  Damage from the collision is done, whether
      the decryptor detects it or not.

1. 暗号化する人だけが、値が1つ以上のパケットに使用されないのを確実にすることができるので、decryptorがカウンタブロック値が衝突するかどうか決定できるメカニズムを選択する利点が全くありません。 decryptorがそれを検出するか否かに関係なく、衝突からの損害は与えられます。

      2.  The use of explicit IVs allows adders, LFSRs, and any other
      technique that meets the time budget of the encryptor, so long as
      the technique results in a unique value for each packet.  Adders
      are simple and straightforward to implement, but due to carries,
      they do not execute in constant time.  LFSRs offer an alternative
      that executes in constant time.

2. 明白なIVsの使用は毒蛇、LFSRs、および暗号化する人の時間予算に間に合ういかなる他のテクニックも許容します、テクニックが各パケットのためのユニークな値をもたらす限り。 毒蛇は、実装するために簡単であって、簡単ですが、桁上げのため、それらは中で一定の時間を実行しません。 LFSRsはそれが一定の時間で実行する代替手段を提供します。

      3.  Complexity is in control of the implementer.  Furthermore, the
      decision made by the implementer of the encryptor does not make
      the decryptor more (or less) complex.

3. 複雑さはimplementerのコントロール中です。 その上、暗号化する人のimplementerによってされた決定は、より多くの(それほど)複合体をdecryptorにしません。

      4.  The assignment of the per-packet counter block value needs to
      be inside the assurance boundary.  Some implementations assign the
      sequence number inside the assurance boundary, but others do not.
      A sequence number collision does not have the dire consequences,
      but, as described in Section 6, a collision in counter block
      values has disastrous consequences.

4. 1パケットあたりのカウンタブロック価値の課題は、保証境界の中にある必要があります。 いくつかの実装が保証境界の中で一連番号を割り当てますが、他のものは割り当てるというわけではありません。 一連番号衝突には、恐ろしい結果がありませんが、セクション6で説明されるように、カウンタブロック値における衝突に惨憺たる結果があります。

      5.  Using the sequence number as the IV is possible in those
      architectures where the sequence number assignment is performed
      within the assurance boundary.  In this situation, the sequence
      number and the IV field will contain the same value.

5. IVとして一連番号を使用するのは一連番号課題が保証境界の中で実行されるそれらのアーキテクチャで可能です。 この状況で、一連番号とIV分野は同じ値を含むでしょう。

      6.  By decoupling the IV and the sequence number, architectures
      where the sequence number assignment is performed outside the
      assurance boundary are accommodated.

6. IVと一連番号の衝撃を吸収することによって、一連番号課題が保証境界の外で実行されるアーキテクチャは対応されます。

   The use of an explicit IV field directly follows from the decoupling
   of the sequence number and the per-packet counter block value.  The
   additional overhead (64 bits for the IV field) is acceptable.  This
   overhead is significantly less overhead associated with Cipher Block
   Chaining (CBC) mode.  As normally employed, CBC requires a full block
   for the IV and, on average, half of a block for padding.  AES CCM
   confidentiality processing with an explicit IV has about one-third of
   the overhead as AES CBC, and the overhead is constant for each
   packet.

明白なIV分野の使用は一連番号のデカップリングと1パケットあたりのカウンタブロック価値から直接続きます。 追加オーバーヘッド(IV分野への64ビット)は許容できます。 このオーバーヘッドはCipher Block Chaining(CBC)モードに関連しているかなり少ないオーバーヘッドです。 通常、使われるように、CBCはIVのための1つのまるブロックと詰め物のための半分の平均的にブロックを必要とします。 明白なIVとのAES CCM秘密性処理には、AES CBCとしてオーバーヘッドのおよそ1/3があります、そして、各パケットに、オーバーヘッドは一定です。

Housley                     Standards Track                    [Page 10]

RFC 4309           Using AEC CCM Mode with IPsec ESP       December 2005

超能力2005年12月にIPsecがあるAEC立方センチメートルモードを使用するHousley標準化過程[10ページ]RFC4309

11.  IANA Considerations

11. IANA問題

   IANA has assigned three ESP transform numbers for use with AES CCM
   with an explicit IV:

IANAは明白なIVと共にAES CCMとの使用の3つの超能力変換番号を割り当てました:

      14 for AES CCM with an 8-octet ICV;
      15 for AES CCM with a 12-octet ICV; and
      16 for AES CCM with a 16-octet ICV.

14 8八重奏のICVがあるAES立方センチメートルのために。 15 12八重奏のICVがあるAES立方センチメートルのために。 そして、16八重奏のICVがあるAES立方センチメートルのための16。

12.  Acknowledgements

12. 承認

   Doug Whiting and Niels Ferguson worked with me to develop CCM mode.
   We developed CCM mode as part of the IEEE 802.11i security effort.
   One of the most attractive aspects of CCM mode is that it is
   unencumbered by patents.  I acknowledge the companies that supported
   the development of an unencumbered authenticated encryption mode (in
   alphabetical order):

ダグ・ホワイティングとニールズファーガソンは、CCMモードを開発するために私と共に働いていました。 私たちはIEEE 802.11iセキュリティ取り組みの一部としてCCMモードを開発しました。 CCMモードの最も魅力的な局面の1つはそれが特許で邪魔されないということです。 私は邪魔されない認証された暗号化モード(アルファベット順に)の開発をサポートした会社を承認します:

      Hifn
      Intersil
      MacFergus
      RSA Security

Hifn Intersil MacFergus RSAセキュリティ

   Also, I thank Tero Kivinen for his comprehensive review of this
   document.

また、私は彼のこのドキュメントの包括的なレビューについてTero Kivinenに感謝します。

13.  References

13. 参照

   This section provides normative and informative references.

このセクションは規範的で有益な参照を提供します。

13.1.  Normative References

13.1. 引用規格

   [AES]       NIST, FIPS PUB 197, "Advanced Encryption Standard (AES),"
               November 2001.

FIPSパブ197、「エー・イー・エス(AES)」2001年11月の[AES]NIST。

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

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

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

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

   [CCM]       Whiting, D., Housley, R., and N. Ferguson, "Counter with
               CBC-MAC (CCM)", RFC 3610, September 2003.

[立方センチメートル] 2003年9月のホワイティングとD.とHousley、R.とN.ファーガソン、「CBC-MAC(立方センチメートル)があるカウンタ」RFC3610。

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

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

Housley                     Standards Track                    [Page 11]

RFC 4309           Using AEC CCM Mode with IPsec ESP       December 2005

超能力2005年12月にIPsecがあるAEC立方センチメートルモードを使用するHousley標準化過程[11ページ]RFC4309

13.2.  Informative References

13.2. 有益な参照

   [ARCH]      Kent, S. and K. Seo, "Security Architecture for the
               Internet Protocol", RFC 4301, December 2005.

[アーチ]ケント、S.、およびK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。

   [IKE]       Harkins, D. and D. Carrel, "The Internet Key Exchange
               (IKE)", RFC 2409, November 1998.

[IKE]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。

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

[IKEv2] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、2005年12月。

   [ROAD]      Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
               Document Roadmap", RFC 2411, November 1998.

[道路] セイヤーとR.とDoraswamy、N.とR.グレン、「IPセキュリティドキュメント道路地図」、RFC2411、1998年11月。

   [JUMBO]     Borman, D., Deering, S., and R. Hinden, "IPv6
               Jumbograms", RFC 2675, August 1999.

1999年8月の[ジャンボ]のボーマンとD.とデアリング、S.とR.Hinden、「IPv6 Jumbograms」RFC2675。

Author's Address

作者のアドレス

   Russell Housley
   Vigil Security, LLC
   918 Spring Knoll Drive
   Herndon, VA 20170
   USA

ラッセルHousley不寝番セキュリティ、スプリング小山Driveハーンドン、LLC918ヴァージニア20170米国

   EMail: housley@vigilsec.com

メール: housley@vigilsec.com

Housley                     Standards Track                    [Page 12]

RFC 4309           Using AEC CCM Mode with IPsec ESP       December 2005

超能力2005年12月にIPsecがあるAEC立方センチメートルモードを使用するHousley標準化過程[12ページ]RFC4309

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機能のための基金は現在、インターネット協会によって提供されます。

Housley                     Standards Track                    [Page 13]

Housley標準化過程[13ページ]