<!-- title: N3IWF与EAP-AKA'认证信令拆解 -->
<!-- domain: security -->

# 5G非可信WiFi接入N3IWF与EAP-AKA'认证信令拆解

## 1. 背景与问题定义

当5G UE通过公共WiFi热点等**非可信非3GPP接入网络**连接到5G核心网时，面临三个核心安全挑战：**身份暴露风险**、**中间人攻击风险**和**密钥隔离问题**。3GPP在TS 33.501中引入了**N3IWF（Non-3GPP InterWorking Function）**作为安全网关，通过**IKEv2 + EAP-AKA'**双重协议栈解决这些问题。

与3GPP接入直接使用5G-AKA不同，非可信非3GPP接入必须先建立IPsec隧道再承载NAS信令，这使得整个注册流程在信令层面呈现**四层嵌套**结构：IP → IKEv2 → EAP-AKA' → NAS。本文将逐层拆解这一复杂信令交互。

## 2. 架构总览与N3IWF定位

### 2.1 参考点与接口

N3IWF在5G架构中引入了三个新的参考点：

| 参考点 | 连接 | 协议 | 功能 |
|--------|------|------|------|
| **Yu** | UE ↔ N3IWF | IKEv2 / IPsec | 建立安全隧道，承载EAP-AKA'认证和NAS信令 |
| **N2** | N3IWF ↔ AMF | NGAP | 传递NAS消息和NAS消息，等同于gNB与AMF间的N2 |
| **N3** | N3IWF ↔ UPF | GTP-U | 用户面数据转发 |

```mermaid
graph TB
    subgraph "非可信非3GPP接入域"
        UE["UE<br/>(WiFi连接)"]
        WiFi["WiFi AP<br/>(非可信)"]
    end

    subgraph "安全边界"
        N3IWF["N3IWF<br/>EAP Authenticator<br/>IKEv2 Responder"]
    end

    subgraph "5G核心网"
        AMF["AMF<br/>SEAF角色"]
        AUSF["AUSF"]
        UDM["UDM/ARPF<br/>SIDF"]
        UPF["UPF"]
    end

    UE -->|"Yu: IKEv2/IPsec<br/>EAP-AKA'"| N3IWF
    N3IWF -->|"N2: NGAP"| AMF
    AMF -->|"Nausf: Auth"| AUSF
    AUSF -->|"Nudm: Auth Get"| UDM
    N3IWF -->|"N3: GTP-U"| UPF
    UE -.->|"WiFi"| WiFi

    style N3IWF fill:#ff6b6b,color:#fff
    style UE fill:#4ecdc4,color:#fff
    style AUSF fill:#ffe66d,color:#333
```

### 2.2 N3IWF的三重角色

N3IWF同时扮演三种角色，这是理解其信令交互的关键：

1. **IKEv2 Responder**：与UE建立IPsec安全关联，充当隧道终结点
2. **EAP Authenticator**：前端EAP认证器，将EAP消息通过N2转发给AMF/AUSF
3. **接入网节点模拟器**：向AMF暴露N2接口，行为类似gNB

> **设计意图**：N3IWF将非3GPP接入的安全处理与5G核心网隔离。即使WiFi网络被攻破，攻击者也无法获取5G NAS层的任何信息，因为所有NAS消息都封装在IPsec隧道内。

## 3. 完整信令时序图

以下是基于TS 23.502 Section 4.12.2.2和TS 33.501 Section 6.3.3的完整信令流程：

