51学通信

深度解析 3GPP TS 23.501：认证、接入与开放：5GC的安全边界 (AUSF, N3IWF & AF)

20分钟阅读

本文技术原理深度参考了3GPP TS 23.501 V18.9.0 (2025-03) Release 18规范中，关于“6.2.8 AUSF”、“6.2.9 N3IWF”和“6.2.10 AF”的核心章节，旨在为读者提供一个5G核心网如何通过这三大关键功能，构建起从用户身份、接入媒介到上层应用的、层次分明的“安全与信任边界”的全景视图。本文是解读“6 Network Functions”系列的第四部分。

深度解析 3GPP TS 23.501：认证、接入与开放：5GC的安全边界 (AUSF, N3IWF & AF)

欢迎来到“解构5G核心网”的NF深度解析系列。在前面的文章中，我们已经深入剖析了AMF、SMF和PCF这三大“前台”网络功能，它们共同构筑了5G的用户连接、会话与策略。今天，我们将把目光转向那些定义了网络“边界”与“信任”的关键角色，它们是5G安全体系和开放生态的守护者。

我们将一次性解读三个在逻辑上紧密关联的网络功能（或实体）：

  • AUSF (Authentication Server Function): 5G网络的“身份公证处”，负责核验每一个UE的合法身份，是信任链条的起点。

  • N3IWF (Non-3GPP InterWorking Function): 5G网络在“非信任”地盘上建立的“装甲通道”，负责将公共Wi-Fi等不可信的网络环境，安全地接入到5G核心网。

  • AF (Application Function): 来自外部世界的“商业伙伴”，它们通过指定的“外交渠道”（NEF），与5G核心网进行可信的、可控的能力交互。

这三者共同定义了5G核心网的安全边界：AUSF确立了用户身份的信任，N3IWF确立了接入媒介的信任，而AF（通过NEF）则定义了应用生态的信任。

为了将这三个功能串联起来，让我们跟随小晴的脚步，体验一次现代化的国际出行。小晴抵达了**“未来城市”国际机场**，她将在这里完成一系列需要无缝、安全网络连接的操作：

  1. 落地开机，手机自动连接到本地5G网络。

  2. 为了节省流量，她连接了机场的免费公共Wi-Fi，但依然希望保持VoNR高清通话的畅通。

  3. 在等待登机时，她使用航空公司的官方APP，请求了VIP休息室的导航服务。

我们将通过小晴的这次机场之旅，来解构AUSF、N3IWF和AF是如何在幕后协同工作，为她提供安全、无缝的连接与服务的。

1. “身份公证处”：AUSF (6.2.8 Authentication Server Function)

在5G这个庞大的数字社会中，任何交互都始于一个根本问题：“你是谁？”。AUSF就是负责回答这个问题的权威机构。

The Authentication Server Function (AUSF) supports the following functionality:

  • Supports authentication for 3GPP access and untrusted non-3GPP access as specified in TS 33.501.

1.1 AUSF的核心职责：专职的认证服务器

AUSF的功能非常专一和聚焦：执行认证。在4G时代，认证功能是HSS的一部分，而在5G服务化架构中，它被独立出来，成为一个专门的NF。这种解耦带来了更高的灵活性和安全性。

AUSF在认证流程中扮演“认证官”的角色，但它本身不存储用户的“终极秘密”（即永久密钥K）。它更像是一个执行者和计算者：

  1. 接收请求： AMF在收到UE的注册请求后，会将UE提供的SUCI和相关信息，通过Nausf_UEAuthentication服务，请求AUSF对UE进行认证。

  2. 获取鉴权向量： AUSF向UDM请求该用户的鉴权向量（Authentication Vector, AV）。UDM作为“密钥保管库”，会使用永久密钥K生成这个一次性的鉴权向量，并返回给AUSF。

  3. 发起挑战： AUSF将鉴权向量中的“挑战”（RAND和AUTN）发送给AMF，再由AMF传递给UE。

  4. 验证响应： UE使用其USIM卡中的密钥进行计算，生成“响应”（RES*），并回传给AMF → AUSF。AUSF将UE的响应与鉴权向量中的期望响应（XRES*）进行比对。

  5. 得出结论： 如果比对一致，AUSF就确认该UE是合法的，并生成用于后续通信加密和完整性保护的会话密钥，发送给AMF。

