51学通信

深度解析 3GPP TS 33.501：7.1-7.2 非3GPP接入安全 (Untrusted Non-3GPP Access)

21分钟阅读

好的，我们继续深入解读3GPP TS 33.501规范。

深度解析 3GPP TS 33.501：7.1-7.2 非3GPP接入安全 (Untrusted Non-3GPP Access)

本文技术原理深度参考了3GPP TS 33.501 V18.9.0 (2025-03) Release 18规范中，关于“7.1 General for non-3GPP access”和“7.2 Security procedures for Untrusted non-3GPP Access”的核心章节，旨在为读者深度剖析5G如何将其电信级的安全能力，无缝扩展到Wi-Fi等非3GPP网络，构建一张融合、统一的安全大网。

在之前的系列文章中，我们的讨论始终聚焦于通过3GPP无线接入技术（5G NR或4G LTE）接入5G核心网的场景。然而，5G的宏伟愿景是“万物互联”，这意味着接入方式绝不会局限于蜂窝网络。Wi-Fi、有线网络、卫星等非3GPP技术，同样是这张大网中不可或缺的组成部分。

那么，当用户通过一个我们无法完全信任的公共Wi-Fi网络，想要访问安全的5G核心网服务时，5G是如何确保其通信安全的呢？今天，我们将深入解读规范的第7章——非3GPP接入安全，重点关注其中最典型的场景：不可信非3GPP接入（Untrusted Non-3GPP Access）。

这一章将为我们揭示5G如何巧妙地利用IETF的成熟IPsec技术，在不安全的接入网络之上，构建一条通往5G核心网的“加密高速公路”。我们将了解到：

  • 网络如何判断一个Wi-Fi是“可信”还是“不可信”的？
  • N3IWF这个“安全网关”扮演了什么关键角色？
  • EAP-5G这个特殊的“集装箱”协议，是如何将NAS信令安全地“渡运”过Wi-Fi海洋的？

为了让这个场景更加生动，我们的主角“安安”今天来到了一个繁忙的国际机场。在等待登机时，她连接上了机场提供的免费公共Wi-Fi。利用这个Wi-Fi，她无缝地拨打了一通VoWiFi（Voice over Wi-Fi）高清语音电话给家人。在她看来，这只是一次普通的通话，但其背后，却是一场横跨Wi-Fi和5G核心网的、极其复杂的安全协商。

1. 7.1 通用原则 - “可信”与“不可信”的边界

在进入具体流程之前，我们必须首先理解5G对非3GPP接入的一个核心划分：可信（Trusted）与不可信（Untrusted）。

7.1 General Whether a non-3GPP IP access network is trusted or untrusted is not a characteristic of the access network. In non-roaming scenario it is the HPLMN’s operator decision if a non-3GPP IP access network is used as trusted or untrusted non-3GPP access Network.

核心解读：

  • “信任”是一种策略，而非技术属性：一个Wi-Fi网络本身，并没有一个技术上的标签写着“可信”或“不可信”。它是否被信任，完全取决于归属网络运营商（HPLMN）的安全策略。
  • 可信接入（Trusted Access）：通常指那些运营商能够直接或间接控制其安全性的网络。例如，运营商自己部署的Wi-Fi热点，或者与运营商有深度安全合作的企业内部Wi-Fi。在这种网络下，运营商相信其链路层（L2）已经提供了足够的安全保护，因此后续的接入流程可以被简化。这部分内容在7A章节中有详细定义，我们将后续解读。
  • 不可信接入（Untrusted Access）：指所有运营商无法控制其安全性的网络。机场的公共Wi-Fi、酒店Wi-Fi、家里的宽带，对于运营商来说，都属于典型的“不可信”网络。在这种网络下，运营商必须假设整条接入链路都可能被窃听和篡改。

Security for untrusted non-3GPP access to the 5G Core network is achieved by a procedure using IKEv2 as defined in RFC 7296 to set up one or more IPsec ESP security associations. The role of IKE initiator (or client) is taken by the UE, and the role of IKE responder (or server) is taken by the N3IWF.

