14 SRVCC between E-UTRAN and Circuit Switched UTRAN/GERAN

33.4013GPP3GPP System Architecture Evolution (SAE)Release 17Security architectureTS

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

14.1 From E-UTRAN to Circuit Switched UTRAN/GERAN

Single Radio Voice Call Continuity (SRVCC) is specified in TS 23.216 [22].

The MME shall select the current NAS downlink COUNT value to use in the handover and then increase the stored NAS downlink COUNT value by 1.

NOTE 0: Increasing the NAS downlink COUNT by 1 is to ensure that a fresh NAS downlink COUNT is used for any future purposes.

The MME and the UE shall derive a confidentiality key CK_SRVCC, and an integrity key IK_SRVCC from K_ASME of the current EPS security context and the selected NAS downlink COUNT with the help of a one-way key derivation function KDF as specified in clause A.12.

The KDF returns a 256-bit output, where the 128 most significant bits are identified with CK_SRVCC and the 128 least significant bits are identified with IK_SRVCC.

The MME shall also provide the 4 LSB of the selected NAS downlink COUNT value to the source eNB, which then includes the bits to the HO Command to the UE. The UE shall use the received 4 LSB and its stored NAS downlink COUNT to estimate the NAS downlink COUNT selected by the MME.

NOTE 1: It is left to the implementation how to estimate the NAS downlink COUNT.

The UE shall ensure that the estimated NAS downlink COUNT has not been used to calculate a CK’ and IK’ in a previous successful or unsuccessful PS or SRVCC handover. If the estimated NAS downlink COUNT is greater than all the estimated NAS downlink COUNTs either used by the UE for key derivation in a handover or received in a NAS message that passed its integrity check, the UE shall update its stored NAS downlink COUNT as though it has successfully integrity checked a NAS message with that estimated NAS downlink COUNT. In particular, the stored NAS downlink COUNT shall never be decreased.

UE and MME shall assign the value of eKSI to KSI. MME shall transfer CK_SRVCC, IK_SRVCC with KSI and the UE security capability to the MSC server enhanced for SRVCC. The MSC server enhanced for SRVCC shall replace all the stored UTRAN CS key parameters CK, IK, KSI, if any, with CK_SRVCC, IK_SRVCC, KSI received from the MME when the SRVCC handover is successful. The UE shall replace all the stored UTRAN CS key parameters CK, IK, KSI, if any, with CK_SRVCC, IK_SRVCC, KSI in both ME and USIM. START_CS shall comply with the rules in TS 25.331 [24].

The ME shall use CK_SRVCC and IK_SRVCC to derive the GSM CS Kc using the c3 function specified in TS 33.102 [4]. The ME shall assign the eKSI value (associated with CK_SRVCC and IK_SRVCC) to the GSM CS CKSN (associated with the GSM CS Kc). The ME shall update the USIM and ME with the GSM CS Kc and GSM CS CKSN.

NOTE 2: The new derived security context (including CK_SRVCC, IK_SRVCC, and KSI) replacing the stored values in the USIM is for allowing to reuse the derived security context without invoking the authentication procedure in subsequent connection set-ups, and also for avoiding that one KSI value indicates to two different key sets and consequently leads to security context desynchronization.

NOTE 3: An operator concerned about the security of keys received from an E-UTRAN of another operator may want to enforce a policy in the MSC server enhanced for SRVCC to run a UMTS AKA as soon as possible after the handover. One example of ensuring this is the deletion of the mapped UMTS security context in the enhanced MSC server after the UE has left active state.

NOTE 4: Due to replacing all the UTRAN CS key parameters CK, IK, KSI with CK_SRVCC, IK_SRVCC and KSI on USIM and in ME, a new GSM CS Kc needs to be derived from the new UTRAN CS key parameters CK and IK (i.e. CK_SRVCC and IK_SRVCC), which is part of the new UMTS security context as well, as any old GSM CS Kc stored on USIM and in ME, belongs to an old UMTS security context and can no longer be taken into use.

