首页 › ims › IMS-AKA鉴权挑战与IPsec安全联盟拆解

5G VoNR IMS注册中的IMS-AKA鉴权挑战与IPsec安全联盟建立机制全链拆解

在5G核心网（5GC）完成主认证（5G AKA/EAP-AKA'）并建立IMS PDN连接之后，VoNR终端仍不能直接拨打语音电话——它必须先在IMS域完成一次独立的、基于ISIM凭据的IMS-AKA双向认证，并在UE与P-CSCF之间协商出一对IPsec SA（Security Association）。本文聚焦TS 24.229 §5.1.1.2.1（初始注册）、§5.1.1.2A（鉴权处理）与TS 33.203 §6.2（IMS-AKA）所定义的这条"401挑战→密钥推演→IPsec SA建立"信令链，逐消息拆解关键IE，并给出抓包识别与排错实战。

一、机制定位：为什么IMS需要"二次认证"

很多工程师会困惑：UE在5GC已经做过一次5G AKA，为什么IMS还要再做一次？根本原因在于信任域隔离与凭据分离：

这一设计源自TS 33.203的安全架构原则：IMS安全（接入安全+网络域安全）独立于底层IP-CAN的安全。下图给出IMS注册鉴权在VoNR整体流程中的位置。

flowchart TD
    A[5GC主认证<br/>5G AKA] --> B[IMS PDU会话建立<br/>5QI=5 信令专用]
    B --> C[P-CSCF发现<br/>PCF Rx/PCO]
    C --> D[IMS初始注册<br/>SIP REGISTER]
    D --> E{IMS-AKA<br/>401挑战}
    E --> F[IPsec SA建立<br/>UE↔P-CSCF]
    F --> G[200 OK<br/>注册成功]
    G --> H[可发起VoNR呼叫<br/>SIP INVITE]

    style E fill:#ffe4b5
    style F fill:#b5e4ff

注意一个关键事实：IMS-AKA使用的认证算法本质上就是TS 33.102定义的UMTS AKA，复用了RAND/AUTN/XRES/CK/IK五元组。它和5G AKA共享同一套数学内核（MILENAGE/MAC函数），但密钥来源、向量生成节点、挑战下发通道完全不同——这正是后续对比表（第四节）的核心。

二、P-CSCF发现：IMS认证的前提

UE要发起REGISTER，必须先知道P-CSCF的地址。在5G架构下，TS 23.228 Annex E.1.1与TS 23.501定义了通过5GC下发P-CSCF地址的机制：

5G商用网络绝大多数采用方案A，因为P-CSCF地址由SMF从UDM订阅数据或本地配置获取后直接注入PCO，省去额外DHCP往返，时延更低。

三、IMS-AKA完整信令时序（TS 24.229 §5.1.1.2.1）

下面是基于TS 23.228 §5.2.2.3（注册信息流）与TS 24.229 §5.1.1.2A（鉴权处理）绘制的完整时序图。图中的Cx接口（HSS↔S-CSCF）使用Diameter协议，承载Multimedia-Auth (MAR/MAA)和Server-Assignment (SAR/SAA)两个命令。