不可信接入的安全基石：IPsec隧道 对于不可信接入，5G给出的解决方案是：忽略接入网络本身的一切安全承诺，在UE和5G核心网的安全网关（N3IWF）之间，建立一条端到端的、强大的IPsec安全隧道。

场景代入： 安安连接机场Wi-Fi后，她的手机操作系统会根据运营商的配置（或预置策略），将这个Wi-Fi标记为“不可信”。手机知道，接下来它发出的所有去往5G核心网的数据包，都必须先经过IPsec的“加密打包”，才能被发送出去。这就像安安要通过一个治安混乱的区域寄送一个贵重包裹，她不会直接把包裹交给当地的邮差，而是会先把它锁进一个坚不可摧的保险箱（IPsec），再把整个保险箱交给邮差去递送。

2. 7.2 不可信接入的安全流程 - “集装箱”里的“认证仪式”

本节的核心，是详细定义UE如何与N3IWF（非3GPP互通功能）建立IPsec隧道，并在这个隧道之上，完成向核心网AMF的注册和认证。这个流程巧妙地将IKEv2（用于建立IPsec隧道）和EAP-5G（用于传输NAS信令）两个协议“嫁接”在了一起。

我们将参照规范中的 Figure 7.2.1-1: Authentication for untrusted non-3GPP access 来拆解这个分为两个阶段的复杂流程。

阶段一：建立“加密高速公路” - IKEv2与IPsec隧道的建立

这个阶段的目标，是在UE和N3IWF之间建立起一条基础的、用于保护后续认证信令的IPsec隧道。

Step 2. The UE proceeds with the establishment of an IPsec Security Association (SA) with the selected N3IWF by initiating an IKE initial exchange… Step 3. The UE shall initiate an IKE_AUTH exchange by sending an IKE_AUTH request message. The AUTH payload is not included…, which indicates that the IKE_AUTH exchange shall use EAP signalling…

解读：

  1. UE选择N3IWF (Step 1)：UE通过DNS等方式，找到归属运营商的N3IWF的IP地址。
  2. IKE_SA_INIT (Step 2)：UE向N3IWF发起IKEv2协议的第一个交互IKE_SA_INIT。这个交互主要用于协商加密算法、交换密钥生成材料（Diffie-Hellman交换），并建立一个临时的、用于保护后续IKEv2消息的IKE SA。
  3. IKE_AUTH with EAP (Step 3-4)：接下来，UE发起IKE_AUTH交互。这里的关键创新是：UE在IKE_AUTH请求中不包含AUTH载荷，而是表明它希望通过EAP协议来进行认证。N3IWF收到后，会回复一个包含EAP-Request/5G-Start的消息，正式“拉开”EAP-5G认证会话的序幕。

场景代入： 安安的手机找到了运营商N3IWF的地址，开始“修路”。

  • 手机：“N3IWF你好，我们来建一条加密通道吧。我会用算法A，你呢？这是我的密钥生成材料X。”
  • N3IWF：“好的，我同意用算法A，这是我的密钥生成材料Y。”
  • 此时，双方都有了X和Y，可以各自计算出相同的、用于保护后续“修路指令”的临时密钥。
  • 手机：“好了，现在我们的‘对讲机’（IKE SA）是加密的了。接下来，请不要用传统的证书来验证我，我希望走一个更高级的‘5G认证流程’（EAP-5G）。”
  • N3IWF：“收到！‘5G认证流程’启动！”

阶段二：在“高速公路”上运送“集装箱” - EAP-5G与NAS信令的封装

EAP-5G是一个由3GPP定义的、特殊的EAP方法。它本身不执行任何认证逻辑，而是作为一个**“集装箱”协议**，其唯一的作用，就是将UE与AMF之间的NAS信令原封不动地封装在EAP消息中，以便它们能够被承载在IKEv2协议之上。

Step 5. The UE shall send an IKE_AUTH request which includes an EAP-Response/5G-NAS packet that contains a Registration Request message…

