首页 › security › 5G EAP二次认证全链拆解

5G PDU 会话 EAP 二次认证（DN-AAA 鉴权）全链拆解

在 5G 系统里，一个终端要"上网"必须先通过主认证（Primary Authentication，5G AKA / EAP-AKA'）——这是终端与运营商网络（归属 UDM/ARPF/AUSF）之间的身份确认。但在企业专网、行业切片、第三方数据网络（DN）接入场景下，仅凭运营商域的认证远远不够：数据网络的归属方往往不信任运营商的 SIM 凭证，需要用自己的凭证库再"验一次身"。这就是 3GPP 定义的二次认证（Secondary Authentication）——在 PDU 会话建立期间，由外部 DN-AAA 服务器通过 EAP（可扩展认证协议） 框架对 UE 进行一次额外的、面向具体数据网络的鉴权与授权。

本文依据 TS 33.501（5G 安全架构）条款 11.1、TS 23.502（5G 系统流程）条款 4.3.2.3、TS 23.501 条款 5.6.6 以及 NAS 层 TS 24.501 的 IE 定义，对该机制进行全链拆解。

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

二次认证解决的是一个信任域不重合的问题。下表把两个认证维度区分清楚：

维度	主认证（Primary）	二次认证（Secondary）
标准	TS 33.501 §6	TS 33.501 §11.1
凭证域	运营商 USIM / 5G 凭证	数据网络 DN 凭证（NAI + 密钥/证书）
鉴权方	AUSF + ARPF（UDM）	外部 DN-AAA 服务器
触发时机	注册流程（Registration）	PDU 会话建立（或之后重认证）
协议框架	5G AKA / EAP-AKA'（改进版）	通用 EAP（EAP-AKA'、EAP-TLS 等）
Authenticator	AMF（服务网络）	SMF（会话管理功能）
产生密钥	KAMF → 接入层密钥	EAP MSK/EMSK（面向 DN）
典型场景	接入运营商网络	企业专网、垂直行业、IoT、第三方 DN

设计意图有三点值得强调：

职责解耦：运营商无需知道 DN 凭证，DN-AAA 也无需信任运营商的 SIM。两个信任链完全独立，符合"纵深防御"。
复用 IETF EAP 框架：3GPP 不重新发明轮子。EAP 是成熟的多方法承载框架（RFC 3748），可以承载 EAP-AKA'（复用 USIM，TS 33.501 引用 RFC 9048）或 EAP-TLS（企业证书），可扩展性强。
会话粒度的授权：DN-AAA 不仅认证身份，还在认证成功后下发授权数据（如允许的 QoS、Session-AMBR、UE-IP/MAC、会话时长限制，见 TS 23.501 §5.6.6），由 SMF 据此约束该 PDU 会话。这使认证与策略下发一体化。

二、网络功能角色与 EAP 传递路径

理解二次认证的关键，是搞清楚 EAP 消息在各 NF 之间怎么被搬运。AMF 在这里只是 NAS 透传，真正扮演 EAP Authenticator 角色的是 SMF，而 EAP 消息从 SMF 到 DN-AAA 的最后一段由 UPF 中继。

flowchart TD
    UE["UE<br/>(EAP Peer)"] -->|"N1 NAS SM<br/>(PDU Estb Req + EAP)"| AMF["AMF<br/>(NAS 透传)"]
    AMF -->|"Nsmf_PDUSession_*<br/>(N1 SM 容器)"| SMF["SMF<br/>(EAP Authenticator)"]
    SMF -->|"N4 会话"| UPF["UPF<br/>(EAP 中继/转发)"]
    UPF -->|"EAP/Identity<br/>(RADIUS 或 Diameter)"| DNAAA["DN-AAA 服务器<br/>(EAP Server)"]
    SMF -.->|"获取订阅<br/>(SUCI/SUPI, DNN)"| UDM[("UDM")]
    DNAAA -.->|"授权数据<br/>(QoS/AMBR/IP)"| SMF
    classDef sec fill:#e8f4f8,stroke:#2b6cb0,stroke-width:2px;
    class UE,DNAAA sec;

几点说明：

UE 是 EAP Peer（被认证方），DN-AAA 是 EAP Server（认证方），二者之间的 EAP 消息被层层封装：在 UE↔AMF 段走 N1 NAS SM 信令（封装在 PDU Session Establishment Request/Accept 的 IE 中），在 AMF↔SMF 段走 Nsmf 服务化接口（N1 SM Container 作为 payload），在 SMF↔DN-AAA 段由 UPF 中继并以 RADIUS（RFC 2865/2869）或 Diameter（TS 29.561） 承载（接口定义见 TS 29.561）。
SMF 是唯一的 EAP Authenticator：它负责发起 EAP、缓存认证结果、在重认证/撤销时决策。
HR 漫游场景下要拆出 V-SMF / H-SMF：V-SMF 仅做信令代理（proxy），真正的 EAP 交互在 H-SMF；LBO（本地疏导）漫游则只有一个 VPLMN 内的 SMF。

