IKE 中的主模式与野蛮模式(抓包分析)

easy

IKE 介绍
IKE（Internet密钥交换协议）是一个混合协议，它包括ISAKMP和IKE，负责在两台设备之间建立安全的连接。ISAKMP定义了消息的格式和密钥交换协议的机制，以及构建连接的协商过程。IKE负责产生、共享和管理密钥。在 IPsec 中，IKE 协议负责在两个 IPsec 对等体间协商一条 IPsec 隧道。（参考 RFC2409，在本文档中将 ISAKMP 和 IKE 统称为 IKE）

IKE引入了阶段这个概念，分为IKE 1和IKE 2。在IKE 1阶段是在两个对等体设备之间建立一个安全的管理连接，没有实际的数据通过这个连接。在IKE 2阶段是构造一个安全的数据连接。这些连接都是使用UDP的端口号500实现通信的。（注：本文只讨论IKE 1阶段）
在IKE 1阶段将要做3件事情：

1、对等体协商管理连接是如何被保护的。
2、对等体使用DH来共享密钥信息从而保护管理连接。
3、对等体相互身份验证。

执行这3个步骤有两个模式：主模式和野蛮模式。下面将详细讨论这两个模式。

主模式

主模式执行3步双向交换过程。总共有6个数据包的交互。3步交换是指：一、协商安全策略（1、2个包）；二、相互交换DH公共值和随机数（3、4个包）；三、交换ID信息，进行身份验证（5、6个包）。（本文只讨论采用预共享密钥认证的主模式）

消息1
发起者（Initiator） ---> 回应者（Responder）


（图1）

在前2条消息发送之前,发送者和回应者必须先计算出各自的 cookie。Cookie 用于标识每个单独的协商交换。它把和其他设备建立 IPSEC 所需要的连接信息 HASH 成一个 cookie 值。实际上 cookie 是用来防止 DOS 攻击的，只要双方确定对方的 Cookie 和以前从对方那里接收到的 Cookie 值不同，他将抛弃该消息。

发送者（Initiator）的 cookie：CKY-I = md5{(src_ip, dest_ip)，随机数，时间和日期}

回应者（Responder）的 cookie：CKY-R = md5{(src_ip, dest_ip), 随机数，时间和日期}

在消息1中，发送者向接收者发送一条包含一组或多组策略提议，在策略提议中包括5元组(加密算法，hash算法，认证方法，DH，lifetime)。

从上面抓包分析，消息1中包括以下内容：

ISAKMP header：
Cookie：包括发起者和回应者的cookie，实际上就是一个HASH值。

Exchange type：主模式或者野蛮模式。

Message ID：由发起者生成的一个随机值，用于阶段2协商中标识协议状态。

Security Association Payload：
Domain of interpretation (DOI)：解释域，它说明这条消息交换用于IPsec。DOI定义格式、交换类型和用于命名的相关信息（密码算法，模式等）的约定。

Proposal payload：
Proposal number：提议号。起到一个标识的作用。

Proposal ID： ISAKMP（1）；AH（2）；ESP（3）。

Proposal transforms：提议转换数。指明转换的数目。在上图中为1，说明只有一组转换。

SPI（Security Parameter Index）：安全参数索引，由IKE自动分配。在IKE 2阶段交换中根据SPI可以查找到相应的 IPsec SA。

Transform payload：
Transform number/ ID：转换号/转换ID。用于确定某个转换，起到一个标识作用。

Encryption-Algorithm：DES（密钥长度为56位）；3DES（密钥长度为168位）；AES（密钥长度最长可达到256位）。

Hash-Algorithm：哈希算法。MD5（128位）；SHA（160位）。

Authentication-Method：认证方式。PSK（预共享密钥）；RSA Signature（数字签名）。

Group-Description：DH 1；DH2。通过设置DH组，也就定义了要使用哪个质数p以及底数g（p和g这两个数在计算公共密钥时要用到）。

Life-Type：Seconds。

Life-Duration：IKE 1阶段的生存周期。如果到期之后，将重新建立IKE 1阶段的协商。一般情况下，会使用双方的生存周期值中较小的一个。

