您的所有问题都已在您的原始问题中得到解答。

在主模式下，预共享密钥 (PSK) 在消息 5 和 6 中进行验证。消息 5 和 6 受 ISAKMP 生成的会话密钥保护，如上所述。

在积极模式下，协商中的任何消息都不会被加密。并且在消息 2 和 3 中验证了 PSK。注意，在这两种情况下，我都说 PSK 是经过验证的，而我从未说过 PSK 是交换的。显然，如果在积极模式下没有加密，而您只是通过未加密的线路发送预共享密钥，则会出现巨大的安全漏洞。

幸运的是，ISAKMP 的作者已经想到了这一点。因此，他们创建了一种特殊的方法来验证每一方是否具有正确的 PSK，而无需实际通过网络共享它。有两个项目用于向每个 Peer 验证它们都具有相同的 PSK：Identity Method和Identity Hash。

VPN Peers 可以选择通过多种方式识别自己；最常见的是，对等方将简单地使用它们的源 IP 地址。但他们可以选择使用 FQDN 或主机名。这些中的每一个，连同所选方法的相关值，构成了标识方法。因此，例如，如果我的 IP 为 5.5.5.5，并且我想使用我的 IP 地址来标识自己，那么我的ID 方法实际上将是[IP Address, 5.5.5.5]。 （注意：这两个值构成了整个 ID 方法）

然后将 ID 方法与我们之前讨论的种子值 (SKEYID) 和其他一些值组合（使用 PRF），以创建身份哈希。回想一下，首先创建 SKEYID 的是预共享密钥。

然后通过网络发送 ID 方法和 ID 哈希，另一方尝试使用相同的公式重新创建 ID 哈希。如果接收方能够重新创建相同的 ID 哈希，则向接收方证明发送方必须拥有正确的预共享密钥。

和

在进行预共享密钥认证时，主模式定义如下：

         Initiator                        Responder
        ----------                       -----------
         HDR, SA             -->
                             <--    HDR, SA
         HDR, KE, Ni         -->
                             <--    HDR, KE, Nr
         HDR*, IDii, HASH_I  -->
                             <--    HDR*, IDir, HASH_R

消息 5 是 HDR、IDii 和 HASH_I
消息 6 是 HRD、IDir 和 HASH_R

在我的描述中，IDix 是 ID Method，而 HASH_x 是 ID Hash。里面有什么不合理的吗？

如果 Firewall1 的 IP 为 1.1.1.1，Firewall2 的 IP 为 2.2.2.2，并且它们都使用“Zebra”的预共享密钥，那么消息 5 和消息 6 将包含以下信息：

1.1.1.1                                    2.2.2.2
----------                             -----------
HDR*, IDii, HASH_I   ---5-->
                     <--6---    HDR*, IDir, HASH_R

消息 5 将包括：

• IDii，实际上是[IP Address, 1.1.1.1]。
• HASH_I，它是以下值的哈希：( SEED Value + IDii + Public Values)

消息 6 将包括：

• IDir，实际上是[IP 地址，2.2.2.2]
• HASH_R，它是以下值的哈希：( SEED Value + IDir + Public Values)

上面的公共值是在明文消息 1、2、3 和 4 中交换的值，如果他们在网络上窃听，任何人都可以访问这些值。种子值是哈希的唯一部分，只有拥有原始预共享密钥的人才能知道。作为创建种子值的值之一是字符串“ Zebra ”——也就是预共享密钥。请参见上文，以及有关如何形成的更多详细信息的原始答案。