IKEv1 Phase 2 的目的是建立用来安全传输数据的 IPsec SA，并为数据传输衍生出密钥；

Phase 2 采用快速模式（Quick Mode）。该模式使用 IKEv1 协商第一阶段中生成的密钥对 ISAKMP 消息的完整性和身份进行验证，并对 ISAKMP 消息进行加密，故保证了交换的安全性；

当建立 IKE SA 关系之后（无论通过主模式还是通过野蛮模式交换），便可用它为 IPSec 生成相应的 SA。IPSec SA 是通过 Quick Mode 交换来建立的，对快速模式交换来说，它是在以前建立好的 IKE SA 的保护下完成的；

概述交互过程

IKEv1 Phase 2 通过 3 条 ISAKMP 消息完成双方 IPsec SA 的建立：

快速模式共需要交换 3 个消息
1）在 MSG-1 和 MSG-2 中，交换 SA、KEY、Nonce、ID，用以协商算法、保证 PFS 以及提供“在场证据”
2）在 MSG-3 中：是用于验证响应者是否可以通信，相当于确认信息；

MSG-1

协商发起方，发送本端的安全参数和身份认证信息；
安全参数包括被保护的数据流和 IPsec 安全提议等需要协商的参数。身份认证信息包括第一阶段计算出的密钥和 Phase 2 产生的密钥材料等，可以再次认证对等体；

MSG-2

协商响应方，发送确认的安全参数和身份认证信息并生成新的密钥；
IPsec SA 数据传输需要的加密、验证密钥由第一阶段产生的密钥、SPI、协议等参数衍生得出，以保证每个 IPsec SA 都有自己独一无二的密钥；

MSG-3

发送方发送确认信息，确认与响应方可以通信，协商结束；

详细交互过程

在一次快速交换模式中，通信双方需要协商拟定 IPSec 安全联盟的各项特征，并为其生成密钥。IKE SA 保护快速模式交换的方法是：对其进行加密，并对消息进行验证。消息的验证是通过伪随机函数来进行的。来自 IKE SA 的 SKEYID_a 的值作为一个密钥，对快速模式交换的整个消息进行验证。这种验证除了能提供数据完整性保证之外，还能对数据源的身份进行验证：在消息接收到之后，我们知道它只有可能来自验证通过的实体，而且那条消息在传送过程并未发生改变。而通过加密（使用 SKEYID_e），则可保障交换的机密性；

快速模式需要从 SKEYID_d 状态中衍生出用于 IPSec SA 的密钥。随同交换的 nonce 以及来自 IPSec SA 的 SPI 及协议一道，这个密钥将在伪随机函数中使用，这样便可确保每个 SA 都有自己独一无二的密钥：每个 SA 都有一个不同的 SPI，所以入方向 SA 的密钥也会与出方向 SA 不同。所有 IPSec 密钥都是自相同的来源衍生的，所以相互间都有关联。假如一名攻击者能够根据 IKE SA 判断出 SKEYID_d 的值，那么就能非常容易地掌握自那个 SKEYID_d 衍生出来的任何 IPSec SA 的任何密钥。另外，还能继续掌握未来将要衍生的所有密钥！这显然是个大问题，所有这些密钥都不能保证所谓的“完美向前保密（PFS）”。快速模式为此专门提供了一个 PFS 选项，来满足这方面的需要，用户可根据自己地安全需要选择是否使用 PFS；

为了在快速模式交换中实现 PFS，需要执行一次额外的 DH 交换，最终生成的共享密钥将在为 IPSec 生成密钥的过程中用到。显然，一旦交换完成，这个密钥便不复存在。一旦完成，它所驻留的那个内存位置必须清零和释放。从而保证了密钥之间地不相关性；

我们前面将快速模式描述成一种简单的请求／响应交换，但它的实际功用远不止于此。发起者可能需要一个“在场”证据，证明响应者在线，而且已经实际地处理了它的初始快速模式消息。为了达到这个要求，响应者需亚在验证散列载荷中，加入交换的发起者 nonce 以及消息 ID。这个摘要现在不仅能保障消息的完整性，也能为发起者提供源验证功能，另外还能提供在场证据；

响应者也需要一个在场证据，从发起者传来的可能是一条过期的消息，是由不怀好意的人重播的。这个人可能不知道消息的内容，但通过对通信的分析，能够知道它是一条快速模式消息。如果重播那条消息，响应者便不得不创建多余的 SA。我们可将其想像成一种“服务否认”攻击，只是属于比较温和的那种，因为响应者会根据这条消息，增加不必要的内存及 SA 管理开销。想要防范此类攻击，需在快速模式交换中增加第三条消息。在这条消息中，发起者需要同时包括 nonce 和此次交换的消息 ID，并把它们保存在一个验证散列载荷中。这样发起者便可向响应者证实：自己是此次交换的活动参与者；

在前两条消息中，发起者和响应者都发送了 SA 载荷，和主模式、野蛮模式一样，SA 载荷是用来协商各种保护算法的。而 Ni、Nr 以及 ID 则是用来提供“在场证据”的。Xa 以及 Xb 则是用来生成新的 DH 共享密钥，保证 PFS 的。Xa 以及 Xb 将与 IKE 第一阶段生成的 SKEYID_d、Ni、Nr 以及 SPI 等信息共同生成最终用于 IPSec 加密的密钥；

第三条消息

最后，发起者会发送一条确认信息，响应者收到该信息后就知道发起者已经收到了第二条消息。此时 IKE Phase 2 结束；