Windows ipsec 简介

简介

当您创建 IPsec 策略时，您需配置 IPsec 规则（这些规则确定 IPsec 的行为）以及设置（设置的应用与配置的规则无关）。 配置 IPsec 策略后，必须将该策略指派给一台计算机才能实施该策略。 虽然在一台计算机上可以存在多个 IPsec 策略，但每次只能将一个 IPsec 策略指派给一台计算机。

IPsec 规则确定 IPsec 必须对哪些类型的通信流进行检查；是允许通信流、阻止通信流还是协商安全性；如何对 IPSec 对等方进行身份验证；以及其他设置。 配置 IPsec 规则时，您可以配置筛选器列表，该列表包含一个或多个筛选器、筛选器操作、身份验证方法、连接类型和 IPsec 封装模式（传输模式或隧道模式）。 IPsec 规则通常是针对特定用途（例如，“阻止所有从 Internet 到 TCP 端口 135 的入站通信流”）配置的。

筛选器定义了要检查的通信流（这与防火墙规则类似）以及源和目标 IP 地址、协议和端口号（如果适用）。 筛选器操作定义了网络通信流的安全性要求。 您可以配置筛选器操作以允许通信流、阻止通信流或协商安全性（协商 IPsec）。 如果将筛选器操作配置为协商安全性，则还必须配置各种密钥交换安全措施（以及这些方法的优先顺序）、是否接受最初传入的无安全保护的通信流、是否允许与不支持 IPsec 的计算机进行无安全保护的通信以及是否使用完全向前保密 (PFS)。

密钥交换设置和密钥交换安全措施确定了 IPsec 协议线格式（验证头 (AH) 或封装式安全措施负载 (ESP)）、加密和哈希算法、密钥生存期以及配置 Internet 密钥关联 (IKE) 主模式和 IPsec 安全关联 (SA) 所必需的其他设置。 SA 是与密钥资料相关联的安全性设置协议。 在第一次 IKE 协商阶段创建的 SA 被称为 IKE 主模式 SA（亦称为 ISAKMP 主模式 SA）。 IKE 主模式 SA 对 IKE 协商本身进行保护。 在第二次 IKE 协商阶段创建的 SA 被称为 IPsec SA（亦称为 IKE 快速模式 SA，这是因为每个 IKE 快速模式协商都为每个方向进行 IPsec SA 协商）。 IPsec SA 对应用程序通信流进行保护。

本节提供了有关以下重要 IPsec 策略概念的信息：

•	IKE 协商过程
•	IPsec 策略筛选器
•	安全措施
•	IPsec 协议线格式
•	IKE 身份验证
•	IKE 身份验证方法和安全措施优先顺序
•	安全协商选项

有关 IPsec 策略概念的详细信息，请参阅 Microsoft Windows Server™ 2003 的帮助和支持中心。

返回页首

IPsec 策略筛选器

筛选器是 IPsec 策略最重要的组成部分。 如果您未在客户端策略或服务器策略中指定正确的筛选器，或者如果 IP 地址已更改，但该策略的筛选器却未更新，则安全性就会得不到保障。 IPsec 筛选器被插入到计算机上的 TCP/IP 网络协议堆栈的 IP 层，因此这些筛选器可以对所有入站或出站 IP 数据包进行检查（筛选）。 除了稍有延迟之外（在两台计算机之间协商安全性关系必然引起延迟），IPsec 对于最终用户应用程序和操作系统服务来说是透明的。 筛选器依据 IPsec 策略中的安全性规则与相应的筛选器操作相关联。 Windows IPsec 同时支持将 IPsec 隧道模式和 IPsec 传输模式用作此规则的选项。 IPsec 隧道模式规则的配置与 IPsec 传输模式规则的配置有很大差异。

与 IPsec 策略相关联的筛选规则与防火墙规则类似。 通过使用 IP 安全策略管理 Microsoft 管理控制台 (MMC) 管理单元提供的图形用户界面 (GUI)，可以将 IPsec 配置为根据源与目标地址组合以及特定协议和端口来允许或阻止特定类型的通信流。

注：Windows IPsec 并不是功能全面并基于主机的防火墙，它也不支持动态筛选功能或有状态筛选功能，例如在 TCP 握手期间跟踪已建立的位以控制通信流可以具有的流向。

了解 IPsec 筛选

筛选器列表仅仅是已知子网和基础结构 IP 地址的清单。 重要的是，您要了解包含在所有规则中的全部筛选器是如何组合到一起以提供所需的入站和出站访问控制的。 本节提供了非常重要的详细信息，通过这些详细信息，您就可以了解 IPsec 筛选器是如何影响数据包处理的。

