数据完整性保证之外，还能对数据源的身份进行验证：在消息接收到之后，我们知道它只有可能来自验证通过的实体，而且那条消息在传送过程并未发生改变。而通过加密（使用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，需要执行一次额外的Diffie-Hellman交换，最终生成的共享密钥将在为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第二阶段结束。
幻灯片 23
幻灯片 24
相关推荐：
loading