Content for TS 33.501 Word version: 19.4.0

1… 4… 5… 5.3… 5.9… 5.10… 6… 6.1.3… 6.1.4… 6.2… 6.2.2… 6.3… 6.4… 6.5… 6.6… 6.7… 6.8… 6.9… 6.10… 6.11 6.12… 6.13 6.14… 6.15… 6.16… 7… 7A… 7A.2.3… 7B… 8… 9… 10… 11… 12… 13… 13.2.2… 13.2.4… 13.3… 13.4… 14… 15… 16… 18… A… B… C… D… E… F… G… I… I.9… J… K… M… N… O… P… R S… T… U… V… W… X… Y… Z…

Z.1 General Z.2 Authentication of AUN3 devices by 5GC Z.3 Authentication of AUN3 devices by AAA server AA.1 General AA.2 Server authentication for MPQUIC in ATSSS AB.1 General AB.2 Architecture AB.3 Proxy entity at the border AB.4 Policy Check AB.5 Security for DNS messages crossing the border

Z (Normative) Authentication of AUN3 devices using additional EAP methods |R18| p. 339

Z.1 General p. 339

This Annex describes the authentication procedure for AUN3 devices behind 5G-RG in private networks or in isolated deployment scenarios (i.e., roaming is not supported) using any key generating EAP method.

An AUN3 device may be authenticated by the 5GC or a Credential Holder using a AAA server.

Z.2 Authentication of AUN3 devices by 5GC p. 339

Reproduction of 3GPP TS 33.501, Fig. Z.2-1: Authentication Procedure for AUN3 devices by 5GC using key-generating EAP method

Figure Z.2-1: Authentication Procedure for AUN3 devices by 5GC using key-generating EAP method

This authentication procedure is based on clause 7B.7.3 but differs in some steps.

Steps 1-6 are the same as steps 1-6 in clause 7B.7.3.

Step 7.

Upon reception of the Nudm_UEAuthentication_Get Request, the UDM shall invoke the SIDF to map the SUCI to the SUPI and select an authentication method based on the SUPI and the AUN3 device indicator. When the "username" part of the SUPI is "anonymous" or omitted, the UDM may select an authentication method based on the "realm" part of the SUPI, the AUN3 device indicator, a combination of the "realm" part and the AUN3 device indicator, or the UDM local policy. When EAP-AKA' authentication method is selected, the UDM/ARPF shall generate an authentication vector using the Access Network Identity as the KDF input parameter.

Step 8.

The UDM shall send to the AUSF a Nudm_UEAuthentication_Get Response message, including the SUPI and EAP-AKA' authentication vector if EAP-AKA' is selected or the selected authentication method if other key generating EAP method (e.g., EAP-TLS, EAP-TTLS, etc) is selected. According to the AUN3 subscription data, the UDM shall also send the MSK indicator to AUSF.

Step 9.

The AUN3 device and the AUSF perform the selected EAP authentication method.

Steps 10-15 are the same as steps 17-22 in clause 7B.7.3.

Z.3 Authentication of AUN3 devices by AAA server p. 340

Reproduction of 3GPP TS 33.501, Fig. Z.3-1: Authentication Procedure for AUN3 devices by AAA using key-generating EAP method

Figure Z.3-1: Authentication Procedure for AUN3 devices by AAA using key-generating EAP method

This authentication procedure is based on clause 7B.7 and I.2.2.2.2.

Steps 1-6 are the same as steps 1-6 in clause 7B.7.

Steps 7-16 are the same as steps 4-13 in clause I.2.2.2.2.

Steps 17-22 are the same as steps 17-22 in clause 7B.7.

AA (Normative) Security aspects of the Access Traffic Steering, Switching and Splitting (ATSSS) |R18| p. 341

AA.1 General p. 341

This Annex specifies the Security aspects of the Access Traffic Steering, Switching and Splitting (ATSSS). The ATSSS feature is described in TS 23.501.

AA.2 Server authentication for MPQUIC in ATSSS p. 341

When multipath QUIC (MPQUIC) [115], [116], [117] steering functionality is used for ATSSS, RFC 9001 mandates the use of TLS to secure QUIC.

AB Security for PLMN hosting a NPN through SBA interface |R19| p. 342

AB.1 General p. 342

This Annex specifies the security aspects of PLMN hosting an NPN with dedicated NFs deployed in the PNI_NPN operational domain. The Annex describes how to secure the boundary between PLMN operational domain and PNI_NPN operational domain when dedicated NFs interacting with PLMN operational domain through SBA interface and vice versa.

This Annex is based on the following assumptions:

Mutual trust between PLMN operational domain and the dedicated Network functions at the PNI_NPN operational domain is not in place.
Attacks may happen from PNI_NPN operational domain to PLMN operational domain and PLMN operational domain to PNI_NPN operational domain.

AB.2 Architecture p. 342

Reproduction of 3GPP TS 33.501, Fig. AB.2-1: Example of dedicated NFs deployed in the PNI-NPN operational domain

Figure AB.2-1: Example of dedicated NFs deployed in the PNI-NPN operational domain

As depicted in Figure AB.2-1, dedicated UPF and part of CP functions are deployed in the PNI-NPN operational domain. The interface between the dedicated NFs in the PNI-NPN operational domain and the NFs in the PLMN operational domain is SBA interface.

When the AMF is deployed in the PNI-NPN operational domain, there exists a privacy risk regarding SUPI exposure outside the PLMN operational domain. Appropriate measures to mitigate this risk may be considered when choosing this architecture for deployment.

AB.3 Proxy entity at the border p. 343

It is recommended to deploy one or more proxy entities at the border between PLMN and PNI-NPN operational domains. The security capabilities of these proxy entities are listed below.

Transport layer protection solution (as defined in clause 13.3) is supported for mutual authentication between the proxy entities and between each proxy entity and the NFs they serve.
SBA authorization framework (as defined in clause 13.4) is reused for authorization between NFs in the PLMN and PNI-NPN operational domains.
Topology hiding to IP level (e.g., IP address or FQDN) and application level (e.g., target NFs in the discovery response, Callback URI in the payload of the messages) is supported.
Message inspection and filtering, malformed message handling are supported.

Besides the security capabilities listed above, the part of the routing functionalities listed below also needs to be supported:

Indirect Communication (see clause 7.1.1 of TS 23.501 for details).
Delegated Discovery (see clauses 7.1.1 and 6.3.1 of TS 23.501 for details).
Message forwarding and routing to destination NF/NF service.
Message forwarding and routing to a next hop. (Required for bi-directional protection).

AB.4 Policy Check p. 343

To control the information exchange between the PNI-NPN operational domain and the PLMN operational domain, policy checks can be performed by the proxy entity at the border that segregates the trust domain between these operational domains.

Policy check can be defined based on available controls from the present specification considering architectural requirements. Examples of such policy checks are:

Having transport layer protection based on clause 13.1 of the present document.
Having authorization based on clause 13.4 of the present document.

The selection and definition of the policies from the examples above or from the present specification is left to the choice of implementation considering the architectural needs.

AB.5 Security for DNS messages crossing the border p. 343

DNS messages crossing the trust boundary can be protected. Security configuration and profiling of DNS servers is left to implementation. The dedicated NFs in the PNI-NPN operational domain are provisioned with the DNS security configuration, for example using one of the following methods:

Pre-configuring the DNS security configuration in the dedicated NF.
Updating the DNS security configuration in the dedicated NF during NF instantiation via the OAM.