如 RFC 6696 [59] 中所述，可以使用 EAP 重新认证协议 (ERP)，以使 UE 在同一 TNGF 区域内从源 TNAP 移动到目标 TNAP，而无需执行完整的验证。

        为了支持 EAP 重新认证，图 4.12a.2.2-1 中指定的 5GC 注册过程应能够支持 RFC 6696 [59] 中指定的 ERP 隐式引导。特别是，为了支持 EAP 重新认证，图 4.12a.2.2-1 中规定的 5GC 注册过程应扩展如下：

• - TNGF 应将功能实现为本地 EAP 重新认证（ER）服务器。

• - 在步骤 6b 中，从 TNGF 发送到 AMF 的包含 NAS 注册请求的 N2 消息还应包含 ERP 请求，这表明需要 EAP 重新认证根密钥（rRK）。如有必要，ERP 请求还可能包含一个域名，在这种情况下，请求一个特定于域的 rook 密钥 (DSRK)（参见 RFC 6696 [59]）。在步骤 8a 中，ERP 请求被发送到 AUSF。

• - 在步骤 8b 中成功认证后，AUSF 通过应用 RFC 5295 [60] 中的过程从扩展主会话密钥 (EMSK) 创建 EAP 重新认证根密钥 (rRK)。如果在步骤 8a 中接收到域名，则改为创建 DSRK。

• - 在步骤 8c 中，AUSF 发送一个 ERP 响应，其中包含创建的 EAP 重新认证根密钥（例如 rRK 或 DSRK）以及其他信息，例如根密钥生存期和 EMSK 名称，如 RFC 6696 [59 ]。 ERP 响应在步骤 9a 中被转发到 TNGF。

• - TNGF 应用接收到的 EAP 重认证根密钥来派生其他 EAP 重认证密钥，例如重认证完整性密钥 (rIK)。这些密钥存储在 TNGF 中，稍后在启动 EAP 重新身份验证过程时使用。

  注意：预计 SA WG3 将确认上述步骤，并将定义如何创建重新认证根密钥 (rRK)。

  使用 ERP 隐式引导完成 5GC 注册后，可以在移动事件期间应用 EAP 重新身份验证，如下图所示。

                                        图 4.12a.9-1：当 UE 移动到另一个 TNAP 时的 ERP 交换

• - 当 UE 移动到与源 TNAP 域属于同一 ERP 域的目标 TNAP 时，按照 RFC 6696 [59] 中的规定启动 EAP 重新认证过程。在步骤 1 中，UE 通知目标 TNAP 它支持 ERP。

• - UE 在 5GC 注册过程中导出与 TNGF 导出的相同的 EAP 重新认证密钥（例如在步骤 3 中）。

• - 步骤 4 中的 EAP-Initiate/Re-auth 和步骤 5 中的 EAP-Finish/Re-auth 都使用 UE 和 TNGF 中独立创建的重新验证完整性密钥进行完整性保护。如果这些完整性密钥相同，则 EAP 重新认证过程成功，并且重新认证 MSK (rMSK) 密钥用于在 UE 和目标 TNAP 之间建立安全上下文。

• - 上图假设分配给 UE 的 IP 地址在移动事件期间没有改变。因此，在步骤 1-6 之后，UE 可以使用相同的 IP 地址通过现有的 NWt 连接恢复与 TNGF 的通信。

• - UE 可以基于在 QoS 流建立或修改期间接收到的附加 QoS 信息来保留非 3GPP 特定的 QoS 资源。如果 UE 决定为与子 SA 关联的 QoS 流保留非 3GPP 接入的 QoS 资源，但未能保留这些资源，则 UE 应释放关联的 IKEv2 Child SA。在这种情况下，TNGF 启动 PDU 会话修改过程，如第 4.3.3.2 节中步骤 1e 中所述。

资料来源：TS 23.502 4.12

整理：kangguoying20220519