Content for  TS 33.501  Word version:  16.3.0

Top   Top   Up   Prev   Next
1…   4…   5…   6…   6.2…   6.3…   6.5…   6.8…   6.9…   6.10…   6.12…   6.14   6.15   6.16   7…   7A…   7B…   8…   9…   10…   11…   13…   13.3…   13.4…   14…   15…   A…   B…   C…   D…   G…   K…   O…


G  Application layer security on the N32 interface

G.1  Introduction

The SEPP as described in clause 4.X is the entity that sits at the perimeter of the network and performs application layer security on the HTTP message before it is sent externally over the roaming interface.
The application layer traffic comprises all the IEs in the HTTP message payload, sensitive information in HTTP message header and Request URI. Not all the IEs get the same security treatment in SEPP. Some IEs require e2e encryption, some only require e2e integrity protection, while other IEs may require e2e integrity protection but modifiable by intermediate IPX provider while in-transit.
[not reproduced yet]
Figure G.1-1: Signaling message from AMF (vPLMN) to AUSF (hPLMN) traversing the respective SEPPs
In the above figure, an example is shown where the AMF NF in the visiting PLM network (vPLMN) invokes an API request on the AUSF NF in the home PLM network (hPLMN) using the following message flow:
  • The AMF NF first sends the HTTP Request message to its local SEPP (i.e. vSEPP).
  • The vSEPP applies application layer security (PRINS) and sends the secure message on the N32 interface to AUSF NF of the hPLMN.
  • The hSEPP at the edge of the hPLMN, receives all incoming HTTP messages from its roaming partners. It verifies the message, removes the protection mechanism applied at the application layer, and forwards the resulting HTTP message to the corresponding AUSF NF.
To allow for the trusted intermediary IPX nodes to see and possibly modify specific IEs in the HTTP message, while completely protecting all sensitive information end to end between SEPPs, the SEPP implements application layer security in such a way that:
  • Sensitive information such as authentication vectors are fully e2e confidentiality protected between two SEPPs. This ensures that no node in the IPX network shall be able to view such information while in-transit.
  • IEs that are subject to modification by intermediary IPX nodes are integrity protected and can only be modified in a verifiable way by authorized IPX nodes.
  • Receiving SEPP can detect modification by unauthorized IPX nodes.

G.2  Structure of HTTP MessageWord‑p. 222
Following is a typical structure of the HTTP Message:
\fig:tinv-33-501-ny#Figure G.2-1 Typical structure of the HTTP message received by SEPP
It consists of:
  • HTTP Message payload with JSON based IEs
  • HTTP Headers with or without sensitive elements
  • HTTP Request-URI with or without sensitive elements such as SUPI.
In the outgoing direction, i.e. towards the N32 interface, the SEPP shall parse the HTTP message fully and apply protection on each part as required.
In the incoming direction, i.e. towards the Network Function, the SEPP shall verify the message, and if successful reassemble the original message and send it to the destined Network Function.


I (Normative)  Non-public networks |R16|Word‑p. 225

I.1  General

This Annex provides details on security for non-public networks. Most of the security procedures are the same as public networks so this annex only summarizes and specifies where there are exceptions to the normal procedures.
The feature for support of non-public networks (NPN) by 5GS is described in clause 5.30 of TS 23.501.
Editor's Note: Security aspects for other NPN issues including PNiNPN are ffs.

I.2  Authentication in standalone non-public networks

I.2.1  General

One of the major differences of non-public networks is that authentication methods other than AKA based ones may be used in a standalone non-public network (SNPN). When an AKA-based authentication method is used, clause 6.1 shall apply. When an authentication method other than 5G AKA or EAP-AKA' is used, only the non-AKA specific parts of clause 6.1 shall apply. An example of running such an authentication method is given in Annex B with EAP-TLS.
The choice of the supported authentication methods for access to SNPNs follows the principles described in clauses I.2.2 and I.2.3.

