首页 › security › 5G数据网二次认证授权机制

5G PDU会话中的数据网二次认证与授权机制深度解析

一、为什么5G在主认证之外还需要"二次认证"

5G系统在UE注册阶段通过5G-AKA或EAP-AKA'完成主认证（Primary Authentication），其本质是验证"UE与USIM是否合法、属于哪个运营商网络"，并在UE与5GC之间建立NAS/AS安全上下文。但主认证解决的是网络层接入凭证的合法性，并不能回答一个更细粒度的问题：这个已经被5GC接纳的UE，是否有权接入某一个特定的数据网络（DN）？

典型的现实场景包括：

3GPP为此在TS 23.502 clause 4.3.2.3定义了独立的"PDU Session建立期间由DN-AAA Server执行的二次授权/认证"流程，并在TS 33.501 clause 6.3给出安全要求。它的核心定位是：可选、独立、EAP承载、由SMF按需触发。理解这条流程，是把握5G"网络即服务、数据网即客户"商业模式下鉴权边界的关键。

二、架构定位与触发条件

二次认证在网络架构中的逻辑位置如下图所示。SMF是整个流程的EAP Authenticator（认证者），UE是EAP Peer（被认证者），DN-AAA Server是EAP Server（最终鉴权决策点）。三者之间通过EAP消息容器透明承载，鉴权结果决定PDU Session的最终建立或拒绝。

flowchart TD
    UE["UE<br/>(EAP Peer)"]
    AMF["AMF<br/>(N1 NAS中继)"]
    SMF["SMF<br/>(EAP Authenticator<br/>+ DN-AAA Proxy)"]
    UPF["UPF<br/>(透明中继)"]
    DNAAA["DN-AAA Server<br/>(EAP Server)"]

    UE -->|"N1 NAS<br/>(EAP message容器)"| AMF
    AMF -->|"Nsmf_PDUSession_*"| SMF
    SMF -->|"N4 会话<br/>TS 29.561"| UPF
    UPF -->|"透明转发"| DNAAA

    style SMF fill:#e1f5ff,stroke:#0277bd,stroke-width:2px
    style DNAAA fill:#fff4e1,stroke:#e65100,stroke-width:2px

SMF何时决定触发二次认证？依据TS 23.502 clause 4.3.2.3 Step 0，触发源有三：

  1. 订阅数据触发：UDM下发的PDU Session订阅信息中，针对某(DNN, S-NSSAI)组合标记了"需要二次认证"；
  2. 本地策略触发：SMF本地配置策略要求该DNN必须经过DN-AAA鉴权；
  3. UE主动指示：UE在PDU Session Establishment Request中携带了SM PDU DN Request Container或独立的DN-specific identity，主动声明它希望接入一个需要独立鉴权的DN。

SMF识别DN-AAA Server的依据同样在Step 0中明确：本地配置，或UE提供的DN-specific identity（该identity记录在SM PDU DN Request Container内，或出现在PDU Session Authentication Complete消息的EAP message中，定义见TS 24.501）。

一个关键架构细节：DN-AAA Server的物理位置决定了消息路径。当DN-AAA位于5GC外部时，SMF必须经UPF透明中继（Step 1要求先建立N4 session作为承载管道，TS 29.561定义此信令封装）；当DN-AAA位于5GC内部、SMF可直接寻址时，UPF被旁路——规范NOTE 2明确：此时Step 1跳过，Step 2/3a/3f/4/6不经UPF执行。这是排错时第一条要核实的拓扑事实。

三、完整信令时序图与逐步IE解析

下图是TS 23.502 Figure 4.3.2.3-1的完整时序还原，覆盖非漫游、LBO与Home Routed漫游三种部署（HR场景下流程中的SMF即H-SMF）。

