IPSec之IKEv2协议详解
IKEv2简介
IKEv2介绍:
- 定义在RFC4306 ,更新与 RFC 5996.
- 不兼容IKEv1,IKEv1不支持认证,IKEv2支持认证,EAP。
- 支持NAT穿越。
- IKEv2支持私密性、完整性、源认证。
- 工作在UDP 的 500 /4500端口。NAT-T用的是UDP4500端口。
IKE的安全机制:
身份认证
确认通信算双方的身份(对等体的IP地址或者名称),包括:
预共享密钥PSK(pre-shared key)认证。
数字签名RSA(rsa-signature)认证。
身份保护
DH(Diffie-Hellman)密钥交换算法
完善的向前安全性PFS(Perfect Forward Secrecy)
短暂的一次性密钥系统称为“完美向前保密”
在IPSec里,PFS是通过在IPSec SA协商阶段重新进行一个DH交换来实现的。
DH交换算法:
图:DH交换算法
详解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中将IKEv1中的主模式和野蛮模式换成了Inital Exchange,将快速模式阶段换成了CRATE_CHILD_SA.
初始交换:
正常情况下,IKEv2通过初始交换就可以完成第一对IPSec SA的协商建立。IKEv2初始交换对应IKEv1的第一阶段,初始交换包含两次交换四条消息。
图:初始交换过程图
消息①和②属于第一次交换(称为IKE_SA_INIT交换),以明文方式完成IKE SA的参数协商,包括协商加密和验证算法,交换临时随机数和DH交换。IKE_SA_INIT交换后生成一个共享密钥材料,通过这个共享密钥材料可以衍生出IPSec SA的所有密钥。相当于IKEv1的主模式的第1,3个包。
消息③和④属于第二次交换(称为IKE_AUTH交换),以加密方式完成身份认证、对前两条信息的认证和IPSec SA的参数协商。IKEv2支持RSA签名认证、预共享密钥认证以及扩展认证方法EAP(Extensible Authentication Protocol)。EAP认证是作为附加的IKE_AUTH交换在IKE中实现的,发起者通过在消息3中省去认证载荷来表明需要使用EAP认证。
图:IKEv2协商过程抓包,总共四个包
交换消息
- 2个初始信息
- 2个认证信息
IKEv2报文协商详细过程:
Initiator Responder-------------------------------------------------------------------HDR, SAi1, KEi, Ni --><-- HDR, SAr1, KEr, Nr, [CERTREQ]HDR, SK {IDi, [CERT,] [CERTREQ,][IDr,] AUTH, SAi2,TSi, TSr} --><-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr}
字段说明:
AUTH AuthenticationCERT Certificate,证书CERTREQ Certificate RequestCP ConfigurationD DeleteEAP Extensible AuthenticationHDR IKE header (not a payload),IKE头部IDi Identification - InitiatorIDr Identification - ResponderKE Key Exchange,发起方提供的密钥交换材料、有限使用最高安全级别的DH组Ni, Nr Nonce,随机数N NotifySA Security Association,安全关联参数SK Encrypted and AuthenticatedTSi Traffic Selector - InitiatorTSr Traffic Selector - ResponderV Vendor ID
IKEv2中的消息交换都是以IKE_SA_INIT 和 IKE_AUTH开始的。在IKEv1中称为阶段一。这些初始交换通常是由4个消息组成,在大于一对IPSec SA的建立中,可以增加子SA。
IKEv2的所有通信都是以request/response对组成。
第一对消息(IKE_SA_INIT)进行协商密码算法、交换nonces,和DH算法。生成SKEYSEED,后续的消息使用密钥进行加密和验证。
第二对消息(IKE_AUTH)操作在又IKE_SA_INIT所创建的IKE_SA之上。对前一对消息进行身份验证,交换身份和整数,并建立第一个CHILD_SA,这些消息的一部分是加密和完整的,使用通过IKE_SA_INIT交换建立的密钥来包加密。
初始交换之后所有的消息都是加密传输的。
IKEv2协商过程的第1个包:
图:IKEv2协商过程的第一个包抓包示例
第一个包交换的信息如下:
IKE_SA_INIT: Message 1
发起方提供基本的SA(安全关联)参数和密钥交换材料。等同与IKEv1的主模式的第1和第3个包。
Initiator Responder-------------------------------------------------------------------HDR, SAi1, KEi, Ni -->----------------------------------KEi:发起方提供的密钥交换材料,优先级使用最高安全级别的DH组
发起方发送:HDR包含安全参数索引(SPIs)、版本号和flags。SAi1有效载荷声明了发起方支持的IKE SA加密算法。KE有效载荷是发送方的DH值,Ni为发起方的随机数。
第一个包:Responder SPI的值为0,Flags位的Initiator的值为1,标志位发起方。Message ID的值也为0,该值和下一个会回应方的Message ID值相同。用来标即区分一对request/response消息对。
IKEv2协商过程的第2个包:
图:IKEv2协商过程的第2个包抓包示例
第2个包的信息交换如下:
IKE_SA_INIT: Message 2
接收方会一个可以接受的参数,并附带密钥交换内容和证书请求(可选)。等同于IKEv1的主模式的第2和第4个包。
<-- HDR, SAr1, KEr, Nr, [CERTREQ]------------------------------------------------SAri:接收方选择的密码学算法KEr:接收方选择的密钥交换材料Nr:接收方的随机数CertReq: 整数请求,可选
回应方:从发起方提供的SAi1负载中选择一个可接受的加密组套件,封装在SAr1中,并发送双方都支持的DH算法的最高级封装在KEr负载中,以及发送回应方的Nr随机值。
在回应方的报文中,SPIi为发起方的SPI,SPIr中填充自己生产的spi。Flags中的Response位置1,表示自己为回应方的报文。Message ID的值同第一个报文的Message ID,为0.
第1个和第2个包交换完成后,每一方都能生成SKEYSEED,所有的密钥都是从这个密钥推导出来的。以后的消息除了消息头都会被加密和完整性保护。加密和完整性保护的密钥都是来自SKEYSEED,分别称为SK_e,用于加密,SK_a,用于认证,做完整性保护。会为每个方向计算单独的SK_a和SK_e。
除了密钥来自DH算法的SK_e和SK_a之外,还会导出另一个两SK_d,用于生成子SA的密钥材料。符号SK{…}表示这些有效载荷已加密使用该方向的SK_e和SK_a保护完整性。
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 )-------------------------------------------------------IKE SA; SK_ai and SK_ar used as a key to the integrity protection algorithm for authenticating the component messages of subsequent exchanges;SK_ei and SK_er used for encrypting (and of course decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are used when generating an AUTH payload. The lengths of SK_d, SK_pi,and SK_pr MUST be the preferred key length of the PRF agreed upon.
IKEv2协商过程的第3个包:
图:IKEv2协商过程的第3个包抓包示例
第3个包的信息如下:
IKE_AUTH: Message 1
创建child SA相关的认证内容和参数(等于与IKEv1的主模式的第5个包和部分快速模式的包)
HDR, SK {IDi, [CERT,] [CERTREQ,][IDr,] AUTH, SAi2,TSi, TSr} -->
-------------------------------------------SK :该负载被加密并且完整性保护。IDi:发起方的身份信息Cert:发起方的整数,可选CertReq:发起方的证书请求,可选IDr:期望的相应方的身份信息,可选AUTH: 发起方认证数据,没有EAP就没有这个字段,可选SAi2,发起方Child SA转换集TSi/TSr: Child SA流量选择器 符号SK{…}表示这些有效载荷已加密使用该方向的SK_e和SK_a保护完整性。
发起方:除了HDR未加密,其余都被加密。IDi是发起方的有效身份载荷,用来证明自己的身份和完整性保护。也可以在CERT中发送整数有效载荷记忆在CertReq有效宰割中的信任列表。如果包含任何CERT有效载荷,必须提供第一个证书,包含用于验证AUTH字段的公钥。
可选的有效负载IDr使发起者能够指定哪个响应者。当在有同一个IP地址的机器上可能有多个身份ID。如果响应者不接受发起方提出的IDr,响应者可能会使用其他一些IDr完成交换。如果发起方不接收相应方提供的IDr,发起方可以关闭这个SA协商。
Tsi,Tsr是流量选择器,可以用来协商双方的感兴趣流。在IKEv2中可以协商,取感兴趣流的交集。但是在IKEv1中不能协商,只能双方互相配置为镜像地址。
发起方使用SAi2负载来协商Child SA,SAi2用来描述CREATE_CHILD_SA的交换参数。
第3个报文中的报文头是明文的,其余都是密文传输。在该报文中的Flags中的Initiator位置1,表示是发起方的报文。Message ID区别于上一对消息,为1。下一个回应的报文的Message ID和这个值相同。其余消息被封装到了Encrypted and Authenticated载荷中。
IEKv2协商过程的第4个包:
图:IKEv2协商过程的第4个包抓包示例
第4个包信息如下:
IKE_AUTH: Message 2
创建于child SA相关的认证内容和参数。等同于IKEv1主模式的第6个包和部分快速模式的包。
<-- HDR, SK {IDr, [CERT,] AUTH,SAr2, TSi, TSr}
----------------------------------------------------------
SK: 负载被加密和完整性保护
IDr:相应方的身份信息
Cert:相应方的证书,可选
AUTH:相应方的认证数据,没有EAP就没有这个字段,可选
SAr2:相应方选择的Child SA转换集
TSi/TSr: Child SA流量选择器,感兴趣流
响应方:使用IDr有效载荷声明其身份,可选发送一个或多个证书(同样这个证书需要有用于验证AUTH的公钥),AUTH:验证第二消息的身份和完整性保护。SAr2字段用于发送创建CREATE_CHILD_SA的提议材料。
创建子SA交换:
当一个IKE SA需要创建多对IPSec SA时,需要使用创建子SA交换来协商多于一对的IPSec SA。另外,创建子SA交换还可以用于IKE SA的重协商。
创建子SA交换包含一个交换两条消息,对应IKEv1协商阶段2,交换的发起者可以是初始交换的协商发起方,也可以是初始交换的协商响应方。创建子SA交换必须在初始交换完成后进行,交换消息由初始交换协商的密钥进行保护。
类似于IKEv1,如果启用PFS,创建子SA交换需要额外进行一次DH交换,生成新的密钥材料。生成密钥材料后,子SA的所有密钥都从这个密钥材料衍生出来。
通知交换:
运行IKE协商的两端有时会传递一些控制信息,例如错误信息或者通告信息,这些信息在IKEv2中是通过通知交换完成的。如下图
通知交换必须在IKE SA保护下进行,也就是说通知交换只能发生在初始交换之后。控制信息可能是IKE SA的,那么通知交换必须由该IKE SA来保护进行;也可能是某子SA的,那么该通知交换必须由生成该子SA的IKE SA来保护进行。
IKEv1和IKEv2的区别
IKEv1与IKEv2的区别:
可比较的角度:
IPsec建立过程,报文角度
阶段比较,IKEv1有两个阶段,IKEv2没有阶段。
IKEv1
IKEv1协商安全联盟主要分为两个阶段。
IKEv1阶段1的目的是建立IKE SA,它支持两种协商模式:主模式和野蛮模式。主模式用6条ISAKMP消息完成协商。野蛮模式用3条ISAKMP消息完成协商。野蛮模式的优点是建立IKE SA的速度较快。但是由于野蛮模式密钥交换与身份认证一起进行无法提供身份保护。
IKEv1阶段2的目的就是建立用来传输数据的IPSec SA,通过快速交换模式(3条ISAKMP消息)完成协商。
IKEv2
IKEv2简化了安全联盟的协商过程。IKEv2正常情况使用2次交换共4条消息就可以完成一个IKE SA和一对IPSec SA,如果要求建立的IPSec SA大于一对时,每一对SA只需额外增加1次交换,也就是2条消息就可以完成。
载荷角度
AUTH,TSi,TSr,EAP
认证方法
IKEv2支持EAP身份认证。IKEv2可以借助认证服务器对远程接入的PC、手机等进行身份认证、分配私网IP地址。IKEv1无法提供此功能,必须借助L2TP来分配私网地址。
支持远程接入
L2TP OVER IPSEC---------IKEV1解决方案
其他功能
NAT -T DPD
IKE SA的完整性算法支持情况不同。
IKE SA的完整性算法仅IKEv2支持,IKEv1不支持。
配置不同
DPD中超时重传实现不同。
retry-interval参数仅IKEv1支持。表示发送DPD报文后,如果超过此时间间隔未收到正确的应答报文,DPD记录失败事件1次。当失败事件达到5次时,删除IKE SA和相应的IPSec SA。直到隧道中有流量时,两端重新协商建立IKE SA。
对于IKEv2方式的IPSec SA,超时重传时间间隔从1到64以指数增长的方式增加。在8次尝试后还未收到对端发过来的报文,则认为对端已经下线,删除IKE SA和相应的IPSec SA。
IKE SA超时时间手工调整功能支持不同。
IKEv2的IKE SA软超时为硬超时的9/10±一个随机数,所以IKEv2一般不存在两端同时发起重协商的情况,故IKEv2不需要配置软超时时间。
IKEv1与IKEv2的对比:
图:IKEv1和IKEv2区别
区别:
- IKEv2:支持DPD,EAP认证方式,NAT-T,支持消息的确认(一端删除sa信息,另一端也会删除),支持自动协商感兴趣流,针对DOS的攻击防护,支持远程用户接入,最少4个包协商速度更快。
- IKEv1:远程用户接入必须结合L2TP、主模式9个包,野蛮模式6个包。不能协商感兴趣流,得互相配置为镜像。
图:IKEv1和IKEv2载荷对比
总结:
IKEv1的主要问题:
- 不支持远程用户接入
- 协商建立IPSec SA的时间太长
IKEv2的改进:
- IKEv1是一个混合型协议,其自身的复杂性不可避免地带来一些安全及性能上的缺陷,已经成为目前实现IPSec系统的瓶颈。
- IKEv2协议保留了IKEv1的基本功能,并针对IKEv1研究过程中发现的问题进行修订,同时兼顾简洁性、高效性、安全性和见健壮性的需要,整合了IKEv1的相关文档,由RFC4306单个文档替代。通过核心功能最小化规定,新协议极大提高了不同IPSec VPN系统的互操作性。
IKEv2与IKEv1相比有以下优点:
简化了安全联盟的协商过程,提高了协商效率。
IKEv1使用两个阶段为IPSec进行密钥协商并建立IPSec SA:第一阶段,通信双方协商和建立IKE本身使用的安全通道,建立一个IKE SA;第二阶段,利用这个已通过了认证和安全保护的安全通道,建立一对IPSec SA。IKEv2则简化了协商过程,在一次协商中可直接生成IPSec的密钥并建立IPSec SA。
修复了多处公认的密码学方面的安全漏洞,提高了安全性能。
加入对EAP(Extensible Authentication Protocol)身份认证方式的支持,提高了认证方式的灵活性和可扩展性。
EAP是一种支持多种认证方法的认证协议,可扩展性是其最大的优点,即若想加入新的认证方式,可以像组件一样加入,而不用变动原来的认证体系。当前EAP认证已经广泛应用于拨号接入网络中。
通过EAP协议解决了远程接入用户的认证问题,彻底摆脱了L2TP的牵制。目前IKEv2已经广泛应用于远程接入网络中了。
参考文档:RFC 5996
IPSec之IKEv2协议详解相关推荐
- IPSec之IKEv1协议详解
IKE简介 安全联盟SA: 定义: 安全联盟是要建立IPSec 隧道的通信双方对隧道参数的约定,包括隧道两端的IP地址.隧道采用的验证方式.验证算法.验证密钥.加密算法.共享密钥以及生命周期等一系列参 ...
- nb服务器协议,nb-iot协议详解
设计的优点是都能部署在现在的LTE网络,只需要对基站和核心网的软件进行升级即可,不需要为IoT物联网通讯专门设计并建设一个专门网络,可以大大降低建设成本.与LTE一样,NB-IoT终端在开机并搜索载波 ...
- HTTP协议详解(真的很经典)
转自:http://blog.csdn.net/gueter/archive/2007/03/08/1524447.aspx Author :Jeffrey 引言 HTTP是一个属于应用层的面向对象的 ...
- Http 协议详解笔记
HTTP是一个属于应用层的面向对象的协议,由于其简捷.快速的方式,适用于分布式超媒体信息系统.它于1990年提出,经过几年的使用与发展,得到不断地完善和扩展.目前在WWW中使用的是HTTP/1.0的第 ...
- Http协议 详解(转载)
http://blog.csdn.net/gueter/archive/2007/03/08/1524447.aspx 引言 HTTP是一个属于应用层的面向对象的协议,由于其简捷.快速的方式,适用于分 ...
- ARP协议详解之ARP动态与静态条目的生命周期
ARP协议详解之ARP动态与静态条目的生命周期 ARP动态条目的生命周期 动态条目随时间推移自动添加和删除. q 每个动态ARP缓存条目默认的生命周期是两分钟.当超过两分钟,该条目会被删掉.所以,生 ...
- ARP缓存表的构成ARP协议全面实战协议详解、攻击与防御
ARP缓存表的构成ARP协议全面实战协议详解.攻击与防御 1.4.3 ARP缓存表的构成 在局域网的任何一台主机中,都有一个ARP缓存表.该缓存表中保存中多个ARP条目.每个ARP条目都是由一个IP ...
- HTTP协议详解 转自小坦克
HTTP协议详解 转自小坦克 -- 有些文章是引用别人的,为了方便我以后或不再备注;引用目的是因为直接网摘里面的地址经常被重置,找不到原来的文章 当今web程序的开发技术真是百家争鸣,ASP.NET, ...
- nbns协议_网络协议详解1 - NBNS
NetBIOS 简介 NetBIOS,Network Basic Input/Output System的缩写,一般指用于局域网通信的一套API,相关RFC文档包括 RFC 1001, RFC 100 ...
最新文章
- web前端——让人头疼的多列复选框排列解决办法
- 『数据中心』供配电与空调设计基础知识
- 解决错误: Failed to load class “org.slf4j.impl.StaticLoggerBinder“
- 学生社团网站html,学生社团活动平台的设计与实现.docx
- 势头迅猛的儿童手表:恐陷下一个文曲星之地?
- vscode写python爬虫_如何在vscode中调试python scrapy爬虫
- 剑指offer面试题[7]-用两个栈实现队列
- c#调用javascript的方法,有Updatepanel的情况
- AcWing 877. 扩展欧几里得算法(拓展欧几里得模板)
- xshell与xftp免费版
- 惠普HP LaserJet 1320n 打印机驱动
- 大学机器人类公选课(ROS机器人高效编程)申请表、大纲、部分教案、进度表等材料分享
- python 去重方法
- Java修改图片尺寸
- c语言pow为什么溢出,c – GMP pow中的溢出处理
- 如何通俗易懂地阐述机器学习?
- android 实现ble蓝牙自动配对连接
- 【论文泛读76】将来自bert的提取信息和多种嵌入方法与深度神经网络集成在一起,以进行幽默检测
- 成为顶流平台后 新氧阳谋峥嵘显露
- libreCAD源码阅读笔记3
热门文章
- 跨境电商如何打造爆款主图
- 惠普星14青春版12代酷睿值不值得买 好不好
- Windows下安装Tensorflow-GPU+keras(T590: Nvidia MX250 + Dell工作站:Quadro P2000)
- 超级计算机英语怎么读的,沃森超级计算机的意思
- 荆门哪个小学招计算机老师,正在公示!荆门10名老师入选特级教师!看看有你认识的吗?...
- 使用php制作导航栏,怎样用PHP来给网页做导航栏
- 遇到的数学公式摘记(持续更新)
- c++ list, vector, map, set 区别与用法比较
- c语言中bool的使用
- java map初始化并赋值