知识库 / IKEv2 密钥交换协议详解：RFC 7296 五大交换流程与国密适配

IKEv2 密钥交换协议详解：RFC 7296 五大交换流程与国密适配

协议详解 · 2026-10-06

1. 概述

IKEv2（Internet Key Exchange version 2，RFC 7296）是 IPsec 协议的密钥管理核心组件，由 IETF IPsec 工作组于 2014 年发布为标准（STD: 79）。该标准替代了 RFC 5996，并合并了所有勘误表，标志着 IKEv2 正式成为互联网标准。

IKEv2 设计目标明确：简化 IKEv1 的复杂状态机，增强抗 DoS 能力，原生支持 NAT 穿越，以及提供双向认证机制。作为 IPsec 实现的事实标准，IKEv2 被广泛应用于 Linux strongSwan、Libreswan、Windows Schannel 以及华为、华三等厂商设备中。

1.1 与 IKEv1 的核心差异

特性IKEv1（RFC 4306）IKEv2（RFC 7296）
状态机复杂度两套模式（Main Mode/Aggressive Mode）单一状态机，四阶段交换
NAT 穿越需 NAT-T 扩展（RFC 3947）原生支持 NAT traversal
重保护可选（RFC 4739）强制支持
认证方式预共享密钥/数字证书预共享密钥/公钥/EAP
子 SA 建立通过 Quick Mode通过 CREATE_CHILD_SA
错误处理分散在各 Exchange统一的 ERR_MSG payload
IKEv2 采用请求-响应模型，每个 Exchange 由 Initiator 发起，Responder 响应。消息结构统一使用 IKE Header + Payload 链式设计。

2. IKEv2 消息结构

2.1 IKE Header

IKEv2 消息头部固定为 28 字节：

C
struct ike_header {
    uint32_t  initiator_spi;    // Initiator SPI（8字节）
    uint32_t  responder_spi;    // Responder SPI（8字节）
    uint16_t  next_payload;     // 下一个 payload 类型
    uint8_t   version;          // IKE 版本号（0x20 = IKEv2）
    uint8_t   exchange_type;    // 交换类型
    uint32_t  message_id;       // 消息 ID（防重放）
    uint32_t  length;           // 消息总长度（含 header）
};

2.2 Payload 通用格式

每个 Payload 遵循 TLV（Type-Length-Value）结构：

CODE
┌──────────┬──────────┬────────────────────────────┐
│ Next Pld │ Flags    │      Payload Data           │
│  (1B)    │ (1B)     │      (variable)             │
├──────────┼──────────┼────────────────────────────┤
│ 8 bits   │ 8 bits   │ 以 4 字节对齐的填充          │
└──────────┴──────────┴────────────────────────────┘
  • Next Payload：指向链中下一个 payload 类型，最后一个 payload 为 0
  • Flags：保留位（R）和关键位（K），K=1 表示即使解密失败也必须报告错误

2.3 Exchange 类型编号

Exchange Type数值说明
IKE_SA_INIT2初始安全关联建立
IKE_AUTH3身份认证与首个子 SA
CREATE_CHILD_SA4派生子安全关联
INFORMATIONAL5生命周期管理、错误报告
DELETE6删除安全关联

3. 核心交换流程详解

3.1 IKE_SA_INIT：初始密钥协商

IKE_SA_INIT 是建立 IKE 安全关联（IKE_SA）的第一步，完成 DH 密钥交换和加密算法协商。此阶段不交换身份信息，仅协商算法参数和生成初始密钥材料。

关键参数：

  • SPI：各 8 字节随机值，用于标识 IKE_SA
  • Nonce：各自生成的随机数，用于防重放和密钥派生
  • SA Payload：包含 Proposal Substructure，协商加密算法、PRF、完整性算法、DH 组
  • KE Payload：Diffie-Hellman 公钥值
DH 组选择（RFC 7296 §2.4）：
Group ID描述安全强度
1MODP 2048-bit112 bits
2MODP 1536-bit96 bits
5MODP 2048-bit (SHA-256)112 bits
14ECP 256-bit128 bits
15ECP 384-bit192 bits
16ECP 521-bit256 bits
18MODP 4096-bit152 bits
19MODP 8192-bit192+ bits
IKEv2 推荐使用 Group 14（ECP 256-bit）或 Group 19（MODP 8192-bit）。

3.2 IKE_AUTH：身份认证

IKE_AUTH 在 IKE_SA_INIT 基础上完成双向身份认证，并建立第一个 CHILD_SA（通常用于传输控制消息）。

认证数据结构：

AUTH payload 格式：