```mermaid
sequenceDiagram
    participant UE
    participant N3IWF
    participant AMF
    participant AUSF
    participant UDM

    Note over UE,N3IWF: Phase 1: IKE_SA_INIT
    UE->>N3IWF: IKE_SA_INIT Request<br/>SAi1, KEi, Ni
    N3IWF->>UE: IKE_SA_INIT Response<br/>SAr1, KEr, Nr, [Cookie]

    Note over UE,N3IWF: Phase 2: IKE_AUTH + EAP-AKA'
    UE->>N3IWF: IKE_AUTH Request<br/>IDi(SUCI@nai.epc...), SAi2, TSi, TSr
    N3IWF->>UE: IKE_AUTH Response<br/>EAP-Request/AKA'-Start<br/>AT_KDF_INPUT, AT_KDF

    UE->>N3IWF: IKE_AUTH Request<br/>EAP-Response/AKA'-Identity<br/>(SUCI)
    N3IWF->>AMF: N2 NAS Transport<br/>NAS: Registration Request + EAP-5G(ID)

    Note over AMF,UDM: Phase 3: 5G AKA via EAP-AKA'
    AMF->>AUSF: Nausf_UEAuthentication_Auth<br/>SUCI, SNN
    AUSF->>UDM: Nudm_UEAuthentication_Get<br/>SUCI, SNN
    UDM->>AUSF: 5G AV(RAND, AUTN, KAUSF, XRES*)
    AUSF->>AMF: RAND, AUTN, HXRES*
    AMF->>N3IWF: N2 NAS Transport<br/>EAP-Request/AKA'-Challenge<br/>AT_RAND, AT_AUTN, AT_MAC

    N3IWF->>UE: IKE_AUTH Response<br/>EAP-Request/AKA'-Challenge

    Note over UE: UE验证AUTN<br/>计算RES*<br/>派生CK', IK', MK, MSK
    UE->>N3IWF: IKE_AUTH Request<br/>EAP-Response/AKA'-Challenge<br/>AT_RES, AT_MAC

    N3IWF->>AMF: N2 NAS Transport<br/>EAP-Response/AKA'-Challenge
    AMF->>AUSF: Nausf_UEAuthentication_Auth<br/>RES*
    AUSF->>AMF: Auth Success + KSEAF
    AMF->>N3IWF: N2 NAS Transport<br/>EAP-Success + KSEAF
    N3IWF->>UE: IKE_AUTH Response<br/>EAP-Success

    Note over UE,N3IWF: Phase 4: IPsec Child SA + NAS Registration
    N3IWF->>UE: IKE_AUTH Response<br/>IDr, AUTH, SAr2, TSi, TSr<br/>(IPsec Child SA建立)
    UE->>N3IWF: NAS: Registration Complete<br/>(通过IPsec隧道)
    N3IWF->>AMF: N2 NAS Transport<br/>NAS: Registration Complete
    AMF->>N3IWF: N2 NAS Transport<br/>NAS: Registration Accept
    N3IWF->>UE: NAS: Registration Accept<br/>(通过IPsec隧道)
```

## 4. 逐阶段信令拆解

### 4.1 Phase 1: IKE_SA_INIT — 安全关联协商

IKE_SA_INIT阶段建立未认证的IKE SA，为后续EAP-AKA'提供加密传输通道。

**UE → N3IWF: IKE_SA_INIT Request**

| IE名称 | 说明 | 典型值 |
|--------|------|--------|
| SAi1 | 安全关联提案（加密/完整性/DH组） | ENCR-AES-CBC-256, AUTH-HMAC-SHA2-256, DH Group 14/19 |
| KEi | DH公共值 | 2048-bit MODP / 256-bit ECP |
| Ni | UE nonce | 16-256字节随机数 |

**N3IWF → UE: IKE_SA_INIT Response**

N3IWF选中一组算法并返回自己的DH值和nonce。可选返回Cookie用于DoS防护。

> **抓包识别**：IKE_SA_INIT消息的UDP端口为**500**（NAT-T后续切换到4500）。IKE SA建立后的所有IKE_AUTH消息通过该IKE SA加密，但**此时IKE SA尚未认证**——认证在Phase 2的EAP-AKA'中完成。

### 4.2 Phase 2: IKE_AUTH + EAP-AKA' — 认证核心

这是整个流程的核心，IKE_AUTH阶段内嵌EAP-AKA'方法实现UE与5G核心网的双向认证。

