我目前正在尝试了解用于 IPsec 的 IKEv2 协议，并且想知道身份验证过程为何/如何工作。
据我了解，在之前的 IKE_SA_INIT 交换中，发起者和响应者就加密套件达成一致，相互发送他们的 DH 值和随机数。
以下 IKE_AUTH 交换应该验证对等方的身份。该协议从使用 DH 值和随机数计算的共享密钥 SKEYSEED 中派生出许多密钥。
在 IKE_AUTH 交换中，其中一个密钥对基本上只用于签署数据块 - 先前 IKE_SA_INIT 交换的副本、对等方的 nonce 和 prf(SK, ID)。
我不明白的事实是，由于 DH 值和随机数在 IKE_SA_INIT 交换中未经身份验证和未加密发送，攻击者就不能欺骗对方通信伙伴的身份并执行中间人攻击吗？
在协议中的什么时候，这样的中间人攻击（例如替换 DH 值）会被另一方识别？
非常感谢您！
DH 的要点是只有双方才能为 DH 交换生成共享密钥 (g xy )。 SKEYSEED不是 DH 交换的共享密钥。事实上，它源自DH 共享秘密和随机数；不是来自传输的 DH 参数。 SKEYSEED永远不会通过电线传输。
DH 交换完成并生成加密/完整性密钥后，AUTH 消息将用于证明每一方的身份。
发起者使用 IDi 有效负载断言其身份，证明与 IDi 对应的秘密的知识，并且完整性使用 AUTH 有效负载保护第一条消息的内容（参见第 2.15 节）。它还可能在 CERT 有效负载中发送其证书，并在 CERTREQ 有效负载中发送其信任锚列表。如果包含任何 CERT 有效负载，则提供的第一个证书必须包含用于验证 AUTH 字段的公钥。
要使中间人攻击起作用，您需要知道 DH 共享密钥。您不能简单地替换 DH 参数。交换的值是 g x mod p 和 g y mod p。你需要知道x或y。这些不容易计算，因为您需要对（应该是）非常大的数字执行离散日志。
您可以尝试冒充谈判的一方，但这并不是真正的中间人。并且 IKEv2 不能防止这种类型的攻击。那将是防火墙规则的工作，什么不是。