51学通信

深度解析 3GPP TS 33.501：9-11 接口安全、IMS紧急会话与二次认证

23分钟阅读

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

深度解析 3GPP TS 33.501：9-11 接口安全、IMS紧急会话与二次认证

本文技术原理深度参考了3GPP TS 33.501 V18.9.0 (2025-03) Release 18规范中，关于“9 Security procedures for non-service based interfaces”、“10 Security aspects of IMS emergency session handling”和“11 Security procedures between UE and external data networks via the 5G Network”的核心章节，旨在为读者深入剖析5G安全体系中网络内部的“高速公路”安防、生命至上的“应急通道”规则，以及通往外部世界的“联合认证”机制。

在前面的系列文章中，我们已经详细探讨了围绕UE的接入认证、移动性管理等核心安全流程。然而，一个完整的安全体系，不仅要保护好“城堡”的大门（UE接入），还要确保“城堡”内部各个建筑物之间道路（网络接口）的安全，为“紧急事件”（紧急呼叫）预留特殊通道，并建立一套与“盟友”（外部数据网络）进行可信交互的“外交礼节”。

今天，我们将深入解读规范的第9、10、11章。这三章分别解决了5G安全体系在这三个维度的扩展问题：

  • 第9章 非服务化接口安全：当5G核心网与传统网元或接入网（如gNB）通过非SBA的点对点接口通信时，这些“专线公路”的安全是如何保障的？
  • 第10章 IMS紧急会话安全：当生命安全高于一切时，5G安全是如何为IMS紧急呼叫“让路”，甚至在用户无法被认证的情况下，也能建立起一条“生命通道”的？
  • 第11章 与外部数据网络的二次认证：当用户不仅要接入5G网络，还需要访问企业内网等需要额外身份验证的外部数据网络（DN）时，5G是如何扮演“认证代理”的角色，实现无缝的二次认证的？

为了贯穿这三个场景，我们的主角“安安”将经历不平凡的一天。早上，她在公司通过手机接入了需要二次认证的企业内网，查阅机密文件。下午，她在野外徒步时不幸遇到意外，在手机信号微弱且没有SIM卡的情况下，成功拨打了紧急电话。而核心网工程师“李工”，则将从后台视角，为我们揭示支撑这些场景的网络接口安全，以及IMS紧急呼叫的特殊安全逻辑。

1. 第9章 非服务化接口安全 - 网络内部的“装甲运输线”

虽然5G核心网大力推行服务化架构（SBA），但仍然存在大量基于传统IP协议的点对点接口，它们像一张张“高速公路网”，连接着核心网与接入网，以及核心网内部的关键功能。第9章的核心任务，就是为这些“高速公路”部署“安防系统”。

9.1.1 Use of NDS/IP The protection of IP based interfaces for 5GC and 5G-AN according to NDS/IP is specified in TS 33.210. Traffic on interfaces carrying control plane signalling can be both integrity and confidentiality protected according to NDS/IP.

核心技术：NDS/IP (网络域安全/IP) NDS/IP是3GPP定义的一套基于IETF标准IPsec协议的网络域安全框架。它要求在不同网络设备（如AMF和gNB）之间，建立IPsec隧道，为所有通过的IP流量提供强大的安全保护。

1.1 关键接口的安全要求

9.2 Security mechanisms for the N2 interface N2 is the reference point between the AMF and the 5G-AN. … The transport of control plane data over N2 shall be integrity, confidentiality and replay-protected.

  • N2接口（AMF ←> gNB）：这是核心网与接入网之间的“主动脉”，承载着所有NAS信令和UE上下文管理信令。规范强制要求使用IPsec对其进行机密性、完整性和抗重放保护。

9.3 Security requirements and procedures on N3 N3 is the reference point between the 5G-AN and UPF. It is used to carry user plane data from the UE to the UPF. The transport of user data over N3 shall be integrity, confidentiality and replay-protected.

  • N3接口（gNB ←> UPF）：这是用户数据的“主干道”。经过空口加密的数据包到达gNB解密后，会通过N3接口的GTP-U隧道被送往UPF。规范同样强制要求使用IPsec保护N3接口。