If the SRVCC is from E-UTRAN to GERAN, the above description in this clause applies as well for the MME, the enhanced MSC server and the UE. The enhanced MSC server shall in addition derive GSM CS cipher key Kc from CK_SRVCC and IK_SRVCC with the help of the key conversion function c3 as specified in TS 33.102 [4], and assign the value of eKSI to GSM CS CKSN associated with the GSM CS Kc, and the target MSC server and UE shall compute the 128-bit GSM CS cipher key Kc₁₂₈ as specified in TS 33.102 [4] when the new encryption algorithm selected by the target BSS requires Kc₁₂₈. The UE and the enhanced MSC Server shall assign the value of eKSI to GSM CS CKSN associated with the GSM CS Kc₁₂₈.

Non-voice bearers may be handed over during the SRVCC handover operation. For this case, k ey derivation for non-voice bearers is specified in clause 9.2.1 and 10.3.1 of the present specification. If non-voice bearers are not handed over during the SRVCC handover operation and if the UE subsequently resumes PS services in UTRAN/GERAN, key derivation for the PS domain is specified in clause 9.1.1 and 10.2.1 of the present specification.

If the SRVCC handover is not completed successfully, the new mapped CK_SRVCC, IK_SRVCC and KSI_SRVCCcan not be used in the future. The MSC server enhanced for SRVCC shall delete the new mapped CK_SRVCC, IK_SRVCC and KSI_SRVCCand the stored parameters CK_CS and IK_CS which has the same KSI as the new mapped CK_SRVCC, IK_SRVCC (if such exist).

14.2 Emergency call in SRVCC from E-UTRAN to circuit switched UTRAN/GERAN

If the SRVCC is for an emergency call and the session in EUTRAN complies with clause 15.2.1, the security procedure in clause 14.1 shall be applied.

If the SRVCC is for an emergency call and the session in EUTRAN complies with clause 15.2.2, the security procedure in clause 14.1 shall not be applied, i.e., no key derivation is needed.

14.3 SRVCC from circuit switched UTRAN/GERAN to E-UTRAN

14.3.1 Procedure

The procedure for SRVCC handover from UTRAN/GERAN CS to E-UTRAN, as far as relevant for security, proceeds as described below.

The activation of NAS and AS security in E-UTRAN, and selection of the key set from the source system for the handover shall be according to following principles:

i) The source MSC server enhanced for SRVCC shall select the key set most recently generated. This key set may have been generated by either a successful UMTS AKA run in UTRAN or from a UMTS security context mapped from an EPS security context during a previous visit to UTRAN. The UE and source MSC server enhanced for SRVCC may or may not have taken the key set into use. The MSC server enhanced for SRVCC shall transfer this key set to the MME in the CS to PS HO request.

ii) Activation of AS security in the UE (for details cf. TS 36.331 [21]):

The CS to PS HO command received at the UE shall activate AS security in the UE.

The CS to PS HO Confirmation received at the eNB shall activate AS security in the eNB.

iii) Activation of NAS security (for details cf. TS 24.301 [9]):

The CS to PS HO request received at the UE shall activate NAS security in the UE.

The Handover Notify received at the MME shall activate NAS security in the MME. In case the MME does not have the UE security capabilities stored from a previous visit, then the MME shall only accept TAU requests from this UE, and shall not send any messages to this UE, until the MME has successfully checked the UE security capabilities received in a TAU request from this UE.

iv) Both AS and NAS ciphering and integrity protection algorithms shall be selected according to the policy of the target PLMN.

The above four principles consequentially always activate ciphering (potentially NULL ciphering) in E-UTRAN even if it was not active in the source system.

Figure 14.3.1-1: SRVCC handover from UTRAN/GERAN to E-UTRAN. Key derivations in the figure are only shown for UMTS subscribers.

Handover signalling in case of successful handover