解读：

  1. UE封装NAS (Step 5)：UE构建一个标准的Registration Request（包含SUCI等信息），就像它在3GPP接入时做的一样。然后，它将整个NAS消息放入一个EAP-Response/5G-NAS的“集装箱”里，再将这个EAP消息放入IKE_AUTH请求中，发给N3IWF。
  2. N3IWF“拆箱”并转发 (Step 6)：N3IWF收到IKE_AUTH请求后，从中“拆”出EAP-5G集装箱，再从集装箱里“拆”出原始的NAS消息。N3IWF本身不理解NAS消息的内容，它只是一个“中转港口”。它会根据NAS消息中的路由信息，选择一个合适的AMF，然后将这条NAS消息通过N2接口转发给AMF。
  3. 核心网认证 (Step 7)：接下来的故事我们已经非常熟悉了！AMF收到了这条来自N3IWF的Registration Request，它会像处理来自gNB的请求一样，与AUSF、UDM进行交互，完成标准的5G主认证流程（5G AKA或EAP-AKA’）。
  4. 认证消息原路返回 (Step 8-11)：核心网的认证信令（如SMC命令）会沿着相反的路径，由AMF发给N3IWF，N3IWF再将其封装进EAP-Request/5G-NAS集装箱，通过IKE_AUTH响应发回给UE。
  5. K_N3IWF的生成与下发 (Step 12)：当认证成功、NAS安全上下文建立后，AMF会从K_AMF派生出一个专用于非3GPP接入的密钥——K_N3IWF。AMF会将这个密钥通过Initial Context Setup Request消息，安全地发送给N3IWF。
  6. IKE_AUTH的最后一步 (Step 13-14)：N3IWF收到K_N3IWF后，会向UE发送一个**EAP-Success消息，并利用K_N3IWF作为IKEv2流程的主会话密钥（MSK），与UE完成IKE_AUTH流程的最后一步验证。此时，一条或多条用于传输用户数据的子SA（Child SA），即真正的IPsec ESP隧道**，就成功建立起来了。

场景代入： “加密高速公路”的基础已经打好，现在开始运送“货物”。

  • 安安的手机将“入网申请”（Registration Request），装进一个标有“5G-NAS”的集装箱（EAP-5G），再把集装箱吊到一辆“IKE”卡车上，开上了通往N3IWF的高速公路。
  • N3IWF港口收到卡车，卸下集装箱，取出里面的“入网申请”，通过“内部铁路”（N2接口）送到了核心网的AMF“海关大楼”。
  • “海关大楼”里进行了一场标准的身份核查（主认证）。
  • 核查通过后，AMF制作了一把专用于这条“高速公路”的“主钥匙”K_N3IWF，并交给了N3IWF港口。
  • N3IWF港口向安安的手机发出了“认证成功”的信号，并用这把K_N3IWF主钥匙，与手机协商好了后续所有“货运卡车”（用户数据）的加密和签名方式。

至此，一条从安安的手机，穿越机场公共Wi-Fi，直达5G核心网UPF的安全、加密的“数字货运专线”就全线贯通了。安安的VoWiFi通话，就可以在这条专线上安全地传输。

4. 总结

本章深入探讨的7.1和7.2节，为我们揭示了5G安全体系强大的融合与扩展能力。它没有试图去改造Wi-Fi等非3GPP网络，而是采取了一种更聪明的“叠加（Overlay）”方案。

  • 信任边界清晰：通过将公共Wi-Fi等网络明确定义为“不可信”，5G为其上的安全通信设定了“零信任”的基调。
  • 借力成熟技术：巧妙地利用了IETF的IKEv2/IPsec这一极其成熟、健壮的VPN技术，来构建底层的安全传输隧道。这避免了重复发明轮子，并保证了技术的可靠性。
  • 创新的“集装箱”协议：通过定义EAP-5G这一“信封”协议，实现了将原生的NAS信令在IKEv2协议中“透明传输”。这使得核心网的认证逻辑（AMF/AUSF/UDM）可以完全复用，无需为非3GPP接入场景开发一套全新的认证体系。
  • 独立的密钥分支：通过从K_AMF派生出专用的**K_N3IWF**，非3GPP接入的安全上下文与3GPP接入的上下文实现了密钥隔离，遵循了“信任之树”的一贯设计哲学。

