IKE V2 实现的预研报告.doc

IKE V2 实现的预研报告（草稿）吴世强一 IKE的发展历程 IKE 协议保证了安全关联建立过程的安全性和动态性, 但作为一个混合型协议, 它的实现是极为复杂的; 同时它又是一个使用非常频繁的流程。Ike v1 是建立在由Internet安全联盟和密钥管理协议( ISAKMP) 定义的一个框架上, 同时还包含了两种密钥管理协议的一部分Oakley 和SKEME，它主要由rfc24012412定义组成。Ike v1面临的问题主要有以下几个方面：( 1) 从协议本身来看, 原有标准所提供的某些功能实际很少被使用, 甚至根本不用, 其数据结构存在进一步简化的空间。( 2) 从系统耗费来看, 高强度的密钥在提供更高安全性的同时对计算机系统意味着更大的运算负担, 有必要在实现时考虑尽量避免使用大强度的密钥计算。( 3) SA 建立时需要多轮协商, 为节约通信资源, 应该减少传送的信息和交换次数, 从而提高IKE 的效率。( 4) 应注意到在公共互联网上普遍存在的安全隐患, IKE协议本身的特点决定了其有可能遭受拒绝服务攻击、重播攻击、中间人攻击等危险, 有必要加以改进以增强其抵御能力。 针对v1的情况，ike v2（rfc4306）做了如下改进：( 1) 协议的整合。IKEV2整合了ikev1的主体协议（RFC2407, 2408, 2409）以及后来补充的NAT 穿越( NAT Traversal) 、遗传认证( Legacy Authentication)、远程地址采集( Remote Address Acquisition) 等协议, 形成了一个完整的IKE 协议。它保留了IKEv1 的基本功能, 同时兼顾了高效性、安全性、健壮性和复杂性的需要, 大幅度精简了原有协议, 并针对在此之前对IKEv1 研究过程中发现的问题进行了修订。( 2) 协商轮数的减少。在保证安全性的前提下, 将第一阶段中主模式交换的消息条数由六条减少到四条, 第二阶段的消息由三条变为两条。( 3) 载荷的变化。在载荷方面的变化是新版协议最显著的特点之一，后面详细说明。( 4) 安全性。为了防御来自网络的拒绝服务( DoS) 攻击, IKEv2 规定通信双方任何一端不能通过任何路由信息( ICMP 消息) 或未加密保护的IKE 消息( 报错消息) 来判定另一方是否已经无法通信。( 5) 兼容性。考虑到便于将来修订, 并在一定程度上能够向前兼容, 新版协议详细给出了在各类错误情况下协商双方所应该采取的行为。IKEv2 保留了已有的语法和幻数( Magic Numbers) , 通过付出最小代价, 使得IKEv1 在一定范围内得到增强而支持IKEv2。如果双方都支持多版IKE, 则双方采用彼此都支持的最高版本协议的IKE 进行协商。在IKEv2 中, 为了将来更灵活地向前兼容, 每个载荷头都增加了一个鉴定标志( Critical Bit,通常以“C”表示) 。如果一个消息设置了鉴定标志, 但其载荷类型不被识别, 那么它必须被丢弃。同时响应方在响应这个IKE 请求时, 必须包含一个通知载荷, 提示收到无法支持的载荷。如果鉴定标志未被设置, 则接收者必须忽略这个无法支持的载荷类型而接收消息。( 6) 对NAT 的支持。IKEv2 明确提出了对NAT 穿越的支持，IKEv2 用UDP 封装的IKE, ESP, AH 数据包来协商。有关IPSec下NAT 实施的详细说明请参考draft-ietf-ipsec-nat-reqts- 06. txt。二 IKEv1和v2 的SA消息格式和交互流程IKEv2 在ISAKMP消息头部的开始部分不再是发起者和响应者的Cookie, 而是双方的安全关联索引( SPI) 。在消息头部的交换类型( Exchange Type) 中, 第二版只定义了四种, 分别对应于初始化交换、IKE 验证、创建子SA 和信息交换, 编号3437( 0 33 保留, 可能是基于与第一版协议兼容的需要) , 不再保留所谓的基本模式、野蛮模式、新组模式和身份保护模式。在标志位( Flag) 的定义上, 第二版占用了这个比特的3 5 位( 0 2 位保留, 正好是第一版占用的位) , 其中第3 位用来表示发起者, 第5 位用来表示响应者。为了在工程实现时更紧凑地编码, IKEv2 定义了新的安全联盟载荷, 不再保留IKEv1 中的数据属性载荷、建议载荷和变换载荷, 而是将其作为一个统一载荷的不同子( Substructure)放在一起。与第一版的一个显著的差别是: 安全关联载荷通用头部后面删除了解释域( DOI) 和情形标志( SIT) 。IKEv2 允许有多个建议子结构, 每个建议子结构必须有相同的建议编号( 如AH 和ESP 同时使用的情况) ; 每个建议后面可以有一至多个变换子结构。IKE v2 定义了五种变换类型, 如表1 所示：对于每个协议, 每个允许的变换集合都分配了变换ID 号,它出现在每个变换的头中。这样的定义和IKEv1 有了很大的区别。在第一版协议中, 当协议需要多个算法时, 通常有一个算法在变换中体现, 而其余的算法则放在属性中, 相比之下,IKEv2 的定义更加清晰明确。IKEv2 与IKEv1 的一大差别就是新协议第一次定义了独立的加密载荷, 加密载荷所包含的内容有一个正常载荷包含的通用头部, 一个称为初始化向量( IV) 的随机值以及经过加密之后的其他载荷、填充值和完整性校验数据。对于IKE_AUTH阶段的消息, 以及在CREATE_CHILD_SA 和信息交换的消息而言, 消息除去头部之外的部分都是加密的, 在定义了加密载荷之后,从外界直观看来, 整个消息只包含一个有效载荷加密载荷。IKEv2 不再保留杂凑载荷和签名载荷, 而是定义了新的验证载荷( Authentication Payload, 用AUTH表示) , 在它的验证方法( Auth Method) 域中, 定义了三种常用的验证方式: RSA 数字签名( 对应值为1) 、共享密钥消息完整性代码( 对应值为2) 、DSS 数字签名( 对应值为3) ; 载荷中还带有一个可变长的域,用于装载验证数据。通信量选择载荷是一个IKEv2 新定义的载荷, 它分担了原来ID 载荷的一部分功能, 通信量选择符( TS) 允许通信双方使用它们自己SPD中的某些信息与对方进行通信。TS 载荷具体描述了数据包的选择标准( 如地址范围和端口范围等) ，而这些数据包将会按照标准建立新的SA 发送。在IKE 验证的两条消息( 第三、四条消息) 中, 通信量选择载荷是必须要有的,其中TSi 具体给出了来自于发起方的通信量传送源地址;TSr具体给出了响应方的通信量传送目的地址。双方所划定的地址范围可能是不同的, 而协商的结果就是建立双方共同拥有地址范围的交集, 并在此基础上建立起SA 束。同时, 为了适应新的安全需求, 辅助性载荷种类中添加了配置载荷和扩展认证载荷。另外, 给出了流量选择符( TrafficSelectors) 的载荷形式, 不必重载ID 载荷。2.1 sa格式Ikev1的sa格式如下：Ikev2的sa格式如下：2.2 ike协商交换流程 忽略快速模式交换和信息交互的描述。2.2.1 ikev1三种认证方式两种在两种交换模式下的交互流程1 psk认证a） 主模式消息流程图 b） 野蛮模式消息流程图 2 RSA加密认证a）主模式消息流程图b）野蛮模式消息流程图 3数字签名认证a） 主模式消息流程图b）野蛮模式消息流程图4公共密钥认证a） 主模式消息流程图b）野蛮模式消息流程图2.2.2 ikev2的交互流程 Ikev2已没有交互模式的区分，在保证安全的情况下只有初始化交换、IKE 验证。如下如下图所示1） IKE_SA_INIT消息交互2） IKE_AUTH消息交互三 vsp平台上ikev2实现 从ikev1和ikev2的架构、消息格式、负载、交互流程以及安全考量方面来看，差异比较明显。现在vsp平台采用的是racoon程序，它支持ikev1，但不包括组交换模式。 如果在racoon上进行二次开发需要解决以下问题：1 v1和v2是否要并存，或者说都支持？2）如果要支持，协商模式和认证如何处理？3）负载的封装是否需要调整？4）第一阶段和第二阶段协商的数据结构是否需要调整？5）ikev2中增加了和spd相关的TS消息域？。 细节尚需更深一步对比，但从总体性来说，在其上升级到支持ikev2和ikev2比较有难度和较大的工作量。 目前支持ikev2的主要开源项目有 OpenIKEv2 - / Racoon2 - http:/www.racoon2.wide.ad.jp/ IKEv2 - http:/ikev2.zemris.fer.hr/ strongSwan - /几家特征比较分别引用ikev2 n的数据，新的变化待确认。ikev2 项目提供的数据：上面的数据并不是最新，但从项目的人气来说， strongswan人气较旺，现在strongswan已经发展到了4.3.6版本。Openikev2实现采用的是C+语言。Racoon2和ike2的优