Before attempting a handover for a UE, the source RNC/BSC may check if the UE is authenticated using UMTS AKA as described in clause 9.2.2.1 of the present document, and may avoid doing a SRVCC handover to E-UTRAN in case the UE is not authenticated using UMTS AKA and does not have an ongoing emergency call.

NOTE 1: The numbering in the followingrefers to the signalling numbering in Figure 14.3.1-1.

1. The source BSC/RNC sends HO required to the source MSC server enhanced for SRVCC.

2. For UMTS and GSM subscribers, the source MSC server enhanced for SRVCC shall generate a NONCE_MSC.

For UMTS subscribers, the source MSC server enhanced for SRVCC shall derive CK’_PS and IK’_PS from the NONCE_MSC and the latest CK_CS and IK_CS using the key derivation function as specified in annex B.6 of TS 33.102 [2]. The source MSC server enhanced for SRVCC shall further set the KSI’_PS equal to the KSI_CS associated with the latest key set as specified for SRVCC from UTRAN/GERAN to HSPA in TS 33.102 [2].

For GSM subscribers, the source MSC server enhanced for SRVCC shall derive GPRS Kc’ from the NONCE_MSC and the latest GSM Kc using the key derivation function as specified in annex B.7 of TS 33.102 [2] . The source MSC server enhanced for SRVCC shall further set the CKSN’_PS equal to the CKSN_CS associated with the latest key set as specified for SRVCC from UTRAN/GERAN to HSPA in TS 33.102 [2].

For UMTS subscribers, the MSC server enhanced for SRVCC shall transfer the CK’_PS/IK’_PS and the KSI’_PS, to the target MME in the CS to PS handover request.

For GSM subscribers, the MSC server enhanced for SRVCC shall transfer the GPRS Kc’ and the CKSN’_PS, to the target MME in the CS to PS handover request.

NOTE 2: The MSC server enhanced for SRVCC does not include any authentication vectors in the CS to PS HO request, since this could result in that authentication vectors intended for use only in the CS domain would end up being used in a PS domain by accident.

NOTE 3: The MSC server enhanced for SRVCC does not include any UE security capability information in the CS to PS HO request, since the target MME either has this information available, or will retrieve the information from the old SGSN. Further, the MSC may not have access to the complete UE security capabilities.

If the MME receives a GPRS Kc’ from the source MSC server enhanced for SRVCC in the CS to PS HO request, the MME shall reject the request.

3 and 4. The MME shall discard any CK, IK, Kc, CKSN and KSI retrieved from the old SGSN in a context request procedure

The MME shall create a mapped EPS security context by setting the K’_ASME of the mapped EPS security context equal to the concatenation CK’_PS|| IK’_PS,where the CK’_PS and IK’_PS were received in the CS to PS handover request. The MME shall further associate the K’_ASME with a KSI_SGSN. The value of the KSI_SGSN shall be the same as the value of the KSI’_PS received in the CS to PS handover request.

NOTE 4: The naming of the KSI_SGSN hints at that this identifier is somehow related to an SGSN. However, in this case it is related to the MSC server enhanced for SRVCC. Even though KSI_MSC could have been a more appropriate name here, the name KSI_SGSN is kept to avoid introducing a new name for the same entity.

The MME shall derive K_eNB by applying the KDF as defined in Annex A. 3 using the mapped key K’_ASME and 2³²-1 as the value of the uplink NAS COUNT parameter. The uplink and downlink NAS COUNT values for the mapped EPS security context shall be set to start value (i.e. 0) in the MME.

If the MME does not have access to the UE EPS security capabilities the MME shall assume that the default set of EPS security algorithms defined in clause 9.2.2.1 of the present document is supported by the UE (and the MME shall set the UE EPS security capabilities in the mapped EPS security context according to this default set). The same considerations regarding security algorithm selection using the default set as noted in clause 9.2.2.1 of the present document applies here. If the security context information received from the old SGSN contains EPS security capabilities or the MME already have access to EPS security capabilities for the UE, the MME shall populate the mapped EPS security context with these EPS security capabilities instead of falling back to the default set of security algorithms.