#### 4.2.1 UE发起IKE_AUTH

UE发送IKE_AUTH Request，携带以下关键信息：

| IE名称 | 说明 | 编码格式 |
|--------|------|----------|
| **IDi** | UE身份标识 | NAI格式：`suci@nai.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org` |
| **SAi2** | IPsec SA提案 | ESP隧道模式，AES-GCM-256或AES-CBC+HMAC-SHA2-256 |
| **TSi/TSr** | 流量选择器 | 通常为动态地址（0.0.0.0），后续由N3IWF分配 |
| **AUTH** | 认证数据 | **空**（使用EAP认证时AUTH省略） |

> **关键点**：当使用EAP方法时，IKE_AUTH Request中**不包含AUTH载荷**。这是RFC 7296的规定——EAP方法负责后续认证，IKE_AUTH最终由N3IWF在EAP-Success后发送AUTH完成双向认证。

#### 4.2.2 EAP-AKA'流程

N3IWF回复IKE_AUTH Response，内含**EAP-Request/AKA'-Start**消息，触发EAP-AKA'流程。

**EAP-Request/AKA'-Start关键属性（TS 33.501 Section 6.1.3.1）**：

| AT属性 | 用途 | 值 |
|--------|------|----|
| AT_KDF_INPUT | 网络名称（SNN），用于密钥绑定 | `"5G:mnc<MNC>.mcc<MCC>.3gppnetwork.org"` |
| AT_KDF | 密钥派生函数标识 | KDF=1 (HMAC-SHA-256) |

> **EAP-AKA'与EAP-AKA的根本区别**：EAP-AKA'通过AT_KDF_INPUT将密钥绑定到特定网络名称（SNN），实现**密钥分离**（Key Separation）。这意味着同一组CK/IK在不同网络中派生出的CK'/IK'完全不同，防止跨网络密钥重用攻击。

UE收到AKA'-Start后回复**EAP-Response/AKA'-Identity**，携带SUCI。N3IWF将SUCI通过N2接口转发给AMF。

#### 4.2.3 AKA' Challenge过程

AMF收到EAP-Identity后，触发5G AKA认证流程：

1. **AMF → AUSF**: `Nausf_UEAuthentication_Auth`，携带SUCI和SNN
2. **AUSF → UDM**: `Nudm_UEAuthentication_Get`，请求认证向量
3. **UDM/ARPF**: 生成5G AV，包含RAND、AUTN、KAUSF和XRES*

**UDM侧密钥派生（TS 33.501 Annex A.2）**：

```
CK || IK = KDF_K(RES || CK || IK)  -- 从USIM获取基础CK/IK
CK' || IK' = KDF(CK || IK, SNN)   -- 绑定网络名称
KAUSF = KDF(CK' || IK', SQN ⊕ AK) -- 绑定序列号
```

AUSF使用CK'和IK'计算EAP-AKA'的MK（Master Key）：

```
MK = PRF'(CK' || IK', <identity> || n)
MSK = MK[0..511]      -- 512-bit MSK，用于IPsec密钥
EMSK = MK[512..1023]  -- 512-bit EMSK，5G中不使用
```

AMF收到认证向量后，将RAND和AUTN通过EAP-Request/AKA'-Challenge发送给UE：

| AT属性 | 方向 | 说明 |
|--------|------|------|
| AT_RAND | Network → UE | 128-bit随机数，用于USIM卡计算 |
| AT_AUTN | Network → UE | 128-bit认证令牌，含SQN和AMF字段 |
| AT_MAC | Network → UE | 消息认证码，由MK派生的K_aut密钥计算 |

UE侧处理：
1. 将RAND和AUTN传递给USIM
2. USIM验证AUTN（检查MAC和SQN freshness）
3. USIM返回RES、CK、IK
4. UE执行与网络侧相同的CK'/IK'/MK/MSK派生
5. UE发送**EAP-Response/AKA'-Challenge**，包含AT_RES和AT_MAC

