首页 › slicing-mec › NSSAA切片二次认证信令拆解

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认证。这种分层认证架构实现了:

二、核心网元与接口架构

2.1 NSSAAF——专为切片认证引入的新网元

NSSAAF(Network Slice-Specific Authentication and Authorization Function)是Rel-16新增的核心网功能实体,作为PLMN与外部AAA服务器之间的EAP认证代理。

graph TB
    UE["UE<br/>持有切片凭证"]
    AMF["AMF<br/>EAP Authenticator角色<br/>触发NSSAA"]
    NSSAAF["NSSAAF<br/>EAP代理/中继<br/>协议转换"]
    AAA_P["AAA-P<br/>PLMN侧AAA代理"]
    AAA_S["AAA-S<br/>切片方AAA服务器<br/>(可能第三方)"]
    UDM["UDM<br/>签约数据<br/>NSSAA指示"]
    NSSF["NSSF<br/>切片选择"]

    UE -->|"N1 NAS<br/>(EAP容器)"| AMF
    AMF -->|"Nnssaaf_NSSAA<br/>_Authenticate"| NSSAAF
    NSSAAF -->|"SWa/STa<br/>(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信令流,嵌入在初始注册流程中:

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<br/>Requested NSSAI: [S-NSSAI-A, S-NSSAI-B]
    RAN->>AMF: N2 Message + Registration Request
    AMF->>UDM: Nudm_SDM_Get (SUPI)
    UDM-->>AMF: 订阅数据<br/>S-NSSAI-A: NSSAA Required=True<br/>S-NSSAI-B: NSSAA Required=False
    Note right of AMF: S-NSSAI-B → Allowed NSSAI<br/>S-NSSAI-A → Pending NSSAI<br/>触发NSSAA

    AMF->>UE: Registration Accept<br/>Allowed NSSAI: [S-NSSAI-B]<br/>Pending NSSAI: [S-NSSAI-A]

    Note over UE,AAA_S: 阶段2: NSSAA EAP认证交换

    AMF->>UE: DL NAS Transport<br/>EAP-Request/Identity<br/>(针对S-NSSAI-A)
    UE->>AMF: UL NAS Transport<br/>EAP-Response/Identity

    AMF->>NSSAAF: POST /nnssaaf-nssaa/v1/{supi}/authenticate<br/>{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<br/>EAP-Request/TLS-Start
    UE->>AMF: UL NAS Transport<br/>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,<br/>snssai: S-NSSAI-A}

    AMF->>UE: DL NAS Transport<br/>EAP-Success
    Note right of AMF: S-NSSAI-A从Pending移至Allowed

    AMF->>UE: Configuration Update Command<br/>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中的典型交互:

sequenceDiagram
    participant UE
    participant AMF
    participant NSSAAF
    participant AAA

    AMF->>UE: EAP-Request/Identity
    UE->>AMF: EAP-Response/Identity ([email protected])
    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双向证书认证<br/>TLS隧道保护后续数据

EAP-TLS交互要点: - UE需预配置切片特定X.509客户端证书 - AAA服务器持服务端证书,实现双向认证 - TLS版本要求≥1.2(推荐1.3) - 大证书可能导致EAP分片(MTU协商)

五、Pending NSSAI状态机与生命周期管理

NSSAA涉及复杂的S-NSSAI状态管理,AMF需维护每个S-NSSAI的认证状态:

stateDiagram-v2
    [*] --> Requested: UE在Registration Request<br/>中携带该S-NSSAI
    Requested --> Pending: AMF判定需NSSAA<br/>且发起EAP认证
    Requested --> Allowed: 签约数据中<br/>NSSAA Required=False
    Pending --> Allowed: NSSAA成功<br/>EAP-Success
    Pending --> Rejected: NSSAA失败<br/>EAP-Failure
    Pending --> Pending: EAP多轮交换<br/>(authResult=ONGOING)
    Allowed --> Pending_NSSAA: 重认证触发<br/>(定时器到期/AAA通知)
    Pending_NSSAA --> Allowed: 重认证成功
    Pending_NSSAA --> Revoked: 重认证失败
    Revoked --> [*]: PDU Session释放
    Rejected --> [*]: UE可重新请求
    Allowed --> Revoked: AAA撤销通知<br/>(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服务器主动发起重新认证请求 - 切片授权策略变更

sequenceDiagram
    participant AAA_S as AAA-S
    participant NSSAAF
    participant AMF
    participant UE

    Note over NSSAAF,AMF: 定时器到期或AAA触发

    NSSAAF->>AMF: Nnssaaf_NSSAA_Authenticate<br/>通知(重认证触发)
    AMF->>UE: DL NAS Transport<br/>EAP-Request/Identity (重认证)
    UE->>AMF: UL NAS Transport<br/>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<br/>释放关联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结构示例:

{
  "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)

{
  "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增强

10.2 Rel-18增强

10.3 Rel-19方向

常见问题

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 — Section 4.2.9 NSSAA流程定义、Section 4.2.9.2重认证与撤销
  2. 3GPP TS 33.501 V18.10.0 — Section 13.x NSSAA安全架构与要求
  3. 3GPP TS 29.526 V19.4.0 — Nnssaaf SBI接口Stage 3定义
  4. TS 23.502 Section 4.2.9 — iTecSpec — NSSAA流程在线解读
  5. 3GPP Network Slicing Security — 官方切片安全概述
  6. free5GC Network Slicing Blog — 开源5GC中NSSAA实现分析
  7. NSSAAF Glossary — 3GPP Explorer — 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 等场景全覆盖。

51学通信知识星球海报-扫码加入