非可信非3GPP接入安全建立全链拆解：IKEv2、EAP-5G 与 K_N3IWF 锚定

一、为什么非3GPP接入需要一套独立的安全建立机制

3GPP 从 Rel-15 起在 5G 系统中引入了"非可信非3GPP接入（Untrusted Non-3GPP Access）"，允许 UE 通过运营商不可控的接入网（典型如公网 Wi-Fi 热点、家庭宽带）接入 5GC。与 3GPP 接入不同，这段接入链路不在运营商的安全域内：中间链路可被嗅探、AP 可被伪造、流量可被重放或篡改。因此 5G 不能依赖空口（PDCP/NAS）那套由 gNB 与 AMF 共同维持的密钥体系，而必须在 UE 与一个"可信锚点"之间重新建立一条端到端加密隧道，把 UE 的注册信令与用户面流量整体"灌进"隧道里，再交给 5GC。

这个可信锚点就是 N3IWF（Non-3GPP InterWorking Function），其安全架构由 TS 33.501 Section 8 规定。整条安全链可以一句话概括：

UE 与 N3IWF 之间用 IKEv2/IPSec 建立 ESP 隧道；在 IKEv2 的 IKE_AUTH 阶段，用自定义的 EAP-5G 方法把 5G NAS 注册信令"搭载"进去，完成 5G 主认证；主认证成功后由 AMF 从 K_AMF 派生出 K_N3IWF 并下发 N3IWF，作为 IKEv2 的 MSK 锚定整条 IPSec 隧道。

本文严格按 TS 33.501 §8 / §6.1.3.3、TS 24.502 Annex A、TS 23.502 §4.12.2、RFC 7296 逐消息拆解这条链路。

二、N3IWF 的架构定位与接口

flowchart TD
    subgraph Untrusted["非可信非3GPP接入域（公网/Wi-Fi）"]
        UE[UE]
    end
    subgraph Trust["运营商可信域（5GC + N3IWF）"]
        N3IWF[N3IWF<br/>IPSec/IKEv2终结点]
        AMF[AMF]
        UPF[UPF]
        UDM[AUSF/UDM]
    end
    UE -- "外层IP + IPSec ESP隧道" --> N3IWF
    UE -. "内层IP(N1 NAS / N3 UP)" .-> N3IWF
    N3IWF -- "N2 (NGAP)" --> AMF
    N3IWF -- "N3 (GTP-U)" --> UPF
    AMF -- "服务化接口" --> UDM

TS 23.501 §5.2.5 对 N3IWF 的功能定义可归纳为四点：① 与 UE 建立 IPSec 隧道；② 终结 IKEv2 并作为 EAP 认证器（但不解析 NAS 语义，只做透传）；③ 通过 N2 向 AMF 转发 NAS（扮演 gNB 的 N2 角色）；④ 通过 N3 把用户面 GTP-U 送到 UPF。理解这一点很关键：N3IWF 对 5GC 而言是一个"特殊的 gNB"，对 UE 而言是一个"IPSec 安全网关"。

三、完整信令时序图（IKE_SA_INIT → IKE_AUTH/EAP-5G → IPSec SA）

下图严格对应 TS 23.502 §4.12.2 的"经非可信非3GPP接入的注册"流程，叠加 TS 24.502 Annex A 的 EAP-5G 消息交互与 TS 33.501 的密钥派生节点：

