ネットワークワーキンググループ
Request for Comments: 4109
更新: 2409
分類: スタンダードトラック
P. Hoffman
VPN Consortium
2005年5月

インターネット鍵交換プロトコルバージョン 1(IKEv1)用のアルゴリズム
(Algorithms for Internet Key Exchange version 1 (IKEv1))

このメモの位置付け 
この文書は、インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを定義するとともに、それを改良するための議論や提言を求めるものである。
このプロトコルの標準化状態およびステータスについては、「Internet Official Protocol Standards」(STD 1) の最新版を参照すること。
このメモの配布に制限はない。
著作権表示
Copyright (C) The Internet Society (2005).
要旨 
オリジナルの IKEv1(Internet Key Exchange version 1)の仕様で要求され、提案されたアルゴリズムは、現在の IPsec 市場の要求の現実を反映していない。
オリジナルの仕様は、弱いセキュリティを許容し、弱く実装されたアルゴリズムを提案している。
本文書は、オリジナルの仕様書である RFC 2409 を更新するものであり、今日利用されているすべての IKEv1 実装を対象としている。
1. はじめに 
オリジナルの IKEv1 の定義 [RFC2409] では、IPsec ユーザのニーズにマッチしない MUST レベルおよび SHOULD レベルの要求事項のセットについて記述している。
本文書は、そこで定義されているアルゴリズムに関する要求事項を変更することにより、RFC 2409 を更新するものである。

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

2. アルゴリズムに関する古い要求事項 
RFC 2409 には、次の MUST レベルおよび SHOULD レベルの要求事項が記載されている。
RFC 2409 には、楕円暗号を使用した Diffie-Hellman MODP グループに対する 2 つの矛盾する要求レベルが記述されている。
その仕様の 4 章では、「IKE 実装は、...(中略)... ECP および EC2N グループをサポートしても良い (MAY)」と記述されているが、6.3 節では、EC2N グループに関する MODP グループ 3 および 4 をサポートする必要がある (SHOULD) と記述されている。
3. アルゴリズムに関する新たな要求事項 
ここでは、IKEv1 に対する新たな要求事項をリストアップする。
いくつかの要求事項は、RFC 2409 と同じであるが、その他は変更されていることに注意すること。
将来、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 は、あまり利用されていないことや、相互接続性が欠如していることから落とされた。

4. まとめ 
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(利用されてないため)
5. セキュリティに関する考慮事項 
本文書のすべてにおいてセキュリティについて記述している。
本文書の「アルゴリズムに関する新たな要求事項」の節で MUST レベルまたは SHOULD レベルとなっているすべてのアルゴリズムは、本文書執筆時点において、堅牢で安全であると信じられている。
6. 基準としている参考文献 
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

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

[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.

[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.

[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.

[RFC3664] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 3664, January 2004.

著者の連絡先 
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 エディタの機能に対する資金は、インターネットソサエティによって提供されている。