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

このメモの位置づけ

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

著作権表記

要旨

オリジナルのIKEv1(Internet Key Exchange version 1)の仕様で要求され、提案されたアルゴリズムは、現在のIPsec市場の要求の現実を反映していない。オリジナルの仕様は、弱いセキュリティを許容し、弱く実装されたアルゴリズムを提案している。本書は、オリジナルの仕様書であるRFC2409 を更新するものであり、今日、利用されているすべての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レベルの要求事項が記載されている。

暗号化用に、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)と記述されている。

3. アルゴリズムに関する新たな要求事項 English

ここでは、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は、あまり利用されていないことや、相互接続性が欠如していることから落とされた。

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

著作権表示全文

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

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