Answers:
你问了一个好问题。这个问题看似很简单，但实际上答案却有些复杂。我会尽力简洁地回答。另外，由于您提到了ISAKMP，因此我假设您对IKEv1感兴趣。IKEv2发生了一些变化（嗯，很多），但是我确实想提一下下面的答案仅与IKEv1相关。
阶段1可以通过两种不同的模式来完成：主模式和积极模式。在任何一种模式下，第一条消息都是由发起方发送的，第二条消息是由响应方发送的。这两个消息都包括在密码学界称为Nonce的消息。随机数只是用于密钥生成的随机生成的数字。 （术语Nonce来自使用_Once_的_N_umber）。因此，在消息1和消息2之后，双方都知道彼此的随机数。
Nonce与Pre-Shared-Key组合在一起以创建用于生成密钥的Seed值。IKE RFC的相对部分在这里：
For pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b | Nr_b)
SKEYID是种子值，以后将用于生成其他秘密密钥。通过使用PRF或伪随机函数将预共享密钥和两个Nonce值（Ni_b是发起方的Nonce，Nr_B是响应方的Nonce）组合在一起。PRF类似于哈希算法，不同之处在于结果可以是所需的任意多的位。
现在，如果您最初是在进入主模式，则消息3和消息4分别共享发起者和响应者的Diffie-Hellman公钥。他们都使用这些值来生成Diffie-Hellman 共享密钥。如果您正在使用积极模式，则这些DH Public值也将包含在消息1和消息2中（以及随机数）。
然后，将Seed值与DH共享机密（以及其他一些值）组合在一起，以创建三个会话密钥：Derevative密钥，Authentication密钥和Encryption密钥。RFC声明如下：
主模式或积极模式的结果是三组经过身份验证的密钥材料：
SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)
SKEYID_d，_a和_e是上面提到的三个会话密钥。 SKEYID是种子值。 g^xy是DH共享秘密。CKY-I并且CKI-R是发起方和响应方Cookie，它们只是其他随机生成的值，这些值稍后将用于标识此特定的ISAKMP交换和安全关联。 0 1 2分别是文字数字0、1和2。“管道”符号|表示串联。
无论如何，所有这些值都使用创建三个会话密钥的PRF组合在一起：
身份验证密钥和加密密钥用于保护/加密随后的阶段2协商。在主模式下，阶段1的消息5和消息6也受这些键保护。此外，任何将来的ISAKMP信息交换（DPD，密钥更新事件，删除消息等）也受这两个密钥保护。
派生密钥已交给IPsec，并且IPsec从此密钥生成自己的密钥材料。如果您还记得，IPsec天生就没有包含密钥交换机制，因此它获取私钥的唯一方法是手动设置它们（这是过时的，现在再也没有做过），或者依赖于外部服务来设置。提供密钥材料，例如ISAKMP。
RFC这样说：
SKEYID_e是ISAKMP SA用于保护其消息的机密性的密钥材料。
SKEYID_a是ISAKMP SA用于验证其消息的密钥材料。
SKEYID_d是用于为非ISAKMP安全关联派生密钥的密钥资料。
综上所述，我们可以回头再提您的问题：使用什么密钥来保护预共享密钥？
在主模式下，消息5和消息6中验证了预共享密钥（PSK）。消息5和6受ISAKMP生成的会话密钥保护，如上所述。
在积极模式下，协商中的所有消息均未加密。并且在消息2和消息3中对PSK进行了验证。注意，在这两种情况下，我都说PSK已验证，而我从未说过已交换 PSK 。显然，如果没有加密积极模式下的任何内容，而您只是未经加密地通过网络发送了预共享密钥，则将存在巨大的安全漏洞。
对我们来说幸运的是，ISAKMP的作者已经想到了这一点。结果，他们创建了一种特殊的方法来验证每一方是否具有正确的PSK，而无需实际在线共享。有两个项目可用于向每个对等方验证它们是否都具有相同的PSK：身份方法和身份哈希。
VPN对等方可以选择通过多种方法来标识自己。通常，对等方将仅使用其源IP地址。但是他们可以选择使用FQDN或主机名。这些中的每一个，以及所选方法的相关值，都构成了身份方法。因此，例如，如果我拥有IP 5.5.5.5，并且我想使用自己的IP地址来标识自己，那么我的ID方法实际上就是[IP Address，5.5.5.5]。 （注意：这两个值构成了整个ID方法）
然后将ID方法（使用PRF）与我们之前讨论的Seed值（SKEYID）以及其他一些值结合起来，以创建Identity Hash。回想一下，最初创建SKEYID的是Pre-Shared-Key。
然后通过电线发送ID方法和ID哈希，另一方尝试使用相同的公式重新创建ID哈希。如果接收方能够重新创建相同的ID哈希，则向接收方证明发送方必须具有正确的预共享密钥。
这在RFC中进行了描述：
为了验证任一交换，协议的发起者生成HASH_I，响应者生成HASH_R，其中：
HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b ) HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b )
IDii和IDir是ID方法。HASH_I和HASH_R是发起方和响应方哈希值。这两个都是在阶段1中共享的。从RFC：
在进行预共享密钥身份验证时，主模式定义如下：
Initiator Responder ---------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, Ni --> <-- HDR, KE, Nr HDR*, IDii, HASH_I --> <-- HDR*, IDir, HASH_R带有预共享密钥的积极模式描述如下：
Initiator Responder ----------- ----------- HDR, SA, KE, Ni, IDii --> <-- HDR, SA, KE, Nr, IDir, HASH_R HDR, HASH_I -->
现在，我们终于可以完全回答您的问题：
使用带有随机数的PRF和在协商中其他任何人都知道的其他值组合来组合预共享密钥。结果是，只有当双方以相同的值（也就是相同的预共享密钥）开始时，双方才能相互获得一个值。结果值是在线上共享的值，允许双方验证它们是否具有匹配的预共享密钥，而无需实际公开有关预共享密钥本身的任何信息。
通过对上述“结果值”的交换进行加密，“主模式”更安全了一步，这使得提取有关“预共享密钥”的任何有用信息变得更加困难。
（看来我很遗憾未能简洁回答）
您的问题就在您的答案中：Diffie-Hellman交换用于生成公共密钥，以安全地交换公共密钥（即预共享）。
看到这个：https : //security.stackexchange.com/questions/67953/understanding-diffie-hellman-key-exchange