By Christine Jost, WI Rapporteur SA3, Ericsson

First published Nov 2023, in Highlights Issue 07  

The Non-Public Network (NPN) is one of the main new scenarios for 5G compared to earlier generations of mobile networks. NPNs are network deployments intended for usage of a private entity, such as an enterprise (see clause 6.25 of TS 22.261 [o]). 3GPP SA3 has included security features for Non-Public Networks from Rel-15 and extended them in Releases 16, 17 and 18.

The term "Non-Public Network" was introduced in Rel-16. In Rel-15, the terms "private network" and “isolated deployment” were used. The starting point for the security of NPNs is that the same level of security for 5G deployments in Public Land Mobile Networks (PLMN) of course also applies to Non-Public Networks.

The difference between NPN and PLMN from a security standardization point of view is only based on different use case requirements for security features, for example on the support of certificate-based authentication methods. But let's take it step-wise and see how the security features of NPN have evolved from Rel-15 to Rel-18.

Release 15

The most basic feature that many of the later additions rely on is the introduction of the EAP framework at the fundamentals of 5G authentication in Rel-15.

EAP stands for Extensible Authentication Protocol and is specified in the IETF RFC 3748 [x]. EAP itself is not an authentication method, but a framework that allows the usage of several authentication methods.

For 5G, the most illustrative examples are EAP-AKA' and EAP-TLS. EAP-AKA' [z] allows to run the 3GPP specified AKA (Authentication and Key Agreement) protocol, for authentication to 3GPP networks, over EAP. The predecessor of EAP-AKA’, namely EAP-AKA [z1], was introduced to 3GPP already in Rel-6 for non-3GPP access to 3G.

