HCNA第九章IPSecVPN技术V2.0技巧.pptVIP

* IKE交换阶段第一阶段——野蛮模式交换 从上述主模式协商的叙述中可以看到，在第二次交换之后便可生成会话密钥，会话密钥的生成材料中包含了预共享密钥。而当一个对等体同时与多个对等体进行协商SA时，则需要为每个对等体设置一个预共享密钥。为了对每个对等体正确地选择对应地预共享密钥，主模式需要根据前面交换信息中的IP地址来区分不同的对等体。 但是当发起者的IP地址是动态分配获得的时候，由于发起者的IP地址不可能被响应者提前知道，而且双方都打算采用预共享密钥验证方法，此时响应者就无法根据IP地址选择对应地预共享密钥。野蛮模式就是被用于解决这个矛盾的。 与主模式不同，野蛮模式仅用3条信息便完成了IKE SA的建立。由于对消息数进行了限制，野蛮模式同时也限制了它的协商能力，而且不会提供身份保护。 在野蛮模式的交换过程中，发起者会提供一个保护套件列表、Diffie-Hellman公共值、nonce以及身份资料。所有这些信息都是随第一条信息进行交换的。作为响应者，则需要回应选择一个保护套件、Diffie-Hellman公共值、nonce、身份资料以及一个验证载荷。发起者将它的验证载荷在最后一条消息交换。 野蛮模式由于在其第一条信息中就携带了身份信息，因此本身无法对身份信息进行加密保护，这就降低了协商的安全性，但也因此不依赖IP地址标识身份，在野蛮模式下也就有了更多灵活的应用。 * * IKE交换阶段第二阶段——快速模式交换 建立好IKE SA之后（无论通过主模式还是通过野蛮模式交换），便可用它为IPSec生成相应的SA。IPSec SA是通过快速模式交换来建立的，对快速模式交换来说，它是在以前建立好的IKE SA的保护下完成的。 在一次快速交换模式中，通信双方需要协商拟定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，需要执行一次额外的Diffie-Hellman交换，最终生成的共享密钥将在为IPSec生成密钥的过程中用到。显然，一旦交换完成，这个密钥便不复存在。一旦完成，它所驻留的那个内存位置必须清零和释放。从而保证了密钥之间地不相关性。 我们前面将快速模式描述成一种简单的请求／响应交换，但它的实际功用远不止于此。发起者可能需要一个“在场”证据，证明响应者在线，而且已经实际地处理了它的初始快速模式消息。为了达到这个要求，响应者需亚在验证散列载荷中，加入交换的发起者nonce以及消息ID。这个摘要现在不仅能保障消息的完整性，也能为发起者提供源验证功能，另外还能提供在场证据。 响应者也需要一个在场证据，从发起者传来的可能是一条过期的消息，是由不怀好意的人重播的。这个人可能不知道消息的内容，但通过对通信的分析，能够知道它是一条快速模式消息。如果重播那条消息，响应者便不得不创建多余的SA。我们可将其想像成一种“服务否认”攻击，只是属于比较温和的那种，因为响应者会根据这条消息，增加不必要的内存及SA管理开销。想要防范此类攻击，需在快速模式交换中增加第三条消息。在这条消息中，发起者需要同时包括nonce和此次交换的消息ID，并把它们保存在一个验证散列载荷中。这样发起者便可向响应者证实：自己是此次交换的活动参与者。 在前两条消息中，发起者和响应者都发送了SA载荷，和主模式、野蛮模式一样，SA载荷是用来协商各种保护算法的。而Ni、Nr以及ID则是用来提供“在场证据”的。Xa以及Xb则是用来生成新的DH共享密钥，保证PFS的。