Content for TS 33.401 Word version: 17.3.0

1… 4 5… 6… 6.2… 7… 7.2.5… 7.2.8 7.2.9… 7.3… 8… 9… 10… 11… 15… A… B… C… C.1.6 C.2… C.2.7 C.2.8 C.3… C.4.7 D… E… E.2… E.3… F… G… H… I… K…

14.1 From E-UTRAN to Circuit Switched UTRAN/GERAN 14.2 Emergency call in SRVCC from E-UTRAN to circuit switched UTRAN/GERAN 14.3 SRVCC from circuit switched UTRAN/GERAN to E-UTRAN
...

11 Network Domain Control Plane protection p. 72

The protection of IP based control plane signalling for EPS and E-UTRAN shall be done according to NDS/IP as specified in TS 33.210. S3, S6a and S10 interfaces carry subscriber specific sensitive data, e.g. cryptographic keys. Thus in addition to the mandatory integrity protection according to NDS/IP, traffic on these interfaces shall be confidentiality-protected according to NDS/IP.

In order to protect the S1 and X2 control plane as required by clause 5.3.4a, it is required to implement IPsec ESP according to RFC 4303 as specified by TS 33.210. For both S1-MME and X2-C, IKEv2 certificates based authentication according to TS 33.310 shall be implemented. For S1-MME and X2-C, tunnel mode IPsec is mandatory to implement on the eNB. On the core network side a SEG may be used to terminate the IPsec tunnel.

Transport mode IPsec is optional for implementation on the X2-C and S1-MME.

If the sender of IPsec traffic uses DiffServ Code Points (DSCPs) to distinguish different QoS classes, either by copying DSCP from the inner IP header or directly setting the encapsulating IP header's DSCP, the resulting traffic may be reordered to the point where the receiving node's anti-replay check discards the packet. If different DSCPs are used on the encapsulating IP header, then to avoid packet discard under one IKE SA and with the same set of traffic selectors, distinct Child-SAs should be established for each of the traffic classes (using the DSCPs as classifiers) as is specified in RFC 4301.

Other 3GPP specifications may specify other IKEv2 and certificate profiles and IPsec implementation details for specific types of eNBs. The provisions in such other 3GPP specifications shall take precedence over the provisions in the present clause for those specific eNB types only if explicitly listed here. In particular, the provisions for HeNBs specified in TS 33.320 shall take precedence over the provisions in this clause.

12 Backhaul link user plane protection p. 72

The protection of user plane data between the eNB and the UE by user specific security associations is covered by clause 5.1.3 and 5.1.4.

In order to protect the S1 and X2 user plane as required by clause 5.3.4, it is required to implement IPsec ESP according to RFC 4303 as profiled by TS 33.210, with confidentiality, integrity and replay protection.

On the X2-U and S1-U, transport mode IPsec is optional for implementation.

Tunnel mode IPsec is mandatory to implement on the eNB for X2-U and S1-U. On the core network side a SEG may be used to terminate the IPsec tunnel..

For both S1 and X2 user plane, IKEv2 with certificates based authentication shall be implemented. The certificates shall be implemented according to the profile described by TS 33.310. IKEv2 shall be implemented conforming to the IKEv2 profile described in TS 33.310. Other 3GPP specifications may specify other IKEv2 and certificate profiles and IPsec implementation details for specific types of eNBs. The provisions in such other 3GPP specifications shall take precedence over the provisions in the present clause for those specific eNB types only if explicitly listed here. In particular, the provisions for HeNBs specified in TS 33.320 shall take precedence over the provisions in this clause.

13 Management plane protection over the S1 interface p. 73

For the management plane protection of relay nodes the provisions in clause D.2.5 apply instead of the provisions given in this clause.

For management plane protection the requirements in clause 5.3.2 apply.

In order to achieve such protection, IPsec ESP according to RFC 4303 as profiled by TS 33.210 shall be implemented for all O&M related traffic, i.e. the management plane, with confidentiality, integrity and replay protection.

Tunnel mode IPsec shall be implemented on the eNB for supporting the management plane. On the core network side a SEG may be used to terminate the IPsec tunnel. If no SEG is used, the IPsec tunnel may be terminated in the element manager.

If the sender of IPsec traffic uses DiffServ Code Points (DSCPs) to distinguish different QoS classes, either by copying DSCP from the inner IP header or directly setting the encapsulating IP header's DSCP, the resulting traffic may be reordered to the point where the receiving node's anti-replay check discards the packet. If different DSCPs are used on the encapsulating header, then to avoid packet discard under one IKE SA and with the same set of traffic selectors, distinct Child-SAs should be established for each of the traffic classes (using the DSCPs as classifiers) as is specified in RFC 4301.

For the management plane, IKEv2 with certificates based authentication shall be implemented on the eNB. The certificates shall be implemented according to the profile described by TS 33.310. IKEv2 shall be implemented conforming to the IKEv2 profile described in TS 33.310. Other 3GPP specifications may specify other IKEv2 and certificate profiles and IPsec implementation details for specific types of eNBs.

