Loading article…
コンピューティングにおいて、インターネット鍵交換( IKE 、 IKEv1およびIKEv2としてバージョン化) は、 IPsecプロトコル スイートでセキュリティ アソシエーション(SA)を設定するために使用されるプロトコルです。IKE は、 Oakley プロトコルとISAKMPを基盤としています。[1] IKE は、認証にX.509証明書 (事前共有またはDNS ( DNSSECを推奨) を使用して配布) を使用し、Diffie-Hellman 鍵交換を使用して、暗号鍵が導出される共有セッション シークレットを設定します。[2] [3]さらに、接続するすべてのピアのセキュリティ ポリシーを手動で管理する必要があります。[2]
歴史
インターネット技術タスクフォース(IETF) は、1998 年 11 月に、 RFC 2407、RFC 2408、RFC 2409 として知られる 一連の出版物 ( Request for Comments ) で IKE を最初に定義しました。
- RFC 2407はISAKMPのインターネットIPセキュリティ解釈ドメインを定義しました。[4]
- RFC 2408はインターネットセキュリティアソシエーションおよびキー管理プロトコル（ISAKMP）を定義しました。[5]
- RFC 2409はインターネット鍵交換（IKE）を定義した。[6]
RFC 4306 は、2005 年 12 月に IKE をバージョン 2 (IKEv2) に更新しました。[7] RFC 4718 は、2006 年 10 月にいくつかの未解決の詳細を明確化しました。[8] RFC 5996 は、これら 2 つのドキュメントと追加の明確化を組み合わせて、更新された IKEv2 [9]を作成し、 2010 年 9 月に公開しました。その後の更新で、ドキュメントは Proposed Standard からInternet Standardにアップグレードされ、2014 年 10 月にRFC 7296 として公開されました。
IETF の親組織であるインターネット協会(ISOC) は、これらの標準の著作権をインターネット コミュニティが自由に利用できるように維持しています。
建築
ほとんどの IPsec 実装は、ユーザー空間で実行されるIKEデーモンと、実際のIPパケットを処理するカーネル内の IPsec スタックで構成されます。
ユーザー空間デーモンは、必要に応じて、IPsec エンドポイント アドレス、キー、証明書などの構成情報を含む大容量ストレージに簡単にアクセスできます。一方、カーネル モジュールは、最小限のオーバーヘッドで効率的にパケットを処理できます。これは、パフォーマンス上の理由から重要です。
IKE プロトコルは、通常ポート 500 でUDPパケットを使用し、両側でISAKMP セキュリティ アソシエーション(SA) を作成するために、通常 4 ～ 6 パケットと 2 ～ 3 回の往復を必要とします。ネゴシエートされたキー マテリアルは、次に IPsec スタックに渡されます。たとえば、これはAESキー、保護する IP エンドポイントとポートを識別する情報、および作成された IPsec トンネルの種類になります。次に、IPsec スタックは、適切な場合に適切な場所で関連する IP パケットを傍受し、必要に応じて暗号化/復号化を実行します。実装によって、パケットの傍受方法が異なるため、たとえば、仮想デバイスを使用するものや、ファイアウォールの一部を使用するものなどがあります。
IKEv1はフェーズ1とフェーズ2の2つのフェーズで構成されています。[10]
IKEv1 フェーズ
IKE フェーズ 1 の目的は、 Diffie-Hellman 鍵交換アルゴリズムを使用して共有秘密鍵を生成し、その後の IKE 通信を暗号化することで、安全な認証済み通信チャネルを確立することです。このネゴシエーションの結果、単一の双方向 ISAKMP セキュリティ アソシエーションが確立されます。[11]認証は、事前共有鍵(共有秘密)、署名、または公開鍵暗号化を使用して実行できます。[12]フェーズ 1 は、メイン モードまたはアグレッシブ モードのいずれかで動作します。メイン モードでは、ピアの ID と共有鍵のハッシュを暗号化して保護しますが、アグレッシブ モードでは保護しません。[10]
IKEフェーズ2では、IKEピアはフェーズ1で確立された安全なチャネルを使用して、IPsecなどの他のサービスに代わってセキュリティアソシエーションをネゴシエートします。ネゴシエーションの結果、少なくとも2つの単方向セキュリティアソシエーション（1つは着信、もう1つは発信）が生成されます。[13]フェーズ2はクイックモードでのみ動作します。[10]
IKE の問題
元々、IKE には多数の設定オプションがありましたが、広く実装されている既知のデフォルト ケースの自動ネゴシエーションを行うための一般的な機能がありませんでした。その結果、IKE の両側で、作成するセキュリティ アソシエーションのタイプについてオプションごとに正確に合意する必要がありました。そうしないと、接続を確立できませんでした。多くの実装では、診断出力を生成する機能があったとしても、デバッグ出力の解釈が困難であったため、さらに複雑な状況になりました。
IKE 仕様は、設計上の欠陥に迫るほどの解釈の余地があり ( Dead Peer Detectionがその一例[引用が必要] )、両端で正しく構成されているように見えても、さまざまな IKE 実装で、多くのオプションの組み合わせに対して合意されたセキュリティ アソシエーションをまったく作成できないという事態を引き起こしました。
IKEv2 による改善
IKEv2 プロトコルは、2005 年に RFC 4306 の付録 A で説明されました。次の問題が解決されました。
- RFC ( Requests for Comments ) の減少: IKE の仕様は少なくとも 3 つの RFC でカバーされていましたが、NAT トラバーサルや一般的に使用されているその他の拡張機能を考慮すると、さらに多くなります。IKEv2 では、これらを 1 つの RFC にまとめ、NAT トラバーサル(ネットワーク アドレス変換(NAT)) とファイアウォールトラバーサル全般のサポートを改善しています。
- 標準モビリティ サポート: IKEv2 には、[rfc:4555 モビリティおよびマルチホーミング プロトコル] (MOBIKE) ( IPsecも参照) という標準拡張機能があり、IKEv2のモビリティとマルチホーミング、およびカプセル化セキュリティ ペイロード(ESP)をサポートするために使用されます。この拡張機能を使用することで、IKEv2 とIPsec をモバイル ユーザーとマルチホーミング ユーザーが使用できるようになります。
- NATトラバーサル：IKEとESPをユーザーデータグラムプロトコル（UDPポート4500）にカプセル化することで、これらのプロトコルはNATを実行するデバイスやファイアウォールを通過できるようになります。[14]
- ストリーム制御伝送プロトコル(SCTP) のサポート: IKEv2 では、インターネット テレフォニー プロトコルであるVoice over IP (VoIP)で使用されるSCTPプロトコルが許可されます。
- シンプルなメッセージ交換: IKEv2 には 4 つのメッセージの初期交換メカニズムが 1 つありますが、IKE は 8 つの明確に異なる初期交換メカニズムを提供し、それぞれにわずかな長所と短所がありました。
- 暗号化メカニズムの削減: IKEv2 は、IPsec ESP が IPsec パケットを保護するために使用するものと非常によく似た暗号化メカニズムを使用してパケットを保護します。これにより、各暗号化実装を個別に検証する必要があるCommon CriteriaおよびFIPS 140-2 (連邦情報処理標準(FIPS)) の実装と認定が簡素化されました。
- 信頼性と状態管理: IKEv2 は、信頼性を提供するためにシーケンス番号と確認応答を使用し、エラー処理ロジスティクスと共有状態管理を義務付けています。このような信頼性対策が欠如しているため、IKE はデッド状態になる可能性があり、その場合、双方が相手がアクションを開始することを期待していましたが、実際には何も起こりませんでした。回避策 ( Dead-Peer-Detectionなど) は開発されましたが、標準化されていませんでした。つまり、回避策の異なる実装は必ずしも互換性があるわけではありませんでした。
- サービス拒否 (DoS) 攻撃に対する耐性: IKEv2 は、要求者が実際に存在するかどうかを判断するまで、多くの処理を実行しません。これにより、偽装された場所から多くのコストのかかる暗号化処理を実行する IKE が抱えていた DoS 問題の一部が解決されました。
- HostA のセキュリティ パラメータ インデックス(SPI)が で
A、HostB のSPIがであるとするBと、シナリオは次のようになります。
ホストA ------------------------------------------------- - ホストB
|HDR(A,0),sai1,kei,Ni-------------------------------------> |
| <----------------------------HDR(A,0),N(クッキー)|
|HDR(A,0),N(cookie),sai1,kei,Ni----------------> |
| <--------------------------HDR(A,B),SAr1,ker,Nr|
- HostB (レスポンダ) が半オープン IKE 接続を大量に経験している場合、HostB は の暗号化されていない応答メッセージを の通知メッセージとともにHostA (イニシエーター)
IKE_SA_INITに送信し、HostA がその Cookie 値を通知ペイロードに含む要求をHostBに送信することを期待します。これは、イニシエーターがレスポンダからの IKE 応答を実際に処理できることを確認するためです。COOKIEIKE_SA_INIT
プロトコル拡張
IETF ipsecme ワーキング グループは、IKEv2 プロトコルを最新化し、大量の実稼働環境により適切に適応させることを目標として、いくつかの拡張機能を標準化しました。これらの拡張機能には次のものが含まれます。
- IKE セッション再開: IKE セットアップ プロセス全体を実行する必要なく、失敗した IKE/IPsec「セッション」を失敗後に再開する機能 ( RFC 5723)。
- IKE リダイレクト: 着信 IKE 要求をリダイレクトし、複数の IKE エンドポイント間での単純な負荷分散を可能にします ( RFC 5685)。
- IPsec トラフィックの可視性: 認証されているが暗号化されていない ESP パケットに特別なタグを付け、ミドルボックス (侵入検知システムなど) がフローを分析しやすくすることを目的としています ( RFC 5840)。
- 相互 EAP 認証:両方の IKE ピアのEAPのみ (つまり、証明書なし) の認証をサポートします。目標は、最新のパスワードベースの認証方法を使用できるようにすることです ( RFC 5998)。
- 迅速なクラッシュ検出: IKE ピアが反対側のピアがクラッシュしたことを検出するまでの時間を最小限に抑えます ( RFC 6290)。
- 高可用性拡張機能: IPsec エンドポイントのクラスターとピア間の IKE/IPsec レベルのプロトコル同期を改善し、フェイルオーバー イベント後に接続が切断される可能性を低減します ( RFC 6311)。
実装
IKEは、Windows 2000、Windows XP、Windows Server 2003、Windows Vista、Windows Server 2008のIPsec実装の一部としてサポートされています。[15] ISAKMP/IKEの実装は、CiscoとMicrosoftによって共同開発されました。[16]
Microsoft Windows 7およびWindows Server 2008 R2 は、VPN 再接続機能 ( Agile VPNとも呼ばれます) を通じて、IKEv2 ( RFC 7296) と MOBIKE ( RFC 4555)を部分的にサポートしています。
IKE 機能に関連する IPsec のオープン ソース実装がいくつかあります。Linux では、Libreswan、Openswan、strongSwan実装によって、KLIPS または XFRM/NETKEY カーネル ベースの IPsec スタックを構成 (つまり、SAを確立) できる IKE デーモンが提供されます。XFRM/NETKEY は、バージョン 2.6 以降で利用可能な Linuxネイティブ IPsec 実装です。
Berkeley Software Distributions は、OpenBSD Cryptographic Framework (OCF)を介して IPsec や IKE デーモンも実装しており、これにより暗号化アクセラレータのサポートがはるかに容易になります。OCF は最近 Linux に移植されました。
多くのネットワーク機器ベンダーが独自の IKE デーモン (および IPsec 実装) を作成したり、相互にスタックのライセンスを取得したりしています。
IKEv2 の実装は数多くあり、IPsec 認証と相互運用性テストを扱う企業の中には、IKEv2 テストに対応するためにテストや更新された認証要件に関するワークショップを開催し始めているところもあります。
IKEv2 の次のオープン ソース実装が利用可能です。
脆弱性
2014年にデア・シュピーゲルによって公開されたNSAのプレゼンテーションによると、IKEは未知の方法でIPsecトラフィックを解読するために利用されており、ISAKMPも同様である。[19] Logjam攻撃を発見した研究者は、1024ビットのDiffie-Hellmanグループを破ると、VPNサーバーの66％、上位100万のHTTPSドメインの18％、SSHサーバーの26％が破られると述べており、研究者はこれが漏洩と一致していると主張している。[20]この主張は、2015年にEyal RonenとAdi Shamirの論文「不完全な前方秘匿性の批判的レビュー」[21]とLibreswanのPaul Woutersの2015年の記事「VPNの66％[ sic ]は実際には破られていない」[22]で反論されている。
複数の設定のネゴシエーションを可能にするIPsec VPN設定は、IKEv1とIKEv2の両方で、提供された設定間のMITMベースのダウングレード攻撃の対象となります。 [23] これは、より厳格な設定でクライアントシステムを複数のサービスアクセスポイントに慎重に分離することで回避できます。
IKE標準のどちらのバージョンも、低エントロピーパスワードが使用されている場合、オフライン辞書攻撃の影響を受けやすい。IKEv1の場合、メインモードとアグレッシブモードでこれが当てはまる。[24] [25] [26]
参照
参考文献
- ^ インターネット鍵交換 (IKE)、RFC 2409、§1 概要
- ^ ab Thomas, M. (2001 年 6 月)、RFC 3129: Kerberos 化されたインターネットの鍵ネゴシエーションの要件、インターネット エンジニアリング タスク フォース、p. 1、doi : 10.17487/RFC3129
- ^ Richardson, M.; Redelmeier, DH (2001 年 6 月)、RFC 4322: インターネット鍵交換 (IKE) を使用した日和見暗号化、インターネット技術タスク フォース、p. 5、doi :10.17487/RFC4322
- ^ ISAKMP のインターネット IP セキュリティ解釈ドメイン。doi : 10.17487 / RFC2407。RFC 2407 。
- ^インターネットセキュリティアソシエーションおよびキー 管理プロトコル (ISAKMP)。doi : 10.17487/ RFC2408。RFC 2408 。
- ^ D. Harkins. インターネット鍵交換 (IKE). doi : 10.17487/RFC2409 . RFC 2409.
- ^ C. Kaufman ( Microsoft) (2005 年 12 月)。インターネット キー交換 (IKEv2) プロトコル。doi : 10.17487/ RFC4306。RFC 4306 。
- ^ Eronen , P.; Hoffman, P. (2006 年 10 月). IKEv2 の説明と実装ガイドライン。doi : 10.17487/ RFC4718。RFC 4718 。
- ^ Kaufman, C.; Hoffman, P.; Nir, Y.; Eronen, P. (2010 年 9 月). インターネット キー交換 (IKEv2) プロトコル. doi : 10.17487/RFC5996 . RFC 5996.
- ^ abc 「RFC 2409 インターネット鍵交換 (IKE)」、インターネット技術タスクフォース (IETF)、p. 5
- ^ 「RFC 2409 インターネット鍵交換 (IKE)」、インターネット技術特別調査委員会 (IETF)、6 ページ
- ^ 「RFC 2409 インターネット鍵交換 (IKE)」、インターネット技術タスクフォース (IETF)、p. 10-16
- ^ 「RFC 4306 インターネット鍵交換 (IKEv2) プロトコル」、インターネット技術特別調査委員会 (IETF)、p. 11,33
- ^ 「RFC 4306: インターネット鍵交換 (IKEv2) プロトコル」、インターネット技術特別調査委員会 (IETF)、p 38-40
- ^ インターネット鍵交換: インターネット プロトコル セキュリティ (IPsec): Technet
- ^ 「Windows 2000 および XP での IPSec の使用、パート 1」。2008 年 10 月 12 日時点のオリジナルよりアーカイブ。2009 年 12 月 24 日閲覧。
- ^ “OpenIKEv2”. GitHub . 2023年6月21日閲覧。
- ^ 「iked(8) - OpenBSDマニュアルページ」。man.openbsd.org 。2023年6月21日閲覧。
- ^ フィールド機能: エンドツーエンド VPN SPIN9 設計レビュー(PDF)、NSA 経由 'Der Spiegel'、p. 5
- ^ Adrian, David; Bhargavan, Karthikeyan; Durumeric, Zakir; Gaudry, Pierrick; Green, Matthew; Halderman, J. Alex; Heninger, Nadia ; Springall, Drew; Thomé, Emmanuel; Valenta, Luke; VanderSloot, Benjamin; Wustrow, Eric; Zanella-Béguelin, Santiago; Zimmermann, Paul (2015 年 10 月)。Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice (PDF)。22nd ACM Conference on Computer and Communications Security (CCS '15)。デンバー。2016 年6 月 15 日閲覧。
- ^ Ronen, Eyal; Shamir, Adi (2015 年 10 月)。「Imperfect Forward Secrecy の批評的レビュー」(PDF)。
- ^ Wouters, Paul (2015 年 10 月)。「VPN の 66% は実際には破られていない」。
- ^ バーガヴァン、カーティケヤン;ブルズスカ、クリスティーナ。フルネ、セドリック。コールワイス、マルクルフ。ザネラ・ベグリン、サンティアゴ。マシュー、グリーン（2016年1月）。 「キー交換プロトコルのダウングレード復元力」(PDF)。
- ^ Pliam, John (1999年10月2日). 「脆弱な事前共有秘密によるIKEおよびXauthの認証脆弱性」ジョンズホプキンス大学。2002年6月10日時点のオリジナルよりアーカイブ。 2020年2月5日閲覧。
- ^ McGrew, David (2011 年 7 月 5 日). 「素晴らしい暗号ですが、その鍵はどこで入手したのですか?」. Cisco Blog . 2011 年 7 月 9 日時点のオリジナルよりアーカイブ。2020 年2 月 11 日閲覧。
- ^ フェルシュ、デニス（2018年8月）。キー再利用の危険性：IPsec IKEに対する実践的な攻撃。ISBN 9781939133045. 2020年2月11日閲覧。
{{cite book}}:|website=無視されました (ヘルプ)
外部リンク
- RFC 2407 インターネット セキュリティ アソシエーションおよびキー管理プロトコル (ISAKMP)、インターネット エンジニアリング タスク フォース (IETF)
- RFC 2409 インターネット鍵交換 (IKE)、インターネット技術特別調査委員会 (IETF)
- RFC 7296: インターネット鍵交換プロトコル バージョン 2 (IKEv2)、インターネット技術タスクフォース (IETF)
- IKE の概要 (Cisco より)