三、完整信令时序图

下图依据 TS 33.501 §11.1.2 图 11.1.2-1（基于 TS 23.502 §4.2.2.2.2、§4.3.2.2.1、§4.3.2.3），以非漫游（单 SMF）为主线，给出 19 步完整流程：

sequenceDiagram
    autonumber
    participant UE
    participant AMF
    participant SMF as SMF<br/>(Authenticator)
    participant UPF
    participant DNAAA as DN-AAA
    participant UDM

    Note over UE,AMF: 步骤1-3：主认证 + NAS 安全上下文（TS 23.502 §4.2.2.2.2）
    UE->>AMF: 注册 / 5G AKA 主认证（建立 NAS 安全）

    Note over UE,SMF: 步骤4-6：PDU 会话建立请求
    UE->>AMF: PDU Session Establishment Request<br/>(N1 SM容器, DNN, S-NSSAI, PDU Session ID)<br/>[可选: SM PDU DN Request Container IE = NAI]
    AMF->>SMF: Nsmf_PDUSession_CreateSMContext Request<br/>(N1 SM容器, SUPI, DNN, S-NSSAI)
    SMF->>UDM: Nudm_SDM_Get（订阅数据）
    UDM-->>SMF: 订阅数据（是否需二次认证）

    Note over SMF: 步骤7：SMF 判定是否需要二次认证<br/>若该UE已对同DN/AAA认证过可跳过8-15
    SMF->>UPF: 建立/选择 N4 会话（步骤8/11）
    SMF->>DNAAA: 通知 GPSI + UE IP(或MAC)

    Note over UE,DNAAA: 步骤9-13：EAP 交互（核心）
    opt 未在步骤4携带NAI
        SMF-->>UE: EAP Request/Identity（经NAS）
        UE->>SMF: EAP Response/Identity（NAI格式）
    end
    SMF->>UPF: 转发 DN-specific identity（EAP Response/Identity）
    UPF->>DNAAA: EAP Response/Identity（RADIUS/Diameter）
    loop 按 EAP 方法（EAP-AKA' / EAP-TLS）
        DNAAA-->>UE: EAP Request（挑战，经UPF→SMF→NAS）
        UE-->>DNAAA: EAP Response（应答）
    end

    Note over DNAAA: 步骤14：认证成功
    DNAAA-->>SMF: EAP Success + 授权数据(QoS/AMBR等, TS23.501 §5.6.6)
    Note over SMF: 步骤15：SMF 缓存认证结果<br/>（DN-ID + DNN 或 AAA Server ID）

    Note over SMF,UE: 步骤16-19：继续 PDU 会话建立
    SMF->>UPF: N4 Session Modification
    SMF-->>AMF: Namf_Communication_N1N2MessageTransfer<br/>(PDU Estb Accept + EAP Success)
    AMF-->>UE: PDU Session Establishment Accept + EAP Success

逐步 IE 解析

步骤 4 的关键在于 SM PDU DN Request Container IE（TS 24.501）。该 IE 携带数据网络特定的身份，必须符合 NAI（Network Access Identifier）格式（如 [email protected]）。若 UE 在此主动携带 NAI，可省去步骤 9–10 的两次往返——这是协议刻意留给 UE 的优化点。
步骤 7 是决策中枢：SMF 从 UDM 取回订阅数据后判断"该 DNN 是否要求二次认证"。若同一 UE 此前已对相同 DN 或相同 AAA 服务器认证成功（结果可缓存在 SMF 或 UDM），SMF 可直接跳过步骤 8–15，避免重复挑战。这是降低企业专网信令风暴的关键设计。
步骤 8/11：SMF 选择 UPF 并建立 N4 会话；同时把 GPSI（通用公共订阅标识）和 UE 的 IP 地址（IPv4/IPv6，IP 型 PDU）或 MAC 地址（Ethernet 型 PDU） 通知 DN-AAA，便于 DN-AAA 做基于身份+地址的绑定授权。
步骤 13：DN-AAA 可额外下发授权信息，定义于 TS 23.501 §5.6.6，例如允许的 Session-AMBR、5QI、会话存活时间等。
步骤 14–15：EAP Success 是认证成功的标志；SMF 把 DN-specific ID + DNN（或 AAA Server ID）写入缓存清单（本地或 UDM）。
步骤 18–19：EAP Success 最终随 PDU Session Establishment Accept 经 N1 下发给 UE，整个二次认证闭环。