AMF将RES转发给AUSF验证。AUSF比对XRES*与RES*后返回认证结果和KSEAF：

```
KSEAF = KDF(KAUSF, SNN || SQN ⊕ AK)
```

### 4.3 Phase 3: IPsec Child SA建立

EAP认证成功后，N3IWF向UE发送最终的IKE_AUTH Response：

| IE名称 | 说明 |
|--------|------|
| **IDr** | N3IWF身份 |
| **AUTH** | N3IWF认证数据（基于MSK计算，证明N3IWF合法） |
| **SAr2** | IPsec ESP SA参数 |
| **TSi/TSr** | 流量选择器（N3IWF为UE分配的内网IP地址范围） |
| **CP(CFG_REPLY)** | UE内部IP地址、DNS服务器地址 |

> **关键设计**：IPsec Child SA的密钥由EAP-AKA'产生的MSK通过IKEv2密钥材料推演得出，而非独立协商。这确保了IPsec隧道的安全性与EAP-AKA'认证绑定。

### 4.4 Phase 4: NAS Registration

IPsec隧道建立后，NAS Registration Request在隧道内传输：

```
UE → IPsec隧道 → N3IWF → N2(NGAP) → AMF
```

NAS Registration流程与3GPP接入的Registration基本一致，但有以下差异：

| 差异点 | 3GPP接入 | 非可信非3GPP接入 |
|--------|----------|-----------------|
| 接入类型 | 3GPP | Non-3GPP |
| NAS传输通道 | RRC + NGAP | IPsec + N2(NGAP) |
| 安全模式激活 | NAS SMC in 5G-AKA | 已在EAP-AKA'中完成 |
| AMF选择 | gNB基于GUAMI路由 | N3IWF基于SUCI中的PLMN选择 |
| TAI管理 | gNB广播TAI | N3IWF配置虚拟TAI |

## 5. 密钥层级推演

非可信非3GPP接入的密钥层级是理解整个安全架构的核心。以下是基于TS 33.501 Section 6.2的完整密钥派生链：

```mermaid
graph TD
    K["K<br/>永久密钥<br/>(USIM/UDM)"]
    K -->|"f1-f5算法<br/>+ RAND"| AV["5G AV<br/>CK, IK, AUTN<br/>RAND, XRES*"]
    AV --> CKIK["CK || IK"]
    CKIK -->|"KDF(CK‖IK, SNN)"| CKP_IKP["CK' || IK'<br/>绑定SNN"]
    CKP_IKP -->|"KDF(CK'‖IK',<br/>SQN⊕AK)"| KAUSF["KAUSF"]
    KAUSF -->|"KDF(KAUSF,<br/>SNN‖SQN⊕AK)"| KSEAF["KSEAF"]
    KAUSF -->|"MK = PRF'(CK'‖IK',...)"| MK["MK<br/>EAP-AKA'<br/>Master Key"]
    MK --> MSK["MSK (512-bit)<br/>→ IPsec密钥"]
    MK --> EMSK["EMSK (512-bit)<br/>5G未使用"]
    KSEAF -->|"KDF(KSEAF,<br/>SUPI‖ABBA)"| KAMF["KAMF<br/>NAS根密钥"]
    KAMF --> KNAS_INT["KNAS_int<br/>NAS完整性密钥"]
    KAMF --> KNAS_ENC["KNAS_enc<br/>NAS加密密钥"]
    MSK -->|"IKEv2 PRF+"| IPsec_KEYS["IPsec ESP SA密钥<br/>SK_e(入/出)<br/>SK_a(入/出)"]

    style K fill:#e74c3c,color:#fff
    style KAUSF fill:#f39c12,color:#fff
    style KSEAF fill:#2ecc71,color:#fff
    style KAMF fill:#3498db,color:#fff
    style MSK fill:#9b59b6,color:#fff
```

### 密钥层级关键参数表