消息2
发起者（Initiator）<--- 回应者（Responder）

在消息2中，是回应者对发起者的响应。在这个过程中，回应者将从发起者发过来的一组或多组转换集中选出一个和自己匹配的转换集（即上文提到的Transform payload），并回复给发起者。如果没有找到匹配的转换集，那么IKE 1阶段就不会建立成功。
从上面抓包分析，消息2中包括以下内容：

ISAKMP header：请参考消息1中的解释。

Security Association Payload：请参考消息1中的解释。

Proposal payload： 包含了回应者所接受的提议的信息。

Transform payload：包含了回应者所接受的转换集。

Vendor ID： DPD（Detecting Dead IKE Peers）：
对方失效探测，在 RFC3706 中定义，利用定时发送探测信息的方法检测 VPN 通道对方是否失效。

消息3
发起者（Initiator） ---> 回应者（Responder）

消息3是发起者发给回应者的，用于交换 DH 公共值和 Nonce。用在发送消息3、4之前，发起者和接收者会采用DH算法算出各自的DH公共值，同时也生成一个Nonce（一个大的随机数）。（DH算法不在本文中讨论，可以参考：《IKE 介绍》）

从上面抓包分析，消息3中包括以下内容：

Key Exchange payload：包含发起者的 DH 公共值。

Nonce payload：发起者产生的一个很大的随机数。

消息4
发起者（Initiator）<--- 回应者（Responder）

消息4是回应者发给发起者的。与消息3相似。其中包括回应者向发起者发送的DH公共值和Nonce（很大的随机数）。

消息5
发起者（Initiator） --> 回应者（Responder）


消息5是发起者发给回应者的，用于双方彼此验证。这个过程是已经被 skeyID_e 加密保护的。

在发送消息5、6之前，发起者和接收者双方会根据收到的DH公共值算出一个相同的DH密钥，然后结合收到的Nonce和配置的预共享密钥生成 SKEYID，再由 SKEYID推算出 3 个密钥，并且双方产生的这 3 个密钥都是一样的。

注意：当配置多个对等体的时候，每一个对等体都会有一个预共享密钥。这个时候它是怎样找到相对应的预共享密钥呢？毫无疑问在主模式里肯定是通过 IP 地址找到的。但是它怎么知道是哪个 IP 地址呢？在前面消息交互中并没有告诉它通过哪个 IP 地址去找预共享密钥。并且标识对方的 IP 地址或是主机名在下一个消息（消息6）里才会提到。因此，双方必须使用前面接收消息的源 IP 地址来找到与其对应的预共享密钥。

SKEYID = PRF（预共享密钥，发起者的 Nonce，接收者的 Nonce）
说明：PRF（key，msg）：使用密钥key和输入信息msg做一个密钥的hash。

SKEYID_d：用于计算后续的IPsec的密钥资源。

SKEYID_a：用于提供IKE消息的数据完整性和认证。如HMAC。
SKEYID_e：用于加密后续的IKE消息。

消息5加密部分包括以下内容：

Identity payload：
发起者标识的信息。包括自己的IP地址或者主机名。

Hash payload：
Hash_I = PRF（SKEYID，CKY-I，CKY-R，Pre-shared Key（PK-I），SA Payload，Proposals+Transforms，ID_I）
注：CKY-I：发起者的cookie；CKY-R：回应者的cookie。

消息6
发起者（Initiator）<--- 回应者（Responder）



消息6 是回应者发给发起者的。同消息5相似，用于双方彼此验证。这个过程是已经被 skeyID_e 加密保护的。

消息6加密部分包括以下内容：
Identity payload（ID）：
发起者标识的信息。包括自己的IP地址或者主机名。

Hash payload：
Hash_R  =  PRF（SEKYID，CKY-I，CKY-R，Pre-shared Key（PK-R），SA Payload，Proposals+Transforms，ID_R）

当双方都收到了对方发过来的 hash 值之后，它会将这个 hash 值与自己计算出来的 hash 值做比较，如果两个hash相同，就表示认证成功。

野蛮模式

消息1
发起者（Initiator） ---> 回应者（Responder）


