Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
このページの内容
 

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メッセージ交換に置き換えます。

  • IPsec SA設定の遅延を短縮し、接続確立速度を向上させます。

  • DOS攻撃に対する堅牢性が向上します。

  • シーケンス番号、確認応答、エラー訂正を使用して信頼性を向上させます。

  • すべてのメッセージがリクエストまたは応答であるため、信頼性が向上します。応答を受信しない場合、開始側には再送信する責任があります。

IKE と IPSec 間の相互作用

IPsecは、以下のいずれかの方法でVPNを確立できます。

  • Internet Key Exchange(IKE)プロトコル — IPsecは、IKEプロトコルを使用した鍵とセキュリティアソシエーションの自動生成とネゴシエーションをサポートします。IKE を使用して 2 つのエンドポイント間の VPN をネゴシエートすると、手動での鍵交換よりも高いセキュリティが得られます。

  • 手動での鍵の交換—IPsecは、VPNを確立するための双方での手動(電話や電子メールなど)の使用と交換をサポートします。

IKEv1メッセージ交換

IKEネゴシエーションには、次の2つのフェーズがあります。

  • フェーズ1 — チャネルの認証とセキュリティ確保の方法に関する提案の交換をネゴシエートします。

  • フェーズ2 — セキュリティアソシエーション(SA)をネゴシエートして、IPsecトンネルを通過するデータを保護します。

IKEトンネルネゴシエーションのフェーズ1

