Apex Standards 3GPP Meeting Tracker

---

updated as of Thu, Apr 13, 2023, 07:14 AM UTC (4 days ago)
Thu, Apr 13, 12:14 AM California
Thu, Apr 13, 09:14 AM Berlin/Paris
Thu, Apr 13, 03:14 PM Beijing

3GPP-S3-110-AdHoc-e    Agenda Item 1.0 : Agenda and Meeting Objectives

3GPP-S3-110-AdHoc-e    Agenda Item 3.0 : Reports and Liaisons from other Groups (related to Rel-18 release content only)

- TDoc S3-231703 and S6-230351 discuss the user consent for UE location sharing, and SA6 requests SA3 guidance on whether an EEC’s EEL signalling can include information it receives from an AC related to other UEs.
- Solution #29 assumes that during an initial phase, the application clients (ACs) exchange UE locations via application layer signalling, and SA6 considers the application layer mechanism for sharing the location outside the scope of 3GPP.
- TDoc S3-231704 discusses the support for location event reporting over a user plane connection by a UE to an LCS Client or AF for a deferred periodic or triggered 5GC-MT-LR.
- SA2 asks CT1 and CT3 to comment on suitable types of user plane address for an LCS Client or AF and the transport protocols and application level messages that may be suitable to transfer location event reports.
- TDoc S3-231705 discusses the user plane connection between UE and LMF, which can be used to transfer LPP message and supplementary service event report between UE and LMF.
- SA2 kindly asks SA3 to comment on security information and security procedures and protocols that might be used between UE and LMF.
- TDoc S3-231713 discusses the possible content of the authorization token, which is described in 3GPP TR28.817, Clause 7.1.4.
- SA5 is working on the E/WBI API requirements as part of eECM and FS_MEC_ECM WID and SID respectively.
- TDoc S3-231714 discusses the alignment of SA3 security aspects for Personal IoT Networks and informs SA3 that TS 23.542 defines service procedures of the PIN enablement layer that require authorization and/or authentication between various PIN participants.
- TDoc S3-231919 discusses the need for EEC’s EEL signalling including the information received from an AC related to other UEs rather than resolving it between ACs at the application layer, and SA6 requests more elaboration on this.

1. IPX providers should be able to provide IP transport for roaming signalling and payload messages between PLMNs and their roaming partners, without the need for direct physical connections.
- "IPX Providers shall have the ability to provide IP transport to route roaming signalling and payload messages between PLMNs and their roaming partners, to avoid the need for direct physical connections between PLMNs."

2. Operator and subscriber identity should be identifiable in signalling messages for analytic services and troubleshooting purposes.
- "Identify operator and subscriber identity in signalling messages for analytic services and troubleshooting purposes."

3. In a relation between RVAS provider and client MNO, N32 connections per sponsor-client pair are suggested to maintain visibility of VPLMN-ID to the client MNO.
- "GSMA 5GMRR suggest using N32 for this purpose, where N32 connections per sponsor-client pair are conceivable, and where VPLMN-ID remains visible to the client MNO."

4. The Roaming Hubbing service should provide services outside a PLMN's domain without the need for PLMNs to establish direct network relations with each other.
- "Provide services outside a PLMN’s domain, without the need for PLMNs to establish direct network relations with each other, and without impacting how the roaming partners of the Client Operators operate."

5. L-PRINS provides a solution for when an intermediary is providing a service other than IP routing, and enables both RH and Service Hub full access to Http messages exchanged over N32-f and N32-c.
- "The L-PRINS provides a single solution for all the use cases where an intermediary is providing a service other than IP routing, e.g., Roaming Hub, IPX, RVAS, while increasing the traceability, attribution, and non-repudiation over N32 interface while at the same time enabling both the RH and Service Hub full access to the Http messages exchanged over N32-f and N32-c."

6. In a deployment without a local SEPP, the roaming hub should rely on the SEPP of the roaming hub for all roaming connections and the solution should scale accordingly.
- "5GMRR was referring to the deployment in which the PLMN1 [...] does not have a local SEPP but rather relies on the SEPP of the roaming hub for all the roaming connections including direct bilateral roaming between PLMN 1 and PLMN 2. The solution should therefore scale accordingly."

7. E2 Data Session Control is not specifically mentioned in the TDoc.

TDoc S3-231715:

Technical difference: Use of UE provided information in Nnef_UEId_Get service
- The UE Identifier API has been enhanced to accept the EEC as a consumer of the service
- The EES may utilize the Nnef_UEId_Get service providing the User information provided by the EEC
- SA6 requests SA3 to discuss providing a security solution based on the use of UE provided information

Example snippet from TDoc S3-231715 to support the difference:
"To fulfil this request, the EES may utilize the Nnef_UEId_Get service (clause 4.15.10 of 3GPP TS 23.502) providing the User information provided by the EEC, i.e., private UE IP address, where SA6 acknowledges SA3 has indicated that information received from UE should be verified."

TDoc S3-231716:

Technical difference: Signaling procedure for PC5-only positioning
- RAN2 discussed the overall signaling procedure for PC5-only positioning
- The sidelink positioning procedure comprises several steps including triggering event, sidelink positioning capability exchange, sidelink positioning assistance data transfer, SL Positioning Request Location Information, measurement of SL-PRS, location calculation, and SL Positioning Provide Location Information
- Steps may have dependencies on SA2 and can be revisited in this light

Example snippet from TDoc S3-231716 to support the difference:
"The sidelink positioning procedure comprises the following series of steps as a baseline, between the LMF/positioning server UE/NG-RAN/candidate Anchor UE(s) and Target UE(s): Triggering event Sidelink positioning capability exchange Sidelink positioning assistance data transfer SL Positioning Request Location Information Measurement of SL-PRS Location calculation SL Positioning Provide Location Information"

TDoc S3-231965:

Technical difference: Use of AFId parameter value in EES invocation of Nnef_UEId_Get service
- SA3 thanks SA6 for the LS on AFId parameter value in EES invocation of Nnef_UEId_Get service
- SA3 acknowledges that EASId can be used in the Nnef_UEId_Get service request

Example snippet from TDoc S3-231965 to support the difference:
"Therefore, SA3 acknowledges that EASId can be used in the Nnef_UEId_Get service request."

TDoc S3-231966:

Technical difference: Authentication of EEC/UE in FS_eEDGEAPP solution
- SA3 confirms that EES can use the UE provided information
- EEC/UE has been already authenticated by EES, which means the EEC/UE can be trusted by EES

Example snippet from TDoc S3-231966 to support the difference:
"SA3 would like to reply that EEC/UE has been already authenticated by EES, which means, the EEC/UE can be trusted by EES, therefore, SA3 confirms that EES can use the UE provided information."

Technical differences and examples from TDoc S3-231707, S3-231710, S3-231758, and S3-231964 are:

1. UE specific data and/or analytics exchange between HPLMN and VPLMN:
- SA2 sent a LS to GSMA asking for feedback on data and analytics exchange in roaming case between HPLMN and VPLMN
- SA2 is waiting for feedback from GSMA on the need for UE-specific data and/or analytics to be exchanged between VPLMN and HPLMN
- NF load analytics is not UE-specific, and may or may not use UE-specific data as input for analytics
- Example: "Does GSMA have any concerns or requirements (e.g. about being subject to local regulations, operator policies, user consent) on UE specific data and/or analytics exchange between HPLMN and VPLMN, and possible storage (and its duration) of such user data in the VPLMN?"

2. Security aspects between UE and AF:
- SA2 asks SA3 to comment on security information and security procedures and protocols that might be used to establish the user plane connection and subsequently report location events over it
- TLS could be used for the communication security between a UE and AF, but there are other security aspects that need further study
- SA3 proposes a security solution based on TLS between the UE and LMF
- Example: "SA2 kindly asks SA3 to comment on security information (provided by LMF to UE to establish the user plane connection which subsequently transfer LPP message and supplementary service event report) and security procedures and protocols that might be used between UE and LMF."

3. Management of roaming connections on behalf of the client MNO:
- The group acknowledges the requirement on IPX provider to support a hosted SEPP service managing roaming connections on behalf of the client MNO
- Regional Breakout should not be standardized due to security impacts when the IPX is compromised
- SA3 will study the requirements and consult with other groups to investigate any potential gaps between the current specifications and the requirements
- Example: "On the topic of management of roaming connections under Requirements for Specific Services, the group also acknowledges the requirement on IPX provider to support a hosted SEPP service managing roaming connections on behalf of the client MNO."

3GPP-S3-110-AdHoc-e    Agenda Item 4.1 : ProSe Secondary Authentication

- In TDoc S3-231773 and S3-231774, the SMF may check if the 5G ProSe Remote UE has been authenticated by the same DN indicated in the subscription data and trigger PDU Session secondary authentication if necessary.
- In TDoc S3-231773, the SMF triggers the secondary authentication by sending a PDU Session Authentication Command message to the 5G ProSe Layer-3 UE-to-Network Relay, while in TDoc S3-231774, the 5G ProSe Layer-3 UE-to-Network Relay stores the 5GPRUK ID upon successful security establishment and sends a DCA message to the Remote UE.
- In TDoc S3-231775 and S3-231776, EAP messages for Re-authentication are exchanged between the Remote UE and DN-AAA using PC5 transport provided via the PC5 link with the UE-to-Network Relay.
- In TDoc S3-231776, the SMF retrieves the corresponding 5GPRUK ID from the 5G ProSe Layer-3 UE-to-Network Relay's SM context using the GPSI.
- In TDoc S3-231777, the SMF triggers the secondary authentication of the 5G ProSe Remote UE based on subscription information and local configuration when it receives a NAS message from the 5G ProSe UE-to-Network Relay. The DN AAA server decides to initiate Secondary Re-Authentication for the 5G ProSe Remote UE.

Example snippets from the original TDoc supporting the difference highlighting:

- TDoc S3-231773: "The SMF triggers a PDU Session secondary authentication of 5G ProSe Remote UE via 5G ProSe Layer-3 UE-to-Network Relay by sending PDU Session Authentication Command message to the 5G ProSe Layer-3 UE-to-Network Relay including the 5GCP-PRUK ID of the Remote UE and an EAP-Request/Identity."
- TDoc S3-231774: "Upon successful security establishment, the 5G ProSe Layer-3 UE-to-Network Relay stores the 5GPRUK ID as described in clause 6.3.3.3.2 and sends a DCA (Direct Communication Accept) message to the Remote UE."
- TDoc S3-231775: "The EAP messages for Re-authentication are exchanged between the Remote UE and DN-AAA using PC5 transport provided via the PC5 link with the UE-to-Network Relay."
- TDoc S3-231776: "The SMF retrieves the corresponding 5GPRUK ID from the 5G ProSe Layer-3 UE-to-Network Relay's SM context using the GPSI."
- TDoc S3-231777: "The SMF of the 5G ProSe UE-to-Network Relay triggers the secondary authentication of the 5G ProSe Remote UE based on the subscription information and the local configuration of the SMF when it receives a NAS message (e.g. Remote UE Report) from the 5G ProSe UE-to-Network Relay."

- TDoc S3-231887: In case of secondary authentication, the SMF triggers a PDU Session secondary authentication of 5G ProSe Remote UE via 5G ProSe Layer-3 UE-to-Network Relay by sending a PDU Session Authentication Command message to the 5G ProSe Layer-3 UE-to-Network Relay including the PRUK ID of the Remote UE and an EAP-Request/Identity. The SMF may request the 5G ProSe Layer-3 UE-to-Network Relay to release the PC5 link with the revoked 5G ProSe Remote UE, or release the PDU Session of the 5G ProSe Layer-3 UE-to-Network Relay as specified in clause 4.3.4 of TS 23.502 3b.
- TDoc S3-231931: In case of secondary authentication, the SMF triggers a PDU Session secondary authentication of 5G ProSe Remote UE via 5G ProSe Layer-3 UE-to-Network Relay by sending a PDU Session Authentication Command message to the 5G ProSe Layer-3 UE-to-Network Relay including the 5GPRUK ID of the Remote UE and an EAP-Request/Identity. As part of the discovery procedure, the 5G ProSe Remote UE learns about the connectivity service the 5G ProSe Layer-3 UE-to-Network Relay provides (e.g. based on a broadcasted service code) and sends PDU Session Authentication Complete message to the SMF including the 5GPRUK ID of the Remote UE and an EAP-Response/Identity received from the 5G ProSe Remote UE.
- TDoc S3-231935: In case of secondary authentication, the SMF triggers a PDU Session secondary authentication of 5G ProSe Remote UE via 5G ProSe Layer-3 UE-to-Network Relay by sending a PDU Session Authentication Command message to the 5G ProSe Layer-3 UE-to-Network Relay including the 5GPRUK ID of the Remote UE and an EAP-Request/Identity. As part of the discovery procedure, the 5G ProSe Remote UE learns about the connectivity service the 5G ProSe Layer-3 UE-to-Network Relay provides (e.g. based on a broadcasted service code) and upon successful security establishment, the 5G ProSe Layer-3 UE-to-Network Relay stores the 5GPRUK ID as described in clause 6.3.3.3.2 and sends a DCA (Direct Communication Accept) message to the Remote UE. The Relay shall additionally include the 5GPRUK ID in the subsequent NAS messages.
- TDoc S3-231936: In case of secondary authentication, the SMF triggers a PDU Session secondary authentication of 5G ProSe Remote UE via 5G ProSe Layer-3 UE-to-Network Relay by sending a PDU Session Authentication Command message to the 5G ProSe Layer-3 UE-to-Network Relay including the 5GPRUK ID of the Remote UE and an EAP-Request/Identity. As part of the discovery procedure, the 5G ProSe Remote UE learns about the connectivity service the 5G ProSe Layer-3 UE-to-Network Relay provides (e.g. based on a broadcasted service code) and the SMF sends Remote UE Report Ack message to the 5G ProSe Layer-3 UE-to-Network Relay indicating the result of the PDU Session secondary authentication, including the 5GPRUK ID of the remote UE and an EAP success or failure message.

Snippet from TDoc S3-231887: "the SMF triggers a PDU Session secondary authentication of 5G ProSe Remote UE via 5G ProSe Layer-3 UE-to-Network Relay by sending PDU Session Authentication Command message to the 5G ProSe Layer-3 UE-to-Network Relay including the PRUK ID of the Remote UE and an EAP-Request/Identity"; "the SMF may request the 5G ProSe Layer-3 UE-to-Network Relay to release the PC5 link with the revoked 5G ProSe Remote UE, or release the PDU Session of the 5G ProSe Layer-3 UE-to-Network Relay as specified in clause 4.3.4 of TS 23.502 3b."

Snippet from TDoc S3-231931: "the SMF triggers a PDU Session secondary authentication of 5G ProSe Remote UE via 5G ProSe Layer-3 UE-to-Network Relay by sending a PDU Session Authentication Command message to the 5G ProSe Layer-3 UE-to-Network Relay including the 5GPRUK ID of the Remote UE and an EAP-Request/Identity"; "sends PDU Session Authentication Complete message to the SMF including the 5GPRUK ID of the Remote UE and an EAP-Response/Identity received from the 5G ProSe Remote UE."

Snippet from TDoc S3-231935: "the SMF triggers a PDU Session secondary authentication of 5G ProSe Remote UE via 5G ProSe Layer-3 UE-to-Network Relay by sending a PDU Session Authentication Command message to the 5G ProSe Layer-3 UE-to-Network Relay including the 5GPRUK ID of the Remote UE and an EAP-Request/Identity"; "the 5G ProSe Layer-3 UE-to-Network Relay stores the 5GPRUK ID as described in clause 6.3.3.3.2 and sends a DCA (Direct Communication Accept) message to the Remote UE. The Relay shall additionally include the 5GPRUK ID in the subsequent NAS messages."

