跳到主要内容

1.2. The Initial Exchanges (初始交换)

1.2 The Initial Exchanges (初始交换)​

使用 IKE 的通信始终以 IKE_SA_INIT 与 IKE_AUTH 交换开始 (在 IKEv1 中称为 Phase 1). 这些初始交换通常由四条消息组成, 某些场景下该数目可能增加. 所有使用 IKE 的通信均由请求/响应对构成. 下文先描述基础交换, 再描述其变体. 第一对消息 (IKE_SA_INIT) 协商密码算法, 交换 nonce, 并进行 Diffie-Hellman 交换 [DH].

第二对消息 (IKE_AUTH) 对先前消息进行认证, 交换身份与证书, 并建立第一个 Child SA. 这些消息的一部分使用通过 IKE_SA_INIT 交换建立的密钥进行加密与完整性保护, 因此身份对窃听者隐藏, 且所有消息中的所有字段均经过认证. 有关如何生成加密密钥的信息见第 2.14 节. (无法完成 IKE_AUTH 交换的中间人攻击者仍可能看到发起方身份.)

初始交换之后的所有消息均使用在 IKE_SA_INIT 交换中协商的密码算法与密钥进行密码保护. 这些后续消息使用第 3.14 节所述 Encrypted 载荷的语法, 使用按第 2.14 节所述方式导出的密钥加密. 所有后续消息均包含 Encrypted 载荷, 即便文中称其为 "empty (空)". 对于 CREATE_CHILD_SA, IKE_AUTH 或 INFORMATIONAL 交换, 紧随头之后的消息被加密, 包含头的整条消息使用为 IKE SA 协商的密码算法进行完整性保护.

每条 IKE 消息在其固定头中都包含 Message ID. 该 Message ID 用于匹配请求与响应, 并标识消息的重传.

在下述说明中, 消息所包含的载荷用下表所列名称表示.

Notation (记号)Payload (载荷)
AUTHAuthentication (认证)
CERTCertificate (证书)
CERTREQCertificate Request (证书请求)
CPConfiguration (配置)
DDelete (删除)
EAPExtensible Authentication (可扩展认证)
HDRIKE header (not a payload) (IKE 头, 非载荷)
IDiIdentification - Initiator (标识 - 发起方)
IDrIdentification - Responder (标识 - 响应方)
KEKey Exchange (密钥交换)
Ni, NrNonce (随机数)
NNotify (通知)
SASecurity Association (安全关联)
SKEncrypted and Authenticated (加密且认证)
TSiTraffic Selector - Initiator (流量选择器 - 发起方)
TSrTraffic Selector - Responder (流量选择器 - 响应方)
VVendor ID (厂商 ID)

各载荷内容的细节见第 3 节. 可选出现的载荷用方括号标示, 例如 [CERTREQ], 表示可选择包含 Certificate Request 载荷.

初始交换如下:

Initiator                         Responder
-------------------------------------------------------------------
HDR, SAi1, KEi, Ni  -->

HDR 包含 Security Parameter Indexes (SPI, 安全参数索引), 版本号, Exchange Type, Message ID 以及各种标志. SAi1 载荷说明发起方为 IKE SA 支持的密码算法. KE 载荷发送发起方的 Diffie-Hellman 值. Ni 为发起方的 nonce.

                               <--  HDR, SAr1, KEr, Nr, [CERTREQ]

响应方从发起方提供的选项中选择一套密码套件, 并在 SAr1 载荷中表达该选择, 用 KEr 载荷完成 Diffie-Hellman 交换, 并在 Nr 载荷中发送其 nonce.

在此协商阶段, 各方均可生成称为 SKEYSEED 的量 (见第 2.14 节), IKE SA 的所有密钥均由此导出. 随后的消息除消息头外整体被加密并完整性保护. 用于加密与完整性保护的密钥由 SKEYSEED 导出, 称为 SK_e (加密) 与 SK_a (认证, 亦称完整性保护), 详见第 2.13 与 2.14 节. 每个方向分别计算一套 SK_e 与 SK_a. 除用于保护 IKE SA 的 Diffie-Hellman 值导出的 SK_e 与 SK_a 外, 还导出另一量 SK_d, 用于为 Child SA 派生更多密钥材料. 记号 SK { ... } 表示这些载荷使用该方向的 SK_e 与 SK_a 加密并完整性保护.

