ネットワーク WG
Request for Comments: 3602
分類: スタンダードトラック
S. Frankel
R. Glenn
NIST
S. Kelly
Airespace
2003年 9月

AES-CBC 暗号アルゴリズムと IPsec でのその使用法
(The AES-CBC Cipher Algorithm and Its Use with IPsec)

 

このメモの位置付け 
この文書は、インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを定義するとともに、それを改良するための議論や提言を求めるものである。このプロトコルの標準化状態およびステータスについては、「Internet Official Protocol Standards」(STD 1) の最新版を参照すること。 このメモの配布に制限はない。
著作権表記
Copyright (C) The Internet Society (2003). All Rights Reserved.
要旨 
この文書では、IPsec 暗号ペイロード(Encapsulating Security Payload:ESP)における機密性の仕組みとして、明示的初期ベクトル(Initialization Vector:IV)を伴う暗号ブロック連鎖(CBC)モードでの AES(Advanced Encryption Standard)暗号アルゴリズムの使用法について記述する。
目次 
1. はじめに
1.1. 要求条件を指定する用語
2. AES 暗号アルゴリズム
2.1. モード
2.2. 鍵長とラウンド数
2.3. 脆弱鍵
2.4. ブロックサイズとパディング
2.5. 付加情報
2.6. 性能
3. ESP ペイロード
3.1. ESP アルゴリズム相互作用
3.2. 鍵素材
4. テストベクトル

5. IKE 相互作用

5.1. フェーズ 1 識別子
5.2. フェーズ 2 識別子
5.3. 鍵長属性
5.4. ハッシュアルゴリズムに関する考慮事項
6. セキュリティに関する考慮事項

7. IANA に関する考慮事項

8. 知的財産権表示

9. 参考文献

9.1. 基準としている参考文献
9.2. 基準としていない参考文献
10. 謝辞

11. 著者の連絡先

12. 著作権表示全文

1. はじめに 
4 年に渡る選考の結果、NIST(National Institute of Standards and Technology)は、由緒ある DES(Data Encryption Standard)の後継である AES(Advanced Encryption Standard)を選出した。 選考会は開かれたものであり、その過程の各ステップにおいて、一般からの参加とコメントが求められた。 そして、かつては Rijndael として知られていた AES [AES] が 5 つの最終候補の中から選出された。

AES の選考は、以下のいくつかの特性を基本として行われた。

+ セキュリティ

+ 機密扱いではないこと

+ 一般に公開されていること

+ 世界中で特許権使用料が無料で利用できること

+ 最低 128 ビットのブロックサイズを扱えること

+ 最低、128 ビット、192 ビット、256 ビットの鍵長を扱えること

+ スマートカードを含め、様々なソフトウェアおよびハードウェアにおける計算効率とメモリ要件

+ 実装の柔軟性、単純性、そして、容易性

AES は、政府指定の暗号となるだろう。 AES は、最低でも次世紀までは、政府の取扱注意(機密扱いなし)情報を保護するのに十分であると予測される。 また、それは、ビジネスや金融機関にも広く採用されると予測される。

IETF IPsec ワーキンググループは、将来的には AES を IPsec ESP のデフォルト暗号として採用し、仕様に適合した IPsec 実装に含まれる MUST のステータスにするつもりである。

この文書の残りの部分では、IPsec ESP における AES の使用法について定義する。セキュリティサービスを提供するために、ESP の様々な要素がどのように適合しあうのかということへのさらなる情報については、[ARCH]、[ESP]、そして、[ROAD] を参照すること。

1.1. 要求条件を指定する用語 
この文書において、しなければならない(MUST)、してはならない(MUST NOT)、要求される(REQUIRED)、することになる(SHALL)、することはない(SHALL NOT)、する必要がある(SHOULD)、しないほうがよい(SHOULD NOT)、推奨される(RECOMMENDED)、してもよい(MAY)、選択できる(OPTIONAL)のキーワードが使用された場合は、[RFC-2119] における定義に沿って解釈されるものとする。
2. AES 暗号アルゴリズム 
すべての対称ブロック暗号アルゴリズムは、モードや鍵長、脆弱鍵、ブロックサイズ、ラウンドなどの共通の特性と変数を持っている。
この後に続く節では、AES 暗号に関係する特性について記述する。
2.1. モード 
NIST は、AES およびその他の FIPS として承認された暗号について、5 つの動作モード(CBC(Cipher Block Chaining)、ECB(Electronic CodeBook)、CFB(Cipher FeedBack)、OFB(Output FeedBack)、CTR(Counter))を定義した。
CBC モードは、対称暗号に対して十分に定義され、かつ、理解しやすいものであり、現在、他のすべての ESP 暗号に対して要求されている。
この文書では、ESP における CBC モードでの AES 暗号の使用法について指定する。
このモードでは、ブロックサイズと同じサイズの初期ベクトル(IV)を必要とする。
ランダムに生成された IV を使用することにより、暗号アルゴリズムのブロックサイズ分の最初のブロックに同一のデータを持つパケットから同一の暗号文を生成することを防ぐことができる。