If the MME received any authentication vectors from the old SGSN, the MME shall process these authentication vectors according to clause 6.1.6 of the present document.

5. MME shall select the NAS security algorithms (including ciphering and integrity protection) which have the highest priority from its configured list and are also present in the UE EPS security capabilities. MME shall derive the NAS keys from K’_ASMEusing the algorithm types and algorithm IDs as inputto the NAS key derivation functions (see Annex A.7). MME generates NONCE_MME. MME shall include KSI_SGSN, NONCE_MMEand the selected NAS security algorithms in the NAS Security Transparent Container IE of Allocate resources message to the target eNB. MME shall further include K_eNB and the UE EPS security capabilities from the mapped EPS security contextin the Allocate resources message to the target eNB.

6. The target eNB shall select the AS algorithms (including ciphering for both RRC and UP, and integrity protection for RRC) which have the highest priority from its configured list and is also present in the UE EPS security capabilities. The target eNB creates a target to source transparent container that contains a handover command (the target to source transparent container is denoted "E-UTRAN RRC container" in Figure 14.3.1-1). The handover command incluesd the selected RRC, UP algorithms and the NAS Security Transparent Container IE, and the eNB sends the target to source transparent container in the Allocate resources Ack message towards the MME. The eNB shall derive the keys for RRC and UP protection from the received K_eNB using the key derivation function defined in clause A.7.

NOTE 5: The handover command in the target to source transparent container is not security protected by the target eNB.

7. MME shall include the target to source transparent container received from the target eNB in the CS to PS HO Response message sent to source MSC server enhanced for SRVCC.

8. Source MSC server enhanced for SRVCC shall include the NONCE_MSC and the target to source transparent container in the relocation command sent to the BSC/RNC in the CS to PS HO command.

9. The RNC/BSC shall include the NONCE_MSC and the transparent container in the CS to PS HO command sent to the UE.

NOTE 6: The CS to PS HO command is integrity protected and optionally ciphered in UTRAN. It is optionally ciphered in GERAN as specified by TS 33.102 [4].

10. For UMTS subscribers the ME shall silently discard the NONCE_MME received in received in the NAS Security Transparent Container. The ME shall further derive K’_ASME, associate it with KSI_SGSN recived in the NAS Security Transparent Container IE and derive NAS keys and K_eNB following the same key derivations as the MSC and MME performed in steps 2, 3 and 4. The ME shall also derive the RRC and UP keys as the eNB did in (see description for message 6 above). The UE sends a CS to PS HO Confirmation message to the target eNB. The ME shall set the uplink and downlink NAS COUNT values for the mapped EPS security context to start value (i.e. 0)

NOTE 7: Since the MME denies access to E-UTRAN for GSM subscribers, the UE never has to perform any key derivations for GSM subscribers..

The mapped EPS security context established as above shall become the current (cf. clause 3.1) EPS security context at AS and NAS level. The MME and ME shalloverwrite any existing current mapped EPS security context with the newly created one. If the current EPS security context is of type native, then it shall become the non-current native EPS security context. The MME and ME shall in this case also overwrite any existing non-current EPS security context with this current native EPS security context. The CS to PS HO Confirmation messages and all following AS messages in E-UTRAN shall be ciphered and integrity protected according to the policy of the target PLMN.

If the SRVCC handover is not completed successfully, the new mapped EPS security context cannot be used in the future. The MME and the ME shall in this case delete the new mapped EPS security context.

The text regarding subsequent NAS signalling in bullet B) in clause 9.2.2.1 of the present specification applies also after an SRVCC handover from GERAN/UTRAN to E-UTRAN.

In SRVCC handover from GERAN/UTRAN to E-UTRAN, the START_PS and START_CS values used in UTRAN shall be kept in the volatile memory of the ME, cf. also clause 6.8.11 of TS 33.102 [4].