在 5G 系统中，UE 通过主认证（Primary Authentication，5G AKA 或 EAP-AKA'）获得对整个 5G 核心网（5GC）的接入授权。但网络切片（Network Slice）打破了"一次认证、全网通行"的假设：一个为海量物联网传感器服务的切片、一个为工业 URLLC 自动化服务的切片、一个为医院远程手术服务的切片，其安全等级、信任域和身份管理体系可能完全不同。仅凭 UDM 中"该用户是否订阅了某个 S-NSSAI"这种二元订阅检查，无法满足企业租户（tenant）希望用自己的凭证、自己的 AAA 服务器来独立决定谁能进入"自己切片"的商业与安全诉求。
为此，3GPP 在 Rel-16 引入了网络切片特定认证与授权（Network Slice-Specific Authentication and Authorization，NSSAA）机制，定义于 TS 23.501、TS 23.502 Section 4.2.9.x、TS 33.501 Clause 16、TS 24.501（NAS 承载）以及服务化接口规范 TS 29.509（Nnssaaf）与 TS 29.526（NSSAAF–AAA 接口）。它是在主认证之上、针对单个 S-NSSAI 额外执行的、基于 EAP 的认证授权流程，由新增的网络功能 NSSAAF 编排。本文聚焦 TS 23.502 Section 4.2.9.2 的完整信令链路，逐消息拆解 IE，并解析其安全设计意图。
NSSAA 涉及的功能实体与参考点如下：
graph TD
UE["UE<br/>(EAP Peer)"]
AMF["AMF"]
UDM["UDM<br/>订阅: 需NSSAA的S-NSSAI"]
NSSAAF["NSSAAF<br/>(EAP Authenticator / AAA Client)"]
AUSF["AUSF<br/>(Rel-17 辅助EAP-AKA')"]
AAAP["AAA Proxy"]
AAAS[("AAA-S<br/>租户/切片凭证库")]
UE -- "N1 NAS<br/>UL/DL NAS TRANSPORT" --> AMF
AMF -- "Nnssaaf (SBI)<br/>TS 29.509" --> NSSAAF
NSSAAF -. "Rel-17 参考" .-> AUSF
UDM -. "Nudm_SDM<br/>订阅数据/订阅通知" .-> AMF
NSSAAF -- "TS 29.526" --> AAAP
AAAP --> AAAS
各角色的职责边界值得强调：
设计要点：NSSAAF 把"运营商域（5GC SBI）"与"租户域（AAA/EAP）"这两个信任域隔离开，AMF 永远不直接接触租户的 AAA 协议——这正是网络切片隔离在控制面的落点。
下图对应 TS 23.502 Figure 4.2.9.2-1，展示一次完整的切片认证授权流程。前置条件是：UE 的初始注册已完成主认证，NAS 安全上下文（完整性保护 + 加密）已建立——这一点对理解后续 EAP 交换的安全性至关重要。
sequenceDiagram
autonumber
participant UE
participant AMF
participant UDM
participant NSSAAF
participant AAAP as AAA-P
participant AAAS as AAA-S
Note over UE,UDM: 主认证已完成; NAS安全已激活
UDM->>AMF: Nudm_SDM: S-NSSAI 需 NSSAA 标记
AMF->>AMF: 该 S-NSSAI 置入 Pending NSSAI
AMF->>NSSAAF: Nnssaaf_NSSAA_Authentication Request<br/>(SUPI, S-NSSAI, EAP-ID req)
NSSAAF->>AAAP: 选择 AAA, 发起 EAP 会话
AAAP->>AAAS: EAP-Request/Identity
NSSAAF-->>AMF: Nnssaaf_NSSAA_Auth Response<br/>(EAP-Request/Identity)
AMF->>UE: DL NAS TRANSPORT<br/>(Payload=EAP, S-NSSAI)
UE->>AMF: UL NAS TRANSPORT<br/>(EAP-Response/Identity)
AMF->>NSSAAF: Nnssaaf_NSSAA_Authentication Request (EAP msg)
Note over UE,AAAS: 多轮 EAP 方法交换<br/>(EAP-AKA' / EAP-TLS / 其它)
AAAS->>AAAP: EAP-Success + 授权结果
AAAP->>NSSAAF: 授权结果 (Allowed/Pending/Reject)
NSSAAF->>UDM: 记录授权状态(可选)
NSSAAF-->>AMF: Auth Response (成功, S-NSSAI 已授权)
AMF->>AMF: Pending NSSAI → Allowed NSSAI
AMF->>UE: DL NAS TRANSPORT (EAP-Success)
AMF->>UE: Configuration Update / Reg Accept (Allowed NSSAI)
① UDM 订阅数据下发：UDM 通过 Nudm_SDM_Get（及 Nudm_SDM_Subscribe）向 AMF 提供订阅的 S-NSSAI 列表，其中对需要 NSSAA 的 S-NSSAI 携带"切片特定认证授权"指示。这是整个流程的触发条件——AMF 并非对任何切片都做 NSSAA，而是严格按 UDM 指示。
② AMF 本地处理：AMF 将该 S-NSSAI 置入 Pending NSSAI（待认证切片列表），它此时既不在 Allowed NSSAI、也不在 Rejected NSSAI 中。注意：Pending 期间，该切片对应的 PDU 会话不能建立。
③ AMF → NSSAAF：Nnssaaf_NSSAA_Authentication Request（TS 29.509）。该服务操作的请求体关键 IE：
| IE | 含义 |
|---|---|
SUPI |
用户永久标识，供 NSSAAF 关联订阅与认证状态 |
S-NSSAI |
本次要认证的切片，决定 AAA 路由与方法选择 |
EAP-ID / AAA routing info |
请求生成首条 EAP-Request/Identity 的指示 |
EAP message |
后续轮次中携带 UE 返回的 EAP-Response |
④ NSSAAF 选择 AAA 并发起 EAP 会话：NSSAAF 基于 S-NSSAI 选定 AAA 代理与 AAA-S，以 AAA 客户端身份发起首条 EAP-Request/Identity（EAP Code=1, Type=1）。
⑤–⑥ NSSAAF → AMF → UE：NSSAAF 通过 Nnssaaf_NSSAA_Authentication Response 把 EAP 报文回送给 AMF；AMF 用 DL NAS TRANSPORT 消息（TS 24.501）下行携带，其中：
- Payload container type IE = "EAP message"
- Payload container IE = 完整 EAP 报文
- S-NSSAI IE = 关联到对应切片（关键：当多个切片并行做 NSSAA 时，S-NSSAI 是解复用的依据）
⑦–⑧ UE → AMF → NSSAAF：UE 用 UL NAS TRANSPORT 携带 EAP-Response/Identity 上行；AMF 经 Nnssaaf_NSSAA_Authentication Request 转发给 NSSAAF。
⑨ 多轮 EAP 方法交换：根据所选 EAP 方法（EAP-AKA'、EAP-TLS 或 Rel-16 扩展的其它方法），UE 与 AAA-S 之间进行多轮请求/响应。EAP-AKA' 会通过 NSSAAF↔AUSF（Rel-17 参考点）获取认证向量并复用 5G 凭证；EAP-TLS 则由 AAA-S 校验 UE 证书。每一轮都遵循"UE↔AMF（NAS）↔NSSAAF↔AAA"的透传路径。
⑩ AAA-S 决策与结果：认证完成后 AAA-S 返回 EAP-Success/EAP-Failure，并附带授权结果（Allowed / 仍 Pending / Reject，可含切片使用参数）。
⑪–⑭ 结果落地与 UE 通知：NSSAAF 记录授权状态（可写 UDM），通过 Auth Response 通知 AMF；AMF 将 S-NSSAI 从 Pending 迁移到 Allowed NSSAI（成功）或 Rejected NSSAI（失败），最后通过 DL NAS TRANSPORT（EAP-Success/Failure） 与 Configuration Update Command / Registration Accept（携带更新后的 Allowed NSSAI）通知 UE。至此 UE 方可建立该切片的 PDU 会话。
NSSAA 没有发明新的认证协议，而是复用 IETF EAP（RFC 3748），通过 NAS 透传。EAP 报文结构如下：
graph LR
A["Code (1B)<br/>1=Req 2=Resp<br/>3=Success 4=Failure"]
B["Identifier (1B)<br/>请求/响应配对"]
C["Length (2B)<br/>含Code+Id+Length+Data"]
D["Data<br/>Type(1B)+Type-Data"]
A --- B --- C --- D
| EAP Type | 值 | 在 NSSAA 中的用途 |
|---|---|---|
| Identity | 1 | 协商 UE 身份 |
| EAP-TLS | 13 | 证书型切片认证 |
| EAP-AKA' | 50 | 复用 5G 凭证的切片认证（常用） |
NAS 层的关键设计是：AMF 不解析 EAP 报文内容，仅做容器透传，并用 S-NSSAI 做多切片并发解复用。EAP 报文在 N1 上始终处于 NAS 安全（完整性 + 加密）保护之下——这是后续安全分析的基础。
一个需要 NSSAA 的 S-NSSAI，其生命周期由状态机管理。下图综合 TS 23.502 Section 4.2.9.2（认证）、4.2.9.3（AAA-S 触发重认证 Re-authentication）、4.2.9.4（AAA-S 触发撤销 Revocation）三条流程：
stateDiagram-v2
[*] --> PendingNSSAI: 请求的 S-NSSAI 需 NSSAA
PendingNSSAI --> Allowed: EAP 成功(4.2.9.2)
PendingNSSAI --> Rejected: EAP 失败/超时(4.2.9.2)
Allowed --> ReAuth: AAA-S 触发重认证(4.2.9.3)
ReAuth --> Allowed: 重认证成功
ReAuth --> Rejected: 重认证失败
Allowed --> Rejected: AAA-S 撤销授权(4.2.9.4)
Allowed --> Allowed: UE 重注册/AMF 查询 AA_Status
Rejected --> [*]
Nnssaaf_NSSAA_AA_Status_Get（TS 29.509）查询切片是否仍处于已认证状态，避免重复走完整 EAP。1. 为什么是"叠加"而非"替代"主认证？ NSSAA 必须在主认证之后执行，因为它依赖已建立的 NAS 安全上下文来承载 EAP 交换。主认证解决"你是合法 5G 用户"，NSSAA 解决"这个合法用户是否被这个特定切片的租户授权"——二者是正交的两层授权。这种分层防御（layered defense）确保了即便低安全切片被攻破，也不会成为横向进入高安全切片的跳板。
2. EAP 交换为何可信？ 关键在于 EAP 报文在 N1 上全程受 NAS 完整性与加密保护。外部攻击者无法在空口注入伪造的 EAP-Response，也无法窃听 EAP-AKA' 的挑战-响应。这把 EAP 本身"无原生保护"的弱点用 NAS 安全兜了底。
3. 域分离（Domain Separation）。 最终授权决策权在租户的 AAA-S，而非运营商。运营商无需管理企业自有身份，企业也无需把凭证交给运营商。NSSAAF 作为信任域网关，把两个域的协议（5GC SBI vs. AAA/EAP）隔离。
4. NSSAA 产出的是"授权"而非"新的用户面密钥"。 这是一个常被误解的要点：Rel-16/17 的 NSSAA 产生的是一个授权判定，并不为该切片的用户面派生独立的保密/完整性密钥；切片内 PDU 会话的用户面保护仍沿用正常 5G 密钥。它解决的是"准入（authorization）"而非"用户面加密"。（Rel-17 的"切片上 AKMA"是另一条独立的应用层密钥派生路径，不混淆。）
5. 切片级并行与隔离。 多个切片的 NSSAA 可并行执行、彼此独立，一个切片认证失败不影响其它已授权切片——这是通过 Pending/Allowed/Rejected 三态列表与 S-NSSAI 解复用实现的。Rel-15 还在主认证中加入 ABBA 参数以支持切片相关的安全上下文特性协商。
| 维度 | 主认证 Primary Auth | 二次认证 Secondary Auth | NSSAA |
|---|---|---|---|
| TS 章节 | TS 33.501 / 23.502 4.2 | TS 33.501 / 23.502 4.3.4 | TS 33.501 Cl.16 / 23.502 4.2.9 |
| 作用对象 | 整个 5GC 接入 | 单个 PDU 会话（DN-AAA） | 单个 S-NSSAI（切片） |
| 凭证 | USIM（5G AKA/EAP-AKA'） | 外部 DN 凭证 | 切片租户 AAA 凭证 |
| 编排 NF | AUSF+UDM | SMF+DN-AAA | NSSAAF + AAA-S |
| 触发时机 | 注册时 | PDU 会话建立 | 注册后、切片待用 |
| 失败影响 | 全网拒绝接入 | 该 PDU 会话失败 | 仅该切片不可用 |
三者关系是"嵌套授权"：主认证 → NSSAA（切片）→ 二次认证（数据网）。NSSAA 居于中间层。
| Release | NSSAA 关键增强 |
|---|---|
| Rel-15 | 主认证引入 ABBA 参数，为切片安全上下文铺路 |
| Rel-16 | 正式引入 NSSAA 流程与 NSSAAF；扩展 EAP 方法（不限于 AKA'/TLS） |
| Rel-17 | 新增 AUSF–NSSAAF 参考点支持 EAP-AKA'；SNPN 可用 AAA-S 做主认证；切片上 AKMA |
| Rel-18 | 引入 Partially Allowed NSSAI / Partially Rejected S-NSSAI；Alternative S-NSSAI |
| Rel-19 | 基于 AF 请求的切片变更；MWAB 节点授权 |
| Rel-20 | NSSAA over EPC（4G 网络）；漫游下 PLMN ID claim 修正 |
抓包识别：在 Wireshark/抓包工具中，NSSAA 的标志是：NAS 层出现 UL/DL NAS TRANSPORT 消息且 Payload container type = EAP message，并伴随 S-NSSAI IE；其下挂的 EAP 报文 Code=1/2（Request/Response）、Type 可能是 50（AKA'）或 13（TLS）。在 Nnssaaf 接口（HTTP/2）上可见 POST /nnssaaf-.../authenticate，请求体含 SUPI、S-NSSAI 与 EAP 报文。
常见故障点与排错： - 故障 1：切片一直停留在 Pending，EAP 无后续。 多为 NSSAAF 无法路由到 AAA-S（AAA 代理配置错误、N60/TS 29.526 链路不通）或 AAA-S 凭证库无该 UE。排查 Nnssaaf 调用日志与 AAA-S 侧计费/认证记录。 - 故障 2：EAP 交换正常但 UE 仍无法建 PDU 会话。 检查 AMF 是否将 S-NSSAI 从 Pending 正确迁入 Allowed；确认 Configuration Update / Registration Accept 携带了更新后的 Allowed NSSAI。 - 故障 3：撤销不生效，旧会话未释放。 检查 4.2.9.4 流程是否触发了对应切片 PDU 会话的 SMF 释放；部分实现需要 AMF 显式发起 PDU 会话释放命令。 - 故障 4：漫游场景失败。 Rel-20 前后对 PLMN ID claim 处理有调整，跨厂商漫游对接时需核对访问 token 结构。
厂商差异：不同厂商对"NSSAAF 独立部署 vs. 与 AUSF 合设"、"AAA 代理协议（Diameter vs. RADIUS over TLS）"、以及"撤销后是否主动释放 PDU 会话"的实现不一；SNPN 场景下 AAA-S 做主认证的路径（Rel-17）尤其需要端到端对齐。
Q1：NSSAA 与二次认证（Secondary Authentication to DN-AAA）有何区别？ A：作用层级不同。二次认证针对单个 PDU 会话到外部数据网（DN-AAA），由 SMF 编排；NSSAA 针对单个 S-NSSAI（切片），由 NSSAAF 编排。前者是"数据网准入"，后者是"切片准入"，二者可共存于同一会话。
Q2：NSSAA 失败会不会导致 UE 注册失败？ A：通常不会。只有该特定 S-NSSAI 被迁入 Rejected NSSAI，UE 的注册与其它已授权切片不受影响（多切片并行、相互隔离）。但若被拒切片是 UE 唯一请求的切片，则 UE 实际无可用业务。
Q3：NSSAA 会为切片派生用户面加密密钥吗？ A：Rel-16/17 不会。NSSAA 产出的是授权判定，切片内用户面保护沿用正常 5G 密钥；切片级独立用户面密钥不在 NSSAA 范畴。
Q4：为什么选 EAP 而不是直接复用 5G AKA？ A：EAP 是 IETF 成熟的认证框架，支持多种方法（AKA'/TLS 等），便于租户接入自有 AAA 域；而 5G AKA 是运营商 USIM 体系。用 EAP 才能实现"租户凭证 + 运营商网络"的解耦，NSSAAF 正是协议转换点。
Q5：UE 重注册时是否要重跑完整 NSSAA？
A：不必。AMF 可用 Nnssaaf_NSSAA_AA_Status_Get 查询该切片是否仍处于已认证状态；只要状态有效，即可直接恢复 Allowed NSSAI，避免重复 EAP 交换。
本文由「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 等场景全覆盖。