9.4 Security mechanisms for the Xn interface Xn is the interface connecting NG-RAN nodes. … The transport of control plane data and user data over Xn shall be integrity, confidentiality and replay-protected.

  • Xn接口（gNB ←> gNB）：这是基站之间的“联络线”，主要用于支持快速切换。规范同样强制要求使用IPsec对其进行保护。

场景代入： 李工指着一张网络拓扑图解释道：“你可以把AMF、gNB、UPF这些网元看作一个个独立的‘军事基地’。它们之间的N2、N3、Xn接口，就是连接这些基地的‘公路’。因为这些公路可能会穿越不安全的区域（例如，租用的商业传输网络），我们必须让所有在上面跑的‘运输车队’（IP包）都变成‘装甲车队’（IPsec封装）。每两个基地之间，都通过IKEv2协议，使用数字证书相互认证身份，并协商出一次性的加密密钥，建立起一条条‘加密地道’（IPsec隧道）。”

这个机制确保了5G网络的“神经系统”和“循环系统”在物理传输层面是高度安全的，即使传输网络被攻破，攻击者也只能看到一堆无法解密的加密数据流。

2. 第10章 IMS紧急会话安全 - “生命至上”的特殊规则

当安安在野外需要拨打紧急电话时，常规的安全流程可能因为各种原因（如未注册、认证失败、无SIM卡）而无法执行。第10章详细定义了在这种极端情况下，如何为IMS（IP多媒体子系统）紧急呼叫建立一条“生命通道”。

10.2.2 Unauthenticated IMS Emergency Sessions There are many scenarios when an unauthenticated Emergency Session may be established without the network having to authenticate the UE or apply ciphering or integrity protection for either AS or NAS. For example: a) UEs that are in Limited service state UEs…

核心思想：安全为可用性让路 IMS紧急会告的安全核心，是在保障生命通道畅通的前提下，尽力而为地提供安全；当两者冲突时，可用性永远优先。

2.1 认证失败，但呼叫继续

If the serving network policy allows unauthenticated IMS Emergency Sessions, the AMF, after the unsuccessful authentication verification of the UE, should not send a reject an Authentication Reject message and continue using the current security context with the UE.

场景代入： 安安的手机有SIM卡，但因为某种原因（如归属网络故障）主认证失败了。

  • 常规呼叫：AMF会直接拒绝服务。
  • 紧急呼叫：如果网络策略允许，AMF不应该拒绝，而是会“假装”认证通过，继续后续的呼叫建立流程，但可能会将安全等级降至最低。

2.2 无认证用户的“零安全”模式

场景代入： 安安的手机没有SIM卡，或者她使用的是一部不支持5G签约的手机，处于“有限服务模式”（Limited Service Mode）。此时她发起了紧急呼叫。

If an AMF allows unauthenticated UEs in LSM to establish bearers for an emergency session, then for the NAS protocol, the AMF shall use NIA0 and NEA0 as the integrity and ciphering algorithm respectively.

  1. UE发起紧急注册：UE会发送一条特殊的Registration Request，并明确指出是为了“Emergency Registration”。
  2. AMF的决策：AMF收到请求后，会发现无法对UE进行认证。根据预置的紧急策略，AMF决定接受这个呼叫。
  3. 强制使用“空算法”：AMF会发起一次特殊的NAS SMC流程。在这个流程中，AMF会强制选择**NIA0（空完整性）和NEA0（空加密）**作为NAS安全算法。
  4. UE的配合：UE在发起紧急呼叫时，已经做好了接收“空算法”的准备。当它收到这个SMC命令时，会无条件接受，并建立一个“无保护”的NAS安全上下文。
  5. AS层的同步“降级”：AMF在通知gNB为这个紧急呼叫建立承载时，会在UE的安全能力中只包含EIA0/EEA0（AS层的空算法），迫使gNB也只能选择“无保护”模式。

