The Cable Guy - 2002年6月
针对IPSec安全关联的IKE协商
欲了解关于The Cable Guy所主持的所有专栏的列表和更多信息,请点击此处。
为确保进行顺利和安全的Internet协议安全(IPSec)通信,Internet密钥交换(Internet Key Exchange,IKE)协议将执行一项双阶段协商。IKE同时接和了Internet安全关联密钥管理协议(ISAKMP)和Oakley密钥确定协议的组合。对于Windows 2000和Windows XP的IPSec实施,这两个阶段分别是主模式(Main Mode)和快速模式(Quick Mode)协商。
主模式
主模式(也称为第1阶段)IKE协商在两台计算机之间建立一个称为ISAKMP安全关联(Security Association,SA)的安全通道。ISAKMP SA用于保护安全协商。为实现这个目标,主模式协商将确定特定的一组密码保护套件(cryptographic protection suite),交换加密材料来建立共享秘密密钥,以及对计算机身份进行身份验证。
快速模式
快速模式(也称为第2阶段)IKE协商在两台计算机之间建立一个通道来保护数据。由于这个阶段涉及SA(代表IPSec服务进行协商)的创建,因此在快捷模式期间建立的SA称为IPSec SA。在快捷模式期间,加密材料将被刷新,或在必要时生成新的密钥。在此期间还会选择一个用于保护特定IP流量的保护套件。快速模式没有被看作是完整的交换,因为它依赖主模式交换。
本页内容
ISAKMP消息
主模式协商
快速模式协商
更多信息
ISAKMP消息
ISAKMP消息是源和目标UDP端口被设置为500的UDP消息的有效负载,由一个ISAKMP报头和一个或多个ISAKMP有效负载组成。ISAKMP有效负载包含协商信息,并且对大多数ISAKMP消息来说都是加密的。加密保护了大多数协商避免被捕获了ISAKMP流量的恶意用户所查看。
Windows 2000和Windows XP的IPSec用于主模式和快速模式协商的ISAKMP有效负载包括:
安全关联
包含推荐的保护套件的一个列表,或者为某个SA选定的一个保护套件。
开发商ID
包含开发厂商定义的一个字符串或一个数字,以便某个IPSec实施能够识别正在运行相同实现的IPSec对等方。开发商ID值必须是唯一的,并且通常是某个IPSec实施的设计者所创建的众所周知的文本的hash码。在Windows XP和Windows 2000的IPSec中,开发商ID值为: 0x1E-2B-51-69-05-99-1C-7D-7C-96-FC-BF-B5-87-E4-61-00-00-00-02。
密钥交换
包含Diffie-Hellman密钥交换过程的Diffie-Hellman公共密钥信息。
Nonce
包含一个仅使用一次的伪随机数。Nonces可提供中继信息。
Kerberos令牌
包含一个IPSec对等方的当前Kerberos令牌,IPSec对等方通过一个Kerberos密钥分发中心(Kerberos Key Distribution Center,KDC)使用它来对另一个IPSec对等方进行身份验证。
身份验证
包含用于识别和验证一个IPSec对等方身份的信息。
Hash
包含一个hash值,这个值是一个hash函数对一组字段或其他参数所执行的计算结果。Hash有效负载可用于提供IPSec对等方的完整性或身份验证。
证书请求
包含可信任的根认证中心(certification authoritie,CA)的一个列表,IPSec对等方从这些认证中心那里接受一个用于身份验证的证书或证书链。
证书
包含一个IP对等方的证书或证书链。
签名
包含一个数字签名,它是对一组字段或参数执行计算来得出的。 Signature有效负载在主模式协商的身份验证阶段中提供数据完整性和认可服务。
通知
包含控制信息,比如错误条件。
除了前四条消息之外,所有消息的其他有效负载都是加密的,并且根据所选择的身份验证方法而定。这些消息将在“主模式协商,第3部分:身份验证”一节中进行讨论。
主模式协商
主模式协商在以下三个部分中进行:
保护套件的协商
Diffie-Hellman交换
身份验证
主模式协商由一组六条ISAKMP消息的组成。发起者和响应者均发送3条消息。发起者是通过发送第一个ISAKMP消息来发起安全通信的IPSec对等方。响应者发送第二个消息,它是发起者正在向其请求安全通信的IPSec对等方。
前四条主模式消息未经加密,如下表(表 1)所示。
表1 主模式消息1至4
主模式消息 |
发送者 |
有效负载 |
---|---|---|
1 |
发起者 |
安全关联(包含建议)、开发商ID |
2 |
响应者 |
安全关联(包含一个选定的建议)、开发商ID |
3 |
发起者 |
密钥交换(包含Diffie-Hellman公共密钥)、Nonce、附加的有效负载(取决于身份验证方法) |
4 |
发送者 |
密钥交换(包含Diffie-Hellman公共密钥)、Nonce、附加的有效负载(取决于身份验证方法) |
主模式协商第1部分:保护套件的协商
当发起IKE交换时,发起者基于所应用的安全策略建议一个保护套件。每个建议的保护套件包括加密算法、hash算法、身份验证方法和Diffie-Hellman Oakley组的属性。主模式协商第1部分包含在主模式消息1和2中。
下表(表2)列出了Windows XP和Windows 2000中的IPSec当前实现所支持的保护套件属性值。
表 2 主模式保护套件属性值
属性 |
属性值 |
---|---|
加密算法 |
DES、3DES |
完整性算法 |
MD5、SHA-1 |
身份验证方法 |
Kerberos、预共享的密钥、证书 |
Diffie-Hellman组 |
Group 1(768位)、Group 2(1024位) |
加密算法、完整性算法和Diffie-Hellman组被配置为多种密钥交换安全方法之一。这些方法可以通过**“密钥交换设置”对话框上的“方法”按钮来找到,而该对话框可以通过“IP安全策略”插件中的IPSec策略属性中的“常规”选项卡上的“高级”按钮来打开。身份验证方法是在IPSec规则的属性中的“身份验证方法”**选项卡上配置的。
最初的IPSec对等方推荐一个或多个保护套件,其顺序与所应用的安全策略的顺序相同。如果其中一个保护套件可接受,响应者将选择使用它,并使用这个选择来响应发起者。由于响应IKE对等方可能没有运行Windows XP或Windows 2000,并正在选择第一个可接受的推荐保护套件,因此所应用的安全策略中的保护套件应该在“IP安全策略”插件中从最安全到最不安全的顺序配置。由于密码分析学的发展,不应该使用DES来为IKE或通过封装安全有效负载(Encapsulating Security Payload,ESP)保护的数据提供保密性。
主模式协商第2部分:Diffie-Hellman交换
在协商保护套件之后,IPSec对等方使用CryptoAPI,基于协商的Diffie-Hellman Oakley组来生成一个Diffie-Hellman公用和专用密钥对。Diffie-Hellman公开密钥将在一个ISAKMP Key Exchange有效负载中发送给其他IPSec对等方。主模式协商第2部分包含在主模式消息3和4中。
Diffie-Hellman密钥对的加密强度与它的素数长度(也称为密钥尺寸)相关。 Windows 2000 IKE模块目前仅支持Diffie-Hellman Oakley Group 1(768位)和Group 2(1024位)。虽然这两个组都提供了避免传统攻击的安全性,但是Group 2被认为更加安全,因为它具有更大的密钥尺寸。然而,涉及基于Group 1的密钥的计算可能稍快一点,因为它们具有更小的素数尺寸。
在交换Diffie-Hellman公开密钥之后,IKE模块使用CryptoAPI,基于相互同意的身份验证方法来计算主模式主密钥(master key)加密材料。
主模式协商第3部分:身份验证
Windows XP和Windows 2000支持三种身份验证方法:
Kerberos(默认)
基于证书的数字签名
预共享密钥
对主模式协商执行的身份验证是基于计算机的身份验证(也称为基于机器的身份验证)。 身份验证过程检验计算机的身份,而不是检验身份验证过程发生时使用该计算机的单独用户。
Kerberos身份验证
提供Kerberos身份验证主要用于对公司网络中客户端到服务器的IPSec机器执行身份验证,在公司网络中,客户端和服务器是Windows 2000域或相互信任的域的成员。 在Windows XP和Windows 2000中,Kerberos身份验证基于通用安全服务(Generic Security Service,GSS)API IKE身份验证方法,这种身分验证方法在名为“针对IKE的GSS-API身份验证方法”的Internet草案中有所描述。下表(表3)列出了ISAKMP消息及其有效负载,这些消息在Kerberos身份验证主模式协商期间进行交换。
表 3 针对Kerberos身份验证方法的主模式消息
主模式消息 |
发送者 |
有效负载 |
---|---|---|
1 |
发起者 |
安全关联(包含建议)、开发商ID |
2 |
响应者 |
安全关联(包含一个选定的建议)、开发商ID |
3 |
发起者 |
密钥交换(包含Diffie-Hellman公用密钥)、Nonce、Kerberos令牌(发起者) |
4 |
响应者 |
密钥交换(包含Diffie-Hellman公用密钥)、Nonce、Kerberos令牌(响应者) |
5(已加密) |
发起者 |
Identification、Hash(发起者) |
6(已加密) |
响应者 |
Identification、Hash(响应者) |
身份验证发生在:
每个对等方检验其他对等方的Kerberos令牌的时候。响应者检验发起者的Kerberos令牌,发起者又检验响应者的Kerberos令牌。
每个对等方的hash被检验的时候。hash有效负载除了使用主模式主密钥来加密外,还使用Kerberos会话密钥进行加密。在使用主模式主密钥来解密hash有效负载之后,接收者使用Kerberos会话密钥来解密该有效负载并检验hash。
证书身份验证
为符合Internet标准,Windows XP和Windows 2000 IPSec对等方在主模式协商期间执行基于证书的数字签名身份验证。IKE模块使用CryptoAPI来检索将被发送的证书链,检验对等方证书和证书链,检查证书撤消,以及创建和检验数字签名。 所有证书、证书链和数字签名信息都在下表(表4)列出的主模式消息中进行交换。
表 4 用于证书身份验证方法的主模式消息
主模式消息 |
发送者 |
有效负载 |
---|---|---|
1 |
发起者 |
安全关联(包含建议)、开发商ID |
2 |
响应者 |
安全关联(包含一个选定的建议)、开发商ID |
3 |
发起者 |
密钥交换(包含Diffie-Hellman密钥)、Nonce |
4 |
响应者 |
密钥交换(包含Diffie-Hellman密钥)、Nonce、证书请求 |
5(已加密) |
发起者 |
识别、证书、证书请求、签名 |
6(已加密) |
响应者 |
识别、证书、签名 |
Windows XP和Windows 2000仅支持基于RSA的证书和数字签名。
通过发送一个证书请求(Certificate Request)有效负载,每个IPSec对等方都被指定于另一个IPSec对等方,而在身份验证方面,将仅接受一个来自CA所分发的证书,这个CA可沿着一个链追溯回可信任的根CA的列表中的某个CA。 受信任的根CA的列表是在“IP安全策略”插件的IPSec规则的属性中的**“身份验证方法”**选项卡上配置的。
当提交一个证书时,每个IPSec对等方使用CryptoAPI来从本地证书存储库中检索一个证书链。 每个IPSec对等方必须拥有该证书的专用密钥,并且该证书必须可沿着一个链追溯回所列出的可信任的根CA之一,这些根CA是由其他IPSec对等方在接收到的证书请求有效负载中发送的。证书链(不带根证书)将插入一个证书有效负载,并发送给其他IPSec对等方。每个IPSec对等方还在ISAKMP 签名有效负载中包括一个数字签名,从而提供证据来表明提交证书的IPSec对等方已访问过所提交的证书的专用签名密钥。
当每个对等方检验其他对等方的证书和数字签名时,证书身份验证就是成功的。
对于IPSec连接上的L2TP,可信任的根证书的列表是不可配置的。相反,在主模式消息4和5的证书请求有效负载中发送的受信任的根CA列表包含这样的根CA,即它安装了这些根CA的一个对应的计算机证书。对于IPSec连接上的L2TP,IPSec对等方必须拥有通过一个可信任的公共根CA分发的计算机证书,或者使用允许客户端和服务器证书得到相互信任的交叉证书。 每个对等方都必须能够使用其他对等方的证书来对自己的计算机构建证书根CA的信任链。
预共享密钥方法
预共享密钥IKE身份验证要求每个IKE对等方使用一个预定义和共享的密钥来对IKE交换执行身份验证。Windows XP和Windows 2000都支持RFC 2409中规定的预共享密钥身份验证方法。预共享密钥是在“IP安全策略”插件中的IPSec规则的属性的**“身份验证方法”** 选项卡上配置的。
用于预共享密钥IKE身份验证的主模式消息在下表(表5)中列出。
表 5 针对预共享密钥身份验证方法的主模式消息
主模式消息 |
发送者 |
有效负载 |
---|---|---|
1 |
发起者 |
安全关联 (包含建议)、Vendor ID |
2 |
响应者 |
安全关联 (包含一个选定的有效负载)、开发商ID |
3 |
发起者 |
密钥交换(包含Diffie-Hellman公开密钥)、Nonce |
4 |
响应者 |
密钥交换(包含Diffie-Hellman公开密钥)、Nonce |
5(已加密) |
发起者 |
识别、Hash (发起者) |
6 (已加密) |
响应者 |
识别、Hash(响应者) |
发起者和响应者Hash计算整合了预共享密钥的值。每个IPSec对等方都计算其他对等方的hash,并将它与接收到的消息中的Hash有效负载中的值作比较。如果两个hash值都有效,那么身份验证就是成功的。
快速模式协商
在主模式协商完成或现有IPSec SA过期时,快速模式协商将基于适当的过滤器操作来发起。这其中包括关于特定的加密和hash算法、链路是隧道还是传输、协议是ESP和/或AH的规定。所有快速模式协商消息都使用主模式期间建立的ISAKMP SA来保护。每次快速模式协商将建立两个IPSec SA。一个SA针对传入的流量,另一个SA针对传出的流量。
下表(表6)列出了运行Windows XP或Windows 2000的两个IPSec对等方之间交换的快速模式消息。
表 6 快速模式消息
快速模式消息 |
发送者 |
有效负载 |
---|---|---|
1(已加密) |
发起者 |
安全关联(包含建议)、识别(包含安全流量描述)、Nonce |
2(已加密) |
响应者 |
安全关联(包含一个选定的建议)、识别(包含安全流量描述)、Nonce |
3(已加密) |
发起者 |
Hash |
4(已加密) |
响应者 |
通知 |
这四个快速模式消息如下:
包括一个安全关联有效负载——其中包含用来保护流量的加密和hash算法建议列表(AH与ESP、DES与3DES和MD5与SHA)、一个识别有效负载——其中包含对被保护的流量的描述(IP地址、IP协议、TCP端口或UDP端口),以及一个Nonce有效负载。
加密和hash算法是在“IP安全策略”插件中的IPSec过滤器操作属性中的**“安全方法”**选项卡上配置的。
IP流量描述是在“IP安全策略”插件中作为一个IPSec过滤器列表来配置的。
将Commit位设置为ISAKMP报头,并包括一个Security Association有效负载(包含选定用于保护流量的方法)、一个Identification有效负载,以及一个Nonce有效负载。 Commit位用于确保SA在发送被保护的数据之前完成其协商。
包括一个Hash有效负载,它提供检验和重放(replay)保护。
包括一个通知有效负载,它包含"已连接"通知消息。 这个消息由运行Windows XP或Windows 2000的IPSec对等方使用,它不是IKE标准所必需的。 它用于防止发起者在响应者准备好接收之前向响应者发送受IPSec保护的包。
如果在过滤器操作上启用了会话密钥完美转发保密(session key perfect forward secrecy),快速模式消息1和2还包含Key Exchange有效负载来执行Diffie-Hellman密钥交换,从而得出快速模式会话密钥。
在快速模式协商完成之后,将存在三个SA:
ISAKMP SA,它同时由双方对等方用于保护未来的主模式或快速模式协商。
传出IPSec SA,它由IPSec对等方用来保护传出到其他IPSec对等方的数据。
传入IPSec SA,它由IPSec对等方用来保护从其他IPSec对等方传入的数据。
IPSec对等方的传出IPSec SA是其他IPSec对等方的传入IPSec SA。
更多信息
欲了解关于IPSec的更多信息,请参考以下资源:
Windows 2000 Server文档(网络\Internet协议安全)
Internet协议安全(“Windows 2000 Server 资源包”部分章节)
探索Windows 2000中的对等IPSec(The Cable Guy 2001年5月专栏)
IETF IP 安全协议工作组(IPSec RFC和Internet草案)
在Windows 2000和XP中使用IPSec(SecurityFocus.com文章)
在Windows和XP中使用IPSec,第二部分 (SecurityFocus.com文章)
在Windows 2000和XP中使用IPSec:第三部分(SecurityFocus.com文章)
如对本专栏的内容有任何疑问或想发表反馈信息,请致信Microsoft TechNet。
欲了解关于The Cable Guy所主持的所有专栏的列表和更多信息,请点击此处。