51学通信

深度解析 3GPP TS 33.501：6.1.2 认证的发起与方法选择 (谁来敲响安全的第一声钟)

20分钟阅读

深度解析 3GPP TS 33.501：6.1.2 认证的发起与方法选择 (谁来敲响安全的第一声钟?)

本文技术原理深度参考了3GPP TS 33.501 V18.9.0 (2025-03) Release 18规范中，关于“6.1.2 Initiation of authentication and selection of authentication method”的核心章节，旨在为读者详细拆解5G主认证流程是如何被触发，以及网络是如何智能地决定采用何种认证方式来“盘问”终端的。

在前几篇文章中，我们已经打下了坚实的理论基础，从5G安全的顶层架构、基本原则，一路走到了认证框架的门口。我们知道了5G认证是一个基于EAP框架、角色分明、且密钥与服务网络强绑定的精密体系。今天，我们将迈出关键一步，正式进入这个流程的起点——认证是如何被发起的，以及网络是如何选择认证方法的。

这一节是后续所有复杂认证交互（如5G AKA、EAP-AKA’）的“发令枪”。理解了“谁在何时、基于什么信息、向谁发起了请求”，我们才能清晰地把握整个安全流程的脉络。

为了更好地诠释这一过程，我们将继续我们的工业场景。主角“智行一号”，一台先进的AGV，在经历了漫长的夜晚休眠后，于清晨被工厂中央控制系统激活。它的“苏醒”，正是敲响5G安全第一声钟的时刻。我们将通过追踪它从“睡眼惺忪”到准备接受网络“身份盘问”的全过程，来生动地解读规范6.1.2的每一个细节。

1. 认证的触发：UE的注册请求 (Registration Request)

所有安全故事的开端，都源于终端（UE）的一次主动“问候”。在5G中，这个“问候”就是**注册请求（Registration Request）**消息。

The SEAF may initiate an authentication with the UE during any procedure establishing a signalling connection with the UE, according to the SEAF’s policy. The UE shall use SUCI or 5G-GUTI in the Registration Request.

这段话揭示了认证流程的触发点：

  • 时机：当UE需要与网络建立一个信令连接时，最典型的场景就是开机后的初始注册。
  • 发起者：虽然是UE发送消息，但从网络侧看，是SEAF（位于AMF中）根据本地策略，决定在收到这个注册请求后，需要发起一次认证。
  • 身份凭证：UE在这次“问候”中，会递上自己的“名片”。这张名片有两种形式：
    • SUCI：对于“智行一号”这样刚被激活，与网络还没有建立任何安全上下文的设备，它会发送SUCI（订阅隐藏标识符）。这是一个加密后的身份，用于保护隐私。
    • 5G-GUTI：如果“智行一号”只是短暂休眠后被唤醒，它可能还持有一个由网络上次分配的有效临时身份5G-GUTI。此时，它会使用5G-GUTI来发起请求，网络可以尝试通过GUTI快速找到它之前的安全上下文。

场景代入： 清晨6点，工厂中控系统激活了“智行一号”。

  1. “智行一号”的5G模组上电，它环顾四周，发现自己没有任何有效的网络连接信息。
  2. 它从自己的UICC（工业级eSIM）中读取了归属网络（工厂专网管理中心）的公钥，将自己的永久身份SUPI（例如imsi-99901...）加密，生成了一个一次性的SUCI。
  3. 它向周围信号最强的工厂5G基站发送了一条注册请求消息，消息中包含了这个SUCI，并说：“你好，我是代号‘AGV-Alpha-7’（SUCI）的设备，请求入网。”
  4. 这个请求通过基站，最终抵达了工厂5G核心网的AMF。

至此，认证流程的“发令枪”已经打响。

2. 第一跳：SEAF的“信使”角色

AMF中的SEAF功能块，作为服务网络的“前线安全官”，收到了“智行一号”的请求。它知道这是一个新来的设备，必须对其进行严格的身份核查。但SEAF本身没有能力进行最终裁决，它的职责是作为一个“穿透式认证器”，即一个忠实的“信使”。

The SEAF shall invoke the Nausf_UEAuthentication service by sending a Nausf_UEAuthentication_Authenticate Request message to the AUSF whenever the SEAF wishes to initiate an authentication. The Nausf_UEAuthentication_Authenticate Request message shall contain either:

  • SUCI, as defined in the current specification, or
  • SUPI, as defined in TS 23.501. The Nausf_UEAuthentication_Authenticate Request shall furthermore contain:
  • the serving network name, as defined in sub-clause 6.1.1.4 of the present document.

解读： SEAF的核心动作是：调用归属网络AUSF的Nausf_UEAuthentication_Authenticate服务。这个服务请求中包含了两个至关重要的信息：

  1. 用户标识：就是从UE那里收到的SUCI（或在重认证场景下的SUPI）。
  2. 服务网络名 (serving network name)：这是我们在上一章强调过的关键参数，用于将密钥和当前服务网络绑定。SEAF会根据自己的配置，生成这个字符串（例如 "5G:mcc999.mnc01"）。

