前回の IPSec と IKE の紹介は非常にわかりやすく、図を参照して IPSec を理解し、IKE SA (ISAKMP SA) と IPSec SA を区別することができます。
このドキュメントでは主に、IKE 動的ネゴシエーション モードで IPSec トンネルを確立する基本的な動作原理を紹介します。
1. IKE動的ネゴシエーションの概要
SA を手動で確立するには、構成が複雑である、イニシエータ アドレスの動的な変更をサポートしていない、期限切れのない SA を作成している、セキュリティ上不利であるなどの欠点があります。以下では、動的ネゴシエーションの利点と、IKE と IPSec の関係について説明します。
1. IKE 動的ネゴシエーションの利点
IKE プロトコルを使用して IPSec 自動ネゴシエーション用の SA を確立すると、次の利点が得られます。
(1) 構成の複雑さの軽減
IKE 動的ネゴシエーション モードでは、SPI、認証キー、暗号化キーなどのパラメータが自動的に生成されますが、手動モードでは、SA の発信方向と受信方向に応じてパラメータを指定する必要があります。
(2) リプレイ防止機能の提供
IPSec は、アンチリプレイのために AH または ESP ヘッダーのシーケンス番号を使用します (同じシーケンス番号を持つパケットは受け入れられません)。AH または ESP ヘッダーのシリアル番号がオーバーフローした場合 (最大値にも達すると、番号を付け続けることができなくなり、新しいラウンドの再番号付けが開始されます)、アンチリプレイを実現するには、SA を次のようにする必要があります。このプロセスには IKE プロトコルの連携が必要であるため、手動モードではアンチリプレイ機能はサポートされません。
リプレイ攻撃とは、すでに送信されたデータ パケット (データ パケットのシリアル番号は元のパケットと同じです) を再送信することを指します。攻撃者はこの方法を使用して宛先ホストを攻撃し、宛先ホストが引き続き攻撃を受けるようにすることができます。重複したデータ パケットを受信して解析し、大量のリソースを消費したり、場合によってはクラッシュしたりします。このリプレイ攻撃に対抗するのがアンチリプレイです。
(3) ネゴシエーション開始者のアドレスが動的に変化する場合 (PPPoE ダイヤルアップを使用してインターネットにアクセスする場合など) の ID 認証をサポートしますが、手動方式ではサポートされておらず、両方のエンドが接続されている状況にのみ適用できます。専用回線接続を使用してインターネットにアクセスします。
(4) CA (認証局) オンライン ピア ID 認証と集中管理をサポートします。これは、IPSec の大規模展開に役立ちます。手動方式はオンライン認証をサポートしません。
(5) IKE ネゴシエーションによって確立された SA にはライフサイクルがあり、リアルタイムに更新できるため、SA がクラックされるリスクが軽減され、セキュリティが向上します。
ライフタイムが指定された時間または指定されたトラフィックに達すると、SA は無効になります。SA の有効期限が切れる前に、IKE はピアの新しい SA をネゴシエートします。新しい SA がネゴシエートされると、ピアは通信を保護するために新しい SA を直ちに採用します。ライフサイクルを定義するには 2 つの方法があります。
時間ベースの有効期間は、SA の確立から失敗までの時間を定義します。
基本トラフィックの有効期間は、SA によって許可される最大トラフィックを定義します。
2. IKE と IPSec の関係
IKE プロトコルは、ISAKMP (Internet Security Association and Key Management Protocol) で定義されたフレームワークに基づいており、UDP ベースのアプリケーション層プロトコル (UDP ポート 500 に相当) です。これは、キーのネゴシエーションと交換、および SA の確立を自動的に行うサービスを IPSec に提供するため、IPSec の使用と管理が簡素化されます。
実際、IKE は別個のプロトコルではなく、ISAKMP (Internet Security Association and Key Management Protocol、Internet Security Association and Key Management Protocol)、Oakley (Oakley Key Determination Protocol、Olik Key Determination Protocol)、および SKEME (インターネット用の安全なキー交換メカニズム、インターネット セキュリティ キー交換メカニズム)。ISAKMP は主に IKE ピア間の協力関係 (IKE Peer) を定義し、IKE SA を確立します。Oakley プロトコルは、IPSec キー マテリアルの生成と交換、および IPSec パラメータ (サポートされるセキュリティ プロトコルを含む) の調整のためのフレームワークであり、SKEME プロトコルは、主に DH (Diffie-Hellman) アルゴリズムを使用して IKE キー交換方法を決定します。
IKE と IPSec (AH および ESP プロトコルを含む) の関係を図 1 に示します。IKE は UDP 上のアプリケーション層プロトコル (AH および ESP はネットワーク層プロトコル) であり、IPSec のシグナリング プロトコルです。IKE は IPSec を通じて確立されます。 SA を作成し、確立されたパラメータと生成されたキーを IPSec に渡します。IPSec は、IKE によって確立された SA を使用して、IP パケットを暗号化または認証します。
図 1 IKE と IPSec の関係
ピア間で IKE SA が確立された後、IKE SA が IPSec トンネルを保護する場合、設定された AH、ESP セキュリティ プロトコル パラメータなどに従って IPSec SA のペアがネゴシエートされます。トンネル内の安全なデータ送信。
IKE プロトコルには現在、IKEv1 と IKEv2 の 2 つのバージョンがあります。IKEv1 は、IPSec キーのネゴシエーションに 2 つのフェーズを使用し、最後に IPSec SA を確立します。第 1 段階では、通信当事者がネゴシエートして、IKE 自体が使用する安全なチャネル (トンネル) を確立します。つまり、IKE SA のペアを確立します。第 2 段階では、認証とセキュリティ保護を通過した安全なチャネルを使用して、トンネル内のデータの安全な送信を保護するために、IPSec SA のペアが使用されます。IKEv2 バージョンではネゴシエーション プロセスが簡素化され、1 回のネゴシエーションで IPSec キーと IPSec SA を直接生成できます。
まず、SA (IKE SA および IPSec SA を含む) の生成プロセスで IKE によって使用されるいくつかのセキュリティ メカニズムを理解しましょう。これらのメカニズムは、後で紹介する特定の IKE ネゴシエーション プロセスで使用されます。
2. IKEのセキュリティメカニズム
IPSec アプリケーション方式がパブリック ネットワーク (インターネットなど) 上で安全に通信できる重要な理由は、さまざまなセキュリティ メカニズムを使用してピア間のトンネル確立とデータ送信プロセス全体を保証できるためです。自動キー交換とネゴシエーションに使用されますが、IKE 自体が一連の自己保護メカニズムを備えているため、これも実行できます。これにより、安全に ID を認証し、安全でないネットワーク上でキーを配布できます。具体的には、セキュリティ保護の次の側面に反映されます。
1. 本人認証の仕組み
IKE を利用してピア間で情報を交換する場合、まず相手の正当性を確認する、つまり身元認証が必要です。IKE では、ピアの ID (ピアの IP アドレスまたは名前) を決定するために使用できるメカニズムは、事前共有キー PSK (事前共有キー) 認証、RSA デジタル証明書 (rsa-署名、または RSA デジタル署名）認証と RSA デジタル エンベロープ認証。
(1) 事前共有鍵認証
事前共有キー認証では、共有キーがキー生成マテリアルとして使用され、通信の 2 つの当事者は共有キーを使用して、同じハッシュ アルゴリズム (ハッシュ アルゴリズム、または一方向ハッシュ アルゴリズムとも呼ばれます) でメッセージをハッシュします。 ). ギリシャ演算。演算の結果が送信者から送信されたハッシュと一致するかどうかに基づいて、受信したデータが改ざんされているかどうか、およびメッセージの送信元が信頼できるかどうかを判断します。それらが同じであれば認証は成功し、そうでなければ認証は失敗します。
ほとんどの IPSec アプリケーションでは、比較的簡単な構成の事前共有キー認証方式が採用されています。
(2) 電子証明書認証
デジタル証明書認証では、通信する双方の当事者が CA 証明書を使用してデジタル証明書の有効性を検証します。CA 証明書では、双方が独自の公開キー (ネットワーク上で送信) と秘密キー (自身が保持) を持っています。送信者は、元のメッセージに対してハッシュ演算を実行し、メッセージの計算結果を独自の秘密鍵で暗号化してデジタル署名を生成します。受信者は送信者の公開キーを使用してデジタル署名を復号化し、同じハッシュ アルゴリズムを使用して復号化されたメッセージをハッシュし、操作の結果が復号化された送信者によって送信されたハッシュ値と同じかどうかを確認します。それらが同じであれば認証は成功し、そうでなければ認証は失敗します。
(3) 電子封筒認証
電子封筒認証の基本原理は、現実の手紙と同様に、非対称暗号化の結果（つまり、公開鍵と秘密鍵が 2 つ存在する）を通じて対称鍵を相手に配布することです。現実の手紙には、受信者だけが手紙の内容を読むことができるように法律で拘束されていることを私たちは知っています。電子封筒は暗号化技術を使用して、指定された受信者のみが機密内容を読み取ることができるようにします。
デジタル エンベロープでは、送信者は対称鍵 (送信者が事前に対称鍵をランダムに生成する必要がある) を使用して送信するメッセージにデジタル署名し、受信者の公開鍵 (これを部分的にデジタル エンベロープと呼びます) で対称鍵を暗号化します。エンベロープ)、暗号化された対称キーがデジタル署名されたメッセージとともに受信者に送信されます。それを受信した後、受信者はまず自分の秘密キーを使用してデジタル エンベロープを開いて送信者の対称キーを取得し、次にその対称キーを使用して元のデジタル署名されたメッセージを復号化し、送信者のデジタル署名が有効かどうかを確認します。正しければ認証は成功し、そうでなければ認証は失敗します。
事前共有鍵認証方式は、1つのピアが複数のピアに対応する場合、ピアごとに事前共有鍵を設定する必要があり、作業負荷が大きいため、小規模なネットワークでは確立しやすい方式ですが、セキュリティが低下します。デジタル証明書の使用は非常に安全ですが、CA がデジタル証明書を発行する必要があるため、大規模ネットワークでの使用に適しています。デジタル エンベロープ認証は、デバイスが国家暗号局の要件を満たす必要がある場合に使用されます (国家暗号局が要求するハッシュ アルゴリズム SM3 を使用する必要があります)。この認証方法は、デバイスのネゴシエーション プロセス中にのみサポートされます。 IKEv1のメインモード。
上記の ID 認証に使用されるさまざまなキーはすべて IKE 認証キーであり、サポートされるアルゴリズムは MD5、SHA1、SHA2-256、SHA2-384、SHA2-512、SM3 です。MD5 アルゴリズムは 128 ビット キーを使用し、SHA-1 アルゴリズムは 160 ビット キーを使用し、SHA2-256、SHA2-384、SHA2-512 はそれぞれ 256 ビット、384 ビット、512 ビット キーを使用します。 、SM3 は 128 ビット キーを使用します。それらの間のセキュリティの順序は、SM3 > SHA2-512 > SHA2-384 > SHA2-256 > SHA1 > MD5 です。一般的なセキュリティ要件の場合、認証アルゴリズムは SHA2-256、SHA2-384、SHA2-512 が推奨されますが、MD5 と SHA1 は推奨されませんが、特にセキュリティ要件が高い場合には SM3 アルゴリズムが使用できます。
上記に関与する身元認証キー（事前共有キー、公開/秘密キーを含む）と証明書は、送信者の「検証データ」として送信され、対応する方法で検証のために相手に送信されます。
2. データ暗号化の仕組み
IPSec のデータ暗号化メカニズムは、主に 2 つの側面で使用されます。1 つは、送信されるデータ情報 (共有キー、証明書、認証キーなど) を保護することです。次に、トンネル内で送信されるユーザー データを保護します。ただし、ここで説明するデータ暗号化メカニズムで使用される対称キー メカニズム、つまり、上記のデジタル証明書の身元認証やデジタル署名アプリケーションで使用される非対称キー システムではなく、暗号化と復号化に同じキーが使用されます。
IKE でサポートされる暗号化アルゴリズムには、DES、3DES、AES-128、AES-192、AES-256、SM1、および SM4 が含まれます。DES アルゴリズムは 56 ビット キーを使用し、3DES は 168 ビット キーを使用し、AES-128、AES-192、および AES-256 はそれぞれ 128、192、および 256 ビット キーを使用し、SM1 と SM4 は両方とも使用します。 128 ビット鍵を使用します。これらの暗号化アルゴリズムのセキュリティ レベルは、高から低の順に次のとおりです。SM4 > SM1 > AES-256 > AES-192 > AES-128 > 3DES > DES。AES-256、AES-192、および AES-128 は推奨されますが、推奨されません。推奨 3DES および DES アルゴリズムを使用する SM1 および SM4 は、計算速度が比較的遅いため、機密性とセキュリティ要件が非常に高い場所でのみ推奨されます。非対称鍵システムでは通常、RSA または DSA (Digital Signature Algorithm、デジタル署名アルゴリズム) 暗号化アルゴリズムが使用されます。
3. DH (Diffie-Hellman) 鍵交換アルゴリズム
Diffie-Hellman アルゴリズムは公開鍵アルゴリズムです。通信中の 2 者は、鍵を送信せずに何らかのデータを交換することで共有鍵を計算できます。また、たとえ第三者が、鍵を計算するために双方が使用するすべての交換データを傍受したとしても、実際の鍵を計算するには十分ではありません。
DH は主に、IKE 動的ネゴシエーション中に新しい IPSec SA によって使用されるキーを再生成するために使用されます。これは、初期段階で生成されたキー生成マテリアルに依存せずに、一連のデータ交換を通じて双方が共有するキーを最終的に計算できるためです。ただし、DH は両当事者の身元に関する情報を提供しないため、交換されたデータが法的当事者に送信されたかどうかを確認することはできません。第三者は、鍵をネゴシエートし、双方向の通信を共有することによって、情報を取得および送信できます。データが傍受されるため、IKE にはピアの ID を認証するための ID 認証も必要です。
4. PFSの仕組み
PFS (Perfect Forward Secrecy、完全前方セキュリティ) はセキュリティ機能です。これは、キーがクラックされた後、他のキーのセキュリティに影響を与えないことを意味します。これらのキーの間には派生関係がないためです。
IPSec SA のキーは IKE SA のキーから派生します。1 回の IKE SA ネゴシエーションで、特定の導出関係を持つ 1 つ以上の IPSec SA のペアが生成される可能性があるため、IKE キーが盗まれると、攻撃者が十分な情報を収集することによって IPSec SA キーを不正に導出する可能性があり、もはや安全ではありません。IPSec の生成中に PFS が有効になっている場合、追加の DH 交換を実行することで新しい独立した IPSec SA を生成できるため、IPSec SA キーのセキュリティが保証されます。
3. IKEv1 キー交換とネゴシエーション: フェーズ 1
前述したように、IKEv1 バージョンでは、最終的な IPSec SA を生成するために 2 つの段階を経る必要があります。これらの段階は、IKE SA と IPSec SA をそれぞれ確立するために使用されます。最初の段階を以下に紹介します。
IKEv1 の最初のフェーズの最終目標は、ピア間に安全なチャネルを作成し、ピアの IKE SA を確立することです。このフェーズでは、IKE ピアが相互に認証し、共通のセッション キーを決定します。この段階では、Diffie-Hellman (DH) アルゴリズムを使用して鍵交換が行われ、IKE SA の確立が完了するため、その後の第 2 段階プロセスのネゴシエーション プロセスは安全に保護されます。
IKEv1 では、IKE SA を確立するプロセスに、メイン モードとアグレッシブ モード (「アグレッシブ モード」とも呼ばれる) の 2 つの交換モードがあります。以下に紹介します。
1. メインモード
IKEv1 のメインモードにおける IKE SA 確立プロセスでは、3 つの双方向メッセージ交換があり、6 つの情報が使用されます (図 2-)。
図 2 メイン モードでのキー交換およびネゴシエーション プロセスの概略図
最初のステップはメッセージ①と②に対応しており、トンネルの両端のピアは、お互いに設定された IKE ポリシーを交換することで、採用する IKE セキュリティ ポリシーをネゴシエートします。その他. データを暗号化し、相手の身元を正しく認証します。
2 番目のステップは、パラメータ情報 (DH 公開値や乱数 nonce など) であるメッセージ③と④に相当します。キーには、主に、第 2 フェーズのネゴシエーションに使用される身元認証キーと、ネゴシエートされたデータの暗号化キーが含まれます。
3番目のステップはメッセージ⑤と⑥に相当し、事前に作成した暗号化キーを使用して、お互いのアイデンティティ（IPアドレスやピア名など）と検証データ（採用されているアイデンティティ認証方式のパスワード）を送信します。 、または証明書データなど）、上記の対応する認証方法を使用して、ピア間の ID 認証を実行します。これでIKE SAの構築が完了します。
メッセージを正式に交換する前に、開始者と受信者はまずそれぞれの Cookie (ISKMP ヘッダー内。これによりリプレイや DoS 攻撃を防ぐことができます) を計算する必要があります。これらの Cookie は、個々のネゴシエーション交換メッセージを識別するために使用されます。RFC では、送信元/宛先 IP アドレス、送信元/宛先ポート番号、ローカルで生成された乱数、日付と時刻をハッシュして Cookie を生成することを推奨しています。Cookie は IKE ネゴシエーションで情報を交換するための一意の識別子となり、IKEv1 版では Cookie、IKEv2 版では IKE の SPI (Security Parameter Index) になります。
上記6つのメッセージについて、以下で詳しく紹介していきます。
(1) メッセージ①と②は IKE ポリシー交換に使用され、双方の IKE セキュリティ ポリシーを交渉および確認するプロセスであり、一般的なフレームワークが提案されており、特定の SA フォーマットは定義されていません。
このプロセスでは、イニシエータは 1 つ以上の IKE セキュリティ プロポーザル [5 タプルを含む: 認証方法 (デジタル証明書認証、事前共有キー認証、またはデジタル エンベロープ認証)、暗号化アルゴリズム (AES、DES、または 3DES など)、ハッシュ アルゴリズム (MD5 または SHA など)、DH グループ、IKE SA ライフタイム]、レスポンダは、受信したセキュリティ プロポーザルに最初に一致する IKE セキュリティ プロポーザルをローカルで検索し、決定された IKE セキュリティ プロポーザル パーティでイニシエータに応答します。イニシエータは、双方が共同で決定した IKE ポリシーを学習します。これらの IKE ポリシーは IPSec SA ネゴシエーションの第 2 フェーズに直接暗号化保護を提供するため、これは安全な環境でのその後の IPSec SA ネゴシエーションの基礎を築くためのものです。
(2) メッセージ③と④は、必要な各種鍵を生成する処理である鍵情報交換に使用されます。
まず、両者は公開鍵と Diffie-Hellman アルゴリズムによって計算されたノンス値 (乱数) を交換し、次に自分の公開/秘密鍵、相手の公開鍵、ノンス値、および設定された値を使用します。事前共有キー (事前共有キーのキー認証方式を使用) などを実行して、最終的に第 2 フェーズの一連の共有キーを生成します (両端で生成されるキーは同じです)。たとえば、認証キー (skey ID_a と呼びます)、暗号化キー (skey ID_e と呼びます)、IPSec SA キーの生成に使用できるキー素材 (skey ID_d と呼びます) です。認証キーは、IKE ネゴシエーションの第 2 フェーズ中にチャネル上で送信されるネゴシエーション データ (非ユーザー データ) を認証するために使用され、暗号化キーは、IKE ネゴシエーションの第 2 フェーズ中にチャネル上で送信されるネゴシエーション データを暗号化するために使用されます。
事前共有鍵認証方式を使用する場合、上記の鍵を正しく生成するために、各ピアは相手に対応する事前共有鍵を見つける必要があります。複数のピアが接続されている場合、各ピアのペアは両端で必要です。同じ共有キーを使用して構成されます。
(3) メッセージ⑤および⑥は、ピア間の識別情報（ピアのIPアドレスや名前など）や検証データ（採用されている識別認証方式の鍵や証明書データなど）の認証に使用されます。この際の情報のやり取りは、予め生成された暗号鍵（スキーID_e）により暗号化されて保護される。相互認証が通過すると、ピア間の IKE SA の確立が完了し、第 2 フェーズで IPSec SA のネゴシエーションに必要なセキュリティ チャネルが直ちに確立され、両端の VPN デバイスは、ネゴシエートされたセキュリティ ポリシーを使用できるようになります。第 1 フェーズから第 2 フェーズへ 第 2 フェーズでは、安全な暗号化と認証のために IPSec SA をネゴシエートします。
2. サベージモード
図 3 に示すように、アグレッシブ モードでは 3 つの情報のみが使用され、メッセージ①と②はピア間の IKE セキュリティ ポリシーのネゴシエーション、DH 公開キー、必要な補助情報、および ID 情報 (通常は IP アドレスでは識別されません) の交換に使用されます。 、代わりにホスト名によって識別されます）。
図 3 アグレッシブ モードでの鍵交換およびネゴシエーション プロセスの概略図
(1) メッセージ①には、イニシエータからレスポンダに提供される IKE セキュリティ ポリシー、ローカル鍵生成情報 (ローカル DH 公開鍵)、アイデンティティ情報 (主にピア名) が含まれており、レスポンダはこれらを受信します。いずれも、イニシエータから送信された IKE セキュリティ ポリシーに一致するポリシーをローカルで検索する必要があり、見つかった場合は共通 IKE ポリシーとして決定されます。次に、決定された IKE セキュリティ ポリシー、イニシエータから送信されたキー生成情報、およびローカル DH 公開/秘密キー、ノンス乱数を使用して、イニシエータから送信された ID 情報に従って、認証キーと暗号化キーを生成します。発信者の身元が最初に検証されます。
(2) ②のメッセージには、鍵生成情報と応答者の身元情報のみが含まれており、応答者が本人確認に使用する検証データ（採用されている身元認証機構における鍵や証明書等を含む）は、イニシエーター。イニシエーターは、最終的な IKE ポリシーを受信した後、それを知り、レスポンダーの公開キー、ローカル エンドの公開/秘密キー、およびノンス乱数を使用して一連のキーを生成します (正しい状況下では、応答側が生成したキーは同じです）、最後に応答側から送信された ID 情報と検証データに従って応答側を認証します。
(3) メッセージ③は、イニシエータが決定された IKE 戦略に従って検証データ (採用されている身元認証メカニズムのキーと証明書を含む) をレスポンダに送信し、レスポンダが最終的にイニシエータの検証を完了できるようにするというものです。 。この時点で、情報交換プロセス全体が完了し、第 2 段階に入り、IPSec SA が確立されます。
図 2 と図 3 の比較から、メイン モードと比較して、アグレッシブ モードは交換される情報の数が減少し、ネゴシエーションの速度が向上しますが、身元情報と検証データは暗号化および保護されないことがわかります。なぜなら、双方が送信する識別情報（メッセージ①と②に相当）は暗号化されていないからです（ただし、メッセージ⑤と⑥に相当する、メインモードで送信される識別情報と検証データは暗号化されています）。ただし、アグレッシブ モードは ID 保護を提供しませんが、それでも一部の特定のネットワーク環境のニーズを満たすことができます。
IPSec トンネル内に NAT デバイスが存在する場合、NAT トラバーサル機能を有効にする必要があり、NAT 変換によりピアの IP アドレスが変更されます。アグレッシブ モードは ID を識別するために IP アドレスに依存しないため、事前共有キー認証方式が使用されている場合、NAT タイム トラバーサルはブルータル モードでのみ可能です。
イニシエータの IP アドレスが固定されていないか予測不可能で、双方が事前共有キー認証方式を使用して IKE SA を作成したい場合は、アグレッシブ モードのみを使用できます。
イニシエーターがレスポンダーのポリシーを知っている場合、またはレスポンダーのポリシーを包括的に理解している場合は、アグレッシブ モードの方が IKE SA をより迅速に作成できます。
メイン モードとアグレッシブ モードは、事前共有キーを決定する方法が異なります。メイン モードでは、IP アドレスに基づいて事前共有キーのみを決定できます。アグレッシブ モードでは、ID 情報 (ホスト名または IP アドレス) に基づいて事前共有キーが決定されます。ピアの両端がホスト名で識別される場合、ネゴシエーションにはアグレッシブ モードを使用する必要があります。メイン モードを使用すると、送信元 IP アドレスに従って事前共有キーが見つからないため、キーを生成できません。 , メインモードでは、③と④のメッセージ交換後に事前共有鍵を使って鍵を計算する必要がありますが、⑤と⑥のメッセージでは双方の身元情報が送信されるためです。アグレッシブモードでは、メッセージ①と②でホストのID情報（IPアドレスまたはホスト名）が送信されており、相手はID情報を基に対応する事前共有鍵を見つけて鍵を計算することができます。
4. IKEv1 キー交換とネゴシエーション: フェーズ 2
IKEv1 の第 2 フェーズでは、第 1 フェーズに基づいて最終的に IPSec SA のペアを確立します。このフェーズには、クイック モードという 1 つのモードしかありません。クイック モード ネゴシエーションは IKE SA によって保護されており、ネゴシエーション プロセス全体を図 4 に示します。
図 4 クイック モード ネゴシエーション プロセスの概略図
クイック モード ネゴシエーション中に、主に次の IPSec SA セキュリティ ポリシーが決定されます。
どの IPSec セキュリティ プロトコルを使用するか: AH または ESP。
どの HASH アルゴリズム (認証アルゴリズム) を使用するか: MD5 または SHA。
使用する IPSec 動作モード: トンネル モードまたはトランスポート モード。
暗号化が必要かどうか。必要な場合は、暗号化アルゴリズムとして 3DES または DES を選択します。
オプションで PFS (Perfect Forward Secrecy、完全転送セキュリティ) をサポートします。
上記の側面について合意に達した後、インバウンド通信とアウトバウンド通信用に 2 つの IPSec SA がそれぞれ確立されます。
メッセージ①と②の IPSec セキュリティ提案には、セキュリティ プロトコル、SPI、IPSec カプセル化モード、PFS (オプション)、IPSec SA ライフ サイクルなどが含まれます。これら 2 つのメッセージには、両当事者の ID 情報 (IP アドレス、トランスポート層ポートなど)、検証データ (採用された ID 認証メカニズムのキー、証明書などを含む)、およびノンス (リプレイに抵抗するために使用される乱数) も含まれます。 、暗号化マテリアルとしても使用されますが、PFS が有効な場合にのみ使用されます)。受信側は受信した相手のデータを用いて暗号鍵を生成します｡メッセージ③は確認メッセージです｡この段階で送信者がメッセージ②を受信したことを確認することで､応答側は正式な通信が行われたことがわかります｡可能。
5. IKEv2 キーのネゴシエーションと交換
上記の検討を通じて、IKEv1 では最終的に IPSec SA のペアを確立するまでに少なくとも 6 つのメッセージを交換する 2 段階を経る必要があるのに対し、IKEv2 ではセキュリティの確保を前提に送信する情報量と交換回数を削減することが分かりました。もっとシンプルに。
1.IKEv2の概要
IKEv2 は IKEv1 のほとんどの機能を保持しており、IKEv1 のいくつかの拡張機能 (NAT トラバーサルなど) が IKEv2 プロトコルのコンポーネントとして IKEv2 フレームワークに導入されています。IKEv1 とは異なり、IKEv2 のすべてのメッセージは「要求と応答」の形式でペアで表示されます。応答側は、イニシエーターが送信したメッセージを確認する必要があります。確認メッセージが指定された時間内に受信されない場合、イニシエーターはパケットを受信する必要があります。セキュリティを向上させるために再送信されます。
IKEv2 は DoS 攻撃に対しても防御できます。IKEv1 では、ネットワーク内の攻撃者がメッセージをリプレイし続けると、レスポンダーはそれに応答するための計算を実行し、デバイスのリソースを消費する必要があり、その結果、レスポンダーに対する DoS 攻撃が発生します。IKEv2 では、リクエストを受信した後、レスポンダーは急いで計算することはありませんが、最初に Cookie タイプの Notify ペイロード (つまり、特定の値) をイニシエーターに送信し、その後の 2 つの間の通信ではリンクを維持する必要があります。 Cookie とイニシエーター間の対応関係により、DoS 攻撃を効果的に防御します。
IKEv2 では、初期交換、Create_Child_SA 交換、および情報交換の 3 種類の交換が定義されています。IKEv2 は、最初の交換を通じて IKE SA と IPSec SA の最初のペアのネゴシエーションと確立を完了できます。複数の IPSec SA ペアを確立する必要がある場合、IPSec SA 値の各ペアを 1 回追加して子 SA 交換を作成するだけで済みます (IKEv1 が使用されている場合は、子 IPSec SA を作成する必要があります) 2 つの段階を経ます）。
2. IKEv2 の初期交換
IKEv2 の最初の交換は、IKEv1 の最初のフェーズに対応します。図 5 に示すように、最初の交換には 4 つのメッセージの 2 つの交換が含まれます。メッセージ①と②は最初の交換に属し、IKE SA パラメータのネゴシエーションは平文で完了し、主に暗号化アルゴリズムのネゴシエーション、ノンス値の交換、DH 交換の完了により、暗号化のための鍵マテリアルの生成と後続の交換の検証が行われます。メッセージ③と④は 2 番目の交換局に属し、身元認証 (身元情報と検証データの交換による)、最初の 2 つのメッセージの認証、および IPSec SA のパラメータ ネゴシエーションが暗号化された方法で完了します。
3. 子 SA 交換を作成する
最初の交換が完了すると、どの当事者も子 SA 交換の作成を開始できますが、この交換の開始者は最初の交換の開始者とは異なる場合があります。この交換は最初の交換の後に行われる必要があり、交換されたメッセージは最初の交換でネゴシエートされたキーによって保護されます。
子 SA の作成交換には、IKEv1 の第 2 フェーズに対応する、複数の IPSec SA または IKE 再ネゴシエーションを作成するために 1 つの IKE SA に使用される 2 つのメッセージが含まれています。PFS をサポートする必要がある場合は、追加の DH 交換を実行して子 SA 交換を作成し、IPSec SA の新しいキーを確立できます。
4. 通知のやり取り
通信する 2 つの当事者間の鍵ネゴシエーション中に、一方の当事者が制御情報を他方の当事者に送信して、何らかのエラーまたは特定のイベントの発生を通知することができます。これは、「通知交換」プロセスによって完了する必要があります。
通知交換は、エラー情報、削除情報、通知情報などの一部の制御情報をピア間で転送するために使用されます。情報メッセージを受信した当事者は応答する必要がありますが、これにはペイロードが含まれていない可能性があります。通知交換は最初の交換後にのみ発生でき、その制御情報は IKE SA (交換は IKE SA によって保護される) またはサブ SA (交換はサブ SA によって保護される) のいずれかになります。