IPSec IKEv1&IKEv2

---

IKE简介

IKE概述

因特网密钥交换IKE（Internet Key Exchange）协议建立在Internet安全联盟和密钥管理协议ISAKMP定义的框架上，是基于UDP（User Datagram Protocol）的应用层协议。它为IPSec提供了自动协商密钥、建立IPSec安全联盟的服务，能够简化IPSec的配置和维护工作。

IKE与IPSec的关系如图1所示，对等体之间建立一个IKE SA完成身份验证和密钥信息交换后，在IKE SA的保护下，根据配置的AH/ESP安全协议等参数协商出一对IPSec SA。此后，对等体间的数据将在IPSec隧道中加密传输。

IKE SA是一个双向的逻辑连接，两个对等体间只建立一个IKE SA。

IKE版本

IKE协议分IKEv1和IKEv2两个版本。IKEv2与IKEv1相比有以下优点：

• 简化了安全联盟的协商过程，提高了协商效率。
• IKEv1使用两个阶段为IPSec进行密钥协商并建立IPSec SA：第一阶段，通信双方协商和建立IKE本身使用的安全通道，建立一个IKE SA；第二阶段，利用这个已通过了认证和安全保护的安全通道，建立一对IPSec SA。IKEv2则简化了协商过程，在一次协商中可直接生成IPSec的密钥并建立IPSec SA。IKEv1和IKEv2的具体协商过程请分别参见IKEv1协商安全联盟的过程和IKEv2协商安全联盟的过程。
• 修复了多处公认的密码学方面的安全漏洞，提高了安全性能。

IKE协商

IKE的三个组件

• SKEME：定义如何通过公共密钥技术（DH算法）实现密钥交换。
• Oakley：提供了IPSec对各种技术的支持，例如对新的加密与散列技术，但并没有具体的定义使用什么样的技术。
• ISAKMP：定义了消息交换的体系结构，包括两个IPSec对等体间分组形态和状态转变（定义封装格式和协商包交换的方式）。

IKEv1协商安全联盟的过程

采用IKEv1协商安全联盟主要分为两个阶段：第一阶段，通信双方协商和建立IKE协议本身使用的安全通道，即建立一个IKE SA；第二阶段，利用第一阶段已通过认证和安全保护的安全通道，建立一对用于数据安全传输的IPSec安全联盟。

IKEv1协商阶段1

IKEv1协商阶段1的目的是建立IKE SA。IKE SA建立后对等体间的所有ISAKMP消息都将通过加密和验证，这条安全通道可以保证IKEv1第二阶段的协商能够安全进行。

两个对等体间只有一个IKE SA，它是一个双向逻辑连接。

IKEv1协商阶段1支持两种协商模式：主模式（Main Mode）和野蛮模式（Aggressive Mode）。

主模式包含三次双向交换，用到了六条ISAKMP信息，协商过程如图1所示。这三次交换分别是：

1. 消息①和②用于提议交换
   发起方发送一个或多个IKE安全提议，响应方查找最先匹配的IKE安全提议，并将这个IKE安全提议回应给发起方。匹配的原则为协商双方具有相同的加密算法、认证算法、认证方法和Diffie-Hellman组标识。
2. 消息③和④用于密钥信息交换
   双方交换Diffie-Hellman公共值和nonce值，用于IKE SA的认证和加密密钥在这个阶段产生。
3. 消息⑤和⑥用于身份和认证信息交换（双方使用生成的密钥发送信息），双方进行身份认证和对整个主模式交换内容的认证。

• Efficient VPN仅支持野蛮模式。
• IKE安全提议指IKE协商过程中用到的加密算法、认证算法、Diffie-Hellman组及认证方法等。
• nonce是个随机数，用于保证IKE SA存活和抗重放攻击。

野蛮模式只用到三条信息

1. 消息①和②用于协商IKE安全提议，交换Diffie-Hellman公共值、必需的辅助信息（与密钥生成相关信息）以及身份信息。
2. 消息②中对收到的第一个数据包进行确认，查找并返回匹配的参数，密钥生成信息和身份验证信息。
3. 消息③用于响应方认证发起方，并建立IKE SA。

IKEv1协商阶段1的协商过程如图1所示。

图1 IKEv1协商阶段1的协商过程图

与主模式相比，野蛮模式减少了交换信息的数目，提高了协商的速度，但是没有对身份信息进行加密保护。

野蛮模式适用场景

