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来替换共享密钥。