51学通信

深度解析 3GPP TR 33.898：5 Solutions (Part 1 - 复用现有机制：5G安全的“旧瓶装新酒”)

19分钟阅读

好的，这是系列文章的第五篇。我们正式进入TR 33.898最核心的章节——解决方案。由于本章包含六个不同的解决方案，我们将分几篇文章进行连载。本文将首先聚焦于那些主张“复用现有能力”的解决方案。

深度解析 3GPP TR 33.898：5 Solutions (Part 1 - 复用现有机制：5G安全的“旧瓶装新酒”)

本文技术原理深度参考了3GPP TR 33.898 V18.0.1 (2023-07) Release 18规范中，关于“Chapter 5.1, 5.3, 5.4, 5.5”的核心章节，旨在为读者深入剖析在应对5G+AI带来的新安全挑战时，3GPP如何巧妙地利用并扩展已有的安全框架（如OAuth 2.0, CAPIF, UDM用户同意机制），构建出高效、务实且对网络影响最小的第一道防线。

引言：陈思的“务实”之道

在上一篇文章中，“智行一号”的安全架构师陈思，已经清晰地认识到了KI#1这道“考题”的严峻性。她知道，为5G+AI的融合保驾护航，核心在于解决好“辅助信息”暴露时的隐私与授权问题。

现在，作为一名经验丰富的工程师，陈思的第一反应并非天马行空地去设计一套全新的、革命性的安全体系。她首先想到的，是打开5G系统的“工具箱”，仔细盘点一下里面是否已经有现成的、可以稍加改造就能解决新问题的工具。这是一种务实、高效的工程哲学，也是3GPP标准演进的核心思想之一——最大化地复用和继承。

这正是TR 33.898第五章Solutions中，Solution #1, #3, #4, 5这四个解决方案共同的核心思想。它们如同经验丰富的老将，试图用久经沙场的“旧武器”，来迎战“AI/ML”这个新敌人。今天，我们就将跟随陈思，深入探索这场精彩的“旧瓶装新酒”的实践。

1. 核心武器库：OAuth 2.0 与 CAPIF

在深入具体方案之前，我们必须先了解5G安全工具箱中两件最核心、也是被复用得最多的“神器”。

  • OAuth 2.0：一个行业标准的授权框架。它允许第三方应用（客户端）在不获取用户密码的情况下，通过“令牌（Token）”的方式，有限地访问用户在某个服务（资源服务器）上的资源。在5G核心网内部，网络功能（NF）之间的服务化接口调用，就是通过基于OAuth 2.0的机制进行相互授权的。
  • CAPIF (Common API Framework)：3GPP定义的通用API框架。它是5G网络能力向第三方应用（AF）开放的“安全门户”。它本身就集成了一套基于OAuth 2.0的、用于对AF进行身份认证和授权访问的完整流程。

简单来说，OAuth 2.0是5G网络内部“官对官”的授权法则，而CAPIF则是“官对民”（网络对应用）的授权法则。

2. Solution #1 & #3：面向外部AF的“门户守卫”

Solution 1和3的核心思想非常直接：既然我们已经有CAPIF这个强大的“门户”来管理外部AF的访问，那为什么不直接用它来授权AI/ML辅助信息的请求呢？

Solution #1: Reusing existing mechanism for authorization of 5GC assistance information exposure to AF …reusing the OAuth-based authorization mechanism as depicted in clause 12.4 in TS 33.501 . If CAPIF is used, authorization method … in clause12.5 in TS 33.501 is reused. Solution #3: Reusing existing authorization mechanism for internal or external AF For the AI/ML AF that is external to the operator’s network, the NEF authorizes the external AF’s service request using OAuth-based authorization mechanism … If NEF supports CAPIF for external exposure, the CAPIF authorization mechanism … can be reused.

深度解析：

这两套方案在本质上是高度一致的，都指向了同一个核心机制——复用TS 33.501（5G安全架构）中为外部AF定义的、基于CAPIF和OAuth 2.0的授权流程。

2.1 工作流程回顾

这个流程，可以被看作是AF进入5G网络获取数据的“标准安检流程”：

  1. 注册与认证：AF首先需要在NEF（网络开放功能）上进行注册，获得自己的“身份ID”。
  2. 请求授权：当AF需要访问某个网络能力时（比如，请求“智行一号”的辅助信息），它会向NEF发起授权请求。
  3. NEF进行授权决策：NEF作为“安检官”，会检查AF的“身份ID”是否合法，以及它所请求的权限（访问哪些数据）是否在允许的范围内。
  4. 发放令牌：如果授权通过，NEF会向AF发放一个有时效性的访问令牌（Access Token）。
  5. 凭令牌访问：AF在后续的每一次数据请求中，都必须携带这个令牌。NWDAF等数据提供方，在收到请求后，会首先验证令牌的有效性，然后再提供数据。

