IKEv2的认证数据生成过程

在IKEv2的第三个消息和第四个消息中，双方都会向对方发送一个AUTH Payload来证明自己的身份。这个过程是通过对各自发送的第一个消息进行签名来实现的。比如，如果一个Responder想证明自己的身份，那么，当它发送IKE_SA_INIT消息时，需要把这个消息完整的缓存下来。然后在发送IKE_SA_AUTH之前，将缓存的IKE_SA_INIT消息和Nonce_I，以及它自身的ID的MAC值连接到一起，再用PRF算法算出一个结果，便是AUTH值。

如下：

1. 计算自己的ID MAC

MACedIDForR =prf( SK_pr, IDType | RESERVED | RespIDData )

2.     计算AUTH值

AUTH_DATA = prf( SK_pr, RealMessage2 | NonceIData |MACedIDForR )

这里RealMessage2代表Responder发送的IKE_SA_INIT消息，因为它在所有的消息序列中是第二个消息，所以叫RealMessage2。NonceIData是Initiator发过来的Nonce值。

 

类似的，Initiator计算AUTH DATA过程如下：

3.     计算自己的ID MAC

MACedIDForI =prf( SK_pi, IDType | RESERVED | InitIDData )

4.     计算AUTH值

AUTH_DATA = prf( SK_pi, RealMessage1 | NonceRData |MACedIDForI )

这里RealMessage1代表Initiator发送的IKE_SA_INIT消息，NonceRData是Responder发过来的Nonce值。

 

但是如果双方选择的认证方式是共享密钥，那么计算AUTH DATA时会有一点区别：

  For the initiator:

     AUTH = prf( prf(Shared Secret, "Key Pad forIKEv2"),

                      <InitiatorSignedOctets>)

  For the responder:

     AUTH = prf( prf(Shared Secret, "Key Pad forIKEv2"),

                      <ResponderSignedOctets>)

 

在计算最终的AUTH DATA时，如果认证方式是Pre-shared key，那么prf算法的第一个参数将不再使用SK_pi/SK_pr，而是用prf( Shared Secret, “Key Pad for IKEv2” )作为prf的密钥。

 

最后一点是关于EAP的，如果双方协商使用EAP认证，那么EAP过程结束后，双方还会发送AUTH消息。如果使用的EAP方法是key-generation的，那么在计算AUTH DATA时必须用MSK (Master Shared Key) 来替换共享密钥。如果是non-key-generating方法，那么用SK_pi和SK_pr来替换共享密钥。