CODE
┌──────────┬──────────┬──────────────────────────────┐
│ Next Pld │  Auth Method │      Authentication Data    │
│  (1B)    │  (1B)      │      (variable)              │
├──────────┼──────────┼──────────────────────────────┤
│ 预共享密钥 │ 0x01     │  HMAC(prf(SKM, Ni|Nr, KiNa))  │
│ 公钥认证 │ 0x02     │  数字签名 (initiatorSig)        │
│ EAP      │ 0x03     │  EAP 响应报文                  │
└──────────┴──────────┴──────────────────────────────┘

SKM（Shared Key Material）计算：

CODE
SKM = prf++(CKOctet, IKM, 
    Ni | Nr | IDi | IDr | 
    KeI | KeR | SPIi | SPIr)

其中：

  • CKOctet = 填充至 PRF 输出长度的 0x00
  • IKM = DH 共享密钥（SKM 输入）
  • prf++ = 迭代 PRF：prf(SK, data) || prf(SK, data || counter || data)

3.3 CREATE_CHILD_SA：派生子 SA

CREATE_CHILD_SA 用于在已建立的 IKE_SA 上派生新的 CHILD_SA，支持重新密钥（rekey）和新增 SA，无需重建 IKE_SA。

子 SA 重新密钥：使用相同 SPI 建立新 SA，旧 SA 进入延迟删除状态（Delayed Delete）。

3.4 INFORMATIONAL：管理与通知

INFORMATIONAL exchange 用于：

  • 发送证书请求（CERTREQ）
  • 报告错误（ERR_MSG）
  • 请求内部地址分配
  • 查询对端版本信息
CODE
Initiator                          Responder
   │                                  │
   │─── INFORMATIONAL ──────────────→│
   │   ·Notification (optional)       │
   │   ·Payloads ...                  │
   │                                  │
   │←── INFORMATIONAL ────────────────│
   │   ·ACK / Notification            │
   │   │                              │

错误消息通过 ERR_MSG payload 传递，包含：

  • Protocol ID：出错的协议（1=IKE，2=IPComp）
  • Sender SPI：发送方 SPI
  • Error Type：错误类型（如 INVALID_KE_PAYLOAD）
  • Critical：是否必须处理

3.5 DELETE：安全关联删除

DELETE exchange 用于显式删除 IKE_SA 或 CHILD_SA。

CODE
Initiator                          Responder
   │                                  │
   │─── DELETE (SPI, Protocol) ────→│
   │                                  │
   │←── DELETE (SPI, Protocol) ──────│
   │                                  │

支持对称删除：双方各自独立触发 DELETE，无需等待对方确认。

4. 密钥派生管线

IKEv2 采用分层密钥派生结构（RFC 7296 §2.14）：

各密钥用途：

  • SK_d：签名密钥，用于 AUTH payload
  • SK_ai/SK_ar：IKE 完整性保护密钥
  • SK_ei/SK_er：IKE 加密密钥
  • SK_ke/SK_kr：CHILD_SA 加密密钥
  • SK_pi/SK_pr：CHILD_SA 完整性密钥
密钥派生函数：

CODE
SKpi = prf(SK_d, Ni ‖ Nr ‖ 0x01)
SKpei = prf(SKpi,  SK_ei ‖ 0x02)
SKper = prf(SKpi,  SK_er ‖ 0x03)
SKpai = prf(SKpi,  SK_ai ‖ 0x04)
SKpar = prf(SKpi,  SK_ar ‖ 0x05)

对于 CHILD_SA：

CODE
SKpid = prf(SK_d, Ni ‖ Nr ‖ 0x06)
SKpie = prf(SKpid, SK_ke ‖ 0x07)
SKper = prf(SKpid, SK_kr ‖ 0x08)
SKpia = prf(SKpid, SK_pi ‖ 0x09)
SKpra = prf(SKpid, SK_pr ‖ 0x0A)

5. 认证方法详解

5.1 预共享密钥认证（PSK）

预共享密钥是最简单的认证方式，适用于小型网络或测试环境。

认证数据结构：

CODE
AUTH Data = HMAC(prf(SK_d, Ni ‖ Nr), 
                 Ni ‖ Nr ‖ SPIi ‖ SPIr ‖ IDi ‖ IDr)

局限性：

  • 密钥分发困难
  • 不支持证书吊销检查
  • 不适合大规模部署

5.2 公钥认证（数字证书）

公钥认证使用 X.509 或 SM2 证书进行身份验证。

认证数据结构：

CODE
AUTH Data = signature(SK_priv, 
             Ni ‖ Nr ‖ SPIi ‖ SPIr ‖ IDi ‖ IDr)

其中 signature 可以是：

  • ECDSA-SHA2-256（椭圆曲线数字签名算法）
  • RSA-PSS-SHA256（RSA 填充方案）
  • SM2-with-SM3（国密签名算法）

5.3 EAP 认证

扩展认证协议（EAP）支持多种认证方法，包括：

  • EAP-TLS：基于证书的 mutual authentication
  • EAP-PEAP：受保护的 EAP
  • EAP-AKA/AKA'：移动网络认证
  • EAP-SIM：GSM 认证