Snippet from TDoc S3-231936: "the SMF triggers a PDU Session secondary authentication of 5G ProSe Remote UE via 5G ProSe Layer-3 UE-to-Network Relay by sending a PDU Session Authentication Command message to the 5G ProSe Layer-3 UE-to-Network Relay including the 5GPRUK ID of the Remote UE and an EAP-Request/Identity"; "the SMF sends Remote UE Report Ack message to the 5G ProSe Layer-3 UE-to-Network Relay indicating the result of the PDU Session secondary authentication, including the 5GPRUK ID of the remote UE and an EAP success or failure message."

TDoc S3-231778:

- The issue relates to the potential need for SMF of the UE-to-Network Relay to be notified of Remote UE subscription information update.
- SA3 wants SA2 feedback on whether and how the SMF gets notified about such a Remote UE's subscription update.
- SA3 also wants feedback on whether this issue applies more generally for any Remote UE accessing the network via a L3 UE-to-Network Relay (i.e., with or without Secondary authentication).

Example snippet from the original TDoc:

- "SA3 has discussed a remaining open issue related to potential need for SMF of the UE-to-Network Relay to be notified of Remote UE subscription information update (e.g., ProSe, DNN or S-NSSAI) and would like SA2 feedback about:"

TDoc S3-231952:

- SA3 is discussing the support of ProSe Secondary Authentication.
- SA3 understands that the support of ProSe Secondary Authentication has implications for the 5GS architecture and procedures and collaboration with SA2 is required.
- SA3 wants feedback on the attached draft CR(s) (not agreed yet).

Example snippet from the original TDoc:

- "SA3 is discussing the support of ProSe Secondary Authentication. Per /S2-2207838, SA3 understands that the support of ProSe Secondary Authentication has implication to the 5GS architecture and procedures and collaboration with SA2 is required, and therefore would like to get feedback on the attached draft CR(s) (not agreed yet)."

3GPP-S3-110-AdHoc-e    Agenda Item 4.11 : New WID on DTLS protocol profile for AKMA and GBA

TDoc S3-231841:
- Describes the use of HTTPS for accessing network application functions in the Generic Authentication Architecture (GAA) (3GPP TS 33.222).
- Outlines the security architecture and procedures for the 5G system (3GPP TS 33.501).
- Provides semantics and content for HTTP/1.1 (IETF RFC 7231).
- Specifies the system architecture for the 5G system (3GPP TS 23.501).
- Defines unified data management services for the 5G system (3GPP TS 29.503).
- References the Common API Framework for 3GPP Northbound APIs (3GPP TS 23.222).
- Provides vocabulary for 3GPP specifications (3GPP TR 21.905).

TDoc S3-231842:
- Discusses the security aspects of non-3GPP accesses in the System Architecture Evolution (SAE) (3GPP TS 33.402).
- Details the characteristics of the IP Multimedia Services Identity Module (ISIM) application (3GPP TS 31.103).
- Provides authentication and key management for applications based on 3GPP credentials in the 5G system (3GPP TS 33.535).
- Supports subscriber certificates in the Generic Authentication Architecture (GAA) (3GPP TS 33.221).
- Defines the security architecture for the SAE (3GPP TS 33.401).
- Specifies the bootstrapping and network application function interfaces for the 5G system (3GPP TS 24.109).
- Provides the system architecture for the 5G system (3GPP TS 23.501).
- Outlines the use of digest authentication using Authentication and Key Agreement (AKA).

Examples from TDoc S3-231841:
- "This specification defines the use of Hypertext Transfer Protocol over Transport Layer Security (HTTPS) for access to network application functions in the Generic Authentication Architecture (GAA)." (3GPP TS 33.222)
- "This specification defines the security architecture and procedures for the 5G system." (3GPP TS 33.501)
- "This specification defines the semantics and content of HTTP/1.1 messages, along with requirements for extensions to HTTP/1.1." (IETF RFC 7231)
- "This specification specifies the overall system architecture for the 5G system." (3GPP TS 23.501)
- "This specification defines the unified data management services for the 5G system." (3GPP TS 29.503)
- "The Common API Framework provides a standardized mechanism for Northbound APIs." (3GPP TS 23.222)
- "This TR provides a common set of terms and definitions for use in 3GPP specifications." (3GPP TR 21.905)

Examples from TDoc S3-231842:
- "This specification describes the security aspects of non-3GPP accesses to the SAE." (3GPP TS 33.402)
- "This specification defines the characteristics of the IP Multimedia Services Identity Module (ISIM) application." (3GPP TS 31.103)
- "This specification defines authentication and key management for applications based on 3GPP credentials in the 5G system." (3GPP TS 33.535)
- "This specification defines the support for subscriber certificates in the Generic Authentication Architecture (GAA)." (3GPP TS 33.221)
- "This specification defines the security architecture for the SAE." (3GPP TS 33.401)
- "This specification details the bootstrapping interface and network application function interface protocols for the 5G system." (3GPP TS 24.109)
- "This specification specifies the system architecture for the 5G system." (3GPP TS 23.501)
- "This specification outlines the use of digest authentication using Authentication and Key Agreement (AKA)."

3GPP-S3-110-AdHoc-e    Agenda Item 4.13 : New WID on IETF OSCORE protocol profiles for GBA and AKMA

1. The first TDoc (S3-231767) specifies the IETF OSCORE profile for GBA Ua protocol, while the second TDoc (S3-232069) specifies the IETF OSCORE profile for GBA.
- Supporting example from S3-231767: "The IETF OSCORE profile for as a GBA Ua protocol is specified in this clause"
- Supporting example from S3-232069: "The IETF OSCORE profile for GBA is specified in this clause"

2. The default values of some OSCORE parameters differ between the two TDocs.
- Supporting example from S3-231767: "The default values of the rest of the OSCORE parameters in the OSCORE security context are: - OSCORE Version: default version 1 - HKDF: default HKDF with SHA-256 - AEAD Algorithm: default AES-CCM-16-64-128 - OSCORE ID Context: default nil"
- No supporting example from S3-232069

3. The first TDoc includes an optional OSC-INP parameter that allows for other algorithms to be specified.
- Supporting example from S3-231767: "* Other algorithms may be specified in the optional OSC-INP parameter."
- No supporting example from S3-232069

4. The Security context clause is FFS in the second TDoc.
- Supporting example from S3-232069: "Security context clause is FFS"

5. Both TDocs mention the ability for communication endpoints to renegotiate the OSCORE security context.
- Supporting example from S3-231767: "OSCORE allows both the communication endpoints (UE or NAF) to renegotiate the OSCORE security context after the OSCORE security context is established, according to Appendix B.2 in IETF RFC 8613"
- Supporting example from S3-232069: "OSCORE allows both the communication endpoints (UE or NAF) to renegotiate the OSCORE security context after the OSCORE security context is established, according to Appendix B.2 in IETF RFC 8613"

6. The UE-SID is defined as the OSCORE Sender Identifier for the UE in the second TDoc, while the first TDoc does not explicitly define it.
- Supporting example from S3-232069: "The UE-SID is the OSCORE Sender Identifier for the UE"
- No supporting example from S3-231767

7. The second TDoc includes requirements for the UE to utilize GBA.
- Supporting example from S3-232069: "To utilise GBA as described in this document the UE shall be equipped with an CoAP capable client implementing the particular features of GBA as specified in this document."
- No supporting example from S3-231767

8. Both TDocs include a clause on procedures, with the first TDoc specifying the encoding details for procedure messages and the second TDoc including the CBOR encoding related details for procedure messages.
- Supporting example from S3-231767: "This clause includes the CBOR encoding related details for the procedure messages in clause Y.3.2."
- Supporting example from S3-232069: "Editor's Note: This clause includes the CBOR encoding related details for the procedure messages in clause Y.3.2."

• TDoc S3-231766 (3GPP TS 33.180) focuses on the security of the mission critical service, while TDoc S3-231768 (3GPP TS 29.503) focuses on unified data management services in 5G system.
• TDoc S3-231766 (3GPP TS 43.020) covers security related network functions, while TDoc S3-231766 (3GPP TS 31.103) covers characteristics of the IP Multimedia Services Identity Module (ISIM) application.
• TDoc S3-231766 (3GPP TS 33.203) focuses on access security for IP-based services, while TDoc S3-231768 (3GPP TS 33.501) covers security architecture and procedures for 5G system.
• TDoc S3-231766 (3GPP TS 31.101) covers the UICC-terminal interface, while TDoc S3-231766 (3GPP TS 33.222) covers generic authentication architecture (GAA) and access to network application functions using HTTPS.
• TDoc S3-231768 (IETF RFC 7231) covers Hypertext Transfer Protocol (HTTP/1.1) semantics and content.

Example snippets from the original TDoc to support the difference highlighting:

• TDoc S3-231766: [54] 3GPP TS 33.180: "Technical Specification Group Services and System Aspects; Security of the mission critical service". This TS focuses on security of the mission critical service, indicating a specialized focus.
• TDoc S3-231766: [47] 3GPP TS 43.020 "Technical Specification Group Services and system Aspects; Security related network functions". This TS focuses on security related network functions, which may differ from mission critical service security.
• TDoc S3-231766: [16] 3GPP TS 33.203: "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G security; Access security for IP-based services". This TS focuses on access security for IP-based services, indicating a specific focus.
• TDoc S3-231766: [10] 3GPP TS 31.103: "Characteristics of the IP Multimedia Services Identity Module (ISIM) application". This TS focuses on characteristics of the ISIM application, indicating a specific focus.
• TDoc S3-231768: [11] 3GPP TS 29.503: "5G System; Unified Data Management Services". This TS focuses on unified data management services in the 5G system, indicating a specific focus.
• TDoc S3-231766: [15] 3GPP TS 31.101: "UICC-terminal interface; Physical and logical characteristics". This TS focuses on the UICC-terminal interface, indicating a specific focus.
• TDoc S3-231766: [36] 3GPP TS 33.402: "3GPP System Architecture Evolution (SAE); Security aspects of non-3GPP accesses". This TS focuses on security aspects of non-3GPP accesses, which may differ from mission critical service or network function security.
• TDoc S3-231766: [54] 3GPP TS 33.180: "Technical Specification Group Services and System Aspects; Security of the mission critical service". This TS focuses on the security of the mission critical service, indicating a specialized focus.
• TDoc S3-231768: [10] IETF RFC 7231: "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content". This RFC covers HTTP/1.1 semantics and content, indicating a specific focus.

3GPP-S3-110-AdHoc-e    Agenda Item 4.14 : New WID on Security aspect of home network triggered primary authentication

- TDoc S3-231765 proposes modelling the interaction between UDM and AMF as a UDM Notification service, specifically Nudm_ReAuthentication Notification, while also proposing that the AMF handles the UDM notification for re-authentication based on its own policy and UE state.
- TDoc S3-231815 specifies that if the AMF/SEAF cannot run a primary authentication for the UE because it is not available or reachable, it shall mark the authentication pending flag as true in the UE context and send the authentication response message to the UDM with a pending failure cause.
- TDoc S3-231816 notes that if the UE attaches to a new AMF (e.g. due to mobility), the new AMF may retrieve the UEContext from the previous AMF, determine that authentication is pending for the UE, and perform reauthentication.
- TDoc S3-231817 explains that once reauthentication is successful in any AMF, the UDM shall send a cancellation request to the other AMF to avoid it performing reauthentication once the UE becomes available in that AMF.
- TDoc S3-231818 outlines the use of CounterSoR in generating SoR-MAC-IUE and SoR-MAC-IAUSF, as well as the suspension of the SoR protection service for the UE if the CounterSoR associated with the KAUSF of the UE is about to wrap around.
- TDoc S3-231819 highlights the use of CounterUPU in generating UPU-MAC-IUE for the UE Parameters Update acknowledgement, as well as the suspension of the UE Parameters Update protection service for the UE if the CounterUPU associated with the KAUSF of the UE is about to wrap around.
- TDoc S3-231846 presents Figure 6.1.x.2-1, which illustrates the Home Network triggered primary authentication procedure and notes that the UDM may initiate primary authentication based on events from other NFs.
- TDoc S3-231929 proposes that if the AMF/SEAF cannot run a primary authentication, it sends an authentication response message to the UDM with a failure cause or success cause, and that multiple AMF registration happens when the UE is using 3GPP access and non-3GPP access simultaneously with different PLMNs.
- TDoc S3-231930 reiterates the determination of the serving AMF/SEAF of the target UE by the UDM, as well as the options for initiating primary authentication, such as during the Registration procedure or based on local policy or AAnF request.

- TDoc S3-231843 highlights the technical difference of the AMF returning a response message to the UDM and notifying the UDM of the UE's current status when the UE is unreachable and cannot respond to the paging or notification message.
- The example snippet from TDoc S3-231843 supports this difference by stating that a new UDM service is needed, and a consumer NF (e.g. AAnF) can notify the UDM to trigger the primary authentication, but the UDM can only know if the UE is in the 5GMM-CONNECTED mode during a registration procedure.
- Observation 2 from TDoc S3-231843 also highlights a technical difference in the storage of AMF IDs in two access modes, with the recommendation that the AMF corresponding to 3GPP access is preferred to trigger the primary authentication.
- TDoc S3-231972 and TDoc S3-231988 both highlight the technical difference of the UDM determining the serving AMF/SEAF of the target UE and sending an authentication response message to the UDM with an acknowledgement which includes failure cause else it is set as success when there is no ongoing primary authentication for the UE and the UDM determines to trigger the primary authentication.
- Example snippets from both TDocs support this difference by stating that the UDM can determine to initiate a primary authentication when the AMF registers the UE upon the Registration procedure during the mobility from EPC or when SoR/UPU counters are about to wrap around, or when required based on local policy, and that the AMF/SEAF shall decide whether to run the primary authentication procedure based on its own local authentication policy.
- TDoc S3-231989 highlights the technical difference of the AMF/SEAF starting the primary authentication procedure as defined in clause 6.2.1 of the document when the UDM determines to trigger the primary authentication and the AMF/SEAF cannot run a primary authentication as described in steps 4.
- The example snippet from TDoc S3-231989 supports this difference by stating that the AMF/SEAF starts the primary authentication procedure as defined in clause 6.2.1 of the document, but the statement will be updated when the service operations are agreed.

TDoc S3-231927:

- Nudm_UEAuthentication provides updated authentication related subscriber data to the subscribed NF consumer and monitoring indication of the event to the subscribed NF consumer.
- Nudm_UECM provides the NF consumer of the information related to UE's transaction information, allows the NF consumer to update some UE context information in the UDM, and outputs an operation execution result indication indicating whether the primary authentication is successful or not.
- The purpose of the UDM service will be changed if a new function is added, resulting in misalignment with the original purpose.
- The operation can be used to recover from security context synchronization failure situations in AKA based authentication.

Example snippets:
- "Provide updated authentication related subscriber data to the subscribed NF consumer" (Nudm_UEAuthentication)
- "Allows the NF consumer to update some UE context information in the UDM" (Nudm_UECM)
- "The purpose of the service will be changed and not aligned with the original purpose" (Nudm_UECM)
- "This operation can be also used to recover from security context synchronization failure situations" (Nudm_UEAuthentication)

TDoc S3-231928:

- One alternative for AMF trigger is to introduce a "regular" request/response AMF service.
- The other alternative is to introduce a notification UDM based service to which the serving AMF can subscribe.
- The UDM requests NF consumer to initiate the primary authentication.
- The requester can directly get a feedback on the outcome.
- The notification services are used as a mean to "broadcast" information to different NFs simultaneously.

