# 5G切片专属认证与授权（NSSAA）信令全链拆解 ## 一、为什么需要"切片之上的第二把锁" 5G主认证（5G AKA / EAP-AKA'）解决的是**"你是谁"**——它用USIM里的永久密钥K，在AUSF与UE之间完成一次全网级的身份验证，并派生出KSEAF→KAMF等密钥。但网络切片的商业场景颠覆了这个假设：一个工厂租用了一张"工业URLLC切片"，一张"海量物联网切片"，这些切片的**凭证、策略、信任域全部归租户（垂直行业）所有**，运营商并不掌握。仅靠UDM里"该用户是否订阅了某S-NSSAI"这一**二元订阅检查**，无法满足： 1. 租户希望用自己的企业证书/身份系统做实时准入决策； 2. 切片之间安全等级差异巨大，低安全切片凭证不应成为高安全切片的入场券； 3. 授权必须**可撤销、可周期重认证**，而非注册时一次性盖章。 3GPP在**TS 23.502 §4.2.9**（Network Slice-Specific Authentication and Authorization，简称NSSAA，Rel-16引入）定义了这套"切片之上的第二把锁"。它的核心思想是：**在主认证成功之后、针对每一个需要专属认证的S-NSSAI，再由AMF作为EAP认证器前端、经NSSAAF向切片租户的AAA-S发起一次独立的EAP认证**，授权结果（Allowed/Rejected）以S-NSSAI粒度回写到UE的Allowed NSSAI。 ```mermaid flowchart TD UE[UE] -- "N1 / NAS-TRANSPORT
(承载EAP, 含S-NSSAI)" --> AMF[AMF
EAP认证器前端] AMF -- "Nnssaaf_NSSAA_Authenticate
(EAP, GPSI, S-NSSAI)" --> NSSAAF[NSSAAF
AAA协议互通] NSSAAF -. "Nudm_UECM_Get
(GPSI→AMF ID)" .-> UDM[(UDM)] NSSAAF -- "AAA协议(EAP)
非SBI参考点" --> AAAP[AAA-P
可选代理] AAAP --> AAAS[AAA-S
切片租户域] style AAAS fill:#fde2e2,stroke:#c0392b style NSSAAF fill:#e3f2fd,stroke:#1976d2 style AMF fill:#e8f5e9,stroke:#388e3c ``` ## 二、涉及的网元与接口 | 网元 | 角色 | 关键职责 | |------|------|---------| | **AMF** | EAP认证器前端 | 触发NSSAA、用NAS TRANSPORT承载EAP、存储每个S-NSSAI的认证结果、更新Allowed/Rejected NSSAI | | **NSSAAF** | AAA协议互通功能 | 负责把EAP消息转译/中继给AAA-S、按S-NSSAI选路AAA-S地址、处理AAA协议互通 | | **AAA-P** | AAA代理（可选） | 当AAA-S属于第三方时，运营商部署的代理，隔离外网 | | **AAA-S** | 切片租户AAA服务器 | 真正的认证决策方，评估UE的租户凭证 | | **UDM** | 数据库 | 存储哪些S-NSSAI需要NSSAA、为每个S-NSSAI提供GPSI、供NSSAAF用GPSI反查AMF ID | > **避坑提示**：NSSAAF与外部AAA-S之间通过**AAA协议（承载EAP，通常为Diameter或RADIUS，也可为厂商私有HTTP API）**互通，3GPP**未**将其标准化为SBI参考点。不少资料误称为"N33"——N33实为NEF–AF接口，与NSSAAF无关。Rel-17又新增了AUSF–NSSAAF参考点，用于SNPN主认证与凭证远程下发场景，但标准切片二次认证路径里AUSF不在主链上。 ## 三、主认证流程全链拆解（TS 23.502 §4.2.9.2） 该流程共19步。下面以"UE注册时请求了一个需要NSSAA的S-NSSAI"为背景，逐步拆解每个消息的Information Element。 ```mermaid sequenceDiagram autonumber participant UE participant AMF participant NSSAAF participant AAAP as AAA-P(可选) participant AAAS as AAA-S Note over UE,AMF: 主认证(5G AKA)已成功, AMF发现Requested NSSAI中含需NSSAA的S-NSSAI AMF->>UE: DL NAS TRANSPORT(EAP Identity Request, S-NSSAI=H-PLMN值) UE->>AMF: UL NAS TRANSPORT(EAP Identity Response, S-NSSAI) AMF->>NSSAAF: Nnssaaf_NSSAA_Authenticate(EAP-ID Resp, GPSI, S-NSSAI) NSSAAF->>AAAP: 转发EAP(采用AAA-S支持的同一AAA协议) AAAP->>AAAS: EAP Identity(GPSI+S-NSSAI) Note over AAAS: AAA-S存储 GPSI↔EAP Identity 绑定,供后续撤销/重认证 loop 7~14: 一轮或多轮EAP消息交换(EAP-Request/Response, 如EAP-TLS握手) AAAS-->>AAAP: EAP-Request(method) AAAP-->>NSSAAF: EAP NSSAAF-->>AMF: Nnssaaf_NSSAA_Authenticate Resp(EAP) AMF-->>UE: DL NAS TRANSPORT(EAP) UE-->>AMF: UL NAS TRANSPORT(EAP) AMF-->>NSSAAF: Nnssaaf_NSSAA_Authenticate(EAP) NSSAAF-->>AAAS: EAP end AAAS-->>AAAP: EAP-Success/Failure(GPSI, S-NSSAI) AAAP-->>NSSAAF: AAA协议(EAP-Success/Failure, S-NSSAI, GPSI) NSSAAF-->>AMF: Nnssaaf_NSSAA_Authenticate Resp(EAP-Success/Failure, S-NSSAI, GPSI) AMF-->>UE: DL NAS TRANSPORT(EAP-Success/Failure) Note over AMF: AMF按S-NSSAI存储EAP结果 AMF->>UE: [条件] UE Configuration Update(新Allowed NSSAI / Rejected S-NSSAIs) Note over AMF: 若全部失败且无默认切片 → 网络发起去注册(§4.2.2.3.3) ``` ### 关键步骤与IE逐条解析 - **步骤1（触发）**：AMF根据UDM订阅信息（哪些S-NSSAI被标记为"需NSSAA"）或AAA-S触发，启动流程。注意一个省信令设计——若UE已在某接入上对同一S-NSSAI完成过NSSAA，AMF可**按策略跳过**第二接入上的重复认证。 - **步骤2~3（EAP Identity Request/Response）**：承载于**NAS MM Transport消息**（TS 24.501 §5.4.7 + §5.4.5定义的DL/UL NAS TRANSPORT），其中**必须携带S-NSSAI，且是H-PLMN的S-NSSAI值、而非本地映射值**——这保证漫游与归属场景语义一致。 - **步骤4（Nnssaaf_NSSAA_Authenticate Request）**：AMF经SBI把`(EAP Identity Response, GPSI, S-NSSAI)`发给NSSAAF。**GPSI替代SUPI**——AAA-S永远看不到SUPI，这是隐私隔离的核心。 - **步骤5~6（NSSAAF选路与绑定）**：NSSAAF**按S-NSSAI的本地配置选择对应AAA-S地址**，并采用该AAA-S所支持的同一AAA协议（Diameter/RADIUS等）转发。AAA-S把**GPSI与EAP Identity绑定存储**——这正是后续"网络发起重认证/撤销"能找到UE的依据。 - **步骤7~14（多轮EAP）**：EAP框架（IETF RFC 3748）允许任意方法，一轮可能不够（如EAP-TLS证书握手需多轮）。AMF/NSSAAF对EAP方法**完全透明**，只做透传。 - **步骤15~17（结果回传）**：AAA-S给出EAP-Success/Failure，沿AAA协议→NSSAAF→Nnssaaf_NSSAA_Authenticate Response回到AMF，字段`(EAP-Success/Failure, S-NSSAI, GPSI)`。 - **步骤18**：AMF用DL NAS TRANSPORT把EAP-Success/Failure发给UE，并**按S-NSSAI存储结果**。 - **步骤19a/19b（授权落地）**：这是真正影响业务的一步。AMF发起**UE Configuration Update（§4.2.4.2）**，更新Allowed NSSAI（成功的S-NSSAI纳入）与Rejected S-NSSAIs（失败的纳入）；若全部S-NSSAI失败且无默认切片可用，则**网络发起去注册（§4.2.2.3.3）**并在去注册请求中带Rejected S-NSSAIs及cause值。 ### 关键IE/服务操作参数说明表 | IE / 服务操作 | 方向 | 含义与设计要点 | |---------------|------|----------------| | **GPSI** | AMF→NSSAAF→AAA-S | 通用公共订阅标识，AAA-S侧UE身份；多GPSI时AMF任选其一；屏蔽SUPI | | **S-NSSAI（H-PLMN值）** | NAS + Nnssaaf | 标识目标切片；必须是H-PLMN值以保证漫游一致性 | | **EAP message** | NAS TRANSPORT + Nnssaaf | 实际认证载荷；方法由租户决定 | | **Nnssaaf_NSSAA_Authenticate** | AMF↔NSSAAF | 主认证的服务操作（TS 29.526 §5.2），Request/Response双向 | | **Nnssaaf_NSSAA_Re-AuthNotification** | NSSAAF→AMF | AAA-S发起重认证时的回调通知 | | **Nnssaaf_NSSAA_RevocationNotification** | NSSAAF→AMF | AAA-S发起撤销时的回调通知 | | **Nudm_UECM_Get(GPSI)** | NSSAAF→UDM | 网络发起流程中，用GPSI反查当前服务AMF ID | | **Mapping Of Allowed NSSAI** | AMF内部 | 判断该S-NSSAI是否已在某接入上被授权 | ## 四、AAA-S主导的重认证与撤销（TS 23.502 §4.2.9.3 / §4.2.9.4） "一次性认证"无法支撑动态授权。NSSAA定义了两个**网络发起（network-initiated）**流程，均由AAA-S主动发起，走的是"先用GPSI经UDM定位AMF、再回调AMF"的逆向路径。 ```mermaid sequenceDiagram autonumber participant AAAS as AAA-S participant AAAP as AAA-P(可选) participant NSSAAF participant UDM participant AMF participant UE Note over AAAS: 14: AAA-S决定撤销某UE对某S-NSSAI的授权 AAAS->>AAAP: AAA Revoke-Auth Request(S-NSSAI, GPSI) AAAP->>NSSAAF: 转发 NSSAAF->>UDM: Nudm_UECM_Get(GPSI) UDM-->>NSSAAF: AMF ID(可能两个接入两个AMF) NSSAAF-->>AAAP: ACK NSSAAF->>AMF: Nnssaaf_NSSAA_RevocationNotification(GPSI, S-NSSAI) Note over AMF: 若该S-NSSAI在Mapping Of Allowed NSSAI中 AMF->>UE: UE Configuration Update(从Allowed NSSAI移除该S-NSSAI, 新增Rejected) Note over AMF: 若有该切片的PDU会话 → 触发PDU Session Release(§4.3.4) Note over AMF: 若Allowed NSSAI为空且无默认切片 → 网络发起去注册(§4.2.2.3.3) ``` **重认证（§4.2.9.3）**与撤销前4步几乎同构（AAA协议消息换成`Re-Auth Request`，回调换成`Nnssaaf_NSSAA_Re-AuthNotification`），区别在第5步：重认证会让AMF**重新走一遍§4.2.9.2主流程**；若该S-NSSAI仅在非3GPP接入且UE在该接入CM-IDLE，AMF将其标记为**pending**，等UE回到CM-CONNECTED再发起。撤销则直接回收授权。 ### 每个S-NSSAI的认证状态机（AMF UE Context内） ```mermaid stateDiagram-v2 [*] --> NotAuthenticated NotAuthenticated --> Pending: AMF发起NSSAA(§4.2.9.2) Pending --> Authenticated: EAP-Success Pending --> Failed: EAP-Failure Authenticated --> Pending: AAA-S触发重认证(§4.2.9.3) Authenticated --> Revoked: AAA-S触发撤销(§4.2.9.4) Failed --> Pending: 下次注册重新请求 Revoked --> [*]: S-NSSAI移出Allowed NSSAI ``` ## 五、设计意图深度剖析 1. **租户主权（Tenant Sovereignty）**：最终授权决策权在AAA-S（租户域），运营商只做"管道与编排"。这是Network-as-a-Service商业闭环的基础——企业用自己的证书/身份系统控制谁能进自己的切片。 2. **隐私分层**：AAA-S只见GPSI、不见SUPI/SUCI。即使租户AAA-S被攻破，也无法反推5G永久身份。 3. **AMF=EAP认证器前端**：把面向UE的EAP传输收编进**已加密的NAS通道**，UE不需要新增任何接口或协议栈改动（复用DL/UL NAS TRANSPORT）；NSSAAF只专职AAA协议互通，职责单一。 4. **EAP方法中立**：AMF/NSSAAF对EAP方法透明，Rel-16起支持EAP-AKA'与EAP-TLS之外的任意方法，租户可按需选择。 5. **切片隔离与并行**：每个S-NSSAI独立认证、可并行进行，一个切片失败不影响其它已授权切片（Rel-18的Partially Allowed NSSAI进一步细化了这种部分放行语义）。 6. **全生命周期**：支持周期重认证与实时撤销，使授权从"静态订阅检查"进化为"动态可撤销决策"。 ## 六、实战连接：抓包识别与排错 ### 抓包识别 - **N1侧（UE↔AMF）**：tshark过滤器 `nas-5gs && (nas_5gs.message_id == 0x67 || nas_5gs.message_id == 0x68)` 即UL/DL NAS TRANSPORT（0x67/0x68，具体值见TS 24.501 §9.7消息表）。展开payload container可见`eap`（EAP-Request/Response/Success/Failure）与`S-NSSAI` IE——这是NSSAA与主认证EAP最直观的区别：**主认证的EAP在Authentication Request/Response里，NSSAA的EAP在NAS TRANSPORT里且带S-NSSAI**。 - **SBI侧（AMF↔NSSAAF）**：HTTP/2，路径形如`/nnssaaf-nssaa/v1/{ueId}/authentications`，JSON体含`eapPayload`、`snssai`、`gpsi`。 - **NSSAAF↔AAA-S侧**：厂商相关，常见Diameter（命令码承载EAP）或RADIUS Access-Request/Challenge，也可能为私有HTTP API。 ### 常见故障点 | 现象 | 根因 | 排查方向 | |------|------|---------| | UE始终拿不到目标切片 | UDM未给该S-NSSAI标记"需NSSAA"，或未配GPSI | 查UDM订阅数据中S-NSSAI的NSSAA指示与GPSI列表 | | NSSAA超时、切片被拒 | NSSAAF按S-NSSAI选路到错误的AAA-S地址，或AAA-S不可达 | 查NSSAAF本地AAA-S地址映射表与AAA-S连通性 | | EAP-Failure | 租户凭证不匹配/证书过期（EAP-TLS） | 在AAA-S侧看凭证库；AMF侧看EAP method | | 漫游下取不到切片 | AMF用了本地映射S-NSSAI而非H-PLMN值 | 核对NAS TRANSPORT与Nnssaaf中S-NSSAI取值 | | 撤销后业务未断 | AMF未触发PDU Session Release | 确认§4.2.9.4步骤对已建PDU会话的处理 | ## 七、对比：主认证 vs 切片专属认证 | 维度 | 主认证 5G AKA/EAP-AKA' | 切片专属认证 NSSAA | |------|----------------------|-------------------| | 标准 | TS 33.501 §6 | TS 23.502 §4.2.9 / TS 33.501 §16 | | 凭证 | USIM永久密钥K（订阅） | 租户自定（EAP-TLS证书/EAP-AKA'等） | | 决策方 | AUSF+UDM（H-PLMN） | AAA-S（切片租户域） | | UE标识 | SUPI/SUCI | **GPSI** | | EAP承载 | Authentication Request/Response NAS | DL/UL NAS TRANSPORT（TS 24.501 §5.4.7） | | 5GC功能 | AUSF | NSSAAF（AMF为EAP认证器前端） | | 产物 | KSEAF→KAMF密钥派生 | S-NSSAI粒度Allowed/Rejected状态 | | 生命周期 | 注册时单次+周期 | 单次 + **AAA-S可主动重认证/撤销** | ## 八、Release演进脉络 - **Rel-15**：在主认证引入**ABBA参数**为切片安全上下文铺路； - **Rel-16**：正式定义NSSAA，支持EAP-AKA'/EAP-TLS； - **Rel-17**：新增AUSF–NSSAAF参考点、凭证远程下发、切片内AKMA、SNPN用AAA做主认证； - **Rel-18**：Partially Allowed NSSAI、Alternative S-NSSAI（NSSF）、切片去激活时PDU会话优雅释放； - **Rel-19**：基于AF请求的切片变更、MWAB节点的授权处理； - **Rel-20**：NSSAA扩展到EPC（4G），覆盖EPS互通场景。 ## 常见问题 **Q1：NSSAA和主认证的EAP-AKA'有什么区别？** A：主认证EAP-AKA'用USIM密钥、在Authentication Request/Response NAS消息中承载、产物是密钥；NSSAA是主认证**之后**针对特定S-NSSAI的**第二次**EAP认证，用租户凭证、在NAS TRANSPORT中承载、产物是切片授权状态。二者是叠加关系，不是替代。 **Q2：为什么用GPSI而不是SUPI面向AAA-S？** A：AAA-S属于第三方租户域，不应感知5G永久身份。GPSI是专为外部暴露设计的标识，AAA-S侧存储GPSI↔EAP Identity绑定即可完成认证与后续撤销，SUPI始终留在运营商域内。 **Q3：一个UE请求多个需要NSSAA的切片，会串行还是并行？** A：可并行。TS 23.502明确支持对多个S-NSSAI并行执行NSSAA，某一切片失败不影响其它已成功切片，授权结果以S-NSSAI粒度独立维护。 **Q4：AAA-S撤销授权后，已经建立的PDU会话会怎样？** A：AMF在§4.2.9.4中检查Mapping Of Allowed NSSAI，移除该S-NSSAI并发起UE Configuration Update；若存在该切片的PDU会话，AMF会触发**PDU Session Release（§4.3.4）**；若Allowed NSSAI因此为空且无默认切片，则**网络发起去注册（§4.2.2.3.3）**。 **Q5：漫游场景下NSSAA在归属网还是拜访网执行？** A：以H-PLMN语义执行。NAS TRANSPORT与Nnssaaf中携带的必须是**H-PLMN的S-NSSAI值**而非本地映射值，AAA-S由归属侧/租户部署，保证漫游下授权决策的一致性。 ## 参考来源 1. [3GPP TS 23.502 §4.2.9 — Network Slice-Specific Authentication and Authorization procedure](https://itecspec.com/3gpp/23.502/s/4.2.9.2) — §4.2.9.2主流程、§4.2.9.3重认证、§4.2.9.4撤销逐步步骤 2. [3GPP — Network Slicing Security for 5G and 5G Advanced Systems](https://www.3gpp.org/technologies/slicing-security) — 官方对NSSAA设计意图与Release演进的权威解读 3. [3GPP TS 29.526 — Nnssaaf Service Stage 3 (V19.3.0)](https://www.etsi.org/deliver/etsi_ts/129500_129599/129526/) — Nnssaaf_NSSAA_Authenticate / Re-Auth / Revocation 服务操作定义 4. [3GPP TS 24.501 §5.4.7 — Network slice-specific authentication and authorization procedure](https://itecspec.com/3gpp/24.501/s/5.4.5) — NAS层EAP承载与NAS TRANSPORT映射 5. [3GPP Explorer — NSSAA / NSSAAF Glossary](https://3gpp-explorer.com/glossary/nssaa/) — 网元角色与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 等场景全覆盖。