与主模式相比，野蛮模式减少了交换信息的数目，提高了协商的速度，但是没有对身份信息进行加密保护。虽然野蛮模式不提供身份保护，但他可以满足某些特定的网络环境需求。

• 当IPSec隧道中存在NAT设备时，需要用到NAT穿越功能，而NAT转换会改变对等体的IP地址，由于野蛮模式不依赖于IP地址标识身份，使得采用预共享秘钥验证方法时，NAT穿越只能在野蛮模式中实现。
• 如果发起方的IP地址不固定或者无法预先知道，而双方都希望采用预共享秘钥的方法来创建IKE SA，则只能采用野蛮模式。
• 如果发起方已知响应方的策略，或者对响应者的策略有全面的了解，采用野蛮模式更快。

IKEv1协商阶段2

IKEv1协商阶段2的目的就是建立用来安全传输数据的IPSec SA，并为数据传输衍生出密钥。这一阶段采用快速模式（Quick Mode）。该模式使用IKEv1协商阶段1中生成的密钥对ISAKMP消息的完整性和身份进行验证，并对ISAKMP消息进行加密，故保证了交换的安全性。IKEv1协商阶段2的协商过程如图2所示。

图2 IKEv1协商阶段2的协商过程图

IKEv1协商阶段2通过三条ISAKMP消息完成双方IPSec SA的建立：

1. 协商发起方发送本端的安全参数和身份认证信息。

   安全参数包括被保护的数据流和IPSec安全提议等需要协商的参数。身份认证信息包括第一阶段计算出的密钥和第二阶段产生的密钥材料等，可以再次认证对等体。

IPSec安全提议指IPSec协商过程中用到的安全协议、加密算法及认证算法等。

2. 协商响应方发送确认的安全参数和身份认证信息并生成新的密钥。

   IPSec SA数据传输需要的加密、验证密钥由第一阶段产生的密钥、SPI、协议等参数衍生得出，以保证每个IPSec SA都有自己独一无二的密钥。

   如果启用PFS，则需要再次应用DH算法计算出一个共享密钥，然后参与上述计算，因此在参数协商时要为PFS协商DH密钥组。

3. 发送方发送确认信息，确认与响应方可以通信，协商结束。

IKEv2协商安全联盟的过程

采用IKEv2协商安全联盟比IKEv1协商过程要简化的多。要建立一对IPSec SA，IKEv1需要经历两个阶段：“主模式＋快速模式”或者“野蛮模式＋快速模式”，前者至少需要交换9条消息，后者也至少需要6条消息。而IKEv2正常情况使用2次交换共4条消息就可以完成一对IPSec SA的建立，如果要求建立的IPSec SA大于一对时，每一对IPSec SA只需额外增加1次创建子SA交换，也就是2条消息就可以完成。

IKEv2定义了三种交换：初始交换（Initial Exchanges）、创建子SA交换（Create_Child_SA Exchange）以及通知交换（Informational Exchange）。

IKEv2中所有消息都以 “请求-响应” 的形式出现，响应方对发起方的消息进行确认，如果在规定的时间内没有收到确认报文，发起方需要对报文进行重传处理，提高了安全性。

IKEv2还可以防御拒绝服务Dos（Denial of service）攻击，在IKEv1中，当网络中攻击方一直重放消息，响应方需要通过计算后，对其进行响应而消耗设备资源，造成对响应方的Dos攻击，在IKEv2中，响应方收到请求后，并不急于计算，而是先向发起方发送一个Cookie类型的Notify载荷（即一个特定的数值)，两者之后的通信必须保持Cookie与发起方之间的对应关系，有效防御了Dos攻击。

初始交换

正常情况下，IKEv2通过初始交换就可以完成第一对IPSec SA的协商建立。IKEv2初始交换对应IKEv1的第一阶段，初始交换包含两次交换四条消息，如图1所示。

图1 初始交换过程图

消息①和②属于第一次交换（称为IKE_SA_INIT交换），以明文方式完成IKE SA的参数协商，包括协商加密和验证算法，交换临时随机数和DH交换。IKE_SA_INIT交换后生成一个共享密钥材料，通过这个共享密钥材料可以衍生出IPSec SA的所有密钥。

消息③和④属于第二次交换（称为IKE_AUTH交换），以加密方式完成身份认证、对前两条信息的认证和IPSec SA的参数协商。IKEv2支持RSA签名认证、预共享密钥认证以及扩展认证方法EAP（Extensible Authentication Protocol）。发起者通过在消息3中省去认证载荷来表明需要使用EAP认证。

