# 5G二次认证EAP信令机制拆解：UE与外部数据网络的鉴权授权全链 ## 一、为什么5G需要"二次认证" 5G系统（5GS）的"一次认证"（Primary Authentication）由 AMF/SEAF、AUSF、UDM 协同完成，解决的是 **"UE 是否为合法的 5G 用户"** 这一问题，产物是接入层密钥 `Kamf→Krrc/Kup`。但很多场景下，仅证明"你是运营商的合法用户"远远不够： - **企业园区专网**（SNPN/公网集成）需要确认该 UE 是否是该企业网络的成员； - **行业切片**（如电网、医疗）需要对接企业自己的 AAA 系统，做账号密码或证书校验； - **应用层服务**（如运营商自营业务平台）希望复用 5G 接入通道，但对用户做独立授权。 于是 3GPP 在 TS 33.501 §11 引入了 **二次认证与授权（Secondary Authentication / Authorization）**：在 PDU 会话建立过程中，由 **SMF 充当 EAP 鉴权器（Authenticator）**，在 UE 与位于数据网络（DN）侧的 **DN-AAA 服务器** 之间中继一次完整的 EAP 交换。它与一次认证 **完全独立、互不复用凭证**（除非显式选用 EAP-AKA'），是叠加在 5GC 之上的"数据网络准入"机制。 需要特别强调：本文聚焦的是 **TS 33.501 §11 / TS 23.502 §4.3.2** 定义的 PDU 会话级 DN-AAA 二次认证，而非一次认证中的 EAP-AKA'（那是 TS 33.501 §8 的范畴，已在上一轮 AKA 主题中覆盖）。 ## 二、架构与参考点 ### 2.1 功能实体与参考点 二次认证涉及的核心实体如下表： | 实体 | 角色 | 相关规范 | |------|------|---------| | UE | EAP Peer（被认证方），持 DN 凭证 | TS 33.501 §11.1 | | AMF | EAP 消息的 NAS 透传通道（不解析 EAP） | TS 23.502 §4.3.2.2 | | SMF | **EAP Authenticator + AAA Client**，决策与中继 | TS 23.501 §6.3.2.3 | | UDM | 提供订阅数据，含"是否需二次认证"指示 | TS 29.503 | | DN-AAA | EAP Server，存储 DN 凭证，下发授权 | TS 29.561 | | UPF | 用户面锚点，可选承载 AAA 信令到 DN | TS 23.501 §6.3.3 | SMF 与 DN-AAA 之间的接口**不是**一个标准化的 Nx 命名参考点，而是 **RADIUS 或 Diameter** 形式（TS 29.561《5GC 与外部数据网络的互通》定义）。常见实现里，SMF 内置 RADIUS/Diameter 客户端，经 N6（UPF）或直连 IP 通道访问 DN-AAA；当 AAA 服务器位于 5GC 侧的数据通信服务（DCS）中时，TS 29.561 §21.2 单独规范了 "AAA server in DCS" 的选择与交互。 ### 2.2 设计意图 把 DN-AAA 准入设计成 **PDU 会话级、EAP 承载、SMF 代理** 有三个考量： 1. **解耦**：5G 运营商无需感知企业凭证体系，只做信令搬运，企业 AAA 自治； 2. **协议复用**：EAP 是成熟的可扩展框架（IETF RFC 3748），天然支持 TLS/TTLS/AKA' 等多种方法； 3. **会话粒度**：按 (DNN, S-NSSAI) 触发，不同数据网络可有不同认证强度，且支持会话建立后的 **重认证（Re-authentication）**。 ## 三、触发条件与 SMF 决策 SMF 在 PDU 会话建立过程中执行如下判定逻辑（TS 23.501 §5.6.4、§6.3.2.3）： ```mermaid flowchart TD A[UE发起PDU会话建立请求] --> B[SMF调用Nudm_SDM_Get
拉取该DNN/S-NSSAI订阅数据] B --> C{订阅或本地策略
是否要求二次认证?} C -->|否| D[跳过,直接进入N4会话建立] C -->|是| E[选择DN-AAA服务器] E --> F{是否为仅授权
Secondary Authorization Only?} F -->|是| G[SMF仅向DN-AAA查授权
不发起EAP挑战] F -->|否| H[启动完整EAP交换
SMF作Authenticator] ``` 订阅数据中由 UDM 下发的关键字段（TS 29.503 `DnnConfiguration`）： - **`SecondaryAuthentication`**：布尔指示，是否对该 DNN 强制二次认证； - **`DN-AAAServerAddress`**：目标 DN-AAA 的 FQDN 或 IP（若订阅未提供，SMF 用本地策略或 DNS 解析选择）； - **`AuthorizationData`**：可选的预置授权信息。 > 关键点：**一次认证失败会拒绝注册；二次认证失败会拒绝该 PDU 会话建立**。两者失败域不同，UE 仍可注册 5GC、访问其它不需要二次认证的 DNN。 ## 四、完整信令时序图（TS 23.502 §4.3.2.2） 以下为标准 Figure 4.3.2.2-1 的工程化解读，假设 UE 事先不知道需二次认证、由 SMF 发起 EAP： ```mermaid sequenceDiagram autonumber participant UE participant AMF participant SMF participant UDM participant DN as DN-AAA participant UPF UE->>AMF: PDU Session Establishment Request
(DNN, S-NSSAI, PDU Session ID) AMF->>SMF: Nsmf_PDUSession_CreateSMContext
(含N1 SM容器) SMF->>UDM: Nudm_SDM_Get(订阅数据) UDM-->>SMF: SecondaryAuthentication=需 + DN-AAA地址 SMF->>DN: RADIUS Access-Request
(EAP-Response/Identity) DN-->>SMF: Access-Challenge
(EAP-Request, Type=50 AKA'挑战) SMF->>AMF: Namf_Communication_N1N2MessageTransfer
(5GSM: EAP message) AMF->>UE: DL NAS transport
(EAP message IE) UE->>AMF: UL NAS transport
(EAP-Response: RES/MAC) AMF->>SMF: Nsmf_PDUSession_UpdateSMContext
(透传EAP) SMF->>DN: Access-Request(EAP-Response) DN-->>SMF: Access-Accept
(EAP-Success + 授权数据 + MSK) SMF->>UPF: N4 Session Establishment
(PDR/FAR/QER) SMF->>AMF: Namf_N1N2MessageTransfer
(EAP-Success) AMF->>UE: PDU Session Establishment Accept
(分配IP, Session-AMBR) ``` 若 EAP 协商需要多轮（如 EAP-TLS 的证书链验证），步骤 5–10 会重复若干次，直到 DN-AAA 给出最终裁决。 ## 五、关键 Information Element 逐条解析 ### 5.1 EAP message IE 的内部结构 EAP 消息在 5GC 内部并不单独成帧，而是作为 **NAS SM 信令透传**：SMF→UE 方向，SMF 调用 `Namf_Communication_N1N2MessageTransfer`，AMF 据此构造 **DL NAS transport**（Payload Container Type 指示为 5GSM）；UE→SMF 方向，UE 发 **UL NAS transport**，SMF 经 `Nsmf_PDUSession_UpdateSMContext` 收回。EAP 本身被封装在 5GSM 容器的 **EAP message IE** 中（TS 24.501 §9.11.2.2）。 ```mermaid flowchart TB N[UL/DL NAS Transport] --> P1[Payload Container Type = 1
'5GS session management message'] N --> P2[PDU Session ID] N --> P3[Old PDU Session ID / Request Type] P1 --> Q[5GSM Message] Q --> E["EAP message IE (9.11.2.2)"] E --> C1[Code: 1=Req / 2=Resp / 3=Success / 4=Failure] E --> C2[Identifier] E --> C3[Length] E --> C4[Type: 1=Identity / 50=AKA' / 13=TLS / 21=TTLS] C4 --> M[Method Data
RAND/AUTN/RES*/MAC 或 TLS记录] ``` ### 5.2 IE 参数说明表 | IE / 属性 | 所在消息 | 含义 | 抓包要点 | |----------|---------|------|---------| | `EAP message` | NAS transport(双向) | 承载 EAP 帧 | Code/Type 决定认证方法 | | `PDU Session ID` | 全流程 | 唯一标识该会话 | 与 N4/N11 会话一一对应 | | `DNN` / `S-NSSAI` | Establishment Request | 决定是否触发二次认证 | 关键决策输入 | | RADIUS `EAP-Message`(79) | SMF↔DN-AAA | 分片承载 EAP | RFC 3579 | | RADIUS `Message-Authenticator`(80) | SMF↔DN-AAA | 防篡改 | 共享密钥 HMAC-MD5 | | `MS-MPPE-Send/Recv-Key` | Access-Accept | 透传 MSK 到 SMF | 16 字节密钥材料 | | `Class` / `Framed-IP-Address` | Access-Accept | DN-AAA 下发授权（IP、计费类） | 影响 UPF/QoS | | `Session-AMBR` | Establishment Accept | SMF 据 DN-AAA 授权下发 | 限速依据 | ### 5.3 SMF→DN-AAA 的 AAA 属性映射 DN-AAA 给出的 `Access-Accept` 中携带的授权数据会被 SMF 转译为 5GC 内部参数：`Framed-IP-Address`→分配给 UE 的会话 IP；`Session-Timeout`→触发重认证定时器；自定义 VSA→QoS 参数传给 PCF。这就是"认证"之外的"授权"价值。 ## 六、EAP 方法协商与密钥派生 ### 6.1 支持的 EAP 方法对比 | EAP 方法 | 凭证类型 | 标准 | 典型场景 | 密钥产物 | |---------|---------|------|---------|---------| | **EAP-AKA'** | USIM 凭证（与 DN-AAA 共享） | RFC 9048 | 运营商标配 DN、复用 SIM | MSK/EMSK | | **EAP-TLS** | X.509 双向证书 | RFC 5216 | 企业网、高安全专网 | MSK/EMSK | | **EAP-TTLS** | 服务端证书+用户名密码 | RFC 5281 | BYOD、轻量接入 | MSK/EMSK | | **PEAP** | 服务端证书+MS-CHAPv2 | RFC 6962 等 | 企业 WLAN 风格 | MSK/EMSK | 方法选择由 **UE 与 DN-AAA 协商**：DN-AAA 在首条 `EAP-Request/Identity` 后，依据自身策略下发某方法的 `EAP-Request`，UE 若支持则进入该方法的状态机。 ### 6.2 密钥层级：与一次认证的关键区别 这是最容易混淆的地方——二次认证的密钥与 5G 接入层密钥 **相互独立**： ```mermaid flowchart LR subgraph S1["一次认证密钥层级 (TS 33.501 §8/§9)"] K1["K (USIM永久密钥)"] --> SEAF["Kseaf"] SEAF --> AMF["Kamf"] AMF --> AS["Krrc-enc/Krrc-int/Kup-int"] end subgraph S2["二次认证EAP密钥 (TS 33.501 §11)"] CRED["DN凭证 / 证书"] --> EAP["EAP方法状态机"] EAP --> MSK["MSK (UE & SMF共享)"] EAP --> EMSK["EMSK (保留)"] MSK -.可选.-> DNSEC["用户面应用层保护"] end ``` **设计要点**：EAP 成功后产出的 `MSK` 由 DN-AAA 经 `Access-Accept` 透传给 SMF，UE 本地也由 EAP 状态机生成相同的 MSK。**该 MSK 不参与 RAN 接入层加密**——RAN 的 `Kup/Krrc` 始终来自一次认证的 `Kamf`。MSK 在标准中主要作为该 PDU 会话对应数据网络的会话凭证（可选用于应用层/用户面到该 DN 的保护），其存在证明了"UE 与 DN-AAA 完成了一次独立可信交换"。 ## 七、失败处理与重认证 ### 7.1 失败处理 DN-AAA 下发 `EAP-Failure`（Access-Reject）后，SMF 会向 UE 回 **PDU Session Establishment Reject**，其中携带： - **5GSM cause**（TS 24.501 §9.11.4.2）：指示二次认证/授权失败； - **EAP message IE**：封装 `EAP-Failure`，让 UE 协议栈知道 EAP 已终止。 此时 PDU 会话不建立，但 UE 与 5GC 的注册关系不受影响。 ### 7.2 重认证（Re-authentication） TS 23.502 §4.3.2 还定义了已建立会话的二次重认证： - **DN-AAA 发起**：DN-AAA 认为需要重新校验（如 `Session-Timeout` 到期、安全策略变更），可经 SMF 向 UE 发起新一轮 EAP； - **SMF 发起**：依据订阅或本地策略周期性触发； - 信令复用同一套 NAS transport + EAP message 机制，UPF 用户面连接保持不中断，仅 EAP 层重协商。 重认证失败同样会导致 SMF 主动释放该 PDU 会话（`PDU Session Release`）。 ### 7.3 仅授权（Authorization Only） 若订阅标记为 `Secondary Authorization Only`，则 **不发起 EAP 挑战**，SMF 仅向 DN-AAA 查询授权数据（如 IP 池、QoS），用于加速无凭证场景下的会话授权。 ## 八、抓包识别与排错 ### 8.1 抓包特征 在 NGAP/NAS 抓包中识别二次认证： 1. 一条 `PDU Session Establishment Request` 之后，**连续出现多条 DL/UL NAS transport，其 Payload Container Type=1 且 5GSM 容器内为 EAP message**； 2. EAP `Code` 在 1/2 之间反复（Request/Response），最终出现 `Code=3`（Success）或 `Code=4`（Failure）； 3. `Type=50` 表示 EAP-AKA'，`Type=13` 表示 EAP-TLS； 4. **RAN 层面无任何新增安全模式命令**——纯 NAS SM 层动作。 ### 8.2 常见故障点与排错 | 现象 | 根因 | 排错思路 | |------|------|---------| | PDU 会话立即 Reject，5GSM cause 指示认证失败 | UDM 订阅误开启二次认证，但 DN-AAA 无此用户 | 核对 UDM `DnnConfiguration` 与 DN-AAA 用户库 | | EAP 多轮后失败 | 方法不匹配 / 证书过期 / 凭证错误 | 抓 AAA 侧日志，核对 EAP `Type` 与证书链 | | SMF 日志报 DN-AAA 不可达 | 防火墙、路由、RADIUS 共享密钥错误 | 验证 SMF↔DN-AAA 的 UDP/1812 或 TCP/3868 连通 | | EAP-TLS 握手中断 | UE modem 不支持该方法 / 根证书未预置 | 查 UE 能力、导入企业根证书 | | 偶发重认证失败掉线 | `Session-Timeout` 过短 | 调整 DN-AAA 下发值或 SMF 重试策略 | ## 九、常见问题 **Q1：二次认证和一次认证都用 EAP-AKA'，到底有什么区别？** A：一次认证的 EAP-AKA'（TS 33.501 §8）由 AUSF/UDM 完成，凭证是 5GC 主密钥 K，产物是 `Kamf` 接入密钥；二次认证的 EAP-AKA'（TS 33.501 §11）由 SMF↔DN-AAA 完成，凭证是 DN-AAA 中独立登记的记录，产物是 MSK 且**不**用于 RAN 加密。两者实体、触发时机、密钥用途全不同。 **Q2：如果 UE 不支持 SMF 要求的 EAP 方法怎么办？** A：UE 会在 EAP 协商阶段返回 `EAP-Response/Nak`，列出自己支持的方法；若双方无交集，DN-AAA 下发 `EAP-Failure`，SMF 拒绝该 PDU 会话建立。工程上需在终端 modem 入网测试时预置企业所需的 EAP 方法与证书。 **Q3：二次认证会影响用户面时延吗？** A：仅在会话建立阶段增加 EAP 交换的往返时延（EAP-TLS 可能数百毫秒级）。会话建立完成后，UPF 数据面与一次认证完全一致，无额外逐包开销。 **Q4：DN-AAA 必须部署在 DN 侧吗？** A：不一定。TS 29.561 §21.2 定义了 "AAA server in DCS"——AAA 服务器可位于 5GC 侧的数据通信服务域内，SMF 据订阅或本地策略选择它。两种部署下 SMF 与 AAA 的 RADIUS/Diameter 交互机制相同。 **Q5：二次认证的 MSK 能否用于加密用户面到该 DN 的数据？** A：MSK 由 UE 与 SMF 共享，标准将其作为该数据网络会话的可信凭证；它不参与 3GPP 定义的 RAN 接入层加密。若需端到端到 DN 的保护，通常在应用层（如基于 MSK 派生的会话密钥）或上层 VPN 实现，而非依赖 5G RAN 密钥。 ## 参考来源 1. [3GPP TS 33.501 V18.10.0 — Security architecture and procedures for the 5G System](https://www.etsi.org/deliver/etsi_ts/133500_133599/133501/18.10.00_60/ts_133501v181000p.pdf) — §11 Security procedures between UE and external data networks via the 5G Network（二次认证定义与密钥） 2. [3GPP TS 23.502 — Procedures for the 5G System](https://www.3gpp.org/dynareport/23502.htm) — §4.3.2 Secondary authentication/authorization procedures（完整信令流程图） 3. [3GPP TS 29.561 — 5GC to external DN interworking](https://itecspec.com/3gpp/29.561/s/21.2) — §21.2 Secondary authentication using AAA server in DCS 4. [RFC 9048 — EAP-AKA' (EAP Authentication and Key Agreement)](https://datatracker.ietf.org/doc/html/rfc9048) — EAP-AKA' 方法与密钥派生 5. [Cisco UCC 5G SMF Configuration Guide 2025.01 — RADIUS Authentication](https://www.cisco.com/c/en/us/td/docs/wireless/ucc/smf/2025-01/config-and-admin/b_ucc-5g-smf-config-and-admin-guide_2025-01/m_radius-authentication-and-accounting.html) — 厂商 SMF↔DN-AAA RADIUS 实现细节 6. [MDPI — Secure Secondary Authentication Framework for Efficient Mutual Authentication on a 5G Data Network](https://www.mdpi.com/2076-3417/10/2/727) — 二次认证框架的互认证与安全分析 --- > 本文由「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 等场景全覆盖。