sequenceDiagram
    autonumber
    participant UE
    participant N3IWF
    participant AMF
    participant AUSF as AUSF/UDM

    Note over UE,N3IWF: 阶段A：IKE_SA_INIT（建立预安全通道）
    UE->>N3IWF: IKE_SA_INIT(SAi1提案, KEi=DH公钥, Ni=nonce)
    N3IWF->>UE: IKE_SA_INIT(SAr1选中提案, KEr, Nr)
    Note right of N3IWF: 双方由 DH+Ni/Nr 算出 SKEYSEED<br/>派生 SK_e/SK_a/SK_i 保护后续 IKE_AUTH

    Note over UE,N3IWF: 阶段B：IKE_AUTH + EAP-5G（承载5G注册与主认证）
    UE->>N3IWF: IKE_AUTH(IDi, SAi2/ESP提案, TSi, TSr)（无AUTH）
    N3IWF->>UE: IKE_AUTH(EAP-Request/5G-Start)
    UE->>N3IWF: EAP-Response/5G-NAS-Stream(AN-Parameters: PLMN, NSSAI…)
    Note right of N3IWF: N3IWF依据AN-Parameters选择AMF
    N3IWF->>AMF: N2 Initial UE Message（含首条NAS注册请求封装）
    UE->>N3IWF: EAP-Response/5G-NAS-Stream(NAS: Registration Request)
    N3IWF->>AMF: 转发 NAS Registration Request

    rect rgb(235, 248, 245)
    AMF->>AUSF: 调用鉴权服务
    AUSF->>AMF: 鉴权向量(AV)
    AMF->>UE: EAP-Request/5G-NAS-Stream(NAS: Auth Request)
    UE->>AMF: EAP-Response/5G-NAS-Stream(NAS: Auth Response)
    Note over UE,AUSF: 5G-AKA 或 EAP-AKA' 主认证成功<br/>双方得到 K_AUSF→K_SEAF→K_AMF
    end

    Note over UE,N3IWF: 阶段C：K_N3IWF 锚定与 IPSec SA 建立
    AMF->>N3IWF: N2 下发 K_N3IWF（=KDF(K_AMF)，受NDS/IP保护）
    Note right of N3IWF: K_N3IWF 作为 IKEv2 MSK<br/>验证UE侧AUTH，派生ESP密钥
    AMF->>UE: EAP-Request/5G-NAS-Stream(NAS: Registration Accept)
    N3IWF->>UE: IKE_AUTH(自身AUTH) + EAP-Success
    Note right of N3IWF: IKE SA 与首条 Child SA(ESP) 建立<br/>UE获得内层IP
    UE->>N3IWF: IKEv2 AUTH(基于MSK) 完成互认证
    N3IWF->>N3IWF: 协商后续 Child SA（信令SA + 用户面SA）

四、IKEv2 建立过程逐步拆解

4.1 IKE_SA_INIT：先建一条"临时加密管道"

IKE_SA_INIT 的作用不是认证 UE，而是先协商出一套密码学算法与 Diffie-Hellman 共享密，把后续 IKE_AUTH 报文加密起来。这一步完全不需要任何 5G 凭证，因为双方此时都还没有共享密钥。其核心 IE 如下：

完成后双方各自计算出 SKEYSEED = prf(Ni ‖ Nr, g^ir)，并进一步派生 SK_d / SK_ai / SK_ar / SK_ei / SK_er / SK_pi / SK_pr，其中 SK_e*/SK_a* 用于加解密与完整性保护 IKE_AUTH 报文。注意：这一阶段没有任何 UE 身份信息，SUPI/SUCI 都还没有出现——这是 RFC 7296 的标准做法，目的是让身份在加密后才发送。

4.2 IKE_AUTH：身份 + EAP-5G 的核心战场

进入 IKE_AUTH 后，所有报文已被 SK_e/SK_a 加密与完整性保护。UE 发出的第一个 IKE_AUTH 不带 AUTH 载荷（因为 EAP 模式下发起方的 AUTH 要等 EAP 成功后再算），而是携带 ESP 子 SA 提案 SAi2、流量选择器 TSi/TSr 和身份 IDi。随后进入 EAP-5G 的交互循环。

EAP-5G 不是通用 EAP 方法，而是 3GPP 专门为 5G 设计的"传输容器"，其唯一职责是把 5G NAS 消息和 AN-Parameters 封装进 EAP 报文，让 N3IWF 透明转发给 AMF，从而复用 5G 的注册与主认证流程。

五、EAP-5G 消息格式拆解（TS 24.502 Annex A）

5.1 帧结构与 IE 说明

flowchart TB
    EAP["EAP报文<br/>Code(1) + Identifier(1) + Length(2)<br/>Type = EAP-5G(1) + Type-Data"]
    EAP --> E5G["EAP-5G 报文 Type-Data"]
    E5G --> HDR["EAP-5G 头部（1 octet）<br/>含 message segregation 指示位"]
    E5G --> STR["5G-NAS-Stream（变长）<br/>Length(1~2 octet) + 净荷"]
    STR --> AN["AN-Parameters 净荷<br/>(GUAMI/PLMN/NSSAI/Cause…)"]
    STR --> NAS["5G NAS 消息净荷<br/>(Registration/Auth Request…)"]

