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

English

IKEv1 用アルゴリズム
(Algorithms for Internet Key Exchange version 1 (IKEv1))

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

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

2. アルゴリズムに関する古い要求事項 English
RFC 2409 には、次の MUST レベルおよび SHOULD レベルの要求事項が記載されている。
RFC 2409 には、楕円暗号を使用した Diffie-Hellman MODP グループに対する 2 つの矛盾する要求レベルが記述されている。その仕様の 4 章では、「IKE 実装は、...(中略)... ECP および EC2N グループをサポートしても良い (MAY)」と記述されているが、6.3 節では、EC2N グループに関する MODP グループ 3 および 4 をサポートする必要がある (SHOULD) と記述されている。
3. アルゴリズムに関する新たな要求事項 English
ここでは、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. まとめ English

 

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. セキュリティに関する考慮事項 English
本書のすべてにおいてセキュリティについて記述している。本書の「アルゴリズムに関する新たな要求事項」の節で MUST レベルまたは SHOULD レベルとなっているすべてのアルゴリズムは、本書執筆時点において、堅牢で安全であると信じられている。
6. 規範的参考文献 
[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 エディタの機能に対する資金は、インターネットソサエティによって提供されている。