场景代入： 工厂AMF中的SEAF收到了“智行一号”的SUCI。它立即执行以下操作：

  1. 它知道自己的网络ID是mcc999.mnc01，于是构建了服务网络名"5G:mcc999.mnc01"。
  2. 它找到了工厂专网的中央认证中心——AUSF的地址。
  3. 它向AUSF发送了一条Nausf_UEAuthentication_Authenticate请求，请求中包含了“智行一号”的SUCI和自己构建的服务网络名，并附上自己的“身份ID”（通过SBA的机制，如3gpp-Sbi-Originating-Network-Id头域）。请求的含义是：“认证中心你好，我这里有个新设备（SUCI），它声称想在我们网络（服务网络名）入网，请你来处理一下。”

3. 认证的守护者：AUSF的授权校验

AUSF作为归属网络的“认证中心”，收到了来自SEAF的请求。在处理这个请求之前，它必须先完成一步至关重要的、但经常被忽略的安全校验——验证SEAF的合法性。

Upon receiving the Nausf_UEAuthentication_Authenticate Request message, the AUSF shall check that the requesting SEAF in the serving network identified by the 3gpp-Sbi-Originating-Network-Id header … is entitled to use the serving network name in the Nausf_UEAuthentication_Authenticate Request.

解读： 这个校验非常精妙。AUSF会对比两个信息：

  1. 请求者的身份：通过SBA机制（如TLS证书或HTTP头域）确认的，发起这次API调用的SEAF的真实身份（例如，SEAF-A，属于PLMN-A）。
  2. 请求声称的服务网络：SEAF在请求体中填写的serving network name参数（例如，"5G:PLMN-B"）。

AUSF会检查：SEAF-A是否有权为PLMN-B网络下的用户提供服务？

在正常情况下，这两者应该是一致的。但在某些攻击或配置错误的场景下，一个属于PLMN-A的恶意/错误配置的SEAF，可能会尝试去发起对一个位于PLMN-B的用户的认证，并声称自己是PLMN-B的网络。AUSF的这一步校验，就是为了防止这种“跨域冒充”的行为，确保了只有合法的服务网络才能为其网络下的用户发起认证请求。这是保障漫游结算和防止跨网欺诈的关键一步。

4. 最终决策者：UDM的选择

AUSF确认了SEAF的合法性后，它自己仍然无法完成认证，因为它不知道用户的密钥，也不知道该用哪种认证方法。于是，它将请求进一步转发给了信息的最终源头——UDM。

整个流程如规范中的 Figure 6.1.2-1: Initiation of authentication procedure and selection of authentication method 所示：

  1. UE → SEAF: Registration Request (SUCI or 5G-GUTI)
  2. SEAF → AUSF: Nausf_UEAuthentication_Authenticate Request (SUCI or SUPI, SN name)
  3. AUSF → UDM/ARPF: Nudm_UEAuthentication_Get Request (SUCI or SUPI, SN name)
  4. UDM内部处理:
    • SUCI to SUPI de-concealment
    • Authentication Method Selection

Based on SUPI, the UDM/ARPF shall choose the authentication method.

解读： UDM在收到AUSF的请求后，执行两个核心动作：

  1. 身份揭秘：如果收到的是SUCI，UDM会立即调用其内部的SIDF功能，使用归属网络的私钥对SUCI进行解密，从而得到用户（“智行一号”）的真实、永久身份SUPI。
  2. 方法决策：UDM根据这个SUPI，查询用户的签约数据库。数据库中为每个用户都配置了允许使用的认证方法。例如，“智行一号”的档案里可能写着：“认证方法：5G AKA”。而另一个来自第三方企业的物联网设备的档案里可能写着：“认证方法：EAP-TLS，证书路径：…”。UDM会根据这个配置，做出最终的认证方法选择。

场景代入：

  1. 中央AUSF确认工厂SEAF合法后，将请求转发给UDM。
  2. UDM的SIDF模块收到SUCI，迅速解密出“智行一号”的SUPI。
  3. UDM查询“智行一号”的档案，档案上明确写着：“设备类型：AGV，安全等级：高，认证方法：5G AKA”。
  4. UDM做出决策：“使用5G AKA！”
  5. UDM随即请求其内部的ARPF模块，为“智行一号”的SUPI生成一套全新的5G认证向量（AV）。
  6. 最后，UDM将选择的认证方法（5G AKA）和生成的认证向量一起，打包在Nudm_UEAuthentication_Get Response消息中，返回给AUSF。

至此，认证的发起和方法选择阶段就全部完成了。网络的“指挥中心”已经做出了决策，并准备好了“考卷”（认证向量）。接下来的步骤，就是将这份“考卷”安全地送达“考生”（“智行一号”）手中，这将是我们下一篇文章要解读的6.1.3节 认证流程的内容。

5. 特殊情况：灾难漫游 (Disaster Roaming)

For the Disaster Roaming, the AUSF shall check the local configuration and, if allowed, the AUSF sends Nudm_UEAuthentication_Get Request to the UDM.

