【通信行业标准(YD)】 互联网密钥交换协议（IKEv2）技术要求

中华人民共和国出入境检验检疫行业标准SN/T2359—-2009/IS022716:2007进出口化妆品良好生产规范
Good manufacturing practice for cosmetics for import and export[ISO 22716:2007,Cosmetics--Good manufacturing practices(GMP)-Guideline on good manufacturing practices,IDTJ2009-09-02发布
中华人民共和国
段码防伙
国家质量监督检验检疫总局
2010-03-16实施
ICS33.040.40
中华人民共和国通信行业标准
YD/T 1897-2009
互联网密钥交换协议（IKEv2）技术要求Technical reguirements of Internet Key Exchange Protocol (iKEv2)2009-06-15发布
2009-09-01实施
中华人民共和国工业和信息化部　发布前言·
1范围·
2规范性引用文件
3术语、定义和缩略语
4IKE基本使用与操作
5IKE协议细节及变化
6报头和载荷的格式·
一致性要求·
8安全性考虑·
附录A（资料性附录）
附录B（资料性附录）
参考文献·
与IKE版本1的区别汇总
Diffie-Hellman 组
YD/T 1897-2009
YD/T1897-2009
本标准是IP安全协议（IPSec）系列标准之一，该系列标准的名称及结构预计如下：1.《IP安全协议体系结构》（MODIETFRFC2401）2.《IP认证头(AH)》（MODIETFRFC2402）3.《IP封装安全载荷(ESP)》（MODETFRFC2406）4.YD/T1466-2006《IP安全协议（IPSec）技术要求》5.YD/T1467-2006《IP安全协议（IPSec）测试方法》6.《IP安全协议（IPSec）穿越网络地址翻译（NAT）技术要求》7.《互联网密钥交换协议（IKEv2）技术要求》8.《互联网密钥交换协议（IKEv2）测试方法》本标准与《互联网密钥交换协议（IKEv2）测试方法》配套使用。本标准的附录A、附录B均为资料性附录。本标准由中国通信标准化协会提出并归口。本标准起草单位：工业和信息化部电信研究院本标准起草人：谢玮、刘述、田慧蓉、马科、马军峰、高巍、江浩洁、唐浩、武静、吴英桦
1范围
互联网密钥交换协议（IKEv2）技术要求YD/T 1897-2009
本标准规定了动态建立并管理IPsec安全联盟的协议-一互联网密钥交换协议（IKEv2）技术要求，包括IKEv2协议使用的命令、交换过程、报头和载荷格式、安全性等方面的要求。本标准适用于支持互联网密钥交换协议（IKEv2）的设备和网络。2＇规范性引用文件
下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准。然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。YD/T 1466-2006
IETFRFC822（1982)
IETFRFC3168(2001)
IETFRFC3513(2003)
IETFRFC3748（2004)
IETFRFC3948（2005)
IETFRFC4301（2005)
3术语、定义和缩略语
3.1术语和定义
IP安全协议（IPSec）技术要求
ARPA因特网正文信息格式标准
到IP的显示拥塞指示其他要求
IPv6寻址体系结构
扩展认证协议(EAP)
IPsecESP包的UDP封装
因特网协议的安全体系结构
YD/T1466-2006确立的术语和定义适用于本标准。3.2缩略语
下列缩略语适用于本标准。
Authentication Header
Certificate Authority
Copher Block Chaining
Encapsulating Security PayloadData Encryption Standard
Explicit Congestion NotificationHASHMAC
Internet Control Message ProtocolIntegrity Check Value
Internet Key Exchange
IPSecurity
认证头
证书授权中心
码块链
封装安全载荷
数据加密标准
显示拥塞指示
散列消息认证码
互联网控制消息协议
完整性校验值
互联网密钥交换
IP安全
YD/T1897-2009
Message Digest 5
PathMaximunTransmissionUnit
Security Association
SADatabase
Secure Hash Algorithm-1
SimpleNetworkManagementProtocolSecurity Parameter Index
SecurityPolicyDatabase
Traffic Selector
Transmission Control ProtocolUser Datagram Protocol
4IKE基本使用与操作
4.1概述
消息摘要5
路径最大传输单元
安全联盟
安全联盟数据库
安全散列算法-1
简单网络管理协议
安全参数索引
安全策略数据库
流量选择器
传输控制协议
用户数据报协议
IPsec为P数据报提供机密性、数据完整性、接入控制和数据源认证。这些服务通过在IP数据报的源和信宿之间维护共享的状态来提供。该状态定义了提供给数据报的特定服务（使用加密算法来提供这些服务）以及作为作为加密算法输入的密钥。通过手动的方式建立这个共享状态缺乏扩展性。因此，需要一种协议动态建立这个共享状态。本标准就描述了这样的一个协议一一互联网密钥交换（IKE）协议的第二版本。IKE执行两个参与方之间的相互认证，并建立IKE安全联盟（SA），该安全联盟包括共享秘密信息（该信息用于有效建立ESP和/或AH的SA），以及SA使用的一组加密算法，该算法用于对其承载的流量进行保护。本标准中，术语“算法族”或者“加密算法族”指的是一整套用于保护SA的加密算法。发起者通过列举它所支持的能够通过混合匹配方式被组合进“算法族”的算法来建议使用一个或者多个“算法族”。IKE也能够协商关于ESP和/或AHSA的IP压缩的使用。定义IKESA为“IKE_SA”。通过IKE_SA获得建立的ESP和/或者AHSA，定义为“CHILD_SA”。所有的IKE通信都是由消息对组成的：请求和响应。这个消息对被称为“交换”。我们称第一个建立IKE_SA的消息为IKE_SA_INIT和IKE_AUTH交换，随后的IKE交换为CREATE_CHILD_SA交换或者INFORMATIONAL交换。在通常情况下，建立IKE_SA以及第一个CHILD_SA，包括一个IKE_SA_INIT交换和一个IKE_AUTH交换（总共四个消息）。在例外情况下，可能存在多次这些交换。在所有情况下，所有的IKE_SA_INIT交换都必须在任何其他类型交换之前完成，随后必须完成所有的IKE_AUTH交换，然后任意数目的CREATE_CHILD_SA和INFORMATIONAL交换可以以任意顺序出现。在某些场景中，在IPsec端点之间只需要个单独的CHILD_SA，因此这里就不存在额外的交换。随后的交换可以被用于在相同的经过认证的端点对之间建立额外的CHILD_SA，以及执行内部事务管理功能。
IKE消息流总是以一个请求紧跟着一个响应的方式出现。这样请求者可以确保可靠性。如果响应在一个超时间隔内没有被收到，请求者就需要重传这个请求（或者断开链接）。IKE会话的第一个请求/响应消息（IKE_SA_INIT）为IKE_SA协商安全参数，发送临时随机数2
（nonce），并发送DiffieHellman值。YD/T 1897-2009
第二个请求/响应（IKE_AUTH）传输标识符，检验符合两个标识符的安全信息，以及为第一个（通常只有一个）AH和/或ESPCHILD_SA建立SA。随后的交换类型是CREATE_CHILD_SA（创建一个CHILD_SA）和INFORMATIONAL（删除SA，报告错误条件，或者做其他事务管理）。每个请求要求一个响应。没有载荷的INFORMATIONAL请求（不同于通过语法请求的空加密载荷）通常被用于检查存活状态。这些后续的交换只有在初始的交换完成之后才能使用。
在下面的描述中，我们假设没有错误发生。对可能发生错误的数据流的调整在第5.21节描述。4.2使用场景
IKE可以被用于不同场景下的ESP和/或者AHSA的协商，每个都具有自己特定的要求。4.2.1安全网关到安全网关隧道
在图1所示的这种场景下，IP连接的任意一个端点都没有实现IPsec，但是它们之间的网络节点在部分路径上保护流量。这种保护对于端点是透明的，并且依赖于发送数据报通过隧道端点的普通路由。每一个端点都应该宣告一系列在它“后面”的地址，并且数据报应该按照隧道模式被发送，隧道模式是指内部的IP头应该包含实际的端点的IP地址。被保护
的子网
4.2.2端点到端点传输
IPsec隧道
图1安全网关到安全网关隧道免费标准下载网bzxz
被保护
的子网
在图2所示的这种场景下，两个IP连接的端点都实现了IPsec，遵循IETFRFC4301（2005）中对主机的要求。传输模式通常没有内部IP头。如果存在内部IP头，内部头的地址应该和外部头的地址相同。被这个SA保护的数据包的单一地址对将被协商。这些端点可以给予参与方的IPsec认证标识符实现应用层接入控制。该场景能够实现端到端安全，并已经成为互联网的一个指导性原则，同时也是限制网络中固有问题复杂度的方法。尽管这个场景可能不能被完全应用于IPv4的互联网，但是它已经在某些使用IKEv1的企业网（Intranet）中的特定场景下被成功应用。IKE应该被广泛地应用于向IPv6的过渡中，并应采用IKEv2。
在这种场景中，可能一个或者两个被保护端点藏在NAT（网络地址翻译）节点之后，在这种情况下，被隧道封装的数据包采用UDP封装，以便UDP头中的端口号能够被用于标识藏在NAT后面的单独的端点（参见第5.24）。
被保护
的端点
4.2.3端点到安全网关隧道
IPsec传输或隧道模式SA
图2端点到端点
被保护
的端点
在图3所示的场景下，被保护的端点（典型例子是正在漫游的可移动计算机）通过IPsec保护的隧道连接回它自己的企业网。它可以只利用该隧道访问企业网信息，也可以利用隧道将自已的信息传回企3
YD/T1897-2009
业网，以便它能够利用企业防火墙的保护来抵御来自互联网的攻击。不管哪种情况，被保护的端点都将向安全网关获取IP地址，使得到它的数据包能够先到安全网关，然后再被隧道封装返回给该端点。这个IP地址可以是静态的，也可以由安全网关动态分配。对于后者，本标准包括了个在SA使用期内，发起者向安全网关请求P地址的机制。被保护
的端点
IPsec隧道
隧道端点
图3端点到安全网关隧道
被保护的子网
和/或Internet
在这个场景下，数据包将使用隧道模式。对于每一个来自被保护的端点的数据包，外部P头将包含同它当前位置一致的源地址（即：将直接获得路由到该端点的流量的地址），而内部IP头将包含分配给安全网关的源IP地址（即：将获得路由到安全网关的流量的地址，这些流量将被前转给该端点）。外部的目的地址总是安全网关的地址，而内部的目的地址则是数据包的最终目的地址。在这个场景下，被保护的端点可能隐藏在NAT之后。在这种情况下，安全网关看到的IP地址同被保护的端点发送的IP地址不同，数据包具有一个UDP的封装，以便能够被合适地路由。4.2.4其他场景
作为上述场景的组合而出现其他场景也是可能的。4.2.1和4.2.3场景组合就是一个明显的例子。个子网可以通过使用IPsec的远程安全网关来完成所有的外部访问，到达子网的数据包将被外部网络路由到安全网关。举例，虚拟地放在Internet上具有静态IP地址的某家庭网络，实际上，其连接是由ISP通过分配一个单独的动态P地址给用户安全网关来提供的(这里的静态IP地址和IPsec中继由位于其他地方的第三方提供）。
4.3初始交换
IKE通信总是从IKE_SA_INIT和IKE_AUTH交换开始。这些初始交换通常由4个消息组成，在某些场景下消息数目可能会增加。所有使用IKE的通信都由请求/响应对组成。首先描述基本的交换，然后是一些变化。第个消息对（IKE_SA_INIT）协商加密算法，交换临时随机数和Diffie-Hellman交换。第二个消息对（IKE_AUTH）认证先前的消息，交换标识符和证书，建立第个CHILD_SA。部分消息通过IKE_SA_INIT交换建立的密钥进行加密和完整性保护，所以标识符对窃听者是隐藏的，并且在所有消息中的字段都是被认证的。在表1的描述中，列举了消息中包含的载荷的名称。表1消息中载荷的名称
CERTREQ
证书请求
可扩展认证协议
IKE头
有效载荷
Ni, Nr
发起者标识
响应者标识
密钥交换
表1（续）
有效载荷
临时随机数（i表示发起者，r表示响应者）通知
安全联盟
流量选择器发起者
流量选择器响应者
厂商ID
YD/T 1897-2009
每个载荷的详细内容在第6章描述。可选的载荷显示在中括号中，例如[CERTREQ]，表明载荷中包含的证书请求可选。
初始的交换如下所示：
发起者
HDR, SAil, KEi, Ni
响应者
HDR包含安全参数索引（SPI)，版本号，和不同种类的标志。SAi1载荷声明了发起者支持IKE_SA的加密算法。KE载荷发送发起者的Diffie-Hellman值。Ni是发起者的临时随机数。HDR, SAr1, KEr, Nr, [CERTREQ]响应者从发起者提供的选择中选择加密族，并且在SAr1载荷中表达这种选择，使用KEr载荷完成Diffie-Heliman交换，并且通过Nr载荷发送它的临时随机数。在这个阶段，每一个参与方都能产生SKEYSEED，IKE_SA的所有密钥都是继承自它。几乎所有后面的消息头都是加密的，且完整性受到保护。用于加密和完整性保护的密钥继承自SKEYSEED，并且被称为SK_e（加密）和SK_a（认证，也称为完整性保护）。SK_e和SK_a在每个方向上都分别进行计算。除了继承自DH值的，用于IKE_SA保护的SK_e和SK_a密钥外，另外一批SKd也计算出，并被用于引出将来的CHILD_SA建立过程。符号SKI..)显示了那些被加密和被完整性保护的载荷使用了那个方向的SK_e和SK_a。
HDR,SK (IDi,[CERT,] [CERTREQ,] [IDr,]AUTH, SAi2,TSi, TSr)
发起者使用IDi载荷声称它的身份，证明和IDi一致的秘密信息，以及使用AUTH载荷保护第一个消息内容的完整性（参见第6.8节）。它也可以通过CERT载荷发送它的证书，并且在CERTREQ载荷中列出它所信任的CA。如果包含了任何CERT载荷，则第一个被提供的证书必须包含用于验证AUTH字段的公开密钥。可选的载荷IDr使得发起者能够指明它想和哪个响应者的标识进行对话。这对于正在运行的响应者在使用相同的IP地址，但具有多个标识符的主机时，是非常有用的。最后的字段（以SAi2开始）在CREATE_CHILD_SA交换中进行描述。<-
HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr
响应者使用IDr载荷说明它的标识符，可选发送个或者多个证书（证书中包含用于验证AUTH的5
YD/T1897-2009
共开密钥），使用AUTH载荷来认证它的标识符和第二个消息的完整性，通过下节描述的CREATE_CHILD_SA交换完成CHILD_SA的协商消息3和4的接收必须验证所有被正确计算的签名和MAC，验证符合用于产生AUTH载荷的密钥的ID载荷中的名字。
4.4CREATE_CHILD_SA交换
这个交换由一个单一的请求/响应对。它可以在初始交换完成之后由IKE_SA的任意一端引发。紧随初始交换后的所有消息都被使用，和在IKE交换中的前两个消息中协商的加密算法与密钥，进行加密保护。这些随后的消息使用在第6.14节描述的加密载荷的语法。所有的消息都在一个加密载荷中，即使它们内容为“空的”。
任意一个端点都可以发起CREATE_CHILD_SA交换，所以在这章中术语“发起者”指发起交换的端点。
CHILD_SA通过发送一个CREATE_CHILD_SA请求被创建。CREATE_CHILD_SA请求包括一个KE载荷，进行额外的Diffie-Hellman交换，以便能够使CHILD_SA的加密更加健壮。CHILD_SA的密钥原料来自在IKE_SA建立期间被建立的SK_d函数，在CREATE_CHILD_SA交换进行交换的临时随机数，以及Diffie-Hellman值（如果在CREATE_CHILD_SA交换中包含了KE载荷）。当CHILD_SA作为初始交换的一部分时，第二个KE的载荷和临时随机数不需要被发送。来自初始交换的临时随机数被用于计算CHILD_SA的密钥。CREATE_CHILD_SA请求包括：
发起者
HDR, SK {[N], SA, Ni,[KEi],
[TSi,TSr]]
响应者
发起者在SA载荷中发送SA，在Ni载荷中发送临时随机数，可选在KEi载荷中发送Diffie-Hellmar值，以及在TSi和TSr载荷中发送建议的流量选择器。如果这个CREATE_CHILD_SA交换是为一个不为IKE_SA的，已建立的SA重新协商密钥时，第一个REKEY_SA类型的N载荷必须表明这是SA重新分配密钥。如果这个CREATE_CHILD_SA交换不是给-个已经存在的SA重新分配密钥，这N载荷必须被忽略。如果SA包括不同的Diffie-Hellman组，KEi必须是发起者期望接收者接收的组的元素。如果他猜错了，那么CREATE_CHILD_SA交换将失败，并且它将使用不同的KEi重试。紧随着IKE头的消息经过加密，这些消息包括头，由被IKE_SA协商的加密算法进行完整性保护。CREATE_CHILD_SA响应包括：
HDR, SK {SA, Nr, [KEr],
[TSi,TSr]
响应者在SA载荷中回应接收到的SA（使用相同的消息ID），并且如果请求中包含KEi，以及被选择的加密族包括那个组，响应者将Diffie-Hellman值包含在KEr载荷中。如果响应者选择了不同组的加密族，他必须拒绝这个请求。发起者应该使用来自响应者选择的组中的KEi载荷，重复发送请求。TS载荷中规定了用于送往该SA流量的流量选择器，它可以是CHILD_SA建议的发起者的一个子集。如果这个CREATE_CHILD_SA轻轻被用于交换IKE_SA密钥，流量选择器应该被忽略。6
4.5INFORMATIONAL交换
YD/T1897-2009
在IKE_SA操作的不同阶段，对方可以要求互相传送控制信息，而不管特定事件的错误或者错误通知。为了完成这些，IKE定义了INFORMATIONAL交换。INFORMATIONAL交换必须只在初始交换完成之后出现，并且使用协商的密钥进行加密保护。属于IKE_SA的控制信息必须在那个IKE_SA下被发送。属于CHILD_SA的控制信息必须在产生他们的IKE_SA的保护下被传送（或者，如果IKE_SA因为重新分配密钥的原因被替代了，应该在IKE_SA的继任者的保护下被传送）。
INFORMATIONAL交换的信息包含O个或者多个错误通知载荷，删除载荷和配置载荷。INFORMATIONAL交换请求的接收者必须发送响应（否则发送者将认为这些消息在网络传输中丢失了，并重传他们。这些响应必须是没有载荷的消息。INFORMATIONAL交换的请求消息也可以不包含任何载荷。这种情况在一个端点验证另一个端点是否存活的情况下出现。ESP和AH的SA总是成对出现的，即每个方向上都存在着一个SA。当一个SA被关闭时，该对中的两个成员都必须被关闭。当SA被嵌套时，即相同端点对之间的数据（如果在隧道模式下，包括P头）首先使用IPComp封装，然后使用ESP，最后使用AH，所有的SA都必须被一起删除。任意一个端点必须关闭它的输入SA，并允许另一个端点关闭另一个SA。为了删除一个SA，具有一个或者多个删除载荷的INFORMATIONAL交换被发送，该交换中列出了被删除SA的SPI（当他们可能会出现在入站数据包的头中时）。接收者必须关闭指定的SA。通常，INFORMATIONAL交换的响应包含删除载荷，该载荷用于去往其他方向的SA。但是也有一个例外情况。如果碰巧，一组SA的两端同时单独决定关闭它们，每一个端点都可能发送个删除载荷，这样两个方向上的请求可能在网络中一起出现。如果一个节点收到了对SA的删除请求，但是它已经发出了删除该SA的请求，该节点必须在处理请求时，删除输出的SA；而在处理响应时，删除输入SA。在那种情况下，响应不必包含被删除SA的删除载荷，因为那样将导致多个删除，并且在理论上可能删除错误的SA。节点应将半关闭的连接看作是反常的，并且审计他们应该保持的连接。注意，本标准没有规定时间期，应该由独立的端点来决定应等待多长时间。节点可以拒绝接收来自半关闭连接的数据，但不能单方面的关闭他们，以及重用SPI。如果连接状态已经变得足够混乱，节点可以关闭IKE_SA；这样做将隐含关闭在其之下协商的所有SA。然后它可以在一个新的IKE_SA下，一个干净的数据库中重建SA。INFORMATIONAL交换定义如下：
发起者
HDR, SK [[N,I [D,] [CP,] ...] -->接收者
<--HDR, SK ([N,] [D,J [CP], ...]INFORMATIONAL交换的处理由它的载荷构成决定。4.6IKE_SA之外的INFORMATIONAL消息如果具有不可知的SPI加密的IKE数据包到达端口500或者4500，可能是因为接收节点最近刚刚岩机，或者状态丢失，也可能因为其他的系统故障或者攻击。如果接收节点具有到数据包源P地址的激活的IKE_SA，它可以通过INFORMATIONAL交换经由这个IKE_SA发送不正确数据包的通知。如果接收节点不具备这样的IKE_SA，它可以发送一个没有加密保护的INFORMATIONAL消息到源IP地址。该7
YD/T1897-2009
消息不是INFORMATIONAL交换的一部分，接收节点不需要响应它。进行这样的操作可能会形成消息环路。
5IKE协议细节及变化
5.1概述
尽管可能在UDP端口4500以稍有不同的格式接收到IKE消息，但IKE通常在UDP端口500侦听和发送。由于UDP是不可靠的数据包协议，IKE包含了从传输错误中恢复的规定，包括丢包、数据包重放、数据包伪造。IKE设计成发生以下情况时还可以工作：（1）在超时之前，被传输的一系列数据包中至少有一个数据包到达了目的地。（2）信道还没有充满了重放和伪造的数据，以至于耗尽网络或任一端节点的CPU资源。即使没有这些最低的性能要求，IKE设计成可以明确表示失效的协议。所有IKEv2的实现应能够发送、接收并处理最长1280字节的IKE消息，并建议能够发送、接收并处理最长3000字节的消息。建议IKEv2的实现考虑所支持的最大UDP消息长度，并且如果通过丢弃一些证书或加密族建议可使得消息长度小于最大值，则可通过该方法使消息变短。可能时，使用“哈希（Hash）与URL”格式，而不是使用证书，可避免大多数问题。但是，要牢记实现及配置，如果只有在IPsecSA实现后才能进行URL查找，递归问题会导致该技术无法工作。5.2重传定时器的使用
所有IKE消息以请求和响应成对出现。IKE_SA的建立通常包含两个请求/响应消息对。一旦IKE_SA建立，安全联盟的任一端都能在任何时候发起请求，在任一给定的时刻，可能有许多传输中的请求和响应。但每一个消息只能被标记为请求或响应，对每一个请求/响应对，安全联盟的一端是发起者，另一端是响应者。
对每一对IKE消息，发起者负责超时重传。除非收到重传的请求，响应者从来不应重传响应。在这种情况下，响应者在考虑重传的请求触发响应的重传之外，应忽略重传的请求。发起者应记住每个请求直到收到了相应的响应。响应者应记住每个响应直到收到了一个请求且该请求的序列号大于响应中的序列号与窗口大小的和（见5.4节）。IKE是个可靠的协议，因为发起者应重传请求直到收到了相应的回复或者可以确信IKE安全联盟失效并丢弃了所有与IKE_SA及协商使用该IKE_SA的任一CHILD_SA相关联的所有状态。5.3消息ID序列号的使用
每一个IKE消息都包含一个消息ID作为其固定消息头的一部分。该消息ID用于请求和响应的匹配并用来识别重传的消息。
消息ID为32比特位，对于每一个方向上的第一个IKE请求值为0。最初IKE_SA建立的消息序号总是0或者1。IKE安全联盟的每一个终端维护两个“当前”消息ID：将要发起的下一个请求的ID，期望从对端收到的下一个请求的ID。这些计数器随着发起或接收到的请求而增加。响应总是与相应的请求具有相同的ID。这意味着在初始交换之后，每一个整数n都可能作为消息ID在4种不同的消息中出现起始IKE发起者的第n个请求及相应的应答，起始IKE响应者的第n个请求及相应的应答。如果两端使用差异很大的请求序号，那么两个方向的消息ID也将会有很大差异。消息头的I和R比特位指定了消息属于以上4种中的哪一种，因为消息的类型是非常明确的。消息D是加密的，用来防止重放攻击。一种不太可能的情况是消息ID增长到太大能填充完32比特，此时IKE_SA应被终止。重新建立IKE_SA来重设序列号。8