Other 3GPP specifications may specify other security mechanisms and certificate profiles for specific types of eNBs for the case when the management traffic is not carried over the same backhaul link as S1 traffic. If other security mechanisms are specified, they shall provide mutual authentication based on certificates, as well as confidentiality, integrity and replay protection. These functions shall have at least equal strength as that provided by the use of IKEv2/IPsec.

The provisions in such other 3GPP specifications shall take precedence over the provisions in the present clause for those specific eNB types only if explicitly listed here. In particular, the provisions for HeNBs specified in TS 33.320 shall take precedence over the provisions in this clause.

14 SRVCC between E-UTRAN and Circuit Switched UTRAN/GERAN p. 73

14.1 From E-UTRAN to Circuit Switched UTRAN/GERAN p. 73

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

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.

The MME and the UE shall derive a confidentiality key CKSRVCC, and an integrity key IKSRVCC from KASME 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 CKSRVCC and the 128 least significant bits are identified with IKSRVCC.

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.

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 CKSRVCC, IKSRVCC 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 CKSRVCC, IKSRVCC, 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 CKSRVCC, IKSRVCC, KSI in both ME and USIM. STARTCS shall comply with the rules in TS 25.331.

The ME shall use CKSRVCC and IKSRVCC to derive the GSM CS Kc using the c3 function specified in TS 33.102. The ME shall assign the eKSI value (associated with CKSRVCC and IKSRVCC) 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.

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 CKSRVCC and IKSRVCC with the help of the key conversion function c3 as specified in TS 33.102, 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 Kc128 as specified in TS 33.102 when the new encryption algorithm selected by the target BSS requires Kc128. The UE and the enhanced MSC Server shall assign the value of eKSI to GSM CS CKSN associated with the GSM CS Kc128.

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 CKSRVCC, IKSRVCC and KSISRVCC can not be used in the future. The MSC server enhanced for SRVCC shall delete the new mapped CKSRVCC, IKSRVCC and KSISRVCC and the stored parameters CKCS and IKCS which has the same KSI as the new mapped CKSRVCC, IKSRVCC (if such exist).

14.2 Emergency call in SRVCC from E-UTRAN to circuit switched UTRAN/GERAN |R9| p. 75

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 |R11| p. 75

14.3.1 Procedure p. 75

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:

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.
Activation of AS security in the UE (for details cf. TS 36.331):
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.
Activation of NAS security (for details cf. TS 24.301):
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.
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.

Copy of original 3GPP image for 3GPP TS 33.401, Fig. 14.3.1-1: SRVCC handover from UTRAN/GERAN to E-UTRAN. Key derivations in the Figure are only shown for UMTS subscribers.

Figure 14.3.1-1: SRVCC handover from UTRAN/GERAN to E-UTRAN. Key derivations in the Figure are only shown for UMTS subscribers.
(⇒ copy of original 3GPP image)

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.

Step 1.

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

Step 2.

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

For UMTS subscribers, the source MSC server enhanced for SRVCC shall derive CK'PS and IK'PS from the NONCEMSC and the latest CKCS and IKCS using the key derivation function as specified in Annex B.6 of TS 33.102. The source MSC server enhanced for SRVCC shall further set the KSI'PS equal to the KSICS associated with the latest key set as specified for SRVCC from UTRAN/GERAN to HSPA in TS 33.102.

For GSM subscribers, the source MSC server enhanced for SRVCC shall derive GPRS Kc' from the NONCEMSC and the latest GSM Kc using the key derivation function as specified in Annex B.7 of TS 33.102 . The source MSC server enhanced for SRVCC shall further set the CKSN'PS equal to the CKSNCS associated with the latest key set as specified for SRVCC from UTRAN/GERAN to HSPA in TS 33.102.

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.

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.

Step 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 KSISGSN. The value of the KSISGSN shall be the same as the value of the KSI'PS received in the CS to PS handover request.

The MME shall derive KeNB by applying the KDF as defined in Annex A.3 using the mapped key K'ASME and 232-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.

Step 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'ASME using the algorithm types and algorithm IDs as input to the NAS key derivation functions (see Annex A.7). MME generates NONCEMME. MME shall include KSISGSN, NONCEMMEand the selected NAS security algorithms in the NAS Security Transparent Container IE of Allocate resources message to the target eNB. MME shall further include KeNB and the UE EPS security capabilities from the mapped EPS security contextin the Allocate resources message to the target eNB.

Step 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 KeNB using the key derivation function defined in clause A.7.

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

Step 8.

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

Step 9.

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

Step 10.

For UMTS subscribers the ME shall silently discard the NONCEMME received in received in the NAS Security Transparent Container. The ME shall further derive K'ASME, associate it with KSISGSN received in the NAS Security Transparent Container IE and derive NAS keys and KeNB 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)

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 STARTPS and STARTCS values used in UTRAN shall be kept in the volatile memory of the ME, cf. also clause 6.8.11 of TS 33.102.