| 密钥 | 派生位置 | 输入参数 | 用途 | 长度 |
|------|----------|----------|------|------|
| CK'/IK' | UE + UDM | CK, IK, SNN | 密钥分离，绑定网络名称 | 各128-bit |
| KAUSF | UE + AUSF | CK', IK', SQN⊕AK | AUSF级别密钥 | 256-bit |
| KSEAF | AUSF → AMF | KAUSF, SNN, SQN⊕AK | SEAF/AMF级别锚定密钥 | 256-bit |
| MK | UE + AUSF | CK', IK', Identity, n | EAP-AKA'主密钥 | 256-bit |
| MSK | UE + AUSF | 从MK截取 | IPsec SA密钥材料 | 512-bit |
| KAMF | AMF + UE | KSEAF, SUPI, ABBA | NAS层根密钥 | 256-bit |

## 6. EAP-AKA' vs EAP-AKA vs 5G-AKA对比

| 特性 | 5G-AKA | EAP-AKA | EAP-AKA' |
|------|--------|---------|----------|
| **规范** | TS 33.501 Sec 6.1.1 | RFC 4187 | RFC 9048 |
| **适用接入** | 3GPP接入 | 4G非3GPP | 5G非3GPP |
| **EAP框架** | 否（直接NAS） | 是 | 是 |
| **密钥分离** | SNN绑定 | 无 | SNN绑定（AT_KDF_INPUT） |
| **KDF** | TS 33.501 Annex A | 无额外KDF | HMAC-SHA-256 (KDF=1) |
| **身份保护** | SUCI (ECIES) | IMPI明文 | SUCI (NAI格式) |
| **密钥输出** | KSEAF | MSK,EMSK | MSK,EMSK |
| **隐私保护** | 是（SUCI） | 否 | 是（SUCI） |
| **重放保护** | SQN + AUTN | SQN + AUTN | SQN + AUTN |

> **核心差异**：EAP-AKA'通过AT_KDF_INPUT属性引入SNN绑定，使CK/IK → CK'/IK'的派生与特定PLMN绑定。攻击者即使获取了CK/IK也无法在不同PLMN中伪造密钥。

## 7. EAP-5G容器机制

在IKEv2隧道内，N3IWF使用**EAP-5G**（TS 24.302 Section 7.2.3）作为NAS消息的封装协议，这是一个容易被忽视但至关重要的中间层：

```mermaid
graph TD
    subgraph "IKE_AUTH载荷"
        EAP5G["EAP-5G<br/>Type=55<br/>Vendor-Id=3GPP"]
        subgraph "EAP-5G PDU"
            ANQP["AN-Parameters<br/>(接入网参数)"]
            NAS_PDU["NAS PDU<br/>(Registration Request等)"]
        end
        EAP5G --> ANQP
        EAP5G --> NAS_PDU
    end

    subgraph "最终封装"
        UDP["UDP 500/4500"]
        IKE["IKEv2 HDR"]
        ENC["SK{IKE_AUTH}"]
        UDP --> IKE --> ENC --> EAP5G
    end
```

EAP-5G消息格式：

| 字段 | 长度 | 说明 |
|------|------|------|
| Code | 1字节 | Request(1) / Response(2) |
| Identifier | 1字节 | 匹配Request/Response |
| Length | 2字节 | EAP消息总长度 |
| Type | 1字节 | 55 (EAP-5G Vendor-Specific) |
| Vendor-Id | 4字节 | 3GPP (10415) |
| Vendor-Type | 4字节 | 3 (EAP-5G) |
| AN-Parameters | 可变 | 接入网参数（如PLMN ID、NID） |
| NAS PDU | 可变 | 完整的NAS消息 |

> **注意**：EAP-5G仅用于在IKEv2隧道内传输NAS消息，与EAP-AKA'是**两个独立的EAP方法**。EAP-AKA'负责认证，EAP-5G负责NAS消息封装。

## 8. 抓包识别与故障排查

### 8.1 Wireshark过滤技巧

