# IMS 注册鉴权（IMS-AKA）全链拆解：从 SIP REGISTER 到 IPsec SA 建立 > 本文聚焦一个具体机制：**IMS 初始注册过程中的 IMS-AKA 双向鉴权与 Gm 接口 IPsec 安全联盟建立**。所有信令步骤均对应到具体 3GPP TS 章节与 RFC 条目，适合协议开发与 VoLTE/VoNR 排障工程师对照抓包逐字节核对。 --- ## 一、为什么 IMS 要"再"做一次 AKA 鉴权 很多工程师第一次接触 IMS 时都会产生疑问：UE 在接入网（5G AKA / EPS AKA）已经做过一次鉴权，AMF/MME 已经确认了用户身份，为什么到了 IMS 层 S-CSCF 还要让 UE 再跑一次 AKA？ 这是一个**设计意图**问题，原因有三： 1. **鉴权的对象不同**。接入网鉴权证明的是"这张 USIM/ISIM 卡有权接入 3GPP 网络"；IMS 鉴权证明的是"这个 IP 多媒体私有身份（IMPI）有权使用 IMS 业务"。两者使用**不同的长期密钥**——接入用 K（USIM），IMS 用 K_IMS（ISIM 应用，独立存储在 UICC 上）。即便用户漫游、IMS 核心由拜访或第三方提供，IMS 域也能独立完成身份裁决。 2. **保护域的边界不同**。5G AKA 在 UE 与 ARPF/HSS 之间建立的是接入层密钥；而 IMS 信令（SIP over Gm）要穿越无线、传输、PGW/UPF 才到达 P-CSCF，这条 Gm 链路跨越多个不可信中转节点。TS 33.203 因此规定在 **UE 与 P-CSCF 之间**用 IPsec 强制保护 SIP，其密钥正是从 IMS-AKA 派生的 CK/IK。鉴权与密钥协商一次完成，缺一不可。 3. **防止伪 IMS 核心网（Rogue IMS）**。IMS-AKA 是**双向鉴权**：UE 用 AUTN 中的 MAC 验证网络身份，网络用 RES 验证 UE 身份。这使伪 P-CSCF/S-CSCF 无法骗取用户 SIP 信令。 理解这三点，后面所有"看似冗余"的信令步骤就有了合理性。 --- ## 二、参与网元与接口拓扑 IMS 注册鉴权横跨四个接口：**Gm（UE↔P-CSCF，SIP）、Mw（CSCF 之间，SIP）、Cx（CSCF↔HSS，Diameter）、Mw/Dh（可选）**。关键网元角色如下表： | 网元 | 在鉴权中的职责 | 相关接口/规范 | |------|---------------|--------------| | UE/ISIM | 存储 IMPI/IMPU/K_IMS，执行 AKA 算法，建立 IPsec SA | Gm，TS 33.203 §6 | | P-CSCF | Gm 边缘安全锚点，建立/维护 IPsec，剥离 CK/IK，下发 Security-Server | Gm/Mw，TS 33.203 §7 | | I-CSCF | 查询 HSS 选定 S-CSCF（Cx-UAR/UAA） | Cx，TS 29.228 | | S-CSCF | 鉴权裁决者（比对 XRES/RES），向 HSS 取向量，注册后下载用户档案 | Cx/Mw，TS 24.229 §5.1 | | HSS | 生成鉴权五元组（RAND/AUTN/XRES/CK/IK），存储用户档案与 iFC | Cx，TS 29.229 / TS 23.002 | ```mermaid flowchart TD UE["UE + ISIM
(K_IMS)"] -->|Gm SIP/IPsec| PCSCF["P-CSCF
安全锚点"] PCSCF -->|Mw SIP| ICSCF["I-CSCF
选 S-CSCF"] ICSCF -->|Cx Diameter
UAR/UAA, MAR/MAA| HSS[("HSS
鉴权向量
用户档案")] ICSCF -->|Mw SIP| SCSCF["S-CSCF
鉴权裁决"] SCSCF -->|Cx Diameter
MAR/MAA, SAR/SAA| HSS ``` --- ## 三、完整信令时序图 下面这张时序图对应 TS 24.229 §5.1.1.2（注册）与 §5.1.2.2（带鉴权的初始注册），是排障时必须背下来的骨架： ```mermaid sequenceDiagram autonumber participant UE as UE/ISIM participant PCSCF as P-CSCF participant ICSCF as I-CSCF participant SCSCF as S-CSCF participant HSS as HSS Note over UE: 第一条 REGISTER（未鉴权，未受保护端口发出） UE->>PCSCF: REGISTER (IMPI/IMPU, Security-Client, Authorization Digest nonce="") PCSCF->>PCSCF: DNS 查询 I-CSCF PCSCF->>ICSCF: REGISTER (+ Via: P-CSCF, integrity-protection:no) ICSCF->>HSS: Cx-UAR User-Authorization-Request (IMPI/IMPU, visited-net) HSS-->>ICSCF: Cx-UAA (S-CSCF name 或 capability set) ICSCF->>SCSCF: REGISTER Note over SCSCF: 无此用户鉴权向量 → 向 HSS 申请 SCSCF->>HSS: Cx-MAR Multimedia-Auth-Request (IMPI, 计数) HSS-->>SCSCF: Cx-MAA (AV: RAND,AUTN,XRES,CK,IK) SCSCF-->>PCSCF: 401 Unauthorized (WWW-Authenticate: nonce, algorithm=AKAv1-MD5, qop, ) Note over PCSCF: 关键：剥离 ck/ik，注入 Security-Server(SPI/端口) PCSCF-->>UE: 401 Unauthorized (WWW-Authenticate, Security-Server) Note over UE: ISIM 用 RAND/AUTN 跑 AKA：验 MAC、算 RES、派生 CK/IK；
建立 4 条 IPsec SA，切换到受保护端口 UE->>PCSCF: REGISTER (Authorization: Digest response=H(...RES...), Security-Client, Security-Verify, 受保护端口) PCSCF->>ICSCF: REGISTER ICSCF->>SCSCF: REGISTER Note over SCSCF: 用 XRES 重算 digest response 比对 → 通过 SCSCF->>HSS: Cx-SAR Server-Assignment-Request (注册, S-CSCF name) HSS-->>SCSCF: Cx-SAA (用户档案 + iFC + IFC) SCSCF-->>UE: 200 OK (Service-Route, P-Associated-URI) Note over UE,PCSCF: Gm 全程 IPsec 保护，后续 INVITE 走受保护端口 ``` --- ## 四、逐消息 IE 拆解 ### 4.1 第一条 REGISTER（未鉴权） ```text REGISTER sip:ims.mnc.mcc.3gppnetwork.org SIP/2.0 Via: SIP/2.0/UDP :;rport;branch=z9hG4bK... Route: :;lr> From: @...>;tag=... To: @...> Contact: @:>;+sip.instance="";+g.3gpp.icsi-ref CSeq: 1 REGISTER Security-Client: ipsec-3gpp; alg=hmac-md5-96; ealg=null; spi-c=; spi-s=; port-c=; port-s= Require: sec-agree Proxy-Require: sec-agree Authorization: Digest username="", realm="...", uri="sip:...", nonce="", response="" Expires: 600000 ``` **关键 IE 解读：** - **`Security-Client`（TS 33.203 §7.1）**：UE 声明自己支持的 IPsec 能力与它**自己将要使用的 SPI/端口**。`spi-c`（client SPI，用于 UE→P-CSCP 方向）、`spi-s`（server SPI，用于 P-CSCF→UE 方向）、`port-c=port_uc`（UE 受保护客户端口，UE 作为源端口）、`port-s=port_us`（UE 受保护服务端口，UE 作为目的端口）。`alg` 是认证算法（`hmac-md5-96` 或 `hmac-sha-1-96`），`ealg` 是加密算法（多数现网用 `null`，仅做完整性）。 - **`Require/Proxy-Require: sec-agree`**：强制 P-CSCF 必须支持安全协商，否则 421 Extension Required。这是"安全第一"原则的体现。 - **`Authorization` 的 `nonce=""`、`response=""`**：第一条不带鉴权响应，只声明"我是谁、属于哪个 realm"，目的是触发网络的 401 挑战。 - **`+g.3gpp.icsi-ref` / `+sip.instance`**：UE 上报能力与设备标识，S-CSCF 据此判断是否允许注册。 ### 4.2 Cx-UAR / Cx-UAA：I-CSCF 选 S-CSCF I-CSCF 收到 REGISTER 后，向 HSS 发 **Cx-UAR（User-Authorization-Request，Diameter 命令码 300）**，主要 AVP： | AVP | 含义 | |-----|------| | `User-Name` (IMPI) | 待注册的私有身份 | | `Public-Identity` (IMPU) | 公有身份 | | `Visited-Network-Identifier` | 拜访网络标识，用于漫游授权 | | `User-Authorization-Type` | 0=REGISTRATION, 1=DE-REG, 2=REG+CAP | HSS 回 **Cx-UAA**，要么直接给 `Server-Name`（已分配过 S-CSCF），要么给 `Server-Capabilities`（能力集，让 I-CSCF 用 DNS/SRV 自选）。**注意：UAR 阶段不下发鉴权向量**，鉴权向量在下一步由 S-CSCF 主动申请——这是职责分离设计。 ### 4.3 Cx-MAR / Cx-MAA：S-CSCF 取鉴权向量 S-CSCF 发现本地没有该用户的鉴权向量，发 **Cx-MAR（Multimedia-Auth-Request）**： | AVP | 含义 | |-----|------| | `User-Name` (IMPI) | 取谁 | | `SIP-Number-Auth-Items` | 一次取几组向量（典型 1~n 组） | | `SIP-Authentication-Scheme` | `Digest-AKAv1-MD5` 或 `Digest-AKAv2-MD5` | | `Server-Name` | 本 S-CSCF 标识（HSS 据此记录谁持有向量） | HSS 用 **K_IMS** 生成一组或多组五元组，回 **Cx-MAA**，`SIP-Authentication-Info` AVP 里携带：`RAND`、`AUTN`、`XRES`、`CK`、`IK`、`Authentication-Method`。这一步等价于接入网 AKA 里的 "Authentication Information" 流程，只是接口从 S6a 换成 Cx、算法套件换成 AKAv1/2。 ### 4.4 401 Unauthorized + Security-Server 这是整个流程信息密度最高的一条消息： ```text SIP/2.0 401 Unauthorized WWW-Authenticate: Digest realm="...", nonce="", algorithm=AKAv1-MD5, qop="auth", opaque="<...>" Security-Server: ipsec-3gpp; alg=hmac-md5-96; ealg=null; spi-c=; spi-s=; port-c=; port-s= ``` **两个极易踩坑的设计点：** 1. **nonce 的构造（RFC 3310）**：服务器把 `nonce = BASE64(RAND || AUTN || server-specific-data)` 拼接后下发。UE 解 base64 即可拿到 RAND、AUTN——这意味着 RAND/AUTN **不是**独立的 SIP 头字段，而是塞进 nonce。`opaque` 帮助服务器在第二条 REGISTER 时定位之前下发的向量。`algorithm` 取值 `AKAv1-MD5`（RFC 3310 早期）或 `AKAv2-MD5`（新版本），决定 digest 用什么当"密码"。 2. **P-CSCF 剥离 ck/ik 并注入 Security-Server**。S-CSCF 在 Cx-MAA 拿到的 CK/IK 不会通过 SIP 透传给 UE（UE 本就要自己算），P-CSCF **截留 CK/IK** 作为 IPsec 密钥，并在 401 中**追加 `Security-Server`**：声明 P-CSCF 侧的 SPI、受保护端口、算法。剥离 ck/ik 的另一层含义是防止把密钥暴露在 SIP 明文（此刻 IPsec 还没建）路径上。 ### 4.5 UE 侧 ISIM 的 AKA 运算 UE 把 nonce 里的 RAND、AUTN 交给 **ISIM** 应用（不是 USIM！密钥不同）： ```mermaid flowchart TD A["输入: K_IMS(存在ISIM), RAND, AUTN(来自nonce)"] --> B["f1~f5 算法簇
(TS 33.102 / 35.206 MILENAGE)"] B --> C["验证 AUTN 中的 MAC == f1(K,SQN,RAND,AMF)
失败→Synchronization Failure"] B --> D["RES = f2(K,RAND)"] B --> E["CK = f3(K,RAND), IK = f4(K,RAND)"] D --> F["以 RES 为 password 跑 HTTP Digest
response = H(A1):nonce:nc:cnonce:qop:H(A2)
A1 = H(IMPI:realm:RES)"] E --> G["CK||IK → IPsec SA 密钥
(TS 33.203 §7.3 手工密钥)"] F --> H["第二条 REGISTER Authorization"] G --> I["建立 4 条 IPsec SA, 切换受保护端口"] ``` **SQN 校验失败**时会触发 **Synchronization Failure**（SIP 层表现为再次 401 或超时），UE 回带 `AUTS` 让 HSS 重新同步序列号——这与接入网 AKA 完全同构。 ### 4.6 第二条 REGISTER（受保护端口发出） ```text REGISTER sip:... SIP/2.0 Via: SIP/2.0/UDP :;branch=... ← 注意源端口已切到受保护端口 Security-Client: ipsec-3gpp; alg=...; spi-c=...; spi-s=...; port-c=...; port-s=... Security-Verify: ipsec-3gpp; alg=...; spi-c=; spi-s=; port-c=...; port-s=... ← 回显P-CSCF的Security-Server Authorization: Digest username="", realm="...", nonce="<同上>", uri="sip:...", qop=auth, nc=00000001, cnonce="<...>", response="", algorithm=AKAv1-MD5 ``` `Security-Verify` 必须**逐字回显** 401 里的 `Security-Server`，这是 RFC 3329（Security Agreement）的防降级机制——证明双方就安全参数达成一致。`response` 是用 RES（AKAv1）或 CK||IK（AKAv2）当密码算出的 digest 值。 ### 4.7 Cx-SAR / Cx-SAA：下载用户档案 S-CSCF 用本地存的 XRES 重算同一个 digest response，与 UE 的 `response` 比对：相等即鉴权通过。随后 S-CSCF 发 **Cx-SAR（Server-Assignment-Request）**，把"我现在服务这个用户"登记到 HSS，并下载： - **用户档案（User Profile）**：含 **iFC（initial Filter Criteria）**——决定哪些 AS 要被触发； - **`Charging-Information`、`SCSCF-Restoration-Info`** 等。 HSS 回 **Cx-SAA**。这一步完成后，用户才算"真正在 IMS 落了户"。 ### 4.8 200 OK ```text SIP/2.0 200 OK Contact: ;expires=600000 P-Associated-URI: , Service-Route: ;lr> Require: sec-agree ``` `Service-Route` 让 UE 后续的 INVITE 走到 S-CSCF；`P-Associated-URI` 下发所有可用的公有身份。从这一刻起，Gm 上所有 SIP 都在 IPsec 隧道里。 --- ## 五、IPsec SA 建立机制（ipsec-3gpp 手工密钥） TS 33.203 §6.1 + §7 规定：**Gm 接口不使用 IKE，而是手工密钥的 IPsec**。原因是 IMS-AKA 已经协商出 CK/IK，没必要再跑一遍 IKE 的 DH，省电省信令。SA 拓扑如下： ```mermaid flowchart LR subgraph UE侧 UC["port_uc
(UE受保护客户端口)"] US["port_us
(UE受保护服务端口)"] end subgraph PCSCF侧 PC["port_pc
(P-CSCF受保护客户端口)"] PS["port_ps
(P-CSCF受保护服务端口)"] end UC == "SA1: spi-c(alg=md5/sha, key from IK),
UE→P-CSCF, SPI=spi-c" ===> PC PS == "SA2: spi-s, P-CSCF→UE, SPI=spi-s" ===> US ``` 实际是 **2 对（4 条）单向 SA**：一对用于"受保护客户端口"流量（UE 发起的 SIP 请求，源 port_uc → 目的 port_pc），一对用于"受保护服务端口"流量（网络发给 UE 的 SIP，源 port_pc → 目的 port_us）。密钥由 IK（完整性）/CK（加密，如启用）派生，SA 生命周期跟随 AKA 向量生命周期，**重注册时会换新向量、新建 SA、换新 SPI/端口**。 排障要点：受保护端口一旦对不上，UE 发的 REGISTER 会被 P-CSCF 直接丢弃（表现为 401 后第二条 REGISTER 无响应、T1 超时重传）。 --- ## 六、状态转换图 ```mermaid stateDiagram-v2 [*] --> 未注册: 开机/附着 未注册 --> 待鉴权: 发送第一条REGISTER 待鉴权 --> 收到401: 收到挑战+Security-Server 收到401 --> SA已建立: ISIM算AKA, 建4条SA, 切端口 SA已建立 --> 鉴权中: 发送受保护REGISTER 鉴权中 --> 已注册: 200 OK (XRES比对通过, Cx-SAR完成) 鉴权中 --> 未注册: 403/超时/同步失败 已注册 --> SA已建立: 重注册(换新向量/SPI) 已注册 --> 未注册: 网络发起去注册 ``` --- ## 七、抓包识别与排错思路 **如何识别这个流程**：在 Wireshark 里 filter `sip.Method == "REGISTER" or sip.Status-Code == 401 or sip.Status-Code == 200`，配合 `diameter.cmd.code == 300 || == 303 || == 301 || == 304`（UAR=300/UAA=301、MAR=303/MAA=304、SAR=305/SAA=306——注意 Diameter 应用 ID 为 16777216 即 Cx/Dx）。一条完整鉴权链应看到：1 条裸 REGISTER → 1 条 401 → 1 条带 response 的 REGISTER → 200 OK，中间夹 Cx 的 UAR/MAA/SAR/MAA。 **常见故障点：** | 现象 | 根因 | 排错方向 | |------|------|---------| | 401 后第二条 REGISTER 无响应 | IPsec SA 端口/SPI 不匹配，P-CSCF 丢弃 | 核对 Security-Client 的 port-c/port-s/spi 与 P-CSCF 期望值；查 P-CSCF 日志是否命中 IPsec 入站规则 | | 持续 401 循环 | response 算错：ISIM 的 K_IMS 与 HSS 不一致；或 algorithm AKAv1 vs AKAv2 不匹配 | 比对 HSS/HLR 中 IMS 密钥；确认 ISIM 算法版本与 S-CSCF 配置一致 | | Synchronization Failure | ISIM 的 SQN 与 HSS 不同步 | 检查 AUTS 重同步，必要时在 HSS 重置 SQN | | 403 Forbidden | IMPU 未签约 IMS 业务，或 iFC/默认 CCF 配置缺失 | 查 HSS 用户档案与业务开通 | | 200 OK 但呼叫失败 | Service-Route 未保存或受保护端口写错 | 查 UE 是否正确保存 Service-Route 并用于 INVITE | **厂商差异**：华为/中兴/爱立信的 P-CSCF 在 `alg` 默认值（md5-96 vs sha-1-96）、是否启用 `ealg`（加密）、一次 Cx-MAR 取几组向量（影响重注册频率）上有差异；S-CSCF 对 AKAv2 的支持（部分老网仍只支持 AKAv1-MD5）是现网升级 VoNR 时常踩的坑。 --- ## 八、三种鉴权/安全方案对比 | 维度 | IMS-AKA (AKAv1-MD5) | IMS-AKA (AKAv2-MD5) | NDS-IP (网络域) | 5G AKA (接入层) | |------|---------------------|---------------------|-----------------|----------------| | 长期密钥 | K_IMS (ISIM) | K_IMS (ISIM) | Za 链路证书/PSK | K (USIM) | | digest 密码 | RES | CK‖IK | — | — | | 双向鉴权 | 是(AUTN+RES) | 是 | 是(IPsec/IKE) | 是(AUTN+RES) | | 密钥输出 | CK/IK→IPsec | CK/IK→IPsec | IKE 协商 | KAMF→接入密钥 | | 规范 | RFC3310, TS33.203 | RFC3310bis, TS33.203 | TS33.210 | TS33.501 | --- ## 常见问题 **Q1：AKAv1-MD5 和 AKAv2-MD5 到底差在哪？** A：核心差别是 HTTP Digest 里的"密码"。AKAv1 用 AKA 计算出的 **RES** 当密码；AKAv2 用 **CK‖IK** 拼接当密码。AKAv2 让 digest 的强度直接绑定到 128-bit 的 CK/IK（而非可能较短的 RES），安全性更高，TS 33.203 R15+ 倾向 AKAv2，但现网大量设备仍是 AKAv1。 **Q2：P-CSCF 为什么能剥离 ck/ik？UE 没收到怎么建 SA？** A：UE 的 ISIM 自己用 RAND 跑 AKA 就能算出完全相同的 CK/IK（对称密钥体制），不需要网络下发。P-CSCF 截留 CK/IK 是为了把它当 IPsec 密钥；不在 SIP 里透传反而避免了"明文 SIP 携带密钥"的安全风险。 **Q3：第一条 REGISTER 的 Authorization 里 nonce/response 为空，那它有什么用？** A：它声明了 IMPI、realm、uri，让网络知道"是谁在注册、属于哪个域"，从而触发 401 挑战。这是 HTTP Digest 的标准"先空响应、再被挑战"模式（RFC 2617/7616）。 **Q4：重注册（re-registration）时还要不要重新鉴权？** A：不一定每次都跑完整 AKA。S-CSCF 可在 Cx-MAA 时一次取多组向量，重注册时换用下一组（新 nonce、新 RES、新 SPI、新端口）即可；当向量耗尽或 S-CSCF 配置强制时才重新 MAR。这就是为什么现网重注册时你会看到新 401 但 CK/IK 变化。 **Q5：VoNR 下这套机制和 VoLTE 有区别吗？** A：鉴权机制本身（SIP/Cx/Diameter/ISIM AKA）完全一致；区别在承载——VoNR 的 Gm 跑在 5G 的 PDU 会话上，P-CSCF 与 5GC 的 PCF 通过 **N5（Rx 等价）** 做 QoS 策略，而 VoLTE 走 Rx。但 REGISTER/401/IPsec 这套握手一字不改。 --- ## 参考来源 1. [3GPP TS 24.229 — IMS CCF stage 3 (SIP/SDP)](https://www.3gpp.org/dynareport/24229.htm) — §5.1.1.2 注册、§5.1.2.2 带鉴权的初始注册 2. [3GPP TS 33.203 — IMS security](https://www.3gpp.org/dynareport/33203.htm) — §6 IMS-AKA、§7 IPsec 安全联盟与受保护端口 3. [3GPP TS 29.228 / TS 29.229 — Cx/Dx 接口 (Diameter)](https://www.3gpp.org/dynareport/29229.htm) — UAR/UAA、MAR/MAA、SAR/SAA 命令与 AVP 4. [RFC 3310 — HTTP Digest Authentication Using AKA](https://datatracker.ietf.org/doc/html/rfc3310) — nonce 构造、AKAv1/AKAv2、digest 密码推导 5. [ShareTechnote — IMS REGISTER with Authentication and IPSec](https://www.sharetechnote.com/html/IMS_SIP_Procedure_Reg_Auth_IPSec.html) — 401/Security-Server/Security-Verify 与 SPI 字段抓包级实例 --- > 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 > 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。