TR 33.926 [9], clause A.2.2.1 Access to GSM.

GSM SIM access forbidden

TS 33.401[5], clause 6.1.1

"Access to E-UTRAN with a GSM SIM or a SIM application on a UICC shall not be granted." as specified in TS 33.401 [5], clause 6.1.1.

Verify that access to EPS with a GSM SIM is not possible.

Procedure and Execution Steps:

Test environment with HSS. HSS may be simulated.

1. The tester triggers the HSS to send an authentication data response with GSM authentication vector to the MME under test.

2. The tester checks whether the MME under test rejects the UE authentication.

MME rejects UE authentication when receiving GSM authentication vector from HSS.

NOTE: When both the MME and HSS function correctly, the GSM authentication vector is never included in the authentication data response from the HSS to the MME.

Evidence suitable for the interface, e.g., Screenshot, packet capture or application logs containing the operational results.

TR 33.926 [9], clause A.2.2.2 Resynchronization.

Inclusion of RAND, AUTS

TS 33.401[5], clause 6.1.2

"In the case of a synchronization failure, the MME shall also include RAND and AUTS." as specified in TS 33.401 [5], clause 6.1.2.

Verify that Re-synchronization procedure works correctly.

Procedure and Execution Steps:

Test environment with UE and HSS. UE and HSS may be simulated.

1. The tester triggers the UE to send an AUTHENTICATION FAILURE message with the EMM cause #21 "synch failure" and a re‑synchronization token AUTS to the MME under test.

2. The MME under test receives the AUTHENTICATION FAILURE message from the UE.

3. The tester checks the authentication data request sent to the HSS by the MME under test.

The MME includes the stored RAND and the received AUTS in the authentication data request to the HSS.

NOTE: When RAND and AUTS are not included in the authentication data request to the HSS then the HSS will return a new authentication vector (AV) based on its current value of the sequence number SQN~HE~ (cf. TS 33.102 [8], clause 6.3.5) A new authentication procedure between MME and UE using this new AV will be successful just the same if the cause of the synchronisation failure was the sending of a "stale" challenge, i.e. one that the UE had seen before or deemed to be too old. But if the cause of the synchronisation failure was a problem with the sequence number SQN~HE~ in the HSS (which should be very rare), and the RAND and AUTS are not included in the authentication data request to the HSS, then an update of SQN~HE~ based on AUTS will not occur in the HSS, and the new authentication procedure between MME and UE using the new AV will fail again. This can be considered a security-relevant failure case as it may lead to a subscriber being shut out from the system permanently.

Evidence suitable for the interface, e.g., Screenshot, packet capture or application logs containing the operational results.

TR 33.926 [9], clause A.2.2.3 Failed Integrity check of Attach message.

Integrity check of Attach message

TS 33.401[5], clause 6.1.4

"If the user cannot be identified or the integrity check fails, then the MME shall send a response indicating that the user identity cannot be retrieved." as specified in TS 33.401, clause 6.1.4.

Verify that secure user identification by means of integrity check of Attach request works correctly.

Procedure and Execution Steps:

Test environment with new and old MME. New MME may be simulated.

1. The tester triggers the new MME to send an Identification Request message with incorrect integrity protection to the old MME under test.

2. The old MME under test receives the Identification Request message from the new MME.

3. The tester checks the response message sent by the old MME under test.

The old MME sends a response indicating that the user identity cannot be retrieved.

Evidence suitable for the interface, e.g., Screenshot, packet capture or application logs containing the operational results.

TR 33.926 [9], clause A.2.2.4 Forwarding EPS authentication data to SGSN.

Not forwarding EPS authentication data to SGSN

TS 33.401[5], clause 6.1.4

"EPS authentication data shall not be forwarded from an MME towards an SGSN." as specified in TS 33.401[5], clause 6.1.4.

Verify that EPS authentication data remains in the EPC.