Windows Server 2003 IPsec 监视器 MMC 管理单元提供了最详细的 IPsec 筛选器顺序视图。 当 IPsec 服务处理一组 IPsec 策略规则时，筛选器被复制为两类筛选器，从而对 IKE 协商的两个阶段进行控制：

1.	IKE 主模式筛选器。 这些筛选器仅使用 IPsec 策略中定义的筛选器源地址和目标地址来控制 IKE 主模式。 专用于 IKE 主模式的筛选器每个都有与之相关的 IKE 主模式协商策略，该策略定义了： • 使用密钥交换设置为 IPsec 策略定义的 IKE 主模式安全措施，例如 Diffie Hellman 主密钥强度和用于保护 IKE 协商本身的加密算法与完整性算法。 • IKE 主模式生存期以及对根据同一主密钥生成的会话密钥数的限制。 • 身份验证方法。
2.	IKE 快速模式筛选器。 这些筛选器包含有关地址、协议和端口的全部筛选器信息。 IKE 快速模式对此筛选器定义进行协商，以确定在 IPsec 安全关联对内部可以对哪些通信流进行保护。 每个特定的筛选器都有相应的权值和一组安全措施，这些安全措施定义了： • 传输模式或隧道模式下的 AH 或 ESP 封装选项。 • 加密算法与完整性算法列表。 • IPsec 安全关联的生存期（以千字节和秒计）。 • 完全向前保密安全设置。

专用于 IKE 快速模式的筛选器就是对 IPsec 驱动程序指定的要强制实施的那些筛选器。 IPsec 驱动程序按照最高权值指定的顺序来将所有入站和出站 IP 通信流与这些筛选器进行匹配。 以下关于 IKE 协商过程的部分描述了 IKE 是如何使用这些策略控制来协商和管理 IPsec 安全关联的。

IPsec 策略中定义的筛选器之所以被看作“一般”筛选器，是因为它们可能已在该策略应用时被 IPsec 服务解释。 在计算机上应用（或更改）IPsec 策略时，IPsec 服务将所有的一般筛选器解释为特定的筛选器。 特定的筛选器具有内置的计算权值的算法或顺序，在选择通信流时，顺序也被称为筛选器的特定程度。 权值越大，筛选器就越特定。 所有这些特定筛选器都根据它们的权值排序。 筛选器权值是依次根据筛选器中可能定义的 IP 地址、协议和端口计算的。 这种方法确保策略中的规则顺序、每个不同筛选器列表中的筛选器顺序，不会对 IPsec 驱动程序在数据包处理期间强制实施的筛选行为产生影响。 数据包首先与最特定的筛选器进行匹配，从而最大程度地缩短根据全部筛选器处理每个数据包所需的时间。 与某个数据包相匹配的最特定筛选器所对应的筛选器操作就是对该数据包执行的唯一操作。 可以定义的最具一般性的筛选器就是与任何 IP 地址、所有协议和端口都匹配的那些筛选器。 例如，请考虑以下四个筛选器定义：

•	任何 IP 地址 <-> 任何 IP 地址，任何协议
•	任何 IP 地址 <-> 192.168.1.0/24，任何协议
•	任何 IP 地址 <-> 192.168.1.0/24，任何协议
•	任何 IP 地址 <-> 192.168.1.10/24，任何 TCP 源端口，目标端口为 25

“任何 IP 地址到任何 IP 地址”就是可以定义的最一般的筛选器。 仅有 Windows Server 2003 和 Windows XP Service Pack 2 (SP2) 支持此筛选器。 此筛选器通常与阻止操作配合使用以实现默认行为“全部拒绝”。如果使用此筛选器来阻止全部通信流，则其余更特定的筛选器可以被看作第一个筛选器的例外情况。 对于 Windows 2000 来说，受支持的最一般筛选器是“任何 IP 地址 <-> 子网，任何协议”或“任何 IP 地址 <-> 我的 IP 地址”（如果未使用子网）。

对于使用 TCP 端口 25 从任何 IP 地址到 192.168.1.10 的入站通信流以及从端口 25 发出的相应出站响应，全部四个筛选器都匹配。 由于第四个筛选器指定了目标 IP 地址、协议和端口号，所以它最为特定。 如果 IPsec 驱动程序强制实施全部这四个筛选器，则发往 TCP 端口 25 的入站数据包将只与第四个筛选器（也就是最特定的筛选器）匹配。 如果远程系统使用除端口 25 以外的其他端口来向 192.168.1.10 发送 TCP 通信流，则此通信流与第三个筛选器匹配。 最后，如果通信流被发送到 192.168.1.0 子网中除 192.168.1.10 以外的任何 IP 地址，则第二个筛选器对于该通信流来说就是最特定的筛选器。