IV は、暗号化される前の最初の平文ブロックと XOR される。
そして、続くブロックに対しては、前の暗号文ブロックが、暗号化される前の現在の平文と XOR される。

CBC モードに関するさらなる情報は、[MODES, CRYPTO-S] から得ることができる。
64 ビット暗号を使用した ESP における CBC モードの使用法については、[CBC] を見ること。

2.2. 鍵長とラウンド数 
AES は、128 ビット、192 ビット、256 ビットの 3 つの鍵長をサポートする。
デフォルトの鍵長は 128 ビットであり、すべての実装は、この鍵長をサポートしなければならない(MUST)
実装は、192 ビットおよび 256 ビットの鍵長をサポートしてもよい(MAY)

AES は、定義された鍵長のそれぞれに対して、異なるラウンド数を使用する。
128 ビットの鍵が使用された場合、実装は 10 ラウンドを使用しなければならない(MUST)
192 ビットの鍵が使用された場合、実装は 12 ラウンドを使用しなければならない(MUST)
256 ビットの鍵が使用された場合、実装は 14 ラウンドを使用しなければならない(MUST)

2.3. 脆弱鍵 
本文書執筆時点では、AES に対して既知の脆弱鍵は存在しない。

いくつかの暗号アルゴリズムは、脆弱鍵、または、その暗号定義のある状況との相互作用により使用されてはならない(MUST)鍵を持っている。
もし、脆弱鍵が AES に対して発見された場合は、手動鍵管理を使用している場合は、脆弱鍵はチェックされ、破棄される必要がある(SHOULD)
[IKE] のような動的鍵管理を使用している場合は、脆弱鍵のチェックは、意図したセキュリティを弱める可能性のある、不必要に付加された複雑なコードと見なされるため、実行しないほうがよい(SHOULD NOT)[EVALUATION]。

2.4. ブロックサイズとパディング 
AES は、16 オクテット(128 ビット)のブロックサイズを使用する。

パディングは、AES において 16 オクテット(128 ビット)のブロックサイズを維持するために必要とされる。
パディングは、暗号化されるデータ(ESP のパディング長フィールドおよび次ヘッダフィールドを含む)が 16 オクテットの倍数の長さを持つように、[ESP] において指定されているように付加されなければならない(MUST)

アルゴリズム特有のパディング要件により、暗号文が 4 オクテット境界で終了することを保証するために付加するパディングは必要ない(つまり、16 オクテットのブロックサイズが、ESP のパディング長フィールドおよび次ヘッダフィールドを 4 オクテットワード内で正確に整列することを保証する)。
16 オクテットのブロックサイズが維持されている限り、[ESP] において指定されているように、付加的なパディングが含まれてもよい(MAY)

2.5. 付加情報 
AES は、Banksys/PWI の Joan Daemen と ESAT-COSIC の Vincent Rijmen(ともにベルギー)によって発明され、世界中で無料で利用可能である。
それは、特許で保護されておらず、Rijndael のホームページには、「Rijndael は無料で利用できる。それが AES として採用されるかどうかに関わらず、あなたは、あなたが求めるどのような目的に対してもそれを利用することができる。」という声明がある。
AES の記述は [AES] で見つけることができる。
Rijndael のホームページは、http://www.esat.kuleuven.ac.be/~rijmen/rijndael/ である。