创建子SA交换

当一个IKE SA需要创建多对IPSec SA时，需要使用创建子SA交换来协商多于一对的IPSec SA。另外，创建子SA交换还可以用于IKE SA的重协商。

创建子SA交换包含一个交换两条消息，对应IKEv1协商阶段2，交换的发起者可以是初始交换的协商发起方，也可以是初始交换的协商响应方。创建子SA交换必须在初始交换完成后进行，交换消息由初始交换协商的密钥进行保护。

类似于IKEv1，如果启用PFS，创建子SA交换需要额外进行一次DH交换，生成新的密钥材料。生成密钥材料后，子SA的所有密钥都从这个密钥材料衍生出来。

通知交换

运行IKE协商的两端有时会传递一些控制信息，例如错误信息或者通告信息，这些信息在IKEv2中是通过通知交换完成的，如图2所示。

通知交换必须在IKE SA保护下进行，也就是说通知交换只能发生在初始交换之后。控制信息可能是IKE SA的，那么通知交换必须由该IKE SA来保护进行；也可能是某子SA的，那么该通知交换必须由生成该子SA的IKE SA来保护进行。

图2 通知交换过程图

IKE安全机制

IKE具有一套自保护机制，可以在网络上安全地认证身份、分发密钥、建立IPSec SA：

• 身份认证

  身份认证确认通信双方的身份（对等体的IP地址或名称），包括预共享密钥PSK（pre-shared
  key）认证、数字证书RSA（rsa-signature）认证。

Efficient VPN仅支持预共享密钥认证。

• 在预共享密钥认证中，通信双方采用共享的密钥对报文进行Hash计算，判断双方的计算结果是否相同。如果相同，则认证通过；否则认证失败。

  当有1个对等体对应多个对等体时，需要为每个对等体配置预共享的密钥。该方法在小型网络中容易建立，但安全性较低。

• 在数字证书认证中，通信双方使用CA证书进行数字证书合法性验证，双方各有自己的公钥（网络上传输）和私钥（自己持有）。发送方对原始报文进行Hash计算，并用自己的私钥对报文计算结果进行加密，生成数字签名。接收方使用发送方的公钥对数字签名进行解密，并对报文进行Hash计算，判断计算结果与解密后的结果是否相同。如果相同，则认证通过；否则认证失败。

  使用数字证书安全性高，但需要CA来颁发数字证书，适合在大型网络中使用。

IKE支持的认证算法有：SHA2-256。

• 身份保护

  身份数据在密钥产生之后加密传送，实现了对身份数据的保护。

  IKE支持的加密算法有：3DES、AES-128、AES-192、AES-256。

• DH

  DH是一种公共密钥交换方法，它用于产生密钥材料，并通过ISAKMP消息在发送和接收设备之间进行密钥材料交换。然后，两端设备各自计算出完全相同的对称密钥。该对称密钥用于计算加密和验证的密钥。在任何时候，通信双方都不交换真正的密钥。DH密钥交换是IKE的精髓所在。

• PFS

  完善的前向安全性PFS（Perfect Forward Secrecy）通过执行一次额外的DH交换，确保即使IKE SA中使用的密钥被泄露，IPSec SA中使用的密钥也不会受到损害。

身份认证

• 在预共享密钥认证中，认证字作为一个输入来产生密钥，通信双方采用共享的密钥对报文进行Hash计算，判断双方的计算结果是否相同。如果相同，则认证通过；否则认证失败。
• 在数字证书认证中，通信双方使用CA证书进行数字证书合法性验证，双方各有自己的公钥（网络上传输）和私钥（自己持有）。发送方对原始报文进行Hash计算，并用自己的私钥对报文计算结果进行加密，生成数字签名。接收方使用发送方的公钥对数字签名进行解密，并对报文进行Hash计算，判断结果与解密的结果是否相同，相同则认证通过；否则认证失败。
• 在数字信封认证中，发送方首先随机产生一个对称密钥，使用接收方的公钥对此对称密钥进行加密（被公钥加密的对称密钥称为数字信封），发送方用对称密钥加密报文，同时用自己的私钥生成数字签名。接收方用自己的私钥解密数字信封得到对称密钥，再用对称密钥解密报文，同时根据发送方的公钥对数字签名进行解密，验证发送方的数字签名是否正确。如果正确，则认证通过；否则认证失败。