The other example is EAP-TLS [y][y'], which specifies the usage of TLS over EAP. With that, EAP-TLS allows the usage of TLS and certificate-based authentication, which is widely used on the internet and for enterprise use cases, over EAP.

In Rel-15, SA3 specified that EAP-AKA' is, besides 5G-AKA, one of the two mandatory authentication methods for accessing the 5G core network via any access type. This integrates the EAP framework firmly into 5G security, compared to EPS where EAP-AKA/EAP-AKA' support was used only for the non-3GPP access type. The authentication framework for 5G and the usage of EAP-AKA' for authentication to 5G networks is described in clause 6.1 of TS 33.501 [m].

In Rel-15, SA3 also described the usage of EAP-TLS, for private networks or IoT devices in isolated deployments of 5G, in the informative Annex B of TS 33.501 [m]. There is one interesting technical detail in this procedure, related to the derivation of the 5G key hierarchy from the keys agreed between UE and AUSF as a result of a successful run of EAP-TLS. In EAP-TLS, the authentication server derives both the MSK (Master Session Key) and the EMSK (Extended Master Session Key) from the TLS master secret. The MSK is exported from the EAP-server, while the EMSK is not shared outside the EAP-server. When EAP-TLS is used between UE and AUSF, the key hierarchy is based on the EMSK. This avoids that the master key from which the key hierarchy is derived leaves the AUSF. In consequence, this also prevents that another network using the same credentials infrastructure (e.g., in a factory or an enterprise) can impersonate the 5G Non-Public Network, since this network would only have access to the MSK.  

Release 16

While Rel-15 was the release for the basic 5G security features, Rel-16 was the release for the first line of feature extensions, and enhanced support for Non-Public Networks was one of them.

SA3 took a closer look at authentication for Standalone Non-Public Networks (SNPN) and clarified how the 5G key hierarchy extends to any key-generating EAP method, not only EAP-TLS. More specifically, the derivation of the key K_AUSF and the serving network name binding of the key hierarchy were clarified. Besides Standalone Non-Public Networks, Public Network Integrated Non-Public Networks (PNI-NPN) is an important use case. According to TS 23.501 [p], clause 5.30.3.1, "[p]ublic Network Integrated NPNs are NPNs made available via PLMNs e.g. by means of dedicated DNNs, or by one (or more) Network Slice instances allocated for the NPN."

Fortunately, the security specifications for PNI-NPN are straightforward, since the security of the PLMN in which the PNI-NPN integrates applies. The only thing that needed to be clarified was authentication for UE access to PNI-NPN, however secondary authentication and slice-specific authentication, both specified in other contexts, can be used for that. Another new use case for NPN in Rel-16 was the CAG (Closed Access Group). SA3 specified that CAG ID lists need to be sent protected. With respect to SUPI (Subscription Permanent Identifier) privacy, it extends to NPN with the only exception that the location of the functionality on the UE is out of scope. All of this is specified in subclauses of Annex I in TS 33.501 [m].

Release 17

Rel-17 brought another series of important features for the security of Non-Public Networks.

One of the main pieces of work was the authentication procedure between UE and network using an external Credentials Holder using a AAA (Authentication Authorisation Accounting) server. This authentication procedure is also based on the usage of EAP. However, since the AAA server is assumed to be legacy, there is an interesting difference to the key hierarchy compared to the case where the EAP authentication is run directly with the 5G core network. The legacy AAA server cannot derive the 5G specific key K_AUSF, and it will not export the EMSK to another entity which could derive it. Hence the key hierarchy needs to be based on the MSK instead of the EMSK for this case. This procedure is specified in Annex I.2.2.2.2 of TS 33.501 [m].

The procedure for authentication with a Credentials Holder using AAA includes another important technical detail, the introduction of the anonymous SUCI (Subscription Concealed Identifier). While AKA-based authentication methods to 5G use public-key based encryption of the SUPI to construct the SUCI, certificate-based authentication methods like EAP-TLS have the option that the client (UE) first sends an anonymous identifier before encryption has been established and later, after the establishment of an encrypted tunnel, sends the certificate with the identifier. To make this option available for 5G SNPNs, it was necessary to specify the anonymous SUCI (done by CT4 in TS 23.003 [n]) and the handling of the anonymous SUCI in the network (in Annex I.5 and Annex I.2.2.2.2 of TS 33.501 [m]).

Compared to the situation for a Credentials Holder using a AAA server, the authentication procedures for a Credentials Holder using an AUSF/UDM (i.e. PLMN or SNPN) were straightforward to specify, since the authentication procedure is the same as in the roaming scenario for PLMN.

In Rel-17, SA3 also specified authentication between UE and an Onboarding Network for the purpose of onboarding a UE to an SNPN, i.e., provisioning of the UE with SNPN credentials and other necessary information. The pre-requisite is that the UE is configured with Default UE credentials for authentication between UE and the Onboarding Network. Default UE credentials are "Information configured in the UE to make the UE uniquely identifiable and verifiably secure to perform UE onboarding" as specified in TS 23.501 [p]. Authentication using Default UE credentials is possible both with and without a Default Credentials Server (DCS). The procedures are specified in Annex I.9 of TS 33.501 [m].

Further, in Rel-17 SA3 explained how token-based authorization applies to Non-Public Networks and that roaming related security procedures extend to the Credentials Holder scenario, even though the UE is not considered to be roaming.

Last but not least, in Rel-17 SA3 also described the usage of another certificate-based authentication method, namely EAP-TTLS [a], in the informative Annex U of TS 33.501 [m].

Release 18

The main addition in Rel-18 was the security for access to SNPN service via non-3GPP access, captured in Annex I.10 of TS 33.501 [m]. Specifically, SA3 specified the security for untrusted non-3GPP access, trusted non-3GPP access, NSWO (Non-Seamless Wireless LAN Offload) and N5CW (Non-5G-Capable over WLAN) devices to SNPN. Fortunately, most of the security procedures for PLMN apply also in the SNPN case. However, the selection of authentication method and the option to use the anonymous SUCI required some adaptations. Especially for the different deployment models with and without Credentials Holder, using AAA or AUSF/UDM, some detailed description of the authentication applicable to these specific cases were necessary.

Furthermore, security for accessing a localized service was described in Annex I.11 of TS 33.501 [m].This could be done by simply referring to existing authentication procedures.

Summary

3GPP security specifications for 5G Non-Public Networks are based on the same level of security for 5G deployments of PLMNs, but extend security features to NPN specific use cases. The main addition is the adoption of the EAP-framework allowing the usage of additional authentication methods within the EAP-framework, and the description of different certificate-based authentication methods with and without external Credentials Holder for usage in Non-Public Networks.

[o] 3GPP TS 22.261 "Service requirements for the 5G system"

[m] 3GPP TS 33.501 "Security architecture and procedures for 5G System"

[n] 3GPP TS 23.003 "Numbering, addressing and identification"

[p] 3GPP TS 23.501 "System architecture for the 5G System (5GS)"

[x] "Extensible Authentication Protocol (EAP)" IETF RFC 3748

[z] "Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')" IETF RFC 9048

[z1] Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA) IETF RFC 4187

[y] "The EAP-TLS Authentication Protocol" IETF RFC 5216

[y'] "EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3" IETF RFC 9190

[a] "Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)" IETF RFC 5281