规范在此处提及了一个特殊场景。灾难漫游指的是在发生地震、海啸等重大自然灾害时，一个地区的通信网络可能完全瘫痪。此时，政府可能会授权其他运营商（甚至是外国运营商）临时向该地区的用户提供无差别的漫游服务。

在这种情况下，正常的漫游协议和计费系统可能无法工作。AUSF和UDM会根据运维人员配置的“灾难模式”标志，可能放宽某些授权策略（例如，允许一个没有正式漫游协议的SEAF发起认证），以最大限度地保证灾区用户的通信生命线。

6. 总结

本章通过对6.1.2节的深入解读，我们清晰地勾勒出了5G主认证流程的“前半段”——从触发到决策的完整链条。

  • 起点是UE：通过Registration Request消息敲响了认证的第一声钟，并用SUCI/GUTI表明身份。
  • SEAF是信使：它忠实地将请求和必要的本地信息（服务网络名）打包，通过SBA接口转发给AUSF。
  • AUSF是守护者：它在转发请求前，会严格校验服务网络（SEAF）的合法性，防止跨网欺诈和攻击。
  • UDM是决策者：它是整个流程的“大脑”，负责揭示用户的真实身份，并根据用户的签约档案，最终决定使用哪一套“考题”（认证方法）来考验UE。

这个设计精良的流程，通过明确的角色分工和服务化的接口调用，不仅实现了高效的认证发起，更在每一个环节都嵌入了必要的安全校验，确保了整个认证体系的健壮性和可信性。

FAQ

Q1：为什么认证方法的选择权在UDM，而不是UE或者AMF？ A1：这是由归属网络（HPLMN）掌握绝对控制权的设计原则决定的。用户的签约信息、安全等级和计费策略都由归属网络定义和管理。将认证方法的选择权集中在UDM，可以：1) 强制执行安全策略：运营商可以根据用户类型（如普通用户、物联网设备、企业用户）强制使用不同强度的认证方法。2) 简化UE和AMF：UE和AMF无需实现复杂的决策逻辑，只需支持标准化的认证方法即可，决策由网络后端统一做出。3) 便于管理和升级：运营商如果想引入新的认证方法或修改策略，只需升级和配置UDM即可，对全网的AMF和海量UE影响最小。

Q2：如果UE同时支持5G AKA和EAP-TLS，它能告诉UDM它倾向于用哪个吗？ A2：不能。在主认证流程中，UE是被动的。它通过SUCI发起请求，然后等待网络告诉它使用哪种方法。UE唯一能做的，是在更早期的能力上报中，告知网络自己“会”哪些方法。但“会”不代表“想用”，最终“用哪个”的决定权完全在UDM。

Q3：在私人5G网络（SNPN）中，这个流程还适用吗？UDM和AUSF在哪里？ A3：逻辑上完全适用，但物理部署可能不同。在一个大型工厂的5G专网中，UDM和AUSF这些逻辑功能依然存在，它们可能被集成在一个或几个物理服务器中，部署在工厂的数据中心里。当“智行一号”（UE）接入工厂基站（gNB），工厂的AMF/SEAF会联系工厂自己的UDM/AUSF。整个流程在企业内网闭环。在这种场景下，UDM的签约档案可能会配置使用EAP-TLS，并指向企业内部的AAA服务器，以实现与企业现有IT身份认证体系的集成。

Q4：图6.1.2-1中，从UE到UDM的请求链条很长，这会影响连接建立的速度吗？ A4：会产生一定的时延，但这部分时延是初始接入时一次性的开销，通常在百毫秒级别。3GPP在设计时已经考虑了性能。一旦主认证成功，UE会获得一个GUTI和一套完整的安全上下文。在后续的移动、空闲态唤醒等场景中，UE可以直接使用GUTI与AMF进行快速、低时延的交互，而无需再走一遍这个完整的、跨越多网元的认证流程。这是一种“先慢后快”的设计，用一次性的较高开销，换取了后续长期、高效、安全的服务。

Q5：SEAF向AUSF发送的Nausf_UEAuthentication_Authenticate请求和AUSF向UDM发送的Nudm_UEAuthentication_Get请求，内容上有什么区别？ A5：它们在逻辑链条上是上下游关系，内容有继承也有不同。

  • Nausf_UEAuthentication_Authenticate（从SEAF到AUSF）的核心意图是“请你认证这个用户”。它携带了用户的（可能加密的）身份和认证发生的服务网络环境。
  • Nudm_UEAuthentication_Get（从AUSF到UDM）的核心意图是“请给我这个用户的认证材料和方法”。AUSF在收到上一个请求并校验SEAF合法性后，向UDM发起的这个请求。它本质上是请求UDM提供执行认证所需的“弹药”（认证向量）和“行动指南”（认证方法）。所以，它的输出（Response）会包含认证向量等具体密码学材料，而Nausf_UEAuthentication_Authenticate的最终输出则是认证结果（成功/失败）和K_SEAF。

关系图谱