DH（Diffie-Hellman）密钥交换算法

DH算法是一种公开密钥算法。通信双方在不传送密钥的情况下通过交换一些数据，计算出共享的密钥。即时第三方截获了双方用于计算密钥的所有交换数据，也不足以计算出真正的密钥。DH保证了IKE不在网络上直接传输密钥，而是通过一系列数据交换，最终计算出双方共享的密钥。但DH没有提供双方身份的任何信息，不能确定交换的数据是否发送给合法方，第三方可以通过截获的数据与通信双方都协商密钥、共享通信，从而获取和传递信息，所以IKE需要身份认证对对等体身份进行认证。

密钥材料交换完成后，IKE peer 双方结合自身配置的身份验证方法各自开始复杂的密钥计算过程（预共享秘钥或数字证书都会参与到密钥计算过程中），最终会产生三个密钥（SKEYID为基础密钥，由其推导出其它三个密钥）：

• SKEYID_a：ISAKMP消息完整性验证密钥–谁也别想篡改ISAKMP消息了，只要消息稍微有改动，响应端完整性检查就会发现。

• SKEYID_e：ISAKMP消息加密密钥–再也别想窃取ISAKMP消息了，窃取了也看不懂

  以上两个密钥保证了后续交换的ISAKMP消息的安全性。

• SKEYID_d：用于衍生出IPSec报文加密和验证密钥–最终是由这个密钥保证IPSec封装的数据报文的安全性。

整个密钥交换和计算过程在IKE SA超时时间的控制下以一定的周期自动刷新，避免了密钥长期不变带来的安全隐患。

IPSec增强原理

IPSec多实例

IPSec多实例主要用于向小企业提供防火墙租赁业务和实现企业内部网络隔离。

如图1所示，三个小企业的总部共用一台VPN网关。三个企业之间需要保持网络独立，互相之间不会产生影响。三个企业的总部内部网络IP地址是各自规划的，可能出现IP地址重叠（即不同私网出现使用相同IP地址的情况），此时需要在网关上应用IPSec多实例功能，将三个企业的IPSec隧道与三个IPSec多实例绑定，保证相同IP地址的报文能够正确转发。

图1 IPSec多实例典型组网

< Home

Efficient VPN

IPSec VPN技术以其高度的安全性、可靠性以及灵活性成为企业构建其VPN网络的首选。在包含大量分支的IPSec应用中，用户希望各个分支网关的配置能够尽量简单，而复杂的配置集中在总部网关上。Efficient VPN可以解决IPSec VPN分支配置复杂的问题。

Efficient VPN采用Client/Server结构。它将IPSec及其它相应配置集中在Server端（总部网关），当Remote端（分支网关）配置好基本参数时，Remote端发起协商并与Server端建立起IPSec隧道，然后Server端将IPSec的其它相关属性及其他网络资源推送给Remote端，简化了分支网关的IPSec和其他网络资源的配置和维护。

运行模式

• Client模式

  1.Remote端向Server端申请IP地址，同时Remote端自动创建一个LoopBack接口，将从Server端获取的IP地址应用到该LoopBack接口上。

  LoopBack接口满规格时，设备无法自动创建一个LoopBack接口。

  2.Remote端用获取的IP地址与总部建立IPSec隧道。

  Client模式一般用于小的分支机构通过私网接入总部网络，如图1所示。

图1 Client模式

• Network模式

  Network模式中Remote端不会向Server端申请IP地址。

  Network模式一般用于分支和总部IP地址已统一规划的场景，需要考虑IP地址的规划，各个区域的IP地址不能重叠。

• Network-plus模式

  与Network模式相比，Network-plus模式中Remote端还会向Server端申请IP地址。这时分支和总部IP地址已统一规划，但Remote端仍会向Server端申请IP地址，获取的IP地址只用于总部对分支进行Ping、STelnet等管理维护。

Server端除了推送IPSec隧道建立的参数，还可以实现以下资源的推送：

• DNS域名、DNS服务器地址、WINS服务器地址等网络资源

  Server端通过对以上资源的推送，实现分支访问总部的服务器资源。

• ACL推送

  Server端将使用ACL定义的总部网络信息推送给Remote端，限定了允许分支子网访问的总部子网范围，目的地不在ACL定义的网络信息范围内的分支子网流量将不会经过IPSec隧道，正常访问Internet。