这个流程确保了即使在双方没有任何共享密钥的情况下，也能走完建立连接所需的信令流程，为紧急呼叫打通一条通路。虽然这条通路是“裸奔”的，但它保障了“能打通”这个最高优先级的需求。

3. 第11章 与外部数据网络的二次认证 - 5G扮演的“认证代理”

当安安回到公司，需要访问内部的ERP系统时，仅仅通过运营商的5G认证是不够的，她还需要通过公司的身份认证。第11章定义了5G网络如何协助UE，完成对外部数据网络（DN）的二次认证（Secondary Authentication）。

11.1.1 General This sub-clause specifies support for optional to use secondary authentication between the UE and an external data network (DN). The EAP framework … shall be used for authentication between the UE and a DN-AAA server… The SMF shall perform the role of the EAP Authenticator.

核心思想：借道5G信令，代理EAP认证 5G网络在这里扮演了一个“认证代理”和“协议隧道”的角色。

  • 认证框架：使用通用的EAP框架。
  • 认证三方：
    • UE：扮演EAP Peer（对等方）。
    • SMF：扮演EAP Authenticator（穿透式认证器）。
    • DN-AAA服务器：企业自己的AAA服务器，扮演EAP Server（后端认证服务器）。
  • 信令隧道：UE与SMF之间的EAP消息，被封装在**NAS SM（会话管理）**消息中进行传输，搭乘了5G控制平面的“便车”。

认证流程 (Figure 11.1.2-1)

场景代入： 安安在手机上打开了公司的ERP App。

  1. UE发起PDU会话建立：App的请求触发UE向网络发起PDU会话建立请求，请求的目标DNN（数据网络名称）指向了公司的内部网络。
  2. SMF识别并触发二次认证 (Step 7-8)：SMF收到请求后，查询策略发现这个DNN需要二次认证。于是，SMF不是直接建立会话，而是向UE发送一条EAP Request/Identity消息（封装在NAS SM消息中），启动了EAP流程。
  3. UE与DN-AAA的EAP“对话” (Step 9-13)：接下来，一场标准的EAP认证（如EAP-TLS、EAP-TTLS/MSCHAPv2等，具体方法由企业AAA服务器决定）在UE和DN-AAA之间展开。所有的EAP消息都由SMF作为“中间人”进行透明转发。SMF将下行的EAP消息封装在NAS SM消息中发给UE，UE将上行的EAP消息同样封装在NAS SM消息中发给SMF。
  4. 认证成功与授权 (Step 14)：当DN-AAA服务器成功认证UE后，它会向SMF发送一个EAP-Success消息。这个消息可能还包含了授权信息，如分配给UE的内网IP地址、允许访问的服务器列表等。
  5. PDU会话建立完成 (Step 15-19)：SMF收到EAP-Success后，确认二次认证成功。它会继续完成PDU会话的建立流程，将DN-AAA分配的IP地址下发给UE，并在UPF上配置相应的路由和策略，打通UE到企业内网的数据通道。

这个机制的强大之处在于，它将5G的接入认证与企业的应用认证无缝地结合在了一起。运营商负责将UE安全地“带到”企业网络的“大门口”（UPF），而进入大门的“钥匙”，则由企业自己的AAA服务器来掌管。这为企业在5G网络上构建安全的私有应用提供了极大的灵活性和控制权。

4. 总结

本章我们深入解读了第9、10、11章，看到了5G安全体系在三个重要维度上的扩展能力：

  • 接口安全 (9)：通过在N2/N3/Xn等关键接口上强制实施IPsec，5G为网络内部的数据流动构建了坚固的“装甲走廊”，实现了传输层面的深度防御。
  • IMS紧急会话安全 (10)：通过设计认证可选、强制使用空算法等特殊流程，5G在“生命至上”的原则下，为紧急呼叫预留了一条即使在最差安全条件下也能打通的“生命通道”，体现了安全设计的“人性化”考量。
  • 二次认证 (11)：通过将EAP认证流程“隧道化”地承载于NAS会话管理信令之上，5G网络化身为一个强大的“认证代理”，无缝地将电信网的身份认证与企业/第三方数据网的应用认证结合起来，是5G赋能垂直行业（B2B）的关键安全基石。