I.2.2  EAP framework, selection of authentication method, and EAP method credentials

The EAP authentication framework is supported by the 5GS as described in clause
The UE and the serving network may support 5G AKA, EAP-AKA', or any other key-generating EAP authentication method.
Selection of the authentication methods is dependent on NPN configuration.
When an EAP authentication method other than EAP-AKA' is selected, the chosen method determines the credentials needed in the UE and network. These credentials, called the EAP-method credentials, shall be used for authentication.

I.2.3  Key hierarchy, key derivation and key distribution

The text in clauses 6.2.1 and 6.2.2 cannot apply directly for an EAP authentication method other than EAP-AKA' as these clauses assume that an AKA-based authentication method is used. The major differences are the way in which K AUSF is calculated and that the UDM/ARPF is not necessarily involved in the key derivation or distribution.
Depending on the selected authentication method, the K AUSF is generated as follows:
  • For 5G AKA and EAP-AKA' refer to clause 6.2.1.
  • When using a key-generating EAP authentication method other than EAP-AKA', the key derivation of K AUSF is based on the EAP-method credentials in the UE and AUSF and shall be done as shown in Figure I.2.3-1.
[not reproduced yet]
Figure I.2.3-1: K AUSF derivation for key-generating EAP authentication methods other than EAP-AKA'
K AUSF shall be derived by the AUSF and UE from the EMSK created by the EAP authentication as for EAP-AKA'.
All of figures 6.2.1-1, and from the K AUSF downwards are used without modification. Similarly, text relating to the key hierarchy, key derivation and key distribution in clauses 6.2.1, and for keys derived from K AUSF (e.g. K SEAF, K AMF, K gNB etc) apply without modification.

I.3  Serving network name for standalone non-public networksWord‑p. 226

I.3.1  General

The identification of standalone non-public networks uses Network Identifier (NID) in addition to PLMN ID. This means the definition of SN Id in clause for the derivation of K SEAF for all authentication methods, CK' and IK' for EAP-AKA', and K AUSF and (X)RES* for 5G AKA needs modification for standalone non-public networks.

I.3.2  Definition of SN Id for standalone non-public networks

For standalone non-public networks, the SN Id (used in the input for various key/parameter derivations) identifies the serving SNPN.
It is defined as follows:
and is specified in detail in TS 24.501.

I.4  Modification of CAG ID list in the UE

The following requirements apply to NAS messages that modify the list of CAG IDs stored in the UE:
  • the AMF shall only send such a NAS message once NAS security has been established; and
  • the UE shall only modify its list of CAG IDs after successful integrity verification of the integrity protected NAS message requesting such a modification.

I.5  SUPI privacy for standalone non-public networksWord‑p. 227
The UE shall support SUPI privacy as defined in clause 6.12 with the following exception. When using an authentication method other than 5G AKA or EAP-AKA', the location of the functionality related to SUPI privacy in the UE is out of scope.
Furthermore, the privacy considerations for EAP TLS (given in Annex B.2.1.2) should be taken into account when using an authentication method other than 5G AKA or EAP-AKA'.

I.6  Authentication in Public Network Integrated Non-Public Networks (PNI-NPN)

For public network integrated NPN (PNI-NPN), the primary authentication shall be performed with the public network as described in clause 6.1. Secondary authentication as described in clause 11 and slice-specific authentication as described in the main body can take place after a successful primary authentication.

J (Normative)  SRVCC from 5G to UTRAN |R16|Word‑p. 228

J.1  SRVCC from NR to UTRAN

J.1.1  General