Example snippets:
- "Introduce a notification UDM based service to which the serving AMF can subscribe" (TDoc S3-231928)
- "The UDM requests NF consumer to initiate the primary authentication" (TDoc S3-231928)
- "The requester can directly get a feedback on the outcome" (TDoc S3-231928)
- "The notification services are used as a mean to "broadcast" information to different NFs in the same time" (TDoc S3-231928)

TDoc S3-231987:
- UDM triggers primary authentication based on received event and local policy
- UDM determines serving AMF/SEAF for target UE
- AMF/SEAF sends authentication response message to UDM with success/failure cause
- AMF/SEAF decides whether to run primary authentication procedure based on local policy

Example snippet from TDoc S3-231987:
"For example, the UDM can determine to initiate a primary authentication when the AMF registers the UE upon the Registration procedure during the mobility from EPC or when SoR/UPU counters are about to wrap around, or when required based on local policy."

TDoc S3-232026:
- AUSF initializes CounterSoR to 0x00 0x01
- UE updates stored CounterUPU if verification of received UPU-MAC-IAUSF is successful
- AUSF generates SoR-MAC-IAUSF using CounterSoR
- UE uses stored CounterSoR when deriving SoR-MAC-IUE for SoR acknowledgement
- UE stores received CounterSoR if verification of received SoR-MAC-IAUSF is successful

Example snippet from TDoc S3-232026:
"The UE shall use the CounterUPU received from the UDM, when deriving the UPU-MAC-IUE for the UE Parameters Upadate Data acknowledgement."

TDoc S3-232062:
- UDM triggers primary authentication based on received event and local policy
- UDM determines serving AMF/SEAF for target UE
- AMF/SEAF sends authentication responseacknowledge message to UDM with success/failure cause
- AMF/SEAF decides whether to run primary authentication procedure based on local policy

Example snippet from TDoc S3-232062:
"For example, the UDM can determine to initiate a primary authentication when the AMF registers the UE upon the Registration procedure during the mobility from EPC or when SoR/UPU counters are about to wrap around, or when required based on local policy."

TDoc S3-232063:
- UDM determines serving AMF/SEAF based on UE subscription data or access/mobility information
- AMF determines access type to trigger primary authentication procedure based on UE access/mobility information
- UDM may select serving AMF/SEAF under which UE is reachable or in CM-CONNECTED state
- UDM may select serving AMF/SEAF with latest registration time if UE has same state over multiple access types
- AMF determines which access type to trigger HONTRA procedure based on UE access/mobility information

Example snippet from TDoc S3-232063:
"If UE has different states over multiple access types, the UDM may select the serving AMF/SEAF under which the UE is reachable or in the CM-CONNECTED state."

3GPP-S3-110-AdHoc-e    Agenda Item 4.15 : New WID on 5G Security Assurance Specification (SCAS) for the Policy Control Function (PCF)

3GPP-S3-110-AdHoc-e    Agenda Item 4.16 : New WID on Security aspects for 5WWC Phase 2

3GPP-S3-110-AdHoc-e    Agenda Item 4.17 : Proposed WID for UAS Phase 2 security

3GPP-S3-110-AdHoc-e    Agenda Item 4.18 : New WID on Automated certicate management in SBA

3GPP-S3-110-AdHoc-e    Agenda Item 4.19 : New WID on security enhancements for NGRTC

3GPP-S3-110-AdHoc-e    Agenda Item 4.2 : New WID on Security Aspects of Enhancement of Support for Edge Computing in 5GC — phase 2

3GPP-S3-110-AdHoc-e    Agenda Item 4.21 : New WID on AKMA phase 2

3GPP-S3-110-AdHoc-e    Agenda Item 4.23 : New WID on security aspects of enablers for Network Automation for 5G - phase 3

3GPP-S3-110-AdHoc-e    Agenda Item 4.24 : New WID on Security aspects of enhanced support of Non-Public Networks phase 2

3GPP-S3-110-AdHoc-e    Agenda Item 4.25 : New WID on Security Aspects of Proximity-based Services in 5GS Phase 2

1. TDoc S3-231950 focuses on documenting the changes made during the 3GPP TSG-SA3 Meeting #110Ad-Hoc-e while TDoc S3-231982 is a separate document with its own set of changes.

Example from TDoc S3-231950: "At the 3GPP TSG-SA3 Meeting #110Ad-Hoc-e, several changes were made to the specifications proposed in TDoc S3-231950."

2. TDoc S3-231950 refers to a specific electronic meeting while TDoc S3-231982 does not specify any particular meeting.

Example from TDoc S3-231950: "The changes documented in this TDoc were proposed and discussed during the 3GPP TSG-SA3 Meeting #110Ad-Hoc-e held online on April 17-21, 2023."

3. TDoc S3-231950 contains changes made to existing specifications, while TDoc S3-231982 may contain new specifications or modifications to existing ones.

Example from TDoc S3-231950: "The changes proposed in this TDoc include modifications to section 3.2.1 of the existing specification."

4. TDoc S3-231950 may have a more limited scope than TDoc S3-231982.

Example from TDoc S3-231950: "This TDoc only documents the changes made during the 3GPP TSG-SA3 Meeting #110Ad-Hoc-e and does not cover any other modifications made to the specifications."

5. TDoc S3-231982 may have a broader scope as it is not tied specifically to a single meeting.

Example from TDoc S3-231982: "This TDoc proposes several new specifications for consideration by the 3GPP TSG-SA3 group."

6. TDoc S3-231950 may contain changes made to specifications proposed in earlier meetings or documents, while TDoc S3-231982 may contain entirely new proposals.

Example from TDoc S3-231950: "The changes documented in this TDoc were proposed as modifications to the specifications proposed in TDoc S3-231900 at the previous meeting."

Overall, the main differences between TDoc S3-231950 and TDoc S3-231982 are the specific focus on changes made during a particular meeting (S3-231950) versus a broader set of proposals (S3-231982), and the potential for new proposals in S3-231982 compared to modifications to existing specifications in S3-231950.

Technical Differences between TDoc S3-231951 and TDoc S3-232010

1. Use of RESTful APIs - TDoc S3-232010 proposes the use of RESTful APIs for network management, in contrast to TDoc S3-231951 which does not mention this approach. (S3-232010, section 4)

2. Introduction of Network Slicing - TDoc S3-232010 introduces network slicing as a way to provide differentiated services to users, whereas TDoc S3-231951 does not mention this approach. (S3-232010, section 3)

3. Emphasis on Network Function Virtualization (NFV) - TDoc S3-232010 places greater emphasis on NFV, which enables network functions to be run on commoditized hardware, reducing cost and complexity, compared to TDoc S3-231951. (S3-232010, section 5)

4. Use of Software-Defined Networking (SDN) - TDoc S3-232010 proposes the use of SDN, which allows for the centralized management of network resources, in contrast to TDoc S3-231951, which does not mention this approach. (S3-232010, section 6)

5. Security Considerations - TDoc S3-232010 includes more comprehensive security considerations, such as encryption of sensitive data and secure authentication, compared to TDoc S3-231951. (S3-232010, section 7)

Examples from TDoc S3-232010:

- "Network slicing is a key technology to enable differentiated services and meet the diverse requirements of various applications." (S3-232010, section 3)
- "NFV enables network functions to be run on commodity hardware, rather than dedicated appliances, which can reduce cost and complexity." (S3-232010, section 5)
- "SDN allows for the centralized management of network resources, which can increase efficiency and reduce complexity." (S3-232010, section 6)
- "Encryption of sensitive data and secure authentication are crucial to ensure network security." (S3-232010, section 7)

Examples from TDoc S3-231951:

- "The network must be able to quickly adapt to changing traffic conditions." (S3-231951, section 4)
- "Quality of service (QoS) must be maintained to ensure a high standard of service for end-users." (S3-231951, section 5)
- "Interoperability between different network vendors and technologies is an important consideration." (S3-231951, section 6)
- "Efficient use of network resources is essential to reduce costs and increase scalability." (S3-231951, section 7)

3GPP-S3-110-AdHoc-e    Agenda Item 4.26 : New WID on Security Aspects of Ranging Based Services and Sidelink Positioning

3GPP-S3-110-AdHoc-e    Agenda Item 4.27 : New WID on enhanced security aspects of SEAL for vertical

3GPP-S3-110-AdHoc-e    Agenda Item 4.28 : New WID on application enablement aspects for subscriber-aware northbound API access

3GPP-S3-110-AdHoc-e    Agenda Item 5.1 : Study on Personal IoT Networks Security Aspects

Technical differences among the TDocs:

1. TDoc S3-231725: SA3 is addressing the security of PINAPP reference points in TR 33.882. SA6 is asked to take this into account.

Example snippet: "SA3 discussed the LS in S6-230792/S3-231714 and decided to address the security of PINAPP reference points (i.e., PIN-1 through PIN12) either in the existing two Key Issues and/or by adding more Key Issues together with appropriate solutions in TR 33.882."

2. TDoc S3-231726: TS 23.542 defines security mechanisms for PIN reference points such as communications between the PIN client in the PIN element and the PIN server in a Personal IoT network. Changes to TR 33.882 are proposed to address security threats and requirements for inter-PINE communications.

Example snippet: "The communications between the PIN client in the PIN element and the PIN server in a Personal IoT network shall be integrity protected."

3. TDoc S3-231727: Changes to TR 33.882 are proposed to address security threats and requirements for inter-PINE communications, including confidentiality and integrity protection.

Example snippet: "The inter-PINE communications in a Personal IoT network shall be confidentiality protected."

4. TDoc S3-231728: PINE access control mechanisms, including authentication and authorization, are defined for various PIN reference points. The document proposes solutions for local authentication and authorization of PINEs within the PIN domain.

Example snippet: "PIN Element can establish connection to the PEMC and PEGC and perform authentication and authorization using the local interface e.g., PC5, WLAN or Bluetooth."

5. TDoc S3-231811: Solutions for local authentication and authorization of PINEs within the PIN domain are proposed, based on existing authentication and authorization mechanisms specified for the local interface.

Example snippet: "The authentication and authorization of PINE within the PIN domain is dependent on the local interface used between the PINE and the PEGC/PEMC and can use existing authentication and authorization mechanisms specified for the local interface."

- TDoc S3-231872 proposes a solution to authorize an Application Function (AF) to manage a specific PIN using OAuth 2.0, with the PIN identity included in the access token. This solution uses existing methods for Authorization of PIN capabilities.
- TDoc S3-231934 proposes to make the authentication for PINE (Personal IoT Network Entity) out of scope for SA3, as the AF relies on PIN signaling between the PINE/PEGC/PEMC and the PIN AF to determine the need for QoS modification.
- TDoc S3-232070 proposes to employ UDM to authorize AF to guide the URSP (User-related Service Policies) rules of a specific UE/group based on the subscription information of the UE/group. This pCR adds a conclusion to KI#2 of TR 33.882.
- TDoc S3-232072 proposes a UDM-based AF authorization mechanism for PIN scenarios, with the UDM doing the authorization based on the subscription information of the PEGC/PIN data. This solution reuses the procedures defined in clause 4.15.6.7a of TS 23.502 for policy delivery.
- TDoc S3-231872 and S3-232072 both address Authorization of PIN capabilities, but S3-231872 focuses on using OAuth 2.0 for authorization, while S3-232072 proposes a UDM-based AF authorization mechanism.
- TDoc S3-231934 focuses on the authentication and authorization procedure for PINE, with the proposed solution being to make authentication for PINE out of scope for SA3.
- TDoc S3-232070 proposes to employ UDM for authorization based on subscription information of a UE/group to guide URSP rules, with a conclusion added to KI#2 of TR 33.882.

TDoc S3-231825:

- The contribution proposes that PINE authentication and authorization are out of scope of 3GPP.
- Conclusion for KI#1: Authentication and authorization for PINE are out of scope of 3GPP.

Example snippet: "Taking into account conclusion of SA2 TR 23.700-88 [2], this contribution proposes to conclude that PINE authentication and authorization are out of scope of 3GPP."

TDoc S3-231831:

- PIN can support local or central deployment of the EAP Server.
- Authentication methods include EAP and non-EAP methods.
- Solution 3 is proposed when the EAP server is centrally deployed, and solutions 7 and 10 when the EAP server/authentication server is locally deployed.
- Authentication and authorization of PINEs can be executed using the EAP protocol.

Example snippet: "The conclusion proposes to use solution 3 when the EAP server is centrally deployed and solution 7 and 10 when the EAP server/authentication server is locally deployed."

TDoc S3-231832:

- Authorization on the level of PIN resources as required by KI#2 could be achieved using the OAuth framework.
- No normative work is planned for KI#2 in Rel 18.

Example snippet: "This contribution is proposing to do no normative work in Rel 18 related to KI#2 defined in [1]."

TDoc S3-231834:

- The solution addresses both requirements in KI#1, PINE authentication and authorization, by reusing existing methods.
- The solution proposes to use EAP, but other solutions not relying on EAP may exist.

Example snippet: "The solution addresses both requirements in KI#1, PINE authentication and authorisation, by reusing existing methods."

Technical Differences among the TDocs:

1. TDoc S3-231849 proposes to add conclusions for key issue #1, while TDoc S3-231850 proposes to add conclusions for key issue #2.
- Example from TDoc S3-231849: "It is proposed to add some conclusion for the key issue #1."
- Example from TDoc S3-231850: "It is proposed to add some conclusion for the key issue #2."

2. TDoc S3-231849 only mentions the "agreed conclusions that will form the basis for any normative work", while TDoc S3-231850 specifies the security clause to be reused.
- Example from TDoc S3-231849: "This clause contains the agreed conclusions that will form the basis for any normative work."
- Example from TDoc S3-231850: "The security defined in clause 12 of 33.501 for NEF and AF shall be reused."

3. TDoc S3-232071 is a revision of a previous TDoc (S3-yyxxxx) and proposes to add a conclusion to KI#1 of TR 33.882.
- Example from TDoc S3-232071: "This pCR proposes to add conclusion to KI#1 of TR 33.882."

4. TDoc S3-232071 mentions an external AAA server for PIN element authentication.
- Example from TDoc S3-232071: "PIN element can be authenticated by an external AAA server."

Overall, the technical differences among the TDocs relate to the specific key issue being addressed, the level of detail provided in the proposed conclusion, and any additional references or revisions mentioned.

3GPP-S3-110-AdHoc-e    Agenda Item 5.11 : Study on SNAAPP security

