Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

インターネット鍵交換

概要とIKE

インターネット鍵交換(IKE)は、2台のデバイス間で認証されたセキュアな通信チャネルを設定するために使用されるセキュアな鍵管理プロトコルです。

IKEは以下を実行します。

  • パケットと IPsec パラメーター IKEネゴシエートし、管理します。

  • セキュアな鍵交換の認証

  • 共有の秘密(パスワードではなく)と公開キーによる相互ピア認証を提供する

  • アイデンティティ保護を提供する(メイン モード)

  • Diffie-Hellman 方法を採用し、IPsec ではオプションです(共有キーをエンドポイントで手動で入力できます)。

IKEバージョン

次の 2 つのIKE標準が用意されています。

  • IKE 1 - RFC 2409でIKEされたプロトコルのアップグレード。

  • IKE バージョン 2 - IKEv2(IKE バージョン 2)は、RFC 7296 で定義された IKE プロトコルの最新バージョンです。

インターネット鍵交換バージョン 2 (IKEv2) は、RFC 7296 で定義されたインターネット鍵交換 (IKE) プロトコルの最新バージョンです。インターネット鍵交換バージョン 2 (IKEv2) は、RFC 7296 で定義されたインターネット鍵交換 (IKE) プロトコルの最新バージョンです。VPN ピアは、IKEv1 または IKEv2 のいずれかとして設定されています。ピアが IKEv2 として設定されている場合、そのリモートピアが IKEv1 ネゴシエーションを開始しても、それを IKEv1 に戻すことはできません。

IKEv2 経由での IKEv1 を使用するメリットは次のとおりです。

  • 1つの4メッセージ交換で8個の初期交換を置き換えます。

  • IPsec SA セットアップの遅延を軽減し、接続の確立速度を向上させます。

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

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

  • すべてのメッセージが要求または応答であるため、信頼性が向上します。イニシエーターは、応答を受信しない場合、再送を行います。