Procedure and Execution Steps:

Test environment with MME and SGSN. SGSN may be simulated.

1. The tester triggers the SGSN to send an Identification Request message to the MME under test.

2. The MME under test receives the Identification Request message from SGSN.

3. The tester checks the response message sent by the MME under test.

The response to the SGSN does not include EPS authentication data.

Evidence suitable for the interface, e.g., Screenshot, packet capture or application logs containing the operational results.

TR 33.926 [9], clause A.2.2.5 Forwarding unused EPS authentication data between different security domains.

Not forwarding unused EPS authentication between different security domains

TS 33.401[5], clause 6.1.5

"Unused EPS authentication vectors, or non-current EPS security contexts, shall not be distributed between MMEs belonging to different serving domains (PLMNs)." as specified in TS 33.401, clause 6.1.5.

Verify that unused EPS authentication data remains in the same serving domain.

Procedure and Execution Steps:

Test environment with old and new MME in different serving domains. New MME may be simulated.

1. The tester triggers the new MME to send an Identification Request message to the old MME under test.

2. The old MME under test receives the Identification Request message from the new MME.

3. The tester checks the response message sent by the old MME under test.

The response to the new MME does not include unused EPS authentication data.

Evidence suitable for the interface, e.g., Screenshot, packet capture or application logs containing the operational results.

TR 33.926 [9], A.2.3.1 Bidding Down.

Bidding down prevention

TS 33.401[5], clause 7.2

"The SECURITY MODE COMMAND shall include the replayed security capabilities of the UE." as specified in TS 33.401[5], clause 7.2.

Verify that bidding down by eliminating certain UE capabilities on the interface from UE to MME is not possible.

Procedure and Execution Steps:

Test environment with UE. UE may be simulated.

1. The tester triggers the UE to send an Attach request message includes security capabilities of the UE to the MME under test.

2. The MME under test receives the Attach request message from the UE and responses with a SECURITY MODE COMMAND message.

3. The tester checks the SECURITY MODE COMMAND message sent by the MME under test.

MME includes the same security capabilities of the UE in the SECURITY MODE COMMAND message.

Evidence suitable for the interface, e.g., Screenshot, packet capture or application logs containing the operational results.

TR 33.926 [9], A.2.3.2 NAS integrity selection and use

NAS integrity algorithm selection

TS 33.401[5], clause 7.2.4.3.1

"The MME shall protect the SECURITY MODE COMMAND message with the integrity algorithm, which has the highest priority according to the ordered lists." as specified in TS 33.401 [5], clause 7.2.4.3.1."

NOTE: The text in TS 33.401 [5], clause 7.2.4.3.1 is somewhat incomplete. It should properly read: "...which has the highest priority according to the ordered lists and is contained in the UE EPS security capabilities."

Verify that NAS integrity protection algorithm is selected and applied correctly.

Procedure and Execution Steps:

Test environment with UE. UE may be simulated.

1. The tester triggers the UE to send an Attach request message with Initial Attach type of the UE to the MME under test.

2. The tester filters the Security Mode Command and Security Mode Complete messages.

3. The tester checks the selected integrity algorithm in the SMC against the list of NAS integrity algorithm and the UE EPS security capabilities supported by the UE. The tester checks the MAC verification of the Security Mode Complete at the MME under test.

1. The MME has selected the integrity algorithm which has the highest priority according to the ordered lists and is contained in the UE EPS security capabilities. The MME checks the message authentication code on the SECURITY MODE COMPLETE message.

2. The MAC in the SECURITY MODE COMPLETE is verified, and the NAS integrity protection algorithm is selected and applied correctly.

Evidence suitable for the interface, e.g., Screenshot, packet capture or application logs containing the operational results.

TR 33.926 [9], A.2.3.3 NAS NULL integrity protection

NAS NULL integrity protection

TS 33.401[5], clause 5.1.4.1

