J.1 SRVCC from NR to UTRAN

33.5013GPPRelease 18Security architecture and procedures for 5G SystemTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

J.1.1 General

5G Single Radio Voice Call Continuity (SRVCC) is specified in 3GPP TS 23.216 [72], TS 23.501 [2] and TS 23.502 [8]. 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[72], 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.

Figure J.1.2-1: Key derivation of 5G SRVCC from NR to UTRAN

1. The gNB sends Handover required message to the AMF.

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.

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.

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 [10] using a downlink NAS COUNT of zero.

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.

6. The MSC server sends the PS to CS HO response message to the MME_SRVCC.

7. The MME_SRVCC sends the Forward relocation response message to the AMF.

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}.

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.

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 [10] 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.