陈思的理解： 这套流程非常成熟和稳健。对于AI/ML的新需求，我们无需改变整个安检流程。需要做的，只是在“安检规则”中，增加一些新的检查项。

3. Solution #4：在“安检”中加入“用户同意”检查

Solution 1和3解决了“AF是否有权访问网络”的问题，但它们没有明确回答一个更深层次的问题：“AF的这次访问，用户同意了吗？” Solution 4则完美地补上了这一环。

Solution #4: Authorization for 5GC assistance information exposure to external AF The NEF determines whether the user consent check is needed based on the service request and operator’s local policy… If there is no user consent parameter in the NEF’s UE context, the NEF sends the Nudm_SDM_Get Request message to the UDM…

深度解析：

这个方案的核心，是在NEF的授权决策流程中，内嵌了一个“检查用户同意”的子流程。其详细步骤在Figure 5.4.2-1中有清晰的描绘。

3.1 “用户同意”检查流程

  • 场景：一个外部的“智能交通”AF，向NEF请求获取“智行一号”的实时位置信息，用于优化交通灯配时。
  1. 触发检查（Step 4）：NEF在收到请求后，根据预设的策略（例如，策略规定“凡是涉及高精度位置信息的请求，都必须检查用户同意”），决定需要启动“用户同意”检查。
  2. 查询UDM（Step 5 & 6）：NEF发现自己的缓存中没有关于“智行一号”车主陈思的同意信息，于是它向**UDM（统一数据管理）**发送一个查询请求（Nudm_SDM_Get），请求获取陈思的“用户同意参数（User consent parameter）”。这个参数，就是陈思在办理业务时，通过App或营业厅明确授权的隐私偏好。
  3. 执行检查（Step 7）：UDM将陈思的同意参数返回给NEF。例如，参数中写着：“同意‘智能交通’服务在每日高峰期（7-9点，17-19点）访问我的车辆位置，精度为区域级”。NEF作为“执行点（enforcement point）”，会将当前AF的请求与这个同意参数进行比对。
  4. 最终决策（Step 8）：如果当前时间是上午8点，且AF请求的是区域级位置，则NEF认为请求符合用户同意，授权通过。如果当前是中午12点，或者AF请求的是米级精度位置，则NEF会拒绝此次请求。

陈思的设计： 她恍然大悟！这套方案极其精妙。它将网络对AF的授权和用户对服务的授权，在NEF这个点上完美地结合了起来。NEF不仅是网络的“门户”，更是用户隐私意愿的“忠实执行者”。

This solution based on the existing service authorization mechanism for the external AF acquires 5GC assistance information. The NEF is deemed as the enforcement point to check user consent and whether privacy related data can be exposed.

4. Solution #5：面向内部AF的“内部通行证”

前面的方案都聚焦于外部AF。那么，如果AI/ML应用是运营商自己的，部署在核心网内部，又该如何授权呢？Solution 5给出了答案。

Solution #5: Authorization for 5GC assistance information exposure to internal AF This solution … is proposed to reuse the existing OAuth 2.0 based authorization of NF service access for the AF that is internal to the operator’s network.

深度解析：

  • 核心思想：对于内部AF，我们可以将它“视同于”一个普通的网络功能（NF），直接复用5G核心网内部NF之间的授权机制。
  • 工作流程 (Figure 5.5.2-1)：
    1. 向NRF请求令牌（Step 2 & 3）：内部AF首先向NRF（网络功能仓库功能）发起请求，声明自己的身份，并请求一个用于访问NWDAF的Access Token。NRF在这里扮演了OAuth 2.0授权服务器的角色。
    2. 凭令牌访问（Step 4）：AF在获得NRF颁发的令牌后，携带该令牌去访问NWDAF。
    3. 同样的用户同意检查（Step 5-8）：NWDAF/NEF在收到请求后，同样可以（如果策略需要）启动向UDM查询用户同意参数的流程，与Solution 4完全一致。

陈思的总结： 无论是外部AF还是内部AF，5G的安全设计都遵循了统一的、基于Token的授权哲学。区别仅仅在于，外部AF的“令牌”由NEF颁发，而内部AF的“令牌”由NRF颁发。这种统一性，极大地简化了系统的设计和实现。