"EIA0 shall only be used for unauthenticated emergency calls." as specified in TS 33.401[5], clause 5.1.4.1."

Verify that NAS NULL integrity protection algorithm is used correctly.

Procedure and Execution Steps:

Test environment with UE. UE may be simulated.

1. The tester triggers the UE to initiate a non-emergency attach procedure.

2. The MME under test selects integrity algorithm after successful UE authentication.

3. The MME under test sends the SECURITY MODE COMMAND message containing the selected integrity algorithm.

The tester checks the SECURITY MODE COMMAND message.

The selected integrity algorithm is different from EIA0.

Evidence suitable for the interface, e.g., Screenshot, packet capture or application logs containing the operational results.

TR 33.926 [9], A.2.3.4 NAS confidentiality protection

NAS confidentiality protection

TS 33.401[5], clause 7.2.4.3.1

"The UE...sends the NAS security mode complete message to MME ciphered and integrity protected." as specified in TS 33.401[5], clause 7.2.4.3.1.

Verify that NAS confidentiality protection algorithm is applied correctly.

Procedure and Execution Steps:

Test environment with UE. UE may be simulated.

1. The tester triggers the UE to send a SECURITY MODE COMPLETE message without confidentiality protection.

2. The MME under test receives the SECURITY MODE COMPLETE message from the UE.

3. The tester checks the selected confidentiality algorithm selected and checks whether the MME rejects the message.Expected Results:

If a confidentiality algorithm different from EEA0 was selected the MME rejects the message.

Evidence suitable for the interface, e.g., Screenshot, packet capture or application logs containing the operational results.

TR 33.926 [9], A.2.4.1 Bidding down on X2-Handover

Bidding down prevention in X2-handovers

TS 33.401[5], clause 7.2.4.2.2

"The MME shall verify that the UE EPS security capabilities received from the eNB are the same as the UE EPS security capabilities that the MME has stored." as specified in TS 33.401[5], clause 7.2.4.2.2."

Verify that bidding down is prevented in X2-handovers.

Procedure and Execution Steps:

Test environment with (target) eNB. eNB may be simulated.

The MME is configured to log the event of a UE EPS security capability mismatch.

1. The tester sends EPS security capabilities for the UE, different from the ones stored in the MME, to the MME under test using a Path-Switch message.

2. The tester captures the Path-Switch Acknowledge message sent by MME under test to the target eNB.

3. The tester checks the MME log regarding the capability mismatch.Expected Results:

The MME logs the event.

Evidence suitable for the interface, e.g., Screenshot, packet capture or application logs containing the operational results.

TR 33.926 [9], A.2.4.2 NAS integrity protection algorithm selection in MME change

NAS integrity protection algorithm selection in MME change

TS 33.401[5], clause 7.2.4.3.2

"In case there is change of MMEs and algorithms to be used for NAS, the target MME shall initiate a NAS security mode command procedure and include the chosen algorithms and the UE security capabilities (to detect modification of the UE security capabilities by an attacker) in the message to the UE (see clause 7.2.4.4). The MME shall select the NAS algorithms which have the highest priority according to the ordered lists (see clause 7.2.4.3.1)." as specified in TS 33.401[5], clause 7.2.4.3.2."

Verify that NAS integrity protection algorithm is selected correctly.

Procedure and Execution Steps:

Test environment with source and target MME. Source MME may be simulated.

1. The tester triggers the source MME to send the UE EPS security capabilities and the NAS algorithms used by the source MME to the target MME under test over the S10 interface.

2. The target MME under test selects the NAS algorithms which have the highest priority according to the ordered lists. The lists are assumed such that the algorithms selected by the target MME are different from the ones received from the source MME.

3. The tester checks whether the target MME implementselects the NAS integrity protection algorithm correctly.

The target MME initiates a NAS security mode command procedure and include the chosen algorithms and the UE security capabilities.