sequenceDiagram
    autonumber
    participant UE
    participant PCSCF as P-CSCF
    participant ICSCF as I-CSCF
    participant SCSCF as S-CSCF
    participant HSS

    Note over UE: 携带ISIM:IMPI/IMPU/K
    UE->>PCSCF: REGISTER(impi,impu,Security-Client,Require:sec-agree)
    PCSCF->>ICSCF: 转发REGISTER(增加P-CSCF网络ID)
    ICSCF->>HSS: Cx-Query/UAR(查询是否已注册+S-CSCF能力)
    HSS-->>ICSCF: Cx-Query Resp/UAA(返回S-CSCF能力集)
    ICSCF->>SCSCF: 转发REGISTER(选定S-CSCF)

    Note over SCSCF: 判断:无此用户鉴权向量
    SCSCF->>HSS: Cx-Put/Pull = MAR(请求认证向量)
    HSS->>HSS: 生成AV(RAND,AUTN,XRES,CK,IK)
    HSS-->>SCSCF: MAA(返回AV+鉴权信息)

    Note over SCSCF: 构造401挑战
    SCSCF-->>PCSCF: 401 Unauthorized<br/>(WWW-Authenticate:AKAv1-MD5,nonce,RAND/AUTN)<br/>Security-Server:IPsec参数
    Note over PCSCF: 缓存CK/IK用于IPsec SA
    PCSCF-->>UE: 401 Unauthorized(含Security-Server)

    Note over UE: ISIM验证AUTN→计算RES→派生CK/IK
    UE->>PCSCF: REGISTER(Authorization:response=H(RES),Security-Verify)
    Note over UE,PCSCF: 双方激活IPsec SA
    PCSCF->>SCSCF: 转发REGISTER(受SA保护)
    SCSCF->>SCSCF: 校验response==H(XRES)
    SCSCF->>HSS: SAR(注册用户,下载用户档案)
    HSS-->>SCSCF: SAA(用户档案+IFC)
    SCSCF-->>PCSCF: 200 OK(Service-Route)
    PCSCF-->>UE: 200 OK(注册成功)

逐步IE解析

步骤1：初始REGISTER（未鉴权）

UE构造的REGISTER消息核心字段（TS 24.229 §5.1.1.2.1.1）：

IE/头域 取值示例 来源/作用
Request-URI sip:ims.mnc<mnc>.mcc<mcc>.3gppnetwork.org 注册域，用于I-CSCF路由
To <sip:impu@ims...> 与注册身份一致
From <sip:impu@ims...>;tag=... 携带tag
Contact <sip:impi@ue_ip:port>;+sip.instance="<urn:gsma:imei:...>" UE IP+Instance ID，用于GRUU
Authorization Digest username="impi",realm="ims...",uri="sip:...",nonce="",response="" 空nonce/response，表示初次注册
Security-Client ipsec-3gpp; alg=hmac-md5-96; spi-c=...; port-c=... UE声明的安全能力（RFC 3329）
Require sec-agree 强制要求安全协商

步骤6-7：MAR/MAA（Cx接口，Diameter）

S-CSCF判断本地无此用户的有效鉴权向量，向HSS发送Multimedia-Auth-Request。HSS基于用户长期密钥K，按TS 33.102 Annex的MILENAGE算法生成认证向量AV，通过Multimedia-Auth-Answer返回。一个MAA通常返回多组AV（如5组），S-CSCF按序使用，减少与HSS的交互次数。

步骤8-9：401挑战

S-CSCF返回401 Unauthorized，关键头域是WWW-Authenticate：

WWW-Authenticate: Digest realm="ims.mnc001.mcc460.3gppnetwork.org",
    nonce="OTNhM2I0Y2Vj...YzQ=",
    algorithm=AKAv1-MD5,
    qop="auth-int",
    opaque="...", 
    ck="a8e8e3d0...", ik="b3f3d7c2..."

同时401携带Security-Server头，由P-CSCF填充（来自其本地策略）：

Security-Server: ipsec-3gpp; alg=hmac-md5-96; ealg=des-ede3-cbc;
    spi-c=1947010302; spi-s=1947010303;
    port-c=36500; port-s=36501

步骤11：受保护的重REGISTER

UE收到401后执行三件事：①ISIM用K和RAND执行AKA，验证AUTN（网络合法性），派生RES/CK/IK；②用RES按RFC 3310计算response；③按Security-Server参数安装IPsec SA。随后发送受保护的重REGISTER：

Authorization: Digest username="impu",realm="ims...",
    nonce="OTNhM2I0...YzQ=",
    uri="sip:ims...",response="6629fae49393a0539749336e...",
    algorithm=AKAv1-MD5,qop=auth-int,nc=00000001,cnonce="..."
Security-Verify: ipsec-3gpp; mod=trans  // UE回显P-CSCF选择的算法
Via: SIP/2.0/UDP <ue_ip>:36500;branch=...  // 受保护端口

S-CSCF收到后用XRES（HSS返回的期望响应）作相同摘要运算，比对response，一致即认证通过。

四、IMS-AKA密钥推演与IPsec SA机制

