この文書は、インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを定義するとともに、それを改良するための議論や提言を求めるものである。このプロトコルの標準化状態およびステータスについては、「Internet Official Protocol Standards」(STD 1) の最新版を参照すること。 このメモの配布に制限はない。

Copyright (C) The Internet Society (2005).

オリジナルの IKEv1（Internet Key Exchange version 1）の仕様で要求され、提案されたアルゴリズムは、現在の IPsec 市場の要求の現実を反映していない。 オリジナルの仕様は、弱いセキュリティを許容し、弱く実装されたアルゴリズムを提案している。 本書は、オリジナルの仕様書である RFC 2409 を更新するものであり、今日、利用されているすべての IKEv1 実装を対象としている。

オリジナルの IKEv1 の定義 [RFC2409] では、IPsec ユーザのニーズにマッチしない MUST レベルおよび SHOULD レベルの要求事項のセットについて記述している。 本書は、そこで定義されているアルゴリズムに関する要求事項を変更することにより、RFC 2409 を更新するものである。

本書において、しなければならない (MUST)、してはならない (MUST NOT)、要求される (REQUIRED)、することになる (SHALL)、することはない (SHALL NOT)、する必要がある (SHOULD)、しないほうがよい (SHOULD NOT)、推奨される (RECOMMENDED)、してもよい (MAY)、選択できる (OPTIONAL) のキーワードが使用された場合は、[RFC2119] における定義に沿って解釈されるものとする。

RFC 2409 には、次の MUST レベルおよび SHOULD レベルの要求事項が記載されている。

• 暗号化用に、DES をサポートしなければならない (MUST)。
• ハッシュ用および HMAC 関数用に、MD5 および SHA-1 をサポートしなければならない (MUST)。
• 認証用に、事前共有秘密鍵をサポートしなければならない (MUST)。
• Diffie-Hellman MODP グループ 1（離散対数 768 ビット）をサポートしなければならない (MUST)。
• 暗号化用に、3DES をサポートする必要がある (SHOULD)。
• ハッシュ用に、Tiger をサポートする必要がある (SHOULD)。
• 署名を使用した認証用に、DSA および RSA をサポートする必要がある (SHOULD)。
• 暗号化を使用した認証用に、RSA をサポートする必要がある (SHOULD)。
• Diffie-Hellman MODP グループ 2（離散対数 1024 ビット）をサポートする必要がある (SHOULD)。

RFC 2409 には、楕円暗号を使用した Diffie-Hellman MODP グループに対する 2 つの矛盾する要求レベルが記述されている。その仕様の 4 章では、「IKE 実装は、...（中略）... ECP および EC2N グループをサポートしても良い (MAY)」と記述されているが、6.3 節では、EC2N グループに関する MODP グループ 3 および 4 をサポートする必要がある (SHOULD) と記述されている。

ここでは、IKEv1 に対する新たな要求事項をリストアップする。いくつかの要求事項は、RFC 2409 と同じであるが、その他は変更されていることに注意すること。

• 暗号化用に、トリプル DES をサポートしなければならない (MUST)。
• 暗号化用に、CBC モードの AES-128 [RFC3602] をサポートする必要がある (SHOULD)。
• ハッシュ用および HMAC 関数用に、SHA-1 をサポートしなければならない (MUST)。
• 認証用に、事前共有秘密鍵をサポートしなければならない (MUST)。
• PRF 関数用に、XCBC モードの AES-128（[RFC3566] および [RFC3664]）をサポートする必要がある (SHOULD)。
• Diffie-Hellman MODP グループ 2（離散対数 1024 ビット）をサポートしなければならない (MUST)。
• Diffie-Hellman MODP グループ 14（離散対数 2048 ビット）[RFC3526] をサポートする必要がある (SHOULD)。
• 署名を使用した認証用に、RSA をサポートする必要がある (SHOULD)。

将来、IKEv1 に対して追加の更新が行われた場合には、暗号化用に CBC モードの AES-128 の実装が必須となる可能性が高い。

RFC 2409 で MUST レベルおよび SHOULD レベルとしてリストアップされていたその他のアルゴリズムは、現在は、MAY レベルとなっている。 これには、暗号化用の DES、ハッシュ用の MD5 および Tiger、Diffie-Hellman MODP グループ 1、楕円暗号を使用した Diffie-Hellman MODP グループ、署名を使用した認証用の DSA、暗号化を使用した認証用の RSA が含まれる。

