首页 › slicing-mec › 5G NSSAA切片二次鉴权与EAP信令拆解

5G NSSAA切片二次鉴权与EAP信令拆解

一、机制概述:为什么需要切片级二次鉴权

在5G网络中,UE接入网络首先要完成主认证(Primary Authentication)——即5G-AKA或EAP-AKA',建立SUPI与PLMN之间的信任关系。但这只是"你能入网",并不代表"你能用任何切片"。

某些垂直行业切片(如电力、车联网、工业控制)由第三方企业运营,这些企业拥有自己的用户数据库和认证系统。运营商无法判断某个UE是否有权接入该行业切片。3GPP从Rel-16开始引入NSSAA(Network Slice-Specific Authentication and Authorization)机制,允许第三方AAA服务器对UE进行独立的二次认证和授权。

核心设计原则(TS 33.501 Section 16.3):

┌───────────────────────────────────────────────────────┐
│              NSSAA在5G认证体系中的位置                    │
│                                                       │
│   Stage 1: 主认证 (5G-AKA / EAP-AKA')                 │
│   ┌─────┐    ┌─────┐    ┌─────┐    ┌─────┐           │
│   │ UE  │───▶│ SEAF│───▶│ AUSF│───▶│ UDM │           │
│   └─────┘    └─────┘    └─────┘    └─────┘           │
│       验证: SUPI/USIM凭证 → 获得Allowed NSSAI          │
│                                                       │
│   Stage 2: NSSAA (EAP-based)                         │
│   ┌─────┐    ┌─────┐    ┌───────┐    ┌──────┐        │
│   │ UE  │───▶│ AMF │───▶│NSSAAF │───▶│ AAA-S│        │
│   └─────┘    └─────┘    └───────┘    └──────┘        │
│       验证: 企业级EAP凭证 → 获得切片接入授权              │
└───────────────────────────────────────────────────────┘

二、触发条件与前置判断

2.1 NSSAA触发时机

根据TS 23.502 Section 4.2.9.1,NSSAA在以下三种场景触发:

触发场景 描述 发起方
注册流程中 UE注册时,Requested NSSAI中包含需要NSSAA的S-NSSAI AMF触发
订阅变更 UDM通知AMF订阅数据变更,新的S-NSSAI需要NSSAA AMF触发
AAA-S发起重认证 第三方AAA服务器主动要求对已授权UE重新认证 AAA-S触发

2.2 AMF的判断逻辑

AMF在注册流程中(TS 23.502 Section 4.2.2.2.1, Step 21/25)进行以下判断:

  1. 检查UE能力:UE是否在UE 5GMM Core Network Capability中声明支持NSSAA - 不支持 → 将该S-NSSAI放入Rejected NSSAI - 支持 → 继续

  2. 检查订阅数据:从UDM获取的订阅信息中,S-NSSAI是否标记为"subject to NSSAA"

  3. 检查已有结果:UE Context中是否已有该S-NSSAI的成功NSSAA记录 - 已成功且有效 → 可跳过(基于网络策略) - 无记录或已过期 → 需要执行NSSAA

  4. 确定Pending NSSAI:将需要NSSAA的S-NSSAI放入Pending NSSAI,不放入Allowed NSSAI

关键博弈点:如果UE请求的所有S-NSSAI都需要NSSAA,AMF将返回空Allowed NSSAI + Pending NSSAI。此时UE已注册但"什么都做不了",必须等待NSSAA完成(TS 23.502 Section 4.2.2.2.1)。

┌──────────┐     Registration Request     ┌─────┐
│   UE     │─────────────────────────────▶│ AMF │
│          │    (Requested NSSAI:          │     │
│          │     S-NSSAI-A, S-NSSAI-B)     │     │
└──────────┘                               └──┬──┘
                                              │
                           ┌──────────────────┤
                           ▼                  ▼
                    订阅数据查询           主认证(如需)
                           │                  │
                           ▼                  ▼
                    ┌─────────────────────────────┐
                    │  AMF 判断逻辑:               │
                    │  S-NSSAI-A: 需要NSSAA        │
                    │  S-NSSAI-B: 不需要NSSAA      │
                    └──────────┬──────────────────┘
                               │
                               ▼
                    Registration Accept
                    Allowed NSSAI: [S-NSSAI-B]
                    Pending NSSAI: [S-NSSAI-A]

2.3 GPSI的必要性

NSSAA必须使用GPSI(Generic Public Subscription Identifier)而非SUPI。这是因为AAA-S通常由第三方运营,不应获得3GPP内部标识符SUPI。GPSI是面向外部的通用标识符(如External Identifier或MSISDN),适合跨域认证场景。

TS 23.502 Section 4.2.9.1明确规定:包含需要NSSAA的S-NSSAI的订阅,必须至少包含一个GPSI。

三、NSSAA完整信令时序图

以下基于TS 23.502 Section 4.2.9.2和TS 33.501 Section 16.3,绘制完整的NSSAA EAP认证流程:

sequenceDiagram
    participant UE
    participant AMF
    participant NSSAAF
    participant AAA_P as AAA-P<br/>(可选)
    participant AAA_S as AAA-S<br/>(第三方)

    Note over UE,AAA_S: 阶段0: 注册流程已完成主认证, AMF已确定S-NSSAI需要NSSAA

    rect rgb(230, 245, 255)
    Note over UE,AMF: Step 1-3: EAP Identity交换
    AMF->>UE: NAS MM Transport<br/>(EAP Identity Request, S-NSSAI)
    UE->>AMF: NAS MM Transport<br/>(EAP Identity Response, S-NSSAI)
    end

    rect rgb(255, 245, 230)
    Note over AMF,AAA_S: Step 4-6: 向AAA-S发起认证请求
    AMF->>NSSAAF: Nnssaaf_NSSAA_Authenticate Request<br/>(EAP ID Response, GPSI, S-NSSAI)
    NSSAAF->>AAA_P: AAA Protocol Message<br/>(EAP ID Response, GPSI, S-NSSAI/ENSI)
    AAA_P->>AAA_S: AAA Protocol Message<br/>(EAP ID Response, GPSI, S-NSSAI/ENSI)
    Note over AAA_S: AAA-S存储GPSI与EAP ID关联<br/>用于后续重认证/撤销
    end

    rect rgb(230, 255, 230)
    Note over UE,AAA_S: Step 7-14: EAP消息多轮交互
    loop EAP方法可能需要多轮交互
        AAA_S->>AAA_P: EAP-Request/Challenge
        AAA_P->>NSSAAF: EAP-Request/Challenge
        NSSAAF->>AMF: Nnssaaf_NSSAA_Authenticate Response<br/>(EAP-Request/Challenge)
        AMF->>UE: NAS MM Transport<br/>(EAP-Request/Challenge)
        UE->>AMF: NAS MM Transport<br/>(EAP-Response)
        AMF->>NSSAAF: Nnssaaf_NSSAA_Authenticate Request<br/>(EAP-Response, GPSI, S-NSSAI)
        NSSAAF->>AAA_P: AAA Protocol (EAP-Response)
        AAA_P->>AAA_S: AAA Protocol (EAP-Response)
    end
    end

    rect rgb(255, 230, 230)
    Note over UE,AAA_S: Step 15-18: 认证结果
    AAA_S->>AAA_P: EAP-Success/Failure<br/>(GPSI, S-NSSAI)
    AAA_P->>NSSAAF: AAA Protocol<br/>(EAP-Success/Failure, S-NSSAI, GPSI)
    NSSAAF->>AMF: Nnssaaf_NSSAA_Authenticate Response<br/>(EAP-Success/Failure, S-NSSAI, GPSI)
    AMF->>UE: NAS MM Transport<br/>(EAP-Success/Failure)
    Note over AMF: AMF存储NSSAA结果到UE Context
    end

    rect rgb(240, 240, 255)
    Note over UE,AMF: Step 19a: 更新Allowed NSSAI
    AMF->>UE: UE Configuration Update<br/>(新Allowed NSSAI包含该S-NSSAI)
    Note over UE,AMF: Step 19b: 若全部失败则执行Deregistration
    end

四、关键信令消息与IE详解

4.1 NAS MM Transport消息

NSSAA的EAP消息通过NAS MM Transport消息在UE和AMF之间传递。该消息类型专为NAS层透传上层协议数据设计。

IE名称 方向 说明
Payload Container Type 双向 值为"N1 SM information"或"SMS"等,NSSAA中使用特定值标识EAP容器
Payload Container 双向 携带EAP消息体(EAP-Request/Response/Success/Failure)
S-NSSAI AMF→UE 标识本次NSSAA针对的切片(使用HPLMN S-NSSAI,非本地映射值)
EAP Message 双向 RFC 3748定义的EAP消息结构

4.2 Nnssaaf_NSSAA_Authenticate SBI接口

根据TS 29.526 Section 5.2.2.2,NSSAAF暴露的SBI服务操作如下:

服务操作 HTTP方法 URI模式 请求参数 响应参数
Authenticate POST /nnssaaf-nssaa/v1/slice-authentications SliceAuthInfo SliceAuthContext
Authenticate(后续) PUT /nnssaaf-nssaa/v1/slice-authentications/{sliceAuthId}/confirm SliceAuthConfirmationData SliceAuthConfirmationResponse
Re-AuthenticationNotification POST AMF回调URI SliceAuthReauthNotification -
RevocationNotification POST AMF回调URI SliceAuthRevocNotification -

4.3 SliceAuthInfo数据结构

根据TS 29.526 Section 6.1.6.2.2:

字段名 类型 必选/可选 说明
EapId String (Binary) 首次必选 UE的EAP Identity(如NAI格式)
Gpsi String 必选 UE的外部标识符
SNssai Snssai 必选 需要NSSAA的切片标识
EapMessage String (Binary) 后续必选 后续EAP消息
graph LR
    subgraph "SliceAuthInfo (Request)"
        A[EapId<br/>EAP Identity] --> B[Gpsi<br/>GPSI]
        B --> C[SNssai<br/>S-NSSAI]
    end

    subgraph "SliceAuthContext (Response)"
        D[SliceAuthId<br/>会话标识]
        D --> E[EapMessage<br/>EAP消息]
    end

    subgraph "SliceAuthConfirmationData"
        F[EapMessage<br/>UE的EAP响应]
        F --> G[SliceAuthId<br/>会话标识]
    end

4.4 NSSAAF的路由逻辑

NSSAAF负责将EAP消息路由到正确的AAA-S。路由规则(TS 33.501 Section 16.3):

  1. 基于S-NSSAI路由:NSSAAF本地配置S-NSSAI到AAA-S地址的映射表
  2. ENSI映射:如果AAA-S属于第三方,NSSAAF可选将S-NSSAI映射为ENSI(External Network Slice Information),避免暴露3GPP内部切片标识
  3. AAA-P中继:如果AAA-S在运营商网络外部,NSSAAF通过AAA-P(AAA Proxy)中继

五、NSSAA状态管理与Pending NSSAI机制

5.1 状态转换图

stateDiagram-v2
    [*] --> Requested: UE注册请求<br/>包含S-NSSAI
    Requested --> Pending_NSSAI: AMF判定需要NSSAA<br/>放入Pending NSSAI
    Pending_NSSAI --> NSSAA_InProgress: AMF发送EAP Identity Request
    NSSAA_InProgress --> Allowed_NSSAI: NSSAA成功<br/>EAP-Success
    NSSAA_InProgress --> Rejected_NSSAI: NSSAA失败<br/>EAP-Failure
    Allowed_NSSAI --> NSSAA_InProgress: AAA-S触发重认证
    Allowed_NSSAI --> Rejected_NSSAI: AAA-S触发授权撤销
    Rejected_NSSAI --> NSSAA_InProgress: UE重新请求<br/>或订阅变更
    Pending_NSSAI --> Deregistered: 所有S-NSSAI的NSSAA<br/>全部失败

5.2 Pending NSSAI的特殊处理

当UE收到的Registration Accept中包含空Allowed NSSAI + Pending NSSAI时(TS 23.502 Section 4.2.2.2.1):

5.3 NSSAA结果在UE Context中的存储

AMF为每个S-NSSAI维护NSSAA状态(TS 29.526):

状态值 含义
SUCCESS NSSAA成功,S-NSSAI可加入Allowed NSSAI
FAILURE NSSAA失败,S-NSSAI加入Rejected NSSAI
ONGOING NSSAA进行中
NOT_PERFORMED 尚未执行NSSAA

注意(TS 23.502 Section 4.2.9.1 Note 2):如果S-NSSAI因NSAC(网络切片准入控制)被拒绝,不影响已存储的NSSAA结果状态。NSSAA成功≠切片一定可用,还需要通过容量准入。

六、AAA-S触发的重认证与授权撤销

6.1 重认证流程

AAA-S可在任何时候主动要求UE重新认证(TS 33.501 Section 16.4),这是NSSAA区别于主认证的重要特性——第三方企业可以在自己的策略下强制重认证。

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

    AAA_S->>NSSAAF: Re-Auth Request (GPSI, S-NSSAI)
    NSSAAF->>UDM: Nudm_UECM_Get (GPSI, AMF Registration)
    UDM->>NSSAAF: AMF ID
    NSSAAF-->>AAA_S: ACK
    NSSAAF->>AMF: Nnssaaf_NSSAA_Re-AuthenticationNotification<br/>(GPSI, S-NSSAI)
    Note over AMF: 检查S-NSSAI是否在Allowed NSSAI中
    AMF->>UE: 触发完整NSSAA流程<br/>(回到Section 16.3步骤)

关键步骤: 1. AAA-S发送Re-Auth Request,包含GPSI和S-NSSAI 2. NSSAAF通过UDM的Nudm_UECM_Get查询当前服务该UE的AMF 3. 如果UE在3GPP和非3GPP两个Access Type都注册了,NSSAAF可能收到两个AMF地址,需要决策通知哪一个 4. AMF收到通知后检查S-NSSAI是否在Allowed NSSAI中,是则触发完整NSSAA流程

6.2 授权撤销流程

授权撤销(TS 33.501 Section 16.5)比重认证更剧烈——直接从Allowed NSSAI中移除S-NSSAI:

撤销后的处理 条件
更新Allowed NSSAI(移除该S-NSSAI) 至少还有一个S-NSSAI在Allowed NSSAI中
加入Default NSSAI Allowed NSSAI变空但有Default NSSAI可用
执行Deregistration Allowed NSSAI变空且无Default NSSAI可用

如果被撤销的S-NSSAI上还有PDU Session,AMF会主动发起PDU Session Release。

七、与主认证的对比分析

对比维度 主认证 (5G-AKA/EAP-AKA') NSSAA
规范定义 TS 33.501 Section 6.1 TS 33.501 Section 16.3
信令流程 TS 23.502 Section 4.2.2.2 TS 23.502 Section 4.2.9.2
凭证来源 USIM (SUPI/K) 企业自有 (EAP ID/企业密钥)
认证服务器 AUSF/UDM (PLMN内) AAA-S (可第三方)
EAP角色 SEAF=Authenticator, AUSF=EAP Server AMF=Authenticator, AAA-S=EAP Server
协议中继 无需 (AUSF直连) NSSAAF+可选AAA-P
UE标识 SUCI/SUPI GPSI
触发时机 注册流程中(首要) 主认证成功后(次要)
密钥产出 KSEAF→NAS/AS密钥 无密钥产出(纯授权)
重认证 网络发起(AMF/AUSF) AAA-S发起
失败后果 注册被拒绝 S-NSSAI被拒绝,不影响其他切片

关键差异:NSSAA不产生密钥材料。它只是授权决策,不参与5G安全密钥层级。NSSAA的保护依赖已建立的NAS安全上下文——所有EAP消息都在NAS安全通道内传输。

八、抓包识别与排错实战

8.1 抓包特征

接口 协议 关键过滤条件
UE↔AMF (N1) NAS nas.mm.msg_type == 0x77(DL NAS Transport) 或 0x78(UL NAS Transport),Payload Container中含EAP
AMF↔NSSAAF HTTP/2 (SBI) POST /nnssaaf-nssaa/v1/slice-authentications
NSSAAF↔AAA-S RADIUS/Diameter 含S-NSSAI和GPSI的认证请求

8.2 常见故障场景

故障1:UE不支持NSSAA但请求了需要NSSAA的切片

现象:Registration Accept中该S-NSSAI出现在Rejected NSSAI中,而非Pending NSSAI。

根因:UE在UE 5GMM Core Network Capability中未声明NSSAA支持能力(TS 23.502 Section 4.2.2.2.1)。

故障2:NSSAA超时未完成

现象:UE收到空Allowed NSSAI和Pending NSSAI后一直等待,无法发起任何业务。

根因:AAA-S不可达或EAP交互超时。AMF会设置该S-NSSAI的NSSAA状态为NOT_PERFORMED(TS 33.501 Section 16.3 Step 15),下次注册时重新触发。

故障3:GPSI缺失

现象:AMF无法发起Nnssaaf_NSSAA_Authenticate Request。

根因:UDM订阅数据中未配置GPSI。NSSAA要求订阅至少包含一个GPSI(TS 23.502 Section 4.2.9.1)。

故障4:多Access Type场景下NSSAA重复执行

现象:UE在3GPP和非3GPP都注册时,同一S-NSSAI被执行了两次NSSAA。

根因:AMF未正确复用已有Access Type上的NSSAA结果。根据规范,AMF应基于网络策略跳过已成功的S-NSSAI的NSSAA。

九、NSSAA与NSSF的协作关系

NSSAA不是孤立运行的。在注册流程中,它与NSSF(Network Slice Selection Function)协作完成切片选择与授权的完整闭环:

 注册请求(Requested NSSAI)
       │
       ▼
  ┌─────────┐    N22    ┌──────┐
  │   AMF   │─────────▶│ NSSF │ ← 切片选择
  └────┬────┘           └──────┘
       │
       ▼
  检查订阅数据(UDM)
  哪些S-NSSAI需要NSSAA?
       │
       ├── 不需要NSSAA → 直接入Allowed NSSAI
       │
       └── 需要NSSAA → 放入Pending NSSAI
                         │
                         ▼
                   触发NSSAA流程
                   (AMF↔NSSAAF↔AAA-S)
                         │
               ┌─────────┼─────────┐
               ▼                   ▼
          NSSAA成功            NSSAA失败
          加入Allowed          加入Rejected
          NSSAI                NSSAI

NSSF负责的是切片选择(Allowed NSSAI中哪些S-NSSAI适合当前TA),而NSSAA负责的是切片级认证授权(UE是否有权接入该切片)。两者是互补关系,NSSF的选择结果可能因为NSSAA失败而被修正。

十、Rel-18增强要点

在Release 18中,NSSAA相关机制有以下增强:

  1. Partially Allowed NSSAI:支持在部分TAI区域内允许的切片,即使NSSAA已成功,切片也可能只在部分区域可用(TS 23.502 Section 4.2.2.2.1)

  2. NSAG(Network Slice AS Group):引入NSAG信息,优化NSSAA结果在RAN侧的应用

  3. Slice Usage Policy:AMF可下发切片使用策略,包括"按需切片"和"切片去注册不活动定时器"

  4. Alternative S-NSSAI:当NSSAA失败的S-NSSAI有替代切片时,AMF可自动替换

常见问题

Q1: NSSAA和主认证的EAP-AKA'有什么区别? A: 主认证的EAP-AKA'使用USIM上的3GPP凭证(SUPI/K),由PLMN内的AUSF/UDM执行,产生安全密钥。NSSAA使用企业自有凭证(如证书、用户名密码),由第三方AAA-S执行,不产生密钥材料。两者是完全独立的认证过程。

Q2: NSSAA失败后UE还能用其他切片吗? A: 可以。NSSAA是按S-NSSAI粒度执行的。某个S-NSSAI的NSSAA失败只影响该切片的接入,不影响其他已授权切片的使用。只有当所有S-NSSAI都因NSSAA失败(且无Default NSSAI)时,AMF才会执行Deregistration。

Q3: NSSAA使用什么EAP方法? A: 规范未强制特定EAP方法。实际部署中常见EAP-TLS(证书认证,适合物联网场景)和EAP-AKA(复用SIM卡凭证)。选择取决于AAA-S的能力和企业的安全策略。TS 33.501建议使用支持隐私保护的EAP方法。

Q4: UE在3GPP和非3GPP两个Access上都注册了,NSSAA需要执行两次吗? A: 不需要。AMF可基于UE Context判断某个S-NSSAI在另一个Access Type上已有成功的NSSAA记录,根据网络策略跳过重复执行(TS 23.502 Section 4.2.9.2 Step 1)。这是优化设计,避免不必要的认证交互。

Q5: AAA-S如何知道要重认证哪个UE? A: AAA-S在首次NSSAA成功时存储了GPSI与EAP Identity的关联。当需要重认证时,AAA-S使用GPSI标识UE,NSSAAF通过Nudm_UECM_Get(GPSI)查询UDM获取当前服务该UE的AMF地址,然后通知AMF触发重认证。

参考来源

  1. 3GPP TS 23.502 V18.x — Section 4.2.9 NSSAA信令流程定义
  2. 3GPP TS 33.501 V18.x — Section 16 安全架构与NSSAA EAP过程
  3. 3GPP TS 29.526 V17.x — NSSAAF SBI服务API定义
  4. 3GPP Network Slicing Security — 切片安全架构总览
  5. IETF RFC 3748 — EAP框架规范
  6. 博客园: 网络切片特定鉴权和授权过程 — 中文流程解读

本文由「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学通信知识星球海报-扫码加入