1.2 场景代入：小晴落地后的“身份确认”

  1. 小晴的飞机落地，她关闭飞行模式。手机扫描到本地运营商的5G信号并发起注册。

  2. AMF收到了包含小晴SUCI的注册请求，立即向其服务范围内的AUSF发起了Nausf_UEAuthentication_Authenticate请求。

  3. AUSF开始工作： 它从SUCI中解析出归属网络信息，并向小晴归属HPLMN的UDM请求鉴权向量。

  4. UDM生成“考题”： UDM使用小晴签约的永久密钥，生成了一套包含“考题”（RAND+AUTN）和“标准答案”（XRES*）的鉴权向量，发给AUSF。

  5. 下发“考题”与作答： AUSF将“考题”通过AMF发给小晴的手机。手机中的USIM卡完成了计算，得出了自己的“答案”（RES*）。

  6. AUSF批改试卷： AUSF收到了UE的“答案”，与UDM给的“标准答案”一比对，完全一致！

  7. 认证成功： AUSF随即生成了会话密钥，通知AMF：“该用户身份合法，这是接下来通信用的密钥”。AMF随即完成了小晴的注册流程。

整个过程对小晴完全无感，但背后却是AUSF、UDM、AMF和UE之间一次严谨而复杂的“加密对话”。

2. “装甲运输车”：N3IWF (6.2.9 Non-3GPP InterWorking Function)

机场的免费Wi-Fi信号很强，小晴想用它来节省流量。但她又担心公共Wi-Fi的安全性，而且不希望正在进行的VoNR通话因为网络切换而中断。这时，N3IWF就该登场了。

The functionality of N3IWF in the case of untrusted non-3GPP access includes the following:

  • Support of IPsec tunnel establishment with the UE: The N3IWF terminates the IKEv2/IPsec protocols with the UE over NWu…
  • Termination of N2 and N3 interfaces to 5G Core Network…
  • Relaying uplink and downlink control-plane NAS (N1) signalling between the UE and AMF.
  • Relaying uplink and downlink user-plane packets between the UE and UPF.

2.1 核心理念：在“公海”上建立“专属安全航道”

N3IWF的核心任务，是在一个不可信的IP网络（如公共Wi-Fi、酒店宽带，甚至竞争对手的网络）之上，为UE建立一条通往5GC的、端到端加密的安全隧道。

  • 不可信的“公海”： 机场的Wi-Fi网络，对于运营商的5GC来说，是完全不可信的。运营商无法保证其安全性、QoS，甚至无法感知其存在。

  • IPsec“装甲航道”： N3IWF通过IKEv2协议与UE协商，建立一条IPsec隧道。所有UE与5GC之间的信令（N1）和数据（N3），都被封装在这条加密的、有完整性保护的隧道中传输。

  • N3IWF的角色：

    • 隧道终结点： 它是IPsec隧道的网络侧终点，负责解封和封装所有进出隧道的数据。

    • 协议转换器： 它将解封后的N1信令通过N2接口送往AMF，将解封后的用户数据通过N3接口送往UPF。

    • 安全网关： 它是5GC面对非3GPP接入的安全屏障。