AutoKey Internet Key Exchange(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アドレスと同じでなければなりません。

完全転送機密保持

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でのみサポートされます。

RFC 5996、 Internet Key Exchange Protocol Version 2(IKEv2)では、応答側が開始側に返すことのできる15種類の構成属性が定義されています。

IKEv2鍵更新と再認証

IKEv2では、鍵更新と再認証は別個のプロセスです。

鍵更新により、IKEセキュリティアソシエーション(SA)用の新しい鍵が確立され、メッセージIDカウンターがリセットされますが、ピアの再認証は行われません。

再認証は、VPNピアが認証資格情報へのアクセスを保持していることを確認します。再認証により、IKE SA と子 SA 用の新しい鍵が確立されます。保留中の IKE SA または子 SA の鍵更新は不要になりました。新しい IKE と子 SA が作成された後、古い IKE と子 SA が削除されます。

IKEv2の再認証は、デフォルトでは無効になっています。再認証を有効にするには、再認証の頻度値を1から100の間で設定します。再認証の頻度とは、再認証が行われるまでに発生する IKE 鍵更新の回数のことです。例えば、再認証の頻度を1として構成した場合、IKE鍵更新のたびに再認証が行われます。再認証の頻度を2として構成した場合、IKE鍵更新2回につき再認証が行われます。再認証の頻度を3として構成すると、IKE鍵更新3回ごとに再認証が行われる、という具合です。

IKEv2フラグメント化

証明書ベースの認証を使用する場合、複数の証明書を送信するとIKEv2パケットがパスMTUを超えることがあります。IKEメッセージのサイズがパスMTUを超える場合、メッセージはIPレベルでフラグメント化されます。NATデバイスなどの一部のネットワーク機器は、IPフラグメントの通過を許可しないため、IPsecトンネルの確立ができません。

RFC 7383 Internet Key Exchange「プロトコルバージョン2(IKEv2)メッセージフラグメント化」で説明されているように、IKEv2メッセージフラグメント化により、IPフラグメントがブロックされ、ピアがIPsecセキュリティアソシエーション(SA)を確立できないような環境でもIKEv2を動作させることができます。IKEv2フラグメント化は、大きなIKEv2メッセージを小さなメッセージのセットに分割し、IPレベルでフラグメント化が発生しないようにします。フラグメント化は、元のメッセージが暗号化および認証される前に行われるため、各フラグメントは個別に暗号化および認証されます。受信側でフラグメントが収集、検証、復号化され、元のメッセージにマージされます。

IKEv2のトラフィックセレクター

IKEv2では、IKEネゴシエーション時に使用する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を介して許可されます。トラフィックセレクターは、リモートゲートウェイデバイスがジュニパーネットワークス以外のデバイスである場合によく必要とされます。

IKE認証(事前共有鍵と証明書ベースの認証)

IKEネゴシエーションは、2つの当事者が通信できるセキュアなチャネルを確立する機能を提供します。事前共有鍵認証または証明書ベースの認証を使用して、2つの当事者が互いを認証する方法を定義できます。

事前共有鍵認証

証明書ベースの認証

VPN接続を確立する一般的な方法。

VPN接続を確立するセキュアな方法。

  • 事前共有鍵とは、両当事者にとって同じパスワードのことです。このパスワードは、事前に電話や口頭でのやりとり、あるいは電子メールなどのセキュリティの低い仕組みを使って交換されます。

  • 事前共有鍵は、少なくとも8文字(12文字以上を推奨)で構成され、文字、数字、非英数字を組み合わせて使用し、文字の大文字と小文字を区別する必要があります。

  • 事前共有鍵には、辞書にある単語を使用してはなりません。

証明書は公開鍵と秘密鍵で構成されており、認証機関(CA)と呼ばれる一次証明書によって署名することができます

当事者は、Diffie-Hellman交換で得られたピアの公開鍵で事前共有鍵を暗号化することで、互いを認証します。

当事者は証明書をチェックして、信頼できる CA によって署名されているかどうかを確認します。

事前共有キーは、単一の組織内または異なる組織間でサイト間IPsec VPNに導入されるのが一般的です。

また、証明書は、全員が事前共有キーを共有するわけではない多数のピアサイトがある大規模な環境では、はるかに理想的です。

ネットワークアドレス変換トラバーサル(NAT-T)

ネットワークアドレス変換トラバーサル(NAT-T)は、IPsecで保護されたデータがアドレス変換のためにNATデバイスを通過する際に発生するNATアドレス変換の問題を回避するための手法です。

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とは、米国国家安全保障局が指定した暗号アルゴリズムのセットで、商用製品でも機密や極秘に分類されたトラフィックを保護することが可能です。スイートBプロトコルは、「RFC6379、 IPsec向けのスイートB暗号スイート」で定義されています。スイートB暗号スイートは、カプセル化セキュリティペイロード(ESP)の完全性と機密性を提供するもので、ESPの完全性保護と暗号化の両方が必要な場合に使用されます。英国の公共部門ネットワーク向けに定義されたIPsecプロファイルであるIPモジュラー暗号化のプロトコル要件(PRIME)は、スイートB暗号スイートをベースにしていますが、IKEv2ネゴシエーションにはAES-CBCではなくAES-GCMを使用します。

以下の暗号スイートがサポートされています。

  • スイート-B-GCM-128

    • ESP:ガロアカウンターモード(GCM)での128ビット鍵と16オクテット整合性チェック値(ICV)を使用した高度暗号化標準(AES)暗号化。

    • IKE:暗号ブロック連鎖(CBC)モードでの128ビット鍵によるAES暗号化、SHA-256認証を使用した完全性、Diffie-Hellman(DH)グループ19を使用した鍵確立、楕円曲線デジタル署名アルゴリズム(ECDSA)256ビット楕円曲線署名を使用した認証。

  • スイート-B-GCM-256

    • ESP: GCM for ESP での 256 ビット鍵と 16 オクテット ICV を使用した AES 暗号化。

    • IKE:CBCモードでの256ビット鍵によるAES暗号化、SHA-384認証を使用した整合性、DHグループ20を使用した鍵確立、ECDSA384ビット楕円曲線署名を使用した認証。

  • プライム-128

    • ESP: GCM での 128 ビット鍵と 16 オクテット ICV を使用した AES 暗号化。

    • IKE:GCMでの128ビット鍵によるAES暗号化、DHグループ19を使用した鍵確立、ECDSA256ビット楕円曲線署名を使用した認証。

  • プライム-256

    • ESP: GCM for ESP での 256 ビット鍵と 16 オクテット ICV を使用した AES 暗号化。

    • IKE:GCMでの256ビット鍵によるAES暗号化、DHグループ20を使用した鍵確立、ECDSA384ビット楕円曲線署名を使用した認証。

Suite-B暗号スイートは、IKEv1およびIKEv2に対応しています。PRIME暗号スイートはIKEv2のみに対応しています。