5.2 两类核心 EAP-5G 消息与 AN-Parameters

UE 向 N3IWF 发出的 EAP-5G 携带的 AN-Parameters（接入网参数）是 N3IWF 选择 AMF 的依据，典型包含：

5.3 分片与重组：NAS 消息如何塞进 EAP

一条完整的 5G NAS 注册请求可能远大于单个 EAP-5G 报文的承载上限。TS 24.502 Annex A 规定了分片机制：当 NAS 消息超长时，UE 将其拆分为多个 EAP-Response/5G-NAS-Stream，由 N3IWF 侧按序重组为完整 NAS 消息后再通过 N2 转发。这意味着在抓包里你会看到多个连续的、Identifier 递增的 EAP-Response 报文，它们拼接起来才是一条完整的 Registration Request——这是排错时极易误判的点。

六、K_N3IWF 密钥派生与整条 IPSec 的锚定

6.1 从 K 到 K_N3IWF 的完整密钥层级

flowchart TD
    K["K (USIM/UDM 永久密钥)"] --> AKA["5G-AKA / EAP-AKA'<br/>产出 CK, IK 或 CK', IK'"]
    AKA --> KAUSF["K_AUSF<br/>(AUSF 派生, TS33.501 §6.1.1.3)"]
    KAUSF --> KSEAF["K_SEAF<br/>(SEAF/AMF 派生, §6.1.1.4)"]
    KSEAF --> KAMF["K_AMF<br/>(AMF 派生, §6.1.1.5)"]
    KAMF --> KN3IWF["K_N3IWF<br/>(AMF 派生, §6.1.3.3 / Annex A.7)"]
    KN3IWF --> MSK["→ 作为 IKEv2 MSK"]
    MSK --> IKEKEY["IKE SA 密钥 + ESP Child SA 密钥"]
    KAMF -. "用于NAS(经N3IWF转发)层安全" .-> NASK["K_NAS_int / K_NAS_enc"]

6.2 K_N3IWF 的派生与下发

主认证（5G-AKA 或 EAP-AKA'）成功后，UE 与 AMF 共享 K_AMF。AMF 调用 KDF 从 K_AMF 派生 K_N3IWF（见 TS 33.501 §6.1.3.3 与 Annex A.7，派生输入包含访问类型标识），UE 侧也用相同的 K_AMF 独立派生出相同的 K_N3IWF。关键设计要点：

1. K_N3IWF 永远不出现在非可信接入链路上：AMF 通过 N2 接口在运营商可信域内（受 NDS/IP 网络域安全保护）把 K_N3IWF 下发给 N3IWF；UE 侧本地派生。攻击者即使在 Wi-Fi 段嗅探全部 IKEv2/EAP-5G 报文，也无法获得 K_N3IWF。
2. K_N3IWF = IKEv2 MSK：IKEv2 在 EAP 成功后，把 K_N3IWF 当作 EAP MSK，用于验证发起方 AUTH 并派生 IKE SA、ESP Child SA 的加密/完整性密钥。于是整条 IPSec 隧道的强度被锚定到 5G 主认证的成功与否——主认证失败就根本没有 MSK，N3IWF 无法算出 AUTH，隧道无法建立。
3. 访问类型隔离：K_N3IWF 与 3GPP 接入的 K_gNB 来自同一 K_AMF 但经不同 KDF 分支派生，互不通用，保证一把密钥泄漏不会跨接入扩散。

6.3 双层 IP 与 Child SA 的分工

IPSec 隧道建立后存在两层 IP：外层 IP 是 UE↔N3IWF 在 Wi-Fi 上的物理可达地址；内层 IP 由 N3IWF 分配给 UE，用于区分信令面与用户面。两条 ESP Child SA 分别承担：信令 SA 承载 UE→AMF 的 N1 NAS（N3IWF 转 N2），用户面 SA 承载 UE→UPF 的 N3 业务流量（N3IWF 转 GTP-U）。后续 PDU 会话建立就在这条内层隧道内完成。

七、抓包识别与实战排错