2.2 场景代入：小晴的“Wi-Fi高清通话”

  1. 连接Wi-Fi： 小晴的手机连接上了“Future-City-Airport-Free-WiFi”。

  2. 发现N3IWF： 手机的操作系统（或运营商配置）被设置为优先通过WLAN接入5GC。它通过DNS查询（例如，查询n3iwf.mncXXX.mccYYY.3gppnetwork.org），找到了运营商N3IWF的IP地址。

  3. 建立IPsec隧道： 手机向该N3IWF发起IKEv2协商，使用其5G USIM中的凭证进行认证（EAP-AKA’），成功建立了一条IPsec隧道。这条隧道穿过了整个机场的Wi-Fi网络。

  4. 5GC注册： 隧道建立后，N3IWF就如同一个“虚拟基站”。小晴的手机通过这条隧道，向AMF发起了标准的注册流程（对于AMF来说，这和一次普通的non-3GPP接入注册没有区别）。

  5. 业务无缝： 由于这次注册依然由同一个AMF处理，并且可以保持PDU会话的连续性（通过SSC Mode 3或IP地址漫游），小晴正在进行的VoNR通话可以无缝地从蜂窝网络切换到这条基于Wi-Fi的IPsec隧道上，通话质量和安全性都得到了保障。

对于小晴来说，她只是简单地连了一下Wi-Fi，但N3IWF在背后为她构建了一条安全的“水下通道”，让她的5G核心网服务得以在公共Wi-Fi上无缝延伸。

3. “商业伙伴”：AF (6.2.10 Application Function)

AF本身不是5G核心网的标准NF，但它是理解5G服务化架构和能力开放的关键。它代表了所有希望与5G网络进行能力交互的外部应用。

The Application Function (AF) interacts with the 3GPP Core Network in order to provide services, for example to support the following:

  • Application Function influence on traffic routing…
  • Accessing Network Exposure Function…
  • Interacting with the Policy and charging control framework…

3.1 AF的定位与交互方式

  • 定位： AF是位于5GC外部的、可信或不可信的第三方应用服务器。例如，航空公司的服务器、云游戏平台、车联网V2X平台等。

  • 交互方式：

    • 受信任的AF： 极少数情况下，如果AF与运营商高度集成且位于同一信任域，它可能可以直接与PCF等NF交互。

    • 不受信任的AF（主流）： 绝大多数情况下，AF必须通过**NEF（网络开放功能）**这个统一的、安全的API网关，与5GC进行交互。

3.2 AF能做什么？

AF可以通过NEF，向5GC请求一系列增值服务，从而优化其自身应用的性能和用户体验：

  • 影响流量路由： 请求PCF/SMF将特定用户的特定流量，路由到离用户更近的边缘UPF上。

  • 请求QoS保障： 请求PCF为特定的数据流（如游戏、视频）提供差异化的QoS保障。

  • 订阅网络事件： 订阅UE的位置变更、可达性状态变化等事件，以便在合适的时机向用户推送信息或调度资源。

3.3 场景代入：VIP休息室的智能导航

  1. AF发起请求： 小晴在航空公司的APP中点击了“查找VIP休息室”按钮。该APP的后台服务器（AF），立即向运营商的NEF发起了一个API请求：“请为用户GPSI_XiaoQing提供实时位置更新服务，并在她进入‘VIP休息室’地理围栏区域时通知我”。

  2. NEF & PCF & AMF 协同：

    • NEF对该AF进行认证和授权。

    • NEF将这个“地理围栏监控”的请求，传递给PCF。

    • PCF生成相应的策略，并订阅AMF的“UE位置报告”事件。

  3. 事件触发与通知： 小晴走进了VIP休息室。

    • 她的位置更新被AMF感知到。

    • AMF检测到UE进入了PCF所订阅的“地理围栏”，于是向PCF上报事件。

    • PCF再通过NEF，将一个通知（"User has entered VIP lounge area"）发送给了航空公司的AF。

  4. 应用响应： 航空公司的AF收到通知后，立即通过其应用，向小晴的手机推送了一条消息：“欢迎来到VIP休息室，您的座位在A区12座”，并在AR眼镜中高亮了通往座位的导航路径。

在这个过程中，AF作为一个外部伙伴，通过NEF这个“外交窗口”，成功地利用了5GC的位置感知能力，为小晴提供了精准、智能的服务。

5. FAQ