潜在的筛选器设计问题

定义筛选器时，不应该使用某些源地址和目标地址组合。 如上所述，对于运行 Windows 2000 的主机而言，应该避免使用指定了“任何 IP 地址到任何 IP 地址”的筛选器。

一般来讲，策略包含的筛选器越多，对数据包处理性能的影响就越大。 这方面的性能影响通常表现为吞吐量下降、非页面缓冲池内核内存利用率提高以及 CPU 利用率提高。 对性能产生的影响是很难精确估算的，这是因为此影响取决于计算机上的总体通信流量、所处理的受 IPsec 保护的通信流量以及 CPU 负载。 因此，在进行规划时，应该考虑对 IPsec 策略设计进行性能测试。 除了在吞吐量非常高的计算机上，几百个筛选器的影响是不大可能被注意到的。

Windows 2000 未提供用于处理大量筛选器的优化措施。 IPsec 驱动程序必须按顺序扫描整个筛选器列表以查找相匹配的筛选器。

在 Windows XP 和 Windows Server 2003 中，采用了许多优化措施来提高筛选器处理速度，因此 IPsec 策略可以使用大量的筛选器。 使用了通用数据包分类器 (GPC) 驱动程序对具有“从 到 ”格式的筛选器（协议和端口不限）进行优化，因而查找速度极快。 GPC 几乎可以处理任意数目的这些筛选器，而吞吐量不会降低。 因此，倘若有足够的非分页内核内存来容纳整个筛选器列表，就可以很容易地支持使用“我的 IP 地址到 <特定免除 IP 地址>”格式的大型免除列表。 GPC 无法优化源和目标不具有特定 IP 地址的筛选器，这意味着“任何 IP 地址 <-> 特定 IP 地址（或子网）”筛选器将要求执行顺序搜索。 但是，实施措施相比 Windows 2000 已有改进。

使用“我的 IP 地址”在许多情况下也许是合适的，但对于具有许多 IP 地址的主机（如托管许多虚拟网站的 Web 服务器），也许会引起问题。 如果有大量的筛选器使用“我的 IP 地址”，则 IPsec 驱动程序数据包筛选操作可能会发生延迟。 在服务启动期间以及发生 IP 地址改变事件时，IPsec 服务需要处理那些 过滤器。 延迟问题可能会引起安全漏洞或者推迟 IPsec 安全连接的建立时间。 同样，应该通过测试性能来确认特定策略设计的影响是否可以接受。

当允许或拒绝发往特定端口或协议的通信流时，可能最适合使用“我的 IP 地址”。 例如，在 Woodgrove Bank 的 IPsec 策略设计中，使用了“我的 IP 地址”筛选器创建了一个更特定的筛选器，该筛选器允许在所有计算机之间使用明文收发 Internet 控制消息协议 (ICMP) 通信流。

如果对组织中的移动客户端分配了“我的 IP 地址 <-> 任何 IP 地址”规则，然后将其放在外部网中，则此移动客户端在该环境中可能无法进行通信。 如果允许该客户端回退到使用明文，它在连接到每个目标时都会出现三秒钟或更长时间的延迟。 如果目标使用 IKE 响应进行答复，则 IKE 协商会失败，这是因为 IKE 将无法使用域信任 (Kerberos) 来进行身份验证。 显然，如果将 RFC 1918 专用地址用作内部网络子网，则移动客户端在连接至酒店、家庭网络以及其他可能的内部网络时会受到影响。 如果移动客户端遇到连接问题，它们在连接至其他网络时可能需要本地管理员权限以停止 IPsec 服务。 因此，当移动客户端连接到内部网络时，可能需要使用域登录脚本来检查 IPsec 服务是否正在运行。

