HCIE-Security Day33：IPSec：深入学习ipsec ikev2、IKEV1和IKEV2比较

ikev2

[RFC 5996 - Internet Key Exchange Protocol Version 2 (IKEv2) (ietf.org)

该文档最初指定于RFC4306版本，并在RFC5996版本中进行了更新。

不兼容IKEV1，ikev1不支持认证，ikev2支持认证，eap。

支持nat穿越

支持私密性、完整性、源认证

工作在UDP500端口NAT-T时使用UDP4500端口。

初始交换

通常情况下，在 IKEv2 中，在进行初始交换后即可实现第一对 IPSec SA 的协商建立过程。这种机制与 IKEv1 的第一阶段相对应，在初始交换阶段总共进行了两次互换共发送了四条消息

数据包①和②属于初次通信过程（称作IKE_SA_INIT通信），在公开传输的渠道上完成IKE SA协议参数的协商工作。该过程涵盖加密算法与认证机制的选择协商，并达成临时随机数与DH参数的交换。该通信结束后将生成共享密钥基础材料，并通过该材料可以推导出IPSec安全套接层的所有密钥。

消息③和④是第二次交换的一部分（称为 IKE_AUTH 交换）。通过加密的方式完成了身份认证，并对前两条信息进行了验证，同时协商了 IPSec SA 的参数。 IKEv2版本支持 RSA 签名认证、预共享密钥认证以及扩展的 EAP 认证方法（即 Extensible Authentication Protocol）。发起方在消息 3 中省略了验证负载，以此来表明将采用 EAP 认证。

RFC4306节选：

使用 IKE 的通信总是从 IKE_SA_INIT 和 IKE_AUTH 交换开始（在 IKEv1 中称为阶段 1）。 这些初始交换通常由四个消息组成，但在某些情况下，数量可能会增加。 所有使用 IKE 的通信都由请求/响应对组成。 我们将首先描述基础交换，然后是变体。 第一对消息 (IKE_SA_INIT) 协商加密算法，交换随机数，并进行 Diffie-Hellman 交换 [DH]。

第二对消息 (IKE_AUTH) 验证先前的消息，交换身份和证书，并建立第一个 CHILD_SA。 这些消息的一部分通过 IKE_SA_INIT 交换建立的密钥进行加密和完整性保护，因此对窃听者隐藏身份，并且所有消息中的所有字段都经过身份验证。

HDR 包括 SPI、版本号以及标志等安全参数。SAi1 载荷使用 IKE_SA 支持的安全协议进行数据保护。KE 载荷则采用 Diffie-Hellman 钥匙作为基础参数。Ni 是由发起者所生成的一个唯一标识符。
响应者从可选的加密套件中挑选出一个，并通过 SAr1 的有效负载来表达这一选择。随后参与与 KEr 相关的有效负载交换过程，在 Nr 的有效装载阶段传递其随机数值。

1.2消息用于初始交换，相当于ike v1主模式的1234消息。

第一个包：发起方提供基本的ike sa参数和密钥交换材料

responder cookie字段初始化为0，在系统中被配置以指示响应式行为。flags字段的初始设置被启用以标识发起方的一端。message_id字段同样初始化为0，并与后续响应端点的message_id字段具有相同的初始设置。该字段用于唯一标识一对请求-响应消息序列。

第二个包：响应方发送匹配的ike sa参数和密钥交换材料

3.4个包是ike-auth

基于ike-sa-init所构建的ike-sa体系之上，在其框架内制定了多种加密算法、认证机制及完整性验证协议等，并以这些协议为基础生成第一个child-sa实例。

双方已达成协议，
每一方均能自主生成SKEYSEED，
基于SKEYSEED生成 IKE_SA的所有密钥。
除消息头信息外，
所有消息均经过双重加密及完整性验证。
这些加密与完整性的核心技术参数来源于SKEYSEED。
分别针对两端设计独特的SK_e与SK_a参数组。
其中一部分参数用于IKE_SA的安全防护，
另外则独立形成另一组参数集合SK_d，
这些参数将被用来构建CHILD_SA的相关密钥基础材料。
符号SK { ... } 表示这些有效载荷经由对应方向上的SK_e与SK_a完成双重加密及完整性验证过程。

发起者通过IDi的有效载荷声明自身身份，并证明与该IDi相关联的秘密知识；该过程还可能在CERT有效负载中传递其证书，并在CERTREQ有效负载中分享信任列表；如果包含CERT有效负载，则第一个证书必须包含用于验证AUTH字段公钥的信息；可选的有效载荷IDr允许发起者指定与其对话的目标响应者的身份；当在同一IP地址托管多个目标时尤为有用；发起者通过SAi2有效负载开始参与CHILD_SA协商过程；从SAi2开始的所有字段描述了CREATE_CHILD_SA交换内容。

响应者通过IDr的有效负载声明自身身份；可选地传递一个或多个证书（再次使用包含用于验证第一个AUTH字段公钥的证书），以确认自身身份并采用AUTH有效负载保护后续消息完整性和利用CREATE_CHILD_SA交换完成目标协商。

消息3和4的接收方必须确保对所有签名及MAC值的计算结果无误，并确认使用的名称标识符与生成AUTH有效负载所使用的密钥一致。

该协议采用双重机制进行数据加密和完整性验证；
该字段存储了发起方的身份认证信息；如果系统没有EAP机制，则会缺少这一字段；
该字段用于描述创建子会话所需的转换参数集合；其中IPsec安全套接框是关键组件；
该选择器决定感兴趣的数据流量；在 IKEv2 中双方会协商确定共同的安全策略；

第三个包（加密）：创建child sa相关的认证内容和参数

相当于ikev1的主模式5和部分快速模式的内容

第四个包（加密）：创建与child sa相关的认证内容和参数

相当于ikev1主模式的第6个包和部分快速模式的包

创建子SA交换

当一个 IKEA 需要建立多个 IPSec 安全套接框时，则必须通过子 IPSec 交换来进行多对的协商。同样地，在进行 IKEA 时也可以利用子 IPSec 交换来进行重新协商。

创建子SA时需要处理两个消息，并与阶段2中的 IKEv1 协商过程相关。在阶段2中进行 IKE 协商时，请注意以下要点：（1）发起方可能来自原始会话双方中的任意一方；（2）该过程应在完成初始会话后实施；（3）所有传递的消息都将采用阶段1协商确定的密钥进行加密传输

类似于 Ikev1 网络架构，在激活 PFS 网关之后，在实现子网间切换时必须执行一次 Diffie-Hellman（DH）交换过程以生产新的密钥数据结构。在完成该过程并获取新密钥之后，在所有子网接入点处的端到端通信参数都将源自于这个新的密钥数据结构中。

RFC 4306 第一部分引文：
子SA建立过程
此过程由单一的一个请求-响应对构成，在 IKEv1 中被定义为第二阶段互换。它可以由 IKE SA 方任一端发起。
所有后续消息均采用 IKE 协议中前两条消息协商确定的加密算法和密钥来进行加密保护。
其中密钥材料是基于 IKE SA 建立时设置的 SK_d、CREATE Child SA 过程中产生的非ces 和 Diffie-Hellman 参数（当携带 KE 加密的有效负载时）。
对于那些作为初始互换组成部分而被创建的 CHILD SA实例，请注意它们不应包含第二个 KE 加密的有效负载或 nonce。
这些附加参数仅用于增强 Child SA 向前保密性保证。
在此场景下使用的随机数将用于计算 Child SA 的相关密钥参数。

发起者通过SA有效载荷传输SA建议，在Ni有效载荷中传输随机数值，在KEi有效载荷中传输可选的Diffie-Hellman数值，并在TSi及TSr有效载荷中建议流量选择器。若该CREATE_CHILD_SA交换正更新除IKE_SA外的现有SA，则应标识正在更新密钥的SA；若未更新现有SA密钥则需省略N有效负载。若SA建议包含不同Diffie-Hellman组别，则KEi必须属于发起方期望响应方能接受的组别；若错判则该CREATE_CHILD_SA交换将失败并需重新尝试。
使用与IKE_SA协商的安全套接字来加密标头后消息并对包含标头的消息实施完整性保护。
若KEi包含于请求中且所选加密套件包含相应组别，则响应方应用接受提议及KEr有效载荷中的Diffie-Hellman值回复（基于相同的消息ID）。若响应方选用不同组别则应拒绝请求；发起方应重传并采用响应方选定组别中的KEi建议。
于该SA上传输的流量流量选择器位于TS有效载荷内指定其可能为CHILD_SA发起者的提议子集；当此CREATE_CHILD_SA请求用于更新IKE_SA密钥时则应忽略流量选择器。

共享密钥的计算过程如下。 SKEYSEED的数量是由 IKE_SA_INIT 交换期间传递的随机数以及该阶段建立的 Diffie-Hellman 共享秘密共同决定的。 SKEYSEED被用来计算其他七个关键：其中SK_d则负责从基于此 IKE_SA 的CHILD_SA中导出新的密钥；而SK_ai和SK_ar则被用作完整性保护算法的关键字，并且同时负责加密（当然还有解密）所有后续会话；此外，在生成AUTH的有效负载时，则分别被用来执行相关任务。

（表示量SK_d SK_ai SK_ar SK_ei SK_er SK_pi SK_pr从prf+生成位开始依次取）。K是由短暂Diffie-Hellman交换产生的共享秘密值。g^ir被表示为一个按大端顺序排列的一个八位字节串，在必要时用零填充使其达到模数所需的总长度。Ni和Nr均为随机数无特定名称定义若协商所采用伪随机场（PRF）使用固定长度密钥且Ni与Nr总位长之和与密钥长度不匹配则必须将Ni贡献的一半二进制位与Nr的一半二进制位结合使用每个来源各提供一位

采用独特的密钥体系分别对两种交通流方向进行加密处理，在确保消息安全性的前提下实现了高效的通信功能。
原始发起者消息的安全性依赖于SK_ai与SK_ei这两个专用密钥。
另一条方向的消息则由SK_ar和SK_er负责加密防护。
所有算法均遵循固定的密钥资源分配原则。
在基于哈希函数的安全完整性机制中所使用的秘钥长度与基础哈希函数输出结果保持一致。

通知交换

双方在进行 IKE 协商时偶尔会发送一些关键数据；这些数据通常包括错误报告和公告消息，并且根据文档规定，在 IKE v2 中采用通知机制来实现数据交换。

为了确保通知交换的安全性，在 IKE SA 的框架下执行是必要的。由此可知，在 IKEA 中心节点完成首次 pairwise 交互后才能展开后续的通知交互。其中一些数据可能直接来源于某个 IKEA 服务实例，并对这些数据流的加密处理则应由生成该服务实例的具体 IkeA 实体负责处理；但在某些复杂场景中还可能出现分层式的 IkeA 架构情况，则应当由负责生成这一服务实例的 IkeA 实体来实施相应的安全防护措施。

ikev1默认不处理远程接入者的认证机制，默认情况下将被视作未授权访问处理，并需配置l2tp以实现l2tp over ipsec的功能

flags字段不同

IKEv1与IKEv2 的区别：

可比较的角度：

IPsec建立过程，报文角度

阶段比较，IKEv1有两个阶段，IKEv2 没有阶段。

IKEv1

IKEv1协商安全联盟主要分为两个阶段。

在 IKEv1 � Stages 1 阶段的主要目标是 实现 IKE 协商协议（SA）的建立 这种协议主要包括两种 协商机制：标准 协商流程 和 快速 协商流程 标准 协商流程 通过 6 条 ISAKMP 消息实现协商过程 而 快速 协商流程 则仅需 3 条 ISAKMP 消息即可完成 整个过程 快速 协商流程 显著提升了 IKE SA 的 建立效率 然而 快速 协商流程 的一个局限性在于 密钥交换与身份认证 同步进行的情况下 并不能提供 双方的身份验证保障

IKEv1阶段2的主要目标在于建立一个用于传输数据的IPSec SA，并通过Quick Pairing Mode（共三段ISAKMP消息）来完成协商过程。

IKEv2

该协议通过优化现有机制降低了安全联盟的协商复杂度。该协议通常采用两次握手即可实现一个 IKE 本地地址 (SA) 和一个 IKE 隐私 tunnels (SA) 的结合。当需要建立超过一对的 IPSec 虌类时，则需额外增加一次握手操作，在这种情况下仅需发送两条消息即可完成。

载荷角度

AUTH，TSi，TSr，EAP

认证方法

该版本支持通过EAP实现身份验证。该版本可以通过认证服务器完成远程设备（如PC及手机）的身份验证及私网IP地址分配。相比之下，在 v1 版本中不具备该功能，在 v2 版本中则可依靠 L2TP 实现私网地址的分配。

支持远程接入

L2TP OVER IPSEC---------IKEV1解决方案

其他功能

NAT -T DPD

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

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

配置不同

DPD中超时重传实现不同。

该参数仅在IKEv1协议中得到支持。它表明在发送DPD报文之后，在指定时间内若未能收到相应的确认报文，则DPD记录发生了一次故障事件。当故障累积达5次时，则导致移除 IKE 会话键和相应的IPSec 系列安全套接缝。直至隧道内出现流量为止,双方将重新 attempt 建立 IKE 会话键

对于采用 IKEv2 方式的 IPSec 安全头（SA），其超时重传时间间隔将逐步增加至 64，并呈几何级数增长。经过 8 次尝试后若未接收到对端发送的报文，则判断对端已处于离线状态，并相应地删除 IKE SA 和相关的 IPSec SA。

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

Ike v2 的 Ike SA 参数将 soft retransmit timer 设置为 hard retransmit timer 的 90% 左右减去一个随机值（±）。通常情况下不会出现双方同时发起重传协商的情况（即不会发生重传同步），因此 Ike v2 参数无需设置 soft retransmit timer

总结：

IKEv1的主要问题：

• 不支持远程用户接入
• 协商建立IPSec SA的时间太长

IKEv2** 的改进：**

• IKEv1被认为是混合型协议的一种形式，在其自身所具有的复杂性必然导致一些安全性和性能方面的缺陷问题上已经暴露出来后就成为了当前实现IPSec系统时必须要面对的关键障碍。
  • 在经过对 IKEv1 研究过程中所发现的问题深入分析后, IKEv2 协议决定对原有技术方案进行相应的改进与优化,在确保既简洁又高效的同时,又兼顾到了安全性以及健壮性等多个重要特性,最终综合考虑将原有的相关技术文档进行了全面整合,并将其以单份 RFC4306 标准文档的形式进行了替代更新.在精简核心功能规定的基础上,新版本协议实现了不同 IPSec VPN 系统间的高度互操作性.

IKEv2** 与IKEv1相比有以下优点：**

简化了安全联盟的协商过程，提高了协商效率。

该协议分两步完成IPSec密钥交换并创建IPSec安全套接框（SA）。在第一步中，双方通过协商确定并建立了一个基于IKE的安全通信渠道。随后，在第二步中，则利用此经过认证并经安全防护的通信渠道创建一个 IKE 安全套接框（SA）。. . .从而完成一对 IPsec 安全套接框的创建。而 IKEv2 则简化了整个流程，在一次会话中即可一次性生成所需的 IPsec 密钥并创建相应的 IPsec 安全套接框（SA）。

修复了多处公认的密码学方面的安全漏洞，提高了安全性能。

增添对EAP（Extensible Authentication Protocol）身份认证方式的支持，并增强了认证方式在灵活性和可扩展性方面的表现。

该协议具备多点认证功能，并且设计上特别注重灵活性与可扩展性。此外，在功能上它也表现出了极强的适应能力——亦即通过模块化设计，在现有体系中无需进行根本性的改动即可引入新的验证机制。目前该方案已得到广泛应用，并在电话接入网络领域发挥着重要作用。

基于EAP协议成功克服了远程接入用户认证难题，并彻底摆脱了L2TP的限制。 IKEv2 已经成为远程接入网络中的主要应用方案。

基于EAP协议成功克服了远程接入用户认证难题，并彻底摆脱了L2TP的限制。 IKEv2 已经成为远程接入网络中的主要应用方案。