# 5G NSSAA切片特定认证与授权全信令流深度拆解 ## 一、机制背景：为什么需要切片级二次认证 5G网络切片（Network Slicing）允许运营商在同一物理基础设施上为不同业务场景构建逻辑隔离的网络实例。标准5G-AKA主认证仅验证UE身份合法性，但**无法判定UE是否有权接入某个特定切片**。当切片由第三方（如企业、MVNO）运营时，切片拥有者需要独立的认证能力。 **NSSAA（Network Slice-Specific Authentication and Authorization）** 正是为解决这一问题而引入的机制，定义于3GPP Rel-16，核心规范分布在： | 规范编号 | 涉及章节 | 内容 | |----------|----------|------| | TS 23.502 | Section 4.2.9 / 4.2.9.2 | NSSAA流程与重认证流程 | | TS 23.501 | Section 5.15.9 | NSSAI与切片认证策略 | | TS 33.501 | Section 13.x | NSSAA安全架构 | | TS 29.526 | 全文 | Nnssaaf SBI接口Stage 3 | | TS 24.501 | Section 4.4.6 | NAS层EAP消息传输 | **设计意图**：主认证（5G-AKA/EAP-AKA'）建立基础信任关系，NSSAA在此基础上为**每个需要额外验证的S-NSSAI**执行独立的EAP认证。这种**分层认证架构**实现了： - 切片级访问控制，隔离不同信任域 - 第三方切片的自主凭证管理（如企业PKI） - 按切片粒度的授权策略执行 ## 二、核心网元与接口架构 ### 2.1 NSSAAF——专为切片认证引入的新网元 NSSAAF（Network Slice-Specific Authentication and Authorization Function）是Rel-16新增的核心网功能实体，作为PLMN与外部AAA服务器之间的**EAP认证代理**。 ```mermaid graph TB UE["UE
持有切片凭证"] AMF["AMF
EAP Authenticator角色
触发NSSAA"] NSSAAF["NSSAAF
EAP代理/中继
协议转换"] AAA_P["AAA-P
PLMN侧AAA代理"] AAA_S["AAA-S
切片方AAA服务器
(可能第三方)"] UDM["UDM
签约数据
NSSAA指示"] NSSF["NSSF
切片选择"] UE -->|"N1 NAS
(EAP容器)"| AMF AMF -->|"Nnssaaf_NSSAA
_Authenticate"| NSSAAF NSSAAF -->|"SWa/STa
(RADIUS/Diameter)"| AAA_P AAA_P -->|"外部接口"| AAA_S AMF -->|"Nudm_SDM_Get"| UDM AMF -->|"Nnssf_NSSelection"| NSSF style NSSAAF fill:#e1f5fe style AAA_S fill:#fff3e0 style UE fill:#e8f5e9 ``` ### 2.2 关键接口一览 | 接口 | 端点 | 协议 | 功能 | |------|------|------|------| | N1 | UE ↔ AMF | NAS (5GMM/5GSM) | 承载EAP消息的NAS传输容器 | | Nnssaaf | AMF ↔ NSSAAF | SBI (HTTP/2) | `Nnssaaf_NSSAA_Authenticate` / `Nnssaaf_NSSAA_Revoke` | | SWa | NSSAAF ↔ AAA-P | RADIUS/Diameter | 非可信非3GPP接入认证 | | STa | NSSAAF ↔ AAA-P | Diameter | 可信非3GPP接入认证 | | N33 | NSSAAF ↔ AAA-S | 外部协议 | 第三方AAA交互（通过AAA-P代理） | | Nudm | AMF ↔ UDM | SBI | 获取切片签约数据中的NSSAA指示 | ### 2.3 NSSAA触发条件判定 AMF根据以下条件判定是否触发NSSAA（依据TS 23.501 Section 5.15.9.2）： ``` 条件1: UDM签约数据中该S-NSSAI标记了 "NSSAA Required" 条件2: 该S-NSSAI不在当前Allowed NSSAI中（尚未通过NSSAA） 条件3: 该S-NSSAI不在Pending NSSAI中（未正在进行NSSAA） ``` 当三个条件同时满足时，AMF将该S-NSSAI放入**Pending NSSAI**列表，并启动NSSAA流程。 ## 三、NSSAA完整信令时序图（注册触发） 以下是TS 23.502 Section 4.2.9定义的完整NSSAA信令流，嵌入在初始注册流程中： ```mermaid sequenceDiagram participant UE participant RAN participant AMF participant UDM participant NSSAAF participant AAA_P as AAA-P participant AAA_S as AAA-S Note over UE,AMF: 阶段1: 初始注册（主认证已完成） UE->>RAN: Registration Request
Requested NSSAI: [S-NSSAI-A, S-NSSAI-B] RAN->>AMF: N2 Message + Registration Request AMF->>UDM: Nudm_SDM_Get (SUPI) UDM-->>AMF: 订阅数据
S-NSSAI-A: NSSAA Required=True
S-NSSAI-B: NSSAA Required=False Note right of AMF: S-NSSAI-B → Allowed NSSAI
S-NSSAI-A → Pending NSSAI
触发NSSAA AMF->>UE: Registration Accept
Allowed NSSAI: [S-NSSAI-B]
Pending NSSAI: [S-NSSAI-A] Note over UE,AAA_S: 阶段2: NSSAA EAP认证交换 AMF->>UE: DL NAS Transport
EAP-Request/Identity
(针对S-NSSAI-A) UE->>AMF: UL NAS Transport
EAP-Response/Identity AMF->>NSSAAF: POST /nnssaaf-nssaa/v1/{supi}/authenticate
{snssai, eapPayload, aaaSelectionData} NSSAAF->>AAA_P: AAA-Request (EAP-Response/Identity) AAA_P->>AAA_S: 转发认证请求 AAA_S-->>AAA_P: AAA-Answer (EAP-Request/TLS-Start) AAA_P-->>NSSAAF: AAA-Response NSSAAF-->>AMF: 200 OK {eapPayload: EAP-Request/TLS-Start} AMF->>UE: DL NAS Transport
EAP-Request/TLS-Start UE->>AMF: UL NAS Transport
EAP-Response/TLS-ClientHello rect rgb(255, 248, 225) Note over UE,AAA_S: EAP-TLS握手（可能多轮） AMF->>NSSAAF: POST .../authenticate {eapPayload} NSSAAF->>AAA_P: AAA-Request AAA_P->>AAA_S: 转发 AAA_S-->>AAA_P: AAA-Answer AAA_P-->>NSSAAF: AAA-Response NSSAAF-->>AMF: 200 OK {eapPayload} AMF->>UE: DL NAS Transport (EAP消息) UE->>AMF: UL NAS Transport (EAP消息) end Note over UE,AAA_S: 阶段3: 认证结果 AAA_S-->>AAA_P: AAA-Answer (EAP-Success + 授权数据) AAA_P-->>NSSAAF: AAA-Response (EAP-Success) NSSAAF-->>AMF: 200 OK {authResult: SUCCESS,
snssai: S-NSSAI-A} AMF->>UE: DL NAS Transport
EAP-Success Note right of AMF: S-NSSAI-A从Pending移至Allowed AMF->>UE: Configuration Update Command
Allowed NSSAI: [S-NSSAI-A, S-NSSAI-B] ``` ## 四、关键信息元素（IE）逐步拆解 ### 4.1 Registration Request中的切片相关IE | IE名称 | 长度 | 来源 | 说明 | |--------|------|------|------| | Requested NSSAI | 可变 | UE | UE请求接入的切片列表，包含S-NSSAI-A等 | | Network Slicing Indication | 1字节 | UE | 指示是否需要在注册中执行NSSAA | | 5GS Registration Type | 4bit | UE | 初始注册/移动性更新/周期更新 | | SUCI/SUPI | 可变 | UE | 用户标识（主认证使用） | ### 4.2 Nnssaaf_NSSAA_Authenticate请求参数 基于TS 29.526定义的SBI接口，AMF向NSSAAF发送的POST请求体结构： | 字段 | 类型 | 必选 | 说明 | |------|------|------|------| | snssai | Snssai | 是 | 需要NSSAA的切片标识（SST+SD） | | eapPayload | Bytes | 是 | UE发送的EAP-Response原始数据 | | routingIndicator | String | 否 | SUPI中的路由指示符，用于AAA选择 | | aaaSelectionData | Object | 否 | AAA服务器选择信息（地址/ID） | | notificationUri | URI | 否 | 用于接收NSSAA状态变更通知的回调URI | | notificationCorrelationId | String | 否 | 通知关联标识 | | afId | String | 否 | 应用功能标识（当AF触发时使用） | ### 4.3 NSSAAF响应参数 | 字段 | 类型 | 说明 | |------|------|------| | eapPayload | Bytes | 返回给UE的EAP-Request消息 | | authResult | Enum | `SUCCESS` / `FAILURE` / `ONGOING` | | snssai | Snssai | 认证结果对应的S-NSSAI | | aaaFailureCause | Enum | AAA服务器失败原因（如可达性、超时等） | ### 4.4 NAS层EAP传输容器 NSSAA的EAP消息通过NAS层的**5GMM Transport**消息承载，而非使用专门的NAS消息类型： | NAS消息 | 方向 | 承载的EAP IE | |---------|------|-------------| | DL NAS Transport | 网络→UE | EAP-Request（含Slice标识） | | UL NAS Transport | UE→网络 | EAP-Response | 关键约束：DL NAS Transport中的**Payload Container Type**必须设置为EAP消息类型，同时携带**Payload Container**（即EAP数据包）和关联的S-NSSAI信息。 ### 4.5 EAP-TLS在NSSAA中的消息交互 以下展示EAP-TLS方法在NSSAA中的典型交互： ```mermaid sequenceDiagram participant UE participant AMF participant NSSAAF participant AAA AMF->>UE: EAP-Request/Identity UE->>AMF: EAP-Response/Identity (slice-user@enterprise.com) Note over AMF: 转发至NSSAAF AMF->>UE: EAP-Request/TLS (Start) UE->>AMF: EAP-Response/TLS (ClientHello) AMF->>UE: EAP-Request/TLS (ServerHello + Certificate + ServerKeyExchange + CertificateRequest) UE->>AMF: EAP-Response/TLS (Certificate + ClientKeyExchange + CertificateVerify + ChangeCipherSpec + Finished) AMF->>UE: EAP-Request/TLS (ChangeCipherSpec + Finished) AMF->>UE: EAP-Success Note over UE,AAA: 关键: UE和AAA双向证书认证
TLS隧道保护后续数据 ``` **EAP-TLS交互要点**： - UE需预配置切片特定X.509客户端证书 - AAA服务器持服务端证书，实现双向认证 - TLS版本要求≥1.2（推荐1.3） - 大证书可能导致EAP分片（MTU协商） ## 五、Pending NSSAI状态机与生命周期管理 NSSAA涉及复杂的S-NSSAI状态管理，AMF需维护每个S-NSSAI的认证状态： ```mermaid stateDiagram-v2 [*] --> Requested: UE在Registration Request
中携带该S-NSSAI Requested --> Pending: AMF判定需NSSAA
且发起EAP认证 Requested --> Allowed: 签约数据中
NSSAA Required=False Pending --> Allowed: NSSAA成功
EAP-Success Pending --> Rejected: NSSAA失败
EAP-Failure Pending --> Pending: EAP多轮交换
(authResult=ONGOING) Allowed --> Pending_NSSAA: 重认证触发
(定时器到期/AAA通知) Pending_NSSAA --> Allowed: 重认证成功 Pending_NSSAA --> Revoked: 重认证失败 Revoked --> [*]: PDU Session释放 Rejected --> [*]: UE可重新请求 Allowed --> Revoked: AAA撤销通知
(Nnssaaf_NSSAA_Revoke) ``` **关键状态转换说明**： | 转换 | 触发条件 | AMF行为 | |------|----------|---------| | Requested→Pending | UDM指示NSSAA Required=True | 将S-NSSAI放入Pending NSSAI，在Reg Accept中通知UE | | Pending→Allowed | 收到NSSAAF的SUCCESS响应 | 将S-NSSAI从Pending移至Allowed，触发UE Configuration Update | | Pending→Rejected | 收到NSSAAF的FAILURE响应 | 通知UE该切片不可用，拒绝相关PDU Session请求 | | Allowed→Revoked | 收到Nnssaaf_NSSAA_Revoke通知 | 释放关联PDU Session，从Allowed中移除 | ## 六、NSSAA重认证与撤销流程 TS 23.502 Section 4.2.9.2定义了两个关键子流程。 ### 6.1 切片重认证流程 当以下条件之一满足时触发重认证： - NSSAAF/AAA设置的认证定时器到期 - AAA服务器主动发起重新认证请求 - 切片授权策略变更 ```mermaid sequenceDiagram participant AAA_S as AAA-S participant NSSAAF participant AMF participant UE Note over NSSAAF,AMF: 定时器到期或AAA触发 NSSAAF->>AMF: Nnssaaf_NSSAA_Authenticate
通知(重认证触发) AMF->>UE: DL NAS Transport
EAP-Request/Identity (重认证) UE->>AMF: UL NAS Transport
EAP-Response/Identity rect rgb(232, 245, 233) Note over UE,AAA_S: EAP认证交换（同初始流程） AMF->>NSSAAF: POST /authenticate NSSAAF->>AAA_S: AAA-Request AAA_S-->>NSSAAF: AAA-Answer NSSAAF-->>AMF: 200 OK {eapPayload} AMF->>UE: DL NAS Transport (EAP消息) end alt 重认证成功 AAA_S-->>NSSAAF: EAP-Success + 新授权数据 NSSAAF-->>AMF: authResult=SUCCESS AMF->>UE: Configuration Update (维持Allowed NSSAI) else 重认证失败 AAA_S-->>NSSAAF: EAP-Failure NSSAAF-->>AMF: authResult=FAILURE AMF->>UE: Configuration Update (从Allowed移除S-NSSAI) Note right of AMF: 按TS 23.502 4.3.4
释放关联PDU Session end ``` ### 6.2 切片授权撤销流程 授权撤销可由NSSAAF或AAA-S主动发起，无需UE参与： | 步骤 | 动作 | 消息/接口 | |------|------|-----------| | 1 | AAA-S决定撤销某UE的切片权限 | AAA-S→AAA-P→NSSAAF | | 2 | NSSAAF通知AMF | `Nnssaaf_NSSAA_Revoke` 通知 | | 3 | AMF将S-NSSAI从Allowed移至Rejected | 内部状态更新 | | 4 | AMF释放该切片上的所有PDU Session | 按4.3.4发起PDU Session Release | | 5 | AMF通知UE | UE Configuration Update Command | ## 七、与其他认证机制的对比 | 维度 | 5G-AKA主认证 | NSSAA切片认证 | EAP-AKA'（非3GPP） | |------|-------------|--------------|-------------------| | **规范** | TS 33.501 Section 6.1 | TS 33.501 Section 13 | TS 33.501 Section 6.2 | | **触发时机** | 注册流程开始时 | 主认证完成后 | 非可信WiFi接入时 | | **认证粒度** | 每个SUPI | 每个S-NSSAI | 每个SUPI | | **凭证类型** | USIM (K, OPc) | 切片特定（证书/预共享密钥） | USIM | | **EAP方法** | 无（原生AKA） | EAP-TLS/EAP-TTLS/EAP-AKA等 | EAP-AKA' | | **认证方** | AUSF + UDM | NSSAAF + AAA-S | AUSF + UDM | | **密钥推演** | K→CK/IK→KAUSF→KSEAF | 不影响5G密钥层级 | 独立密钥推演 | | **NAS保护** | 影响NAS安全上下文 | 不影响NAS安全 | 影响NAS安全 | | **UE端存储** | USIM | 切片凭证可存于USIM或ISIM | USIM | **关键区别**：NSSAA的认证结果**不参与5G密钥层级推演**，仅决定UE是否能接入特定切片。这意味着NSSAA成功/失败不影响NAS信令加密和完整性保护，也不会改变AS层安全密钥。 ## 八、Nnssaaf SBI接口详细参数映射（TS 29.526） ### 8.1 Nnssaaf_NSSAA_Authenticate **URI**: `POST {apiRoot}/nnssaaf-nssaa/v1/{supi}/authenticate` 请求体JSON结构示例： ```json { "supportedFeatures": "ffff", "snssai": { "sst": 1, "sd": "010203" }, "sliceAuthData": { "eapPayload": "0x01...（EAP-Response原始字节）", "routingIndicator": "1234", "aaaSelectionData": { "aaaServerAddress": "aaa.enterprise.com", "aaaProtocol": "DIAMETER" } }, "notificationUri": "https://amf.operator.com/nssaa-notify", "notificationCorrelationId": "corr-id-20260602-001" } ``` ### 8.2 认证结果枚举 | authResult值 | 含义 | AMF处理 | |-------------|------|---------| | `SUCCESS` | 认证授权通过 | S-NSSAI从Pending移至Allowed | | `FAILURE` | 认证或授权失败 | S-NSSAI从Pending移至Rejected | | `ONGOING` | 认证进行中，需继续EAP交换 | 保持Pending状态，继续转发EAP | ### 8.3 Nnssaaf_NSSAA_Revoke 通知 当NSSAAF需要主动撤销切片授权时，向AMF发送通知： **URI**: `POST {notificationUri}` （即AMF在初始请求中提供的notificationUri） ```json { "report": { "supi": "imsi-460001234567890", "snssai": {"sst": 1, "sd": "010203"}, "authResult": "FAILURE", "aaaFailureCause": "SUBSCRIPTION_EXPIRED" } ``` ## 九、实战：抓包识别与故障排查 ### 9.1 Wireshark过滤策略 | 过滤器 | 用途 | |--------|------| | `nas-5gs.message_type == 110` | DL NAS Transport（携带EAP-Request） | | `nas-5gs.message_type == 111` | UL NAS Transport（携带EAP-Response） | | `nas-5gs.nssai` | 查看NSSAI相关IE | | `eap.type == 13` | EAP-TLS类型包 | | `eap.code == 1` | EAP-Request | | `eap.code == 2` | EAP-Response | | `json.path == "$.snssai"` | Nnssaaf SBI接口中的S-NSSAI | | `http2.headers.path contains "nnssaaf"` | NSSAAF相关HTTP/2请求 | ### 9.2 典型故障场景与排查思路 **场景1：Registration Accept中没有包含请求的S-NSSAI** ``` 排查路径: 1. 检查UDM签约数据中该S-NSSAI是否标记NSSAA Required 2. 确认AMF是否将S-NSSAI放入Pending NSSAI 3. 检查Registration Accept中是否有Pending NSSAI IE 4. 如无Pending NSSAI → AMF判定逻辑问题或UDM数据缺失 5. 如有Pending NSSAI → 检查后续EAP交换是否正常发起 ``` **场景2：EAP交换卡在某轮不继续** ``` 排查路径: 1. 抓取Nnssaaf接口HTTP/2消息，确认authResult是否为ONGOING 2. 检查NSSAAF→AAA-P的连通性（RADIUS/Diameter可达性） 3. 检查AAA-S是否可达（第三方服务器状态） 4. 查看AMF日志中EAP超时定时器配置（典型值30-60秒） 5. EAP分片场景下检查MTU设置是否合理 ``` **场景3：EAP-TLS证书验证失败** ``` 排查路径: 1. 确认UE切片证书的有效期（openssl x509 -checkend） 2. 检查证书链完整性（根CA + 中间CA + 终端证书） 3. 确认AAA-S信任的CA列表包含UE证书的签发CA 4. 检查CRL/OCSP可达性（证书吊销检查） 5. 确认TLS版本兼容性（UE和AAA-S支持的TLS版本交集） ``` ## 十、Rel-17/18/19增强特性 ### 10.1 Rel-17增强 - **SNPN场景NSSAA**：为独立非公共网络（Stand-alone Non-Public Network）定义了NSSAA流程，支持SNPN间的切片认证 - **NSSAAF发现增强**：增加了基于NRF的NSSAAF自动发现机制 ### 10.2 Rel-18增强 - **Alternate S-NSSAI替换**：NSSAA重认证失败时，AAA-S可建议替代S-NSSAI，避免直接拒绝 - 参见TS 23.502 Section 4.2.9.2 - AMF将Alternate S-NSSAI通知UE，允许UE使用替代切片建立PDU Session - **NSSAA与NSAC协同**：切片准入控制（Network Slice Admission Control）与NSSAA结果的联动 ### 10.3 Rel-19方向 - **AI辅助NSSAA策略**：基于UE行为模式动态调整切片认证策略 - **跨PLMN NSSAA优化**：漫游场景下的切片认证时延优化 - **量子安全EAP方法**：引入抗量子计算攻击的EAP认证方法用于高安全切片 ## 常见问题 **Q1: NSSAA和主认证5G-AKA可以并行执行吗？** A: 不可以。NSSAA必须在主认证成功完成**之后**才能触发。AMF先完成5G-AKA获取SUPI和NAS安全上下文，再从UDM获取签约数据判断哪些S-NSSAI需要NSSAA。只有已通过主认证的UE才能进入NSSAA流程。 **Q2: 一个UE同时请求多个需要NSSAA的切片时如何处理？** A: AMF对每个需要NSSAA的S-NSSAI**独立**执行NSSAA流程。多个S-NSSAI的NSSAA可以并行进行，每个切片对应独立的EAP会话和AAA交互。通过S-NSSAI字段区分不同的认证实例。 **Q3: NSSAA失败后UE能否继续使用其他切片？** A: 可以。NSSAA是**按切片粒度**执行的。某个S-NSSAI的NSSAA失败仅影响该切片的访问权限，不影响已通过认证的其他切片。UE仍可使用Allowed NSSAI中的其他切片建立PDU Session。 **Q4: NSSAA的EAP消息为什么通过NAS Transport而不是专门的NAS消息承载？** A: 这是设计上的有意选择。NAS Transport消息是通用的NAS容器，设计用于承载非NAS原生协议（如EAP）。NSSAA在Rel-16引入时，为避免新增NAS消息类型（这需要UE和网络的NAS协议栈同时升级），复用了已有的DL/UL NAS Transport机制，降低了实现复杂度。 **Q5: 第三方切片运营商能否直接访问UE的SUPI等永久标识？** A: 不能，这是NSSAA架构的安全设计要点。AAA-S仅能获取EAP-Identity（UE在EAP层提供的切片特定身份），无法获取SUPI。AMF和NSSAAF负责协议转换和身份映射，在PLMN信任边界处隔离了用户隐私信息。这种设计符合GDPR等隐私法规的要求。 ## 参考来源 1. [3GPP TS 23.502 V18.10.0](https://www.3gpp.org/DynaReport/23502.htm) — Section 4.2.9 NSSAA流程定义、Section 4.2.9.2重认证与撤销 2. [3GPP TS 33.501 V18.10.0](https://www.3gpp.org/DynaReport/33501.htm) — Section 13.x NSSAA安全架构与要求 3. [3GPP TS 29.526 V19.4.0](https://www.3gpp.org/DynaReport/29526.htm) — Nnssaaf SBI接口Stage 3定义 4. [TS 23.502 Section 4.2.9 — iTecSpec](https://itecspec.com/3gpp/23.502/s/4.2.9) — NSSAA流程在线解读 5. [3GPP Network Slicing Security](https://www.3gpp.org/technologies/slicing-security) — 官方切片安全概述 6. [free5GC Network Slicing Blog](https://free5gc.org/blog/20241230/20241230/) — 开源5GC中NSSAA实现分析 7. [NSSAAF Glossary — 3GPP Explorer](https://3gpp-explorer.com/glossary/nssaaf/) — NSSAAF功能概述与接口说明 --- > 本文由「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 等场景全覆盖。