Network Working Group R. Housley
Request for Comments: 3686 Vigil Security
Category: Standards Track January 2004
Using Advanced Encryption Standard (AES) Counter Mode
With IPsec Encapsulating Security Payload (ESP)
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（C）インターネット協会（2004）。全著作権所有。
Abstract
抽象
This document describes the use of Advanced Encryption Standard (AES) Counter Mode, with an explicit initialization vector, as an IPsec Encapsulating Security Payload (ESP) confidentiality mechanism.
この文書では、IPsecカプセル化セキュリティペイロード（ESP）機密性の仕組みとして、明示的な初期化ベクトルとのAdvanced Encryption Standard（AES）カウンタモードの使用を記載しています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used In This Document. . . . . . . . . . . . 2
2. AES Block Cipher . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Counter Mode . . . . . . . . . . . . . . . . . . . . . . 2
2.2. Key Size and Rounds. . . . . . . . . . . . . . . . . . . 5
2.3. Block Size . . . . . . . . . . . . . . . . . . . . . . . 5
3. ESP Payload. . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Initialization Vector. . . . . . . . . . . . . . . . . . 6
3.2. Encrypted Payload. . . . . . . . . . . . . . . . . . . . 6
3.3. Authentication Data. . . . . . . . . . . . . . . . . . . 6
4. Counter Block Format . . . . . . . . . . . . . . . . . . . . . 7
5. IKE Conventions. . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Keying Material and Nonces . . . . . . . . . . . . . . . 8
5.2. Phase 1 Identifier . . . . . . . . . . . . . . . . . . . 9
5.3. Phase 2 Identifier . . . . . . . . . . . . . . . . . . . 9
5.4. Key Length Attribute . . . . . . . . . . . . . . . . . . 9
6. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
8. Design Rationale . . . . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 16
10. Intellectual Property Statement. . . . . . . . . . . . . . . . 16
11. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 17
13. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 19
The National Institute of Standards and Technology (NIST) recently selected the Advanced Encryption Standard (AES) [AES], also known as Rijndael. The AES is a block cipher, and it can be used in many different modes. This document describes the use of AES Counter Mode (AES-CTR), with an explicit initialization vector (IV), as an IPsec Encapsulating Security Payload (ESP) [ESP] confidentiality mechanism.
アメリカ国立標準技術研究所（NIST）は最近も、ラインダールとして知られているのAdvanced Encryption Standard（AES）[AES]を選択しました。 AESは、ブロック暗号であり、それは多くの異なるモードで使用することができます。この文書は、IPsecカプセル化セキュリティペイロード（ESP）[ESP]機密性機構として、明示的な初期化ベクトル（IV）を用いて、AESカウンタモード（AES-CTR）の使用を記載しています。
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 [ROADMAP].
この文書では、IPsecの概要を提供していません。しかし、IPsecと彼らは総称してセキュリティサービスを提供する方法の方法を様々なコンポーネントに関する情報は、[ARCH]と[ロードマップ]で利用可能です。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります【STDWORDS]に記載されているように解釈されます。
This section contains a brief description of the relevant characteristics of the AES block cipher. Implementation requirements are also discussed.
このセクションでは、AESブロック暗号の関連する特性の簡単な説明が含まれています。実装要件についても説明します。
NIST has defined five modes of operation for AES and other FIPS-approved block ciphers [MODES]. Each of these modes has different characteristics. The five modes are: ECB (Electronic Code Book), CBC (Cipher Block Chaining), CFB (Cipher FeedBack), OFB (Output FeedBack), and CTR (Counter).
NISTは、AES及び他のFIPS承認のブロック暗号のための動作の5つのモード[MODES]を定義しています。これらの各モードは、異なる特性を持っています。 5つのモードがあります：ECB（電子コードブック）、CBC（暗号ブロック連鎖）、CFB（暗号フィードバック）、OFB（出力フィードバック）、およびCTR（カウンター）。
Only AES Counter mode (AES-CTR) is discussed in this specification. AES-CTR requires the encryptor to generate a unique per-packet value, and communicate this value to the decryptor. This specification calls this per-packet value an 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カウンタモード（AES-CTR）は、本明細書に記載されています。 AES-CTRは、ユニークなパケットごとの値を生成し、暗号解読にこの値を通信するために暗号化が必要です。この仕様は、初期化ベクトル（IV）は、このパケットごとの値を呼び出します。同じIVとキーの組み合わせを複数回使用してはいけません。暗号化には、一意性を保証し、いかなる方法でIVを生成することができます。 IV世代の一般的なアプローチは、各パケットのためのカウンタをインクリメントし、線形フィードバックシフトレジスタ（LFSR）を含みます。
This specification calls for the use of a nonce for additional protection against precomputation attacks. The nonce value need not be secret. However, the nonce MUST be unpredictable prior to the establishment of the IPsec security association that is making use of AES-CTR.
この仕様は、事前計算攻撃に対する追加の保護のためのnonceの使用を呼び出します。ナンス値は秘密である必要はありません。しかし、ノンスは、AES-CTRを利用しているIPsecセキュリティアソシエーションの確立に先立って予測不可能でなければなりません。
AES-CTR has many properties that make it an attractive encryption algorithm for in high-speed networking. AES-CTR uses the AES block cipher to create a stream cipher. Data is encrypted and decrypted by XORing with the key stream produced by AES encrypting sequential counter block values. AES-CTR is easy to implement, and AES-CTR can be pipelined and parallelized. AES-CTR also supports key stream precomputation.
AES-CTRは、高速ネットワーキングにおけるにとって魅力的な暗号化アルゴリズムにする多くの特性を有しています。 AES-CTRは、ストリーム暗号を作成するために、AESブロック暗号を使用しています。データはシーケンシャルカウンタブロック値を暗号化AESによって生成鍵ストリームとの排他的論理和演算することによって暗号化および復号化されます。 AES-CTRは実装が容易で、AES-CTRは、パイプライン化と並列化することができます。 AES-CTRはまた、キーストリームの事前計算をサポートしています。
Pipelining is possible because AES has multiple rounds (see section 2.2). A hardware implementation (and some software implementations) can create a pipeline by unwinding the loop implied by this round structure. For example, after a 16-octet block has been input, one round later another 16-octet block can be input, and so on. In AES-CTR, these inputs are the sequential counter block values used to generate the key stream.
AESは、複数回（セクション2.2を参照）を有しているため、パイプライン処理が可能です。ハードウェア実装（およびいくつかのソフトウェア実装）このラウンド構造によって暗示ループを巻き戻すことにより、パイプラインを作成することができます。 16オクテットのブロックが入力された後、例えば、1ラウンド後、別の16オクテットのブロックは、ように入力すること、およびできます。 AES-CTRでは、これらの入力は、キーストリームを生成するために使用されるシーケンシャルカウンタブロック値です。
Multiple independent AES encrypt implementations can also be used to improve performance. For example, one could use two AES encrypt implementations in parallel, to process a sequence of counter block values, doubling the effective throughput.
複数の独立したAESの暗号化の実装は、パフォーマンスを向上させるために使用することができます。例えば、一つは実効スループットを倍増し、カウンタブロック値のシーケンスを処理するために、並列に2つのAESの暗号化の実装を使用することができます。
The sender can precompute the key stream. Since the key stream does not depend on any data in the packet, the key stream can be precomputed once the nonce and IV are assigned. This precomputation can reduce packet latency. The receiver cannot perform similar precomputation because the IV will not be known before the packet arrives.
送信者は、キーストリームを事前に計算することができます。キーストリームは、パケット内の任意のデータに依存しないので、ナンスとIVが割り当てられたら、キーストリームが事前に計算することができます。この事前計算は、パケットの待ち時間を短縮することができます。パケットが到着する前にIVが知られることはありませんので、受信機は、同様の事前計算を実行することはできません。
AES-CTR uses the only AES encrypt operation (for both encryption and decryption), making AES-CTR implementations smaller than implementations of many other AES modes.
AES-CTRは、他の多くのAESモードの実装よりも小さいAES-CTRの実装を行う、（暗号化および復号化の両方のために）のみAESの暗号化処理を使用します。
When used correctly, AES-CTR provides a high level of confidentiality. Unfortunately, AES-CTR is easy to use incorrectly. Being a stream cipher, any reuse of the per-packet value, called the IV, with the same nonce and key is catastrophic. An IV collision immediately leaks information about the plaintext in both packets. For this reason, it is inappropriate to use this mode of operation with static keys. Extraordinary measures would be needed to prevent reuse of an IV value with the static key across power cycles. To be safe, implementations MUST use fresh keys with AES-CTR. The Internet Key Exchange (IKE) [IKE] protocol can be used to establish fresh keys. IKE can also provide the nonce value.
正しく使用すると、AES-CTRは、機密性の高いレベルを提供します。残念ながら、AES-CTRは間違って使いやすいです。ストリーム暗号なので、同じナンスとキーとIVと呼ばれるパケット単位の値のいずれかの再利用は、壊滅的です。 IVの衝突がすぐに両方のパケットで平文に関する情報をリークします。このため、静的なキーでこの動作モードを使用することは不適切です。臨時措置はパワーサイクル全体で静的キーとIV値の再使用を防止するために必要とされるであろう。安全のために、実装は、AES-CTR新鮮なキーを使用する必要があります。インターネット鍵交換（IKE）[IKE]プロトコルは、新鮮な鍵を確立するために使用することができます。 IKEはまた、一回だけの価値を提供することができます。
With AES-CTR, it is trivial to use a valid ciphertext to forge other (valid to the decryptor) ciphertexts. Thus, it is equally catastrophic to use AES-CTR without a companion authentication function. Implementations MUST use AES-CTR in conjunction with an authentication function, such as HMAC-SHA-1-96 [HMAC-SHA].
AES-CTRで、他の（復号化に有効な）暗号文を偽造するために有効な暗号文を使用するのは簡単です。したがって、コンパニオン認証機能なしAES-CTRを使用することも同様に壊滅的です。実装は、HMAC-SHA-1-96 [HMAC-SHA]のように、認証機能と連携してAES-CTRを使用しなければなりません。
To encrypt a payload with AES-CTR, the encryptor partitions the plaintext, PT, into 128-bit blocks. The final block need not be 128 bits; it can be less.
AES-CTRとペイロードを暗号化するために、暗号化は、128ビットのブロックに、平文、PTを仕切ります。最後のブロックは、128ビットである必要はありません。それは以下とすることができます。
PT = PT[1] PT[2] ... PT[n]
PT = PT [1] PT [2] PT [N]
Each PT block is XORed with a block of the key stream to generate the ciphertext, CT. The AES encryption of each counter block results in 128 bits of key stream. The most significant 96 bits of the counter block are set to the nonce value, which is 32 bits, followed by the per-packet IV value, which is 64 bits. The least significant 32 bits of the counter block are initially set to one. This counter value is incremented by one to generate subsequent counter blocks, each resulting in another 128 bits of key stream. The encryption of n plaintext blocks can be summarized as:
各PTブロックは、CTを暗号文を生成するキーストリームのブロックとXORされます。キーストリームの128ビットの各カウンタブロック結果のAES暗号化。カウンタブロックの最上位96ビットは64ビットであり、パケット単位のIV値を、続く32ビットであるノンス値、に設定されます。カウンタブロックの最下位32ビットが最初にいずれかに設定されています。このカウンタ値は、各キーストリームの別の128ビットで、その結果、後続カウンタブロックを生成するために、1だけインクリメントされます。 n個の平文ブロックの暗号化は、次のように要約することができます。
CTRBLK := NONCE || IV || ONE FOR i := 1 to n-1 DO CT[i] := PT[i] XOR AES(CTRBLK) CTRBLK := CTRBLK + 1 END CT[n] := PT[n] XOR TRUNC(AES(CTRBLK))
CTRBLK：= NONCE || IV ||私の一つ：= 1からn-1までDO CT [I]：= PT [I] XOR AES（CTRBLK）CTRBLK：= CTRBLK + 1つのEND CT [N]：= PT [N] XOR TRUNC（AES（CTRBLK） ）
The AES() function performs AES encryption with the fresh key.
AES（）関数は、新鮮なキーでAES暗号化を実行します。
The TRUNC() function truncates the output of the AES encrypt operation to the same length as the final plaintext block, returning the most significant bits.
TRUNC（）関数は、最上位ビットを返し、最終的な平文ブロックと同じ長さにAESの暗号化操作の出力を切り捨て。
Decryption is similar. The decryption of n ciphertext blocks can be summarized as:
復号化は似ています。 n個の暗号文ブロックの復号化は、次のように要約することができます。
CTRBLK := NONCE || IV || ONE FOR i := 1 to n-1 DO PT[i] := CT[i] XOR AES(CTRBLK) CTRBLK := CTRBLK + 1 END PT[n] := CT[n] XOR TRUNC(AES(CTRBLK))
CTRBLK：= NONCE || IV ||私の一つ：= 1からn-1までDO PT [I]：= CT [i]のXOR AES（CTRBLK）CTRBLK：= CTRBLK + 1つのEND PT [N]：= CT [N] XOR TRUNC（AES（CTRBLK） ）
AES supports three key sizes: 128 bits, 192 bits, and 256 bits. The default key size is 128 bits, and all implementations MUST support this key size. Implementations MAY also support key sizes of 192 bits and 256 bits.
128ビット、192ビット、256ビット：AESは、3つの主要なサイズをサポートしています。デフォルトのキーサイズは128ビットであり、すべての実装がこのキーサイズをサポートしなければなりません。また、実装は192ビット、256ビットのキーサイズをサポートするかもしれません。
AES uses a different number of rounds for each of the defined key sizes. When a 128-bit key is used, implementations MUST use 10 rounds. When a 192-bit key is used, implementations MUST use 12 rounds. When a 256-bit key is used, implementations MUST use 14 rounds.
AESは、定義された鍵サイズのそれぞれについてラウンドの異なる番号を使用します。 128ビットのキーを使用した場合、実装は10ラウンドを使用しなければなりません。 192ビットの鍵を使用した場合、実装は12ラウンドを使用しなければなりません。 256ビットの鍵を使用した場合、実装は14ラウンドを使用しなければなりません。
The AES has a block size of 128 bits (16 octets). As such, when using AES-CTR, each AES encrypt operation generates 128 bits of key stream. AES-CTR encryption is the XOR of the key stream with the plaintext. AES-CTR decryption is the XOR of the key stream with the ciphertext. If the generated key stream is longer than the plaintext or ciphertext, the extra key stream bits are simply discarded. For this reason, AES-CTR does not require the plaintext to be padded to a multiple of the block size. However, to provide limited traffic flow confidentiality, padding MAY be included, as specified in [ESP].
AESは、128ビット（16オクテット）のブロックサイズを有します。 AES-CTRを使用する場合のような、各AES暗号化操作は、キーストリームの128ビットを生成します。 AES-CTR暗号化は平文と鍵ストリームのXORです。 AES-CTRの解読は、暗号文と鍵ストリームのXORです。生成されたキーストリームが平文または暗号文よりも長い場合、余分なキーストリームビットは単に破棄されます。この理由のために、AES-CTRは、ブロックサイズの倍数にパディングされる平文を必要としません。 [ESP]に指定されているようしかし、限られたトラフィックフロー機密性を提供するために、パディングが、含まれるかもしれません。
The ESP payload is comprised of the IV followed by the ciphertext. The payload field, as defined in [ESP], is structured as shown in Figure 1.
ESPペイロードを暗号文に続くIVで構成されています。図1に示すように、ペイロードフィールドは、[ESP]で定義されるように、構成されています。
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) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. ESP Payload Encrypted with AES-CTR
AES-CTR図1. ESPペイロードの暗号化
The AES-CTR 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-CTRのIVフィールドは8つのオクテットでなければなりません。 IVは、同じIV値が指定されたキーの一度だけ使用されることを保証するように暗号化することによって選択されなければなりません。暗号化には、一意性を保証し、いかなる方法でIVを生成することができます。 IV世代の一般的なアプローチは、各パケットのためのカウンタをインクリメントし、線形フィードバックシフトレジスタ（LFSR）を含みます。
Including the IV in each packet ensures that the decryptor can generate the key stream needed for decryption, even when some packets are lost or reordered.
各パケットにおけるIV含めると、いくつかのパケットが失われたり、並べ替えた場合であっても、復号化は、復号に必要な鍵ストリームを生成することができることを保証します。
The encrypted payload contains the ciphertext.
暗号化されたペイロードは、暗号文が含まれています。
AES-CTR mode does not require plaintext padding. However, ESP does require padding to 32-bit word-align the authentication data. The padding, Pad Length, and the Next Header MUST be concatenated with the plaintext before performing encryption, as described in [ESP].
AES-CTRモードでは、平文のパディングを必要としません。ただし、ESPは、認証データをワード整列32ビットにパディングを必要とします。 [ESP]に記載されているようにパディング、パッド長、次ヘッダは、暗号化を行う前に、平文と連結されなければなりません。
Since it is trivial to construct a forgery AES-CTR ciphertext from a valid AES-CTR ciphertext, AES-CTR implementations MUST employ a non-NULL ESP authentication method. HMAC-SHA-1-96 [HMAC-SHA] is a likely choice.
それは有効なAES-CTR暗号文から偽造AES-CTR暗号文を構築することは簡単ですので、AES-CTRの実装は非NULL ESP認証方式を採用しなければなりません。 HMAC-SHA-1-96 [HMAC-SHA]可能性が高い選択肢です。
Each packet conveys the IV that is necessary to construct the sequence of counter blocks used to generate the key stream necessary to decrypt the payload. The AES counter block cipher block is 128 bits. Figure 2 shows the format of the counter block.
各パケットは、ペイロードを復号化するために必要な鍵ストリームを生成するために使用されるカウンタブロックのシーケンスを構築する必要があるIVを伝えます。 AESカウンタブロック暗号ブロックは128ビットです。図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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector (IV) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Counter Block Format
図2.カウンタブロックフォーマット
The components of the counter block are as follows:
次のようにカウンタブロックの成分です。
Nonce The Nonce field is 32 bits. As the name implies, the nonce is a single use value. That is, a fresh nonce value MUST be assigned for each security association. It MUST be assigned at the beginning of the security association. The nonce value need not be secret, but it MUST be unpredictable prior to the beginning of the security association.
ノンスザ・ナンス・フィールドは32ビットです。名前が示すように、ナンスは、単回使用の値です。それは新鮮なナンス値は、各セキュリティアソシエーションのために割り当てられなければならない、です。これは、セキュリティアソシエーションの先頭に割り当てなければなりません。ナンス値は秘密である必要はありませんが、それはセキュリティアソシエーションの開始前予測不可能でなければなりません。
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.
初期化ベクトルザ・IV・フィールドは64ビットです。セクション3.1で説明したように、IVは、同じIV値が指定されたキーの一度だけ使用されることを保証するように暗号化することによって選択されなければなりません。
Block Counter The block counter field is the least significant 32 bits of the counter block. The block counter begins with the value of one, and it is incremented to generate subsequent portions of the key stream. The block counter is a 32-bit big-endian integer value.
ブロックカウンタブロックカウンタフィールドは、カウンタブロックの最下位32ビットです。ブロックカウンタは、一つの値で始まり、キーストリームの後続の部分を生成するようにインクリメントされます。ブロックカウンタは、32ビットのビッグエンディアン整数値です。
Using the encryption process described in section 2.1, this construction permits each packet to consist of up to:
セクション2.1で説明した暗号化処理を使用して、この構成は、最大で構成する各パケットを許可します。
(2^32)-1 blocks = 4,294,967,295 blocks = 68,719,476,720 octets
（2 ^ 32）-1ブロック= 4,294,967,295ブロック= 68719476720個のオクテット
This construction can produce enough key stream for each packet sufficient to handle any IPv6 jumbogram [JUMBO].
この構造は、任意のIPv6のジャンボグラム[JUMBO]を処理するのに十分な各パケットのための十分なキーストリームを生成することができます。
This section describes the conventions used to generate keying material and nonces for use with AES-CTR using the Internet Key Exchange (IKE) [IKE] protocol. The identifiers and attributes needed to negotiate a security association which uses AES-CTR are also defined.
このセクションでは、インターネット鍵交換（IKE）[IKE]プロトコルを使用してAES-CTRで使用するためのキーイング材料及びノンスを生成するために使用される規則を記述する。 AES-CTRを使用してセキュリティアソシエーションをネゴシエートするために必要な識別子と属性も定義されています。
As described in section 2.1, implementations MUST use fresh keys with AES-CTR. IKE can be used to establish fresh keys. This section describes the conventions for obtaining the unpredictable nonce value from IKE. Note that this convention provides a nonce value that is secret as well as unpredictable.
セクション2.1で説明したように、実装は、AES-CTR新鮮なキーを使用しなければなりません。 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）を利用します。 PRFは、任意のサイズの鍵材料と呼ばれるKEYMATを導き出すために反復的に使用されています。鍵材料は、境界に関係なく、出力文字列から抽出されます。
The size of the requested KEYMAT MUST be four octets longer than is needed for the associated AES key. The keying material is used as follows:
要求されたKEYMATの大きさは、関連するAESキーのために必要とされるよりも4つのオクテット長くなければなりません。次のように鍵材料が使用されます。
AES-CTR with a 128 bit key The KEYMAT requested for each AES-CTR key is 20 octets. The first 16 octets are the 128-bit AES key, and the remaining four octets are used as the nonce value in the counter block.
AES-CTR 128ビットの鍵を用いて各AES-CTRキーを要求KEYMATは20オクテットです。第16オクテットは、128ビットのAES鍵であり、残りの4つのオクテットは、カウンタブロックにノンス値として使用されます。
AES-CTR with a 192 bit key The KEYMAT requested for each AES-CTR key is 28 octets. The first 24 octets are the 192-bit AES key, and the remaining four octets are used as the nonce value in the counter block.
AES-CTR 192ビットの鍵を用いて各AES-CTRキーを要求KEYMATは28オクテットです。第24オクテットは192ビットのAES鍵であり、残りの4つのオクテットは、カウンタブロックにノンス値として使用されます。
AES-CTR with a 256 bit key The KEYMAT requested for each AES-CTR key is 36 octets. The first 32 octets are the 256-bit AES key, and the remaining four octets are used as the nonce value in the counter block.
AES-CTR 256ビットの鍵を用いて各AES-CTRキーを要求KEYMATは36オクテットです。第32オクテットは、256ビットのAES鍵であり、残りの4つのオクテットは、カウンタブロックにノンス値として使用されます。
This document does not specify the conventions for using AES-CTR for IKE Phase 1 negotiations. For AES-CTR to be used in this manner, a separate specification is needed, and an Encryption Algorithm Identifier needs to be assigned.
この文書では、IKEフェーズ1ネゴシエーションのためのAES-CTRを使用するための規則を指定していません。このように使用されるAES-CTRのために、別々の仕様が必要、および暗号化アルゴリズム識別子が割り当てられる必要があります。
For IKE Phase 2 negotiations, IANA has assigned an ESP Transform Identifier of 13 for AES-CTR with an explicit IV.
IKEフェーズ2つのネゴシエーションのために、IANAは、ESP明示IVとAES-CTR 13の識別子を変換割り当てました。
Since 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フェーズ2交換の[DOI]で指定する必要があります。キーの長さ属性が128、192、または256の値を持つ必要があります。
This section contains nine test vectors, which can be used to confirm that an implementation has correctly implemented AES-CTR. The first three test vectors use AES with a 128 bit key; the next three test vectors use AES with a 192 bit key; and the last three test vectors use AES with a 256 bit key.
このセクションでは、実装が正しくAES-CTRを実施していることを確認するために使用することができます9つのテストベクタを、含まれています。最初の3つのテストベクトルは、128ビット鍵のAESを使用します。次の3つのテストベクトルは、192ビットキーのAESを使用します。そして、最後の3つのテストベクトルは256ビットキーのAESを使用します。
Test Vector #1: Encrypting 16 octets using AES-CTR with 128-bit key AES Key : AE 68 52 F8 12 10 67 CC 4B F7 A5 76 55 77 F3 9E AES-CTR IV : 00 00 00 00 00 00 00 00 Nonce : 00 00 00 30 Plaintext String : 'Single block msg' Plaintext : 53 69 6E 67 6C 65 20 62 6C 6F 63 6B 20 6D 73 67 Counter Block (1): 00 00 00 30 00 00 00 00 00 00 00 00 00 00 00 01 Key Stream (1): B7 60 33 28 DB C2 93 1B 41 0E 16 C8 06 7E 62 DF Ciphertext : E4 09 5D 4F B7 A7 B3 79 2D 61 75 A3 26 13 11 B8
テストベクトル＃1：キー128ビット鍵のAESとAES-CTRを使用して、16オクテットの暗号化：AE 68 52 F8 12 10 67 CC 4B F7 A5 76 55 77 F3 9E AES-CTR IV：00 00 00 00 00 00 00 00ノンス：00 00 00 30平文文字列： 'シングルブロックMSG' 平文：53 69 6E 67（c）65 20 62 6C 6F 63 6B 20 6D 73 67カウンタブロック（1）：00 00 00 30 00 00 00 00 00 00 00 00 00 00 00 01キーストリーム（1）：B7 60 33 28 DB C2 93 1B 41 0E 16 C8 06 7E 62 DF暗号文：E4 09 5D 4F B7 A7のB3 79 2D 61 75 A3 26 13 11 B8
Test Vector #2: Encrypting 32 octets using AES-CTR with 128-bit key AES Key : 7E 24 06 78 17 FA E0 D7 43 D6 CE 1F 32 53 91 63 AES-CTR IV : C0 54 3B 59 DA 48 D9 0B Nonce : 00 6C B6 DB Plaintext : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F : 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F Counter Block (1): 00 6C B6 DB C0 54 3B 59 DA 48 D9 0B 00 00 00 01 Key Stream (1): 51 05 A3 05 12 8F 74 DE 71 04 4B E5 82 D7 DD 87 Counter Block (2): 00 6C B6 DB C0 54 3B 59 DA 48 D9 0B 00 00 00 02 Key Stream (2): FB 3F 0C EF 52 CF 41 DF E4 FF 2A C4 8D 5C A0 37 Ciphertext : 51 04 A1 06 16 8A 72 D9 79 0D 41 EE 8E DA D3 88 : EB 2E 1E FC 46 DA 57 C8 FC E6 30 DF 91 41 BE 28
テストベクトル＃2：7E 24 06 78 17 FA E0 D7 43 D6 CE 1F 32 53 91 63 AES-CTR IV：C0 54（B）59 DA 48 D9 0BノンスAES-CTR 128ビット鍵のAES鍵とを使用して、32オクテットの暗号化：00 6C B6 DB平文：00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F：10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1Fカウンタブロック（1）：00 6C B6 DB C0 54（B）59 DA 48 D9 0B 00 00 00 01キーストリーム（1）：51 05 A3 05 12 8F 74 DE 71 04 4B E5 82 D7 DD 87カウンタブロック（2）：00 6C B6 DB C0 54（B）59 DA 48 D9 0B 00 00 00 02キーストリーム（2）：FB 3F 0C EF 52 CF 41 DF E4 FF 2A C4 8D 5C A0 37暗号文：51 04 A1 06 16（a）72 D9 79 0D 41 EE 8E DA D3 88：EB 2E 1E FC 46 DA 57 C8 FC E6 30 DF 91 41 28 BE
Test Vector #3: Encrypting 36 octets using AES-CTR with 128-bit key AES Key : 76 91 BE 03 5E 50 20 A8 AC 6E 61 85 29 F9 A0 DC AES-CTR IV : 27 77 7F 3F 4A 17 86 F0 Nonce : 00 E0 01 7B Plaintext : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F : 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F : 20 21 22 23 Counter Block (1): 00 E0 01 7B 27 77 7F 3F 4A 17 86 F0 00 00 00 01 Key Stream (1): C1 CE 4A AB 9B 2A FB DE C7 4F 58 E2 E3 D6 7C D8 Counter Block (2): 00 E0 01 7B 27 77 7F 3F 4A 17 86 F0 00 00 00 02 Key Stream (2): 55 51 B6 38 CA 78 6E 21 CD 83 46 F1 B2 EE 0E 4C Counter Block (3): 00 E0 01 7B 27 77 7F 3F 4A 17 86 F0 00 00 00 03 Key Stream (3): 05 93 25 0C 17 55 36 00 A6 3D FE CF 56 23 87 E9 Ciphertext : C1 CF 48 A8 9F 2F FD D9 CF 46 52 E9 EF DB 72 D7 : 45 40 A4 2B DE 6D 78 36 D5 9A 5C EA AE F3 10 53 : 25 B2 07 2F
テストベクトル＃3：キー128ビット鍵のAESとAES-CTRを使用して、36オクテットの暗号化：27 77 7F 3F 4A 17 86 F0ナンス：76 91 03 5E 50 20 A8 AC 6E 61 85 29 F9 A0 DC AES-CTR IV BE ：00 E0 01 7B平文：00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F：10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F：20 21 22 23カウンタブロック（1） ：00 E0 01 7B 27 77 7F 3F 4A 17 86 F0 00 00 00 01キーストリーム（1）：C1 CE 4A AB 9B 2A FB DE C7 4F 58 E2 E3 D6 7C D8カウンタブロック（2）：00 E0 01 7B 27 77 7F 3F 4A 17 86 F0 00 00 00 02キーストリーム（2）：55 51 B6 38 CA 78 6E 21 CD 83 46 F1 B2 EE 0E 4Cカウンタブロック（3）：00 E0 01 7B 27 77 7F 3F 4A 17 86 F0 00 00 00 03キーストリーム（3）：05 93 25 0C 17 55 36 00 A6 3D FE CF 56 23 87 E9暗号文：C1 CF 48 A8 9F 2F FD D9 CF 46 52 E9 EF DB 72 D7：45 40 A4 2B DE 6D 78 36 D5 9A 5C EA AEのF3 10 53：25 B2 07 2F
Test Vector #4: Encrypting 16 octets using AES-CTR with 192-bit key AES Key : 16 AF 5B 14 5F C9 F5 79 C1 75 F9 3E 3B FB 0E ED : 86 3D 06 CC FD B7 85 15 AES-CTR IV : 36 73 3C 14 7D 6D 93 CB Nonce : 00 00 00 48 Plaintext String : 'Single block msg' Plaintext : 53 69 6E 67 6C 65 20 62 6C 6F 63 6B 20 6D 73 67 Counter Block (1): 00 00 00 48 36 73 3C 14 7D 6D 93 CB 00 00 00 01 Key Stream (1): 18 3C 56 28 8E 3C E9 AA 22 16 56 CB 23 A6 9A 4F Ciphertext : 4B 55 38 4F E2 59 C9 C8 4E 79 35 A0 03 CB E9 28
テストベクトル＃4：16 AF 5B 14 5F C9 F5 79 C1 75 F9 3E 3B FB 0E ED：86 3D 06 CCのFDのB7 85 15 AES-CTR IV：192ビット鍵のAES鍵とAES-CTRを使用して、16オクテットの暗号化36 73（c）14 7D 6D 93 CBナンス：00 00 00 48平文文字列： 'シングルブロックMSG' 平文：53 69 6E 67（c）65 20 62 6C 6F 63 6B 20 6D 73 67カウンタブロック（1）：00 00 00 48 36 73（c）14 7D 6D 93 CB 00 00 00 01キーストリーム（1）：18（c）56 28 8E 3C E9 AA 22 16 56 CB 23 A6 9A 4F暗号文：4B 55 38 4F E2 59 C9 C8 4E 79 35 A0 03 CB E9 28
Test Vector #5: Encrypting 32 octets using AES-CTR with 192-bit key AES Key : 7C 5C B2 40 1B 3D C3 3C 19 E7 34 08 19 E0 F6 9C : 67 8C 3D B8 E6 F6 A9 1A AES-CTR IV : 02 0C 6E AD C2 CB 50 0D Nonce : 00 96 B0 3B Plaintext : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F : 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F Counter Block (1): 00 96 B0 3B 02 0C 6E AD C2 CB 50 0D 00 00 00 01 Key Stream (1): 45 33 41 FF 64 9E 25 35 76 D6 A0 F1 7D 3C C3 90 Counter Block (2): 00 96 B0 3B 02 0C 6E AD C2 CB 50 0D 00 00 00 02 Key Stream (2): 94 81 62 0F 4E C1 B1 8B E4 06 FA E4 5E E9 E5 1F Ciphertext : 45 32 43 FC 60 9B 23 32 7E DF AA FA 71 31 CD 9F : 84 90 70 1C 5A D4 A7 9C FC 1F E0 FF 42 F4 FB 00
テストベクトル＃5：40 1B 3D C3 3C 19 E7 34 08 19 E0 F6（c）（c）（c）のB2：67 8C 3D B8 E6 F6 A9 1A AES-CTR IV：192ビット鍵のAES鍵とAES-CTRを使用して、32オクテットの暗号化02 0C 6E AD C2 CB 50 0Dナンス：00 96 B0 3B平文：00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F：10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1Fカウンタブロック（1）：00 96 B0 3B 02 0C 6E AD C2 CB 50 0D 00 00 00 01キーストリーム（1）：45 33 41 FF 64 9E 25 35 76 D6 A0 F1 7D 3C C3 90カウンタブロック（2）：00 96 B0 3B 02 0C 6E AD C2 CB 50 0D 00 00 00 02キーストリーム（2）：94 81 62 0F 4E C1 B1 8B E4 06 FA E4 5E E9 E5 1F暗号文：45 32 43 FC 60 9B 23 32 7E DF AA FA 71 31 CD 9F：84 90 70 1C 5A D4 A7 9C FC 1F E0 FF 42 F4 FB 00
Test Vector #6: Encrypting 36 octets using AES-CTR with 192-bit key AES Key : 02 BF 39 1E E8 EC B1 59 B9 59 61 7B 09 65 27 9B : F5 9B 60 A7 86 D3 E0 FE AES-CTR IV : 5C BD 60 27 8D CC 09 12 Nonce : 00 07 BD FD Plaintext : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F : 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F : 20 21 22 23 Counter Block (1): 00 07 BD FD 5C BD 60 27 8D CC 09 12 00 00 00 01 Key Stream (1): 96 88 3D C6 5A 59 74 28 5C 02 77 DA D1 FA E9 57 Counter Block (2): 00 07 BD FD 5C BD 60 27 8D CC 09 12 00 00 00 02 Key Stream (2): C2 99 AE 86 D2 84 73 9F 5D 2F D2 0A 7A 32 3F 97 Counter Block (3): 00 07 BD FD 5C BD 60 27 8D CC 09 12 00 00 00 03 Key Stream (3): 8B CF 2B 16 39 99 B2 26 15 B4 9C D4 FE 57 39 98 Ciphertext : 96 89 3F C5 5E 5C 72 2F 54 0B 7D D1 DD F7 E7 58 : D2 88 BC 95 C6 91 65 88 45 36 C8 11 66 2F 21 88 : AB EE 09 35
テストベクトル＃6：B1 59 B9 59 61 7B 09 65 27（b）02 BF 39 1E E8 EC：F5 9B 60 A7 86 D3 E0 FE AES-CTR IV AES-CTR 192ビット鍵のAES鍵とを使用して、36オクテットの暗号化： 5C BD 60 27 8D CC 09 12ナンス：00 07 BD FD平文：00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F：10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F： 20 21 22 23カウンタブロック（1）：00 07 BD FD 5C BD 60 27 8D CC 09 12 00 00 00 01キーストリーム（1）：96 88 3D C6 5A 59 74 28（c）02 77 DA D1 FA E9 57カウンタブロック（2）：00 07 BD FD 5C BD 60 27 8D CC 09 12 00 00 00 02キーストリーム（2）：C2 99 AE 86 D2 84 73 9F 5D 2F D2 0A 7A 32 3F 97カウンタブロック（3）：00 07 BD FD 5C BD 60 27 8D CC 09 12 00 00 00 03キーストリーム（3）：8B CF 2B 16 39 99 B2 26 15 B4 9C D4 FE 57 39 98暗号文：96 89 3F C5 5E 5C 72 2F 54 0B 7D D1 DD F7 E7 58：D2 88 BC 95 C6 91 65 88 45 36 11 66 C8 2F 21 88：AB EE 09 35
Test Vector #7: Encrypting 16 octets using AES-CTR with 256-bit key AES Key : 77 6B EF F2 85 1D B0 6F 4C 8A 05 42 C8 69 6F 6C : 6A 81 AF 1E EC 96 B4 D3 7F C1 D6 89 E6 C1 C1 04 AES-CTR IV : DB 56 72 C9 7A A8 F0 B2 Nonce : 00 00 00 60 Plaintext String : 'Single block msg' Plaintext : 53 69 6E 67 6C 65 20 62 6C 6F 63 6B 20 6D 73 67 Counter Block (1): 00 00 00 60 DB 56 72 C9 7A A8 F0 B2 00 00 00 01 Key Stream (1): 47 33 BE 7A D3 E7 6E A5 3A 67 00 B7 51 8E 93 A7 Ciphertext : 14 5A D0 1D BF 82 4E C7 56 08 63 DC 71 E3 E0 C0
テストベクトル＃7：77（b）EF F2 85 1D B0 6F 4C 8A 05 42 C8 69 6F（c）：（a）81 AF 1E EC 96 B4 D3 7F C1 D6 89 E6 AES-CTR 256ビット鍵のAES鍵とを使用して、16オクテットの暗号化C1 C1 04 AES-CTR IV：DB 56 72 C9 7A A8 F0 B2ナンス：00 00 00 60平文文字列： 'シングルブロックMSG' 平文：53 69 6E 67（c）65 20 62 6C 6F 63 6B 20 6D 73 67カウンタブロック（1）：00 00 00 60 DB 56 72 C9 7A A8 F0 B2 00 00 00 01キーストリーム（1）：47 33 BE 7A D3 E7 6E A5 3A 67 00 B7 51 8E 93 A7暗号文：14 5A D0 1D BF 82 4E C7 56 08 63 DC 71 E3 E0 C0
Test Vector #8: Encrypting 32 octets using AES-CTR with 256-bit key AES Key : F6 D6 6D 6B D5 2D 59 BB 07 96 36 58 79 EF F8 86 : C6 6D D5 1A 5B 6A 99 74 4B 50 59 0C 87 A2 38 84 AES-CTR IV : C1 58 5E F1 5A 43 D8 75 Nonce : 00 FA AC 24 Plaintext : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F : 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F Counter block (1): 00 FA AC 24 C1 58 5E F1 5A 43 D8 75 00 00 00 01 Key stream (1): F0 5F 21 18 3C 91 67 2B 41 E7 0A 00 8C 43 BC A6 Counter block (2): 00 FA AC 24 C1 58 5E F1 5A 43 D8 75 00 00 00 02 Key stream (2): A8 21 79 43 9B 96 8B 7D 4D 29 99 06 8F 59 B1 03 Ciphertext : F0 5E 23 1B 38 94 61 2C 49 EE 00 0B 80 4E B2 A9 : B8 30 6B 50 8F 83 9D 6A 55 30 83 1D 93 44 AF 1C
テストベクトル＃8：AES-CTRとを用いて、32オクテットの暗号化256ビットの鍵KEY AES：F6 D6 6D 6B D5 2D 59 BB 07 96 36 58 79 EF F8 86：C6 6D D5（a）（b）（a）99 74 4B 50 59 0C 87 A2 38 84 AES-CTR IV：C1 58 5E F1 5A 43 D8 75ナンス：00 FA AC 24平文：00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F：10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1Fカウンタブロック（1）：00 FA AC 24 C1 58 5E F1 5A 43 D8 75 00 00 00 01キーストリーム（1）：F0 5F 21 18（c）91 67（b）41 E7 0A 00 8C 43 BC A6カウンタブロック（2）：00 FA AC 24 C1 58 5E F1 5A 43 D8 75 00 00 00 02キーストリーム（2）：A8 21 79 43（b）96 8B 7D 4D 29 99 06 8F 59 B1 03暗号文：F0 5E 23図1（b）38 94 61 2C 49 EE 00 0B 80 4E B2 A9：B8 30 6B 50 8F 83（d）（a）55 30 83 1D 93 44 AF 1C
Test Vector #9: Encrypting 36 octets using AES-CTR with 256-bit key AES Key : FF 7A 61 7C E6 91 48 E4 F1 72 6E 2F 43 58 1D E2 : AA 62 D9 F8 05 53 2E DF F1 EE D6 87 FB 54 15 3D AES-CTR IV : 51 A5 1D 70 A1 C1 11 48 Nonce : 00 1C C5 B7 Plaintext : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F : 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F : 20 21 22 23 Counter block (1): 00 1C C5 B7 51 A5 1D 70 A1 C1 11 48 00 00 00 01 Key stream (1): EB 6D 50 81 19 0E BD F0 C6 7C 9E 4D 26 C7 41 A5 Counter block (2): 00 1C C5 B7 51 A5 1D 70 A1 C1 11 48 00 00 00 02 Key stream (2): A4 16 CD 95 71 7C EB 10 EC 95 DA AE 9F CB 19 00 Counter block (3): 00 1C C5 B7 51 A5 1D 70 A1 C1 11 48 00 00 00 03 Key stream (3): 3E E1 C4 9B C6 B9 CA 21 3F 6E E2 71 D0 A9 33 39 Ciphertext : EB 6C 52 82 1D 0B BB F7 CE 75 94 46 2A CA 4F AA : B4 07 DF 86 65 69 FD 07 F4 8C C0 B5 83 D6 07 1F : 1E C0 E6 B8
テストベクタ＃9：FF 7Aの61 7C E6 91 48 E4 F1 72 6E 2F 43 58 1D E2：AA 62 D9 F8 05 53 2E DF F1 EE D6 87 FB 256ビット鍵のAES鍵とAES-CTRを使用して、36オクテットの暗号化54 15 3D AES-CTR IV：51 A5 1D 70 A1 C1 11 48ナンス：00 1C C5 B7平文：00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F：10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F：20 21 22 23カウンタブロック（1）：00 1C C5 B7 51 A5 1D 70 A1 C1 11 48 00 00 00 01キーストリーム（1）：EB 6D 50 81 19 0E BD F0 C6 7C 9E 4D 26 C7 41 A5カウンタブロック（2）：00 1C C5 B7 51 A5 1D 70 A1 C1 11 48 00 00 00 02キーストリーム（2）：A4 16 CD 95 71（c）EB 10 EC 95 DA AE 9F CB 19 00カウンタブロック（3）：00 1C C5 B7 51 A5 1D 70 A1 C1 11 48 00 00 00 03キーストリーム（3）：3E E1 C4 9B C6 B9 CA 21 3F 6E E2 71 D0 A9 33 39暗号文：EB 6C 52 82 1D 0B BB F7 CE 75 94 46（a）CAの4FのAA：B4 07 DF 86 65 69 FD 07 F4 8C C0のB5 83 D6 07 1F：1E C0 E6 B8
When used properly, AES-CTR mode provides strong confidentiality. Bellare, Desai, Jokipii, Rogaway show in [BDJR] that the privacy guarantees provided by counter mode are at least as strong as those for CBC mode when using the same block cipher.
適切に使用すると、AES-CTRモードでは、強力な機密性を提供します。ベラー、デサイ、Jokipii、同じブロック暗号を使用した場合、カウンタモードによって提供されるプライバシーの保証はCBCモードのものと少なくとも同程度に強力であること[BDJR]でRogawayを示します。
Unfortunately, it is very easy to misuse this counter mode. If counter block values are 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.
残念ながら、このカウンタモードを誤用するのは非常に簡単です。カウンタブロック値は、これまでと同じキーを持つつ以上のパケットのために使用されている場合は、同じキーストリームは、両方のパケットを暗号化するために使用され、機密性の保証が無効とされています。
What happens if the encryptor XORs the same key stream with two different plaintexts? Suppose two plaintext byte sequences P1, P2, P3 and Q1, Q2, Q3 are both encrypted with key stream K1, K2, K3. The two corresponding ciphertexts are:
暗号化は、2つの異なる平文と同じキーストリームを排他的論理和演算場合はどうなりますか？ 2平文バイトのシーケンスP1、P2、P3とQ1、Q2、Q3は、両方のキーストリームK1、K2、K3を用いて暗号化されていると仮定する。 2対応する暗号文は以下のとおりです。
(P1 XOR K1), (P2 XOR K2), (P3 XOR K3)
（P1 XOR K1）、（K2）、XOR P2（P3 XOR K3）
(Q1 XOR K1), (Q2 XOR K2), (Q3 XOR K3)
（Q1 XOR K1）、（K2）、XOR（Q2とQ3 XOR K3）
If both of these two ciphertext streams are exposed to an attacker, then a catastrophic failure of confidentiality results, since:
これら2つの暗号文ストリームが攻撃にさらされているの両方、機密性の結果の致命的な障害、以降の場合：
(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
（P1 XOR K1 XOR）（XOR K1）Q1のQ1 = P1 XOR（XOR）XOR（排他的論理和Q2 K2 K2、P2）P2 = XOR（XOR K3）XOR（P3 Q2と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.
攻撃者が一緒にXOR演算2つの平文を取得したら、それらを分離することは比較的簡単です。したがって、同一のキーストリームの下に2つの平文を暗号化するために、AES-CTRを含む任意のストリーム暗号を使用して平文をリーク。
Therefore, stream ciphers, including AES-CTR, should not be used with static keys. It is inappropriate to use AES-CTR with static keys. Extraordinary measures would be needed to prevent reuse of a counter block value with the static key across power cycles. To be safe, ESP implementations MUST use fresh keys with AES-CTR. The Internet Key Exchange (IKE) protocol [IKE] can be used to establish fresh keys. IKE can also be used to establish the nonce at the beginning of the security association.
したがって、AES-CTRを含むストリーム暗号は、静的キーで使用されるべきではありません。静的なキーでAES-CTRを使用することは不適切です。臨時措置はパワーサイクル全体で静的キーとカウンタブロック値の再使用を防止するために必要とされるであろう。安全のため、ESPの実装は、AES-CTR新鮮なキーを使用する必要があります。 IKE（Internet Key Exchange）プロトコル[IKE]は、新鮮なキーを確立するために使用することができます。 IKEは、セキュリティ関連の先頭にナンスを確立するために使用することができます。
When IKE is used to establish fresh keys between two peer entities, separate keys are established for the two traffic flows. When a mechanism other than IKE is used to establish fresh keys, and that mechanism 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,
IKEは、2つのピアエンティティ間の新鮮なキーを確立するために使用される場合、別々のキーは2つのトラフィックフローのために確立されています。 IKE以外のメカニズムが新鮮な鍵を確立するために使用され、そのメカニズムがパケットを暗号化するために、単一のキーを設定した場合、その後、ピアはいくつかのパケットに同じIV値を選択する確率が高いです。このように、カウンタブロックの衝突を避けるために、
ESP implementations that permit use of the same key for encrypting outbound traffic and decrypting incoming traffic with the same peer MUST ensure that the two peers assign different Nonce values to the security association.
アウトバウンドトラフィックを暗号化し、同じピアとの着信トラフィックを解読に同じ鍵の使用を許可ESP実装は、2つのピアがセキュリティアソシエーションに異なるノンス値を割り当てることを確認しなければなりません。
Data forgery is trivial with CTR mode. The demonstration of this attack is similar to the key stream reuse discussion above. If a known plaintext byte sequence P1, P2, P3 is encrypted with key stream K1, K2, K3, then the attacker can replace the plaintext with one of his own choosing. The ciphertext is:
データ偽造はCTRモードと簡単です。この攻撃のデモは、上記のキーストリームの再利用の議論に似ています。知られている平文バイトシーケンスP1は、P2、P3は、キーストリームK1、K2、K3で暗号化されている場合、攻撃者は、自分自身の選択の一つで平文を置き換えることができます。暗号文は次のとおりです。
(P1 XOR K1), (P2 XOR K2), (P3 XOR K3)
（P1 XOR K1）、（K2）、XOR P2（P3 XOR K3）
The attacker simply XORs a selected sequence Q1, Q2, Q3 with the ciphertext to obtain:
攻撃者は、単に取得する暗号文と選択された配列のQ1、Q2、Q3を排他的論理和演算します：
(Q1 XOR (P1 XOR K1)), (Q2 XOR (P2 XOR K2)), (Q3 XOR (P3 XOR K3))
（Q1 XOR（P1 XOR K1））、（XOR（XOR））、K2（P2 Q2とQ3 XOR（XOR K3）P3）
Which is the same as:
これは同じです。
((Q1 XOR P1) XOR K1), ((Q2 XOR P2) XOR K2), ((Q3 XOR P3) XOR K3)
（（Q1 XOR P1）、（K1）、XOR（XOR）（XOR）、K2（P2 Q2とQ3 XOR）XOR K3 P3）
Decryption of the attacker-generated ciphertext will yield exactly what the attacker intended:
攻撃者は、生成された暗号文の復号化は、攻撃者が意図した正確に何が得られます：
(Q1 XOR P1), (Q2 XOR P2), (Q3 XOR P3)
（Q1 XOR P1）及び（P2）、XOR（Q2とQ3 XOR P3）
Accordingly, ESP implementations MUST use of AES-CTR in conjunction with ESP authentication.
したがって、ESP実装は、ESP認証に関連してAES-CTRを使用しなければなりません。
Additionally, since AES has a 128-bit block size, regardless of the mode employed, the ciphertext generated by AES encryption becomes distinguishable from random values after 2^64 blocks are encrypted with a single key. Since ESP with Enhanced Sequence Numbers allows for up to 2^64 packets in a single security association, there is real potential for more than 2^64 blocks to be encrypted with one key. Therefore, implementations SHOULD generate a fresh key before 2^64 blocks are encrypted with the same key. Note that ESP with 32- bit Sequence Numbers will not exceed 2^64 blocks even if all of the packets are maximum-length IPv6 jumbograms [JUMBO].
AESは、128ビットのブロックサイズを有するので、2 ^ 64ブロックは、単一の鍵で暗号化された後、さらに、関係なく、使用モードの、AES暗号化によって生成された暗号文は、ランダムな値から識別可能となります。強化されたシーケンス番号を持つESPは、単一のセキュリティアソシエーションで最大2 ^ 64パケットを可能にしているので、1つのキーで暗号化する以上の2 ^ 64ブロックのための本当の可能性があります。そのため、実装は2 ^ 64ブロックは同じ鍵で暗号化される前に、新鮮なキーを生成する必要があります。パケットのすべてが最大長のIPv6ジャンボグラム[JUMBO]であっても32ビットのシーケンス番号を持つESPは2 ^ 64ブロックを超えないことに注意してください。
There are fairly generic precomputation attacks against all block cipher modes that allow a meet-in-the-middle attack against the key. These attacks require the creation and searching of huge tables of ciphertext associated with known plaintext and known keys. Assuming that the memory and processor resources are available for a precomputation attack, then the theoretical strength of AES-CTR (and any other block cipher mode) is limited to 2^(n/2) bits, where n is the number of bits in the key. The use of long keys is the best countermeasure to precomputation attacks. Therefore, implementations that employ 128-bit AES keys should take precautions to make the precomputation attacks more difficult. The unpredictable nonce value in the counter block significantly increases the size of the table that the attacker must compute to mount a successful attack.
キーに対する中間一致攻撃を許可するすべてのブロック暗号モードに対してかなり一般的な事前計算攻撃があります。これらの攻撃は、既知の平文と知られたキーに関連付けられた暗号文の巨大なテーブルの作成と検索を必要としています。メモリとプロセッサリソースが事前計算攻撃に利用可能であると仮定すると、AES-CTRの理論強度（及び他のブロック暗号モード）nはビット数である2 ^（N / 2）ビットに制限されていますキー。長いキーを使用すると、攻撃を事前計算するための最良の対策です。したがって、128ビットのAESキーを採用して実装は事前計算攻撃をより困難にするために予防策を取る必要があります。カウンタブロックにおける予測不可能なノンス値が大きく攻撃が成功した攻撃を仕掛けるために計算しなければならないテーブルのサイズを増大させます。
In the development of this specification, the use of the ESP sequence number field instead of an explicit IV field was considered. This selection is not a cryptographic security issue, as either approach will prevent counter block collisions.
この仕様の開発では、ESPのシーケンス番号フィールドの代わりに、明示的なIVフィールドの使用が考えられました。いずれのアプローチは、カウンタブロックの衝突を防ぐことができますので、この選択は、暗号化セキュリティの問題ではありません。
In a very conservative model of encryption security, at most 2^64 blocks ought to be encrypted with AES-CTR under a single key. Under this constraint, no more than 64 bits are needed to identify each packet within a security association. Since the ESP extended sequence number is 64 bits, it is an obvious candidate for use as an implicit IV. This would dictate a single method for the assignment of per-packet value in the counter block. The use of an explicit IV does not dictate such a method, which is desirable for several reasons.
暗号化セキュリティの非常に保守的なモデルでは、最大2 ^ 64ブロックは、単一のキーの下にAES-CTRで暗号化されるべきです。この制約の下で、せいぜい64ビットは、セキュリティアソシエーション内の各パケットを識別するために必要とされません。 ESP拡張シーケンス番号は64ビットであるので、それは暗黙のIVとして使用するための明白な候補です。これは、カウンタブロックにおけるパケット単位の値の割り当てのための単一の方法を指示するであろう。明示的なIVの使用は、いくつかの理由のために望ましいような方法を、規定していません。
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.のみ暗号化値を複数のパケットに使用されていないことを保証することができるので、復号カウンタブロック値が衝突するかどうかを決定することを可能にするメカニズムを選択する利点はありません。衝突による損傷は、復号化がそれを検出したかどうかに関係なく、実行されます。
2. 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.限り、各パケットに一意の値に技術の結果として、加算器、のLFSR、および暗号化の時間バジェットを満たす任意の他の技術を許可します。加算器は、実装が単純明快ですが、運ぶのために、彼らは一定の時間で実行されません。 LFSRは、一定の時間で実行される代替手段を提供します。
3. Complexity is in control of the implementer. Further, the decision made by the implementer of the encryptor does not make the decryptor more (or less) complex.
3.複雑さは、実装者の制御です。さらに、暗号化の実装によって行われた決定は、復号部以上（または以下）の複合体を作成しません。
4. When the encryptor has more than one cryptographic hardware device, an IV prefix can be assigned to each device, ensuring that collisions will not occur. Yet, since the decryptor does not need to examine IV structure, the decryptor is unaffected by the IV structure selected by the encryptor. One cannot make use of the same technique with the ESP sequence numbers, because the semantics for them require sequential value generation.
暗号化は、複数の暗号化ハードウェアデバイスを有する場合4. IVプレフィックスは衝突が発生しないことを確実に、各デバイスに割り当てることができます。復号化は、IVの構造を検討する必要がないので、まだ、復号化は、暗号化によって選択されたIVの構造によって影響を受けません。それらのためのセマンティクスは、順次値の生成を必要とするため、一つは、ESPのシーケンス番号と同じ手法を使用することはできません。
5. Assurance boundaries are very important to implementations that will be evaluated against the FIPS Pub 140-1 or FIPS Pub 140-2 [SECRQMTS]. 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.
5.保証の境界は、140-2 [SECRQMTS]パブ140-1パブFIPSまたはFIPSに対して評価される実装に非常に重要です。パケットごとのカウンタブロック値の割り当てが保証境界内にあることが必要です。一部の実装では、保証境界内にシーケンス番号を割り当てるが、他にはありません。セクション6で説明したように、シーケンス番号の衝突が、悲惨な結果をもたらすのではなく、カウンタブロック値の衝突は、悲惨な結果を有します。
6. Coupling with the sequence number 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.
シーケンス番号6のカップリングは、シーケンス番号の割り当てが保証境界内で実行されるこれらのアーキテクチャで可能です。このような状況では、シーケンス番号とIVのフィールドに同じ値が含まれます。
7. Decoupling from the sequence number is possible in those architectures where the sequence number assignment is performed outside the assurance boundary.
シーケンス番号から7デカップリングは、シーケンス番号の割り当てが保証境界の外側に行われるものアーキテクチャで可能です。
The use of an explicit IV field directly follows from the decoupling of the sequence number and the per-packet counter block value. The overhead associated with 64 bits for the IV field is acceptable. This overhead is significantly less than the 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-CTR with an explicit IV has about one-third of the overhead as AES-CBC, and the overhead is constant for each packet.
明示的なIVフィールドの使用は、直接シーケンス番号とパケットごとのカウンタブロック値のデカップリングから得られます。 IVフィールドに64ビットに関連するオーバーヘッドが許容されます。このオーバーヘッドは、暗号ブロック連鎖（CBC）モードに関連するオーバーヘッドよりもかなり小さいです。通常用いられているように、CBCは、IVのための完全なブロックを必要とし、パディングのためのブロックの平均、半分に。明示的なIVとAES-CTRは、AES-CBCなどのオーバーヘッドの約3分の1を有し、オーバーヘッドは、各パケットに対して一定です。
The inclusion of the nonce provides a weak countermeasure against precomputation attacks. For this countermeasure to be effective, the attacker must not be able to predict the value of the nonce well in advance of security association establishment. The use of long keys provides a strong countermeasure to precomputation attacks, and AES offers key sizes that thwart these attacks for many decades to come.
ナンスを含めることは、事前計算攻撃に対して弱い対策を提供します。この対策を有効にするには、攻撃者は、セキュリティアソシエーションの確立の前に一回だけのウェルの値を予測することはできません必要があります。長いキーを使用すると、攻撃を事前計算する強力な対策を提供し、AESは今後何十年もこれらの攻撃を阻止キーのサイズを提供しています。
A 28-bit block counter value is sufficient for the generation of a key stream to encrypt the largest possible IPv6 jumbogram [JUMBO]; however, a 32-bit field is used. This size is convenient for both hardware and software implementations.
28ビットのブロックカウンタ値は、可能な最大のIPv6ジャンボグラム[JUMBO]を暗号化する鍵ストリームを生成するために十分です。しかし、32ビットのフィールドが使用されます。このサイズは、ハードウェアとソフトウェアの両方の実装のために便利です。
IANA has assigned 13 as the ESP transform number for AES-CTR with an explicit IV.
ESPは、明示的なIVとAES-CTRの番号を変換するようIANAは13が割り当てられています。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
This document is the result of extensive discussions and compromises. While not all of the participants are completely satisfied with the outcome, the document is better for their contributions.
この文書では、広範な議論と妥協の結果です。参加者のすべてではないが、結果と完全に満足していますが、文書には、彼らの貢献のためのより良いです。
The author thanks the members of the IPsec working group for their contributions to the design, with special mention of the efforts of (in alphabetical order) Steve Bellovin, David Black, Niels Ferguson, Charlie Kaufman, Steve Kent, Tero Kivinen, Paul Koning, David McGrew, Robert Moskowitz, Jesse Walker, and Doug Whiting.
著者のおかげで（アルファベット順）の努力の特別な言及したデザインへの貢献、のIPsecワーキンググループのメンバースティーブBellovin氏、デビッド・ブラック、ニールスファーガソン、チャーリー・カウフマン、スティーブ・ケント、TERO Kivinen、ポールKONING、デビッドマグリュー、ロバート・モスコウィッツ、ジェシーウォーカー、そしてダグホワイティング。
The author thanks and Alireza Hodjat, John Viega, and Doug Whiting for assistance with the test vectors.
テストベクトルの支援のための著者のおかげとアリレザHodjat、知られるJohn Viega、そしてダグホワイティング。
This section provides normative and informative references.
このセクションでは、規範的で有益な参照を提供します。
[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard (AES)", November 2001.
[AES] NIST、FIPS PUBの197、 "高度暗号化標準（AES）"、2001年11月。
[DOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[DOI]パイパー、D.、RFC 2407 "ISAKMPのための解釈のインターネットIPセキュリティー領域"、1998年11月。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ESP]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[MODES] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Methods and Techniques", NIST Special Publication 800-38A, December 2001.
[MODES] Dworkin、M.、 "操作のブロック暗号モードのための勧告：方法と技術"、は、NIST Special Publication 800-38A、2001年12月。
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[STDWORDS]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[ARCH] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[ARCH]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[BDJR] Bellare, M, Desai, A., Jokipii, E. and P. Rogaway, "A Concrete Security Treatment of Symmetric Encryption: Analysis of the DES Modes of Operation", Proceedings 38th Annual Symposium on Foundations of Computer Science, 1997.
[BDJR]ベラー、M、デサイ、A.、Jokipii、E.およびP. Rogaway、「対称暗号化の具体的なセキュリティ処理：DES運転モードの分析」、1997年コンピュータサイエンスの基礎の議事第38回シンポジウム。
[HMAC-SHA] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[HMAC-SHA] Madson、C.およびR.グレン、 "ESPおよびAH内HMAC-SHA-1-96の使用"、RFC 2404、1998年11月。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKE]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[JUMBO] Borman, D., Deering, S. and R. Hinden, "IPv6 Jumbograms", RFC 2675, August 1999.
[JUMBO】ボーマン、D.、デアリング、S.とR. Hindenと "IPv6のジャンボグラム"、RFC 2675、1999年8月。
[ROADMAP] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[ロードマップ]セイヤー、R.、Doraswamy、N.とR.グレン、 "IPセキュリティドキュメントロードマップ"、RFC 2411、1998年11月。
[SECRQMTS] National Institute of Standards and Technology. FIPS Pub 140-1: Security Requirements for Cryptographic Modules. 11 January 1994.
[SECRQMTS]アメリカ国立標準技術研究所。暗号モジュールのセキュリティ要件：FIPS 140-1をパブ。 1994年1月11日。
National Institute of Standards and Technology. FIPS Pub
140-2: Security Requirements for Cryptographic Modules.
25 May 2001. [Supercedes FIPS Pub 140-1]
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
ラッセルHousley氏ビジルセキュリティ、LLC 918春小山Driveハーンドン、VA 20170 USA
EMail: housley@vigilsec.com
メールアドレス：housley@vigilsec.com
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（C）インターネット協会（2004）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。