5G Single Radio Voice Call Continuity (SRVCC) is specified in TS 23.216, TS 23.501 and TS 23.502. This clause specifies the security aspect to support SRVCC from 5G to UTRAN. SRVCC from UTRAN to 5G shall not be allowed. After a 5G to UTRAN SRVCC session has terminated, a UE shall run a successfully (re)authentication in 5GS before allowed to access 5G.
During SRVCC from 5G to UTRAN CS, the MSC server should never know the K AMF nor should the K AMF be revealed to an entity other than an AMF.
The AMF derives new key(s) to create a mapped SRVCC security context for the MSC server instead of sending K AMF to the MSC server.

J.1.2  Procedure

As described in TS 23.216, there is no direct interface between the AMF in 5G and the MSC in UTRAN to support SRVCC, so the keys used to protect the SRVCC session once the UE is handed over to UTRAN are derived by MME based on security context mapping from 5G to E-UTRAN and then forwarded to the MSC during the HO procedure.
The procedure is initiated when the gNB wants to trigger a 5G SRVCC handover to UTRAN.
[not reproduced yet]
Figure J.1.2-1: Key derivation of 5G SRVCC from NR to UTRAN
Step 1.
The gNB sends Handover required message to the AMF.
Step 2.
The AMF shall derive a new K ASME_SRVCC key using the K AMF key and the current downlink 5G NAS COUNT of the current 5G security context as described in clause A.21. The AMF increases the downlink 5G NAS COUNT by one.
Step 3.
The AMF shall assign the value of ngKSI to the eKSI (maps ngKSI to eKSI) and shall transfer the new K ASME_SRVCC key and the UE security capability to the MME_SRVCC via Forward relocation request message.
Step 4.
The MME_SRVCC shall derive the CK SRVCC, IK SRVCC based on the new K ASME_SRVCC key as in clause A.12 in TS 33.401 using a downlink NAS COUNT of zero.
Step 5.
The MME_SRVCC assigns the value of eKSI to KSI SRVCC (maps eKSI to KSI SRVCC) and transfers CK SRVCC, IK SRVCC with KSI SRVCC and the UE security capability to the MSC server in PS to CS HO request message.
Step 6.
The MSC server sends the PS to CS HO response message to the MME_SRVCC.
Step 7.
The MME_SRVCC sends the Forward relocation response message to the AMF.
Step 8.
The AMF sends the HO command to the gNB, in which the AMF shall include the 4 LSBs of the downlink NAS COUNT used to calculate K ASME_SRVCC.
Step 9.
The gNB sends the HO command to the UE, in which the gNB shall include the 4 LSB of the downlink NAS COUNT received from the AMF.
Step 10.
When the UE receives the message, the UE shall derive the new K ASME_SRVCC key as described in Annex A.21 using the K AMF key and the downlink 5G NAS COUNT estimated from the 4 LSB received form the AMF. The UE shall further derive CK SRVCC, IK SRVCC based on the new K ASME_SRVCC key as described in the clause A.12 in TS 33.401 using a downlink NAS COUNT of zero. The UE shall identify the CK SRVCC and IK SRVCC from eKSI (= ngKSI) as the MME_SRVCC does.
If the SRVCC handover is not completed successfully, the new mapped CK SRVCC, IK SRVCC and KSI SRVCC cannot be used. In this case, the MSC server enhanced for SRVCC shall delete the newly mapped SRVCC security context for the UE, including CK SRVCC, IK SRVCC and KSI SRVCC.

J.2  Emergency call in SRVCC from NR to UTRANWord‑p. 229

J.2.1  General

IMS Emergency Sessions can be authenticated or unauthenticated depending on the serving network policy (or regulatory requirements) if unauthenticated IMS Emergency Sessions are allowed. Any behaviour not explicitly specified as being special to IMS Emergency Sessions is handled in accordance to normal procedures.

J.2.2  Procedure

When the SVRCC is for an emergency session, the security procedure in clause J.1.2 is applied.
However, in the case when the SRVCC is for an unauthenticated emergency session, since the derived keys have no ability to affect the output of the NULL algorithms, call set up needs to continue even though the network and the UE derive different keys.

Up   Top   ToC