EAP 认证通过 IKE_AUTH exchange 传输，不单独占用 exchange。

6. 国密适配方案

6.1 SM2 在 IKEv2 中的映射

国密算法在 IKEv2 中的适配主要参考 GM/T 0022-2014《IPSec VPN 技术规范》。

加密算法映射：

国际标准国密算法Transform ID
AES-128-GCMSM4-GCM12
AES-256-GCMSM4-GCM13
AES-CBC-128SM4-CBC2
AES-CBC-256SM4-CBC3
NULL Encryption无加密0
完整性算法映射：

国际标准国密算法Transform ID
HMAC-SHA2-256HMAC-SM33
HMAC-SHA2-384HMAC-SM34
HMAC-SHA2-512HMAC-SM35
伪随机函数映射：

国际标准国密算法
PRF-HMAC-SHA2-256PRF-HMAC-SM3
PRF-HMAC-SHA2-384PRF-HMAC-SM3
PRF-HMAC-SHA2-512PRF-HMAC-SM3

6.2 SM2 证书在 IKE_AUTH 中的应用

国密 IKEv2 实现使用 SM2 证书替代 X.509 证书：

6.3 国密 DH 组扩展

GM/T 0022-2014 定义了国密 DH 组：

DH Group描述素数位数
19SM2 256 位曲线256
21SM2 384 位曲线384
这些组使用椭圆曲线 Diffie-Hellman（ECDH）而非传统 MODP。

7. 安全分析

7.1 抗 DoS 机制

IKEv2 通过以下机制增强抗 DoS 能力：

  • Cookie 机制（RFC 7296 §2.6）：
- Responder 在 IKE_SA_INIT 响应中携带 COOKIE payload - Initiator 必须在后续消息中包含合法 COOKIE - 防止伪造 IP 地址的 DoS 攻击

  • 延迟资源分配：
- Responder 仅在收到完整 IKE_AUTH 后才分配内存 - 减少状态耗尽攻击风险

  • 重保护（Replay Protection）：
- 使用 nonce 和序列号双重防护 - Window-based 重放检测

7.2 NAT 穿越

IKEv2 原生支持 NAT 穿越，无需额外扩展：

CODE
NAT 检测流程：
1. Initiator 发送 IKE_SA_INIT，检查是否有 NAT 设备
2. 如果检测到 NAT，启用 NAT-keepalive（UDP 4500）
3. 所有 IKE 消息封装在 UDP 4500 端口

NAT 穿透通过 UDP 封装实现，避免 AH 协议（ICMP 不可传递）的问题。

7.3 前向保密

IKEv2 支持前向保密（PFS），通过 CREATE_CHILD_SA exchange 中的 KE payload 实现：

CODE
if PFS enabled:
    new_shared_secret = DH(new_private, peer_public)
    rekey_child_sa(new_shared_secret, existing_keys)

每重新密钥一次，生成新的 DH 密钥对，确保历史会话密钥不被泄露。

8. 实现参考

8.1 strongSwan 配置示例

8.2 Linux ipsec.conf 配置

9. 与 TLS 1.3 的对比

特性IKEv2TLS 1.3
握手轮数2 RTT（IKE_SA_INIT + IKE_AUTH）1 RTT（0-RTT 可选）
认证方式预共享密钥/证书/EAP证书/PSK
密钥派生HKDF-likeHKDF
前向保密可选（PFS）强制
重协商CREATE_CHILD_SA无（需重建连接）
应用场景IPsec VPNWeb 应用
IKEv2 更适用于网络层 VPN 场景，而 TLS 1.3 适用于应用层加密。两者在密钥派生和认证机制上有相似之处，但 IKEv2 提供了更丰富的子 SA 管理和 NAT 穿越能力。

10. 总结

IKEv2 作为 IPsec 的核心密钥管理协议，通过简化的状态机和增强的安全性设计，成为现代 VPN 实现的首选。其五大交换流程（IKE_SA_INIT、IKE_AUTH、CREATE_CHILD_SA、INFORMATIONAL、DELETE）构成了完整的密钥协商、认证和生命周期管理体系。

国密适配方面，GM/T 0022-2014 定义了 SM2/SM3/SM4 在 IKEv2 中的映射方案，已在华为、华三等厂商设备中广泛部署。随着国密标准的推广，IKEv2 的国密化将成为等保 2.0 和密评合规的必然要求。

相关实践文章

参考文档

  • RFC 7296 - Internet Key Exchange Protocol Version 2 (IKEv2), Kaufman et al., October 2014
  • GM/T 0022-2014 - IPSec VPN 技术规范
  • GM/T 0023-2014 - IPSec VPN 网关产品规范
  • NIST SP 800-43 Rev. 2 - Guide to IPsec Version 2
← 返回知识库