一、IKE简介
IKE是要建立一个Security Association（SA）用于IPsec，也就是传后面的AH、ESP包。
IKE使用了一种很独特的设计，他先建立第一个ISAKMP SA安全通道，这是阶段一，然后阶段二在这个已经建立的安全通道下，协商用于IPsec的SA。这种设计理念我目前还不能完全理解。
网上找的这个图很形象
第一个SA里面包含了一系列的参数，例如认证算法、加密算法、密钥等等。用来保护IKE本身的通信。
二、IKE过程
下面看看过程
1.Phase 1
主要分为三个步骤，1协商SA，2交换密钥，3认证
分两种模式，主模式和激进模式，主模式每个步骤双方各发一条消息，共6条消息，激进模式有将信息合并，一共三条消息。
分四种认证方法
a.Authenticated With Signatures
b.Authenticated With Public Key Encryption
c.Authenticated With a Revised Mode of Public Key Encryption
d.Authenticated With a Pre-Shared Key
还有几个其他的模式不看了，用的时候再去查RFC2409
下面梳理下一阶段的过程
1.发送者发送一个协商请求，附上自己的SPI**(Security Parameter Index)**，SPI是单向的，就类似于自己的安全通信策略数据库的一个索引，通过SPI来在自己的数据库里索引唯一的一组参数，认证算法、加密算法、密钥等等。
这个消息里还会有DOI（Domain of interpretation），这个字段指明了一个规则，表明接下里的参数协商使用什么样的规则。比如这个字段可能是1，代表是下面的参数协商使用IPsec的规则。
接下来他会一个或多个Transform Payload，每个Transform载荷是一组安全参数，发送过去供接收方选择。
这是一个例子，里面的参数有加密算法：AEC-CBC，密钥长度128位，哈希算法SHA，Group-Description指定了某一个DH组，里面有DH的两个参数，大素数和本原根，下一个是认证方式，预共享密钥，这个也可能是数字证书PKI，后面两个参数规定了这次协商出来的SA的时间。
2.接收方收到之后，会附上自己的SPI，选一个transform组，回回去。
3.这样参数都有了，三四步就可以开始交换密钥了。
这里看文档（RFC 2409），我理解的是，先用基本的DH来交换以获得一个共同秘密，这里并没有做认证，所以面临中间人攻击，但是他在后续做了认证。在获得这个共享秘密（g^xy）之后，用这个共享秘密和双方的其他认证信息来生辰一个密钥SKEYID，数字签名、公钥算法、提前分享的密钥三种认证方式生成密钥的方式不同，如下所示：
For signatures: SKEYID = prf(Ni_b | Nr_b, g^xy)
For public key encryption: SKEYID = prf(hash(Ni_b | Nr_b), CKY-I | CKY-R)
For pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b | Nr_b)有了这个SKEYID之后，在根据这个和共享秘密等在生成真正的三组加密不同信息的密钥：
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)这三组密钥用来加密不同的信息，e用来加密正常消息，a用来认证，d用来处理非ISAKMP的SA。
4.最后两条消息是双方验证身份，这里就是用刚才生成的密钥加密的通信了
这里看一个使用签名的例子，如果是要用签名来认证，那么一开始的两条就需要交换公钥，比如通过证书。
Initiator Responder
----------- -----------
HDR, SA -->
<-- HDR, SA
HDR, KE, Ni -->
<-- HDR, KE, Nr
HDR*, IDii, [ CERT, ] SIG_I -->
<-- HDR*, IDir, [ CERT, ] SIG_R前两条就是协商SA，第三四条交换密钥，KE就是要交换的DH公钥，两个N就是随机数，这两个随机数看上面有用于计算接下来的密钥。
最后两条认证，ID就是身份信息，CERT证书可选，SIG是用以下算出来的HASH，对他签名，这个hash的计算包含了双方的DH公私钥，以及刚用DH公共秘密算出来的SKEYID，以及双方的cookie，SAi是整个SA载荷的body，ID就是身份。他们分别会对这些做hash，然后用自己的私钥签名，然后发给对方。
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 )现在设想有个中间人，他可以劫持前两条消息，获得两边的cookie，然后劫持第三四条消息，使用典型的中间人攻击，自己生成两个公私钥对，分别用他们和A和B交换秘密，也自己生成两个随机数，发给a和b，以计算接下来的那一串SKEYID。算出来两对密钥，那他们分别在第五六条和A和B做认证。身份信息可以伪造，签名是用私钥签名的哈希，中间人没法生成这个，对面比如A拿到后，用B的公钥解不开，那就发现不对了，那么中间人攻击就失败了。
上面说的是主模式，还有一种是激进模式，还是看个例子，使用签名的激进模式。
Initiator Responder
----------- -----------
HDR, SA, KE, Ni, IDii -->
<-- HDR, SA, KE, Nr, IDir,
[ CERT, ] SIG_R
HDR, [ CERT, ] SIG_I -->直接在前两条消息就把DH的密钥交换了，而且接收方在第二条也发送了认证消息，这样第三条发送方发的认证消息就是最后一条了。
这样，一阶段就结束了。
2.phase 2
二阶段就是要在刚才建立的SA里建一条用于接下来传真正的ip包的SA
Initiator Responder
----------- -----------
HDR*, HASH(1), SA, Ni
[, KE ] [, IDci, IDcr ] -->
<-- HDR*, HASH(2), SA, Nr
[, KE ] [, IDci, IDcr ]
HDR*, HASH(3) --> HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr )
HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci |
IDcr )
HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b)首先发起者要发协商消息，第一个hash就是用之前协商好的SKEYID_a，和（这条消息的头里的message id和包里剩下所有内容的连接），做的HMAC，然后SA就是发起者提出的很多Transform，一个Transform就是一套规则，Ni是随机数，剩下两个KE是可选的，可以再进行一次密钥协商，后面那个没看懂，也是可选的。
响应者同样会回一个选好SA的包，只有一个Transform，这个包很类似，hash2里面还包含了刚才发来的随机数。
最后，发起者收到之后，会回一个类似ACK的东西，里面就是哈希过的message id和两个随机数。
注意这些消息都是加密的，除了ISAKMP的头不加密，剩下的内容都是用刚才的SKEYID_e来加密的。所以这些协商都提供了完整性和机密性保护。
这个SA里协商了之后AH和ESP需要的信息。