4.1 IMS-AKA vs 5G AKA对比

维度 5G AKA（主认证） IMS-AKA（业务认证）
凭据载体 USIM（5G应用） ISIM（IMS应用）
长期密钥 K（与5GC共享） K（独立，可不同）
向量生成节点 UDM/ARPF（5GC） HSS（IMS）
挑战下发通道 NAS（Authentication Request） SIP 401（WWW-Authenticate）
期望响应比对 SEAF/UDM侧 S-CSCF侧
派生密钥 Kamf→Kgnb→NR加密密钥 CK/IK→IPsec SA密钥
保护对象 NAS信令、空口UP SIP信令（UE↔P-CSCF）
规范依据 TS 33.501 TS 33.203

4.2 IPsec SA建立（RFC 3329安全协商）

IMS-AKA派生的CK ‖ IK（共256bit）作为IPsec SA的主密钥，由P-CSCF和UE各自独立持有。SA参数通过三个头域完成协商（TS 33.203 §7.1 + RFC 3329）：

flowchart TB
    subgraph 协商三阶段
        A[Security-Client<br/>UE→P-CSCF<br/>声明支持算法列表] --> B[Security-Server<br/>P-CSCF→UE<br/>选定算法+分配SPI/端口]
        B --> C[Security-Verify<br/>UE→P-CSCF<br/>回显确认+激活SA]
    end
    subgraph SA参数
        D1[spi-c/s: 入向SPI]
        D2[port-c/s: 受保护UDP端口]
        D3[alg: 完整性算法<br/>hmac-md5-96/sha-1-96]
        D4[ealg: 加密算法<br/>des-ede3-cbc/aes-cbc]
        D5[mod: 传输模式trans]
    end
    C --> D1 & D2 & D3 & D4 & D5

SA建立后，后续所有UE↔P-CSCF的SIP消息（REGISTER/INVITE/PRACK）必须通过ESP或AH隧道/传输模式封装，目标端口使用port-c/port-s（通常为高于49152的随机高端口），而非默认的5060。S-CSCF与I-CSCF之间的信令则不涉及IPsec，走运营商内网的NDS/IP（TS 33.210）。

4.3 UE侧状态转换（TS 24.229 §5.1.1.2A）

stateDiagram-v2
    [*] --> NotRegistered: IMS PDU已建立
    NotRegistered --> PendingChallenge: 发送初始REGISTER(空nonce)
    PendingChallenge --> ComputingRES: 收到401+WWW-Authenticate
    ComputingRES --> SaEstablished: ISIM验证AUTN OK<br/>安装IPsec SA
    SaEstablished --> Registered: 发送受保护REGISTER→收到200 OK
    ComputingRES --> AuthFailed: AUTN校验失败(MAC错误)
    AuthFailed --> [*]: 中止注册,上报IMS注册失败
    PendingChallenge --> AuthFailed: 超时无401
    Registered --> NotRegistered: 注册超时/网络去注册

五、抓包识别与故障排查实战

5.1 抓包识别要点

在Wireshark中对IMS信令专用承载（5QI=5）的GTP隧道内层抓包，按以下特征识别该流程：

  1. 初始REGISTER：Authorization头中nonce为空、response为空，Require含sec-agree。
  2. 401响应：SIP Status 401，WWW-Authenticate含algorithm=AKAv1-MD5和长nonce。
  3. 重REGISTER：response非空，Via端口变为受保护端口（非5060），且该包被ESP封装（在Wireshark中显示为独立的ESP帧）。
  4. 200 OK：携带Service-Route头（含S-CSCF路径信息），UE缓存供后续呼叫路由。

5.2 典型故障点与排错

