TR 33.873
Study on the Security of the System Enablers
for devices having Multiple Universal Subscriber Identity Modules (MUSIM)
V17.1.0 (Wzip)
2021/09 11 p.
- Rapporteur:
- Mr. Kolekar, Abhijeet
Intel Corporation (UK) Ltd
Content for TR 33.873 Word version: 17.1.0
1 Scope
2 References
3 Definitions of terms, symbols and abbreviations
5 Key issues
6 Solutions
7 Conclusions
$ Change history
1 Scope p. 6
The present document contains the study of system enablers for devices having multiple Universal Subscriber Identity Modules (USIM) in the EPS and 5G system architecture are studied in TR 23.761. The present document provides the security and privacy issues related to MUSIM architecture and lists potential solutions for identified key issues including.
- Security and privacy issues exposing the Paging Cause in clear text in paging message.
- Security aspects of the communication between UE and Paging Server and exposing Paging server address.
- Security and Privacy implications if a Multi-USIM device needs to explicitly indicate to the MNO owning one USIM and that UE is also registered via another USIM at the same or different PLMNs.
- Security aspects of Paging Response with cause value busy indication.
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.
3 Definitions of terms, symbols and abbreviations p. 6
3.1 Terms p. 6
For the purposes of the present document, the terms 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.
3.2 Symbols p. 6
Void
3.3 Abbreviations p. 7
4 Void
5 Key issues p. 7
5.1 Key issue #1: Security Aspects of Busy Indication p. 7
5.1.1 Key issue details p. 7
In TR 23.761, a Multi-USIM device with concurrent registrations over 3GPP RAT associated with multiple USIMs procedures is discussed. A multi-USIM device can efficiently perform some activity (e.g. listen to paging) in a system while communicating in another system. The network sends a paging request to notify the UE of a pending MT service. UE may monitor periodically for paging from another system. UE responds to the page (either by accepting the page request or by sending a busy indication), which allows the network to save paging resources due to not escalating the page across a larger area.
It was concluded in TR 23.761 that if a Multi-USIM device in RRC_Idle mode decides not to accept a received paging, a BUSY Indication is sent by the UE via a NAS message to network whenever the UE supports NAS BUSY indication.
5.1.2 Threats p. 7
If the Busy indication is injected, modified or replayed by attackers, the network may be spoofed to believe the UE appears busy, which will mislead the network to stop paging the UE for the incoming MT service and causing Dos attack on the UE.
If the Busy indication sent by the UE in a NAS message is removed by an attacker before reaching the AMF, the network may be spoofed to believe that the UE accepted the paging without indicating busy (e.g. a normal Service Request responding to paging), which will mislead the network to process the request from the UE with the existing procedure to prepare for the UE to be transferred from Idle to Connected mode. This will waste the network resource and alter the real intention of the MUSIM device, which is a type of DoS attack on both the network and the UE.
5.1.3 Potential security requirements p. 7
3GPP system shall support a mechanism to protect BUSY indication against modification, replay, and fabrication attacks.
5.2 Key issue #2: UE and Paging Server Communication p. 8
5.2.1 Key issue details p. 8
As per TR 23.761, A Multi-USIM device is needed to monitor each connected system's paging channel for MT services destined to that device. UE's paging notification and reception need to be done with minimal interruption to ongoing services in the current system and without performing undesirable operations (e.g. Wasting resource, reaching misleading assumption of reachability). MUSIM devices which are unable to simultaneously monitor paging on all 3GPP RATs and systems in which it is in Idle state or RRC_Inactive state (for 5GS) needs to choose the paging channel(s) to monitor, which can lead to unsuccessful paging on the other paging channel(s). There are two solutions, to prevent unnecessary interruption of the current service to receive paging (Solution #7, Solution #12, Solution #27), proposed in the TR 23.761. While connected to a MUSIM system, all these solutions deliver paging notifications of 3GPP RATs and systems in which UE is in Idle or inactive state through a currently active network. Solutions to this key issue should study security and privacy aspects related to communication between UE and paging server.
5.2.2 Threats p. 8
There is no need to analyse security threats for this key issue.
5.2.3 Potential security requirements p. 8
There is not potential security requirements for this key issue.
5.3 Key issue #3: Security aspects of exposing 'paging cause'. p. 8
5.3.1 Key issue details p. 8
In TR 23.761, the MUSIM device considers sending a paging cause part of the [Uu] paging message. The [Uu] paging message contains the identity of UE plus a Paging Cause, i.e., indicating the type of traffic that triggered the paging, e.g., MT Voice. 3G already used to have this paging cause as paging traffic type (Conversational, Streaming, Interactive, Background). In EPS, the paging traffic type was removed. MUSIM system applies to EPS and 5GS. Based on the paging cause, UE makes educated decisions on whether to respond to the other system's paging. The interim conclusion in TR 23.761 is to have only one 'paging cause' value for the voice service. However, UE needs to discriminate the case where the absence of Paging Cause in the Uu Paging message is due to a non-voice MT service from the case where the absence of Paging Cause in the Uu Paging message is due to a legacy RAN node (i.e., regardless whether the MT service is voice or not).
5.3.2 Threats p. 8
No security threats adressed in the present document.
5.3.3 Potential security requirements p. 8
No Security requirements adressed in the present document.
6 Solutions p. 9
6.1 Solution #1: Security Solution for Busy Indication using NAS signaling p. 9
6.1.1 Introduction p. 9
This solution addresses key issue #1: Security Aspects of Reject Paging Indication.
The key issue proposes to support a mechanism to prevent DoS attack caused by Reject Paging Indication. Solution reduces the severity of the DoS attacks and identify the DoS attacks by handling the response to paging for MT service. Solution described proposes a solution allowing the UE to send a Reject Paging Indication to the network in a NAS message as a response to a page.
6.1.2 Solution details p. 9
The procedure below assumes that UE-1 can periodically pause the RRC-connection allowing UE-2 to perform page monitoring.
Step 0.
A device with USIM, i.e., UE1, is in connected mode and UE2 is in IDLE mode.
Step 1.
The AMF-2 serving the UE-2 sends a paging request message to RAN-2. RAN-2 pages UE-2.
Step 2.
Upon receiving the paging message UE-2, if UE supporting NAS Reject Paging Indication decides to send a NAS Reject Paging Indication, responds with a Reject Paging Indication vis NAS message after RACH procedure. RAN-2 forwards the NAS message to the AMF-2. 1.
- The NAS message carrying the Reject Paging Indication may be ciphered. The cipher mechanism as defined in clause 6.4.4 of TS 33.501 can be reused to protect the in the NAS message.
- The NAS message carrying the Reject Paging Indication is integrity protected. The integrity protection mechanism as defined in clause 6.4.3 of TS 33.501 can be reused to integrity protect the in the NAS message.
6.1.3 System impact p. 10
UE:
- Uses existing NAS integrity and ciphering mechanism as per TS 33.501.
- Uses existing NAS integrity and ciphering mechanism as per TS 33.501.
6.1.4 Evaluation p. 10
Above solution relies on already defined mechanisms in TS 33.501 to send ciphered and integrity protected BUSY indication and fulfils security requirements of Key issue 1.
7 Conclusions p. 10
7.1 Key issue #1: Security Aspects of Busy Indication p. 10
Solution 1 is recommended for normative work to support encryption and integrity protection of Reject paging indication (Busy Indication) via NAS signaling. Solution 1 relies on already defined mechanisms in TS 33.501 to send ciphered, and integrity protected Reject paging indication (busy indication) and fulfils security requirements of Key issue 1. No normative work will be pursued.
7.2 Key issue #2: UE and Paging Server Communication p. 10
No solution is needed for security aspect of UE and paging server communication.
7.3 Key issue #3: Security aspects of exposing 'paging cause' p. 10
No solution is adressed in the present document.
$ Change history p. 11
