[要約] 要約：RFC 3602は、AES-CBC暗号アルゴリズムとIPsecの使用に関する情報を提供しています。 目的：このRFCの目的は、IPsecでのAES-CBC暗号アルゴリズムの使用方法を明確にし、セキュリティを向上させることです。
Network Working Group S. Frankel
Request for Comments: 3602 R. Glenn
Category: Standards Track NIST
S. Kelly
Airespace
September 2003
The AES-CBC Cipher Algorithm and Its Use with IPsec
AES-CBC暗号アルゴリズムとIPSECでの使用
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 (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
This document describes the use of the Advanced Encryption Standard (AES) Cipher Algorithm in Cipher Block Chaining (CBC) Mode, with an explicit Initialization Vector (IV), as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP).
このドキュメントでは、暗号ブロックチェーン（CBC）モード（CBC）モードでの高度な暗号化標準（AES）暗号アルゴリズムの使用について、明示的な初期化ベクトル（IV）を使用して、セキュリティペイロード（ESP）をカプセル化するIPSECのコンテキスト内の機密メカニズムとして説明します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Specification of Requirements. . . . . . . . . . . . . . 3
2. The AES Cipher Algorithm . . . . . . . . . . . . . . . . . . . 3
2.1. Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Key Size and Number of Rounds. . . . . . . . . . . . . . 4
2.3. Weak Keys. . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Block Size and Padding . . . . . . . . . . . . . . . . . 4
2.5. Additional Information . . . . . . . . . . . . . . . . . 4
2.6. Performance. . . . . . . . . . . . . . . . . . . . . . . 5
3. ESP Payload . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. ESP Algorithmic Interactions . . . . . . . . . . . . . . 6
3.2. Keying Material. . . . . . . . . . . . . . . . . . . . . 6
4. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. IKE Interactions . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Phase 1 Identifier . . . . . . . . . . . . . . . . . . . 10
5.2. Phase 2 Identifier . . . . . . . . . . . . . . . . . . . 10
5.3. Key Length Attribute . . . . . . . . . . . . . . . . . . 10
5.4. Hash Algorithm Considerations. . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Intellectual Property Rights Statement . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
As the culmination of a four-year competitive process, NIST (the National Institute of Standards and Technology) has selected the AES (Advanced Encryption Standard), the successor to the venerable DES (Data Encryption Standard). The competition was an open one, with public participation and comment solicited at each step of the process. The AES [AES], formerly known as Rijndael, was chosen from a field of five finalists.
4年間の競争プロセスの集大成として、NIST（国立標準技術研究所）は、Venerable DES（データ暗号化標準）の後継者であるAES（Advanced Encryption Standard）を選択しました。競争はオープンなものであり、一般の参加とコメントがプロセスの各ステップで勧誘されました。以前はRijndaelとして知られていたAES [AES]は、5人のファイナリストのフィールドから選ばれました。
The AES selection was made on the basis of several characteristics:
AES選択は、いくつかの特性に基づいて行われました。
+ security
+ 安全保障保安警備証券保証担保安保抵当安泰證券裏付け無難引き当て安全保障機密保護安全性裏付
+ unclassified
+ 未分類
+ publicly disclosed
+ 公開された
+ available royalty-free, worldwide
+ 世界中で利用可能なロイヤリティフリー
+ capable of handling a block size of at least 128 bits
+ 少なくとも128ビットのブロックサイズを処理できます
+ at a minimum, capable of handling key sizes of 128, 192, and 256 bits
+ 少なくとも、128、192、および256ビットのキーサイズを処理できます
+ computational efficiency and memory requirements on a variety of software and hardware, including smart cards
+ スマートカードを含む、さまざまなソフトウェアとハードウェアの計算効率とメモリの要件
+ flexibility, simplicity and ease of implementation
+ 柔軟性、シンプルさ、実装の容易さ
The AES will be the government's designated encryption cipher. The expectation is that the AES will suffice to protect sensitive (unclassified) government information until at least the next century. It is also expected to be widely adopted by businesses and financial institutions.
AESは、政府の指定された暗号化暗号になります。期待されるのは、AESが少なくとも次の世紀まで、敏感な（未分類の）政府情報を保護するのに十分であるということです。また、企業や金融機関によって広く採用されることも期待されています。
It is the intention of the IETF IPsec Working Group that AES will eventually be adopted as the default IPsec ESP cipher and will obtain the status of MUST be included in compliant IPsec implementations.
IETF IPSECワーキンググループの意図は、AESが最終的にデフォルトのIPSEC ESP Cipherとして採用され、準拠のIPSEC実装に含まれる必要があるステータスを取得することを目的としています。
The remainder of this document specifies the use of the AES within the context of IPsec ESP. For further information on how the various pieces of ESP fit together to provide security services, refer to [ARCH], [ESP], and [ROAD].
このドキュメントの残りの部分は、IPSEC ESPのコンテキスト内でAESの使用を指定しています。ESPのさまざまな部分がどのように適合してセキュリティサービスを提供するかについての詳細については、[Arch]、[ESP]、および[Road]を参照してください。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" that appear in this document are to be interpreted as described in [RFC-2119].
キーワードは「必要はない」、「必要」、「必須」、「shall」、「shall "、" bood "、" nove "、" becommended "、"、 "、" optional "、" optional "[RFC-2119]に記載されているように解釈されます。
All symmetric block cipher algorithms share common characteristics and variables, including mode, key size, weak keys, block size, and rounds. The following sections contain descriptions of the relevant characteristics of the AES cipher.
すべての対称ブロック暗号アルゴリズムは、モード、キーサイズ、弱いキー、ブロックサイズ、ラウンドなど、共通の特性と変数を共有します。次のセクションには、AES暗号の関連特性の説明が含まれています。
NIST has defined 5 modes of operation for AES and other FIPS-approved ciphers [MODES]: CBC (Cipher Block Chaining), ECB (Electronic CodeBook), CFB (Cipher FeedBack), OFB (Output FeedBack) and CTR (Counter). The CBC mode is well-defined and well-understood for symmetric ciphers, and is currently required for all other ESP ciphers. This document specifies the use of the AES cipher in CBC mode within ESP. This mode requires an Initialization Vector (IV) that is the same size as the block size. Use of a randomly generated IV prevents generation of identical ciphertext from packets which have identical data that spans the first block of the cipher algorithm's block size.
NISTは、AESおよびその他のFIPS承認の暗号の5つの操作モード[モード] [Modes]：CBC（Cipherブロックチェーン）、ECB（電子コードブック）、CFB（CIPHERフィードバック）、OFB（出力フィードバック）およびCTR（カウンター）を定義しています。CBCモードは、対称的な暗号に明確に定義されており、よく理解されており、現在、他のすべてのESP暗号に必要です。このドキュメントは、ESP内のCBCモードでのAES暗号の使用を指定しています。このモードには、ブロックサイズと同じサイズの初期化ベクトル（IV）が必要です。ランダムに生成されたIVを使用すると、暗号アルゴリズムのブロックサイズの最初のブロックにまたがる同一のデータがあるパケットから同一の暗号文の生成が防止されます。
The IV is XOR'd with the first plaintext block before it is encrypted. Then for successive blocks, the previous ciphertext block is XOR'd with the current plaintext, before it is encrypted.
IVは、暗号化される前に最初のPlantextブロックでXor'dです。次に、連続したブロックの場合、以前の暗号文ブロックは、暗号化される前に現在のプレーンテキストでXor'dです。
More information on CBC mode can be obtained in [MODES, CRYPTO-S]. For the use of CBC mode in ESP with 64-bit ciphers, see [CBC].
CBCモードの詳細については、[Modes、Crypto-S]で取得できます。64ビット暗号でESPでCBCモードを使用するには、[CBC]を参照してください。
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.
AESは、128ビット、192ビット、256ビットの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ラウンドを使用する必要があります。
At the time of writing this document there are no known weak keys for the AES.
このドキュメントを書いている時点では、AESの弱いキーは既知のキーはありません。
Some cipher algorithms have weak keys or keys that MUST not be used due to their interaction with some aspect of the cipher's definition. If weak keys are discovered for the AES, then weak keys SHOULD be checked for and discarded when using manual key management. When using dynamic key management, such as [IKE], weak key checks SHOULD NOT be performed as they are seen as an unnecessary added code complexity that could weaken the intended security [EVALUATION].
一部の暗号アルゴリズムには、暗号の定義の何らかの側面との相互作用のために使用してはならないキーまたはキーが弱い。AESに対して弱いキーが発見された場合、手動キー管理を使用する場合は、弱いキーをチェックし、破棄する必要があります。[IKE]などの動的キー管理を使用する場合、意図したセキュリティを弱める可能性のある不要な追加コードの複雑さと見なされるため、弱いキーチェックを実行する必要はありません[評価]。
The AES uses a block size of sixteen octets (128 bits).
AESは、16個のオクテット（128ビット）のブロックサイズを使用します。
Padding is required by the AES to maintain a 16-octet (128-bit) blocksize. Padding MUST be added, as specified in [ESP], such that the data to be encrypted (which includes the ESP Pad Length and Next Header fields) has a length that is a multiple of 16 octets.
16オクテット（128ビット）のブロックサイズを維持するために、AESがパディングを必要とします。[ESP]で指定されているように、パディングを追加する必要があります。そのため、暗号化されるデータ（ESPパッドの長さと次のヘッダーフィールドを含む）の長さは、16オクテットの倍数です。
Because of the algorithm specific padding requirement, no additional padding is required to ensure that the ciphertext terminates on a 4- octet boundary (i.e., maintaining a 16-octet blocksize guarantees that the ESP Pad Length and Next Header fields will be right aligned within a 4-octet word). Additional padding MAY be included, as specified in [ESP], as long as the 16-octet blocksize is maintained.
アルゴリズムの特定のパディング要件のため、暗号文が4オクテットの境界で終了することを確認するために追加のパディングは必要ありません（つまり、16オクテットブロックサイズの保証を維持することで、ESPパッドの長さと次のヘッダーフィールドが正しく整列されることを保証します。4-オクテットワード）。16オクテットのブロックサイズが維持されている限り、[ESP]で指定されているように、追加のパディングを含めることができます。
AES was invented by Joan Daemen from Banksys/PWI and Vincent Rijmen from ESAT-COSIC, both in Belgium, and is available world-wide on a royalty-free basis. It is not covered by any patents, and the Rijndael homepage contains the following statement: "Rijndael is available for free. You can use it for whatever purposes you want, irrespective of whether it is accepted as AES or not." AES's description can be found in [AES]. The Rijndael homepage is: http://www.esat.kuleuven.ac.be/~rijmen/rijndael/.
AESは、Banksys/PWIのJoan Daemenによって、両方ともベルギーでESAT-CosicのVincent Rijmenによって発明され、ロイヤルティフリーベースで世界中で利用可能です。特許のカバーはなく、Rijndaelのホームページには次の声明が含まれています。「Rijndaelは無料で利用できます。AESとして受け入れられるかどうかに関係なく、どんな目的でも使用できます。」AESの説明は[AES]にあります。Rijndaelのホームページはhttp：//www.esat.kuleuven.ac.be/~rijmen/rijndael/です。
The AES homepage, http://www.nist.gov/aes, contains a wealth of information about the AES, including a definitive description of the AES algorithm, performance statistics, test vectors and intellectual property information. This site also contains information on how to obtain an AES reference implementation from NIST.
AESホームページhttp://www.nist.gov/aesには、AESアルゴリズム、パフォーマンス統計、テストベクター、知的財産情報の決定的な説明など、AEに関する豊富な情報が含まれています。このサイトには、NISTからAES参照実装を取得する方法に関する情報も含まれています。
For a comparison table of the estimated speeds of AES and other cipher algorithms, please see [PERF-1], [PERF-2], [PERF-3], or [PERF-4]. The AES homepage has pointers to other analyses.
AEおよびその他の暗号アルゴリズムの推定速度の比較表については、[Perf-1]、[Perf-2]、[Perf-3]、または[Perf-4]を参照してください。AESホームページには、他の分析への指針があります。
The ESP payload is made up of the IV followed by raw cipher-text. Thus the payload field, as defined in [ESP], is broken down according to the following diagram:
ESPペイロードは、IVで構成されていて、それに続く生の暗号テキストが続きます。したがって、[ESP]で定義されているペイロードフィールドは、次の図に従って分解されます。
+---------------+---------------+---------------+---------------+
| |
+ Initialization Vector (16 octets) +
| |
+---------------+---------------+---------------+---------------+
| |
~ Encrypted Payload (variable length, a multiple of 16 octets) ~
| |
+---------------------------------------------------------------+
The IV field MUST be the same size as the block size of the cipher algorithm being used. The IV MUST be chosen at random, and MUST be unpredictable.
IVフィールドは、使用されている暗号アルゴリズムのブロックサイズと同じサイズでなければなりません。IVはランダムに選択する必要があり、予測不可能でなければなりません。
Including the IV in each datagram ensures that decryption of each received datagram can be performed, even when some datagrams are dropped, or datagrams are re-ordered in transit.
各データグラムにIVを含めることで、一部のデータグラムが削除された場合でも、輸送中にデータグラムが再注文された場合でも、受信した各データグラムの復号化が実行されることが保証されます。
To avoid CBC encryption of very similar plaintext blocks in different packets, implementations MUST NOT use a counter or other low-Hamming distance source for IVs.
さまざまなパケット内の非常に類似したプレーンテキストブロックのCBC暗号化を回避するために、実装はIVのカウンターまたはその他の低ハミング距離ソースを使用してはなりません。
Currently, there are no known issues regarding interactions between the AES and other aspects of ESP, such as use of certain authentication schemes.
現在、特定の認証スキームの使用など、AESとESPの他の側面との間の相互作用に関する既知の問題はありません。
The minimum number of bits sent from the key exchange protocol to the ESP algorithm must be greater than or equal to the key size.
キーエクスチェンジプロトコルからESPアルゴリズムに送信される最小ビット数は、キーサイズ以上でなければなりません。
The cipher's encryption and decryption key is taken from the first <x> bits of the keying material, where <x> represents the required key size.
暗号の暗号化と復号化キーは、キーイング材料の最初の<x>ビットから取得されます。<x>は、必要なキーサイズを表します。
The first 4 test cases test AES-CBC encryption. Each test case includes the key, the plaintext, and the resulting ciphertext. The values of keys and data are either hexadecimal numbers (prefixed by "0x") or ASCII character strings (surrounded by double quotes). If a value is an ASCII character string, then the AES-CBC computation for the corresponding test case DOES NOT include the trailing null character ('\0') of the string. The computed cyphertext values are all hexadecimal numbers.
最初の4つのテストケースは、AES-CBC暗号化をテストします。各テストケースには、キー、プレーンテキスト、および結果の暗号文が含まれます。キーとデータの値は、16進数（「0x」が付いている）またはASCII文字文字列（二重引用符で囲まれた）のいずれかです。値がASCII文字文字列の場合、対応するテストケースのAES-CBC計算には、文字列の後続のヌル文字（「\ 0」）が含まれません。計算されたcyphertext値はすべて16進数です。
The last 4 test cases illustrate sample ESP packets using AES-CBC for encryption. All data are hexadecimal numbers (not prefixed by "0x").
最後の4つのテストケースは、暗号化にAES-CBCを使用してサンプルESPパケットを示しています。すべてのデータは16進数です（「0x」で前に付けられていません）。
These test cases were verified using 2 independent implementations: the NIST AES-CBC reference implementation and an implementation provided by the authors of the Rijndael algorithm (http://csrc.nist.gov/encryption/aes/rijndael/ rijndael-unix-refc.tar).
これらのテストケースは、2つの独立した実装を使用して検証されました。NISTAES-CBC参照実装と、Rijndaelアルゴリズムの著者（http://csrc.nist.gov/encryption/aes/rijndael/ rijndael-unix-refcc。タール）。
Case #1: Encrypting 16 bytes (1 block) using AES-CBC with 128-bit key
Key : 0x06a9214036b8a15b512e03d534120006
IV : 0x3dafba429d9eb430b422da802c9fac41
Plaintext : "Single block msg"
Ciphertext: 0xe353779c1079aeb82708942dbe77181a
Case #2: Encrypting 32 bytes (2 blocks) using AES-CBC with 128-bit key
Key : 0xc286696d887c9aa0611bbb3e2025a45a
IV : 0x562e17996d093d28ddb3ba695a2e6f58
Plaintext : 0x000102030405060708090a0b0c0d0e0f
101112131415161718191a1b1c1d1e1f
Ciphertext: 0xd296cd94c2cccf8a3a863028b5e1dc0a
7586602d253cfff91b8266bea6d61ab1
Case #3: Encrypting 48 bytes (3 blocks) using AES-CBC with 128-bit key
Key : 0x6c3ea0477630ce21a2ce334aa746c2cd
IV : 0xc782dc4c098c66cbd9cd27d825682c81
Plaintext : "This is a 48-byte message (exactly 3 AES blocks)"
Ciphertext: 0xd0a02b3836451753d493665d33f0e886
2dea54cdb293abc7506939276772f8d5
021c19216bad525c8579695d83ba2684
Case #4: Encrypting 64 bytes (4 blocks) using AES-CBC with 128-bit key
Key : 0x56e47a38c5598974bc46903dba290349
IV : 0x8ce82eefbea0da3c44699ed7db51b7d9
Plaintext : 0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf
b0b1b2b3b4b5b6b7b8b9babbbcbdbebf
c0c1c2c3c4c5c6c7c8c9cacbcccdcecf
d0d1d2d3d4d5d6d7d8d9dadbdcdddedf
Ciphertext: 0xc30e32ffedc0774e6aff6af0869f71aa
0f3af07a9a31a9c684db207eb0ef8e4e
35907aa632c3ffdf868bb7b29d3d46ad
83ce9f9a102ee99d49a53e87f4c3da55
Case #5: Sample transport-mode ESP packet (ping 192.168.123.100) Key: 90d382b4 10eeba7a d938c46c ec1a82bf SPI: 4321 Source address: 192.168.123.3 Destination address: 192.168.123.100 Sequence number: 1 IV: e96e8c08 ab465763 fd098d45 dd3ff893
ケース＃5：サンプルトランスポートモードESPパケット（Ping 192.168.123.100）キー：90D382B4 10EEBA7A D938C46C EC1A82BF SPI：4321ソースアドレス：192.168.123.3目的地住所：192.168.23.100シーケンス番号：1 e9608d 5 DD3FF893
Original packet: IP header (20 bytes): 45000054 08f20000 4001f9fe c0a87b03 c0a87b64 Data (64 bytes): 08000ebd a70a0000 8e9c083d b95b0700 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637
元のパケット：IPヘッダー（20バイト）：45000054 08F20000 4001F9FE C0A87B03 C0A87B64データ（64バイト）：08000EBD A70A0000 D1E1F 20212223 24252627 28292A2B 2C2D2E2F 30313233 34353637
Augment data with: Padding: 01020304 05060708 090a0b0c 0d0e Pad length: 0e Next header: 01 (ICMP)
データの増強：パディング：01020304 05060708 090A0B0C 0D0Eパッド長：0E次のヘッダー：01（ICMP）
Pre-encryption Data with padding, pad length and next header (80 bytes): 08000ebd a70a0000 8e9c083d b95b0700 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637 01020304 05060708 090a0b0c 0d0e0e01Post-encryption packet with SPI, Sequence number, IV: IP header: 4500007c 08f20000 4032f9a5 c0a87b03 c0a87b64 SPI/Seq #: 00004321 00000001 IV: e96e8c08 ab465763 fd098d45 dd3ff893 Encrypted Data (80 bytes): f663c25d 325c18c6 a9453e19 4e120849 a4870b66 cc6b9965 330013b4 898dc856 a4699e52 3a55db08 0b59ec3a 8e4b7e52 775b07d1 db34ed9c 538ab50c 551b874a a269add0 47ad2d59 13ac19b7 cfbad4a6
IV：IPヘッダー：4500007C 08F20000 4032F9A5 C0A87B03 C0A87B64 SPI/SEQ＃：00004321 00000001 IV：E96E8C08 AB465763 FD098D45 DD3FF893 ENGPTED DACE（80D86AT） 9453E19 4E120849 A4870B66 CC6B9965 330013B4 898DC856 A4699E52 3A55DB08 0B59EC3A 8E4B7E52 775B07D1 DB3434349C B7 CFBAD4A6
Case #6: Sample transport-mode ESP packet
(ping -p 77 -s 20 192.168.123.100)
Key: 90d382b4 10eeba7a d938c46c ec1a82bf
SPI: 4321
Source address: 192.168.123.3
Destination address: 192.168.123.100
Sequence number: 8
IV: 69d08df7 d203329d b093fc49 24e5bd80
Original packet: IP header (20 bytes): 45000030 08fe0000 4001fa16 c0a87b03 c0a87b64 Data (28 bytes): 0800b5e8 a80a0500 a69c083d 0b660e00 77777777 77777777 77777777
オリジナルパケット：IPヘッダー（20バイト）：45000030 08FE0000 4001FA16 C0A87B03 C0A87B64データ（28バイト）：0800B5E8 A80A0500 A69C083D 0B660E00 77777777777777777777777777777777777777777777777777777777777777777777777777777777
Augment data with: Padding: 0102 Pad length: 02 Next header: 01 (ICMP)
データの増強：パディング：0102パッド長：02次のヘッダー：01（ICMP）
Pre-encryption Data with padding, pad length and next header (32 bytes): 0800b5e8 a80a0500 a69c083d 0b660e00 77777777 77777777 77777777 01020201
パディング、パッドの長さ、次のヘッダー（32バイト）を備えた前駆前データ：0800B5E8 A80A0500 A69C083D 0B660E00 7777777777777777777777777701020201
Post-encryption packet with SPI, Sequence number, IV: IP header: 4500004c 08fe0000 4032f9c9 c0a87b03 c0a87b64 SPI/Seq #: 00004321 00000008 IV: 69d08df7 d203329d b093fc49 24e5bd80 Encrypted Data (32 bytes): f5199588 1ec4e0c4 488987ce 742e8109 689bb379 d2d750c0 d915dca3 46a89f75
SPI、シーケンス番号、IV：IPヘッダー：4500004C 08FE0000 4032F9C9 C0A87B03 C0A87B64 SPI/SEQ＃：00004321 00000008 IV：69D08DF7 D203329D B093FC49 24E5BD80（32PC49 24E5BD80（ 199588 1EC4E0C4 488987CE 742E8109 689BB379 D2D750C0 D915DCA3 46A89F75
Case #7: Sample tunnel-mode ESP packet (ping 192.168.123.200) Key: 01234567 89abcdef 01234567 89abcdef SPI: 8765 Source address: 192.168.123.3 Destination address: 192.168.123.200 Sequence number: 2 IV: f4e76524 4f6407ad f13dc138 0f673f37Original packet: IP header (20 bytes): 45000054 09040000 4001f988 c0a87b03 c0a87bc8 Data (64 bytes): 08009f76 a90a0100 b49c083d 02a20400 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637
ケース＃7：サンプルトンネルモードESPパケット（Ping 192.168.123.200）キー：01234567 89ABCDEF 01234567 89ABCDEF SPI：8765ソースアドレス：192.168.123.3目的地住所：192.168.23.2300シーケンス番号：2 38 0F673F37オリジナルパケット：IPヘッダー（20バイト）：45000054 09040000 4001F988 C0A87B03 C0A87BC8データ（64バイト）：08009F76 A90A0100 B49C083D 02A20400 C1D1E1F 20212223 24252627 28292A2B 2C2D2E2F 30313233 34353637
Augment data with: Padding: 01020304 05060708 090a Pad length: 0a Next header: 04 (IP-in-IP)
データの増強：パディング：01020304 05060708 090Aパッド長：0A次のヘッダー：04（IP-in-IP）
Pre-encryption Data with original IP header, padding, pad length and next header (96 bytes): 45000054 09040000 4001f988 c0a87b03 c0a87bc8 08009f76 a90a0100 b49c083d 02a20400 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637 01020304 05060708 090a0a04
Pre-encryption Data with original IP header, padding, pad length and next header (96 bytes): 45000054 09040000 4001f988 c0a87b03 c0a87bc8 08009f76 a90a0100 b49c083d 02a20400 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637 01020304 05060708 090a0a04
Post-encryption packet with SPI, Sequence number, IV: IP header: 4500008c 09050000 4032f91e c0a87b03 c0a87bc8 SPI/Seq #: 00008765 00000002 IV: f4e76524 4f6407ad f13dc138 0f673f37 Encrypted Data (96 bytes): 773b5241 a4c44922 5e4f3ce5 ed611b0c 237ca96c f74a9301 3c1b0ea1 a0cf70f8 e4ecaec7 8ac53aad 7a0f022b 859243c6 47752e94 a859352b 8a4d4d2d ecd136e5 c177f132 ad3fbfb2 201ac990 4c74ee0a 109e0ca1 e4dfe9d5 a100b842 f1c22f0d
SPI、シーケンス番号、IV：IPヘッダー：4500008C 09050000 4032F91E C0A87B03 C0A87BC8 SPI/SEQ＃：00008765 00000002 IV：F4E76524 4F6407AD F13DC138 0（96738 0（ 773B5241 A4C44922 5E4F3CE5 ED611B0C 237CA96C F74A9301 3C1B0EA1 A0CF70F8 E4ECAEC7 8AC53AAD7A0F022B 859243C6 47752E94 A859352B 8A4D4D2D ECD136E5 C177F132 AD3FBFB2 201AC990 4C74EE0A 109E0CA1 E4DFE99D5 A100B842 F1C22F0D
Case #8: Sample tunnel-mode ESP packet
(ping -p ff -s 40 192.168.123.200)
Key: 01234567 89abcdef 01234567 89abcdef
SPI: 8765
Source address: 192.168.123.3
Destination address: 192.168.123.200
Sequence number: 5
IV: 85d47224 b5f3dd5d 2101d4ea 8dffab22
Original packet: IP header (20 bytes): 45000044 090c0000 4001f990 c0a87b03 c0a87bc8 Data (48 bytes): 0800d63c aa0a0200 c69c083d a3de0300 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
Original packet: IP header (20 bytes): 45000044 090c0000 4001f990 c0a87b03 c0a87bc8 Data (48 bytes): 0800d63c aa0a0200 c69c083d a3de0300 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
Augment data with: Padding: 01020304 05060708 090a Pad length: 0a Next header: 04 (IP-in-IP)Pre-encryption Data with original IP header, padding, pad length and next header (80 bytes): 45000044 090c0000 4001f990 c0a87b03 c0a87bc8 0800d63c aa0a0200 c69c083d a3de0300 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 01020304 05060708 090a0a04
データの増強：パディング：01020304 05060708 090Aパッド長：0A次のヘッダー：04（IP-in-IP）元のIPヘッダー、パディング、パッド長、および次のヘッダー（80バイト）：45000044 090C0000
Post-encryption packet with SPI, Sequence number, IV: IP header: 4500007c 090d0000 4032f926 c0a87b03 c0a87bc8 SPI/Seq #: 00008765 00000005 IV: 85d47224 b5f3dd5d 2101d4ea 8dffab22 Encrypted Data (80 bytes): 15b92683 819596a8 047232cc 00f7048f e45318e1 1f8a0f62 ede3c3fc 61203bb5 0f980a08 c9843fd3 a1b06d5c 07ff9639 b7eb7dfb 3512e5de 435e7207 ed971ef3 d2726d9b 5ef6affc 6d17a0de cbb13892
SPI、シーケンス番号、IV：IPヘッダー：4500007C 090D0000 4032F926 C0A87B03 C0A87BC8 SPI/SEQ＃：00008765 00000005 IV：85D47224 B5F3DD5D 2101D4EPED：15PEDEDED ANC（85D47222）：15DD4DEADES（85D47224） 683 819596A8 047232CC 00F7048F E45318E1 1F8A0F62 EDE3C3FC 61203BB5 0F980A08 C9843FD3A1B06D5C 07FF9639 B7EB7DFB 3512E5DE 435E7207 ED971EF3 D2726D9B 5EF6AFFC 6D17A0DE CBB13892
For Phase 1 negotiations, IANA has assigned an Encryption Algorithm ID of 7 for AES-CBC.
フェーズ1交渉のために、IANAはAES-CBCに7の暗号化アルゴリズムIDを割り当てました。
For Phase 2 negotiations, IANA has assigned an ESP Transform Identifier of 12 for ESP_AES.
フェーズ2の交渉のために、IANAはESP_AESに12のESP変換識別子を割り当てました。
Since the AES allows variable key lengths, the Key Length attribute MUST be specified in both a Phase 1 exchange [IKE] and a Phase 2 exchange [DOI].
AESは可変キーの長さを許可するため、主要な長さの属性は、フェーズ1の交換[IKE]とフェーズ2の交換[DOI]の両方で指定する必要があります。
A companion competition, to select the successor to SHA-1, the widely-used hash algorithm, recently concluded. The resulting hashes, called SHA-256, SHA-384 and SHA-512 [SHA2-1, SHA2-2] are capable of producing output of three different lengths (256, 384 and 512 bits), sufficient for the generation (within IKE) and authentication (within ESP) of the three AES key sizes (128, 192 and 256 bits).
最近、広く使用されているハッシュアルゴリズムであるSHA-1の後継者を選択するためのコンパニオンコンテストが最近結論付けられました。SHA-256、SHA-384、SHA-512 [SHA2-1、SHA2-2]と呼ばれる結果のハッシュは、3つの異なる長さ（256、384、および512ビット）の出力を生成できます。）および3つのAESキーサイズ（128、192、および256ビット）の認証（ESP内）。
However, HMAC-SHA-1 [HMAC-SHA] and HMAC-MD5 [HMAC-MD5] are currently considered of sufficient strength to serve both as IKE generators of 128-bit AES keys and as ESP authenticators for AES encryption using 128-bit keys.
ただし、HMAC-SHA-1 [HMAC-SHA]およびHMAC-MD5 [HMAC-MD5]は現在、128ビットAESキーのIKEジェネレーターとして、および128ビットを使用したAES暗号化のESS認証器の両方として機能するのに十分な強度があると考えられています。キー。
Implementations are encouraged to use the largest key sizes they can when taking into account performance considerations for their particular hardware and software configuration. Note that encryption necessarily impacts both sides of a secure channel, so such consideration must take into account not only the client side, but the server as well. However, a key size of 128 bits is considered secure for the foreseeable future.
実装は、特定のハードウェアとソフトウェアの構成のパフォーマンスに関する考慮事項を考慮したときに、できる最大のキーサイズを使用することをお勧めします。暗号化は必然的に安全なチャネルの両側に影響を与えるため、クライアント側だけでなくサーバーも考慮する必要があるため、そのような考慮事項も考慮する必要があります。ただし、128ビットのキーサイズは、近い将来に安全であると見なされます。
For more information regarding the necessary use of random IV values, see [CRYPTO-B].
ランダムIV値の必要な使用に関する詳細については、[Crypto-B]を参照してください。
For further security considerations, the reader is encouraged to read [AES].
さらなるセキュリティ上の考慮事項については、読者は[AES]を読むことをお勧めします。
IANA has assigned Encryption Algorithm ID 7 to AES-CBC. IANA has assigned ESP Transform Identifier 12 to ESP_AES.
IANAは、暗号化アルゴリズムID 7をAES-CBCに割り当てました。IANAは、ESP変換識別子12をESP_AESに割り当てました。
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 implementers 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エグゼクティブディレクターに宛ててください。
[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard (AES)," November 2001. http://csrc.nist.gov/publications/fips/fips197/ fips-197.{ps,pdf}
[AES] Nist、Fips Pub 197、「Advanced Encryption Standard（AES）」、2001年11月。http：//csrc.nist.gov/publications/fips/fips197/ fips-197。{ps、pdf}
[CBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[CBC] Pereira、R。およびR. Adams、「ESP CBC-Mode Cipher Algorithms」、RFC 2451、1998年11月。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ESP] Kent、S。およびR. Atkinson、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[ARCH] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[Arch] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[CRYPTO-B] Bellovin, S., "Probable Plaintext Cryptanalysis of the IP Security Protocols", Proceedings of the Symposium on Network and Distributed System Security, San Diego, CA, pp. 155-160, February 1997. http://www.research.att.com/~smb/papers/probtxt.pdf
[Crypto-B] Bellovin、S。、「IPセキュリティプロトコルの可能性のある平文単位分析」、ネットワークおよび分散システムセキュリティに関するシンポジウムの議事録、カリフォルニア州サンディエゴ、155-160ページ、1997年2月。http：//www.research.att.com/~smb/papers/probtxt.pdf
[CRYPTO-S] B. Schneier, "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1995, ISBN 0-471-12845-7.
[Crypto-S] B. Schneier、「Applied Cryptography Second Edition」、John Wiley＆Sons、New York、NY、1995、ISBN 0-471-12845-7。
[DOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[doi] Piper、D。、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、RFC 2407、1998年11月。
[EVALUATION] Ferguson, N. and B. Schneier, "A Cryptographic Evaluation of IPsec," Counterpane Internet Security, Inc., January 2000. http://www.counterpane.com/ipsec.pdf
[評価] Ferguson、N。およびB. Schneier、「IPSecの暗号化評価」、Counterpane Internet Security、Inc。、2000年1月。
[HMAC-MD5] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.
[HMAC-MD5] Madson、C。およびR. Glenn、「ESPおよびAH内のHMAC-MD5-96の使用」、RFC 2403、1998年11月。
[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. Glenn、「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] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[MODES] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Methods and Techniques," NIST Special Publication 800-38A, December 2001. http://csrc.nist.gov/publications/nistpubs/ 800-38a/sp800-38a.pdf
[Modes] Dworkin、M。、「操作のブロックモードの推奨：方法と技術の推奨」、NIST Special Publication 800-38A、2001年12月。http：//csrc.nist.gov/publications/nistpubs/800-38a/800-38a/SP800-38A.pdf
[PERF-1] Bassham, L. III, "Efficiency Testing of ANSI C Implementations of Round1 Candidate Algorithms for the Advanced Encryption Standard." http://csrc.nist.gov/encryption/aes/round1/r1-ansic.pdf
[Perf-1] Bassham、L。III、「高度な暗号化標準のRound1候補アルゴリズムのANSI C実装の効率テスト」。http://csrc.nist.gov/encryption/aes/round1/r1-ansic.pdf
[PERF-2] Lipmaa, Helger, "AES/Rijndael: speed." http://www.tcs.hut.fi/~helger/aes/rijndael.html
[Perf-2] Lipmaa、Helger、「AES/Rijndael：Speed」。http://www.tcs.hut.fi/~helger/aes/rijndael.html
[PERF-3] Nechvetal, J., E. Barker, D. Dodson, M. Dworkin, J. Foti and E. Roback, "Status Report on the First Round of the Development of the Advanced Encryption Standard." http://csrc.nist.gov/encryption/aes/round1/r1report.pdf
[Perf-3] Nechvetal、J.、E。Barker、D。Dodson、M。Dworkin、J。FotiおよびE. Roback、「高度な暗号化基準の開発の第1ラウンドに関するステータスレポート」。http://csrc.nist.gov/encryption/aes/round1/r1report.pdf
[PERF-4] Schneier, B., J. Kelsey, D. Whiting, D. Wagner, C. Hall, and N. Ferguson, "Performance Comparison of the AES Submissions." http://www.counterpane.com/aes-performance.pdf
[Perf-4] Schneier、B.、J。Kelsey、D。Whiting、D。Wagner、C。Hall、およびN. Ferguson、「AES提出のパフォーマンス比較」。http://www.counterpane.com/aes-performance.pdf
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[ROAD] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[Road] Thayer、R.、Doraswamy、N。and R. Glenn、「IP Security Document Roadmap」、RFC 2411、1998年11月。
[SHA2-1] NIST, FIPS PUB 180-2 "Specifications for the Secure Hash Standard," August 2002. http://csrc.nist.gov/publications/fips/fips180-2/ fips180-2.pdf
[SHA2-1] NIST、FIPS PUB 180-2 "Secure Hash Standardの仕様、2002年8月。http：//csrc.nist.gov/publications/fips/fips180-2/ fips180-2.pdf
[SHA2-2] "Descriptions of SHA-256, SHA-384, and SHA-512." http://csrc.nist.gov/cryptval/shs/sha256-384-512.pdf
[SHA2-2]「SHA-256、SHA-384、およびSHA-512の説明。」http://csrc.nist.gov/cryptval/shs/sha256-384-512.pdf
Portions of this text, as well as its general structure, were unabashedly lifted from [CBC].
このテキストの一部とその一般的な構造は、[CBC]からab然と解除されました。
The authors want to thank Hilarie Orman for providing expert advice (and a sanity check) on key sizes, requirements for Diffie-Hellman groups, and IKE interactions. We also thank Scott Fluhrer for his helpful comments and recommendations.
著者は、主要なサイズ、Diffie-Hellmanグループの要件、およびIKEの相互作用に関する専門家のアドバイス（および正気チェック）を提供してくれたHilarie Ormanに感謝したいと考えています。また、彼の有益なコメントと推奨事項について、Scott Fluhrerに感謝します。
Sheila Frankel NIST 820 West Diamond Ave. Room 677 Gaithersburg, MD 20899
シーラフランケルニスト820ウェストダイヤモンドアベニュールーム677ゲーサーズバーグ、メリーランド20899
Phone: +1 (301) 975-3297
EMail: sheila.frankel@nist.gov
Scott Kelly Airespace 110 Nortech Pkwy San Jose CA 95134
Scott Kelly Airespace 110 Nortech Pkwy San Jose CA 95134
Phone: +1 408 635 2000
EMail: scott@hyperthought.com
Rob Glenn NIST 820 West Diamond Ave. Room 605 Gaithersburg, MD 20899
ロブグレンニスト820ウェストダイヤモンドアベニュールーム605ゲーサーズバーグ、メリーランド20899
Phone: +1 (301) 975-3667
EMail: rob.glenn@nist.gov
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。