5. 总结：“最小化影响”的智慧

通过对这四个“复用派”解决方案的深入分析，陈思深刻地体会到了3GPP在标准设计中所蕴含的“最小化影响（No Impact / Low Impact）”的智慧。

  • 不动摇根基：所有方案都建立在TS 33.501和TS 33.122这两大安全基石之上，无需对5G的整体安全架构进行伤筋动骨的改造。
  • 不重复造轮子：它们没有去发明一套全新的授权协议，而是巧妙地将成熟、健壮的OAuth 2.0和CAPIF框架，应用到了AI/ML这个新场景。
  • 精巧的“插件式”扩展：唯一的“新意”，是在授权流程中，增加了一个查询和执行“用户同意”的逻辑。这就像是在一个已经稳定运行的系统中，增加了一个可插拔的“插件”，既增强了功能，又将对原有系统的影响降到了最低。

这种“旧瓶装新酒”的思路，也许在理论上不如一个全新设计的方案来得“完美”，但它在工程上的可行性、经济上的合理性、以及部署上的快捷性，使其成为了在标准化初期，最明智、最务实的选择。它确保了像“智行一号”这样的AI应用，能够在不颠覆现有安全体系的前提下，快速、安全地融入5G生态。

FAQ 环节

Q1：为什么Solution 1和3看起来几乎一样？它们有什么区别？ A1：它们在核心思想上确实高度重合，都主张复用现有的外部AF授权机制。在TR的演进过程中，不同的公司可能会提出相似的方案，它们在一些细节或侧重点上可能略有不同。最终，这些方案的思想会被融合，并在结论中形成一个统一的共识。对于读者而言，可以将它们理解为同一个思路的两种不同表述。

Q2：NEF在检查用户同意时，如果UDM中没有相关的“同意参数”，会发生什么？ A2：这取决于运营商的默认策略。

  • 保守策略（默认拒绝）：如果查询不到明确的“同意”记录，NEF会直接拒绝AF的请求。这是对用户隐私最安全的保护方式。
  • 开放策略（默认允许，但不推荐）：在某些非敏感数据场景下，运营商可能会设置默认允许的策略。
  • 动态授权：更高级的系统，在查询不到预设同意时，可能会触发一个实时的用户授权流程，例如，向用户的手机App推送一个授权请求，由用户实时决定是否同意。

Q3：用户同意参数是存储在UDM中的，用户（比如陈思）该如何去设置和修改它呢？ A3：UDM是核心网内部的网元，用户无法直接访问。用户需要通过运营商提供的**门户（Portal）**来管理自己的隐私设置。这个门户可以是：

  • 手机App：运营商的官方App中，提供一个“隐私与授权管理”的界面。
  • Web门户：运营商的网上营业厅。
  • 实体营业厅：通过客服人员进行设置。 当用户在这些门户上做出修改后，这些设置会被同步到UDM中，存储为用户的签约数据的一部分。

Q4：为什么内部AF和外部AF的授权服务器不同（一个是NRF，一个是NEF）？ A4：这是由它们在网络中的“角色定位”决定的。

  • NRF（网络功能仓库功能）：它的核心职责是管理和发现“内部公民”（即所有的NF）。因此，由它来担任内部授权的“认证中心”，是最合乎逻辑的。
  • NEF（网络开放功能）：它的核心职责是管理和验证“外来访客”（即第三方AF）。因此，由它来担任对外开放的“安检官”和“签证处”，也是职责所在。 这种职责的分离，使得网络内部和外部的安全策略可以独立演进，权责清晰。

Q5：这些“复用”的方案，能完全解决AI/ML的隐私和授权问题吗？它们有没有局限性？ A5：它们提供了一个强大且务实的基础框架，但并非没有局限性。这些方案主要解决了“谁（AF）可以访问”和“是否同意访问”这两个问题。但AI/ML场景可能还涉及更复杂的隐私需求，例如：

  • 数据使用目的的限制：用户可能同意AF访问其位置用于“交通优化”，但不同意用于“广告推送”。
  • 联合隐私：当多个用户的数据被联合分析时，如何保护“群体”的隐私。
  • 算法的透明度：用户是否有权知道AF将如何使用其数据来训练模型。 这些更深层次的问题，正是后续的Solution 2和6等方案试图去探索和解决的。我们将在下一篇文章中深入探讨。

关系图谱