TS 33.116
Security Assurance Specification (SCAS)
for the MME Network Product Class
V18.0.0 (PDF)
2024/03 … p.
V17.0.0
2022/03 20 p.
V16.1.0
2021/12 20 p.
V15.1.0
2021/12 20 p.
V14.2.0
2021/12 20 p.
- Rapporteur:
- Dr. Zugenmaier, Alf
NTT DOCOMO INC.
Content for TS 33.116 Word version: 17.0.0
1 Scope
2 References
3 Definitions and abbreviations
4 MME-specific security requirements and related test cases
4.1 Introduction
4.2 MME-specific adaptations of security functional requirements and related test cases
4.3 MME-specific adaptations of hardening requirements and related test cases
4.4 MME-specific adaptations of basic vulnerability testing requirements and related test cases
$ Change History
1 Scope p. 6
The present document contains objectives, requirements and test cases that are specific to the MME network product class. It refers to the Catalogue of General Security Assurance Requirements and formulates specific adaptions of the requirements and test cases given there, as well as specifying requirements and test cases unique to the MME network product class.
2 References p. 6
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
- References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
- For a specific reference, subsequent revisions do not apply.
- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]
TR 21.905: "Vocabulary for 3GPP Specifications".
[2]
[3]
TR 33.117: "Catalogue of General Security Assurance Requirements".
[4]
TR 33.916: "Security assurance scheme for 3GPP network products for 3GPP network product classes".
[5]
TS 33.401: "3GPP System Architecture Evolution (SAE); Security architecture".
[6] Void.
[7]
TS 23.401: "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access".
[8]
TS 33.102: "3G security; Security architecture".
3 Definitions and abbreviations p. 6
3.1 Definitions p. 6
For the purposes of the present document, the terms and definitions given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.
MME Application: The running processes (typically more than one) executing the software package for the MME functions and OAM functions of the MME network product model.
3.2 Abbreviations p. 7
4 MME-specific security requirements and related test cases p. 7
4.1 Introduction p. 7
The structure of the present TS 33.116 is aligned with TS 33.117 such that the MME-specific adaptation of a generic requirement in 33.sas, clause 4.a.b.c.d, can be always found in TS 33.116, clause 4.a.b.c.d. The text on pre-requisites for testing in clause 4.1.2 of TS 33.117 applies also to the present document.
4.2 MME-specific adaptations of security functional requirements and related test cases p. 7
4.2.1 Introduction p. 7
4.2.2 Security functional requirements on the MME deriving from 3GPP specifications and related test cases p. 7
4.2.2.1 Security functional requirements on the MME deriving from 3GPP specifications - general approach p. 7
In addition to the requirements and test cases in TS 33.117, clause 4.2.2, an MME shall satisfy the following:
It is assumed for the purpose of the present SCAS that an MME conforms to all mandatory security-related provisions pertaining to an MME in:
- 3GPP TS 33.401: "EPS security architecture";
- other 3GPP specifications that make reference to TS 33.401 or are referred to from TS 33.401 (e.g. TS 23.401).
- AKA authentication is embedded in an Attach procedure or a TAU procedure.
- Security Mode Control is embedded in an Attach procedure or a TAU procedure.
- The derivation of a mapped security context is embedded in inter-RAT mobility procedures.
4.2.2.2 Authentication and key agreement procedure p. 7
4.2.2.2.1 Access with 2G SIM forbidden p. 7
Requirement Name:
2G SIM access forbidden
Requirement Reference:
TBA
Requirement Description:
"Access to E-UTRAN with a 2G SIM or a SIM application on a UICC shall not be granted." as specified in TS 33.401, clause 6.1.1.
Threat References:
TBA
Security Objective References:
TBA
Test Case:
Purpose:
Verify that access to EPS with a 2G SIM is not possible.
Pre-Conditions:
Test environment with HSS. HSS may be simulated.
Execution Steps
Include 2G authentication vector in authentication data response from HSS.
Expected Results:
MME rejects UE authentication when receiving 2G authentication vector from HSS.
4.2.2.2.2 Re-synchronization p. 8
Requirement Name:
Inclusion of RAND, AUTS
Requirement Reference:
TBA
Requirement Description:
"In the case of a synchronization failure, the MME shall also include RAND and AUTS." as specified in TS 33.401, clause 6.1.2.
Threat References:
TBA
Security Objective References:
TBA
Test Case:
Purpose:
Verify that Re-synchronization procedure works correctly.
Pre-Conditions:
Test environment with UE and HSS. UE and HSS may be simulated.
Execution Steps
The MME receives an AUTHENTICATION FAILURE message, with the EMM cause #21 "synch failure" and a re synchronization token AUTS.
Expected Results:
The MME includes the stored RAND and the received AUTS in the authentication data request to the HSS.
4.2.2.2.3 Integrity check of Attach message p. 9
Requirement Name:
Integrity check of Attach message
Requirement Reference:
TBA
Requirement Description:
"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.
Threat References:
TBA
Security Objective References:
TBA
Test Case:
Purpose:
Verify that secure user identification by means of integrity check of Attach request works correctly.
Pre-Conditions:
Test environment with new and old MME. New MME may be simulated.
Execution Steps
The old MME receives an Identification Request message from the new MME with incorrect integrity protection.
Expected Results:
The old MME sends a response indicating that the user identity cannot be retrieved.
4.2.2.2.4 Not forwarding EPS authentication data to SGSN p. 9
Requirement Name:
Not forwarding EPS authentication data to SGSN
Requirement Reference:
TBA
Requirement Description:
"EPS authentication data shall not be forwarded from an MME towards an SGSN." as specified in TS 33.401, clause 6.1.4.
Threat References:
TBA
Security Objective References:
TBA
Test Case:
Purpose:
Verify that EPS authentication data remains in the EPC.
Pre-Conditions:
Test environment with MME and SGSN. SGSN may be simulated.
Execution Steps
The MME receives an Identification Request message from the SGSN.
Expected Results:
The response to the SGSN does not include EPS authentication data.
4.2.2.2.5 Not forwarding unused EPS authentication data between different security domains p. 10
Requirement Name:
Not forwarding unused EPS authentication between different security domains
Requirement Reference:
TBA
Requirement Description:
"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.
Threat References:
TBA
Security Objective References:
TBA
Test Case:
Purpose:
Verify that unused EPS authentication data remains in the same serving domain.
Pre-Conditions:
Test environment with old and new MME in different serving domains. New MME may be simulated.
Execution Steps
The old MME receives an Identification Request message from the new MME.
Expected Results:
The response to the new MME does not include unused EPS authentication data.
4.2.2.3 Security mode command procedure p. 10
4.2.2.3.1 Bidding down prevention p. 10
Requirement Name:
Bidding down prevention
Requirement Reference:
TBA
Requirement Description:
"The SECURITY MODE COMMAND shall include the replayed security capabilities of the UE." as specified in TS 33.401, clause 7.2.
Threat References:
TBA
Security Objective References:
TBA
Test Case:
Purpose:
Verify that bidding down by eliminating certain UE capabilities on the interface from UE to MME is not possible.
Pre-Conditions:
Test environment with UE. UE may be simulated.
Execution Steps
Attach request message includes security capabilities of the UE.
Expected Results:
MME includes the same security capabilities of the UE in the SECURITY MODE COMMAND message.
4.2.2.3.2 NAS integrity algorithm selection and use p. 11
Requirement Name:
NAS integrity algorithm selection
Requirement Reference:
TBA
Requirement Description:
"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, clause 7.2.4.3.1.
Threat References:
TBA
Security Objective References:
TBA
Test Case:
Purpose:
Verify that NAS integrity protection algorithm is selected and applied correctly.
Pre-Conditions:
Test environment with UE. UE may be simulated.
Execution Steps
The MME sends the SECURITY MODE COMMAND message. The UE replies with the SECURITY MODE COMPLETE message.
Expected Results:
- 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.
- The MAC in the SECURITY MODE COMPLETE is verified, and the NAS integrity protection algorithm is selected and applied correctly.
4.2.2.3.3 NAS NULL integrity protection p. 11
Requirement Name:
NAS NULL integrity protection
Requirement Reference:
TBA
Requirement Description:
"EIA0 shall only be used for unauthenticated emergency calls." as specified in TS 33.401, clause 5.1.4.1.
Threat References:
TBA
Security Objective References:
TBA
Test Case:
Purpose:
Verify that NAS NULL integrity protection algorithm is used correctly.
Pre-Conditions:
Test environment with UE. UE may be simulated.
Execution Steps
The MME sends the SECURITY MODE COMMAND message after successful UE authentication.
Expected Results:
The selected integrity algorithm is different from EIA0.
4.2.2.3.4 NAS confidentiality protection p. 12
Requirement Name:
NAS confidentiality protection
Requirement Reference:
TBA
Requirement Description:
"The UE…sends the NAS security mode complete message to MME ciphered and integrity protected." as specified in TS 33.401, clause 7.2.4.3.1.
Threat References:
TBA
Security Objective References:
TBA
Test Case:
Purpose:
Verify that NAS confidentiality protection algorithm is applied correctly.
Pre-Conditions:
Test environment with UE. UE may be simulated.
Execution Steps
The MME receives the SECURITY MODE COMPLETE message without confidentiality protection.
Expected Results:
If a confidentiality algorithm different from EEA0 was selected the MME rejects the message.
4.2.2.4 Security in intra-RAT mobility p. 12
4.2.2.4.1 Bidding down prevention in X2-handovers p. 12
Requirement Name:
Bidding down prevention in X2-handovers
Requirement Reference:
TBA
Requirement Description:
"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, clause 7.2.4.2.2.
Threat References:
TBA
Security Objective References:
TBA
Test Case:
Purpose:
Verify that bidding down is prevented in X2-handovers.
Pre-Conditions:
Test environment with (target) eNB. eNB may be simulated.
The MME is configured to log the event of a UE EPS security capability mismatch.
Execution Steps
The MME receives the path-switch message with the UE EPS security capabilities different from the ones stored in the MME for that UE.
Expected Results:
The MME logs the event.
4.2.2.4.2 NAS integrity protection algorithm selection in MME change p. 13
Requirement Name:
NAS integrity protection algorithm selection in MME change
Requirement Reference:
TBA
Requirement Description:
"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, clause 7.2.4.3.2.
Threat References:
TBA
Security Objective References:
TBA
Test Case:
Purpose:
Verify that NAS integrity protection algorithm is selected correctly.
Pre-Conditions:
Test environment with source and target MME. Source MME may be simulated.
Execution Steps
The target MME receives the UE EPS security capabilities and the NAS algorithms used by the source MME from the source MME over the S10 interface. The target MME 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.
Expected Results:
The target MME initiates a NAS security mode command procedure and include the chosen algorithms and the UE security capabilities.
4.2.2.5 Security in inter-RAT mobility p. 13
4.2.2.5.1 No access with 2G SIM via idle mode mobility p. 13
Requirement Name:
Idle mode mobility into E-UTRAN forbidden for GSM subscribers
Requirement Reference:
TBA
Requirement Description:
"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.
Threat References:
TBA
Security Objective References:
TBA
Test Case:
Purpose:
Verify that 2G subscribers cannot obtain service in EPS via idle mode mobility.
Pre-Conditions:
Test environment with source SGSN and target MME. Source SGSN may be simulated.
Execution Steps:
The target MME receives the MM context in the Context Response indicating GSM security mode.
Expected Results:
The MME aborts the procedure by acknowledging the Context Response from the SGSN with an appropriate failure cause.
4.2.2.5.2 No access with 2G SIM via handover p. 14
Requirement Name:
Handover into E-UTRAN forbidden for GSM subscribers
Requirement Reference:
TBA
Requirement Description:
"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.
Threat References:
TBA
Security Objective References:
TBA
Test Case:
Purpose:
Verify that GSM subscribers cannot obtain service in EPS via handovers.
Pre-Conditions:
Test environment with source SGSN and target MME. Source SGSN may be simulated.
Execution Steps:
The target MME receives the MM context in the Forward Location Request message indicating GSM security mode.
Expected Results:
The MME aborts the procedure by responding to the Forward Relocation Request from the SGSN with an appropriate failure cause.
4.2.2.5.3 No access with 2G SIM via SRVCC p. 14
Requirement Name:
SRVCC into E-UTRAN forbidden for GSM subscribers
Requirement Reference:
TBA
Requirement Description:
"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.
Threat References:
TBA
Security Objective References:
TBA
Test Case:
Purpose:
Verify that GSM subscribers cannot obtain service in EPS via SRVCC into E-UTRAN.
Pre-Conditions:
Test environment with source MSC server and target MME. Source MSC server may be simulated.
Execution Steps
The target MME receives the GPRS Kc' and the CKSN'PS in the CS to PS handover request.
Expected Results:
The MME rejects the request.
4.2.2.6 Security Aspects of IMS Emergency Session Handling p. 15
4.2.2.6.1 Authentication failure for emergency bearers p. 15
Requirement Name:
Emergency bearer establishment when authentication fails
Requirement Reference:
Requirement Description:
"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.
Threat References:
TBA
Security Objective References:
TBA
Test Case:
Purpose:
Ensure that the MME enforces that only emergency bearers can be used without successful authentication.
Pre-Conditions:
Test environment with MME and UE. UE may be simulated. The serving network policy allows unauthenticated IMS Emergency Sessions.
Execution Steps
The UE sends the initial attach request for EPS emergency bearer services, then the MME initiates an authentication, which fails. The UE attached for EPS emergency bearer services sends the PDN Connectivity request for EPS non-emergency bearer services.
Expected Results:
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.
4.2.3 Technical Baseline p. 15
4.2.3.1 Introduction p. 15
This clause provides baseline technical requirements.
4.2.3.2 Protecting data and information p. 15
4.2.3.2.1 Protecting data and information - general p. 15
There are no MME-specific additions to clause 4.2.3.2.1 of TS 33.117.
4.2.3.2.2 Protecting data and information - unauthorized viewing p. 16
There are no MME-specific additions to clause 4.2.3.2.2 of TS 33.117.
4.2.3.2.3 Protecting data and information in storage p. 16
There are no MME-specific additions to clause 4.2.3.2.3 of TS 33.117.
4.2.3.2.4 Protecting data and information in transfer p. 16
There are no MME-specific additions to clause 4.2.3.2.4 of TS 33.117:
4.2.3.2.5 Logging access to personal data p. 16
There are no MME-specific additions to clause 4.2.3.2.5 of TS 33.117.
4.2.3.3 Protecting availability and integrity p. 16
There are no MME-specific additions to clause 4.2.3.3 of TS 33.117.
4.2.3.4 Authentication and authorization p. 16
There are no MME-specific additions to clause 4.2.3.4.
4.2.3.5 Protecting sessions p. 16
There are no MME-specific additions to clause 4.2.3.5 of TS 33.117.
4.2.3.6 Logging p. 16
All text from TS 33.117, clause 4.2.3.6 also applies to MMEs. There are no MME-specific adaptations or additions to this text.
4.2.4 Operating Systems p. 16
There are no MME-specific additions to clause 4.2.4 of TS 33.117.
4.2.5 Web Servers p. 16
There are no MME-specific additions to clause 4.2.5 of TS 33.117.
4.2.6 Network Devices p. 16
All text from TS 33.117, clause 4.2.6 also applies to MMEs. There are no MME-specific adaptations or additions to this text.
4.3 MME-specific adaptations of hardening requirements and related test cases p. 16
4.3.1 Introduction p. 16
4.3.2 Technical Baseline p. 16
All text from TS 33.117, clause 4.3.2 also applies to MMEs. There are no MME-specific adaptations or additions to this text.
4.3.3 Operating Systems p. 17
There are no MME-specific additions to clause 4.3.3 of TS 33.117.
4.3.4 Web Servers p. 17
There are no MME-specific additions to clause 4.3.4 of TS 33.117.
4.3.5 Network Devices p. 17
There are no MME-specific additions to clause 4.3.5 of TS 33.117.
4.4 MME-specific adaptations of basic vulnerability testing requirements and related test cases p. 17
All text from TS 33.117, clause 4.4 also applies to MMEs. There are no MME-specific adaptations or additions to this text.
$ Change History p. 18
