IKEv2認証-なぜ/どのように機能するのですか？
私は現在、IPsecに使用されるIKEv2プロトコルを理解しようとしており、認証プロセスが機能する理由/方法について疑問に思っています。
私の理解では、以前のIKE_SA_INIT交換では、イニシエーターとレスポンダーが暗号スイートについて合意し、お互いにDH値とナンスを送信します。
次のIKE_AUTH交換では、ピアのIDを相互に検証することになっています。プロトコルは、DH値とノンスを使用して計算された共有秘密SKEYSEEDから多くの鍵を導き出しました。
IKE_AUTH交換では、キーペアの1つを使用して、基本的にデータのブロックに署名します-以前のIKE_SA_INIT交換のコピー、ピアのノンスおよびprf（SK、ID）。
DH値とナンスがIKE_SA_INIT交換で認証されずに暗号化されずに送信されるため、攻撃者が反対の通信パートナーのIDを偽装してMitM攻撃を実行できないのはなぜですか？
プロトコルのどの時点で、このようなMitM攻撃が発生しますか。 DH値を置き換え、反対側で認識されますか？
事前にどうもありがとうございました！
DHのポイントは、2つの当事者だけが共有秘密（gxy）DH交換用。 SKEYSEEDは、DH交換の共有秘密ではありません。実際には、DH共有シークレットとナンスから派生しています。送信されたDHパラメータからではありません。 SKEYSEEDがネットワーク経由で送信されることはありません。
DH交換が完了し、暗号化/整合性キーが生成されると、AUTHメッセージを使用して各サイドのIDが証明されます。
イニシエーターはIDiペイロードを使用してIDをアサートし、IDiに対応する秘密の知識を証明し、整合性はAUTHペイロードを使用して最初のメッセージの内容を保護します（ セクション2.15 を参照）。また、証明書をCERTペイロードで送信し、トラストアンカーのリストをCERTREQペイロードで送信する場合もあります。 CERTペイロードが含まれている場合、提供される最初の証明書には、AUTHフィールドの確認に使用される公開鍵が含まれている必要があります。
MitM攻撃が機能するためには、DH共有秘密を知る必要があります。 DHパラメータを単純に置き換えることはできません。交換される値はgバツ mod pおよびgy mod p。 xまたはyを知っている必要があります。これらは 簡単に計算されない です。
交渉の一方を偽装することもできますが、それは実際にはMitMではありません。また、IKEv2は、この種の攻撃から保護するものではありません。それがファイアウォールルールの仕事です。