如何用 Wireshark/tshark 识别这个流程：

1. 过滤 isakmp（IKEv2）或 udp.port==500/4500，应看到完整的 IKE_SA_INIT 双向一对、随后多条 IKE_AUTH（被加密，payload 显示为 ENC）。
2. EAP-5G 报文在 IKE_AUTH 解密后可见 eap.code==2 (Response) 且 eap.type==EAP-5G，多条 Response 的 Identifier 递增且 payload 为 5G-NAS-Stream，正负交替出现 Request/Response。
3. NAS 注册与鉴权消息被"嵌套"在 EAP-5G 内，需对 IKE_AUTH 解密后才能看到 Registration Request / Authentication Request。

常见故障点与排错思路：

八、与其他方案的对比

九、常见问题

Q1：为什么 N3IWF 不直接用 EAP-AKA'，而要再发明一个 EAP-5G？ A：EAP-AKA' 是真正的认证方法，产出密钥；而 EAP-5G 本质是个"传输容器"，不含任何认证逻辑，只负责把 5G NAS 注册信令封装进 EAP。5G 主认证（5G-AKA 或 EAP-AKA'）是作为 NAS 消息"内嵌"在 EAP-5G 流里完成的。这样设计是为了让非3GPP 接入能完整复用 5G 注册、切片选择、二次认证等所有 NAS 层流程，而无需为每种接入单独定义一套。

Q2：K_N3IWF 和 K_gNB 能不能通用？ A：不能。二者都源自 K_AMF，但经不同 KDF 分支派生（访问类型标识不同），属不同的密钥域。这种隔离保证非3GPP 隧道密钥泄漏不会危及 3GPP 空口，反之亦然，符合 TS 33.501 的密钥域分离原则。

Q3：IKE_SA_INIT 阶段没有任何 5G 身份，会不会泄露 UE？ A：不会暴露 SUPI/SUCI。IKE_SA_INIT 仅含算法提案、DH 公钥与 nonce，不含 UE 身份；UE 身份（Registration Request 中的 SUCI）是在 IKE_AUTH 被加密后才发送的，符合 RFC 7296 的身份保护原则。

Q4：N3IWF 为什么要参与选 AMF？它不就是个隧道网关吗？ A：N3IWF 需要根据 UE 通过 AN-Parameters 上报的 Selected PLMN、Requested NSSAI 来选择合适的 AMF（类似 gNB 的 AMF 选择），因为非3GPP 接入下没有 RRC 层的 NAS 路由，这些切片/PLMN 信息只能靠 EAP-5G 的 AN-Parameters 上送。

Q5：抓包看到一堆 EAP-Response/5G-NAS-Stream 是不是异常重传？ A：通常不是。由于 5G NAS 消息（尤其带鉴权信息的注册请求）较长，会按 TS 24.502 Annex A 分片为多个 EAP-5G 报文，Identifier 递增、序号连续。若 Identifier 跳变或缺失，才是真正的丢包/重组失败。

参考来源

1. 3GPP TS 33.501 (V19) — Security architecture and procedures for 5G system — Section 8（非可信非3GPP接入安全）、§6.1.3.3 与 Annex A.7（K_N3IWF 派生）
2. 3GPP TS 24.502 (ETSI TS 124 502) — Access to the 5GCN via non-3GPP access networks — Annex A（EAP-5G 消息格式、5G-NAS-Stream、分片重组）
3. 3GPP TS 23.502 (V19) — Procedures for the 5G System — Section 4.12.2（经非可信非3GPP接入的注册流程）
4. 3GPP TS 23.501 (V19) — System architecture for the 5G System — Section 5.2.5（N3IWF 功能定义）
5. IETF RFC 7296 — Internet Key Exchange Protocol Version 2 (IKEv2) — IKE_SA_INIT / IKE_AUTH / EAP 扩展与 AUTH 计算
6. ETSI TS 133 520 — Security Assurance Specification (SCAS) for N3IWF — N3IWF 安全保证测试用例，佐证密钥下发与隧道建立要求
7. free5GC N3IWF / IKE Security and EAP-5G AN-Parameters（DeepWiki） — 开源实现层面印证 EAP-5G 承载 AN-Parameters 与 NAS 的机制

本文由「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 等场景全覆盖。