四、关键 IE 结构与封装

EAP 在 NAS 层是被"层层套娃"的。下图展示 SM PDU DN Request Container IE 的内部结构与 EAP 消息的封装路径：

flowchart TD
    A["NAS 消息（受NAS安全保护）"] --> B["N1 SM 容器"]
    B --> C["PDU Session Establishment Request"]
    C --> D["IE: SM PDU DN Request Container<br/>(TS 24.501)"]
    D --> E1["DN-specific Identity（NAI）<br/>username@realm"]
    D --> E2["Port Info（可选）"]
    C -.->|"认证阶段"| F["IE: EAP message<br/>(承载 EAP Request/Response/Success)"]
    F --> G["EAP Code / Identifier / Length"]
    G --> H["EAP Type（13=EAP-AKA', 13'/TLS, …）"]
    H --> I["EAP 方法载荷"]
    style D fill:#fef3c7,stroke:#d97706,stroke-width:2px;
    style F fill:#dbeafe,stroke:#2563eb,stroke-width:2px;

IE 参数说明表

IE / 参数	所在消息	TS 出处	作用
`SM PDU DN Request Container`	PDU Session Establishment Request	TS 24.501	携带 DN-specific 身份（NAI），决定认证对象
DN-specific Identity（NAI）	上述 IE 内	TS 33.501 §11.1.2 step10	`user@realm` 格式，realm 用于 SMF 选 DN-AAA
`EAP message` IE	NAS SM 消息（双向）	TS 24.501	承载 EAP Request/Response/Success/Failure
GPSI	SMF→DN-AAA（步骤8）	TS 23.501 §5.6.6	公网标识，便于 DN 侧关联用户
UE IP / MAC	SMF→DN-AAA（步骤8）	TS 23.501 §5.6.6	地址绑定授权（IP 型带 IP，Ethernet 型带 MAC）
授权数据	DN-AAA→SMF（EAP Success 后）	TS 23.501 §5.6.6	Session-AMBR、QoS 限制、会话时长
`DNN` + `S-NSSAI`	CreateSMContext	TS 23.502 §4.3.2.2.1	触发条件：判断是否对该 DN 做二次认证

五、会话生命周期与状态转换

二次认证不是一次性事件。TS 33.501 §11.1.3（Re-Authentication） 与 §11.1.4（Revocation 撤销） 赋予了它会话全生命周期的动态性：

stateDiagram-v2
    [*] --> PendingAuth: PDU Estb Request（SMF判定需认证）
    PendingAuth --> InProgress: 发起 EAP（步骤8起）
    InProgress --> Authorized: 收到 EAP Success（步骤14）
    InProgress --> Rejected: EAP Failure / 超时
    Rejected --> [*]: SM-NAS 拒绝, PDU会话不建立
    Authorized --> Authorized: 重认证(§11.1.3)<br/>DN-AAA或SMF触发EAP Re-auth
    Authorized --> Released: 撤销(§11.1.4)<br/>DN-AAA→SMF→PDU Release(TS23.502 §4.3.4)
    Authorized --> [*]: 正常 PDU 会话释放

重认证（Re-Authentication）：PDU 会话建立后的任意时刻，DN-AAA 或 SMF 都可发起二次重认证/重授权（流程见 TS 23.502 §4.3.2.3 独立过程）。典型触发：证书即将过期、策略变更、定时刷新。重认证复用既有 N1 SM 信令通道，无需重建会话。
撤销（Revocation）：DN-AAA 若判定用户越权（如检测到异常流量、凭证吊销），可主动通知 SMF 撤销授权；SMF 随即发起 PDU Session Release（TS 23.502 §4.3.4），强制下线。这是企业专网"实时踢人"的安全抓手。

六、密钥派生与安全边界

二次认证的密钥体系与主认证完全隔离：

主认证产生的 KAMF 派生出接入层密钥 KgNB，用于空口（Uu）用户面/控制面加密与完整性——与 DN 密钥无关。
二次认证的 EAP 方法（如 EAP-AKA' per RFC 9048）在 UE 与 DN-AAA 之间协商出 MSK（主会话密钥）与 EMSK（扩展主会话密钥）。其中 MSK 下发给 SMF（作为 Authenticator），EMSK 留存于 DN-AAA。
这套密钥按运营商策略可选地用于 UE 与 DN 之间的额外保护；但基线 5GC 的用户面保护仍由接入层密钥承担，二次认证密钥不进入 5GC 接入面密钥树（TS 33.501 Annex B.3 给出二次认证场景下的密钥推导示例）。

