# IMS初始注册信令全链拆解：从SIP REGISTER到IMS-AKA鉴权与IPsec安全联盟 > 本轮（第3轮）聚焦 **ims** 子域。前序已覆盖 VoNR 预条件机制，本文转向 IMS 最基础也最关键的入口机制——**初始注册（Initial Registration）**。注册是 VoNR/VoLTE 一切会话建立的前提：没有成功的 REGISTER，UE 既拿不到 Service-Route，也无法建立与 P-CSCF 的 IPsec 安全联盟，更无法被网络路由到（terminating）。本文基于 **3GPP TS 23.228（IMS Stage 2）§5.3.2.2**、**TS 24.229（IMS CPlane SIP/SDP）§5.1.1.2**、**TS 29.228/29.229（Cx/Dx 接口信令流）** 与 **TS 33.203（IMS 安全架构）**，逐消息拆解这条贯穿 5 个网元的信令链。 --- ## 一、为什么注册这么"重"：设计意图 IMS 注册看似只是一条 SIP REGISTER，但标准却设计了 **5 个网元（UE、P-CSCF、I-CSCF、S-CSCF、HSS）跨 Gm/Mw/Cx 三种接口的十余次交互**，其设计意图可归结为四点： 1. **身份与可达性的彻底解耦**：IMPI（私有身份，鉴权用）与 IMPU（公共身份，路由用）分离，注册阶段把"我是谁"与"怎么找到我"分两次解决——前者靠 IMS-AKA，后者靠 Contact + Path。 2. **服务节点动态分配**：S-CSCF 不固定，由 I-CSCF 依据 HSS 下发的**能力集（Server-Capabilities）**实时选择，便于负载均衡与差异化服务承载。 3. **鉴权与密钥合一**：复用 USIM/ISIM 已有的 AKA 框架（TS 33.102），把 UMTS AKA 的 RAND/AUTN 塞进 SIP Digest 的 `nonce` 字段，一次挑战同时完成**双向鉴权 + IPsec 密钥（IK/CK）分发**，避免另起一套密钥协商。 4. **隐式注册（Implicit Registration）**：一个 IMPI 注册即同时激活一组关联的 IMPU（如 tel: 与 sip: 别名），减少空口信令。 理解这四点，才能解释后面那些看似冗余的网元跳转。 --- ## 二、完整信令时序图 下图严格对应 TS 23.228 §5.3.2.2 Figure 5.1（初始注册流程），并标注了每条消息携带的关键 IE： ```mermaid sequenceDiagram autonumber participant UE participant PCSCF as P-CSCF participant ICSCF as I-CSCF participant SCSCF as S-CSCF participant HSS as HSS Note over UE,HSS: === 阶段一：选路到 S-CSCF === UE->>PCSCF: REGISTER (IMPI/IMPU, Sec-Client, 无凭证) PCSCF->>ICSCF: REGISTER (+Path=P-CSCF地址) ICSCF->>HSS: Cx-UAR (User-Name=IMPI, Public-Id=IMPU, Visited-Network-Id) HSS-->>ICSCF: Cx-UAA (Server-Capabilities 能力集) ICSCF->>SCSCF: REGISTER (I-CSCF 按能力集选定 S-CSCF) Note over UE,HSS: === 阶段二：取鉴权向量并挑战 === SCSCF->>HSS: Cx-MAR (Multimedia-Auth-Request, 取 AV) HSS-->>SCSCF: Cx-MAA (RAND‖AUTN, XRES, IK, CK, Digest-AKAv1-MD5) SCSCF-->>ICSCF: 401 Unauthorized (WWW-Authenticate: nonce=base64(RAND‖AUTN)) ICSCF-->>PCSCF: 401 (P-CSCF 截留并存储 IK/CK) PCSCF-->>UE: 401 Unauthorized Note over UE: UE: ISIM 计算 RES/IK/CK，校验 AUTN 与 SQN 新鲜性 Note over UE,HSS: === 阶段三：带凭证重发 + 下载用户档案 === UE->>PCSCF: REGISTER (Authorization: response, Sec-Verify, 经 IPsec-SA) PCSCF->>ICSCF: REGISTER ICSCF->>HSS: Cx-UAR (再次确认/选路) HSS-->>ICSCF: Cx-UAA (S-CSCF 名称) ICSCF->>SCSCF: REGISTER SCSCF->>HSS: Cx-SAR (Server-Assignment-Type=REGISTRATION) HSS-->>SCSCF: Cx-SAA (User-Data: iFC/Service-Profile, HSS 标记 REGISTERED) SCSCF-->>ICSCF: 200 OK (P-Associated-URI, Service-Route, Security-Server) ICSCF-->>PCSCF: 200 OK PCSCF-->>UE: 200 OK (P-Associated-URI, Service-Route) Note over SCSCF,HSS: 阶段四：S-CSCF 依 iFC 发起 Third-Party REGISTER 到 AS ``` 四个阶段清晰可分：**选路 → 鉴权挑战 → 凭证校验与档案下载 → 第三方注册**。其中第二次 REGISTER 经过 I-CSCF 时仍会触发 Cx-UAR/UAA；由于此时 Cx-SAR 尚未执行，HSS 通常仍返回能力集（或部分实现暂存的 S-CSCF 名），I-CSCF 据此再次选路到同一 S-CSCF——这正是不同厂商行为出现差异的节点之一（后文详述）。 --- ## 三、关键消息的 IE 逐字段拆解 ### 3.1 第一条 REGISTER（UE → P-CSCF） | SIP 头/IE | 取值示例 | 作用 | |-----------|---------|------| | Request-URI | `sip:home.net` | 归属域 registrar 地址（非个人 URI） | | From / To | `;tag=...` | IMPU（公共身份，两者一致） | | Contact | `;+sip.instance="";+g.3gpp.icsi-ref="urn:urn-7:3gpp-service.ims.icsi.mmtel"` | UE 联系地址 + 设备标识 + 支持的 ICSI | | Authorization | `username="user1@home.net", realm="home.net", uri="sip:home.net", nonce="", response=""` | IMPI + 空 nonce/response（声明待鉴权） | | Security-Client | `ipsec-3gpp; alg=hmac-sha-1-96; ealg=...; spi-c=...; port-c=...` | UE 侧 IPsec SA 参数 | | Require / Proxy-Require | `sec-agree` | 强制启用安全协商 | **设计要点**：第一条 REGISTER 故意不携带凭证（nonce 为空），目的是让网络先把"该用谁鉴权、用什么算法"这件事谈清楚。`sec-agree` 通过 Require 头强制 P-CSCF 必须先完成安全协商，否则 421/494 拒绝。 ### 3.2 401 Unauthorized（S-CSCF → UE） ``` WWW-Authenticate: Digest realm="home.net", nonce="N0RBTmhP...="(base64(RAND‖AUTN‖server-specific)), algorithm=AKAv1-MD5, qop="auth", opaque="..." ``` **最精妙之处在 `nonce`**：它不是随机串，而是 `base64(RAND ‖ AUTN ‖ server-specific-data)`。把整个 AKA 挑战塞进 Digest 字段，使得**现有 SIP Digest 框架无需改造即可承载 AKA**（RFC 3310）。P-CSCF 在转发前会从该响应中截留 IK（完整性密钥）与 CK（加密密钥）——这是后续 IPsec SA 的密钥来源。 ### 3.3 第二条 REGISTER（带凭证） | IE | 说明 | |----|------| | Authorization `response` | `MD5(HA1:nonce:nc:cnonce:qop:MD5(method:uri))`，其中"密码"用 **RES**（ISIM 计算的鉴权响应）替代 | | Security-Verify | 回显 P-CSCF 在 401 中下发的 Security-Server，确认 SA 参数被接受 | | 经 IPsec ESP 承载 | 自此刻起，UE↔P-CSCF 间的 SIP 走受保护端口（protected_client_port / protected_server_port） | ### 3.4 200 OK 的三个"命脉"头 - **P-Associated-URI**：列出本次隐式注册激活的所有 IMPU（IMPU 集合）。 - **Service-Route**：UE 必须在后续所有非 REGISTER 请求的 Route 头中填入的 S-CSCF 路由 URI——没有它，UE 发不出 INVITE。 - **Path 已由 P-CSCF 记录于 S-CSCF**：保证后续被叫会话能从 S-CSCF 逆向找到 P-CSCF 再到 UE。 --- ## 四、Cx 接口 Diameter 命令与 AVP Cx 接口基于 Diameter（TS 29.229），命令码集中在 300~305。下表是注册链用到的核心命令： | 命令 | 缩写 | 码值 | 方向 | 注册中的用途 | |------|------|------|------|--------------| | User-Authorization-Req/Ans | UAR/UAA | 300 | I-CSCF↔HSS | 判断是否允许注册、返回 S-CSCF 能力集或名称 | | Server-Assignment-Req/Ans | SAR/SAA | 301 | S-CSCF↔HSS | 通知 HSS 该 S-CSCF 服务此用户、下载用户档案（User-Data） | | Multimedia-Auth-Req/Ans | MAR/MAA | 303 | S-CSCF↔HSS | 取鉴权向量 AV（RAND/AUTN/XRES/IK/CK） | | Location-Info-Req/Ans | LIR/LIA | 302 | I-CSCF↔HSS | 会话发起/终止时定位已注册 S-CSCF | | Registration-Termination-Req/Ans | RTR/RTA | 305 | HSS→S-CSCF | 网络侧发起去注册 | | Push-Profile-Req/Ans | PPR/PPA | 304 | HSS→S-CSCF | 用户档案变更时推送 | Cx-MAA 返回的关键 AVP：`SIP-Authentication-Scheme=Digest-AKAv1-MD5`、`SIP-Authenticate`（RAND‖AUTN）、`SIP-Authorization`（XRES，网络侧校验用）、`Confidentiality-Key`（CK）、`Integrity-Key`（IK）。 --- ## 五、IMS-AKA 鉴权向量与密钥推演 下图展示 AV（Authentication Vector）的内部结构与密钥如何在网元间流动： ```mermaid flowchart TD subgraph HSS["HSS（持长期密钥 K）"] K["K (长期密钥, 128bit)"] AV["AV = (RAND, XRES, CK, IK, AUTN)
由 K 与 RAND 经 AKA 算法簇推演"] end subgraph UE["UE / ISIM（持同一 K）"] ISIM["收到 RAND, AUTN
校验 MAC 与 SQN
推演出 RES, CK, IK"] end subgraph PCSCF["P-CSCF"] SA["存储 IK, CK
建立 IPsec SA"] end AV -->|"Cx-MAA"| SCSCF["S-CSCF
持 XRES/IK/CK"] SCSCF -->|"401 nonce=RAND‖AUTN"| UE ISIM -->|"ISIM 本地推演"| UE SCSCF -->|"把 IK/CK 传给 P-CSCF"| SA UE -.->|"RES 作为 Digest 密码"| SCSCF SCSCF -->|"比对 RES vs XRES"| OK{"匹配?"} OK -->|是| SUCC["鉴权成功"] OK -->|否| FAIL["403 Forbidden"] ``` **为什么 IK/CK 要到 P-CSCF 而不是 S-CSCF 终止？** 因为 IPsec 安全联盟的端点是 UE↔P-CSCF（接入侧第一个网元），S-CSCF 位于更深的归属网，NAT/拓扑都不适合做 IPsec 端点。S-CSCF 只负责校验 XRES，再把 IK/CK "交接"给 P-CSCF。 ### IMS-AKA 与原生 SIP Digest 的本质区别 | 维度 | IMS-AKA（TS 33.203） | 原生 SIP Digest（RFC 2617） | |------|----------------------|-----------------------------| | 密钥来源 | ISIM 内共享密钥 K + AKA 算法 | 用户名/口令 | | 双向鉴权 | ✅ UE 校验 AUTN→鉴权网络 | ❌ 仅网络鉴权 UE | | 密钥派生 | ✅ 派生 IK/CK 建立 IPsec | ❌ 不派生流量密钥 | | 抗重放 | ✅ SQN 序列号机制 | ⚠️ 仅靠 nonce/nc | | nonce 语义 | RAND‖AUTN（有结构） | 随机串 | --- ## 六、IPsec 安全联盟建立状态机 UE 在注册过程中要完成 sec-agree 与 IPsec SA 协商。下图是 UE 侧的状态转换（TS 33.203 §6.2）： ```mermaid stateDiagram-v2 [*] --> 未鉴权 未鉴权 --> 待协商: 发送 REGISTER(含 Security-Client) 待协商 --> SA参数就绪: 收到 401(含 Security-Server) SA参数就绪 --> SA建立中: ISIM 校验 AUTN 成功, 协商 SPI/端口/算法 SA建立中 --> 已保护: 建立两对单向 ESP SA(4条)\n切换到 protected port 已保护 --> 已注册: 发送第二条 REGISTER 并收到 200 OK 已注册 --> 未鉴权: 注册超时/去注册(RTR)\nSA 拆除 待协商 --> 失败: sec-agree 拒绝(421/494) SA建立中 --> 失败: AUTN 校验失败/MAC不符 ``` 注意建立的是**两对单向 SA（共 4 条）**：一对承载 SIP 信令到 `port_pcscf`，另一对到 `port_pcscf+1`，以区分不同用途。算法由 Security-Client/Server 中的 `alg`（完整性，如 hmac-sha-1-96）与 `ealg`（加密，如 aes-cbc）协商。 --- ## 七、抓包识别与实战排错 ### 7.1 抓包识别（Wireshark 过滤式） | 目的 | 过滤表达式 | |------|-----------| | 抓注册请求 | `sip.Method == "REGISTER"` | | 定位挑战 | `sip.Status-Code == 401` | | 查 nonce 算法 | `sip.www_authenticate.string contains "AKAv1-MD5"` | | Cx 全集 | `diameter.cmd.code >= 300 && diameter.cmd.code <= 305` | | IPsec 加密段 | `esp` 配合 SPI 过滤 | ### 7.2 常见故障点 1. **401 后跟随 403 Forbidden**：99% 是 RES≠XRES。根因多为 ISIM/USIM 与 HSS 的密钥 K 不一致、制卡错配，或 AMF 字段配置不同。 2. **卡在 I-CSCF 选不到 S-CSCF**：HSS 未配能力集或 S-CSCF 节点未注册到 DNS/DRA；表现为 Cx-UAA 返回 Result-Code 非 2001。 3. **拿到 401 却无后续 REGISTER**：UE 侧 ISIM 校验 AUTN 失败（MAC 不符或 SQN 不同步，触发 Resync 重同步流程）。 4. **200 OK 缺 Service-Route**：UE 后续 INVITE 会因找不到 S-CSCF 而 403/超时；多为 S-CSCF 配置遗漏。 5. **sec-agree 421/494**：P-CSCF 拒绝安全参数，常见于 SPI/算法不匹配或 IPsec 端口被防火墙拦截。 6. **5G 场景拿不到 P-CSCF 地址**：VoNR 下 P-CSCF 地址由 SMF/PCF 经 PDU 会话建立的 PCO/ePCO 下发（TS 23.501），若 DNN 非 IMS 专网或 PCF 策略缺失，UE 无法发起注册。 ## 常见问题 **Q1：IMPI 和 IMPU 到底有什么区别？为什么注册要分开？** A：IMPI 是私有身份（如 `user1@home.net` 或由 IMSI 派生 `imsi...@ims.mnc.mcc.3gppnetwork.org`），只用于鉴权，对其他用户不可见；IMPU 是公共身份（如 `sip:user1@home.net`、`tel:+86...`），用于路由与被叫。分开是因为鉴权与服务可达性是两个正交问题：鉴权看"你是谁"（IMPI+K），可达性看"怎么找到你"（IMPU+Contact+Path）。 **Q2：IMS-AKA 的 nonce 为什么要塞 RAND 和 AUTN？** A：因为 SIP Digest 的 `nonce` 字段是标准里唯一允许自由携带挑战数据的载体。把 AKA 的 RAND（随机挑战）和 AUTN（含 MAC+SQN 的鉴权令牌）编码进 nonce，就能在不修改 SIP 消息结构的前提下复用整套 AKA 机制，实现双向鉴权并让 UE 本地推演出 IPsec 密钥——这是 RFC 3310 的核心巧思。 **Q3：第二次 REGISTER 经过 I-CSCF 时，HSS 怎么知道选哪个 S-CSCF？** A：严格按 TS 23.228，S-CSCF 名称是经 Cx-SAR 才"正式"写入 HSS 的。而第二次 REGISTER 发生在 SAR 之前，所以此时 I-CSCF 的 Cx-UAR 仍可能拿到能力集；实践中 I-CSCF 会结合本地缓存/亲和性再次选到同一 S-CSCF，待鉴权通过后 SAR 才把名称固化下来。这也是不同厂商时序略有差异的根因。 **Q4：VoNR 下的 IMS 注册和 VoLTE 有本质区别吗？** A：IMS 注册流程本身（Gm/Mw/Cx 上的 SIP 与 Diameter）几乎不变。差异在**承载与 P-CSCF 发现**：VoLTE 走 EPS bearer + DHCP/PCO 拿 P-CSCF；VoNR 走 5G PDU 会话（IMS 专用 DNN，5QI=5 信令 / 5QI=1 语音）+ PCF 经 ePCO 下发 P-CSCF。即"IP-CAN 换了，IMS 核心网注册机制照旧"。 **Q5：如果 AUTN 中的 SQN 不同步会怎样？** A：UE 校验 SQN 新鲜性失败时会进入重同步流程：在第二条 REGISTER 的 Authorization 中携带 `auts` 参数（带 UE 侧当前 SQN）回传给 HSS，HSS 据此调整计数器后重新下发 AV，UE 再完成注册。抓包上会看到一次带 auts 的 REGISTER 与紧接着的再次 401/200。 --- ## 参考来源 1. [3GPP TS 23.228 — IMS Stage 2（架构与流程，§5.3.2 注册流程）](https://www.3gpp.org/dynareport/23228.htm) — 注册信令流程权威定义 2. [3GPP TS 24.229 — IMS SIP/SDP 信令（§5.1.1.2 注册过程）](https://www.3gpp.org/dynareport/24229.htm) — SIP 头与 IE 详细规范 3. [3GPP TS 29.228 / TS 29.229 — Cx/Dx 接口信令流与 Diameter AVP](https://www.3gpp.org/dynareport/29229.htm) — UAR/SAR/MAR 命令与 AVP 定义 4. [3GPP TS 33.203 — IMS 安全架构（IMS-AKA、IPsec、sec-agree）](https://www.3gpp.org/dynareport/33203.htm) — 鉴权向量、IK/CK 与安全联盟 5. [RFC 3310 — AKA as a Digest Authentication Mechanism](https://www.rfc-editor.org/rfc/rfc3310) — nonce 承载 RAND/AUTN 的设计原理 --- > 本文由「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 等场景全覆盖。