消息1 由发起者向回应者发出。它包含了一组或多组提议转换和所有用于回应者产生一个 DH 密钥的信息。如 DH 公共值、Nonce 等参数。同时，它也将自己的 ID 信息发送给回应者。便于回应者根据 ID 信息找到相应的预共享密钥。

消息2
发起者（Initiator）<--- 回应者（Responder）

当回应者接收到消息1，就根据收到的 DH 公共值利用DH算法算出 DH 密钥。然后回应者使用消息1中的 ID 信息（IP或者主机名）来寻找预共享密钥。于是回应者再使用 DH 密钥、预共享密钥和 Nonce 来计算出那三个密钥，和主模式中的操作一样。密钥生成后，回应者使用 SKEYID 来产生 Hash_R 用于认证。

消息2由回应者发送给发起者。它包括回应者同意的提议转换，以及用于认证目的而由回应者生成的 hash 值。它还包括发起者用来产生 DH 密钥的所有信息以及回应者的 ID 信息。
Hash_R  =  PRF（SEKYID，CKY-I，CKY-R，Pre-shared Key（PK-R），SA Payload，Proposals+Transforms，ID_R）

消息3
发起者（Initiator） ---> 回应者（Responder）

当发起者接收到消息2，它就能计算 DH 密钥，寻找预共享密钥，产生出 SKEYID，并在它们基础之上生成 Hash_R。当它产生的 hash 值一旦同回应者发来的相匹配，就认为已经被认证。发起者现在生成的 hash_I 以允许回应者也能进行认证。

消息3由回应者发送给发起者。它包含了它产生的 Hash_I。当回应者接收到这个hash值，就将这个hash值与自己生成的 hash_I 相比较。如果匹配，就可认为回应者这一端也完成了认证。这样就完成了野蛮模式，生成了 DH 密钥，同时也认证了对端。
Hash_I  =  PRF（SEKYID，CKY-I，CKY-R，Pre-shared Key（PK-I），SA Payload，Proposals+Transforms，ID_I）


两种模式的区别
1、野蛮模式协商比主模式协商更快。主模式需要交互6个消息，野蛮模式只需要交互3个消息。

2、主模式协商比野蛮模式协商更严谨、更安全。因为主模式在5、6个消息中对 ID 信息进行了加密。而野蛮模式由于受到交换次数的限制，ID 信息在1、2个消息中以明文的方式发送给对端。即主模式对对端身份进行了保护，而野蛮模式则没有。

3、两种模式在确定预共享密钥的方式不同。主模式只能基于IP地址来确定预共享密钥。而积极模式是基于ID信息（主机名和IP地址）来确定预共享密钥。

两种模式的应用场合
在实际应用中，一般情况下，如果两端设备都是公网固定IP地址（至少一端是固定 IP 地址）这种接入方式、且要实现设备之间点对点的环境，就采用主模式来协商。对于两端IP地址不是固定的情况（如ADSL拨号上网），并且双方都希望采用预共享密钥验证方法来创建IKE SA，就采用野蛮模式。另外如果发起者已知回应者的策略，采用野蛮模式能够更快地创建IKE SA。

问题回顾
为什么两边都是主机名的时候，就一定要用野蛮模式来协商呢？

通过上述IKE 1阶段的讨论，现在再来回答这个问题已经不难了。在两边都是主机名的时候，如果用主模式的话，就会出现根据源 IP 地址找不到预共享密钥的情况，以至于不能生成 SKEYID。

1、因为主模式在交换完3、4消息以后，需要使用预共享密钥来计算 SKEYID，但是由于双方的 ID 信息在消息5、6中才会被发送，此时主模式的设备只能使用消息3、4中的源 IP 地址来找到与其对应的预共享密钥；如果主模式采用主机名方式，主机名信息却包含在消息5、6中，而 IPSEC 双方又必须在消息5、6之前找到其相应的预共享密钥，所以就造成了矛盾。

2、在野蛮模式中，ID信息（IP地址或者主机名）在消息1、2中就已经发送了，对方可以根据 ID 信息查找到对应的预共享密钥，从而计算出 SKEYID。