故障现象 根因分析 排查方向
UE循环发REGISTER，重复收401 response计算错误（ISIM密钥K不匹配）或SA未真正激活导致P-CSCF拒绝受保护包 抓包确认重REGISTER是否被ESP封装；核对ISIM与HSS的K一致性
401后UE无重REGISTER，注册失败 AUTN校验失败（MAC不匹配）或SQN失步 检查ISIM SQN与HSS的SQN是否严重失步（需resync），MAA可能返回同步失败
收到403 Forbidden S-CSCF比对response≠H(XRES)，或IMPI/IMPU不在签约 核对HSS用户档案、IMPU状态（ barred?）
注册成功但无法呼叫 Service-Route未正确缓存或IPsec SA单向建立 检查SA方向参数、spi-c/s是否对齐
漫游时401丢失 I-CSCF到S-CSCF路由错误，或P-CSCF网络ID校验失败 核查Cx-Query返回、I-CSCF的S-CSCF选择逻辑

SQN失步（最常见的"幽灵故障"）：当UE与HSS的序列号SQN偏差超过阈值，ISIM的AUTN校验会返回"同步失败"，UE在重REGISTER的Authorization头中携带AUTS参数（TS 33.102 §6.3.2）。HSS收到后执行重同步，重新对齐SQN并下发新向量。抓包中若发现重REGISTER的Authorization携带auts=字段，即可定位为此问题。

常见问题

Q1: IMS-AKA和5G AKA用的是同一个密钥K吗？ A: 不一定。ISIM和USIM是同一UICC上的两个独立应用，各自有独立的长期密钥K。运营商务实做法多为"K_ISIM = K_USIM"以简化制卡，但从协议角度两者是隔离的。这也是为何5GC主认证通过不代表IMS认证必然通过。

Q2: 为什么Authorization头里空nonce的REGISTER也能发出去？ A: TS 24.229 §5.1.1.2.1允许初始REGISTER携带"占位"的Digest头（nonce/response为空），其唯一目的是触发S-CSCF发起挑战。S-CSCF识别到空响应即判定为初次注册，不下发200 OK而回401。这是一种"先试探后鉴权"的设计。

Q3: IPsec SA建立后，之前的REGISTER和401用的是什么保护？ A: 初始REGISTER和401是未受IPsec保护的明文SIP（仅依赖5GC的接入层安全）。这正是Require: sec-agree和Proxy-Require: sec-agree存在的意义——P-CSCF据此承诺"在SA建立前不处理后续业务请求，仅处理鉴权相关消息"，避免明文窗口被利用。

Q4: nonce里的RAND和AUTN是明文吗？被窃听会怎样？ A: nonce中的RAND是明文随机数，AUTN包含MAC和SQN。攻击者窃听nonce也无法伪造合法response，因为响应计算依赖只有ISIM和HSS知道的密钥K。nonce外的服务器特定数据用K派生的密钥做了MAC保护（TS 33.203 §H.1），防止重放和篡改。

Q5: VoLTE和VoNR在IMS-AKA流程上有区别吗？ A: IMS-AKA本身完全一致（同一套TS 33.203）。唯一差异在P-CSCF发现通道：VoLTE通过EPS的PDN建立+PCO下发，VoNR通过5GS的PDU会话建立+PCO下发；以及底层IP-CAN从4G LTE变为5G NR。IMS域以上的注册/鉴权/IPsec逻辑完全相同，这也是VoLTE/VoNR终端IMS栈可复用的基础。

参考来源

  1. 3GPP TS 24.229 V18.x.x — §5.1.1.2.1 初始注册、§5.1.1.2A 鉴权处理（IP Multimedia CC based on SIP and SDP; Stage 3）
  2. 3GPP TS 33.203 V18.x.x — §6.2 IMS-AKA机制、§7.1 SA与安全协商、Annex H nonce格式（3G security; Access security for IP-based services）
  3. 3GPP TS 23.228 V18.x.x — §5.2.2.3 注册信息流（User not registered），Annex E.1.1 P-CSCF发现（IMS架构Stage 2）
  4. RFC 3310 — AKAv1-MD5：AKA的HTTP Digest摘要认证扩展
  5. RFC 3329 — Security-Client/Server/Verify头的SIP安全机制协商
  6. ShareTechnote / 5G6G Academy — VoNR Registration Call Flow & SIP Signaling — IPsec SA在步骤8建立、后续SIP受保护的实战解读

本文由「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 等场景全覆盖。

51学通信知识星球海报-扫码加入

📎 本分类最新文章