```
# IKEv2协商阶段
udp.port == 500 || udp.port == 4500

# 过滤IKE_SA_INIT
ikev2 && ikev2.exchange_type == 34

# 过滤IKE_AUTH（含EAP-AKA'）
ikev2 && ikev2.exchange_type == 35

# 过滤EAP-AKA'消息
eap.type == 55 && eap.subtype == 1   # AKA'-Start
eap.type == 55 && eap.subtype == 2   # AKA'-Challenge

# N2接口（NGAP）
ngap && ngap.procedureCode == 44      # UplinkNASTransport
```

### 8.2 常见故障点

| 故障阶段 | 现象 | 可能原因 | 排查方法 |
|----------|------|----------|----------|
| IKE_SA_INIT | 无响应 | N3IWF不可达或端口被阻断 | `ping N3IWF_IP`，检查防火墙UDP 500/4500 |
| IKE_SA_INIT | NO_PROPOSAL_CHOSEN | 算法不匹配 | 检查UE和N3IWF的IKE/IPsec算法配置 |
| EAP-AKA' Identity | 超时 | AMF不可达 | 检查N3IWF与AMF的N2 SCTP连接 |
| AKA'-Challenge | USIM拒绝AUTN | SQN不同步 | 检查UDM侧SQN状态，触发USIM重新同步 |
| AKA'-Challenge | RES验证失败 | 密钥不匹配 | 检查USIM与UDM的K/OPc配置 |
| IPsec Child SA | 创建失败 | 密钥推演异常 | 抓包比较两侧MSK是否一致 |
| NAS Registration | 拒绝(5)#PLMN_NOT_ALLOWED | PLMN限制 | 检查N3IWF配置的PLMN ID |
## 9. 安全分析

### 9.1 为什么非3GPP接入需要EAP-AKA'而非5G-AKA？

这涉及协议设计的深层考量：

1. **协议栈兼容性**：非3GPP接入通过IKEv2建立隧道，IKEv2原生支持EAP框架，因此认证必须采用EAP方法
2. **密钥分离**：EAP-AKA'通过AT_KDF_INPUT确保5G密钥与4G EAP-AKA密钥完全隔离
3. **双向认证保证**：EAP-AKA'在IKEv2框架内运行，N3IWF最终通过AUTH载荷证明自己拥有MSK，实现网络侧认证

### 9.2 隧道嵌套安全模型

```
┌─────────────────────────────────────┐
│         IPsec ESP Tunnel            │ ← MSK派生密钥保护
│  ┌───────────────────────────────┐  │
│  │     NAS Registration          │  │ ← KAMF派生密钥保护
│  ┌───────────────────────────────┐  │
│  │     PDU Session User Data     │  │ ← UPF N3隧道保护
│  └───────────────────────────────┘  │
└─────────────────────────────────────┘
```

这种嵌套模型确保：即使WiFi接入点被攻击者控制，IPsec隧道也能保护NAS信令和用户数据的机密性与完整性。

## 10. 状态转换图

UE在非可信非3GPP接入注册过程中经历以下状态转换：

```mermaid
stateDiagram-v2
    [*] --> WiFi_Connected: WiFi关联成功
    WiFi_Connected --> IKE_SA_Init: 发起IKE_SA_INIT
    IKE_SA_Init --> IKE_SA_Established: IKE SA建立成功
    IKE_SA_Established --> EAP_AKA_Start: 发送IKE_AUTH(IDi)
    EAP_AKA_Start --> EAP_AKA_Identity: 收到AKA'-Start
    EAP_AKA_Identity --> EAP_AKA_Challenge: 发送Identity
    EAP_AKA_Challenge --> EAP_AKA_Verifying: 收到Challenge
    EAP_AKA_Verifying --> EAP_Success: USIM验证AUTN成功
    EAP_AKA_Verifying --> EAP_Failure: AUTN验证失败
    EAP_Success --> IPsec_Child_SA: 收到EAP-Success+AUTH
    IPsec_Child_SA --> NAS_Registration: Child SA建立
    NAS_Registration --> Registered: Registration Accept
    Registered --> [*]: 注册完成
    
    EAP_Failure --> [*]: 认证失败
    IKE_SA_Init --> [*]: IKE超时
```