这一整套机制，如同一座巧妙架设在广阔Wi-Fi海洋上的“跨海大桥”，让用户能够在任何有IP连接的地方，都能安全、无缝地享受到5G核心网提供的服务，真正实现了5G“无处不在”的连接愿景。

FAQ

Q1：为什么需要EAP-5G这个特殊的协议？IKEv2本身不就支持多种认证方法吗？ A1：是的，IKEv2本身支持证书、预共享密钥等认证方法。但5G的认证核心是基于USIM的AKA机制，并且认证的终结点是核心网的AUSF，而非接入网关N3IWF。直接使用IKEv2的标准认证方法，无法将认证请求安全地传递到核心网深处。EAP-5G的巧妙之处在于，它将IKEv2的认证阶段“代理”给了NAS协议。它告诉IKEv2：“认证的具体内容你不用管，把它交给我这个EAP方法就行了”。然后，它再把NAS信令这个“烫手山芋”包裹起来，让IKEv2负责把它安全地运到N3IWF。N3IWF再把NAS信令交给真正能处理它的AMF。所以，EAP-5G是一个“协议胶水”或“适配层”，它完美地解决了IKEv2认证框架与5G核心网认证体系之间的“语言不通”问题。

Q2：K_N3IWF和K_gNB有什么异同？ A2：共同点：它们都是从同一个父密钥K_AMF派生出来的，都属于AS（接入层）级别的密钥，都用于保护UE与接入网关之间的通信。不同点：

  • 用途不同：K_gNB用于UE与gNB之间的无线空口安全（NG-AP协议栈）。而K_N3IWF则被用作IKEv2协议的主会话密钥（MSK），用于派生出保护IPsec隧道的密钥。
  • 分发对象不同：K_gNB被AMF分发给gNB。K_N3IWF被AMF分发给N3IWF。 它们是“信任之树”上从K_AMF这根主枝干上分叉出的、服务于不同接入技术的两条平行“子枝干”。

Q3：如果我在一个不可信的Wi-Fi下，只是浏览网页，不使用VoWiFi等运营商服务，这个IPsec隧道还会建立吗？ A3：不会。这个IPsec隧道的建立，其前提是UE决定要通过这个Wi-Fi接入到5G核心网（5GC）。这通常是由手机操作系统中的“连接管理器”根据运营商的策略来决定的。如果您的手机策略配置为“优先通过Wi-Fi进行数据分流”（LWA），或者您主动发起了VoWiFi通话，手机才会去尝试与N3IWF建立IPsec隧道并注册到5GC。如果您只是像普通设备一样连接Wi-Fi上网，您的所有流量都将直接通过Wi-Fi路由器流向互联网，与5G核心网和N3IWF没有任何关系。

Q4：整个流程看起来非常复杂，建立一次VoWiFi通话的时延会很长吗？ A4：初始建立时的时延会比在蜂窝网络下略长，因为它包含了额外的IKEv2协商和EAP封装过程。这个时延通常在几百毫秒到一秒左右，对于一次通话的建立来说是可以接受的。更重要的是，一旦IPsec隧道（Child SA）建立起来，它就可以被长期保持（keep-alive）。后续的通话或数据业务，可以直接在这个已经建立的隧道上传输，无需再次进行复杂的协商，实现了快速的业务接入。

Q5：什么是“可信”非3GPP接入？它和“不可信”接入相比，安全流程简化在哪里？ A5：“可信”非3GPP接入，是指运营商认为其L2（链路层）已经足够安全的接入网络，例如运营商自己部署和管理的Wi-Fi网络。在这种场景下，核心的简化在于无需建立IPsec隧道来保护NAS信令的传输。UE可以直接在L2链路上，通过EAP-5G来传输NAS信令。认证成功后，虽然仍然会建立IPsec隧道来保护用户数据（UP），但其加密可以是“NULL”（即只做完整性保护），因为机密性已经由可信的L2链路保证了。这减少了IKEv2初始协商的复杂性和开销。我们将在后续解读7A章节时详细探讨这个流程。

关系图谱