Evidence suitable for the interface, e.g., Screenshot, packet capture or application logs containing the operational results.

TR 33.926 [9], A.2.5.1 GSM SIM access via idle mode mobility

Idle mode mobility into E-UTRAN forbidden for GSM subscribers

TS 33.401[5], clause 9.1.2

"In case the MM context in the Context Response/SGSN Context Response indicates GSM security mode, the MME shall abort the procedure." as specified in TS 33.401, clause 9.1.2.

Verify that GSM subscribers cannot obtain service in EPS via idle mode mobility.

Procedure and Execution Steps:

Test environment with source SGSN and target MME. Source SGSN may be simulated.

1. The tester triggers the source SGSN to send the MM context in the Context Response indicating GSM security mode to the target MME under test.

2. The target MME under test receives the Context Response.

3. The tester checks the response message sent by the MME under test.

The MME aborts the procedure by acknowledging the Context Response from the SGSN with an appropriate failure cause.

Evidence suitable for the interface, e.g., Screenshot, packet capture or application logs containing the operational results.

TR 33.926 [9], A.2.5.2 GSM SIM access via handover

Handover into E-UTRAN forbidden for GSM subscribers

TS 33.401[5], clause 9.2.2

"In case the MM context in the Forward relocation request message indicates GSM security mode (i.e. it contains a Kc), the MME shall abort the non-emergency call procedure." as specified in TS 33.401, clause 9.2.2.

Verify that GSM subscribers cannot obtain service in EPS via handovers.

Procedure and Execution Steps:

Test environment with source SGSN and target MME. Source SGSN may be simulated.

1. The tester triggers the source SGSN to send the MM context in the Forward Location Request message indicating GSM security mode to the target MME under test.

2. The target MME under test receives the Forward Location Request message.

3. The tester checks the response message sent by the MME under test.

The MME aborts the procedure by responding to the Forward Relocation Request from the SGSN with an appropriate failure cause.

Evidence suitable for the interface, e.g., Screenshot, packet capture or application logs containing the operational results.

TR 33.926 [9], A.2.5.3 GSM SIM access via SRVCC

SRVCC into E-UTRAN forbidden for GSM subscribers

TS 33.401[5], clause 14.3.1

"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." as specified in TS 33.401, clause 14.3.1.

Verify that GSM subscribers cannot obtain service in EPS via SRVCC into E-UTRAN.

Procedure and Execution Steps:

Test environment with source MSC server and target MME. Source MSC server may be simulated.

1. The tester triggers the source MSC to send the GPRS Kc' and the CKSN'~PS~ in the CS to PS handover request to the target MME under test.

2. The target MME under test receives the CS to PS handover request.

3. The tester checks whether the MME under test rejects the request.

The MME rejects the request.

Evidence suitable for the interface, e.g., Screenshot, packet capture or application logs containing the operational results.

TR 33.926 [9], A.2.6 Threats related to release of non-emergency bearer

Emergency bearer establishment when authentication fails

TS 33.401 [5], clause 15.1.

"The MME or UE shall always release any established non-emergency bearers, when the authentication fails in the UE or in the MME." as specified in TS 33.401, clause 15.1.

Ensure that the MME enforces that only emergency bearers can be used without successful authentication.

Procedure and Execution Steps:

Test environment with MME and UE. UE may be simulated. The serving network policy allows unauthenticated IMS Emergency Sessions.

1. The tester triggers the UE to send the initial attach request for EPS emergency bearer services to the target MME under test.

2. The MME under test initiates an authentication, which fails.

3. The UE attached for EPS emergency bearer services sends the PDN Connectivity request for EPS non-emergency bearer services.

4. The tester checks whether the MME under test acts correctly.

The MME allows to continue the set up of the emergency bearer, and will reject the PDN Connectivity request for EPS non-emergency bearer services.

Evidence suitable for the interface, e.g., Screenshot, packet capture or application logs containing the operational results.