AES のホームページ(http://www.nist.gov/aes)には、AES のアルゴリズム、性能統計、テストベクトル、知的財産情報についての信頼ある記述を含め、AES に関する豊富な情報が含まれている。
このサイトには、NIST からの AES の参照実装の入手方法に関する情報も含まれている。

2.6. 性能 
AES と他の暗号アルゴリズムのスピードの見積もりの比較表については、[PERF-1]、[PERF-2]、[PERF-3]、[PERF-4] を参照すること。
AES ホームページには、その他の分析に対するポインタがある。
3. ESP ペイロード 
ESP ペイロードは、IV にバイナリの暗号テキストが続くように構成される。
そのため、 [ESP] で定義されているように、ペイロードフィールドは、次の図に従って分類される。
   +---------------+---------------+---------------+---------------+
   |                                                               |
   +               Initialization Vector (16 octets)               +
   |                                                               |
   +---------------+---------------+---------------+---------------+
   |                                                               |
   ~ Encrypted Payload (variable length, a multiple of 16 octets)  ~
   |                                                               |
   +---------------------------------------------------------------+
IV フィールドは、使用される暗号アルゴリズムのブロックサイズと同じ長さでなければならない(MUST)
IV はランダムに選ばれなければならず(MUST)、予測不可能でなければならない(MUST)

各データグラムに IV を含むことにより、一部のデータグラムがドロップした場合、あるいはデータグラムが配送中に再送要求された場合でも、各受信データグラムの復号処理が可能となる。

異なるパケットの非常に似通った平文ブロックの CBC 暗号化を避けるため、実装では、IV にカウンタまたはその他のロウハミングディスタンスソースを使用してはならない(MUST NOT)

3.1. ESP アルゴリズム相互作用 
現在、AES と、ある種の認証スキームの使用のような、ESP の他の側面との間の相互作用に関して、既知の問題は存在しない。
3.2. 鍵素材 
鍵交換プロトコルから ESP アルゴリズムに送られる最小ビット数は、鍵長以上でなければならない。

暗号化および復号化用の鍵は、鍵素材の最初の <x> ビット分(<x> は必要な鍵長をあらわす)から取得される。

4. テストベクトル 
最初の 4 つのテストケースは、AES-CBC の暗号化をテストするものである。
各テストケースには、鍵、平文、そして、結果として生じる暗号文が含まれている。
鍵およびデータの値は、16 進数表記(最初に "0x" が付く)または ASCII 文字列(ダブルクォーテーションでくくられている)のいずれかである。
値が ASCII 文字列である場合は、該当するテストケースにおける AES-CBC 計算では、文字列の最後の NULL 文字('\0')は含めない(DOES NOT)
計算された暗号文は、すべて 16 進数表記である。

最後の 4 つのテストケースは、AES-CBC を使用して暗号化した ESP パケットの例を示したものである。
すべてのデータは 16 進数表記である(最初に "0x" は付かない)。

これらのテストケースは、2つの独立した実装(NIST AES-CBC 参照実装、および、Rijndael アルゴリズムの著者によって提供された実装(http://csrc.nist.gov/encryption/aes/rijndael/rijndael-unix-refc.tar))によって検証された。

ケース #1:16 バイト(1 ブロック)を 128 ビットの鍵で AES-CBC を使用して暗号化
鍵 :0x06a9214036b8a15b512e03d534120006
IV :0x3dafba429d9eb430b422da802c9fac41
平文 :"Single block msg"
暗号文 :0xe353779c1079aeb82708942dbe77181a

ケース #2:32 バイト(2 ブロック)を 128 ビットの鍵で AES-CBC を使用して暗号化
鍵 :0xc286696d887c9aa0611bbb3e2025a45a
IV :0x562e17996d093d28ddb3ba695a2e6f58
平文 :0x000102030405060708090a0b0c0d0e0f 101112131415161718191a1b1c1d1e1f
暗号文 :0xd296cd94c2cccf8a3a863028b5e1dc0a 7586602d253cfff91b8266bea6d61ab1

ケース #3:48 バイト(3 ブロック)を 128 ビットの鍵で AES-CBC を使用して暗号化
鍵 :0x6c3ea0477630ce21a2ce334aa746c2cd
IV :0xc782dc4c098c66cbd9cd27d825682c81
平文 :"This is a 48-byte message (exactly 3 AES blocks)"
暗号文 :0xd0a02b3836451753d493665d33f0e886 2dea54cdb293abc7506939276772f8d5 021c19216bad525c8579695d83ba2684

ケース #4:64 バイト(4 ブロック)を 128 ビットの鍵で AES-CBC を使用して暗号化
鍵 :0x56e47a38c5598974bc46903dba290349
IV :0x8ce82eefbea0da3c44699ed7db51b7d9
平文 :0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf b0b1b2b3b4b5b6b7b8b9babbbcbdbebf c0c1c2c3c4c5c6c7c8c9cacbcccdcecf d0d1d2d3d4d5d6d7d8d9dadbdcdddedf
暗号文 :0xc30e32ffedc0774e6aff6af0869f71aa 0f3af07a9a31a9c684db207eb0ef8e4e 35907aa632c3ffdf868bb7b29d3d46ad 83ce9f9a102ee99d49a53e87f4c3da55

ケース #5:トランスポートモード ESP パケットの例(ping 192.168.123.100)
鍵:90d382b4 10eeba7a d938c46c ec1a82bf
SPI:4321
送信元アドレス:192.168.123.3
宛先アドレス:192.168.123.100
シーケンス番号:1
IV:e96e8c08 ab465763 fd098d45 dd3ff893

オリジナルパケット:
IP ヘッダ(20 バイト):45000054 08f20000 4001f9fe c0a87b03 c0a87b64
データ(64 バイト):
08000ebd a70a0000 8e9c083d b95b0700 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637

増加データ:
パディング:01020304 05060708 090a0b0c 0d0e
パディング長:0e
次ヘッダ:01(ICMP)

パディング、パディング長、次ヘッダを伴った暗号化前のデータ(80 バイト):
08000ebd a70a0000 8e9c083d b95b0700 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637 01020304 05060708 090a0b0c 0d0e0e01

SPI、シーケンス番号、IV を伴った暗号化後のパケット:
IP ヘッダ:4500007c 08f20000 4032f9a5 c0a87b03 c0a87b64
SPI/シーケンス番号:00004321 00000001
IV:e96e8c08 ab465763 fd098d45 dd3ff893
暗号化後のデータ(80 バイト):
f663c25d 325c18c6 a9453e19 4e120849 a4870b66 cc6b9965 330013b4 898dc856 a4699e52 3a55db08 0b59ec3a 8e4b7e52 775b07d1 db34ed9c 538ab50c 551b874a a269add0 47ad2d59 13ac19b7 cfbad4a6

ケース #6:トランスポートモード ESP パケットの例(ping -p 77 -s 20 192.168.123.100)
鍵:90d382b4 10eeba7a d938c46c ec1a82bf
SPI:4321
送信元アドレス:192.168.123.3
宛先アドレス:192.168.123.100
シーケンス番号:8
IV:69d08df7 d203329d b093fc49 24e5bd80

オリジナルパケット:
IP ヘッダ(20 バイト):45000030 08fe0000 4001fa16 c0a87b03 c0a87b64
データ(28 バイト):
0800b5e8 a80a0500 a69c083d 0b660e00 77777777 77777777 77777777

増加データ:
パディング:0102
パディング長:02
次ヘッダ:01(ICMP)

パディング、パディング長、次ヘッダを伴った暗号化前のデータ(32 バイト):
0800b5e8 a80a0500 a69c083d 0b660e00 77777777 77777777 77777777 01020201

SPI、シーケンス番号、IV を伴った暗号化後のパケット:
IP ヘッダ:4500004c 08fe0000 4032f9c9 c0a87b03 c0a87b64
SPI/シーケンス番号:00004321 00000008
IV:69d08df7 d203329d b093fc49 24e5bd80
暗号化後のデータ(32 バイト):
f5199588 1ec4e0c4 488987ce 742e8109 689bb379 d2d750c0 d915dca3 46a89f75

ケース #7:トンネルモード ESP パケットの例(ping 192.168.123.200)
鍵:01234567 89abcdef 01234567 89abcdef
SPI:8765
送信元アドレス:192.168.123.3
宛先アドレス:192.168.123.200
シーケンス番号:2
IV:f4e76524 4f6407ad f13dc138 0f673f37

オリジナルパケット:
IP ヘッダ(20 バイト):45000054 09040000 4001f988 c0a87b03 c0a87bc8
データ(64 バイト):
08009f76 a90a0100 b49c083d 02a20400 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637

増加データ:
パディング:01020304 05060708 090a
パディング長:0a
次ヘッダ:04(IP-in-IP)

オリジナルのIPヘッダ、パディング、パディング長、次ヘッダを伴った暗号化前のデータ(96 バイト):
45000054 09040000 4001f988 c0a87b03 c0a87bc8 08009f76 a90a0100 b49c083d 02a20400 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637 01020304 05060708 090a0a04

SPI、シーケンス番号、IV を伴った暗号化後のパケット:
IP ヘッダ:4500008c 09050000 4032f91e c0a87b03 c0a87bc8
SPI/シーケンス番号:00008765 00000002
IV:f4e76524 4f6407ad f13dc138 0f673f37
暗号化後のデータ(96 バイト):
773b5241 a4c44922 5e4f3ce5 ed611b0c 237ca96c f74a9301 3c1b0ea1 a0cf70f8 e4ecaec7 8ac53aad 7a0f022b 859243c6 47752e94 a859352b 8a4d4d2d ecd136e5 c177f132 ad3fbfb2 201ac990 4c74ee0a 109e0ca1 e4dfe9d5 a100b842 f1c22f0d

ケース #8:トンネルモード ESP パケットの例(ping -p ff -s 40 192.168.123.200)
鍵:01234567 89abcdef 01234567 89abcdef
SPI:8765
送信元アドレス:192.168.123.3
宛先アドレス:192.168.123.200
シーケンス番号:5
IV:85d47224 b5f3dd5d 2101d4ea 8dffab22

オリジナルパケット:
IP ヘッダ(20 バイト):45000044 090c0000 4001f990 c0a87b03 c0a87bc8
データ(48 バイト):
0800d63c aa0a0200 c69c083d a3de0300 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff

増加データ:
パディング:01020304 05060708 090a
パディング長:0a
次ヘッダ:04(IP-in-IP)

オリジナルの IP ヘッダ、パディング、パディング長、次ヘッダを伴った暗号化前のデータ(80 バイト):
45000044 090c0000 4001f990 c0a87b03 c0a87bc8 0800d63c aa0a0200 c69c083d a3de0300 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 01020304 05060708 090a0a04

SPI、シーケンス番号、IV を伴った暗号化後のパケット:
IP ヘッダ:4500007c 090d0000 4032f926 c0a87b03 c0a87bc8
SPI/シーケンス番号:00008765 00000005
IV:85d47224 b5f3dd5d 2101d4ea 8dffab22
暗号化後のデータ(80 バイト):
15b92683 819596a8 047232cc 00f7048f e45318e1 1f8a0f62 ede3c3fc 61203bb5 0f980a08 c9843fd3 a1b06d5c 07ff9639 b7eb7dfb 3512e5de 435e7207 ed971ef3 d2726d9b 5ef6affc 6d17a0de cbb13892

5. IKE 相互作用 
5.1. フェーズ 1 識別子 
フェーズ 1 折衝のために、IANA は、暗号化アルゴリズム ID 7 を AEC-CBC に割り当てた。
5.2. フェーズ 2 識別子 
フェーズ 2 折衝のために、IANA は、ESP トランスフォーム ID 12 を ESP_AES に割り当てた。
5.3. 鍵長属性 
AES は、可変長の鍵を許可するため、鍵長属性は、フェーズ 1 交換 [IKE] とフェーズ 2 交換 [DOI] の両方で指定されなければならない(MUST)
5.4. ハッシュアルゴリズムに関する考慮事項 
最近、広く使用されているハッシュアルゴリズムである SHA-1 の後継を選出するためのもう一方の選考会が終了した。
選出された SHA-256、SHA-384、SHA-512 [SHA2-1, SHA2-2] と呼ばれるハッシュは、3 つの AES の鍵長(128、192、256ビット)の(IKEでの)生成および(ESPでの)認証に十分な 3 つの異なる長さの出力(256、384、512 ビット)を生成することができる。

しかしながら、HMAC-SHA-1 [HMAC-SHA] および HMAC-MD5 [HMAC-MD5] は、現在、128 ビットの AES 鍵の IKE 生成子として、そして、128 ビットの鍵を使用した AES 暗号化のための ESP 認証子として、十分な強度を提供すると考えられている。

6. セキュリティに関する考慮事項 
特定のハードウェアおよびソフトウェアの設定に対して性能を考慮した場合、実装は、可能な限り最大の鍵長を使用することが推奨される。
暗号化は、必然的にセキュアチャネルの両側に影響を及ぼすということに注意すること。
そのため、このような考慮はクライアント側だけでなく、サーバ側に対してもなされなければならない。
しかしながら、128 ビットの鍵長は、近い将来に対しては安全であると考えられている。

ランダムな IV 値の使用の必要性に関するさらなる情報については、[CRYPTO-B] を参照すること。

さらなるセキュリティに関する考察については、読者は [AES] を読むことを推奨する。

7. IANA に関する考慮事項 
IANA は、暗号化アルゴリズム ID 7 を AEC-CBC に割り当てた。
IANA は、ESP トランスフォーム ID 12 を ESP_AES に割り当てた。
8. 知的財産権表示 
この文書に記述される技術の実装および使用に関係すると主張される、知的財産権およびその他の権利の有効性または範囲に関して、またこのような権利の下でのあらゆる権利が効力を持つ範囲に関して、IETF はいかなる立場もとらず、また、IETF はそのような権利を確認するためのいかなる取り組みを行ったことも表明しない。
スタンダードトラックおよび標準関連文書における権利に関する IETF の手続きは、BCP-11 で見ることができる。
出版を目的に利用可能な権利主張のコピーおよび利用可能となるライセンス保証のコピー、あるいは、この仕様の実装者やユーザによる所有権の使用に対する一般的な権利や許可を得るために行われた試みの結果は、IETF 事務局から入手可能である。

IETF は、どのような利害関係者に対しても、この標準を実行するために必要な技術をカバーする著作権や特許、特許出願、その他の所有権に対して注意を払うように依頼する。
どうか IETF の Executive Director に情報を伝えてください。

9. 参考文献 
9.1. 基準としている参考文献 
[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard (AES)," November 2001. 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.

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

9.2. 基準としていない参考文献 
[ARCH] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.

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

[EVALUATION] Ferguson, N. and B. Schneier, "A Cryptographic Evaluation of IPsec," Counterpane Internet Security, Inc., January 2000. http://www.counterpane.com/ipsec.pdf

[HMAC-MD5] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.

[HMAC-SHA] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.

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

[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

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

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

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

[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-2] "Descriptions of SHA-256, SHA-384, and SHA-512." http://csrc.nist.gov/cryptval/shs/sha256-384-512.pdf

10. 謝辞 
この文章のある部分は、全体的な文書構造と同様に、厚かましくも [CBC] から拝借させていただいた。

著者は Hilarie Orman に、鍵長、Diffie-Hellman グループ用の必要条件、および、IKE 相互作用における専門的な助言(そしてサニティチェック(sanity check))を与えてくれたことに対して感謝したい。さらに、私たちは、有用なコメントおよび薦めに対して、Scott Fluhrer にも感謝する。

11. 著者のアドレス 
Sheila Frankel
NIST
820 West Diamond Ave.
Room 677
Gaithersburg, MD 20899
 
電話: +1 (301) 975-3297
EMail: sheila.frankel@nist.gov
 
 
Scott Kelly
Airespace
110 Nortech Pkwy
San Jose CA 95134
 
電話: +1 408 635 2000
EMail: scott@hyperthought.com
 
 
Rob Glenn
NIST
820 West Diamond Ave.
Room 605
Gaithersburg, MD 20899
 
電話: +1 (301) 975-3667
EMail: rob.glenn@nist.gov
 
 
翻訳者のアドレス
 
株式会社 NTTデータ
技術開発本部
馬場 達也
 
EMail: babatt@nttdata.co.jp
12. 著作権表示全文 
Copyright (C) The Internet Society (2003). All Rights Reserved.

本文書とその翻訳は、複製および他に提供することができる。 また、この文書に論評や説明を加えたり、その実装を補助するものは、上記の著作権表示およびこの節を付加していれば、全体あるいは一部であっても一切の制約を課されることなく作成、複製、発表、配布できる。 ただし、この文書自体に対して、著作権表示やインターネットソサエティもしくは他のインターネット関連団体への参照を取り除くなどの変更を加えてはならない。 インターネット標準化過程で定義されている著作権のための手続きに従って、インターネット標準を開発するために必要な場合や、RFC を英語以外の言語に翻訳する必要がある場合はそのかぎりでない。

上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはない。

本文書とここに含まれた情報は「無保証」で提供され、インターネットソサエティおよび IETF はすべての保証を明示的にも暗黙的にもおこなわない。その中には、この情報がいかなる権利も侵害していないという保証や、商用利用および特定目的における適合性への保証が含まれる。

謝辞 
現在、RFC エディタの機能に対する資金は、インターネットソサエティによって提供されている。