IPSec之IKEV2协商过程解析

IKEv2协商流程

IKEv2交换的初始阶段

实际上，IKEv2只有两个初始协商阶段：

  • IKE_SA_INIT交换
  • IKE_AUTH交换

IKE_SA_INIT交换:

1
2
3
4
 Initiator                                  Responder
-----------                                -----------
HDR, SAi1, KEi, Ni          -->
                            <--    HDR, SAr1, KEr, Nr, [CERTREQ]

带COOKIE notify：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 Initiator                          Responder
-----------                        -----------
HDR(A,0), SAi1, KEi, Ni   -->

                          <-- HDR(A,0), N(COOKIE)

HDR(A,0), N(COOKIE), SAi1, KEi, Ni   -->

                          <-- HDR(A,B), SAr1, KEr, Nr, [CERTREQ]

HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,]
    AUTH, SAi2, TSi, TSr} -->

                          <-- HDR(A,B), SK {IDr, [CERT,] AUTH,
                                         SAr2, TSi, TSr}
  1. IKE_SA_INIT是对等体在其中建立安全信道的初始交换。完成初始交换后，所有进一步的交换都将加密。交换仅包含两个数据包，因为它将IKEv1中通常在MM1-4中交换的所有信息合并在一起。因此，响应方处理IKE_SA_INIT数据包的计算成本很高，可以离开以处理第一个数据包；它使协议对欺骗地址的DOS攻击保持开放。
  2. 为了防止此类攻击，IKEv2在IKE_SA_INIT内有一个可选交换，以防止欺骗攻击。如果达到不完整会话的特定阈值，响应方不会进一步处理数据包，而是使用cookie向发起方发送响应。要使会话继续，发起方必须重新发送IKE_SA_INIT数据包并包括其收到的cookie。
  3. 发起方重新发送初始数据包以及响应方的通知负载，证明原始交换未欺骗。

IKE_AUTH交换

1
2
3
4
5
6
7
 Initiator                                  Responder
-----------                                -----------
HDR, SK {IDi, [CERT,]
[CERTREQ,] [IDr,]
AUTH, SAi2, TSi, TSr}       -->
                            <--    HDR, SK {IDr, [CERT,] AUTH,
                                        SAr2, TSi, TSr}
  1. 在IKE_SA_INIT交换完成后，IKEv2 SA被加密；但是，远程对等体尚未通过身份验证。IKE_AUTH交换用于对远程对等体进行身份验证并创建第一个IPsec SA。
  2. 交换包含互联网安全关联和密钥管理协议(ISAKMP)ID以及身份验证负载。身份验证负载的内容取决于身份验证方法，身份验证方法可以是预共享密钥(PSK)、RSA证书(RSA-SIG)、椭圆曲线数字签名算法证书(ECDSA-SIG)或EAP。除身份验证负载外，交换还包括描述要创建的IPsec SA的SA和流量选择器负载。

更新IKEv2交换

CREATE_CHILD_SA交换

1
2
3
4
5
6
 Initiator                                 Responder
-----------                               -----------
 HDR, SK {[N], SA, Ni, [KEi],
     [TSi, TSr]}              -->
                              <--    HDR, SK {SA, Nr, [KEr],
                                         [TSi, TSr]}
  1. 如果需要其他子SA，或者如果需要重新键入IKE SA或其中一个子SA，则它的功能与快速模式交换在IKEv1中的功能相同。每重新生成密钥或新SA都会重复交换。

INFORMATIONAL交换

1
2
3
4
 Initiator                        Responder
-----------                      -----------
 HDR, SK {[N,] [D,] [CP,] ...} -->
                             <-- HDR, SK {[N,] [D,] [CP], ...}
    1. 由于它在所有IKEv2交换中，每个信息交换请求都需要响应。信息交换中可包含三种负载类型。可以包括任意数量的负载组合。
    1. 删除负载(D)通知对等体发送方已删除一个或多个传入SA。响应方应删除这些SA，并且通常在响应消息中包括在另一方向对应的SA的删除负载。
    1. 配置负载(CP)用于在对等体之间协商配置数据。CP的一个重要用途是请求（请求）和在受安全网关保护的网络上分配（响应）地址。在典型情况下，移动主机在其家庭网络上建立具有安全网关的虚拟专用网络(VPN)，并请求在家庭网络上为其分配IP地址。
    • 注意：这可消除第2层隧道协议(L2TP)和IPsec的组合使用所要解决的问题之一。

密钥材料计算

长度不够，重复计算来凑：

1
2
3
4
5
6
7
prf+ (K,S) = T1 | T2 | T3 | T4 | ...

 where:
 T1 = prf (K, S | 0x01)
 T2 = prf (K, T1 | S | 0x02)
 T3 = prf (K, T2 | S | 0x03)
 T4 = prf (K, T3 | S | 0x04)

各密钥计算：

1
2
3
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 )
  • SKEYSEED: 用于计算其他七个秘密。
  • SK_d: 用于为使用此IKE_SA建立的子SA导出新密钥。
  • SK_ai和SK_ar: 用作完整性保护算法的密钥，用于验证后续交换的组件消息。
  • SK_ei和SK_er: 用于加密（当然还有解密）所有后续交换。
  • SK_pi和SK_pr: 它们在生成身份验证有效负载时使用。

IKEv1和IKEv2有哪些区别

1. 协商过程不同

  • IKEv1协商安全联盟主要分为两个阶段。IKEv1阶段1的目的是建立IKE SA，它支持两种协商模式：主模式和野蛮模式。主模式用6条ISAKMP消息完成协商。野蛮模式用3条ISAKMP消息完成协商。野蛮模式的优点是建立IKE SA的速度较快。但是由于野蛮模式密钥交换与身份认证一起进行无法提供身份保护。IKEv1阶段2的目的就是建立用来传输数据的IPSec SA，通过快速交换模式（3条ISAKMP消息）完成协商。
  • IKEv2简化了安全联盟的协商过程。IKEv2正常情况使用2次交换共4条消息就可以完成一个IKE SA和一对IPSec SA，如果要求建立的IPSec SA大于一对时，每一对SA只需额外增加1次交换，也就是2条消息就可以完成。

2. 认证方法不同

  • IKEv2支持EAP身份认证。IKEv2可以借助认证服务器对远程接入的PC、手机等进行身份认证、分配私网IP地址。
  • IKEv1无法提供此功能，必须借助L2TP来分配私网地址。

3. IKE SA的完整性算法支持情况不同

  • IKE SA的完整性算法仅IKEv2支持。
  • IKEv1不支持。

4. DPD中超时重传实现不同

  • retry-interval参数仅IKEv1支持。表示发送DPD报文后，如果超过此时间间隔未收到正确的应答报文，DPD记录失败事件1次。当失败事件达到5次时，删除IKE SA和相应的IPSec SA。直到隧道中有流量时，两端重新协商建立IKE SA。
  • 对于IKEv2方式的IPSec SA，超时重传时间间隔从1到64以指数增长的方式增加。在8次尝试后还未收到对端发过来的报文，则认为对端已经下线，删除IKE SA和相应的IPSec SA。

5. IKE SA超时时间手工调整功能支持不同

  • IKEv2的IKE SA软超时为硬超时的9/10±一个随机数，所以IKEv2一般不存在两端同时发起重协商的情况，故IKEv2不需要配置软超时时间。

6. IPSec SA超时时间手工调整功能支持不同

  • IKEv2的IKE SA软超时为硬超时的9/10±一个随机数，所以IKEv2一般不存在两端同时发起重协商的情况，故IKEv2不需要配置软超时时间。

strongswan配置IKEv2

参考