这种"两套密钥、互不污染"的设计，使得即使 DN-AAA 被攻破，也无法反推出运营商主认证密钥；反之亦然。

七、抓包识别与实战排错

抓包如何识别该流程

在 Wireshark 中（结合 pcap-analyzer 思路），二次认证的识别特征：

N1 NAS 层：NAS-5GS > PDU session establishment request 中出现 SM PDU DN request container IE 或随后出现 EAP message IE（而非直接进入会话接受）。
N4 层：SMF 与 UPF 之间出现 PFCP > Session Establishment Request，且伴随 EAP 转发相关字段。
DN 侧：UPF 与 DN-AAA 之间出现 RADIUS（Access-Request / Access-Challenge / Access-Accept） 或 Diameter（DER/DEA） 报文，载荷内可见 EAP-AKA'/EAP-TLS。
关键判据：若 PDU session establishment accept 之前出现了多条 N1 EAP 交互，即可确认触发了二次认证。

常见故障点

NAI realm 配置错误：UE 携带的 @realm 与 SMF 本地 DN-AAA 路由表不匹配 → 找不到 AAA 服务器，认证超时。
DN-AAA 不可达：UPF 到 DN-AAA 的 RADIUS/Diameter 链路不通 → 步骤 13 卡死，最终 EAP 超时，PDU 会话被拒。
证书/凭证不匹配（EAP-TLS）：UE 客户端证书未被企业 CA 信任 → EAP Failure。
授权数据冲突：DN-AAA 下发的 Session-AMBR 与订阅数据矛盾 → SMF 可能拒绝或取较严格值。
漫游拆分不当：HR 漫游时 V-SMF 未正确代理 EAP 信令到 H-SMF → 认证请求丢失。

排错思路：自顶向下分层定位——先看 N1 是否带 SM PDU DN Request Container 确认触发，再看 N4 是否建立，最后查 RADIUS/Diameter 是否往返闭合。

八、对比分析

表 1：主认证 vs 二次认证（已在第一节给出）

表 2：常用 EAP 方法在 5G 二次认证中的对比

EAP 方法	标准	凭证来源	适用场景	优劣
EAP-AKA'	RFC 9048 / TS 33.501	USIM（复用主认证凭证）	与运营商关系紧密的 DN、SNPN	复用 USIM，免额外证书；但要求 DN-AAA 可触达鉴权向量
EAP-TLS	RFC 5216	客户端/服务器证书	企业专网、强安全垂直行业	双向证书认证，安全性高；需 PKI 部署与证书生命周期管理
EAP-TTLS / PEAP	RFC 5281 / 草案	用户名口令（隧道内）	过渡期、轻量接入	部署简单；安全性弱于 TLS
运营商自定义	—	自定义	特定垂直	灵活；互操作性差

常见问题

Q1：二次认证是强制流程吗？ A：不是。是否触发由 SMF 根据订阅数据（UDM）与本地策略判断——只有访问特定 DNN（如企业专网）且订阅要求时才执行。普通公网 DNN 通常不触发。

Q2：UE 必须在步骤 4 携带 NAI 吗？ A：可选。携带可省去步骤 9–10 两次往返（优化）；不携带则由 SMF 主动发 EAP Request/Identity 索取。

Q3：二次认证失败会怎样？ A：SMF 通过 SM-NAS 信令拒绝该 PDU 会话建立请求（EAP Failure），会话不建立；已建立的会话若被撤销则触发 PDU Session Release。

Q4：SMF 与 DN-AAA 之间用什么协议？ A：经 UPF 中继，承载于 RADIUS（RFC 2865/2869）或 Diameter，接口定义见 TS 29.561（5G 与 DN 互通，Stage 3）。

Q5：二次认证产生的密钥会保护空口用户面吗？ A：不会。空口保护仍由主认证派生的 KgNB 承担；二次认证的 MSK/EMSK 面向 DN，两套密钥体系相互隔离。

参考来源

3GPP TS 33.501 V18.10.0 — Security architecture and procedures for 5G System — 条款 11.1 / 11.1.2（EAP 二次认证流程）、Annex B.3（密钥推导）
3GPP TS 23.502 V18.10.0 — Procedures for the 5G System — 条款 4.3.2.3（DN-AAA 二次授权/认证）、4.3.2.2.1（PDU 会话建立）
TS 33.501 §11.1.2 Authentication — iTecSpec 条文索引 — 完整 19 步流程核对
TS 23.502 §4.3.2.3 Secondary authorization/authentication — iTecSpec — DN-AAA 重认证与撤销流程
5G NR PDU Session Authentication Procedure — 3GLTEInfo — 信令流程与故障排查参考

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