这三大机制，分别展现了5G安全在网络纵深防御、极端场景适应性以及跨域信任联邦方面的强大能力，共同构成了5G安全体系完整、健壮、灵活的宏伟蓝图。

FAQ

Q1：为什么N2/N3接口需要用IPsec保护？AMF/gNB/UPF不都部署在运营商自己的安全机房里吗？ A1：这是“零信任”安全理念的体现。虽然这些设备通常在运营商的机房，但：1) 传输网络可能不可信：连接不同机房、不同城市的传输网络（承载网）可能部分是租用的，运营商无法保证其物理上的绝对安全。2. 内部威胁：安全不能假设内部就是安全的。恶意的内部员工、被攻陷的其他网元，都可能对内部网络流量发起窃听或攻击。3. 拓扑隐藏：IPsec隧道可以隐藏网络内部的IP地址规划，增加攻击者进行网络扫描和侦察的难度。因此，通过IPsec对关键接口进行强制保护，是构建纵深防御、抵御高级威胁的必要措施。

Q2：在无认证的紧急呼叫中，既然没有任何加密和完整性保护，如何防止攻击者滥用或干扰这个流程？ A2：这是一个很好的问题，也是一个权衡的结果。虽然信令本身无保护，但网络侧仍然有多重机制来限制滥用：

  • 网络识别：AMF和gNB能识别出这是紧急呼叫，并对其进行特殊处理和高优先级调度。
  • 有限服务：无认证紧急呼叫能访问的服务被严格限制在与紧急服务中心（PSAP）的通信上，无法访问互联网或进行其他普通通信。
  • 位置信息：网络仍然可以获取并上报UE的大致位置信息，用于紧急救援和事后追溯。
  • 法规与监管：恶意拨打或干扰紧急呼叫在所有国家都是严重的违法行为。 虽然无法从密码学上完全阻止干扰，但通过这些策略和管理手段，可以最大限度地将风险控制在可接受的范围内。

Q3：5G的二次认证和我手机App里登录账号有什么区别？ A3：有本质区别。

  • App登录：是纯粹的应用层行为，通常发生在你的手机已经获得IP地址、可以上网之后。它保护的是你在这个App里的账户安全，与你的网络连接本身无关。
  • 5G二次认证：是网络连接建立过程的一部分。它决定了你能否获得一个可以访问特定数据网络（如企业内网）的IP连接。认证失败，你的手机根本无法与那个内网建立任何IP层面的通信。它是在网络层面对访问进行控制，安全等级更高，控制也更底层。

Q4：在二次认证中，SMF扮演了“穿透式认证器”的角色，这和主认证中SEAF的角色有什么异同？ A4：相同点在于，它们都遵循EAP框架，作为“中间人”透明地转发EAP消息，而不解析其具体的认证方法内容。这都体现了认证逻辑与接入控制逻辑解耦的设计思想。不同点在于它们所处的协议层面和业务场景：

  • SEAF：工作在移动性管理（MM）流程中，承载于NAS MM信令，处理的是UE接入5G网络的主认证。
  • SMF：工作在会话管理（SM）流程中，承载于NAS SM信令，处理的是UE访问特定数据网络的二次认证。 它们是5G在不同业务层面，对EAP穿透式认证器模型的两次巧妙应用。

Q5：如果我的企业使用一种非常特殊的、非EAP的认证方法，5G还能支持吗？ A5：原生支持比较困难。3GPP选择EAP作为二次认证的框架，正是看中了它的“可扩展性”，EAP已经能够支持包括密码、证书、SIM卡、令牌等在内的数十种认证方法，足以满足绝大多数企业的需求。如果企业使用一种完全私有的、非EAP的认证协议，那么可能需要开发一个“协议转换网关”，这个网关对UE侧呈现为标准的EAP-Server（由SMF访问），对企业内网侧则使用私有协议与真正的认证服务器通信。但这会增加额外的复杂性和开发成本。因此，遵循EAP框架是实现与5G网络无缝集成的最佳实践。

关系图谱