暗号化用の DES、ハッシュ用の MD5、Diffie-Hellman MODP グループ 1 は、暗号的な脆弱性により MAY に落とされている。

ハッシュ用の Tiger、楕円暗号を使用した Diffie-Hellman MODP グループ、署名を使用した認証用の DSA、暗号化を使用した認証用の RSA は、あまり利用されていないことや、相互接続性が欠如していることから落とされた。

Algorithm                     RFC 2409    本書
------------------------------------------------------------------
DES for encryption            MUST        MAY（暗号的に脆弱なため）
TripleDES for encryption      SHOULD      MUST
AES-128 for encryption        N/A         SHOULD
MD5 for hashing and HMAC      MUST        MAY（暗号的に脆弱なため）
SHA1 for hashing and HMAC     MUST        MUST
Tiger for hashing             SHOULD      MAY（利用されてないため）
AES-XCBC-MAC-96 for PRF       N/A         SHOULD
Pre-shared secrets            MUST        MUST
RSA with signatures           SHOULD      SHOULD
DSA with signatures           SHOULD      MAY（利用されていないため）
RSA with encryption           SHOULD      MAY（利用されてないため）
D-H Group 1 (768)             MUST        MAY（暗号的に脆弱なため）
D-H Group 2 (1024)            SHOULD      MUST
D-H Group 14 (2048)           N/A         SHOULD
D-H elliptic curves           SHOULD      MAY（利用されてないため）

本書のすべてにおいてセキュリティについて記述している。本書の「アルゴリズムに関する新たな要求事項」の節で MUST レベルまたは SHOULD レベルとなっているすべてのアルゴリズムは、本書執筆時点において、堅牢で安全であると信じられている。

[RFC2119]	Bradner, S., 「RFC において要請の程度を示すために用いるキーワード (Key words for use in RFCs to Indicate Requirement Levels)」, BCP 14, RFC 2119, 1997年 3月.
[RFC2409]	Harkins, D. and D. Carrel, 「インターネット鍵交換 (IKE: The Internet Key Exchange)", RFC 2409, 1998年11月.
[RFC3526]	Kivinen, T. and M. Kojo, 「インターネット鍵交換プロトコル（IKE）のための追加 Modular Exponential (MODP) Diffie-Hellman グループ (More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE))」, RFC 3526, 2003年 5月.
[RFC3566]	Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, 2003年 9月.
[RFC3602]	Frankel, S., Glenn, R., and S. Kelly, 「AES-CBC 暗号アルゴリズムと IPsec でのその使用法 (The AES-CBC Cipher Algorithm and Its Use with IPsec)」, RFC 3602, 2003年 9月.
[RFC3664]	Hoffman, P., 「インターネット鍵交換プロトコル（IKE）のための AES-XCBC-PRF-128 アルゴリズム (The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE))」, RFC 3664, 2004年 1月.

　

Paul Hoffman
VPN Consortium
127 Segre Place
Santa Cruz, CA 95060
US

EMail： paul.hoffman＠vpnc.org

翻訳者のアドレス

東京都中央区新川1-21-2 茅場町タワー
株式会社 NTTデータ
技術開発本部
馬場 達也

EMail： babatt＠nttdata.co.jp

Copyright (C) The Internet Society (2005).

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

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

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

この文書に記述される技術の実装および使用に関係すると主張される、知的財産権およびその他の権利の有効性または範囲に関して、またこのような権利の下でのあらゆる権利が効力を持つ範囲に関して、IETF はいかなる立場もとらず、また、IETF はそのような権利を確認するためのいかなる取り組みを行ったことも表明しない。 RFC 文書における権利に関する手続きの情報は、BCP 78 および BCP 79 に記述されている。

IETF 事務局に提出された IPR 公開文書のコピーおよび利用可能となるライセンス保証のコピー、あるいは、この仕様の実装者やユーザによる所有権の使用に対する一般的な権利や許可を得るために行われた試みの結果は、IETF オンライン IPR リポジトリ（http://www.ietf.org/ipr）から入手可能である。

IETF は、どのような利害関係者に対しても、この標準を実装するために必要な技術をカバーする著作権や特許、特許出願、その他の所有権に対して注意を払うように依頼する。IETF（ietf-ipr@ietf.org）までその情報を送っていただきたい。

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