由于无法使用 IKE 协商来对使用多播地址和广播地址的数据包通信进行保护，所以 Windows 2000 最初未被设计成能够为此类数据包提供过滤。 因此，多播数据包类型和广播数据包类型是最初的默认免除（绕过 IPsec 筛选器）的部分内容。 请参阅 Microsoft 知识库 (KB) 文章 811832“IPSec Default Exemptions Can Be Used to Bypass IPsec Protection in Some Scenarios”(http://support.microsoft.com/kb/811832)，以了解默认免除对安全性影响的深入阐释以及默认情况下 Service Pack 3 为了除去某些免除而进行的更改。 在 Windows XP 和 Windows Server 2003 中，TCP/IP 与 IPsec 的集成已被增强为能够对所有类型的 IP 数据包进行筛选。 然而，由于 IKE 无法为多播和广播协商安全性，所以只提供了有限的筛选支持。 请参阅 KB 文章 810207“IPSec default exemptions are removed in Windows Server 2003”(http://support.microsoft.com/kb/810207)，以了解有关删除默认免除以及对多播和广播通信流的筛选支持程度的详细信息。 Windows XP SP2 与 Windows Server 2003 一样，都支持“任何 IP 地址 <-> 任何 IP 地址”筛选功能。

返回页首

IKE 协商过程

设计 IKE 协议的目的是为了帮助在每台计算机之间安全地建立信任关系、协商安全性选项以及动态生成共享的、加密密钥资料。 为了确保能够成功并且安全地进行通信，IKE 执行两阶段的操作：第一阶段（主模式）协商和第二阶段（快速模式）协商。 在每个阶段，通过使用两台计算机在安全协商期间认可的加密算法和身份验证算法，使机密性和身份验证得到保障。

主模式协商

在主模式协商期间，两台计算机建立安全并且经过验证的通道。 首先，对下列 IPsec 策略参数进行协商：加密算法（DES 或 3DES）、完整性算法（MD5 或 SHA1）、用于基本密钥资料的 Diffie-Hellman 组（组 1、组 2 或 Windows Server 2003 中的组 2048）以及身份验证方法（Kerberos V5 协议、公钥证书或预共享密钥）。 在对 IPsec 策略参数进行协商后，公用值的 Diffie-Hellman 交换就完成了。 Diffie-Hellman 算法用来生成计算机之间的共享密钥、对称密钥和加密密钥。 Diffie-Hellman 交换完成后，每台计算机上的 IKE 服务都生成用于帮助保护身份验证的主密钥。 配合协商算法和协商方法，主密钥用来验证身份。 然后，通信的发起方将潜在的 SA 提供给响应方。 响应方发送接受该内容的回复或者其他回复。 成功的 IKE 主模式协商将得到主模式 SA。

快速模式协商

在快速模式协商期间，建立一对 IPsec SA 来帮助保护应用通信流，此通信流可以包括通过 TCP、用户数据报协议 (UDP) 以及其他协议发送的数据包。 首先，对下列策略参数进行协商：IPsec 协议线格式（AH 或 ESP）、用于确保完整性和进行身份验证的哈希算法（MD5 或 SHA1）以及在要求进行加密时要使用的加密算法（DES 或 3DES）。 在此期间，达成一个有关在所建立的 IPsec SA 对中传送的 IP 数据包类型的公共协议。 IPsec 策略参数协商完毕后，就会刷新或交换会话密钥材料（每种算法的加密密钥和密钥生存期，分别以千比特和秒计）。

每个 IPsec SA 都由安全参数指数 (SPI) 标识，后者将被插入到所发送的每个数据包的 IPsec 标头中。 一个 SPI 标识入站 IPsec SA，另一个 SPI 标识出站 IPsec SA。

IKE 主模式 SA 和 IPsec SA

每次使用 IPsec 来帮助保护通信流安全时，就会建立一个 IKE 主模式 SA 和两个 IPsec SA。 在示例方案中，为了在 CORPCLI 与 CORPSRV 之间进行受 IPSec 保护的通信，建立了下列 SA：

CORPCLI [IP1] <-------- IKE main mode SA [IP1, IP2] -----> [IP2] CORPSRV

CORPCLI [IP1] ---------- IPsec SA [SPI=x] ------------------> [IP2] CORPSRV

CORPCLI [IP1] ---------- IPsec SA [SPI=x] ------------------> [IP2] CORPSRV

其中：

•	IP1 是 CORPCLI 的 IP 地址。
•	IP2 是 CORPSRV 的 IP 地址。
•	x 代表 SPI，它标识 CORPSRV 从 CORPCLI 获得的入站 IPsec SA。
•	y 代表 SPI，它标识 CORPSRV 发往 CORPCLI 的出站IPsec SA。

正如本总结所述，CORPCLI 与 CORPSRV 之间的 IKE 主模式 SA 是双向的。 两台计算机都可以通过使用 IKE 主模式 SA 提供的保护来启动快速模式协商。 IPsec SA 不依赖于上层协议的状态。 例如，建立和结束 TCP 连接时，IPsec SA 的工作不会中断，并且 IPsec SA 可以在 TCP 连接结束前到期。 在现有 IPsec SA 对的生存期过期前，IKE 将尝试使用快速模式协商建立两个新的 IPsec SA 对来进行重新协商，从而帮助防止连接中断。 虽然此过程通常被称为重新生成 IPsec SA 密钥，将实际上建立了两个新的 IPsec SA。 IKE 主模式 SA 的寿命仅按时间以及已尝试的 IPsec SA 数目度量（而不是按通过 IKE 协议传输的数据字节数度量）。 IKE 主模式 SA 的到期与 IPsec SA 对无关。 如果需要新的 IPsec SA 对，则将根据需要自动重新协商 IKE 主模式 SA（在主模式 SA 过期后）。 按照 Internet 工程任务小组 (IETF) 的设计，IKE 必须能够在任何一个方向上重新生成主模式 SA 密钥并协商 IKE 快速模式。 因此，两台计算机上的 IPsec 策略中为 IKE 主模式 SA 配置的身份验证方法应该确保能够在 IKE 主模式协商的发起方向上进行成功的身份验证。 同样，快速模式筛选器操作中的 IPsec 策略设置应该确保双向快速模式协商成功。

返回页首

安全措施

在 IKE 主模式协商期间，安全措施用来定义加密算法、哈希算法以及 Diffie-Hellman 组，而 Diffie-Hellman 组用来创建主模式 SA 以及帮助确保 IKE 协商通道的安全。 在快速模式协商期间，安全措施还用来定义封装模式（传输模式或隧道模式）、IPsec 协议线格式（AH 或 ESP）、加密算法和哈希算法以及用来创建快速模式入站和出站 SA 的密钥生存期。

返回页首

IPsec 封装模式和 IPsec 协议线格式

IPsec 通过对 IP 有效负载进行加密保护来对 IP 数据包中的数据进行保护。 所提供的保护依赖于 IPsec 的使用方式以及 IPsec 协议线格式。 您可以以传输模式或隧道模式使用 IPsec。

IPsec 封装模式

IPsec隧道模式最常用于对网络（如通过 Internet 实现的站点到站点联网）之间的站点到站点（也称为网关到网关或路由器到路由器）通信流进行保护。 使用 IPsec 隧道模式时，发送数据包的网关对整个原始 IP 数据包进行封装，其方法是创建一个新的 IP 数据包并通过其中一种 IPsec 协议线格式（AH 或 ESP）对其进行保护。 有关 IPsec 隧道模式的信息，请参阅 Windows Server 2003 部署工具包中的“Deploying Network Services”的“Deploying IPsec”一章，网址为 http://go.microsoft.com/fwlink/?LinkId=8195。

IPsec 传输模式用于对主机到主机的通信进行保护，并且它是 Windows IPsec 的默认模式。 使用 IPsec 传输模式时，IPsec 仅对 IP 有效负载进行加密，而不对 IP 标头进行加密。 在传输模式下，Windows IPsec 主要用于帮助保护端到端通信（如客户端与服务器之间的通信）。

IPsec 协议线格式

IPsec 支持两种协议线格式：AH 和 ESP。 IPsec 传输模式用 IPsec 标头（AH 或 ESP）来封装原始 IP 有效负载。

AH

AH 为整个数据包（既包括 IP 标头也包括数据包中包含的数据有效负载，IP 标头中允许在传输过程中发生改变的字段除外）提供数据来源身份验证、数据完整性以及反重放保护。 AH 未提供数据保密功能，这意味着它不对数据进行加密。 该数据可以被读取但不能被修改，从而防止了电子欺骗。 如下图所示，完整性和身份验证是通过在 IP 标头与 TCP 数据之间放置 AH 标头提供的。

图 A.1 数据包中的验证头
查看大图

要使用 AH，在适当规则的属性中，在“自定义安全措施设置”对话框中，选择“数据和地址不加密的完整性 (AH)”复选框，然后指定要使用的完整性算法。

ESP

ESP 提供了数据来源身份验证、数据完整性、反重放保护以及仅用于 IP 有效负载的保密选项。 在传输模式下，ESP 未通过加密校验和来保护整个数据包。 未对 IP 标头进行保护。 如下图所示，ESP 标头被放置在 TCP 数据之前，ESP 尾端和 ESP 身份验证尾端被放置在 TCP 数据之后。

图 A.2 数据包中的 ESP 数据
查看大图

要使用 ESP，在适当规则的属性中，在“自定义安全措施设置”对话框中，选择“数据完整性和加密 (ESP)”复选框，然后指定要使用的完整性算法和加密算法。

返回页首

IKE 身份验证

IKE 在计算机之间使用相互身份验证以建立受信任通信，并且，IKE 要求使用下列其中一种身份验证方法：Kerberos V5 协议、计算机 X.509 V3 公钥基础结构 (PKI) 证书或预共享密钥。 两个通信端点必须有至少一种公共的身份验证方法，否则通信将会失败。

IKE 身份验证过程

在 IKE 协商期间，IKE 发起方为响应方提供身份验证方法列表。 响应方使用发起方的源 IP 地址来确定 IKE 协商由哪个筛选器控制。 与响应方 IPsec 策略中的筛选器相对应的身份验证方法将被用来从发起方的列表中选择一种身份验证方法。 然后，响应方进行回复，将双方同意的身份验证方法通知发起方。 即使选择的身份验证方法失败，IKE 也不会提供一种途径来尝试使用另一种身份验证方法。 如果身份验证成功，并且主模式协商成功完成，则主模式 SA 将在 8 小时内有效。 如果 8 小时结束时仍在传输数据，则将自动重新协商主模式 SA。

IKE 身份验证方法

选择适合于 IPsec 策略的身份验证方法非常重要。 IPsec 策略规则使筛选器中的每个 IP 地址与一个身份验证方法列表相关联，以便 IKE 可以确定与每个 IP 地址配合使用的身份验证方法列表。

Kerberos V5 身份验证协议

Kerberos V5 协议是 Windows 2000 和 Windows Server 2003 Active Directory 域的默认身份验证标准。 域或受信任域中的任何计算机都可以使用这种身份验证方法。

使用 Kerberos 身份验证方法时，在主模式协商期间，每个 IPSec 对等方都以未加密格式将其计算机标识发送给另一对等方。 在主模式协商期间的身份验证阶段对整个标识有效负载进行加密之前，计算机标识是未加密的。 攻击者可以发送 IKE 数据包来使相应的 IPSec 对等方暴露其计算机标识和域成员资格。 因此，为了确保与 Internet 连接的计算机的安全，建议您使用证书身份验证。

默认情况下，在 Windows 2000 到 Windows 2000 Service Pack 3 以及 Windows XP 中，IPsec 筛选不对 Kerberos 协议通信流进行处理。 要对 Kerberos 协议通信流进行 IPsec 筛选处理，您必须修改注册表，然后添加适当的 IPsec 筛选器以确保此通信流的安全。 有关 Windows 2000 和 Windows Server 2003 中的默认免除的信息，请参阅 Microsoft 网站上的“Special IPsec considerations”以创建、修改和指派 IPSec 策略，网址为：
www.microsoft.com/resources/documentation/WindowsServ/
2003/standard/proddocs/en-us/sag_IPSECbpSpecial.asp。

公钥证书身份验证

在 Windows 2000 Server 中，您可以使用证书服务来在计算机证书的整个寿命周期内为 IPsec 自动管理那些证书。 证书服务与 Active Directory 和组策略集成在一起，它通过启用证书自动注册和续订以及提供一些与 IPsec 兼容的默认证书模板来简化证书部署。 要使用证书来进行 IKE 身份验证，您需定义所要使用的可接受根证书颁发机构 (CA) 有序列表，而不是定义所要使用的特定证书。 两台计算机在它们的 IPsec 策略配置中必须要有公用的根 CA，并且客户端必须要有相关联的计算机证书。

在证书选择过程中，IKE 将执行一系列检查以确保计算机证书的特殊要求得到满足。 例如，计算机证书必须要有长度大于 512 位的公钥并使用数字签名密钥用法。

注：在设置了高级选项“启用强私钥保护”的情况下从证书服务获取的证书不适用于 IKE 身份验证，这是因为您在 IKE 协商期间无法输入必需的个人识别码 (PIN)，因此无法访问计算机证书的私钥。

预共享密钥

如果您未使用 Kerberos 身份验证，并且无权访问 CA，则可以使用预共享密钥。 例如，在某些情况下，网络中的独立计算机可能由于（通过计算机的域帐户进行的）Kerberos 身份验证和 CA 提供的证书都无法成功地进行 IKE 身份验证而需要使用预共享密钥。

重要：预共享密钥容易实施，但使用不当会产生负面影响。 Microsoft 建议不要在 Active Directory 中使用预共享密钥身份认证，这是因为没有安全地存储密钥值，因此难以保密。 预共享密钥值以明文形式存储在 IPsec 策略中。 本地 Administrators 组中的任何成员都可以查看本地 IPsec 策略，任何具有 Local System 用户权限的系统服务都可以读取本地 IPsec 策略。 默认情况下，域中任何已通过身份验证的用户都可以查看存储在基于 Active Directory 的 IPsec 策略中的预共享密钥。 此外，如果攻击者可以捕获 IKE 协商数据包，攻击者就可以利用已发布的方法来发现预共享密钥值。
有关详细信息，请参阅“Authentication Vulnerabilities in IKE and Xauth with Weak Pre-Shared Secrets”，网址为：http://go.microsoft.com/fwlink/?LinkId=18769。

预共享密钥身份验证是为了实现互操作性而提供的，它符合 RFC 标准。 如果您必须使用预共享密钥身份验证，请使用 25 个字符或更长的随机密钥值，并且对每个 IP 地址对使用不同的预共享密钥。 这些措施会导致为每个目标生成不同的安全性规则，从而确保被破坏的预共享密钥只会危害那些共享该密钥的计算机的安全。

IPsec CRL 检查

如果使用基于证书的身份验证，则还可以启用 IPsec 证书吊销列表 (CRL) 检查。 默认情况下，在 Windows 2000 中，在 IKE 证书身份验证期间不会自动进行 IPsec CRL 检查。

要启用 IPsec CRL 检查

注意：错误地编辑注册表可能会严重地破坏系统。 在对注册表进行更改之前，您应该备份计算机上任何有价值的数据。

1.	在 HKEY_LOCAL_MACHINE/System/CurrentControlSet/ Services/PolicyAgent/ 下添加新的 Oakley 注册表项，并创建名为 StrongCrlCheck 的双字节项。
2.	对此项指定 0 与 2 之间的值，其中： • 值 0 禁用 CRL 检查（这是 Windows 2000 中的默认值）。 • 如果值为 1，则将尝试进行 CRL 检查，并且仅当证书已被吊销时才会导致证书验证失败（这是 Windows XP 和 Windows Server 2003 中的默认值）。 在进行 CRL 检查期间遇到的其他故障（如无法访问吊销 URL）不会导致验证证书操作失败。 • 如果值为 2，则启用强 CRL 检查，这意味着必须进行 CRL 检查，并且 CRL 处理期间遇到的任何错误都会导致证书验证操作失败。 请设置此注册表值以增强安全性。
3.	执行下列其中一项操作： • 重新启动计算机。 • 通过从命令提示符运行 net stop policyagent 和 net start policyagent 命令，停止并接着重新启动 IPsec 服务。 注：IPsec CRL 检查不能保证证书验证操作在证书被吊销时立即失败。 在将被吊销的证书放入已更新已发布 CRL 的时刻与执行 IPsec CRL 检查的计算机检索此 CRL 的时刻之间有一段延迟。 在当前 CRL 过期或下次发布 CRL 之前，计算机不会检索新的 CRL。 CryptoAPI 将 CRL 缓存在内存和 /Documents and Settings/UserName/Local Settings/Temporary Internet Files 中。 由于 CRL 不会由于计算机重新启动而丢失，所以，如果发生 CRL 高速缓存问题，重新启动计算机并不能解决该问题。

返回页首

IKE 身份验证方法和安全措施优先顺序

您可以配置仅指定了一种身份验证方法或一种安全措施的 IPsec 规则。 此外，您也可以指定身份验证方法和安全措施的优先列表。 优先顺序将应用于身份验证方法或安全措施，因此，您可以按照从最优先到最不优先的顺序来指定每种方法。 例如，您可以同时指定 Kerberos V5 协议和公钥证书身份验证来作为身份验证方法，但对 Kerberos 协议指定较高的优先顺序，如下图所示。

图 A.3 身份验证方法优先顺序

如果客户端尝试连接至 CORPSRV，却只接受使用公钥证书来进行身份验证，则 CORPSRV 使用此身份验证方法并继续进行通信。 使用所选身份验证方法时，IKE 协商必须成功，否则通信会被阻止。 即使协商失败，IKE 也不会尝试使用另一种身份验证方法。 同一原理也适用于安全措施，例如，ESP 可能比 AH 优先。

返回页首

安全协商选项

在筛选器操作的属性中，您可以在“安全措施”选项卡中配置 IPsec 策略是否允许回退到使用明文（回退到未受保护的通信）、是否允许入站通过和会话密钥 PFS。 在“密钥交换设置”对话框中，您可以在规则的一般属性中配置主密钥 PFS。

回退到使用明文

如果允许回退到使用明文，则 IPsec 将尽可能地保护通信流的安全（如果连接另一端的计算机支持策略包含补充性筛选器操作和筛选器的 IPsec），但是，如果对等方没有与安全协商请求相对应的 IPsec 策略，则以不安全的方式发送通信流。 如果对等方在三秒钟内未响应安全协商请求，则创建用于明文通信流的 SA（软 SA）。 软 SA 允许进行正常的 TCP/IP 通信，不进行 IPsec 封装。 请记住，虽然 IPsec 可能无法对此类通信流进行保护，但别的应用程序也许能确保此通信流的安全（例如，通信流可能受轻型目录访问协议 (LDAP) 加密或远程过程调用 (RPC) 身份验证机制的保护）。 如果对等方在三秒钟内未响应，并且安全协商失败，则与相应筛选器相匹配的通信将被阻止。

“回退到使用明文”设置允许与下列计算机进行互操作：

•	运行比 Wndows 2000 旧的操作系统的计算机
•	运行未配置 IPsec 策略的 Wndows 2000 或更旧系统的计算机
•	运行不支持 IPsec 的非 Microsoft 操作系统的计算机

要启用或禁用“回退到使用明文”，在“安全措施”选项卡上，在筛选器操作的属性中，选择或清除“允许和不支持 IPSec 的计算机进行不安全的通讯”复选框。

对于客户端策略来说，您可以启用或禁用此选项。 如果启用了此选项，并且服务器未响应客户端的协商安全性请求，则可以允许此客户端“回退到使用明文”。 如果清除了此复选框，并且服务器未响应客户端的协商安全性请求，则通信将被阻止。 在某些情况下，允许“回退到使用明文”非常有用。 但是，仅当未接收到答复时，IKE 才允许“回退到使用明文”。 为了确保安全，Windows IPsec 不允许在 IKE 协商失败时或者在 IKE 协商期间（在接收到答复之后）遇到诸如身份验证失败或无法达成安全参数协议之类的错误时进行未受保护的通信。

对于最初的部署，建议您选中此复选框，以便当服务器上的 IPsec 处于禁用状态时客户端可以“回退到使用明文”并建立初始连接。

入站通过

如果启用入站通过功能，则对于正常的入站 TCP/IP 通信流（未受 IPsec 保护的通信流，例如 TCP SYN 数据包）来说，如果它与筛选器操作的相关入站筛选器相匹配，则它会被接受。 上层协议响应数据包（例如，TCP SYN ACK 数据包）与相应的出站筛选器相匹配并触发安全协商。 协商好两个 IPsec SA 之后，两个方向上的通信流都受 IPSec 保护。 “入站通过”选项允许服务器使用默认响应规则来对客户端启动安全协商。 如果在客户端 IPsec 策略中启用了默认响应规则，客户端就不需要维护包含服务器 IP 地址的筛选器。 如果在客户端 IPsec 策略中未启用默认响应规则，您就不需要在服务器 IPsec 策略中启用“入站通过”选项。 此外，在连接到 Internet 的计算机上，绝对不应该启用此选项。

要启用或禁用入站通过，在筛选器操作的属性的“安全措施”选项卡中，选择或清除“允许不安全的通讯，但总是用 IPsec 响应”复选框。

会话密钥和主密钥 PFS

PFS 是一种机制，此机制确定主密钥的现有密钥资料是否可用来派生新的会话密钥。 PFS 确保单个密钥受到的危害只会影响到受 PFS 保护的数据，而不会影响到整个通信。 为此，PFS 确保用于保护数据传输的密钥不能用来生成其他密钥。 会话密钥 PFS 在使用时不需要进行重新验证，与主密钥 PFS 相比，所需资源较少。 如果启用了会话密钥 PFS，则会执行新的 Diffie-Hellman 密钥交换以生成主密钥的新的重新生成密钥信息。

如果在服务器策略中启用了会话密钥 PFS，则还必须在客户端策略中启用它。 您可以启用会话密钥 PFS，方法如下：在“密钥交换设置”对话框中，在规则的常规属性中，选择“使用会话密钥完全向前保密 (PFS)”复选框。 主密钥 PFS 要求进行重新验证，因而耗费的资源较多。 对于进行的每一次快速模式协商，主密钥 PFS 都要求进行新的主模式协商。 您可以通过选择“主密钥完全向前保密 (PFS)”复选框来配置主密钥 PFS。 如果在服务器策略中启用了主密钥 PFS，则不需要在客户端策略中启用它。 由于启用此选项会产生很大的开销，因此，建议您只在危险的环境中才启用会话密钥 PFS 或主密钥 PFS。在那些环境中，IPsec 通信流可能会暴露给老练的攻击者，他们会尝试攻破 IPsec 提供的强加密保护