## 常见问题

**Q1: EAP-AKA'和EAP-AKA的核心区别是什么？**

A: 核心区别在于**密钥分离**。EAP-AKA直接使用CK/IK，而EAP-AKA'通过AT_KDF_INPUT引入SNN（Serving Network Name），将CK/IK经过额外KDF推导为CK'/IK'，使密钥与特定PLMN绑定。这防止了一个PLMN的密钥被用来伪造另一个PLMN的身份。此外，EAP-AKA'使用HMAC-SHA-256作为KDF（AT_KDF=1），而EAP-AKA不涉及额外KDF。

**Q2: 为什么IKE_SA_INIT后还需要EAP-AKA'？IKEv2本身不够安全吗？**

A: IKE_SA_INIT仅建立了**未认证**的IKE SA——Diffie-Hellman交换提供了前向安全性，但没有验证对端身份。EAP-AKA'通过与USIM/AUSF交互完成**双向认证**：网络验证UE（通过RES*），UE验证网络（通过AUTN中的MAC和SQN）。此外，EAP-AKA'产生的MSK作为IKEv2的认证密钥材料，使N3IWF能通过AUTH载荷证明自己确实与5G核心网通信。

**Q3: N3IWF如何选择AMF？它没有gNB那样的NG Setup过程。**

A: N3IWF在收到UE的SUCI后，从NAI中解析出PLMN ID（MCC/MNC），然后通过**NRF发现**或本地配置选择该PLMN的AMF。不同于gNB通过NG Setup建立与AMF的SCTP关联，N3IWF通常按需建立N2连接。部分实现中N3IWF会预先与一组AMF建立SCTP连接池。

**Q4: 通过N3IWF注册的UE能否同时通过gNB注册？**

A: 可以，这就是5G的**多接入（Multi-Access）**场景。TS 23.501允许UE通过3GPP和非3GPP接入同时注册到同一个PLMN，AMF通过注册类型和接入类型区分两个注册实例。3GPP Rel-16引入的**ATSSS（Access Traffic Steering, Switching and Splitting）**进一步支持两个接入间的流量聚合和分流。

**Q5: 非可信和可信非3GPP接入在认证机制上有何不同？**

A: 非可信接入（如公共WiFi）使用N3IWF，必须建立IKEv2+IPsec隧道，认证方法为EAP-AKA'。可信接入（如运营商WiFi）使用TNGF，UE与TNGF之间通过EAP-5G直接传输NAS消息，认证方法同样是EAP-AKA'，但不需要IKEv2/IPsec层——因为接入网络本身被认为是安全的。此外，可信接入还支持EAP-TLS认证（用于NPN场景）。

## 参考来源

1. [3GPP TS 33.501 V18.x.x](https://www.3gpp.org/DynaReport/33501.htm) — Section 6.3.3 (EAP-AKA' for non-3GPP access), Section 6.2 (Key hierarchy), Annex A (KDF specifications)
2. [3GPP TS 23.502 V18.x.x](https://www.3gpp.org/DynaReport/23502.htm) — Section 4.12.2.2 (Registration via untrusted non-3GPP access)
3. [RFC 9048](https://www.rfc-editor.org/rfc/rfc9048) — Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')
4. [EAP AKA Prime Explained — P1 Security](https://www.p1sec.com/blog/eap-aka-prime-what-aka-changes-and-why-it-matters-in-mobile-network-security) — AKA' vs EAP-AKA对比分析
5. [N3IWF DeepWiki — free5GC](https://deepwiki.com/free5gc/free5gc/6.1-n3iwf-(non-3gpp-interworking-function)) — free5GC N3IWF开源实现分析

---
> 本文由「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学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)