Internet Key Exchange
このトピックでは、IKEとIPsecとの相互作用について説明します。
IKEの紹介
Internet Key Exchange（IKE）は、2つのデバイス間のセキュアで認証された通信チャネルを設定するのに使われるセキュアなキーマネージメントプロトコルです。
IKEは以下を実行します。
-
IKEおよびIPsecパラメータのネゴシエートおよび管理
-
セキュアな鍵交換の認証
-
パスワードではなく、共有された秘密鍵と公開鍵による相互ピア認証の提供
-
ID保護の提供（メインモード）
-
Diffie-Hellman方式を採用しており、IPsecではオプションとなっています（共有鍵はエンドポイントで手動で入力できます）。
IKEバージョン
IKE標準には2つのバージョンがあります。
-
IKEバージョン1 - RFC 2409で定義されたIKEプロトコル。
-
IKEバージョン2 - IKEバージョン2（IKEv2）は、RFC 7296で定義されたIKEプロトコルの最新バージョンです。
Internet Key Exchangeバージョン2（IKEv2）は、RFC 7296で定義されたInternet Key Exchange（IKE）プロトコルの最新バージョンです。VPNピアは、IKEv1またはIKEv2のいずれかに構成されます。ピアがIKEv2として構成されている場合、リモートピアがIKEv1のネゴシエーションを開始しても、IKEv1にフォールバックすることはできません。
IKEv1と比べてIKEv2を使用する利点は以下の通りです。
-
8つの初期交換を単一の4メッセージ交換に置き換えます。
-
IPsecSA設定の遅延を短縮し、接続確立速度を向上させます。
-
DOS攻撃に対する堅牢性が向上します。
-
シーケンス番号、確認応答、エラー訂正を使って信頼性を向上させます。
-
すべてのメッセージがリクエストまたは応答であるため、信頼性が向上します。応答を受信しない場合、開始側には再送信する責任があります。
IKEとIPSec間のやり取り
IPsecは、以下のいずれかの方法でVPNを確立できます。
-
Internet Key Exchange（IKE）プロトコル — IPsecは、IKEプロトコルを使用して、鍵とセキュリティの関連付けの自動生成とネゴシエーションをサポートします。IKEを使用して2つのエンドポイント間のVPNをネゴシエートすると、手動での鍵交換よりも高いセキュリティが得られます。
-
手動での鍵の交換 — IPsecは、VPNを確立するために、双方が手動（例：電話や電子メールなど）で鍵を使用および交換することをサポートしています。
IKEv1メッセージ交換
IKEネゴシエーションには2つのフェーズがあります。
-
フェーズ1 — チャネルの認証とセキュリティ確保の方法に関する提案の交換をネゴシエートします。
-
フェーズ2 — IPsecトンネルを通過するデータをセキュリティ保護するために、セキュリティアソシエーション（SA）をネゴシエートします。
IKEトンネルネゴシエーションのフェーズ1
AutoKey IKE（インターネット鍵交換）トンネルネゴシエーションのフェーズ1は、チャネルの認証とセキュリティ確保の方法に関するプロポーザルの交換で構成されています。参加者は、以下のような許容可能なセキュリティ サービスのプロポーザルを交換します。
暗号化アルゴリズムーDES（データ暗号化規格）、3DES（トリプルデータ暗号化規格）、AES（次世代暗号化標準）。（「IPsec の概要」を参照してください。）
認証アルゴリズムーMD5（メッセージダイジェスト5）とSHA（セキュアハッシュアルゴリズム）。（「IPsec の概要」を参照してください。）
Diffie-Hellman（DH）グループ（「IPsec の概要」を参照してください。）
事前共有鍵または RSA/DSA 証明書（「IPsec の概要」を参照してください。）
フェーズ1のネゴシエーションが成功すると、トンネルの両端が提案されたフェーズ1セキュリティパラメーターの少なくとも1つのセットを受け入れ、それを処理することに同意した場合に終了します。ジュニパーネットワークスデバイスは、フェーズ1ネゴシエーションの最大4つのプロポーザルをサポートします。このため、受け入れる鍵ネゴシエーションのセキュリティパラメーターの範囲をどのように制限するかを定義できます。Junos OS は、定義済みの標準、互換、基本フェーズ 1 のプロポーザル セットを提供します。カスタムフェーズ1プロポーザルを定義することもできます。
フェーズ1の交換は、メインモードまたはアグレッシブモードのいずれかで実行できます。IKE ポリシーの設定中にモードを選択できます。
このトピックは、以下のセクションで構成されています。
メイン モード
メインモードでは、イニシエーターと受信者が3つの双方向交換（合計6つのメッセージ）を送信して、以下のサービスを実行します。
最初の交換（メッセージ1および2）—暗号化および認証アルゴリズムを提案して受け入れます。
2番目の交換（メッセージ3および4）—DH交換を実行し、イニシエーターと受信者がそれぞれ疑似乱数を提供します。
3番目の交換（メッセージ5および6）—イニシエーターと受信者のIDを送信および検証します。
3 番目のメッセージ交換で送信される情報は、最初の 2 つの交換で確立された暗号化アルゴリズムによって保護されます。したがって、参加者のIDは暗号化され、「クリアテキスト」では送信されません。
アグレッシブ モード
アグレッシブ モードでは、イニシエーターと受信者がメイン モードと同じ目的を達成しますが、2 つの交換だけで、合計 3 つのメッセージが送信されます。
最初のメッセージ—イニシエーターは、SA（セキュリティアソシエーション）を提案し、DH交換を開始し、疑似乱数とIKE IDを送信します。
フェーズ 1 ネゴシエーションで、複数のプロポーザルを使用してアグレッシブ モードを設定する場合は、DH グループはネゴシエートできないため、すべてのプロポーザルで同じ DH グループを使用します。最大 4 つのプロポーザルを設定できます。
2番目のメッセージ—受信者はSAを受け入れ、イニシエーターを認証し、疑似乱数、IKE IDを送信し、受信者の認定書（認定書を使用している場合）を送信します。
3番目のメッセージ—イニシーターは受信者を認証し、交換を確認した後、証明書を使用している場合は、イニシエーターの証明書を送信します。
参加者のIDは（最初の2つのメッセージでは）クリアテキストで交換されるため、アグレッシブモードではIDの保護は提供されません。
メイン モードおよびアグレッシブ モードは、IKEv1 プロトコルにのみ適用されます。IKEv2プロトコルは、メインモードおよびアグレッシブモードを使用してネゴシエートしません。
関連項目
IKEトンネルネゴシエーションのフェーズ 2
参加者は、セキュアで認証済みのチャネルを確立した後、フェーズ 2 に進み、IPsec トンネルを介して送信されるデータを保護するためにセキュリティアソシエーション (SA) をネゴシエートします。
フェーズ 1 のプロセスと同様、参加者は、SA で採用するセキュリティパラメーターを決定するプロポーザルを交換します。フェーズ2プロポーザルにも、カプセル化セキュリティペイロード（ESP）または認証ヘッダー（AH）のいずれかのセキュリティプロトコルと、一部の暗号化および認証アルゴリズムが含まれます。PFS（Perfect Forward Secrecy）が求められる場合には、プロポーザルで Diffie-hellman（DH）グループも指定できます。
フェーズ1で使用されるモードに関係なく、フェーズ2は常にクイックモードで動作し、3つのメッセージの交換が含まれます。
このトピックは、以下のセクションで構成されています。
プロキシ ID
フェーズ2では、ピアはプロキシIDを交換します。プロキシIDは、ローカルおよびリモートのIPアドレスプレフィックスで構成されています。両方のピアのプロキシー ID は一致しなければなりません。つまり、一方のピアに指定されたローカル IP アドレスは、他方のピアに指定されたリモート IP アドレスと同じでなければなりません。
Perfect Forward Secrecy
PFS は、先行する鍵から独立して、かつ先行するキーとは無関係にフェーズ 2 の鍵を導出する方法です。または、フェーズ 1 プロポーザルが、すべてのフェーズ 2 鍵が派生する鍵（SKEYID_d 鍵）を作成します。SKEYID_d 鍵は、最小限の CPU 処理でフェーズ 2 鍵を生成できます。残念ながら、許可されていない第三者がSKEYID_dキーへのアクセス権を得ると、すべての暗号化キーが危険にさらされることになります。
PFS は、各フェーズ 2 トントンネルに新しい DH鍵交換が発生するよう強制することにより、セキュリティリスクに対応します。このように PFS を使用するとセキュリティが強化されますが、PFS を有効にした状態だとフェーズ 2 での鍵更新手順かかる時間がわずかに長くなる可能性があります。
リプレイ防御
リプレイ攻撃は、許可されていない人物が一連のパケットを傍受し、これを使ってシステムを溢れさせ、DoS（サービス拒否）を引き起こしたり、信頼できるネットワークに侵入したりした場合に発生します。Junos OS では、デバイスがすべての IPsec パケットについて、以前に受信したことがあるかどうかをチェックできるようにするリプレイ防御機能を提供しています。パケットが指定されたシーケンス範囲外に到着すると、Junos OS はこれを拒否します。パケットは常にシーケンス番号を使用して送信されるため、この機能の使用においてネゴシエーションは不要です。シーケンス番号をチェックするか、しないかのみを選択できます。
関連項目
IKEv2メッセージ交換
IKEバージョン2は、IKEv1方式の後継です。これは、ピアVPNデバイス間のセキュアなVPN通信チャネルを提供し、IPsecセキュリティアソシエーション（SA）のネゴシエーションと認証を保護された方法で定義しますす。
IKEv2にはIKEv1のようなフェーズ1とフェーズ2はありませんが、IKEv2でIPsecトンネルをネゴシエートする際には4つのメッセージ交換が行われます。IKEv2のメッセージ交換は以下の通りです。
-
IPsecトンネルを確立するためのセキュリティ属性をネゴシエートします。これには、使用するプロトコル/パラメータの交換や、Diffie-Hellmanグループの交換が含まれます。
-
IPsecトンネルが確立されている間、各ピアは自らのIDを確立または認証します。
-
ピア同士で追加のセキュリティアソシエーションを作成します。
-
ピアは、ライブ性の検出、SAリレーションシップの削除、エラーメッセージのレポートを実行します。
IKEv2構成ペイロード
構成ペイロードは、応答側から開始側へのプロビジョニング情報の伝送用に提供されるIKEv2オプションです。IKEv2構成ペイロードは、ルートベースVPNでのみサポートされます。
RFC5996、Internet Key Exchangeプロトコルバージョン2（IKEv2）では、応答側が開始側に返すことのできる15種類の構成属性が定義されています。
IKEv2鍵更新と再認証
IKEv2では、鍵更新と再認証は別個のプロセスです。
鍵更新により、IKEセキュリティアソシエーション（SA）用の新たな鍵が確立され、メッセージIDカウンターがリセットされますが、ピアの再認証は行われません。
再認証は、VPNピアが認証資格へのアクセスを保持していることを確認します。再認証は、IKESAおよび子SA用に新たな鍵を確立し、保留中のIKESAまたは子SAの鍵更新は必要なくなります。新しいIKEと子SAが作成された後、古いIKEと子SAが削除されます。
IKEv2の再認証は、デフォルトでは無効になっています。再認証を有効にするには、再認証の頻度を1～100の値に構成します。再認証の頻度とは、再認証が行われるまでに発生するIKE鍵更新の回数のことです。例えば、再認証の頻度を1として構成した場合、IKEの鍵更新のたびに再認証が行われます。再認証の頻度を2として構成した場合、IKE鍵更新2回につき再認証が1回行われます。再認証の頻度を3として構成すると、IKE鍵更新3回ごとに再認証が行われる、という具合です。
IKEv2フラグメント化
認定書ベースの認証を使用する場合、複数の認定書を送信するとIKEv2パケットがパスMTUを超えることがあります。IKEメッセージのサイズがパスMTUを超える場合、メッセージはIPレベルでフラグメント化されます。NATデバイスなどの一部のネットワーク機器は、IPフラグメントの通過を許可しないため、IPsecトンネルの確立ができません。
RFC7383「Internet Key Exchangeプロトコルバージョン2（IKEv2）メッセージフラグメント化」で説明されているように、IKEv2メッセージフラグメント化により、IPフラグメントがブロックされ、ピアがIPsecセキュリティアソシエーション（SA）を確立できないような環境でもIKEv2を動作させることができます。IKEv2フラグメント化は、大きなIKEv2メッセージを小さなメッセージに分割して、IPレベルでフラグメント化が発生しないようにします。フラグメント化は、元のメッセージが暗号化および認証される前に行われるため、各フラグメントは別個に暗号化および認証されます。受信側でフラグメントの収集、検証、復号化、統合が実行されて元のメッセージになります。
IKEv2のトラフィックセレクター
IKEv2では、IKEネゴシエーション時に使用するトラフィックセレクターを構成できます。トラフィックセレクターとは、トラフィックが指定されたローカルアドレスとリモートアドレスのペアに一致する場合に、VPNトンネルを介したトラフィックを許可するというIKEピア間の合意です。トラフィックセレクターに適合したトラフィックのみが、関連するセキュリティアソシエーション（SA）を通じて許可されます。トラフィックセレクターは、トンネルの作成時に、トンネルを設定し、トンネルの通過を許可するトラフィックを決定するのに使用されます。
プロキシーID
プロキシーIDは、Internet Key Exchange（IKE）仮想プライベートネットワーク（VPN）ネゴシエーションのフェーズ2で使用されます。VPNトンネルの両端では、プロキシーIDが手動で構成されているか（ルートベースVPN）、トンネルポリシーで送信元IP、宛先IP、サービスの組み合わせが単に使用されます。IKEのフェーズ2がネゴシエートされると、構成されたローカルおよびリモートのプロキシーIDと実際に受信したものが各端で比較されます。
トラフィックセレクター
プロキシーIDは、ルートベースとポリシーベースの両方のVPNでサポートされます。ただし、マルチプロキシーIDはルートベースVPNのみでサポートされます。マルチプロキシーIDは、トラフィックセレクターとも呼ばれます。トラフィックセレクターとは、トラフィックが指定されたローカルアドレスとリモートアドレスのペアに一致する場合に、トンネルを介したトラフィックを許可するというIKEピア間の合意です。特定のルートベースVPN内でトラフィックセレクターを定義すると、複数のフェーズ2IPsecSAが生成されることがあります。トラフィックセレクターに適合したトラフィックのみがSAを介して許可されます。トラフィックセレクターは、リモートゲートウェイデバイスがジュニパーネットワークス以外のデバイスである場合によく必要とされます。
ネットワークアドレス変換トラバーサル（NAT-T）
ネットワークアドレス変換トラバーサル（NAT-T）とは、IPsecで保護されたデータがアドレス変換のためにNATデバイスを通過する際に発生するIPアドレス変換の問題を回避するための手法です。
NATの機能であるIPアドレッシングの変更があった場合、IKEはパケットを破棄します。NAT-Tは、フェーズ1交換時にデータパスに沿って1つ以上のNATデバイスを検出した後、IPsecパケットにユーザーデータグラムプロトコル（UDP）カプセル化のレイヤーを追加し、アドレス変換後のパケットが廃棄されないようにします。NAT-Tは、IKEとESPの両方のトラフィックをUDP内でカプセル化し、ポート4500を送信元と宛先の両方のポートとして使用します。NATデバイスは古くなったUDP変換を期限切れにするため、ピア間でキープアライブメッセージが必要になります。
NATデバイスの位置は、以下のようにできます。
-
IKEv1またはIKEv2開始側のみがNATデバイスの背後にあります。複数の開始側を別個のNATデバイスの背後に置くことができます。開始側は、複数のNATデバイスを介して応答側に接続することもできます。
-
IKEv1またはIKEv2応答側のみがNATデバイスの背後にあります。
-
IKEv1またはIKEv2開始側と応答側の両方がNATデバイスの後ろにあります。
スイートBとPRIME暗号スイート
スイートBとは、米国国家安全保障局（NSA）が指定した暗号アルゴリズムのセットで、商用製品でも機密や極秘に分類されたトラフィックを保護することが可能です。スイートBプロトコルは、「RFC6379、IPsec向けのスイートB暗号スイート」で定義されています。スイートB暗号スイートは、カプセル化セキュリティペイロード（ESP）の完全性と機密性を提供するもので、ESPの完全性保護と暗号化の両方が必要な場合に使用されます。英国の公共部門向けに定義されたIPsecプロファイルであるIPモジュラー暗号化向けのプロトコル要件（PRIME）は、スイートB暗号スイートをベースにしていますが、IKEv2ネゴシエーションにはAES-CBCではなくAES-GCMを使用します。
以下の暗号スイートに対応しています。
-
Suite-B-GCM-128
-
ESP：ガロアカウンターモード（GCM）での128ビット鍵および16オクテット完全性チェック値（ICV）による高度暗号化標準（AES）暗号化
-
IKE：暗号ブロック連鎖（CBC）モードでの128ビット鍵によるAES暗号化、SHA-256認証を使用した完全性、Diffie-Hellman（DH）グループ19を使用した鍵確立、楕円曲線デジタル署名アルゴリズム（ECDSA）256ビット楕円曲線署名を使用した認証。
-
-
Suite-B-GCM-256
-
ESP：GCMにおけるESP向けの256ビット鍵および16オクテットICVを使用したAES暗号化。
-
IKE：CBCモードでの256ビット鍵によるAES暗号化、SHA-384認証を使用した完全性、DHグループ20を使用した鍵確立、ECDSA384ビット楕円曲線署名を使用した認証。
-
-
PRIME-128
-
ESP：GCMでの128ビット鍵と16オクテットICVによるAES暗号化。
-
IKE：GCMでの128ビット鍵によるAES暗号化、DHグループ19を使用した鍵確立、ECDSA256ビット楕円曲線署名を使用した認証。
-
-
PRIME-256
-
ESP：GCMにおけるESP向けの256ビット鍵および16オクテットICVを使用したAES暗号化。
-
IKE：GCMでの256ビット鍵によるAES暗号化、DHグループ20を使用した鍵確立、ECDSA384ビット楕円曲線署名を使用した認証。
-
Suite-B暗号スイートはIKEv1およびIKEv2に対応しています。PRIME暗号スイートはIKEv2のみに対応しています。