HDR, SK {IDi, [CERT,] [CERTREQ,]
    [IDr,] AUTH, SAi2,
    TSi, TSr}  -->

发起方用 IDi 载荷声明其身份, 用 AUTH 载荷证明其掌握与 IDi 对应的秘密并对第一条消息的内容做完整性保护 (见第 2.15 节). 它还可以在 CERT 载荷中发送其证书, 在 CERTREQ 载荷中发送其信任锚列表. 若包含任何 CERT 载荷, 则提供的第一份证书必须包含用于验证 AUTH 字段的公钥.

可选载荷 IDr 使发起方能够指明希望与响应方的哪一个身份通信. 当运行响应方的机器在同一 IP 地址上托管多个身份时这很有用. 若发起方提议的 IDr 对响应方不可接受, 响应方可能使用其他 IDr 完成交换. 若发起方随后不接受响应方使用了与其请求不同的 IDr 这一事实, 发起方在注意到该情况后可以关闭该 SA.

Traffic Selector (流量选择器, TSi 与 TSr) 在第 2.9 节讨论.

发起方使用 SAi2 载荷开始 Child SA 的协商. 最终字段 (自 SAi2 起) 在 CREATE_CHILD_SA 交换的说明中描述.

                               <--  HDR, SK {IDr, [CERT,] AUTH,
                                        SAr2, TSi, TSr}

响应方用 IDr 载荷声明其身份, 可选择发送一份或多份证书 (同样将用于验证 AUTH 的公钥所在证书列在首位), 用 AUTH 载荷认证其身份并保护第二条消息的完整性, 并用 CREATE_CHILD_SA 交换下文所述的附加字段完成 Child SA 的协商. IKE_AUTH 交换中的双方必须验证所有签名与 Message Authentication Code (MAC, 消息认证码) 是否计算正确. 若任一方使用共享秘密进行认证, 则 ID 载荷中的名称必须与用于生成 AUTH 载荷的密钥相对应.

由于发起方在 IKE_SA_INIT 中发送其 Diffie-Hellman 值, 它必须猜测响应方将从其支持的组列表中选择哪一个 Diffie-Hellman 组. 若猜测错误, 响应方将以类型为 INVALID_KE_PAYLOAD 的 Notify 载荷回应, 指明所选组. 此时发起方必须使用更正后的 Diffie-Hellman 组重试 IKE_SA_INIT. 发起方必须再次提议其完整的一套可接受密码套件, 因为拒绝消息未经认证, 否则主动攻击者可能诱使端点协商出弱于双方本可接受的更强套件.

若在 IKE_AUTH 交换期间因某种原因未能创建 Child SA, IKE SA 仍照常建立. IKE_AUTH 交换中至少以下 Notify 消息类型不会阻止建立 IKE SA: NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE 与 FAILED_CP_REQUIRED.

若失败与创建 IKE SA 有关 (例如返回 AUTHENTICATION_FAILED Notify 错误消息), 则不创建 IKE SA. 注意, 尽管 IKE_AUTH 消息已加密且完整性保护, 若收到此 Notify 错误消息的对端尚未认证另一端 (或因某种原因未能认证另一端), 则应对该信息谨慎对待. 更精确地说, 在假定 MAC 验证正确的前提下, 错误 Notify 消息的发送方已知为 IKE_SA_INIT 交换的响应方, 但无法保证发送方身份.

注意 IKE_AUTH 消息不包含 KEi/KEr 或 Ni/Nr 载荷. 因此 IKE_AUTH 交换中的 SA 载荷不能包含 Transform Type 4 (Diffie-Hellman 组) 且其值不能为 NONE 以外的任何值. 实现应该省略整个 transform 子结构, 而不是发送值为 NONE.

最后于 更新