sequenceDiagram
    autonumber
    participant UE
    participant AMF
    participant SMF as SMF<br/>(H-SMF if HR)
    participant UPF
    participant AAA as DN-AAA Server

    UE->>AMF: PDU Session Establishment Request<br/>(含SM PDU DN Request Container)
    AMF->>SMF: Nsmf_PDUSession_CreateSMContext
    Note over SMF: Step0: 判定需二次认证<br/>识别DN-AAA Server

    opt 无可用N4承载管道
        SMF->>UPF: Step1: N4 Session Establishment
        UPF-->>SMF: N4响应
    end

    SMF->>UPF: Step2: 认证请求(含DN-specific identity, GPSI)
    UPF->>AAA: 透明转发(TS 29.561)
    AAA-->>UPF: Step3a: Authentication/Authorization消息
    UPF-->>SMF: 透明转发

    SMF->>AMF: Step3b: Namf_Communication_N1N2MessageTransfer<br/>(DN Request Container→N1 SM)
    AMF->>UE: Step3c: PDU Session Authentication Command<br/>(EAP Request/AKA'-Challenge)
    UE-->>AMF: Step3d: PDU Session Authentication Complete/Command<br/>(EAP Response)
    AMF->>SMF: Step3e: Nsmf_PDUSession_UpdateSMContext<br/>(携带DN Request Container)
    SMF->>UPF: Step3f: 转发认证消息至DN-AAA
    UPF->>AAA: 透明转发

    Note over UE,AAA: Step3 可多轮循环直到DN-AAA确认成功

    AAA-->>UPF: Step4: 成功 + DN Authorization Data<br/>+ SM PDU DN Response Container<br/>+ 可选UE IP/N6路由信息
    UPF-->>SMF: 透明转发

    Note over SMF: Step5: 继续并完成PDU Session建立
    SMF->>AMF: PDU Session Establishment Accept
    AMF->>UE: 下发最终结果

下面逐步拆解每条消息的关键Information Element。

Step 0 — SMF判定阶段。这是逻辑步骤，不产生独立信令。SMF依据前面列出的三种触发源决定是否启动。这里有一个易被忽视的IE：DN-specific identity。它由UE在请求中携带，是DN-AAA用于定位该用户在自身数据库中凭据记录的主键。其编码格式定义在TS 24.501的SM PDU DN Request Container中。

Step 1 — N4会话建立（条件触发）。仅当SMF需要UPF作为承载管道、且尚无可用N4 session时执行。N4会话在这里被赋予一个额外用途：除了传统的用户面QoS/转发规则下发，它还要承载SMF↔DN-AAA之间的鉴权信令。这一点在排错时很关键——若N4会话建立失败，二次认证将无法进行，但根因往往被误判为"UPF故障"。

Step 2 — SMF发起认证。消息内携带的核心IE：

IE名称 含义 来源规范
DN-specific identity UE在DN中的标识 TS 24.501 / TS 33.501
GPSI（Generic Public Subscription Identifier） UE的外部业务标识，DN-AAA可据此关联业务 订阅数据/UDM
SUPI（可选） 经映射后提供 TS 23.501

Step 3a/3f — DN-AAA与UE之间EAP消息的双向穿梭。这是整个流程最"动态"的部分。规范NOTE明确：Step 3的循环次数取决于所用机制。以EAP-AKA'为例，典型为1轮（1个Challenge-Response），但若使用EAP-TLS（证书）、EAP-PEAP等多轮交互方法，循环可达多次。每轮EAP消息都封装在以下NAS SM消息之一中：

Step 3b/3c/3d/3e — N1 NAS消息的转接。这一段揭示了SMF与UE之间EAP消息的实际承载路径：SMF不直接寻址UE，必须经AMF中转。非漫游/LBO场景用Namf_Communication_N1N2MessageTransfer；Home Routed漫游场景中，H-SMF先经Nsmf_PDUSession_Update请求V-SMF代为转发，V-SMF再调Namf_Communication_N1N2MessageTransfer，且H-SMF需额外携带H-SMF SM Context ID以串起跨PLMN上下文。

Step 4 — DN-AAA确认与授权数据下发。成功后DN-AAA可返回多个高价值IE：

IE名称 作用 后续用途
SM PDU DN Response Container 显式指示认证/授权成功 UE侧状态确认
DN Authorization Data 数据网授权信息 含DN Authorization Profile Index
UE IP地址 / IPv6 Prefix 由DN-AAA分配UE地址 替代SMF本地分配
N6 traffic routing信息 指定UE业务如何路由至DN clause 5.6.7
IP/MAC地址通知请求 DN-AAA要求后续获知UE分配结果 会话建立后回填

其中DN Authorization Profile Index最为关键。SMF拿到它后，会向PCF发起策略获取，由PCF据此下发专属PCC规则（TS 23.503 clause 6.3/6.4）。这意味着二次认证不仅是"准入控制"，还会直接影响该PDU Session的QoS与计费策略——这是它区别于简单AAA的一大设计亮点。

Step 5 — 流程收尾。PDU Session Establishment继续走完标准4.3.2.2流程的剩余步骤（SMF选UPF、N4会话、IP分配、下发Accept）。认证成功后，SMF与DN-AAA之间维持一个session，用于后续可能的授权更新与IP地址/MAC回填通知。

四、EAP消息容器与IE结构剖析

UE与DN-AAA之间的EAP交互，全部被装进NAS SM层的一个容器里。下图展示这条容器的嵌套结构：

flowchart TB
    subgraph NAS["5G NAS (N1) 消息"]
        direction TB
        MSG["PDU Session Authentication Command<br/>或 PDU Session Authentication Complete"]
        MSG --> SMHDR["SM Header<br/>(PDU Session ID, PTI)"]
        MSG --> EAPIE["EAP message IE<br/>(TS 24.501)"]
    end

    subgraph EAP["EAP message 内容 (RFC 3748)"]
        direction TB
        E1["Code: 1=Request / 2=Response<br/>3=Success / 4=Failure"]
        E2["Identifier (1字节匹配ID)"]
        E3["Length (2字节)"]
        E4["Type (仅Request/Response)"]
        E4 --> E5["Type=50 → EAP-AKA'<br/>RFC 9048"]
    end

    subgraph AKA["EAP-AKA' 子类型 (Type=50)"]
        direction TB
        A1["Subtype: 1=AKA'-Challenge<br/>2=AKA'-Authentication-Reject<br/>3=Sync-Failure ..."]
        A2["AT_RAND, AT_AUTN<br/>(来自认证向量)"]
        A3["AT_MAC (消息认证码)"]
        A4["AT_KDF, AT_KDF_INPUT<br/>(密钥衍生参数)"]
    end

    E5 --> AKA

    style EAPIE fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
    style A3 fill:#fff3e0,stroke:#e65100

这个嵌套结构解释了为什么抓包工程师必须逐层解码：先剥NAS SM，再剥EAP，再剥EAP-AKA'，才能看到AT_RAND/AT_AUTN/AT_MAC这些真正的鉴权素材。其中AT_KDF与AT_KDF_INPUT是EAP-AKA'相对EAP-AKA最重要的安全增强——它通过将"接入网身份绑定字符串"喂入KDF，使得衍生密钥与具体的接入技术强绑定，防止密钥在不同接入技术间被跨用（这是经典EAP-AKA的已知缺陷，EAP-AKA'专门修补）。

五、安全机制：密钥独立性与认证向量来源

二次认证的密钥体系与主认证完全独立，这是TS 33.501的核心安全原则。理解这一点要回答两个问题：密钥从哪来？衍生到哪去？

凭据来源（TS 33.501）分两类：

凭据类型 说明 典型用途
Generic USIM credentials for secondary authentication (GUSSI) 复用USIM的K，由UDM/ARPF生成二次认证向量 运营商自有数据网，无需额外发卡
Default UE credentials for secondary authentication 设备默认凭据，独立于USIM UE Onboarding、初始配置（DCS作为DN-AAA）

对GUSSI场景，DN-AAA Server（或其背后的UDM）使用与主认证相同的根密钥K，但通过独立的认证向量生成路径（AV推导过程使用不同的AMF分离位和序列号SQN域），确保二次认证的RAND/AUTN不与主认证的认证向量冲突。EAP-AKA'的最终主密钥MK由CK' || IK'经KDF衍生，其中CK' || IK'从认证向量得到。

密钥去向： EAP成功后产生MSK（Master Session Key），其衍生子密钥不用于5G空口保护（那是K_AMF/K_gNB的职责），而是供DN层使用——例如建立UE到DN的IPsec隧道、或应用层会话密钥。这条"密钥隔离"设计使得即便DN-AAA被攻破，也无法反推5G接入层安全；反之亦然。

下方的状态机刻画了SMF视角下二次认证的生命周期：

stateDiagram-v2
    [*] --> 待决策: 收到PDU建立请求
    待决策 --> 跳过: 订阅/策略不要求二次认证
    待决策 --> 触发认证: 标记需二次认证<br/>识别DN-AAA
    跳过 --> PDU建立完成
    触发认证 --> 凭证交换中: 发出首轮EAP
    凭证交换中 --> 凭证交换中: 多轮EAP Challenge-Response
    凭证交换中 --> 认证成功: DN-AAA Success
    凭证交换中 --> 认证失败: Reject / 超时
    认证失败 --> PDU建立拒绝: 返回Reject cause
    认证成功 --> 应用授权: 解析DN Authorization Data
    应用授权 --> PDU建立完成: 取PCC规则/分配IP
    PDU建立完成 --> [*]
    PDU建立拒绝 --> [*]

六、二次认证与相邻机制对比

为避免概念混淆，下表将二次认证与几个常被并列讨论的机制做精确区分。

维度 5G主认证 (5G-AKA/EAP-AKA') PDU会话二次认证 (DN-AAA) 网络切片特定认证 (NSSAA) 非可信非3GPP接入认证 (N3IWF/EAP-AKA')
规范 TS 33.501 §6.1 TS 23.502 §4.3.2.3 / TS 33.501 §6.3 TS 23.502 §4.3.2.2.2步 TS 23.502 §4.12
触发时机 注册 PDU Session建立 PDU Session建立（绑定切片） 经非3GPP接入注册
鉴权主体 AUSF+UDM/ARPF DN-AAA Server NSSAAF+切片AAA AUSF+N3IWF
独立凭据 USIM K 可复用USIM或独立 独立切片凭据 USIM K
结果影响 全局安全上下文 该PDU Session准入+QoS 切片接入许可 非3GPP链路密钥

这张表能帮助工程师在排查时快速定位"卡在哪一层鉴权"——很多故障被错误归因到主认证，实际是二次认证或NSSAA未通过。

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

如何在抓包中识别这条流程。使用Wireshark/TShark解5G NAS报文时，识别序列如下：

  1. 观察PDU Session Management消息类型：出现PDU Session Authentication Command（消息类型0x39）或PDU Session Authentication Complete（0x3A）即可确认二次认证正在发生；
  2. 在这些消息内查找EAP message IE：展开后看Code与Type。Code=1/2, Type=50即EAP-AKA'；若Type=13则是EAP-TLS；
  3. 若Type=50，进一步看Subtype：1为AKA'-Challenge，携带AT_RAND/AT_AUTN/AT_MAC；
  4. 在N4接口（PFCP）侧，应观察到一条额外的N4 Session Establishment/Modification，其携带TS 29.561定义的DN-AAA信令容器（非典型QoS下发）；
  5. 流程终点：看是否出现EAP Success(Code=3)或EAP Failure(Code=4)。

一条TShark快速过滤示例：

tshark -r capture.pcap -Y "5gs.sm.msg_type==57 || 5gs.sm.msg_type==58 || eap.code"

常见故障点与排查思路：

故障现象 可能根因 排查方向
PDU建立卡在认证阶段无响应 DN-AAA不可达，N4承载管道未建立 查N4 Session Establishment是否成功；查SMF→UPF→DN-AAA路由
UE收到Authentication Reject DN-specific identity在DN-AAA无匹配记录 核对UE携带的SM PDU DN Request Container中的identity
EAP方法不匹配导致超时 UE与DN-AAA协商的EAP Type不一致 抓包比对双方EAP Type支持列表；检查SMF本地策略配置的EAP方法
认证成功但QoS策略异常 DN Authorization Profile Index未正确传到PCF 查SMF→PCF的PCC规则请求是否携带该Index
Home Routed漫游下鉴权中断 H-SMF SM Context ID缺失或V-SMF未正确转发 查Nsmf_PDUSession_Update中Context ID字段
多轮EAP后仍失败 SQN失步（AKA'的AUTN校验失败） DN-AAA/UDM侧重置SQN，或触发Re-synchronization

排错时要先确认现网走的是哪一派——这决定了日志该去哪个网元找。

八、Release 18的演进要点

R18在二次认证方向上的增强主要集中在两点。其一，SBI化进一步深化，使二次认证与5GC原生服务化架构更一致，减少对传统AAA协议栈的依赖，便于云原生部署。其二，与网络切片特定认证（NSSAA）的协同更明确——当一个PDU Session同时关联了需要切片认证的S-NSSAI和需要DN认证的DNN时，两者的执行顺序与上下文传递在R18得到了更清晰的规范，避免鉴权状态机冲突。此外，对物联网终端的轻量化EAP方法支持也有所扩展，以适应CIoT场景的低开销需求。

九、设计意图的几点思考

回顾这条流程，有几处设计值得反复体会。第一，SMF被选为Authenticator而非AMF，因为二次认证是会话级而非注册级语义，与会话生命周期强绑定，由SMF掌舵最自然。第二，EAP消息在NAS中透明承载，意味着5GC对EAP的具体内容"不解释、只搬运"，这赋予DN-AAA选用任意EAP方法的自由度，是协议分层解耦的典范。第三，UPF兼做承载管道这一"复用"而非"新增网元"的取舍，体现了3GPP在功能扩展与架构稳定性之间的平衡——代价是排错链路更长。第四，DN Authorization Profile Index回灌PCF，把"准入控制"与"策略下发"打通，让二次认证的价值从"能不能进"升级为"进来后享受什么待遇"。

常见问题

Q1: 二次认证和主认证可以同时进行吗？ A: 不可以。二次认证在主认证成功、UE已注册并建立安全上下文之后的PDU Session建立阶段才触发，二者严格串行。主认证未完成根本不会产生PDU Session建立请求，也就无从触发二次认证。

Q2: 二次认证失败会怎样？ A: SMF将拒绝该PDU Session的建立，向UE返回PDU Session Establishment Reject，并在cause值中指示失败原因（如#27 Missing or unknown DNN或专门的二次认证失败码）。已分配的部分资源将被回滚释放。

Q3: EAP-AKA'二次认证与主认证用的EAP-AKA'有什么区别？ A: 协议机制相同（都是RFC 9048），但作用域与密钥独立：主认证的EAP-AKA'由AUSF主导，密钥进入5G接入层KDF链；二次认证的EAP-AKA'由DN-AAA主导，密钥仅供DN层使用。两者使用不同的认证向量，即便都源自同一个USIM K，也通过AMF分离位和SQN域隔离。

Q4: DN-AAA Server必须部署在5GC外部吗？ A: 不是。规范明确支持两种部署：外部部署时SMF经UPF透明中继；当DN-AAA位于5GC内部、SMF可直接寻址时，UPF被旁路（Step 1跳过）。R17起的SBI方案进一步支持SMF直接以服务化方式寻址DN-AAA功能。

Q5: 如果UE不携带SM PDU DN Request Container会怎样？ A: 若订阅或策略要求该DNN必须二次认证，而UE未提供DN Request Container（即未声明DN-specific identity），SMF仍可基于本地配置识别DN-AAA Server并启动流程；但若认证过程中UE始终无法提供有效identity，最终将因DN-AAA无法匹配用户而认证失败，导致PDU Session建立被拒。

参考来源

  1. 3GPP TS 23.502 V18.10.0 — Procedures for the 5G System — clause 4.3.2.3 Secondary authorization/authentication by a DN-AAA Server
  2. iTecSpec — TS 23.502 §4.3.2.3 规范全文 — 步骤0-5逐条解析
  3. 3GPP TS 33.501 V18 — Security architecture and procedures for the 5G System — clause 6.3 Secondary authentication / 密钥衍生
  4. 3glteinfo — 5G NR PDU Session Authentication Procedure Explained — 信令流程图与EAP payload解读
  5. 3glteinfo — PDU Session Authentication Command in 5G NAS (TS 24.501) — NAS消息IE细节

本文由「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学通信知识星球海报-扫码加入

📎 本分类最新文章