Q1: AUSF和UDM在认证过程中的具体分工是什么？

A:

可以把它们比作“认证官”和“档案库/密钥中心”。

  • UDM (档案库/密钥中心): 负责存储最核心的安全信息（用户的永久密钥K）和生成一次性的认证材料（鉴权向量AV）。它不直接参与和UE的信令交互。

  • AUSF (认证官): 负责执行整个认证流程。它从AMF接收认证请求，从UDM获取认证材料，向UE发起“挑战”，并最终验证UE的“响应”。它本身不存储永久密钥，只在认证过程中临时使用鉴权向量。

这种职责分离，使得存储着最敏感信息的UDM可以被部署在更安全的核心区域，而需要频繁与外部（通过AMF）交互的AUSF可以更灵活地部署。

Q2: N3IWF和TNGF都是用于连接非3GPP接入的，它们有什么区别？

A:

最核心的区别在于它们所连接的非3GPP接入网络的信任级别不同。

  • N3IWF (Non-3GPP InterWorking Function) 用于不可信 (Untrusted) 的非3GPP接入，如公共Wi-Fi、家庭宽带等。因为网络不可信，所以必须在UE和N3IWF之间建立一条IPsec加密隧道来保障通信安全。

  • TNGF (Trusted Non-3GPP Gateway Function) 用于可信 (Trusted) 的非3GPP接入，如运营商自己部署和管理的Wi-Fi网络、或通过有线方式接入的FWA（固定无线接入）设备。因为接入网络本身是可信的，所以不需要在UE和TNGF之间再建立一层IPsec隧道，可以直接进行认证和数据传输。

Q3: AF既然是外部实体，它如何保证自己的API调用是安全的？

A:

AF与NEF之间的交互，通常使用标准的互联网安全协议来保障。

  • 传输层安全： 所有的API调用都基于HTTPS（TLS），确保了信道的机密性和完整性。

  • 应用层认证/授权： AF在调用NEF的API时，需要提供认证凭证，这通常通过OAuth 2.0等框架来实现。NEF会为每个合法的AF颁发一个有时效性的Access Token。AF在每次请求时都需要携带这个Token，NEF会验证Token的合法性、有效性和权限范围，从而决定是否允许本次调用。

Q4: 一个UPF可以同时扮演N3IWF/TNGF和普通的PSA UPF的角色吗？

A:

不可以。N3IWF和TNGF是独立的网络功能，它们专门处理与非3GPP接入相关的信令和用户面协议栈（如IPsec、EAP等）。它们是UE通过非3GPP接入进入5GC的“入口网关”。

一个PDU会话的典型路径是：

  • Untrusted non-3GPP接入： UE <-(IPsec)-> N3IWF <-(N3)-> UPF (PSA) -> DN

  • Trusted non-3GPP接入： UE <-(no IPsec)-> TNGF <-(N3)-> UPF (PSA) -> DN

在这个模型中，N3IWF/TNGF负责接入层的处理和转换，而UPF（PSA）依然是会话的IP锚点和与数据网络的接口。当然，在具体的物理部署上，一个服务器上可以同时运行N3IWF和UPF的软件实例，但它们在逻辑上是两个独立的NF。

Q5: 如果没有NEF，AF还能和5GC交互吗？

A:

在标准的、开放的生态模式下，不能。NEF是3GPP定义的、AF与5GC交互的唯一标准接口。

如果没有NEF，AF想要实现类似的功能，就只能通过运营商提供的、非标准的、私有的接口。这将导致：

  • 安全性差： 每个AF都需要一套独立的认证和安全机制，难以统一管理。

  • 集成难度高： AF需要针对每个运营商的私有接口进行定制开发，无法实现“一次开发，到处适用”。

  • 网络内部暴露： 可能会将核心网内部的接口和拓扑直接暴露给第三方，带来安全风险。

因此，NEF的存在，是5G网络能够构建一个标准化、安全、可扩展的应用生态的基石。

关系图谱