ネットワーク間IKE IPSec

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

  • インターネット鍵交換(IKE)プロトコル: IPsec は、IKE プロトコルを使用して、鍵とセキュリティ アソシエーションの自動生成とネゴシエーションをサポートします。2 IKE VPN をネゴシエートするには、手動の鍵交換よりもセキュリティーが高い。

  • 手動鍵交換:IPsec は鍵の手動での使用と交換をサポートします(例: VPNを確立する必要があります

IKEv1 メッセージ交換

IKEネゴシエーションには 2 つのフェーズが含まれます。

  • フェーズ 1 :チャネルの認証方法とセキュリティ保護方法に関するプロポーザルの交換を交渉します。

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

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

AutoKey トンネル ネゴシエーション(インターネット鍵交換 IKE)トンネル ネゴシエーションのフェーズ 1 は、チャネルを認証し、セキュリティを保護する方法に関するプロポーザルの交換で構成されています。参加者は、以下のような許容セキュリティサービスを提案しています。

  • 暗号化アルゴリズム - データ暗号化規格(DES)、3DES(トリプル データ暗号化規格)、AES(高度暗号化標準) (をIPsec の概要参照してください)

  • 認証アルゴリズム — Message Digest 5(MD5)および SHA(セキュア ハッシュ アルゴリズム) (をIPsec の概要参照してください)

  • Diffie-hellman (DH) グループです。(をIPsec の概要参照してください)

  • 事前共有鍵または RSA/DSA 証明書。(をIPsec の概要参照してください)

フェーズ 1 のネゴシエーションが成功すると、トンネルの両端が、提案されたフェーズ 1 セキュリティ パラメーターの少なくとも 1 つのセットを受け入れ、それを処理することに同意した場合に終了します。ジュニパーネットワークス デバイスは、フェーズ 1 ネゴシエーションの最大 4 つのプロポーザルをサポートします。このため、受け入れる鍵ネゴシエーション用のセキュリティ パラメーターの範囲をどのくらい制限する方法を指定できます。Junos OS は、定義済みの標準、互換、基本フェーズ1の提案書セットを提供します。また、カスタム フェーズ 1 のプロポーザルを定義できます。

フェーズ 1 の交換は、メイン モードまたはアグレッシブ モードのどちらかで実行できます。IKE ポリシーの設定中にモードを選択できます。

このトピックは、以下のセクションで構成されています。

メインモード

メインモードでは、イニシエーターと受信者が 3 2 方向の交換 (合計6つのメッセージ) を送信して、以下のサービスを実行します。

  • 最初の交換(メッセージ 1 と 2) — 暗号化アルゴリズムと認証アルゴリズムを提案して受け入れる。

  • 2 番目の交換(メッセージ 3 と 4) — DH 交換を実行し、イニシエーターと受信者がそれぞれ擬似乱数を提供します。

  • 3 番目の交換(メッセージ 5 と 6) — イニシエーターと受信者の ID を送信および検証します。

第3のメッセージ交換で送信される情報は、最初の2つの交換で確立した暗号化アルゴリズムによって保護されます。したがって、参加者の ID は暗号化されるため、「暗号化されていない」というメッセージは送信されません。

アグレッシブモード

アグレッシブモードでは、イニシエーターと受信者がメインモードと同じ目標を達成しますが、2つの交換だけで、合計3つのメッセージが表示されます。

  • 最初のメッセージ—イニシエーターは SA(セキュリティ アソシエーション)を提案し、DH 交換を開始して、擬似乱数とその番号をIKEします。

    フェーズ1ネゴシエーションの複数の提案を使用してアグレッシブモードを設定する場合は、DH グループをネゴシエートできないため、すべての提案で同じ DH グループを使用します。最大4つの提案を設定できます。

  • 2 番目のメッセージ — 受信者は SA を受け入れ、イニシエーターを認証し、と擬似乱数とその番号IKEアイデンティティを送信し、証明書を使用している場合は受信者の証明書を送信します。

  • 3 番目のメッセージ — イニシエーターは受信者を認証し、交換を確認し、証明書を使用している場合はイニシエーターの証明書を送信します。

参加者の ID は(最初の 2 つのメッセージでは)クリアで交換されるため、アグレッシブ モードでは ID 保護は提供されません。

メインおよびアグレッシブモードは、IKEv1 プロトコルにのみ適用されます。IKEv2 プロトコルは、メイン モードおよびアグレッシブ モードを使用してネゴシエートしません。

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

参加者がセキュアで認証されたチャネルを確立した後、フェーズ 2 を進み、このフェーズ 2 でセキュリティー アソシエーション(SA)をネゴシエートし、IPsec トンネルを介して送信されるデータを保護します。

フェーズ 1 のプロセスと同様に、参加者は SA にどのセキュリティ パラメーターを採用する必要があるかどうかを決定するプロポーザルを交換します。フェーズ 2 のプロポーザルには、セキュリティ プロトコル(ESP(セキュリティペイロードのカプセル化)または AH(認証ヘッダー)、選択した暗号化および認証アルゴリズムも含まれています。提案では、PFS (完全前方秘密) が求められている場合には、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 を使用すると安全性が高くなりますが、フェーズ 2 の再キー操作は、PFS が有効な場合にやや長い時間がかかる場合があります。

防御のリプレイ

リプレイ攻撃は、許可されていない人物が一連のパケットを受信し、それを後で使用して、システムをあふれし、サービス拒否 (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、インターネット鍵交換 プロトコル バージョン 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 キー更新のたびに行われます。再認証の頻度が3に設定されている場合は、3回の IKE キー更新のたびに再認証が行われます。

IKEv2 フラグメント化

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

RFC 7383、インターネット鍵交換 プロトコル バージョン 2(IKEv2)のメッセージ フラグメント化で説明されている IKEv2 メッセージのフラグメント化により、IP フラグメントがブロックされ、ピアが IPsec セキュリティ アソシエーション(SA)を確立できない環境で IKEv2 を動作できます。IKEv2 の断片化によって、大規模な IKEv2 メッセージが、IP レベルで断片化が発生しないように、小規模なメールセットに分割されます。断片化は、元のメッセージが暗号化されて認証される前に行われるため、各フラグメントが個別に暗号化されて認証されます。受信者側では、フラグメントが収集、検証、暗号化解除された後、元のメッセージに反映します。

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

トラフィック セレクターは、ネットワーク ネゴシエーションの間に使用される IKEv2 IKE設定できます。トラフィックの選択は、トラフィックがローカルおよびリモートアドレスの指定されたペアと一致する場合に、VPN トンネルを通過するトラフィックを許可する IKE ピア間の合意です。関連するセキュリティーアソシエーション (SA) では、トラフィックセレクターに準拠しているトラフィックのみが許可されます。トラフィック セレクターは、トンネルの作成中に使用され、トンネルを設定し、トンネルを通過して許可されるトラフィックを決定します。

プロキシー ID

プロキシ ID は、仮想プライベート ネットワーク(インターネット鍵交換 ネットワークIKE)ネゴシエーションのフェーズ 2 で使用されます。VPN トンネルの両端には、プロキシ ID が手動で設定されている(ルートベースの VPN)か、トンネル ポリシーで送信元 IP、宛先 IP、サービスの組み合わせを使用するかのどちらかです。フェーズ 2 のネゴシエーションIKEエンドがネゴシエートされた場合、各エンドは設定済みのローカルおよびリモートのプロキシー ID を実際に受信したプロキシー ID と比較します。

トラフィックセレクター

プロキシ ID は、ルートベースおよびポリシーベースの Vpn の両方でサポートされています。ただし、マルチプロキシ ID はルートベースの Vpn に対してのみサポートされています。マルチプロキシ ID は、トラフィックセレクターとしても知られています。トラフィックの選択は、トラフィックがローカルおよびリモートアドレスの指定されたペアと一致する場合に、トンネルを通過するトラフィックを許可する IKE ピア間の契約です。特定のルートベースの VPN 内でトラフィックセレクターを定義すると、複数フェーズ2の IPsec Sa が生成される可能性があります。SA によって許可されるトラフィックのみが、トラフィックセレクターに準拠しています。リモートゲートウェイデバイスが非ジュニパーネットワークスデバイスである場合、一般的にトラフィックセレクターが必要になります。

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

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

事前共有鍵認証

証明書ベースの認証

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

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

  • 事前共有鍵は、両方の当事者で同じパスワードです。このパスワードは、電話、言葉による交換、安全性の低いメカニズム(電子メールも含む)を使用して事前に交換されます。

  • 事前共有鍵は、英数字、および英数字の異なるケースを組み合わせて使用し、8 文字以上(12 以上を推奨)で構成する必要があります。

  • 事前共有鍵は、辞書語を使用する必要があります。

証明書はパブリック キーとプライベート キーで構成され、パブリック キーとプライベート キーとして知られるプライマリ証明書で署名認証機関できます(CA)

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

当事者は証明書をチェックして、信頼できる認定パートナーによって署名CA。

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

証明書は、事前共有鍵を共有する必要のある多くのピア サイトがある大規模な環境でも、はるかに理想的です。

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

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

IP アドレスを変更すると、NAT の機能によってパケットが破棄され IKE します。フェーズ 1 の交換中に 1 つ以上の NAT デバイスがデータ パスに沿って検出されると、NAT-T は IPsec パケットにユーザー データグラム プロトコル(UDP)カプセル化のレイヤーを追加して、アドレス変換後に破棄されません。NAT-T は、IKE と ESP の両方のトラフィックを、ポート4500を送信元と宛先の両方のポートとして使用する UDP 内にカプセル化します。NAT デバイスは古い UDP 翻訳を期限切れにしているため、ピア間でキープアライブメッセージが必要になります。

NAT デバイスの場所は、以下のようなものになります。

  • NAT デバイスの背後には、IKEv1 または IKEv2 のイニシエーターのみが含まれています。複数のイニシエーターは、個別の NAT デバイスの背後に存在することができます。また、イニシエーターは、複数の NAT デバイスを介してレスポンダーに接続することもできます。

  • IKEv1 または IKEv2 のレスポンダーだけが、NAT デバイスの背後にあります。

  • IKEv1 または IKEv2 の両方のイニシエーターとレスポンダーが、NAT デバイスの背後にあります。

Suite B および PRIME 暗号化スイート

Suite B は、米国国内のセキュリティ機関によって指定された一連の暗号化アルゴリズムです。商用製品では、シークレットまたは top secret レベルで分類したトラフィックを保護することができます。Suite B プロトコルは RFC 6379, Suite B 暗号化スイート for IPsec で定義されています。Suite B 暗号化スイートは、カプセル化セキュリティーペイロード (ESP) 整合性と機密性を提供し、ESP 整合性の保護と暗号化がどちらも必要な場合に使用する必要があります。IP モジュラー暗号化 (素数) のプロトコル要件。英国でパブリックセクターネットワーク用に定義された IPsec プロファイルは、Suite B 暗号化スイートをベースにしていますが、IKEv2 ネゴシエーションには AES-CBC ではなく、AES (GCM) を使用しています。

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

  • Suite-B-GCM-128

    • ESP Advanced Encryption Standard (AES) 暗号化 (128 ビットキーを含む)、および Galois 16 オクテット整合性チェック値 (ICV) は、カウンタモード (GCM) です。

    • IKE:暗号化ブロックチェーン (CBC) モードの128ビットキーを使用した AES 暗号方式、SHA-256 認証を使用した整合性、Diffie-hellman (DH) グループ19を使用したキーの確立、ECDSA による認証を使用するのデジタル署名アルゴリズムの256ビット楕円カーブシグネチャ

  • Suite-B-GCM-256

    • ESP AES 暗号化では、256ビットキーを使用し、GCM では16オクテット ICV を ESP に対応させることができます。

    • IKE:CBC モードで256ビットキーを使用する AES 暗号化は、SHA-384 認証を使用した整合性、DH グループ20を使用した鍵の確立、および ECDSA の384ビットの楕円曲線シグネチャを使用した認証を行います。

  • PRIME-128

    • ESP 128ビットキーを使用した AES 暗号化と GCM の16オクテット ICV

    • IKE:AES 暗号化は、GCM では128ビットキー、DH グループ19を使用してキーを確立すること、および ECDSA の256ビットの楕円曲線シグネチャによる認証を使用します。

  • PRIME-256

    • ESP AES 暗号化では、256ビットキーを使用し、GCM では16オクテット ICV を ESP に対応させることができます。

    • IKE:AES 暗号化は、GCM では256ビットキーを使用し、DH グループ20を使用してキーを確立し、ECDSA 384 ビットの楕円曲線シグネチャを使用して認証を行います。

Suite B 暗号化スイートは、IKEv1 および IKEv2 をサポートしています。主要な暗号化スイートは IKEv2 のみをサポートしています。