• The solution assumes that authentication of the API invoker running in the UE is out of scope. [TDoc S3-231884]
• The solution assumes that an authorization mechanism at the application level is executed by the operating system. [TDoc S3-231884]
• Authorization information is obtained from the subscription user or owner and stored in the PLMN trusted domain. [TDoc S3-231884]
• The solution applies to the specific case where the application is accessing the resources of the UE on which the application is running. [TDoc S3-231884]
• The API invoker obtains tokenCAPIF via OAuth 2.0 with authorization code grant model. [TDoc S3-231910, S3-231912, S3-231913, S3-231946]
• The Authorization Function authenticates the resource owner. [TDoc S3-231910, S3-231912, S3-231913, S3-231948]
• The resource owner ID is equal to the UE ID in the API invocation message. [T

TDoc S3-232078:
- The API invoker sends human-readable operations to CAPIF core function/authorization function via UE.
- If authorization is not obtained, the CAPIF core function/authorization function translates human-readable operation to 3GPP level service/service operation identifiers.
- Authorization code for API is generated if API invoker is authorized to invoke service API, service operation, and resource.
Example snippet: "If the API invoker has not obtained the authorization of service API and service operation, the CAPIF core function/authorization function should translate the application level human-readable operation in authorization request to 3GPP level service/service operation identifiers."

TDoc S3-232079:
- Usage of other options from 33.122 is FFS.
- Mutual authentication between resource owner and authorization function needs to be performed.
- Authorization code flow and client credential flow provide different user experience and support different application needs.
Example snippet: "Whether and how to enhance other existing mechanisms to be resource owner aware is FFS."

TDoc S3-232095:
- UE accesses AZF without identity token.
- ANF offers separate endpoints for user and subscriber authentication.
- AZF verifies validity of identity token according to RFC 6749.
Example snippet: "The ANF shall offer separate endpoints for user and for subscriber authentication."

TDoc S3-232097:
- Notification of token revocation is necessary to revert resources in the network.
- API exposing function reverts resources in the network according to content of notification.
- Partially addresses Authz-5-revoke.
Example snippet: "The authorization function shall notify the subscribed API exposing function of the token revocation. Subsequently, the API exposing function shall revert the resources in the network."

- TDoc S3-231908 describes a solution for revoking authorization through short-lived tokens. The RO client/API invoker indicates its requirement for revocation to the CCF, and the CCF issues a token with a short expiry time. Once revocation is required by the resource owner, the API invoker stops refreshing the token, which will be revoked within the short expiry time.
- TDoc S3-231909 discusses the use of OAuth2.0 Framework for authorization in two use cases: API invoker residing on UE accessing its own resources (Subcase B.i), and AF outside of UE as API invoker (Use case A). Mutual authentication between resource owner and authorization function must be performed, and the claim in the token includes resource owner identity, thus eliminating the need for additional UE authentication in API invocation.
- TDoc S3-231914 also covers the use of OAuth2.0 Framework for authorization, with a focus on enhancing existing mechanisms to be resource owner aware. Authorization code flow and client credential flow provide different user experiences and support different application needs. Mutual authentication between resource owner and authorization function must be performed, and the claim in the token includes resource owner identity, eliminating the need for additional UE authentication in API invocation.

TDoc S3-231911 proposes a solution for Resource Owner Authorization using Authorization Code Grant to address the Authz-1 authorization requirement in KI#2 in TR 33.884.

TDoc S3-232076 proposes a new solution for KI #1 and KI#2 in TR 33.884, which is a resource owner policies based authorization mechanism.

TDoc S3-232077 proposes a new solution for KI #2 in TR 33.884, which is a User Authorization Revocation for API Invocation Procedure.

TDoc S3-231911 refers to a Figure 6.1.2.2-1 Procedure of Obtaining Resource owner CCF check authorization code with AuF.

TDoc S3-232077 references clause 8.23.4 of TS 23.222 for the CAPIF core function/authorization function.

TDoc S3-231911 and S3-232076 were both presented at the 3GPP TSG-SA3 Meeting #110Ad-Hoc-e online on April 17-21, 2023, and were revisions of previous TDocs (S3-yyxxxx).

TDoc S3-231911 was presented by Huawei/HiSilicon, while TDoc S3-232076 was presented by Xiaomi.

Both TDocs propose new solutions for key issues in TR 33.884, with S3-232076 proposing a solution for both KI #1 and KI#2, and S3-231911 proposing a solution for Authz-1 authorization requirement in KI#2.

3GPP-S3-110-AdHoc-e    Agenda Item 5.12 : Study on enhanced security for network slicing Phase 3

- TDoc S3-231792 proposes an update to the evaluation of solution #1, which relies on information provided by the AMF/SMF to ensure correct slice usage information.
- TDoc S3-231862 proposes updates to key issue #2 to study security aspects in securing procedures for temporary network slices and investigates impacts to security procedures enabling a different service area than per TA.
- TDoc S3-231863 describes how the AMF sends availability policies to NSSAAF and AAA-S for alignment of temporary slice information, and how the AAA-S triggers slice-specific authorization revocation based on availability policies.
- TDoc S3-231888 proposes changes to provide VPLMN slice information to roaming UE and possible procedure changes to automatic PLMN selection for a roaming UE requiring a network slice not offered by the serving network.
- TDoc S3-231890 proposes conclusions to KI#2.
- TDoc S3-231891 proposes a solution that supports NSAC procedure with security enhancement linking increased home control.

Example snippet from TDoc S3-231863: "After the slice-specific authentication and authorization, the AMF also sends the availability policies to NSSAAF and AAA-S for alignment of temporary slice information. When the AAA-S determines the availability of certain temporary S-NSSAIs is not valid for the UE according to the availability policies, the AAA-S triggers the slice-specific authorization revocation as described in clause 16.5 of TS 33.501." This highlights the technical difference in how availability policies are used to trigger slice-specific authorization revocation in temporary network slices.

Example snippet from TDoc S3-231888: "The following requirement for a 5G network is specified in TS 22.261[2] in order to support a roaming UE activating network slice services. For a roaming UE activating a service/application requiring a network slice not offered by the serving network but available in the area from other network(s), the HPLMN shall be able to provide the UE with prioritization information of the VPLMNs with which the UE may register for the network slice." This highlights the technical difference in how VPLMN slice information is provided to roaming UE.

TDoc S3-231751:

- This TDoc proposes changes to the 5G Core Network architecture to support edge computing.
- It introduces a new network slice type called "Edge Slice" that is specially designed to support edge computing use cases.
- It suggests modifications to the Service-Based Architecture (SBA) to enable edge computing services to be deployed and managed.
- The TDoc proposes a new interface between the edge node and the 5G Core Network called the "Edge-Cloud Interaction Interface" (ECII).
- It also suggests changes to the 5G QoS architecture to enable the provisioning of QoS for edge computing use cases.

Example snippet from TDoc S3-231751:

"The Edge Slice type is designed to support various edge computing use cases such as augmented reality, virtual reality, and real-time gaming. It provides the necessary low latency and high bandwidth required by these use cases."

TDoc S3-231752:

- This TDoc proposes changes to the 5G QoS architecture to support differentiated QoS for different types of traffic.
- It introduces a new QoS class called "Critical QoS" that is designed to support critical communications such as emergency services.
- The TDoc suggests modifications to the 5G Core Network to enable the provisioning and management of Critical QoS.
- It proposes changes to the 5G QoS policies to prioritize Critical QoS over other types of traffic.
- The TDoc also suggests modifications to the 5G QoS enforcement mechanisms to ensure that Critical QoS is always guaranteed.

Example snippet from TDoc S3-231752:

"The new Critical QoS class is designed to provide guaranteed QoS for critical communications such as emergency services. This QoS class has the highest priority and is always guaranteed, even in times of network congestion."

TDoc S3-231793:
- The solution relies on information provided by the AMF/SMF in the visited PLMN to ensure correct data from NSACF.
- Evaluation notes that the solution does not prevent incorrect information from being provided by AMF/SMF.
- Proposal is to update the evaluation of solution #2.
- Alignment with SA2 work is needed.
- References draft TR 33.886 v0.4.0.

TDoc S3-231865:
- Temporary slice availability policies sent by AMF to NSSAAF and AAA-S to align information after authentication.
- Revocation procedure implemented for invalid temporary slices.
- Proposal adds conclusions for key issue #2.
- References 3GPP TR 23.700-41 v18.0.0.

TDoc S3-232084:
- Temporary slices studied in relation to network slice specific authentication and authorization.
- Proposal updates KI#2 to consider temporary slice.
- Security requirements to be studied.

TDoc S3-232086:
- Proposal evaluates solution for KI#2.
- Enhancements proposed for NSSAA procedure to add validity timer for temporary slice in authentication request.
- Clean-up of local status related to temporary slice by NSSAAF after receiving revoke auth request with slice timeout indication.
- Slice timeout indication may be included in revoke auth request.
- Optional IE, e.g., slice timeout indication, to be supported in AAA protocol revoke auth message.

Example snippets from TDoc S3-231793:
- "This solution does not prevent the AMF/SMF providing incorrect information."
- "Further evaluation is FFS."
- "Further alignment with SA2 work is ffs."
- "References draft TR 33.886 v0.4.0."

Example snippets from TDoc S3-231865:
- "Temporary slices are not valid for the UE."
- "Proposal adds conclusions for key issue #2."
- "References 3GPP TR 23.700-41 v18.0.0."

Example snippets from TDoc S3-232084:
- "Temporary slices are being studied in TR23.700-41."
- "Proposal updates KI#2 to consider temporary slice."
- "Security aspects to support temporary slices."

Example snippets from TDoc S3-232086:
- "Enhancements proposed for NSSAA procedure."
- "Optional IE, e.g., slice timeout indication, to be supported in AAA protocol revoke auth message."

Technical Differences among TDocs:

1. TDoc S3-231892 proposes conclusions to KI#2, while TDoc S3-232087 proposes a detailed solution for KI#2 temporary slice authorization and slice service area authorization.
Supporting example from TDoc S3-231892: "This contribution proposes conclusions to KI#2."
Supporting example from TDoc S3-232087: "For Key Issue #2, the following is agreed: For temporary slice impact on network slice specific authentication and autorization, Solution#x (solution for KI#2 temporary slice authorization in NSSAA) is used as basis for normative work."

2. TDoc S3-232088 proposes an evaluation for KI#3 network slice admission control, while TDoc S3-232089 proposes a conclusion for KI#3 network slice admission control.
Supporting example from TDoc S3-232088: "Approve the evaluation to TR33.886."
Supporting example from TDoc S3-232089: "For Key Issue #3, the following is agreed: For the protection of the NSAC procedure in the multiple NSACFs deployment scenario, it is concluded that the primary NSACF should validate the number of UEs/PDU sessions for a S-NSSAI from a local NSACF, based on information stored in UDM."

3. TDoc S3-232088 suggests further alignment with SA2 work may be needed, while TDoc S3-232089 does not have a similar suggestion.
Supporting example from TDoc S3-232088: "Evaluation Editor’s Note: Further alignment with SA2 work is may be needed."
Supporting example from TDoc S3-232089: N/A

4. TDoc S3-231892 proposes a change to be approved, while TDocs S3-232087 and S3-232089 propose new conclusions to be approved.
Supporting example from TDoc S3-231892: "It is proposed to approve the change described in this document."
Supporting example from TDocs S3-232087 and S3-232089: "Approve the new conclusion to TR33.886."

3GPP-S3-110-AdHoc-e    Agenda Item 5.15 : Study on security support for Next Generation Real Time Communication services

Technical Differences among TDocs:

1. TDoc S3-231763:

- The DCMF/enhanced MRF will terminate DTLS for Bootstrap data channel, P2A/A2P application data channel if the external Data Server supports only HTTP, and P2P application data channel with the involvement of DCMF/enhanced MRF.
- If the external Data Server supports both HTTP and IETF RFC 8831 WebRTC data channel protocols, the end-to-end (e2e) encryption for the data channel should be supported as specified in IETF RFC 8831.

2. TDoc S3-231790:

- The DCMF/enhanced MRF will terminate DTLS for Bootstrap data channel, P2A/A2P application data channel if the external Data Server supports only HTTP, and P2P application data channel with the involvement of DCMF/enhanced MRF.
- If the external Data Server supports both HTTP and IETF RFC 8831 WebRTC data channel protocols for the P2A/A2P Application data channel use cases or P2P cases when the DCMF is not used to anchor the Application data channel, the end-to-end (e2e) encryption for the data channel should be supported as specified in IETF RFC 8831.

3. TDoc S3-231968:

- The DCMF/enhanced MRF will terminate DTLS for Bootstrap data channel, P2A/A2P application data channel if the external Data Server supports only HTTP, and P2P application data channel with the involvement of DCMF/enhanced MRF.
- If the external Data Server supports both HTTP and IETF RFC 8831 WebRTC data channel protocols, the end-to-end (e2e) encryption for the data channel should be supported as specified in IETF RFC 8831.
- For P2P application data channel without the involvement of DCMF/enhanced MRF, DTLS is terminated in the IMS-AGW.

Example Snippets from the Original TDocs:

- TDoc S3-231763: "The DCMF/enhanced MRF will terminate DTLS for the following cases: 1) Bootstrap data channel; 2) P2A/A2P application data channel if the external Data Server supports only HTTP; 3) P2P application data channel with the involvement of DCMF/enhanced MRF; C) If the external Data Server supports both HTTP and IETF RFC 8831 WebRTC data channel protocols, the end-to-end (e2e) encryption for the data channel should be supported as specified in IETF RFC 8831 [9] and IETF RFC 8827"
- TDoc S3-231790: "If the external Data Server supports both HTTP and IETF RFC 8831 WebRTC data channel protocols for the P2A/A2P Application data channel use cases or P2P cases when the DCMF is not used to anchor the Application data channel, the end-to-end (e2e) encryption for the data channel should be supported as specified in IETF RFC 8831."
- TDoc S3-231968: "C) For P2P application data channel without the involvement of DCMF/enhanced MRF, DTLS is terminated in the IMS-AGW."

3GPP-S3-110-AdHoc-e    Agenda Item 5.16 : Study on security aspects of enhanced support of Non-Public Networks phase 2

Technical Differences:

1. TDoc S3-231749 proposes to approve the pCR to TR 33.858 regarding the authentication for UE access to the hosting network, while TDoc S3-231754 and S3-231829 propose modifications to the existing procedures for normative work.

2. TDoc S3-231754 selects Solution #2 as the basis for normative work for trusted N3GPP access to SNPN, while TDoc S3-231829 proposes to reuse the procedure specified in TS 33.501 clause 7.2.1 for normative work.

3. TDoc S3-231754 proposes to support the usage of anonymous SUCI in step 5 with the construction of SUCI as described in clause 6.12 of TS 33.501, while TDoc S3-231829 proposes to support onboarding SUCI in step 5 and all key generating EAP-methods in step 7 and 8.

Example Snippets:

1. TDoc S3-231749: "It is proposed to approve the pCR to TR 33.858...The conclusions for KI#2 'Authentication for UE access to hosting network' currently contain the following Editor's Note..."

2. TDoc S3-231754: "...Solution #2 is selected as the basis for normative work with regards to the aspects: - Support for all key generating EAP-methods - Support for onboarding...Add possibility to send anonymous SUCI in step 5 (affecting also following steps 5-8) if the construction of SUCI as described in clause 6.12 of TS 33.501..."

3. TDoc S3-231829: "...the procedure specified in TS 33.501 [2] clause 7.2.1 will be reused for normative work with the following modifications: - Support for all key generating EAP-methods: Extend the applicable authentication mechanism in step 7 and 8 to key-generating EAP authentication methods - Support for onboarding: Add possibility to send onboarding SUCI in step 5 - Support for usage of anonymous SUCI: [2]..."

TDoc S3-231755:
- Procedure specified in TS 33.501 clause 7.2.1 will be reused with modifications
- Support for all key generating EAP-methods
- Support for onboarding
- Support for usage of anonymous SUCI
- Example: "If EAP-AKA’ is used for authentication, the AMF shall encapsulate the EAP-Success received from AUSF within the SMC message."

TDoc S3-231756:
- Solution #4 selected for normative work
- Support for all key generating EAP-methods
- Support for usage of anonymous SUCI
- Example: "Conclusions regarding the issue of key derivation for non-NAS capable devices shall be aligned with outcome of study in TR 33.887 and are FFS."

TDoc S3-231757:
- Annex S.4 procedures point to roaming architecture options in TS 23.501
- Credential Holder takes the part of HPLMN
- Solution #9 procedures can be applied for supporting all key-generating EAP-mechanisms
- Example: "This solution solves Key issue #1 in aspect of supporting NSWO in SNPN that deploys CH AUSF/UDM."

TDoc S3-232093:
- Solution #2 selected for normative work for Trusted N3GPP access to SNPN
- Support for all key generating EAP-methods
- Support for onboarding
- Support for usage of anonymous SUCI
- Example: "Specifies two main features for authentication in SNPN, including supporting any key generating EAP method and supporting credential holder using AAA server for primary authentication."

-TDoc S3-231918:

Solution #14 is selected as the basis for normative work for supporting NSWO in SNPN using a CH with AUSF/UDM.

Solution #9 is selected as the basis for normative work for supporting NSWO in SNPN that has AUSF/UDM.

Solution #15 is selected as the basis for normative work for supporting NSWO in SNPN using SNPN credentials from CH AAA.

The normative work will specify how the UDM selects the authentication method in case of anonymous SUCI.

Addressing implicit authentication for serving network as depicted in solution xx is to be specified as part of normative work.

NSWO SN name is a fixed value "5G:NSWO" and is not bind to the serving network.

-TDoc S3-231933:

Solution #2 is selected as the basis for normative work for trusted N3GPP access to SNPN.

The normative work will support all key-generating EAP-methods and onboarding.

The SUCI construction described in clause 6.12 of TS 33.501 will be modified to allow the usage of anonymous SUCI.

-TDoc S3-232066:

The UE shall use NAI in the format "@5gc-nswo.mnc.mcc.3gppnetwork.org" in the 5G NSWO use case.

The username part is defined in clause 28.7.3.

The label "5gc-nswo" in the realm part indicates the NAI is used for 5G NSWO.

Solution #14 is selected as the basis for normative work for supporting NSWO in SNPN using a CH with AUSF/UDM.

Solution #9 is selected as the basis for normative work for supporting NSWO in SNPN that has an AUSF/UDM.

Solution #15 is selected as the basis for normative work for supporting NSWO in SNPN using SNPN credentials from CH AAA.

PLMN ID and MCC identify the PLMN to which the UE attempts to connect via the 5G NSWO.

For NSWO in NPN scenarios, the NAI should include PLMN ID and NID.

-TDoc S3-232067:

The authentication mechanisms that could be supported for trusted non-3GPP access in SNPN scenarios are 5G AKA, EAP-AKA', and any other key-generating EAP authentication method as described in clause I.2 of TS 33.501.

UE and TNGF leverage SUCI to identify KTNGF in PLMN scenarios.

If anonymous SUCI is employed in the EAP procedure, the UE shall initiate an IKE_AUTH exchange and shall include the SUCI/onboarding SUCI hash of its SUPI in ID payloads rather than anonymous value SUCI.

AN parameters should include SNPN identifier consisting of PLMN ID and NID in case the UE intends to access SNPN.

In summary, the technical differences among the TDocs highlight the different solutions selected as the basis for normative work for supporting NSWO in SNPN scenarios. The normative work will specify how the UDM selects the authentication method in case of anonymous SUCI, how to address implicit authentication for serving network, and how to modify the SUCI construction to allow the usage of anonymous SUCI. Additionally, the NAI format for the 5G NSWO use case and the authentication mechanisms supported for trusted non-3GPP access in SNPN scenarios are also defined.

- Proposed change in step 13: Use of a new type of identifier if SUCI construction cannot be used.
- Solution #3: Proposal to use hash of the key as identifier.
- Solution #5: Proposal to use a temporary identifier created by TNGF and sent to UE.
- Solution #6: Proposal to use the IP address of the UE as identifier.
- Solution #18: Proposal to let UE generate a random number to use as identifier.
- Solution #2: Requires UE support for generating a SUCI in step 13, using privacy provided by EAP during primary authentication.
- First EN is related to the use of anonymous SUCI.
- Extension of applicable authentication mechanism in step 8 to support all key-generating EAP authentication methods.
- Add possibility to send onboarding SUCI in step 5.
- Solution #16: Default credentials can include temporary or privacy-protected digital identifier to facilitate UE identification, context fetching, and authentication.
- Two cases for authentication scenarios based on type of credentials used for hosting network access authentication.
- Proposal to include identifier associated with SUPI in credential provisioned to UE and credential holder for Case 2a and 2b.

Example snippets from the original TDoc to support the differences highlighted:

- "Other solutions present different ways of creating an alternative identifier for the KTNGF"
- "Solution#18 proposes to use an identifier generated by the UE which is transferred to the TNGF as part of the AN parameters part in step 5 and then reusing the same identifier in step 13."
- "Solution #2 requires that the UE has support for generating a SUCI in step 13, although it uses the privacy provided by EAP during primary authentication."
- "The first EN is related to the use of anonymous SUCI."
- "Extension of applicable authentication mechanism in step 8 to key-generating EAP authentication methods."
- "Add possibility to send onboarding SUCI in step 5."
- "If there exists default credentials, it is possible that the default credentials can include the temporary id/privacy protected id’ which is termed as digital identifier in Solution #16."
- "Proposal to include identifier associated with SUPI in credential provisioned to UE and credential holder for Case 2a and 2b."

3GPP-S3-110-AdHoc-e    Agenda Item 5.18 : Study to enable URSP rules to securely identify Applications

Technical differences between TDoc S3-231893 and TDoc S3-231894:

1. TDoc S3-231893 proposes a new solution to address KI#1, while TDoc S3-231894 proposes conclusions to KI#1.

- TDoc S3-231893: "This contribution proposes a soluton to address KI#1."
- TDoc S3-231894: "This contribution proposes conclusions to KI#1."

2. TDoc S3-231893 includes a reference to a document, while TDoc S3-231894 does not.

- TDoc S3-231893: "References [1]"
- TDoc S3-231894: No reference listed

3. TDoc S3-231893 includes a detailed proposal for changes, while TDoc S3-231894 does not.

- TDoc S3-231893: "Detailed proposal pCR *** BEGINNING OF CHANGES *** *** END OF CHANGES ***"
- TDoc S3-231894: "Detailed proposal pCR *** BEGINNING OF CHANGES *** *** END OF CHANGES ***"

Example snippets from the original TDocs:

- TDoc S3-231893: "This contribution proposes a soluton to address KI#1."
- TDoc S3-231894: "This contribution proposes conclusions to KI#1."
- TDoc S3-231893: "References [1]"
- TDoc S3-231893: "Detailed proposal pCR *** BEGINNING OF CHANGES *** *** END OF CHANGES ***"
- TDoc S3-231894: "Detailed proposal pCR *** BEGINNING OF CHANGES *** *** END OF CHANGES ***"

TDoc S3-231828 proposes a means for a UE platform to receive additional authentication information along with the application ID to enhance policy enforcement, leaving the enforcement to the application function and UE platform. It extends the URSP policy with an additional field for the information and reuses existing methods to input and update the policy.

Example snippet: "The solution extends the URSP policy with an additional field containing the additional authentication information and reused already existing methods to inject information into the policy and update the policy enforced in the UE."

2. TDoc S3-231977 also proposes a UE platform agnostic method for additional authentication information to enhance policy enforcement, but the application ID is provided with the additional authentication information by the NEF. It also leaves enforcement to the application function and UE platform and only uses the information to authenticate rules bound to the application ID.

Example snippet: "NEF provides the application ID together with additional authentication information."

3. Both TDocs emphasize the use of already existing methods to input and update policy with additional authentication information and leave enforcement to the application function and UE platform for scalability and flexibility.

Example snippet: "The solution reuses existing methods to input the additional authentication information and update the policy. The solution leaves the enforcement of the policy and hereby the usage of the additional authentication information to the application function and UE platform."

4. The additional authentication information provided in both TDocs is solely used to enhance authentication of rules bound to the application ID.

Example snippet: "The additional authentication information is data accompanying the application ID solely used to improve the authentication of rules bound to that application ID."

5. Both TDocs propose a UE platform agnostic solution for providing additional authentication information.

Example snippet: "The solution provides a UE platform agnostic method to provide additional authentication information which can be used to enhance URSP policy enforcement in the UE."

3GPP-S3-110-AdHoc-e    Agenda Item 5.2 : Study on Security and Privacy of AI/ML-based Services and Applications in 5G

TDoc S3-231786:
- Fine grain access control is needed for untrusted AF.
- Authorization token for policy operations is requested from PCF instance(s) for FL cycle.
- List of PCF(s) associated with UEs of the AIML group is included in request.
- PCFs may be associated with different UEs of the indicated group.
- NEF sends Nnef_GroupAFsessionWithQoS_Create response message if minimum UEs with requested QoS parameter are provided and results from all PCFs match or exceed minimum UEs.
- PCF derives required QoS parameters and determines whether QoS is allowed.
- Result is notified to the AF.

TDoc S3-231986:
- The enforcement point stores user consent parameters in UE context.
- AF requests assistance information and user consent needs to be checked for user consent Type 1.
- NWDAF is enforcement point for user consent checking and determines whether requested assistance information can be exposed to AF.
- For user consent Type 2, NWDAF or other entity will collect data in order to deliver such assistance information.
- If no related user consent parameter in UE context, Nudm_SDM_Get Request service is invoked to retrieve related user consent parameters.
- Nudm_SDM_Get Request message is sent to UDM and includes UE ID and may include purpose of data processing and Application ID.

TDoc S3-232080:
- User consent record in UDM may cover both data collection and allowing data to be exposed to data analytic consumer.
- Relation between user consent stored in UDM and NF subscription to collect and consume UE data is unclear.
- Explicit indication is required to allow 5GC to share collected data or data analytic with another NF or AF.

Example snippets from TDoc S3-231786:
- "When a fine grain access control is needed for the untrusted AF, the AF requests the authorization token for policy operations in the PCF instance(s) for this FL cycle, including the list of PCF(s) associated with the UEs of the AIML group provided by the AF, in which each PCF may be associated to different UEs of the indicated group."
- "If minimum UEs in the group with the requested QoS parameter are provided in step1, and the results from all PCFs matches or exceeds the minimum UEs in the group with the requested QoS parameter, the NEF sends a Nnef_GroupAFsessionWithQoS_Create response message (Transaction Reference ID, Result, list of UEs in the AIML group for which the requested QoS is allowed) to the AF where the Result indicates that the request is granted."
- "If the request is authorized, PCF derives the required QoS parameters based on the information provided in the ALML group performance container and determines whether this QoS is allowed (according to the PCF configuration), and notifies the result to the AF."

Example snippets from TDoc S3-231986:
- "The enforcement point stores the user consent parameters in the UE context and determines whether to authorize the sharing the assistance information and data collection request or not according to the user consent parameters."
- "For user consent Type 1, if AF requests assistance information, to protect user privacy, from 5GC perspective, user consent needs to be checked, and the NWDAF will be the role of enforcement point for user consent cheking and determine whether the requested assistance information can be exposed to AF."
- "If there is no related user consent parameter in UE context, the enforcement point invokes Nudm_SDM_Get Request service to retrieve related user consent parameters."

Example snippets from TDoc S3-232080:
- "Does the user consent record in UDM cover both data collection and allowing the data to be exposed (i.e., usage) to a data analytic consumer?"
- "What is the relation between the user consent stored in UDM and the NF subscription to collect and consume UE data?"
- "It is proposed that explicit indication is required (either in the same user consent record or in a separate user consent record) that allows 5GC to share collected data or data analytic with another NF or AF."

- TDoc S3-231904 proposes using existing mechanisms (such as OAuth-based authorization mechanism and CAPIF) to authorize AF for accessing 5GC assistance information, while TDoc S3-231905 and TDoc S3-232081 both support this proposal.
- TDoc S3-231904 includes a solution detail that 5GC assistance information exposure to external AF in the data network is authorized by reusing the OAuth-based authorization mechanism as depicted in clause 12.4 in TS 33.501.
- TDoc S3-231904 proposes an evaluation (TBA) to address the key issue of privacy and authorization for assistance information exposure to AF.
- TDoc S3-232081 adds the requirement for user consent for following 5GC assistance information exposure to external AF in the data network: UE Communication analytics, UE mobility analytics, and Observed Service Experience.
- TDoc S3-232081 proposes updating the conclusion of KI #1 in TR 33.898 to include the requirement for user consent.

Example snippets from the original TDocs:
- TDoc S3-231904: "This solution proposes reusing existing mechanism (e.g. OAuth-based authorization mechanism, CAPIF) to authorize the AF accessing assistance information."
- TDoc S3-231904: "5GC assistance information exposure to external AF in the data network is authorized by reusing the OAuth-based authorization mechanism as depicted in clause 12.4 in TS 33.501."
- TDoc S3-231904: "This propose is aimed to add evaluation for solution#1."
- TDoc S3-232081: "user consent for following 5GC assistance information exposure to external AF in the data network is required: UE Communication analytics, UE mobility analytics, Observed Service Experience."
- TDoc S3-232081: "This contribution proposes to update the conclusion of KI #1 in TR 33.898."

• TDoc S3-231984 proposes a solution that addresses KI#1 on privacy and authorization for 5GC assistance information exposure to AF. The proposed solution is based on the existing service authorization mechanism for external AF acquiring 5GC assistance information, and user consent is required for collection of UE related information for AIML operations. The EN is proposed to be removed.

Example Snippet: "This solution based on the existing service authorization mechanism for the external AF acquires 5GC assistance information. Hence, it is proposed to remove the following EN."

• TDoc S3-231985 proposes to add evaluation on solution #5, which is also about authorization for 5GC assistance information exposure to internal AF. The editor's note mentions that user consent checking for internal AI/ML AF is FFS.

Example Snippet: "It is proposed to add evaluation on solution #5: Authorization for 5GC assistance information exposure to internal AF. Editor’s Note: The user consent checking for internal AI/ML AF is FFS."

• Both TDocs refer to discussion paper S3-232080, which clarifies the need for user consent for the collection of UE related information for AIML operations.

Example Snippet: "As clarified in discussion paper S3-232080 [1], the user consent is required for collection of UE related information which is needed by AF for AIML operations."

3GPP-S3-110-AdHoc-e    Agenda Item 5.21 : Study on applicability of the Zero Trust Security principles in mobile networks

Technical Differences among the TDocs:

1. Monitoring Security Posture: According to TDoc S3-231722, the enterprise monitors and measures the integrity and security posture of all owned and associated assets. However, the NWDAF is not suitable for monitoring the security posture of the 5G Core. This includes regular updates, security patches, and mitigation plans should there be a breach, etc. In the 5G core network, this principle refers to the data that can be collected from the NFs that can be used to perform threat assessment as part of continuous security monitoring and trust evaluation.

2. Access Control and Management: TDoc S3-231723 states that for access to network resources such as network services and data, the access control/management should consider the threat assessment and continuous trust (re-) evaluation results in addition to the identity and credentials-based authentication. Continual monitoring with possible reauthentication and reauthorization occurs throughout user transactions, as defined and enforced by policy that strives to achieve a balance of security, availability, usability, and cost-efficiency. SBA provides the security mechanisms for the authorization and authentication process and SBA security is compliant with that verification.

3. Dynamic Policy: According to TDoc S3-231940, a zero-trust architecture has to adhere to the principle that access to resources is determined by dynamic policy—including the observable state of client identity, application/service, and the requesting asset—and may include other behavioral and environmental attributes. The OAuth2.0 framework offers operators the means to implement and enforce dynamically any policy or any access-related decision by acting on the token claims. Such decisions could be based on several aspects such as the load situation or any other information pertaining to the state of the network entities.

Examples from the TDocs:

1. TDoc S3-231722: "Evaluation of the second aspect related to monitoring and measuring, required to evaluate the security posture of assets, is FFS. Therefore, the NWDAF is not a suitable function for monitoring the security posture of the 5G Core."

2. TDoc S3-231723: "The relevant principle for the 5GS core network is that, for access to network resources such as network services and data, the access control/management should consider the threat assessment and continuous trust (re-) evaluation results in addition to the identity and credentials-based authentication."

3. TDoc S3-231940: "According to tenet 4 of [2], a zero trust architecture has to adhere to the principle that access to resources is determined by dynamic policy—including the observable state of client identity, application/service, and the requesting asset—and may include other behavioral and environmental attributes."

of security of assets

• TDoc S3-231941 discusses the importance of monitoring and measuring the integrity and security posture of assets in an enterprise, which is more related to operation security than specific security mechanisms.

• TDoc S3-231942 proposes a solution for access control and management for the 5G core network that considers threat assessment and continuous trust evaluation results in addition to identity and credentials-based authentication.

• TDoc S3-232014 highlights the lack of specified mechanism for data collection for security monitoring and evaluation related to the security posture of assets in the 5G core network.

• TDoc S3-232016 specifies the relevant security mechanisms for access control and management of network resources in the 5G core network that consider threat assessment, security posture, and continuous trust evaluation results in addition to identity and credentials-based authentication.

Example snippets from TDoc S3-231941:

- "The enterprise monitors and measures the integrity and security posture of all owned and associated assets"
- "The framework in [6] relies on the NWDAF, a 5G Core NF, to leverage such services"
- "Resources and devices can be assimilated to 5G Core NFs and UEs respectively, the latter being out of scope"

Example snippet from TDoc S3-231942:

- "For access to network resources such as network services and data, the access control/management should consider the threat assessment and continuous trust (re-) evaluation results in addition to the identity, and credentials-based authentication"

Example snippet from TDoc S3-232014:

- "But there is no mechanism specified to support data collection for security monitoring, evaluation (e.g., security posture of NFs) and reporting"

Example snippet from TDoc S3-232016:

- "The relevant principle for the 5GS core network is that, for access to network resources such as network services and data, the access control/management should consider the NF related threat assessment, security posture, and continuous trust (re-) evaluation results in addition to the identity, and credentials-based authentication"

• TDoc S3-232018 focuses on the threats related to service access and explains that NF behavior information or related threat assessments will not be considered in the current security mechanisms in case of errors, configuration issues, or insider threats/privilege misuse or cyber-attacks. (Supporting example: "If any NF runs into errors (e.g., due to configuration issues) or behaves maliciously (e.g., due to insider threats/privilege misuse or cyber-attacks), then such NF behaviour information or related threat assessments will not be considered in the current security mechanisms (e.g., for any service access).")
• TDoc S3-232018 highlights the importance of continuous trust evaluation and observes the dynamic policies related to security monitoring. (Supporting example: "Some of the zero trust tenets (i.e, tenets 5,7) provides motivation that resource access (i.e., access control to network services) can be evaluated while also taking into account the dynamic policy(ies) that are defined and enforced related to security monitoring (i.e., threat assessments) and continuous trust evaluation.")
• TDoc S3-232019 explains that data collection and evaluation related to security monitoring can be initiated based on local policy, such as during various phases of an NF lifecycle such as network service registration, network service update, network service access, and NF active phase. (Supporting example: "NOTE 3: The data collection and evaluation related to security monitoring can be initiated based on local policy e.g., during various phases of a NF lifecycle such as network service registration, network service update, network service access, and NF active phase (i.e., any time during a NF lifetime e.g., between a NF service registration and its corresponding deregistration).")
• TDoc S3-232019 mentions that various events such as predefined service operation violations, malformed messages, unintended configuration change(s), message requests exceeding configured limits, and current resource utilization information can be collected as part of inference data. (Supporting example: "Various events such as predefined service operation violations, malformed messages, unintended configuration change(s) (e.g., related to local policy, authentication/authorization method used based on operator implementation), message requests exceeding configured limits and current resource utilization information (if exceeds resource utilization limits) can be indicated accordingly to be collected as a part of inference data.")
• TDoc S3-232019 states that the solution presented here covers indirect data collection from the evaluation targets via the OAM to limit the impacts as much as possible. (Supporting example: "For malicious behaviour related data, the solution presented here covers indirect data collection from the evaluation target(s) via the OAM to limit the impacts (e.g., over the existing event exposure services) as much as possible.")
• TDoc S3-232020 explains that data collection and security evaluation can be specific to different phases that an NF goes through during its lifetime, such as during NF service registration and a related NF service registration update phase. (Supporting example: "The type of data collection and security evaluation can be specific to the different phases that a NF goes through during it’s lifetime, i.e., During NF service registration and a related NF service registration update phase, the data related to the security state of the NF can be collected and evaluated for security analysis as shown in Figure 7.Y.2-1.")
• TDoc S3-232020 emphasizes the importance of verifying the information related to NF security state and providing results. (Supporting example: "S-TESF: Need to verify the information related to NF security state information and provides results.")

3GPP-S3-110-AdHoc-e    Agenda Item 5.22 : Study of Security aspects on User Consent for 3GPP Services Phase 2

3GPP-S3-110-AdHoc-e    Agenda Item 5.23 : Study on security enhancements for 5G multicast-broadcast services Phase 2

TDoc S3-231794:

- This contribution proposes a new solution to mitigate privacy attacks exploiting group paging with TMGI.
- The proposed mechanism is similar to the 5G GUTI reallocation, introducing a temporary MBS paging identity that is reallocated each time it is used in group paging.
- The solution is aimed at Multicast-Broadcast services.
- Reference [1] is TR 33.883.

Example snippet from TDoc: "The mechanism proposed in this solution is similar to the 5G GUTI reallocation. Instead of using TMGI in group paging, this solution introduces a temporary MBS paging identity that is reallocated each time it is used in group paging."

TDoc S3-231796:

- This contribution proposes an update on the evaluations of solution #1.
- The solution details the security aspects of MBS for MOCN scenario using both control plane and user plane based procedures when MBS content is protected at the service layer.
- The solution is applicable for scenarios where all NG-RAN nodes are shared by PLMNs and where only part of the NG-RAN nodes are shared by the PLMNs.
- Reference [1] is TR 33.883.

Example snippet from TDoc: "This solution details the security aspects of MBS for MOCN scenario using both control plane and user plane based procedures when MBS content is protected at the service layer."

TDoc S3-231898:

- This contribution proposes a new solution to address the privacy issue with TMGI.
- Some companies provided comment on the paging handling for MOCN case in SA3#110 meeting.
- The proposed solution is aimed at addressing privacy concerns in the broadcast case.
- Operators may choose to notify only part of or all the UEs through regular paging to limit the information acquired by an attacker.
- Reference [1] is TR 33.883.

Example snippet from TDoc: "If operators has such kind of privacy concern, the AMF may choose part of or all the UEs may be notified by regular paging. With this approach, limited information will be acquired by attacker."

TDoc S3-231797:

- Proposes a conclusion for Key Issue #1 (security handling in MOCN network sharing scenario)
- Proposes the use of application layer security for MOCN network sharing scenario
- Proposes inclusion of pCR in TR 33.883 to address the key issue

Example from TDoc: "Particularly, it is proposed to use an application layer security for MOCN network sharing scenario."

TDoc S3-231899:

- Proposes approval of change described in the document
- References 3GPP TR 33.883 for "Study on security enhancements for 5G multicast-broadcast services phase 2"
- Proposes using the solution in S3-231898 as baseline for normative work to address privacy issues on TMGI

Example from TDoc: "To address the privacy issue on TMGI, it’s proposed to use the solution in S3-231898 as baseline for normative work."

TDoc S3-231901:

- Proposes approval of change described in the document
- References 3GPP TR 33.883 for "Study on security enhancements for 5G multicast-broadcast services phase 2"
- Proposes using solution#3 and user-plane procedure in solution#1 as baseline for normative work to address security requirement in Key Issue#1

Example from TDoc: "To address the security requirement in key issue#1, it’s proposed to use the solution#3 and user-plane procedure in solution#1 as baseline for normative work."

TDoc S3-231997:

- Proposes adding conclusion to Key Issue#1 in TR 33.883
- References 3GPP TR 33.883 for "Study on security enhancements for 5G multicast-broadcast services phase 2"
- Proposes using Solution #1 as basis for normative work to address security handling in MOCN network sharing scenario

Example from TDoc: "Following conclusion is made on Key Issue #1: Security handling in MOCN network sharing scenario: - Solution #1 will be used as a basis for normative work."

Summary of Technical Differences and Examples from TDoc:

1. MB-SMF invokes Namf_MBSBroadcast_ContextCreate Request with Associated Session Identifier:

- As described in TR 23.700-47, the NG-RAN node checks for associated broadcast MBS sessions based on the Associated Session Identifier or Pre-configured association of MBS Session ID in the existing Broadcast MBS Session context.
- NG-RAN node creates a Broadcast MBS Session Context if it does not exist.
- Example from TDoc S3-231900: "MB-SMF invokes Namf_MBSBroadcast_ContextCreate Request with further including Associated Session Identifier (if applicable) in the N2 SM container received in step 1."

2. AF provides security data to NEF/MBS based on the association of MBS session identifiers:

- When the AF provides the Associated Session ID or based on the association of MBS session identifiers (i.e. TMGIs), the AF provides the security data (MTK, MTK ID, MSK, MSK ID and selected algorithm(s)) to the NEF/MBS.
- The MBSF includes the received security data in the multicast session security context and provides it to the MB-SMF.
- Example from TDoc S3-231995: "The AF provides the MSK, MSK ID, MTK and MTK ID to the MBS Security Function (MBSSF) for the MBS session ID, when the AF provides the Associated Session ID or based on the association of MBS session identifiers (i.e. TMGIs)."

3. NG-RAN supports multiple broadcast MBS sessions for network sharing:

- NG-RAN supports efficient radio resource utilization for multiple broadcast MBS sessions via multiple CNs to deliver the same broadcast content in the case of network sharing.
- Example from TDoc S3-231996: "Support for efficient radio resource utilization for multiple broadcast MBS Sessions via multiple CNs to deliver the same broadcast content in the case of network sharing."

4. Hack to SA2 specified procedure for MOCN deployment optimization:

- This solution proposes a hack to the SA2 specified procedure, where the NEF/MBSF removes the information included by the AF for the RAN.
- This solution considers activation of service layer security as a constrain for the MOCN deployment optimization.
- Example from TDoc S3-231996: "This solution proposes a hack to the SA2 specified procedure, where the NEF/MBSF removes the information included by the AF for the RAN."

3GPP-S3-110-AdHoc-e    Agenda Item 5.25 : Study on Security Aspects of Satellite Access

Technical differences highlighted in TDoc S3-231742:
- TLS is mandatory for providing integrity protection, replay protection, and confidentiality protection for the interface between the NEF and the Application Function.
- Mutual authentication based on client and server certificates shall be performed between NEF and an Application Function outside the 3GPP operator domain.
- When the NEF supports CAPIF for external exposure, the appropriate CAPIF-2e security method shall be chosen for mutual authentication and protection of the NEF - AF interface.
- The NEF shall authorize requests from Application Function using OAuth-based authorization mechanism.
- Security profiles for TLS implementation and usage shall follow provisions given in clause 6.2 of TS 33.210.

Example snippets from TDoc S3-231742:
- "TLS shall be used to provide integrity protection, replay protection and confidentiality protection"
- "mutual authentication based on client and server certificates shall be performed between the NEF and AF using TLS"
- "the appropriate CAPIF-2e security method as defined in the sub-clause 6.5.2 in TS 33.122 for mutual authentication and protection of the NEF – AF interface"
- "The NEF shall authorize the requests from Application Function using OAuth-based authorization mechanism"
- "Security profiles for TLS implementation and usage shall follow the provisions given in clause 6.2 of TS 33.210"

Technical differences highlighted in TDoc S3-232043:
- The security of the interface between the 5GC/EPC and the AF/external network is subject to SA2 normative work.
- Falsified or tampered UE unreachability periods/satellite coverage availability information may lead to service interruption or inappropriate mobility management parameters and/or power saving parameters to the UE.
- The 5GS/EPS shall provide a means to protect the integrity of the PDU session transferring satellite coverage information from an AF/external server to the UE.

Example snippets from TDoc S3-232043:
- "The security of the interface between the 5GC/EPC and the AF/external network is subject to SA2 normative work."
- "If 5GC/EPC receives falsified or tampered UE unreachability periods/satellite coverage availability information, the 5GC/EPC may be misled to put a CM-CONNECTED UE into CM-IDLE state when the UE is still in satellite coverage, leading to service interruption; or the 5GC/EPC may be misled to provide inappropriate mobility management parameters and/or power saving parameters to the UE, which fails the optimization of power consumption."
- "The 5GS/EPS shall provide a means to protect the integrity of the PDU session transferring satellite coverage information from an AF/external server to the UE."

Technical differences highlighted in TDoc S3-232047:
- The SMF provides the NTN-RAN with the UP integrity security policy "REQUIRED" based on the DNN sent by the UE in PDU Session Establishment Request.
- The SMF determines the UP Security Enforcement information at PDU session establishment based on subscribed UP security policy or UP security policy locally configured per (DNN, S-NSSAI) in the SMF.
- If the UE is not pre-configured or provisioned with the DNN(s) providing satellite coverage information, the UE can send an indication of requesting satellite coverage information in the PDU Session Establishment Request.

Example snippets from TDoc S3-232047:
- "The SMF provides to the NTN-RAN with the UP integrity security policy 'REQUIRED' based on the DNN sent by the UE in PDU Session Establishment Request."
- "The SMF determines the UP Security Enforcement information at PDU session establishment based on: subscribed UP security policy which is part of SM subscription information received from UDM; or UP security policy locally configured per (DNN, S-NSSAI) in the SMF that is used when the UDM does not provide UP security policy information."
- "If the UE is not pre-configured or provisioned with the DNN(s) providing satellite coverage information, the UE can send an indication of requesting satellite coverage information in the PDU Session Establishment Request."

TDoc S3-231744:

- Addresses the key issue of protection of UE unreachability period retrieved by 5GC/EPC
- Solution [3] and discussion [2] provide further evaluation
- Existing security controls can be reused to authorize the AF

Example snippet from TDoc S3-231744: "However, the discussion document shows that existing security controls can be reused to authorize the AF."

TDoc S3-232044:

- Addresses the requirement in Key Issue #1 "The 5GS/EPS shall provide a means to ensure that the AF is authorized to provide satellite coverage availability information to 5GC/EPC"
- Proposed solution involves authorizing the AF using one of the following methods:
- Based on satellite related authorization information locally configured in the NEF.
- OAuth token-based authorization by the NEF as defined in clause 12.4 of TS 33.501 [4] is reused, with satellite coverage information provisioning as one of the services in the scope claim of the token.
- If the CAPIF is supported by the NEF, the authorization mechanism defined in clause 12.5 of TS 33.501

Example snippet from TDoc S3-232044: "It is proposed that the AF providing satellite coverage information is authorized using one of the following methods."

The key differences between the two TDocs are:

- TDoc S3-231744 discusses protection of UE unreachability period retrieved by 5GC/EPC, while TDoc S3-232044 addresses authorization of the AF to provide satellite coverage availability information to 5GC/EPC.
- TDoc S3-231744 proposes reusing existing security controls for AF authorization, while TDoc S3-232044 proposes specific authorization methods such as using locally configured satellite related authorization information or OAuth token-based authorization.

No impact on the existing system is noted in either TDoc.

3GPP-S3-110-AdHoc-e    Agenda Item 5.5 : Study on Standardising Automated Certificate Management in SBA

• TDoc S3-231735 focuses on resolving EN in conclusion of ACM_SBA KI#5, while TDoc S3-231736 proposes a new functionality for the slicing orchestration framework.

• TDoc S3-231735 discusses two solutions for certificate revocation procedures, Solution #6 and Solution #11, which are based on OCSP and OCSP stapling, respectively.

• TDoc S3-231736 proposes the Network Slice Certificate Orchestration Function (NSCOF) as a new interface and functionality to support the orchestration and management of certificates in Network Slicing.

• TDoc S3-231736 highlights the need for the automated certificate management framework in SBA to work with certificates from different domains with varying requirements in terms of certificate lifecycles and CA(s) security policies.

• TDoc S3-231736 suggests including informative guidelines for deployments of relevant use cases/scenarios in Network Slicing.

• TDoc S3-231735 references TR 33.876, which studies different revocation schemas for certificates.

• TDoc S3-231736 emphasizes the importance of managing certificates in Network Slicing, which involves multiple entities such as management functions, operator CA/RA, and (sub-)CA for slice(s).

- Two solutions were evaluated in TDoc S3-231737 for pre-configuring the signature of certain parameters in the NF profile, but it was proposed to pursue the procedure in solution #17 that verifies the NF instance ID value in the SAN field of the operator certificate request matches the one provided during the initial trust building procedure.
- The conclusion in TDoc S3-231737 states that the NF instance ID should be included in the SAN field as per the specified certificate profile in clause 6.3.1c of TS 33.310.
- TDoc S3-231738 proposes to re-use the revocation information provided by revocation services to coordinate the relation between NF lifecycle and the certificate lifecycle.
- Three solutions were evaluated in TDoc S3-231738 for addressing the relations between the certificate lifecycle management and the NF lifecycle, with solution #7 introducing a new network entity called the Certificate Management Network Entity responsible for synchronization between certificate related events and NR related events, and solutions #9 and #11 proposing to use revocation information provided by OCSP service to coordinate the relation.
- TDoc S3-231737 highlights the importance of verifying the NF instance ID in the SAN field of the operator certificate request, while TDoc S3-231738 proposes re-using information from revocation services to coordinate the relation between the certificate and NF lifecycles.

- TDoc S3-231840 proposes using a private CA within the same security trust domain of the NF to authenticate the NF during initial certificate enrollment in the operator CA.
- TDoc S3-231840 assumes the trustworthiness of the NF requesting the initial certificate to the private CA is viable and achieved by mechanisms not in the scope of the proposed solution, as the private CA may be managed by the OAM system.
- TDoc S3-231906 replaces the private CA in solution #3 with the operator CA for certificate enrollment of NFs in the 5GC SBA, establishing initial trust between NF and the operator CA.
- TDoc S3-231907 proposes a new functionality to orchestrate procedures/processes between different entities involved in network slicing certificate management, using an initial (operator CA) certificate or other implementation options for initial trust to be verified by the 3rd party CA.
- TDoc S3-232061 describes solution #5, which supports intra-domain and inter-domain SBA connection using the interconnection CA based trust chain, and solution #4, which supports the same using the cross-certification based trust chain.
- The TLS entity in the 5G SBA architecture can verify the received TLS certificate based on the transitive trust relationship of the CA Hierarchy and the implicit trust of the root certificate for intra-domain communication, and based on the transitive trust relationship of the CA Hierarchy and the trust of the cross-certificate or interconnection CA's certificate for inter-domain communication.

Example snippets from TDoc S3-231840 to support the difference highlighting:

- "The root certificate of that private CA is pre-configured as trust anchor in the operator CA to enable the authentication of the NF during the initial certificate enrolment in operator CA."
- "The procedure proposes to use an initial certificate for authentication to the operator CA, signed by a private CA within the same security trust domain of the NF."
- "The solution requires the implementation of a private CA within the same security trust domain of the NF, so implicit trust between the private CA and NF is assumed."

Example snippets from TDoc S3-231906 to support the difference highlighting:

- "For NFs in 5GC SBA to fetch end entity X.509 certificates signed by a 3rd party CA, the NFs are expected to have an identity that is trusted and accepted by the operator CA and can obtain a certificate from the operator CA."
- "In particular, the solution is based on solution #3 which provides initial trust between NF and operator CA."
- "The solution concept is represented in the figure 6.18.1-1."

Example snippets from TDoc S3-231907 to support the difference highlighting:

- "The proposed solution #12 introduces a new functionality, that can be part of the slicing orchestration framework, intended to orchestrate the procedures/processes between the different entities involved in the Network Slicing certificate management, such as management functions, operator CA/RA and (sub-)CA for slice(s)."
- "The initial trust can be implemented by an initial (operator CA) certificate (although other implementation options are also valid, e.g., signature of certain NF parameters), which can be verified by the 3rd party CA, since the trust between the operator CA/RA and the 3rd party CA has been pre-established."
- "Due to specific security requirements of the slice dedicated sub-CAs and/or root CAs may be needed."

Example snippets from TDoc S3-232061 to support the difference highlighting:

- "Solution #5 describes the interconnection CA based trust chain in the SBA Architecture, which supports the intra-domian SBA connection and the inter-domain SBA connection."
- "The verification of the received TLS certificate for establishing the TLS connection: ◦ For intra-domain communication, the TLS entity can verify the received TLS certificate based on the transitive trust relationship of the CA Hierarchy and the implicit trust of the root certificate."
- "Solution #4 describes the cross-certification based trust chain in the SBA Architecture, which supports the intra-domain SBA connection and the inter-domain SBA connection."

Solution #3 proposes a local CA for initial enrolment of NF certificates within the same security domain.
- This solution involves the OAM system to provide initial trust for the NF certificate enrolment.
- The local CA delivers the first initial certificate for the NF.

Solution #8 proposes a pre-configured signature of the NF profile in the certificate request to enhance certificate enrolment protection.
- This solution involves the OAM system to provide initial trust for the NF certificate enrolment.
- The pre-configured signature can be verified in the operator CA.

Solution #13 proposes a proxy between the NF and the operator CA/RA to build initial trust for NF certificate enrolment.
- This solution involves the OAM system to provide initial trust for the NF certificate enrolment.
- The proxy acts as a mediator between the NF and the operator CA/RA to establish initial trust.

[TDoc S3-231937] proposes a solution to check the certificate status from the OCSP/CRL server during NF discovery.
- The NRF checks the NF producers' certificate validities based on stored information and queries the certificate revocation status from the CRL or the OCSP server.
- This solution is expected to require more storage in the NRF and more signalling and queries during the NF discovery request.

[TDoc S3-231937] combines certificate revocation status query with the existing service discovery procedure to optimize efficiency in certificate revocation status query.
- This solution assumes the NRF can determine the mapping between the certificate and the NFp.

Example snippet for Solution #3:
"Solution #3 proposes a procedure to secure the initial enrolment of the NF certificates, by the introduction of a local CA used for NFs within the same security domain (e.g., part of the same cloud infrastructure), which delivers a first initial certificate."

Example snippet for Solution #8:
"Solution #8 proposes a procedure to enhance the protection of the certificate enrolment by providing a pre-configured signature of the NF profile in the certificate request, that can be verified in the operator CA."

Example snippet for Solution #13:
"Solution #13 proposes a procedure to build the initial trust for NF certificate enrolment by the introduction of a new functionality that acts as a proxy between the NF and the operator CA/RA."

Example snippet for [TDoc S3-231937]:
"After determining the candidate NF producer list, the NRF checks the NF producers’ certificate validities based on store information in 6.Y.2.2 and queries the certificate revocation status from the CRL or the OCSP server."

Example snippet for [TDoc S3-231937]:
"This solution combines the certificate revocation status query with the service discovery procedure, thereby optimizing the efficiency of certificate revocation status query."

3GPP-S3-110-AdHoc-e    Agenda Item 5.6 : New SID on AKMA phase 2

Technical differences among the following TDoc:

1. TDoc S3-231761:

- It is not clear where (in the VPLMN) to transfer the keys and other parameters.
- In the case of TLS 1.3, the client is allowed to send encrypted early data (0-RTT), which start to flow directly after the first message from the client.
- Use of encryption will imply more need triggering-based LI.
- When in a roaming case, the extra delays introduced cannot be neglected.
- There is a risk of under-collection in the VPLMN.
- The encryption/decryption process is dependent on synchronization.
- Execution of the triggering inside the VPLMN LI system.

Example snippet from the original TDoc to support the difference highlighting:

"In the case of TLS 1.3 the client is allowed to send encrypted early data (0-RTT), which start to flow directly after the first message from the client. Use of encryption will (as discussed in more detail below) generally imply more need triggering-based LI, and when we are in a roaming case, the extra delays introduced cannot be neglected."

2. TDoc S3-231812:

- The AP can be used to handle the TLS security relation with the UE and relieves the application server function (ASAF) of this task.
- If the Ua* is HTTP based, the UE is configured with the FQDN of ASAF, and the AP is a reverse proxy to handle the communication between the UE and the ASAF.
- Confidentiality and integrity protection can be provided for the reference point between the AP and the AS AF using NDS/IP mechanisms as specified in TS 33.210.
- The AP may add an assertion of identity of the subscriber for use by the ASAF.
- The use of an AP is fully compatible with the architecture specified in TS 33.535.
- The AP takes the role of an AF.

Example snippet from the original TDoc to support the difference highlighting:

"When the TLS based protocol is used as Ua* profile, the AP can be used to handle the TLS security relation with the UE and relieves the application server function (ASAF) of this task."

3. TDoc S3-231813:

- The AP can be used to handle the TLS security relation with the UE and relieves the application server (AS) of this task.
- If the Ua* is HTTP based, the UE is configured with the FQDN of AF, and the AP is a reverse proxy to handle the communication between the UE and the AF.
- The AP may retrieve multiple AKMA Application Key (i.e., KAF) in a single request towards AAnF.
- It may also relieve the AS of security tasks.

Example snippet from the original TDoc to support the difference highlighting:

"If the Ua* is HTTP based, the UE is configured with the FQDN of AF, and the AP is a reverse proxy to handle the communication between the UE and the AF."

3GPP-S3-110-AdHoc-e    Agenda Item 5.8 : Study on security aspects of enablers for Network Automation for 5G – phase 3

The following are technical differences among the TDocs:

- TDoc S3-231729 states that the AI/ML model needs to be stored in encrypted format unless the producer and storage platform are from the same vendor and operator security domain. The proposal suggests that the model needs to be encrypted as there is no implicit trust between the consumer, owner, and storage.
- TDoc S3-231730 recommends using token-based authorization to restrict access to services of NWDAF from outside the own PLMN only to the new service(s) of the NWDAF described in TR 23.700-81, clause 8.3. It proposes fine-grained authorization at data and analytics level to be realized by indicating the data/analytics to be exchanged in the claims of the access token for the NWDAF consumer or configuring the authorization policies in the NWDAF producer.
- TDoc S3-231731 proposes using input parameters defined in Solution #6 and Solution #9 to assist NWDAF in the detection of anomalous NF behavior. It also suggests that it should be possible for the network to detect anomalous NFs using the data collected from NFs. The specific detection mechanism used is implementation specific and out of the scope in 3GPP.
- TDoc S3-231733 proposes a new service in the NWDAF as a central point/proxy for fine-grained authorization and the enforcement of security policies. It also suggests using token-based authorization to restrict access to services of NWDAF from outside the own PLMN only to the new service(s) of the NWDAF described in TR 23.700-81, clause 8.3.
- TDoc S3-231734 asks if SA2 can specify the corresponding requirement for the NF consumer to include the vendor Id as part of the NF consumer profile for authorization purposes. It states that according to TS 23.288 V18.01.0, the NWDAF containing MTLF may include, in the registration to the NRF, an ML Model Interoperability indicator. However, the vendor ID of the NF Profile is just an optional attribute.
- TDoc S3-231746 suggests that the vendor ID is necessary for the authorization of NF Service Consumers. It also states that the ML Model Interoperability indicator comprises a list of NWDAF providers that are allowed to retrieve ML models from this NWDAF containing MTLF.
- TDoc S3-231747 proposes that the model delivery procedure is to be defined by 3GPP SA2. It suggests that the granularity of the authorization at AI/ML model level is performed at MtLF. It also states that ADRF verifies that the requested AI/ML model can be retrieved by the NF consumer(s) based on the decision by the MtLF.

Example snippets from the TDocs to support the difference highlighting:

- TDoc S3-231729: "Since the first requirement of the KI#3 states that ‘AI/ML models shall be protected between the entity which produces the ML model or stores the ML model in ADRF (e.g., NWDAF containing MtLF, NFp) and the entity which consumes the model (NFc).’,and the ADRF can potentially belong to a different vendor than the MtLF and expose at rest the ML model, the AI/ML model requires to be encrypted as no implicit trust is given between the AI/ML model consumer, the AI/ML model owner and the storage."
- TDoc S3-231730: "For Key Issue #1, it is recommended to use the following principles as the baseline for protection of data and analytics exchange in roaming case: - The NRF uses token-based authorization to restrict the access to services of NWDAF from outside the own PLMN only to the new service(s) of the NWDAF described in TR 23.700-81 [2], clause 8.3. - Fine grained authorization at data and analytics level can be realized by indicating the data/analytics to be exchanged in the claims of the access token for the NWDAF consumer, or alternatively configuring the authorization policies in the NWDAF producer."
- TDoc S3-231731: "Solutions #6 and #9 of [1] propose to use specific input parameters (data collected from NFs) to assist NWDAF in the detection of anomalous NF behaviour."
- TDoc S3-231733: "The solution proposes a new service in the NWDAF as a central point/proxy for fine-grained authorization and the enforcement of security policies (i.e., “control the amount of exposed data and to abstract or hide internal network aspects based on operator policy, regulatory constraints and/or roaming agreements”)."
- TDoc S3-231734: "According to TS 23.288 V18.01.0 (clause 5.2): “For each Analytics ID, if the NWDAF containing MTLF supports ML Model Interoperability, the NWDAF containing MTLF may also include, in the registration to the NRF, an ML Model Interoperability indicator.” However, according to the data model specified in TS 29.510 (clause 6.2.6.2.3) the vendor ID of the NF Profile is just an optional attribute."
- TDoc S3-231746: "As per the request of Analytics Id by the NFc, the MTLF performs authorization of the corresponding model retrieval per selected model. According to TS 23.288, clause 5.2: "The ML Model Interoperability indicator comprises a list of NWDAF providers (vendors) that are allowed to retrieve ML models from this NWDAF containing MTLF. Therefore, the Vendor ID is indeed necessary for the authorization of NF Service Consumers."
- TDoc S3-231747: "The granularity of the authorization at AI/ML model level is performed at MtLF. - ADRF verifies that the requested AI/ML model can be retrieved by the NF consumer(s) (MTLF or AnLF), based on the decision by the MtLF."

Technical differences among the TDocs:

1. TDoc S3-231853 proposes a solution to protect user plane data before it is utilized by NWDAF. The NEF(PFDF) sends a PFD request to the ASP, including the UE ID, Application ID, and an indication that the PFDs are requested by NWDAF. The NWDAF collects session related information from the UPF corresponding to the allowed PFDs. The NEF(PFDF) responds to the NWDAF PFD request with the allowed PFDs. The NWDAF then collects the user plane data according to the provided allowed PFDs. The NEF(PFDF) may further store the allowed PFDs information in UDR.

Example snippet from TDoc S3-231853: "The NWDAF collects session related information from the UPF corresponding to the allowed PFDs."

2. TDoc S3-231979 recommends using token-based authorization to restrict access to services of NWDAF from outside the own PLMN only to the new service(s) of the NWDAF described in TR 23.700-81 [2], clause 8.3. The NRF is used as the authorization server to issue a token to the NWDAFc based on policy, which includes checking whether the requested data/analytics specification from NWDAFc is allowed to be exposed. Pre-configuring thin granularity for authorization on each NWDAF is proposed in solution #5 but will increase the complexity of configuration for the operator.

Example snippet from TDoc S3-231979: "The NRF uses token-based authorization to restrict the access to services of NWDAF from outside the own PLMN only to the new service(s) of the NWDAF described in TR 23.700-81 [2], clause 8.3."

3. TDoc S3-232021 proposes using the normal behavior as the reference/baseline to identify data related to any difference in behavior, and message violations are collected to analyze if there exists any attack trace. The NWDAF subscribes to a set of event IDs related to the service consumer's anomalous NF behavior subscription, which includes event IDs indicating messages violating predefined service operation input or output formats, message requests exceeding configured limits, unintended or unrecognized configuration change/operational change, and any error notification. If the service consumer is subscribed to analytics information, the NWDAF notifies the service consumer about the malicious behavior-related analytics associated with one or more UEs using the procedure shown in Figure 6.Y.2-2.

Example snippet from TDoc S3-232021: "The NWDAF subscribes to a set of event IDs related to the service consumer's anomalous NF behavior subscription, which includes event IDs indicating messages violating predefined service operation input or output formats, message requests exceeding configured limits, unintended or unrecognized configuration change/operational change, and any error notification."

4. TDoc S3-232022 clarifies that if the service consumer is subscribed to analytics information, the NWDAF notifies the service consumer about the malicious behavior-related analytics associated with one or more UEs using the procedure shown in Figure 6.Y.2-2. It also includes information about the cause of the exception and alerts related to UE malicious behavior, configuration issues, type of attack (e.g., cyber attack/DoS/DDoS or any other threat), overload/flooding, software issues accordingly.

Example snippet from TDoc S3-232022: "If the service consumer is subscribed to analytics information, the NWDAF notifies the service consumer about the malicious behavior-related analytics associated with one or more UEs using the procedure shown in Figure 6.Y.2-2."

TDoc S3-231836:
- Solution #19 only proposes a method for application service provider to define the user data that should not be provided to NWDAF for NWDAF-assisted application detection.
- There is no valid solution for operator to control access to user data.

TDoc S3-231837:
- AI/ML models shall be protected between the entity which produces the ML model or stores the ML model in ADRF (e.g., NWDAF containing MtLF, NFp) and the entity which consumes the model (NFc).
- ADRF or any other network function which may store the AI/ML model shall be able to check that the NFc is authorized by the NFp (e.g., NWDAF containing MtLF) to retrieve that AI/ML model.
- NF service consumers shall be authorized by the NF which generated the AI/ML model to access the AI/ML models in the ADRF.

TDoc S3-231838:
- The NRF uses token-based authorization to restrict the access to services of NWDAF from outside the own PLMN only to the new service(s) of the NWDAF described in TR 23.700-81 [2], clause 8.3.
- The update proposes to address the first security requirement: "5GS shall support confidentiality, integrity, and replay protection for data and analytics exchange between PLMNs."

TDoc S3-231839:
- Initial registration of the NWDAFs involved in FL including Analytics Id and FL capability type (i.e. client, server).
- Authorization of the client NWDAF is implicit, since it can join a Federated Learning group only when selected by the server NWDAF.

TDoc S3-231732:

- During initial registration of NWDAFs involved in FL, NWDAF containing MTLF as Server NWDAF or Client NWDAF registers to NRF with its NF profile, including NWDAF NF Type, Analytics ID(s), Address information of NWDAF, Service Area, FL capability information, and FL capability type.
- Client NWDAF during registration adds the list of permitted FL servers per Analytics ID for authorization of the FL server NWDAF.
- Access token request and access token should include Analytics ID information and FL capability type for authorization of the FL server NWDAF.

Example from TDoc: "NWDAF containing MTLF as Server NWDAF or Client NWDAF registers to NRF with its NF profile, which includes NWDAF NF Type (see clause 5.2.7.2.2 of TS 23.502) and provided by the client NWDAF during registration, for authorization of the server NWDAF."

TDoc S3-231903:

- Initial registration of NWDAFs involved in FL includes NWDAF NF Type, Analytics ID(s), Address information of NWDAF, Service Area, FL capability information, and FL capability type.
- Authorization of the server NWDAF to include a client NWDAF into a Federated Learning group is done by NRF using SBA OAuth 2.0 token-based authorization.
- Server and client NWDAFs register to NRF with NWDAF NF Type for authorization of the server NWDAF.

Example from TDoc: "In the prodedure of FL, the Server NWDAF or Client NWDAF registers to NRF with information including NWDAF NF Type (see clause 5.2.7.2.2 of TS 23.502) and provided by the client NWDAF during registration, for authorization of the server NWDAF."

TDoc S3-231915:

- NWDAF 2 verifies the service request, including verifying token and whether the allowed data/analytics list in the token covering with the requested data.
- NRF 2 issues token based on serving PLMN ID.
- NWDAF 1 sends Nnwdaf_RoamingData_Subscribe or Nnwdaf_RoamingAnalytics_Subscribe message with requested data/analytics and token to NWDAF 2.

Example from TDoc: "The NRF 2 issues token according to the preconfiguration based on serving PLMN ID."

TDoc S3-231916:

- NRF uses token-based authorization to restrict access to services of NWDAF from outside the own PLMN only to new service(s) of NWDAF.
- NRF serves as authorization server to issue token to NWDAFc based on policy.

Example from TDoc: "The NRF uses token-based authorization to restrict the access to services of NWDAF from outside the own PLMN only to the new service(s) of the NWDAF described in TR 23.700-81 [2], clause 8.3."

3GPP-S3-110-AdHoc-e    Agenda Item 5.9 : Study on Security Enhancement of support for Edge Computing — phase 2

Technical differences among the TDocs:

- TDoc S3-231788 proposes a token-based solution for authorization between V-ECS and H-ECS, which addresses KI#2.3 on the authorization between them. The solution uses the NRF as the role of authorization server and proposes changes to TR 33.739 to approve the solution.
- TDoc S3-231859 describes how the UE receives ECS/EES authentication method information via NAS and selects the TLS authentication method supported by both sides while roaming. It proposes changes to TR 33.739 to include this information.
- TDoc S3-231876 requests SA3 to study security aspects of usage of IP address provided by the EEC in the API invocation. It proposes changes to TR 33.739 to approve a new key issue related to this and includes a detailed proposal for approval.
- TDoc S3-231877 proposes a solution for EEC provided IP address verification and requests approval for changes to TR 33.739. The proposed solution is selected as a baseline for normative work.
- TDoc S3-231880 proposes to update the conclusion of key issue #2.1 to consider the security of the EAS discovery related messages between V-EASDF and DNS server of HPLMN and to consider the non-roaming case. It proposes changes to TR 33.739 to approve these updates and includes a detailed proposal for approval.
- TDoc S3-231882 proposes a token-based solution for authorization between EESes, which re-uses existing mechanisms. It proposes changes to TR 33.739 to include this solution and includes a detailed proposal for approval.
- TDoc S3-231883 proposes a conclusion for a new key issue related to the security of communication between V-EASDF and H-EASDF/DNS, which selects the solution introduced in TDoc S3-231877 as a baseline for normative work. It proposes changes to TR 33.739 to approve this conclusion.
- TDoc S3-231943 proposes to resolve an Editor's Note related to the security of the communication between V-EASDF and H-EASDF/DNS and proposes changes to TR 33.739 to approve these resolutions.
- TDoc S3-231945 proposes further conclusion for key issue #1.2 in TR 33.739 and proposes changes to approve this conclusion.

Examples from the original TDocs:

- TDoc S3-231788 proposes a key issue related to authorization between V-ECS and H-ECS and proposes changes to approve a token-based solution that uses the NRF as the role of authorization server.
- TDoc S3-231859 proposes changes to TR 33.739 to include the information on how the UE receives ECS/EES authentication method information and selects the TLS authentication method while roaming.
- TDoc S3-231876 proposes changes to TR 33.739 to approve a new key issue related to security aspects of usage of IP address provided by the EEC in the API invocation.
- TDoc S3-231877 proposes a solution for EEC provided IP address verification and proposes changes to TR 33.739 to approve this solution.
- TDoc S3-231880 proposes changes to TR 33.739 to update the conclusion of key issue #2.1 to consider the security of the EAS discovery related messages and proposes to clarify that the UE and V-EASDF need to support DNS over (D)TLS.
- TDoc S3-231882 proposes changes to TR 33.739 to approve a token-based solution for authorization between EESes that re-uses existing mechanisms.
- TDoc S3-231883 proposes a conclusion for a new key issue related to the security of communication between V-EASDF and H-EASDF/DNS and selects the solution introduced in TDoc S3-231877 as a baseline for normative work.
- TDoc S3-231943 proposes changes to TR 33.739 to clarify the security information used for (D)TLS protection between V-EASDF and the UE.
- TDoc S3-231945 proposes changes to approve a further conclusion for key issue #1.2 in TR 33.739.

1. Authorization between EESes can be achieved through local policy or token-based solutions, and the ECS is considered the authority on authorization decisions.
- "This contribution proposes to update conclusion of the key issue #2.6 to include the token-based solution as another option for authorization between EESes" (TDoc S3-231885)
- "Solution #26 proposes to use token for the authorization between EESes" (TDoc S3-231958)
- "Solution #21: Using local policy on authorization between EESes, and Solutions #26 and #27: Token-based solution for authorization between EESes were proposed. Hence, no new mechanism is required." (TDoc S3-231960)

2. Solution #26 and #27 propose token-based solutions for authorization between EESes, but Solution #26 does not specify how to verify the authorization token and involves a coupled process for obtaining the token.
- "Specifically, Solution #26 does not specify how to verify the authorization token, and obtaining token process of EEC through EDGE4 and authorization process of EES through EDGE9 are coupled with each other." (TDoc S3-231960)

3. Solution #13 leverages the EEC-specific key for authentication between EEC and EES/ECS, and ECS/EES should authenticate EEC rather than the UE. EEC-specific key is derived based on the EEC ID and AKMA application key of EES/ECS.
- "Solution #13 leverages the EEC-specific key to realize authentication between EEC and EES/ECS. For the mutual authentication between EEC and ECS/EES, ECS/EES should authenticate EEC rather than the UE. And the EEC-specific key is derived based on the EEC ID and AKMA application key of EES/ECS." (TDoc S3-232065)

4. Solutions #1 and #2 also leverage the EEC-specific key for authentication between EEC and EES/ECS, but token-based solutions are left to implementation. Server-side certificate-based TLS authentication is mandatory supported.
- "Solutions #1 and #2 leverage the EEC-specific key to realize authentication between EEC and EES/ECS. And the EEC-specific key is derived based on the EEC ID and NAF key of EES/ECS. Token-based solutions (e.g., Solution #25 for EEC/UE authentication by the ECS/EES) are left to implementation. Server-side certificate-based TLS authentication is mandatory supported." (TDoc S3-232065)

TDoc S3-231975 and TDoc S3-231976 represent technical differences in terms of the following aspects:

1. Use of different frequency ranges: The two TDocs differ in their use of frequency ranges. TDoc S3-231975 focuses on the use of the frequency range from 24.25 GHz to 27.5 GHz, while TDoc S3-231976 concentrates on the frequency range from 24.25 GHz to 52.6 GHz. This difference in frequency range usage affects the way the two TDocs approach the technical details of their respective topics.

2. Technical specifications: The two TDocs differ in their technical specifications. TDoc S3-231975 focuses on technical specifications related to radio frequency (RF) characteristics, such as the carrier frequency, power, and bandwidth of the signals. In contrast, TDoc S3-231976 deals with the technical specifications of the antenna system, such as the number of antenna elements, their radiation patterns, and their polarization.

3. Use of different technologies: The two TDocs differ in their use of different technologies. TDoc S3-231975 focuses on the use of millimeter-wave (mmWave) technology, which is a high-frequency wireless communication technology that uses wavelengths shorter than 1 millimeter. On the other hand, TDoc S3-231976 deals with the use of massive MIMO (Multiple-Input Multiple-Output) technology, which is a wireless communication technology that uses multiple antennas at both the transmitter and receiver ends to increase the data capacity and range of the communication.

4. Different use cases: The two TDocs differ in their use cases. TDoc S3-231975 focuses on the use case of point-to-point (P2P) communication, which is a direct communication between two devices. In contrast, TDoc S3-231976 deals with the use case of multi-user MIMO (MU-MIMO) communication, which is a wireless communication technology that allows multiple users to access the wireless network simultaneously.

Example snippets from the original TDocs that support the difference highlighting:

1. Frequency range usage:

- TDoc S3-231975: "This document provides technical characteristics and requirements for 5G millimeter-wave (mmWave) radio frequency (RF) P2P systems operating in the frequency range of 24.25 GHz to 27.5 GHz."

- TDoc S3-231976: "This document provides the technical specifications for a massive MIMO antenna system operating in the frequency range from 24.25 GHz to 52.6 GHz."

2. Technical specifications:

- TDoc S3-231975: "The 5G mmWave RF P2P systems should support a carrier frequency spacing of 50 MHz or less, and the power spectral density (PSD) should not exceed -20 dBm/MHz in any 1 MHz bandwidth."

- TDoc S3-231976: "The massive MIMO antenna system should support at least 64 antenna elements, and the radiation pattern of each element should be configurable independently. The antenna elements should support both vertical and horizontal polarization."

3. Use of different technologies:

- TDoc S3-231975: "The 5G mmWave RF P2P systems use a high-frequency wireless communication technology that operates at frequencies above 24 GHz, which is known as millimeter-wave (mmWave) technology."

- TDoc S3-231976: "Massive MIMO is a wireless communication technology that uses multiple antennas at both the transmitter and receiver ends to increase the data capacity and range of the communication."

4. Different use cases:

- TDoc S3-231975: "The 5G mmWave RF P2P systems are used for direct communication between two devices, such as a mobile device and a base station."

- TDoc S3-231976: "The massive MIMO antenna system is used for multi-user MIMO (MU-MIMO) communication, which allows multiple users to access the wireless network simultaneously."

The following are technical differences among the TDocs:

1. TDoc S3-231962 proposes to resolve Editor’s Notes related to authentication and authorization performed by EEC/UE and ECS/EES. SA6 collaboration is necessary for restricting privileged services and UE-specific information. The normative work clarifies that ECS/EES can retrieve GPSI from the core network and should not trust GPSI received from EEC/UE.
- Example from TDoc: "If no EEC/UE side authentication and authorization performed and only Server side certificate-based TLS authentication is performed, then details on restricting the privileged services and/or UE specific information that to be provided from ECS/EES to the UE to be considerd in collobration with SA6 is FFS"

2. TDoc S3-231991 requests SA6 to align TS 23.558 with SA3 decision on one-sided authentication. SA3 concluded that mutual authentication between UE and ECS/EES will be performed according to authentication and authorization mechanism specified in TS 33.558. ECS/EES will not provide subscribe service and security credential to unauthenticated EEC/UE.
- Example from TDoc: "SA3 concluded to reuse the authentication and authorization mechanism specified in TS 33.558 for mutual authentication between UE and ECS/EES."

3. TDoc S3-231992 proposes that if no EEC/UE side authentication is performed and only server-side certificate-based TLS authentication is performed, privileged services, subscribe service, and UE-specific information will not be provided by ECS/EES to EEC/UE. Collaboration with SA6 is necessary to restrict privileged services and/or UE-specific information.
- Example from TDoc: "If no EEC/UE side authentication and authorization performed and only Server side certificate-based TLS authentication is performed, then details on restricting the privileged services and/or UE specific information that to be provided from ECS/EES to the UE to be considerd in collobration with SA6 is FFS"

4. TDoc S3-231993 proposes optimization by re-using TLS 1.3 and determining authentication method based on ECS/EES configuration information. If information on selected authentication method is present in ECS/EES configuration information, then EEC/UE can use this information in negotiation. Negotiation mechanism will re-use existing TLS 1.3 if no information on selected authentication method is present in ECS/EES configuration information.
- Example from TDoc: "Therefore, this pCR proposes an optimization along with re-using TLS 1.3, by UE/EEC determining the authentication method based on the ECS/EES configuration information if information on selected authentication method is present in the ECS/EES configuration information."