# 5G非3GPP接入N3IWF安全机制拆解：从IKEv2隧道到EAP-5G/EAP-AKA'双EAP嵌套认证全链解析 ## 一、为什么需要单独拆解非3GPP接入安全 5G核心网（5GC）相对4G EPC最被低估的架构跃迁之一，是**用一套统一的注册与安全框架同时容纳3GPP接入（NG-RAN）与非3GPP接入（Wi-Fi、固定宽带等）**。在3GPP接入侧，空口安全由RRC/PDCP层的AS安全（加密+完整性）和NAS安全共同保证；但当UE通过一个**运营商不可控、可能位于任意家庭/企业公网、且物理上可被嗅探与中间人攻击的Wi-Fi网络**接入5GC时，整个空口安全模型就失效了——因为根本没有"空口"可言。 3GPP给出的解法是：在UE与5GC之间强制塞入一个**安全网关N3IWF（Non-3GPP InterWorking Function）**，由它在不可信的IP网络上以**双层IPsec隧道**重建一条"可信信道"，并把N3IWF在N2接口上伪装成一个"伪gNB"，使AMF几乎无需改动即可同时服务两类接入。本文严格依据 **TS 33.501 Clause 6.x/7.3、TS 23.502 Section 4.12.2.2、TS 24.502**，把这条安全链从DNS选网、IKEv2握手、EAP-5G承载、EAP-AKA'主认证、KDF密钥推演到用户面IPsec CHILD_SA的每一步拆开。 ## 二、参考架构与关键网元 在TS 23.501的"非漫游、含不可信非3GPP接入"参考模型中，相比纯3GPP架构新增了如下要素： | 网元/参考点 | 全称 | 在非3GPP安全链中的职责 | |------------|------|----------------------| | **N3IWF** | Non-3GPP InterWorking Function | 终结UE侧IPsec/IKEv2隧道；以"伪gNB"身份对接AMF的N2；以GTP-U对接UPF的N3；充当非3GPP接入的**安全网关** | | **NWu** | UE ↔ N3IWF | 承载IKEv2/IPsec（外层信令隧道 + 内层NAS/UP隧道），是整个安全设计的核心参考点 | | **Y1** | UE ↔ N3IWF选择 | DNS-based的N3IWF发现 | | **AMF** | — | 同时管理3GPP与非3GPP两套注册/安全上下文，从K_AMF分别派生K_gNB与K_N3IWF | | **AUSF/UDM** | — | 执行主认证；对非3GPP接入强制使用 **EAP-AKA'** | 一个常被忽视的设计意图：N3IWF在N2上使用的是**与gNB完全相同的NGAP信令**（TS 38.413），AMF对"接入来自RAN还是N3IWF"在协议层是无感的，差异仅体现在接入类型参数（`RAT Type = NR` vs `NON_3GPP_ACCESS`）与密钥派生分支上。这种"协议复用、密钥分离"的设计，使得5GC可以用一套代码同时服务两类接入，是整个机制最优雅的地方。 ## 三、完整信令时序图 下图给出TS 23.502 Section 4.12.2.2（Registration via untrusted non-3GPP access network）的完整流程，并标注了双层IPsec与双EAP嵌套结构： ```mermaid sequenceDiagram autonumber participant UE participant AN as 非3GPP AN
(Wi-Fi AP) participant N3IWF participant AMF participant AUSF participant UDM participant UPF Note over UE,AN: 阶段0：附着与N3IWF发现 UE->>AN: 关联Wi-Fi，获取IP（可能经NAT） UE->>N3IWF: DNS查询 n3iwf.networklabel.n3iwf.mnc.mcc.3gppnetwork.org N3IWF-->>UE: 返回N3IWF IP Note over UE,N3IWF: 阶段1：外层IKEv2 IKE_SA_INIT UE->>N3IWF: IKE_SA_INIT（SAi0, KEi, Ni, NAT-D） N3IWF-->>UE: IKE_SA_INIT（SAr0, KEr, Nr, NAT-D） Note over UE,AUSF: 阶段2：IKE_AUTH + EAP-5G + EAP-AKA'（双EAP嵌套） UE->>N3IWF: IKE_AUTH（IDi, [CERTREQ], EAP-5G{AN-Params, NAS: Registration Request(SUCI)}） N3IWF->>AMF: N2 Initial UE Message（NAS Registration Request, RAT=NON_3GPP） AMF->>AUSF: Nausf_UEAuthentication_Get（SUCI, Access Type=non-3GPP） AUSF->>UDM: Nudm_UEAuthentication_Get UDM-->>AUSF: Auth Vector（EAP-AKA'方法, RAND, AUTN, XRES*, K_AUSF） AUSF-->>AMF: EAP-Request/AKA'-Challenge（RAND, AUTN, MAC） AMF->>N3IWF: N2 Downlink NAS Transport（NAS Auth Request，内含EAP-Request/AKA'-Challenge） N3IWF->>UE: IKE_AUTH 内 EAP-5G{NAS Auth Request{EAP-Request/AKA'-Challenge}} UE-->>N3IWF: IKE_AUTH 内 EAP-5G{NAS Auth Response{EAP-Response/AKA'-Challenge(RES, MAC)}} N3IWF-->>AMF: N2 Uplink NAS Transport AMF-->>AUSF: Nausf_UEAuthentication_Confirm（RES） AUSF-->>AMF: EAP-Success（K_AUSF） Note over UE,AMF: 阶段3：NAS安全与注册完成 AMF->>UDM: 获取签约、SUCI解隐藏 AMF->>N3IWF: N2：下发 K_N3IWF（由K_AMF派生） N3IWF->>UE: IKE_AUTH：完成外层SA（双方用K_N3IWF派生AUTH/IPsec密钥），建立信令CHILD_SA AMF->>N3IWF: N2 Downlink NAS Transport（NAS Security Mode Command） N3IWF->>UE: 经信令IPsec SA：NAS SMC UE-->>AMF: NAS Security Mode Complete（经IPsec/N2） AMF->>N3IWF: N2：Registration Accept（经N2 NAS Transport） N3IWF->>UE: 经信令IPsec SA：Registration Accept Note over UE,UPF: 阶段4：用户面IPsec CHILD_SA（PDU会话） UE->>AMF: PDU Session Establishment Request AMF->>N3IWF: N2 PDU Session Resource Setup（含QFI/TEID） N3IWF->>UE: IKEv2 CREATE_CHILD_SA：建立用户面IPsec SA（与N3 QoS流映射） UE->>N3IWF: 上行用户面（IPsec ESP） N3IWF->>UPF: GTP-U（N3，封装解IPsec后的用户面） ``` 这张图里有**三个最容易被混淆的关键点**，后面会逐一拆解：(1) 外层IKEv2自身并不真正认证UE身份，它只是承载EAP-5G；(2) EAP-5G与EAP-AKA'是**两个嵌套的EAP方法**，前者是3GPP自定义的"运输工具"，后者才是真正的5G主认证；(3) 主认证产生K_N3IWF后，才"回头"完成IKE_AUTH，时序上是**先做5G认证、后闭合IKE隧道**。 ## 四、双层IPsec与协议栈结构 非3GPP接入在NWu上不是一个IPsec SA，而是**嵌套的两层**，这是理解后续密钥与排错的基础： ```mermaid flowchart TB subgraph Outer["外层 IPsec（保护信令本身）"] direction LR IKE["IKEv2 IKE_SA
+ 信令 CHILD_SA
承载 EAP-5G / NAS"] end subgraph Inner["内层 IPsec（注册成功后建立）"] direction LR SIG["信令 CHILD_SA
承载后续 NAS（SMC/会话）"] UP["用户面 CHILD_SA
每个 PDU 会话/QoS 流一条
承载 N3 用户面"] end Outer -->|注册成功后派生| Inner style Outer fill:#e8f4ff,stroke:#2b6cb0 style Inner fill:#eaffea,stroke:#2f855a ``` 对应的协议栈（TS 23.501/24.502）： - **UE → N3IWF（信令）**：`NAS PDU → IPsec ESP（信令CHILD_SA） → IKEv2（外层保护） → UDP（4500, NAT-T） → IP`。注意EAP-5G/EAP-AKA'阶段NAS是"骑"在外层IKE_AUTH的EAP载荷里传输的，外层信令CHILD_SA建立后才转为独立承载。 - **UE → N3IWF（用户面）**：`IP包 → IPsec ESP（用户面CHILD_SA） → 外层IP → N3IWF`；N3IWF解封装后 `IP包 → GTP-U → UPF（N3）`。 - **N3IWF → AMF**：`NAS PDU → NGAP（N2，Initial UE Message / NAS Transport） → SCTP/IP → AMF`，与gNB路径完全一致。 设计意图很明显：**外层IPsec解决"信道可信"**（让EAP-5G/认证报文不在裸Wi-Fi上明文/可篡改地传输），**内层IPsec解决"业务隔离"**（不同PDU会话/QoS流各自独立SA，可独立加解密、独立计数防重放、独立协商算法）。 ## 五、EAP-5G：3GPP私有的"NAS运输工具" EAP-5G是3GPP在TS 24.502专门定义的EAP方法，它**不是认证算法**，而是一个把5G NAS消息（以及少量接入参数）打包进EAP载荷的"集装箱"。其核心信息单元如下表： | EAP-5G IE | 含义 | 作用 | |-----------|------|------| | **EAP-5G Type / Code** | Request/Response | 标识这是一条EAP-5G交互 | | **5G-NAS Message** | 携带完整NAS PDU（如Registration Request/Authentication Response） | 把5GC的NAS原封不动塞进IKEv2 | | **AN-Parameters** | 接入参数，含 **Selected PLMN ID** | N3IWF据此选路到对应PLMN的AMF | | **5G-Connectivity Parameters** | 连接参数（如PDU会话相关） | 后续会话建立阶段使用 | EAP-5G的"巧妙"之处：它让N3IWF**无需理解NAS语义**就能完成UE↔AMF的NAS透传——N3IWF只需看`AN-Parameters`里的PLMN做N2选路，其余NAS字节一律当哑管道转给AMF。这样5GC的注册、认证、会话信令可以零改动复用，AMF完全感知不到对端是Wi-Fi。 而真正的5G身份认证，藏在EAP-5G运输的NAS Authentication报文里的**第二层EAP——EAP-AKA'**。 ## 六、EAP-AKA'主认证：为什么非3GPP强制用EAP而非5G AKA TS 33.501明确规定：**不可信非3GPP接入的主认证必须使用EAP-AKA'（RFC 5448）**，而非3GPP接入侧惯用的5G AKA。原因有三： 1. **EAP框架天然适合跨不可信链路**：EAP本身就是为"在不可信接入上完成认证+派生密钥"设计的，EAP-AKA'在EAP-AKA基础上增加了密钥分离（`KDF`引入接入网络名AN-ID），正好契合N3IWF场景。 2. **EAP-Success可携带派生密钥锚点**：AUSF在EAP-AKA'成功后，从主密钥`MK`派生`K_AUSF`，整个5G密钥层级从这条EAP链路"长出来"。 3. **协议一致性**：3GPP接入可选5G AKA或EAP-AKA'；非3GPP统一收口到EAP-AKA'，使AUSF侧实现简化。 下表对比两种主认证（已在前期文章覆盖过5G AKA，此处仅作非3GPP语境下的差异对照）： | 维度 | 5G AKA（3GPP接入） | EAP-AKA'（非3GPP接入） | |------|-------------------|----------------------| | 认证框架 | 3GPP自有的鉴权请求/响应 | IETF EAP（RFC 3748 + RFC 5448） | | 传输载体 | 直接在NAS Authentication消息 | NAS Authentication内嵌EAP，再嵌EAP-5G，再嵌IKEv2 | | UE挑战方式 | AUTN验证网络 + RES*应答 | AUTN验证网络 + EAP-Response/AKA'-Challenge | | 密钥派生根 | CK‖IK → K_AUSF | MK = PRF'(IK',CK',"EAP-AKA'"+AN-ID) → K_AUSF | | 接入网络名绑定 | 否（空口隐含） | **是**，AN-ID参与KDF，防跨接入重放 | 实战中，这层"认证-派生-密钥下发"的耦合是排错的高发区：MAC失败、SQN失步（触发`Autn Synch Failure`与UDM侧重同步）、AN-ID不匹配都会在这里炸出来。 ## 七、密钥层级与K_N3IWF推演（核心安全机制） 整条链路的安全强度，最终落在密钥派生链上。下图给出TS 33.501 Clause 6定义的非3GPP接入完整密钥层级： ```mermaid flowchart TD K["K（USIM ↔ UDM 共享永久密钥）"] MK["MK（EAP-AKA' 主密钥）
PRF'(IK',CK', 'EAP-AKA' ‖ AN-ID)"] KAUSF["K_AUSF
KDF(K, 'AUSF', SUPI, ...)"] KSEAF["K_SEAF
KDF(K_AUSF, SUPI, ...)"] KAMF["K_AMF
KDF(K_SEAF, 'AMF', AMF-Set, ...)"] KN3IWF["K_N3IWF
KDF(K_AMF, 'N3IWF', AccessType=non-3GPP, ...)"] IPSECKEY["IKEv2密钥材料 / AUTH
→ 信令CHILD_SA密钥
→ 用户面CHILD_SA密钥"] K --> MK --> KAUSF --> KSEAF --> KAMF --> KN3IWF --> IPSECKEY KAMF -.同源分离.-> KGNB["K_gNB（仅3GPP接入，互不影响）"] style KN3IWF fill:#fff3cd,stroke:#d39e00,stroke-width:2px style KGNB fill:#eaffea,stroke:#2f855a ``` 这里有三个关键设计点，决定了非3GPP接入的密码学安全边界： **1. K_AUSF是分叉点，但K_AMF是"接入无关"的共享锚。** 同一UE通过3GPP与非3GPP双注册到同一AMF时，二者**共享同一个K_AMF**（由K_SEAF按AMF身份派生），而非各算一份。这简化了AMF的密钥管理。 **2. K_N3IWF与K_gNB从同一K_AMF"水平分离"派生。** 二者的KDF输入中分别绑定`AccessType`（`non-3GPP` vs `3GPP`），因此： - 即便Wi-Fi侧的IPsec SA密钥被攻陷，攻击者**无法回推K_AMF**，更无法危及3GPP接入的K_gNB； - 反之亦然。这就是TS 33.501反复强调的"**接入间密钥隔离**"，是允许5GC同时信任两类接入的密码学前提。 **3. K_N3IWF回填IKEv2完成"隐式双向认证"。** 时序上很反直觉：外层IKE_AUTH的闭合发生在5G主认证**之后**。流程是——AMF完成EAP-AKA'后派生K_N3IWF，经N2下发给N3IWF；UE侧独立从K_AMF派生出**同一个**K_N3IWF；随后双方用K_N3IWF派生IKEv2的AUTH值与IPsec密钥，闭合外层SA。结果是**IKEv2隧道的安全强度直接继承了5G主认证强度**，而不依赖任何外部CA证书——这是N3IWF相对传统IPsec VPN"证书链"方案的独特优势。 ## 八、抓包识别与实战排错 ### 8.1 抓包识别要点 在UE侧或N3IWF接入侧抓包（Wireshark默认按ISAKMP/IKEv2 + ESP解析）： - **阶段1**：UDP 500的`IKE_SA_INIT`（含`SAi0`/`KEi`/`Ni`），随后若检测到NAT则切换到UDP 4500并启用NAT-T（ESP包封装在UDP 4500内，Wireshark显示为`ESP-over-UDP`）。 - **阶段2**：`IKE_AUTH`的EAP载荷中，可见`EAP-5G`（Type非IANA标准值，需对照TS 24.502解读），其内嵌NAS可被Wireshark的`5GS NAS` dissector解析出`Registration Request`、`Authentication Request/Response`，再往里才是`EAP-Request/Response AKA'-Challenge`。**看到三层嵌套是流程正常的标志**。 - **阶段3/4**：N3IWF↔AMF的SCTP端口应在N2（通常38412对应NGAP默认端口，实际由配置决定）；用户面阶段会出现大量`CREATE_CHILD_SA`与ESP流量。 ### 8.2 常见故障点与排错矩阵 | 现象 | 根因层 | 排查思路 | |------|--------|---------| | UE始终连不上，DNS解析阶段失败 | **选网（Y1）** | 检查FQDN拼装：`n3iwf..n3iwf.mnc.mcc.3gppnetwork.org`，MNC不足3位前补0；DNS是否可达 | | IKE_SA_INIT成功但IKE_AUTH无响应 | **外层IPsec** | NAT-T未启用导致ESP被NAT丢弃；N3IWF与AMF的N2 SCTP未建链 | | EAP-AKA' `MAC Failure` | **主认证** | UE与UDM密钥不同步；SQN失步，看UDM是否触发resync（`Autn Synch Failure`） | | IKE_AUTH完成后仍建不起信令CHILD_SA | **K_N3IWF** | AMF是否成功下发K_N3IWF；UE侧AccessType标签是否为non-3GPP，导致KDF输入不一致 | | 注册成功但业务不通 | **用户面CHILD_SA** | QoS流↔IPsec SA映射策略；N3IWF↔UPF的N3 GTP-U隧道（TEID）是否正确 | | UE在Wi-Fi间切换掉线 | **隧道连续性** | 是否支持MOBIKE（RFC 4555）更新隧道外层IP | ## 九、与非可信接入演进：N3IWF → TNGF / W-AGF 补充背景：3GPP在Rel-16引入了**TNGF（Trusted Non-3GPP Gateway Function）**用于"可信非3GPP接入"（运营商自建/合作Wi-Fi），以及**W-AGF（Wireline Access Gateway Function）**用于固定宽带接入（5G-RG/FN-RG）。三者架构同构（都对接N2、都做接入网关），差异在信任假设： | 维度 | N3IWF（不可信） | TNGF（可信） | W-AGF（有线） | |------|----------------|--------------|---------------| | 信任假设 | 接入网不可信 | 接入网可信 | 有线接入可信 | | UE↔网关保护 | **必须双层IPsec（IKEv2）** | 单层IPsec或更轻量 | 可选PPPoE/IPsec | | 主认证 | EAP-AKA' | EAP-AKA' | EAP-AKA'/5G AKA | | 典型场景 | 公共/家庭Wi-Fi | 运营商热点 | 家庭网关固定接入 | 可见N3IWF的"双层IPsec + 强制EAP-AKA'"是**最重**的一套，原因正是它的信任假设最弱。理解了N3IWF，TNGF/W-AGF就是"信任升级、机制减负"的自然延伸。 ## 十、常见问题 **Q1: EAP-5G和EAP-AKA'到底是什么关系，为什么会嵌套两个EAP？** A: 二者职责完全不同。EAP-5G是3GPP定义的"运输集装箱"（TS 24.502），负责把NAS消息塞进IKEv2隧道在UE与N3IWF间传递，本身不做认证；EAP-AKA'才是真正的5G主认证算法（RFC 5448），它被NAS Authentication消息携带，而该NAS消息又被EAP-5G携带，因此形成"EAP-AKA' ⊂ NAS ⊂ EAP-5G ⊂ IKEv2"的四层嵌套。简言之：EAP-5G是"快递员"，EAP-AKA'是"快递里装的密码学验真"。 **Q2: 为什么不可信非3GPP接入一定要用EAP-AKA'，而不能用3GPP接入的5G AKA？** A: 三方面：EAP框架天生为不可信链路设计且能携带派生密钥锚点；EAP-AKA'通过AN-ID绑定接入网络名做密钥分离，防跨接入重放；统一收口到EAP使AUSF实现简化。5G AKA没有EAP信封，无法优雅地在IKEv2/NAS这条链路上完成"认证+密钥派生"的原子操作。 **Q3: UE同时通过5G基站和Wi-Fi注册，两套接入的密钥会互相影响吗？** A: 不会。二者共享同一个K_AMF（接入无关锚点），但从K_AMF分别用`AccessType`标签水平分离派生出K_gNB（3GPP）和K_N3IWF（非3GPP）。即便Wi-Fi侧IPsec密钥泄露，也无法回推K_AMF或危及3GPP接入，这正是5GC能同时信任两类接入的密码学前提。 **Q4: 抓包看到IKE_AUTH里EAP层一直失败，该如何定位？** A: 沿四层嵌套自外向内排查：先确认外层IKE_SA_INIT/算法协商正常且NAT-T生效；再确认N3IWF↔AMF的N2 SCTP链路、AMF→AUSF/UDM的SBI调用正常；最后聚焦最内层EAP-AKA'，看是MAC Failure（密钥不同步）还是`Autn Synch Failure`（SQN失步，UDM需resync）。若EAP成功但CHILD_SA建不起来，则转向K_N3IWF的派生与下发。 **Q5: N3IWF和传统IPsec VPN网关（如企业VPN）有什么本质区别？** A: 传统VPN的隧道安全依赖外部CA证书链与预共享密钥，认证体系与业务无关；而N3IWF的IKEv2隧道安全**直接继承5G主认证强度**——它的IPsec密钥由EAP-AKA'派生的K_N3IWF生成，认证身份就是5G用户身份（SUPI）。换言之，N3IWF把"5G用户鉴权"和"接入信道加密"在密码学上焊死，无需任何独立证书基础设施。 ## 参考来源 1. [3GPP TS 33.501 — Security architecture and procedures for 5G system](https://www.3gpp.org/dynareport/33501.htm) — Clause 6（密钥层级）、Clause 7.3（Untrusted non-3GPP access security）、K_N3IWF派生 2. [3GPP TS 23.502 — Procedures for the 5G System](https://www.3gpp.org/dynareport/23502.htm) — Section 4.12.2.2 Registration via untrusted non-3GPP access network 3. [3GPP TS 24.502 — Access to the 3GPP 5G core network via non-3GPP access networks](https://www.3gpp.org/dynareport/24502.htm) — EAP-5G方法、IKEv2/IPsec承载NAS 4. [第7章：非3GPP接入 — free-ran-ue 5G核心网书](https://free-ran-ue.github.io/doc-5g-core-book/zh/part2-free5gc/chapter7/) — N3IWF/TNGF架构与free5GC实现视角 5. [N3IWF — 3GPP Glossary (3gpp-explorer)](https://3gpp-explorer.com/glossary/n3iwf/) — N3IWF定义、所涉16条规范索引 6. [N3IWF (Non-3GPP InterWorking Function) — DeepWiki/free5gc](https://deepwiki.com/free5gc/free5gc/4.1-n3iwf-(non-3gpp-interworking-function)) — 开源实现中的隧道与N2处理细节 7. [Nokia's N3IWF: connect untrusted non-3GPP access and 5G](https://www.nokia.com/blog/nokia-n3iwf-seamless-5g-integration/) — 厂商部署视角与场景 8. RFC 7296 (IKEv2) / RFC 5448 (EAP-AKA') / RFC 4555 (MOBIKE) — IETF基础协议 --- > 本文由「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 等场景全覆盖。