IPsec IKEv1中预共享密钥下使用标识符进行表示出现的问题

问题描述

如图所示，在IKEv1的主模式下使用标识符的方式而不是使用IP地址的方式去标识IPsec的双端就会导致主模式无法协商完成的情况，其主要原因就是主模式无法根据第一次数据报的交互中找寻到相关的预共享密钥用于后续的密钥生成，所以这就是主模式无法协商成功的原因以及野蛮模式出现的原因。

当使用IKEv2时

和上面的场景一模一样的配置，当我将版本切换成IKEv2后就可以进行正常的交互。

那么为什么IKEv2使用标识符就可以进行正常的交互？IKEv2不是第一阶段产生相关IKE密钥，然后去加密第二阶段的IPsecSA的协商吗？

其本质原因是因为IKEv2在协商IKE密钥的算法和IKEv1的算法不一样，IKEv1预共享密钥下的IKE密钥的生成是需要预共享密钥的，也就是SKYSEED种子密钥是需要预共享密钥这个参数的，但是在IKEv2中SKYSEED种子密钥的所需参数是第一次数据报交互中的Ni和Nr以及DH算法的共享秘密，所以在IKEv2中IKE密钥的生成与预共享密钥解绑，所以即便使用name标识符去标识IPsec的双端也不用担心没有获取到足够的材料去找寻预共享密钥，因为在IKEv2中IKE密钥的生成和预共享密钥并没有什么联系，name标识符和预共享密钥只是在IKEv2的第二协商阶段中用于身份来源标识的一个参数。

 IKEv1下产生的密钥以及相关的用途

 IKEv2下产生的密钥以及相关的用途

IKEv2密钥生成算法

SKEYSEED = prf (Ni | Nr, g^ir)

{ SK_d | SK_ai | SK_ar | SK_ei | SK_er |SK_pi | SK_pr } = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr)

  IKE SA; SK_ai and SK_ar used as a key to the integrity protection algorithm for authenticating the component messages of subsequent exchanges;
（翻译：Sk_ai和Sk_ar主要用于后续数据交换时完整性算法时使用的密钥）
  SK_ei and SK_er used for encrypting (and of course decrypting) all subsequent exchanges;
（翻译：SK_ei和SK_er主要用于后续数据交换中的加密）
  and SK_pi and SK_pr, which are used when generating an AUTH payload. 
（翻译：SK_pi和SK_pr主要用于产生验证载荷，其实就是验证数据来源的作用）
The lengths of SK_d, SK_pi, and SK_pr MUST be the preferred key length of the PRF agreed upon. （翻译：SK_d,SK_pi,SK_pr的密钥长度一定要符合协商好的伪随机函数的长度）

IKEv1和v2密钥的计算详情看这个

(82条消息) IPsec IKEv1 协商（预共享密钥认证，数字签名认证，公钥认证）_Mllllk的博客-CSDN博客_预共享密钥

(82条消息) IKEv2的密钥计算方式_Mllllk的博客-CSDN博客