Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x
Top   in Index   Prev   Next

TS 33.187
Security aspects of Machine-Type Communications (MTC)
and other Mobile Data Applications Communications enhancements

V18.0.0 (PDF)  2024/03  16 p.
V17.0.0  2022/03  16 p.
V16.0.0  2020/06  16 p.
V15.1.0  2018/06  16 p.
V14.1.0  2017/12  15 p.
V13.0.1  2016/12  15 p.
V12.2.0  2015/03  13 p.
Rapporteur:
Mr. Rajadurai, Rajavelsamy
Samsung R&D Institute UK

Content for  TS 33.187  Word version:  18.0.0

Here   Top

 

1  Scopep. 5

The present document specifies the security architecture enhancements (i.e., enhancements to the security features and the security mechanisms) to facilitate Machine-Type and other mobile data applications Communications enhancements (MTCe) as per the use cases and service requirements defined in TS 22.368 and the architecture enhancements and procedures defined in TS 23.682.

2  Referencesp. 5

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]
TS 22.368: "Service Requirements for Machine-Type Communications (MTC)".
[3]
TS 23.682: "Architecture Enhancements to facilitate communications with Packet Data Networks and Applications".
[4]
TS 29.368: "Tsp interface protocol between the MTC Interworking Function (MTC-IWF) and Service Capability Server (SCS)".
[5]
TS 23.040: "Technical realization of the Short Message Service (SMS)".
[6]
TS 23.142: "Value-added Services for SMS (VAS4SMS); Interface and signalling flow".
[7]
TS 33.220: "Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture (GBA)".
[8]
TS 33.223: "Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture (GBA) Push function".
[9]
TS 23.204: "Support of Short Message Service (SMS) over generic 3GPP Internet Protocol (IP) access; Stage 2".
[10]
TS 31.115: "Remote APDU Structure for (U)SIM Toolkit applications".
[11]
TS 31.116: "Remote APDU Structure for (Universal) Subscriber Identity Module (U)SIM Toolkit applications".
[12]
ETSI TS 102 225: "Smart Cards; Secured packet structure for UICC based applications".
[13]
ETSI TS 102 226: "Smart cards; Remote APDU structure for UICC based applications".
[14]
TS 31.111: "Universal Subscriber Identity Module (USIM) Application Toolkit (USAT)".
[15]
TS 33.210: "3G security; Network Domain Security (NDS); IP network layer security ".
[16]
TS 33.246: "MBMS Security".
[17]
TS 33.310: "3G security; Network Domain Security (NDS); Authentication Framework (AF) ".
[18]
RFC 6749:  "The OAuth 2.0 Authorization Framework ".
[19]
TS 33.122: "Security Aspects of Common API Framework for 3GPP Northbound APIs".
Up

3  Definitions and abbreviationsp. 6

3.1  Definitionsp. 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.

3.2Void

3.3  Abbreviationsp. 6

For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply.
An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.
MTC
Machine-Type Communications
MTC-IWF
MTC Interworking Function
SCEF
Service Capability Exposure Function

4  Security Requirementsp. 6

4.1  Requirements on SCEF - 3GPP Network Entity reference pointp. 6

The SCEF is controlled by the 3GPP operator or a business partner e.g. by another operator than the 3GPP operator controlling the Network Entity or by a 3rd party, the SCEF - 3GPP Network Entity reference point shall fulfil the following requirements:
  • integrity protection, replay protection, confidentiality protection and privacy protection for communication between the SCEF and 3GPP Network Entity shall be supported;
    • mutual authentication between 3GPP Network Entity and SCEF shall be supported;
    • integrity protection and replay protection shall be used;
    • confidentiality protection should be used;
    • privacy of the 3GPP user shall be provided (e.g. IMSI/IMPI shall not be sent outside the 3GPP operator's domain);
  • the 3GPP Network Entity shall be able to determine whether the SCEF is authorized to send requests to the 3GPP Network Entity;
  • the 3GPP Network Entity may be able to determine whether authorization shall be per UE, or optionally per service per UE.
The same security requirements apply also when applications operating in the trust domain access network entities (e.g. PCRF), wherever the required 3GPP interface(s) are made available, directly without going through the SCEF.
Up

4.2  Requirements on Service Capability Exposure Function (SCEF)p. 7

The functionality of the Service Capability Exposure Function (SCEF) includes the following:
  • support ability to satisfy security requirements on SCEF - 3GPP Network Entity reference point in clause 4. 1;
  • it shall be able to determine whether the Application is authorized to send requests for the 3GPP Network Entity, where authorization shall be per UE or optionally per service per UE.
Up

4.3  Requirements on SCEF - Interworking SCEF reference pointp. 7

The requirements for the SCEF - Interworking SCEF reference point include the following:
  • the same integrity protection, replay protection, confidentiality protection and privacy protection requirements from clause 4.1 apply for the interface T7 between the SCEF and IWK-SCEF.
  • the IWK-SCEF shall be able to determine whether the SCEF in the HPLMN is authorized to send requests for the 3GPP Network Entity.

4.4  Requirements on MTC |R13|p. 7

The security requirements for MTC include the following:
  • MTC optimizations shall not degrade security compared to non-MTC communications TS 22.368

4.5  Requirements on Tsp reference point |R13|p. 7

The Tsp reference point shall fulfil the following requirements:
  • integrity protection, replay protection, confidentiality protection and privacy protection for communication between the MTC-IWF and SCS shall be supported:
    • mutual authentication between two directly communicating entities in the security domains, in which MTC-IWF and SCS respectively reside, shall be supported;
    • the use of mutual authentication shall follow the provisions in TS 29.368;
    • integrity protection and replay protection shall be used;
    • confidentiality protection should be used;
    • privacy shall be provided (e.g. IMSI shall not be sent outside the 3GPP operator domain).
Up

4.6  Requirements on MTC-IWF |R13|p. 7

The functionality of the MTC-IWF includes the following:
  • support ability to satisfy security requirements on Tsp reference point in clause 4.5.

4.7  Requirements on T8 reference point |R15|p. 8

The T8 reference point shall fulfil the following requirements:
  • integrity protection, replay protection, confidentiality protection and privacy protection for communication between the SCEF and SCS/AS shall be supported:
    • mutual authentication between two directly communicating entities in the security domains, in which SCEF and SCS respectively reside, shall be supported;
    • the use of mutual authentication shall follow the provisions in clause 5.5;
    • integrity protection and replay protection shall be used;
    • confidentiality protection should be used;
    • privacy shall be provided;
    • IMSI shall not be sent outside the 3GPP operator domain.
  • the SCEF shall be able to determine whether the SCS/AS is authorized to send requests to the 3GPP Network Entity;
  • the SCEF may be able to determine whether authorization shall be per UE, or optionally per service per UE.
Up

5  General security proceduresp. 8

5.1  Security procedures for Tsp interface securityp. 8

The security procedures for the Tsp interface are specified in TS 29.368.

5.2  Security procedures for reference point SCEF - 3GPP Network Entity |R13|p. 8

5.2.0  Introductionp. 8

This clause specifies how the reference point SCEF - 3GPP Network Entity shall be secured. There are two different scenarios to consider:
  • when the SCEF is considered as a 3GPP network function; or
  • when the SCEF is not considered as a 3GPP network function.

5.2.1  SCEF is considered as a 3GPP network functionp. 8

If the SCEF and the 3GPP Network Entity are both considered as 3GPP network functions then this interface shall be protected using NDS/IP as defined in TS 33.210.
If the peers reside in different security domains, functional entity Security GW shall be used to authenticate and authorize the individual instance of SCEF and to secure the interface between the 3GPP Network Entity and the individual instance of SCEF as defined in TS 33.310.
If the operator does not use the mechanisms described in this clause, then other adequate security measures shall be taken to ensure security on that interface. It is up to the operator, i.e. the owner of the 3GPP Network Entity, to decide whether the reference point SCEF - 3GPP Network Entity is trusted or physically protected, or whether it needs protection by a cryptographic protocol as specified above.
Up

5.2.2  SCEF is not considered as a 3GPP network functionp. 9

The security procedure as defined for the Tsp interface in TS 29.368 shall be implemented/supported, where the 3GPP Network Entity takes the role as the MTC-IWF and the SCEF takes the role as the SCS, unless the security procedures for the relevant reference point SCEF - 3GPP Network Entity has been defined explicitly in some other specification (e.g. security procedures for MB2-C reference point are defined in TS 33.246).
Up

5.3  Security procedures for reference point Application - 3GPP Network Entity |R13|p. 9

The security procedure as defined for the Tsp interface in TS 29.368 shall be implemented/supported, where the 3GPP Network Entity takes the role as the MTC-IWF and the Application takes the role as the SCS, unless the security procedures for the relevant reference point Application - 3GPP Network Entity has been defined explicitly in some other specification (e.g. security procedures for MB2-C reference point are defined in TS 33.246).
Up

5.4  Security procedures for reference point SCEF - Interworking SCEF |R13|p. 9

The interface between SCEF and Interworking SCEF shall be protected using NDS/IP as defined in TS 33.210.

5.5  Security procedures for reference point SCEF-SCS/AS |R15|p. 9

5.5.1  Mutual authenticationp. 9

For authentication of the T8 reference point, mutual authentication based on client and server certificates shall be performed between the SCEF and the SCS/AS using TLS.
Certificate based authentication shall follow the profiles given in clauses 6.1.3a and 6.1.4a of TS 33.310. The structure of the PKI used for the certificate is out of scope of the present document.
Up

5.5.2  Security profilesp. 9

TLS shall be used to provide integrity protection, replay protection and confidentiality protection for T8 interface. The support of TLS on T8 interface is mandatory. Security profiles for TLS implementation and usage shall follow the provisions given in TS 33.310, Annex E.

5.5.3  Authorization of SCS/AS's requestsp. 9

After the authentication, SCEF determines whether the SCS / AS is authorized to send requests for the 3GPP Network Entity. The SCEF shall authorize the requests from SCS / AS using OAuth-based authorization mechanism, the specific authorization mechanisms shall follow the provisions given in RFC 6749.

5.5.4  Support for CAPIFp. 9

When the SCEF supports CAPIF as specified in sub-clause 4.4.8 of TS 23.682, then CAPIF core function shall choose the appropriate CAPIF-2e security method as defined in the sub-clause 6.5.2 of TS 33.122 for mutual authentication, authorization and protection of the SCEF-SCS/AS interface.

6  Security procedures for Device Triggeringp. 10

6.1  Network based solution for filtering SMS-delivered device trigger messagesp. 10

The following solution may be implemented to filter SMS-delivered device trigger messages.
This solution relies on the fact that there is a standardized indicator in the SM that can be used to distinguish a trigger SM from other types of SM, i.e. TP Protocol Id as specified in TS 23.040.
The solution further assumes that legitimate trigger SMs are delivered via either a SMS-SC in the HPLMN that can verify the identity of the SME sending a legitimate trigger SM over Tsms, or via an MTC-IWF in the HPLMN that can verify the identity of the SCS sending a legitimate trigger SM over Tsp.
The HPLMN shall implement Home Network Routing according to TS 23.040 for Mobile Terminated SMs destined for all HPLMN subscribers that need protection against unauthorised SMS-delivered device trigger messages (e.g. all subscriptions that may be used in MEs that support SMS-delivered device triggering).
Home Network Routing shall have the effect of forcing the delivery of the SM to an SMS Router in the HPLMN rather than to the serving MSC/VLR, SGSN or MME of the destination UE. If an SM received by the SMS Router does not originate from the SMS-SC in the HPLMN that handles SMS-delivered device trigger messages, then the SMS Router shall forward the SM to infrastructure that shall filter and block all SMs that contain a trigger indication.
  • Referring to the SMS architecture and function defined in TS 23.040 and TS 23.204, SMSs need to be delivered through SMS-SC. On the basis of the architecture of machine-type communication, for SMS based device trigger and TS 23.040, the SMS-SC can receive short message with the related sender and receiver's identities from three paths, i.e. SME via Tsms interface or T4 interface or from SMS-IWMSC. Filtering SMS-delivered device trigger messages is network-based, so the fake triggering SMSs from an attacker shall be distinguished and blocked to be sent by SMS-SC on the network side. The following is how these three paths work for SMS-SC to receive short messages: If an SM received by the SMS-SC in the HPLMN that handles SMS-delivered device trigger messages does not originate from the T4 interface, then the SMS-SC shall forward the SM to filtering infrastructure.
    If an SM received by the filtering infrastructure contains a trigger indication, and does not originate from a trusted SME that is authorised to send trigger SMs, then the SM shall be blocked.
    If an SM received by the filtering infrastructure contains a trigger indication, and does originate from a trusted SME that is authorised to send trigger SMs, then the filtering infrastructure shall only allow trigger requests to be sent to particular UEs that the trusted SME is authorised to send to. It is outside the scope of this specification how the filtering infrastructure shall determine if a trusted SME is allowed to send a device trigger to a particular UE.
  • When SMS-SC receives short message which is forwarded by MTC-IWF via T4 interface, the SMS-SC ensures T4 interface is trusted and sends the short message, because the MTC-IWF can authenticate MTC server and ensure that only the authorized MTC Server can trigger the particular MTC devices.
  • When the SMS-SC receives short messages from SMS-IWMSC, the SMS-SC shall also forward the SM to filtering infrastructure. Thus the SMS-SC can check if the SM is originated from an authorized SME by checking the receiver's authorized sender list. If not, it should block the fake SM to be sent.
If a trigger request received by the MTC-IWF originates from the Tsp interface, then the MTC-IWF shall filter and block the trigger unless it originates from a trusted SCS that is authorised to send trigger requests. The procedure is described in clause 5.2.1 of TS 23.682.
The normal UE is not allowed to send MO trigger SMSs to trigger MTC devices according to clause 9.2.3.9 of TS 23.040, so SMS-SC shall distinguish and block the fake MO device trigger SMSs from normal UE's subscription.
In order to protect against source spoofing, the interfaces used to transport trigger messages shall be suitably secured. In particular, the Tsms, Tsp and T4 interfaces shall be secured. Tsp interface security is specified in clause 4.3.3.1 of TS 23.682. The security mechanisms for the Tsms interface are outside the scope of this specification.
Filtering of SMS can be performed according to the architecture specified in TS 23.142. When the filtering entity receives an SM, it can identify if the SM is a trigger SM based on some trigger indication contained in the SM (i.e. TP Protocol Id as specified in TS 23.040).
Up

7  Security procedures for secure connectionp. 11

7.1  Introductionp. 11

The Secure Connection is a feature with which the network operator is able to efficiently provide key material for securing the application protocol between UE and a SCS (indirect model) or between UE and a MTC Application Server (direct model).
GBA, as specified in TS 33.220, is used to bootstrap authentication and key agreement for application security based on the 3GPP AKA mechanism. GBA shall be used to establish the keys for a UE initiated Secure Connection.
An extension to GBA, called GBAPush, is defined in TS 33.223. GBAPush is also used to establish keys for application security between two entities, but unlike GBA, it is initiated from the network. GBAPush shall be used to establish the keys for a network initiated Secure Connection.
Also other mechanisms (for example, using EAP-AKA authentication in scenarios which GBA cannot apply to) can be used to provide the MTC Secure Connection feature between the UE and SCS or between the UE and MTC Application Server. These mechanisms are regarded to be outside the scope of 3GPP specifications.
The implementation of Secure Connection feature in the ME and network is optional.
Up

7.2  UE initiated secure connectionp. 11

This solution is restricted to such UEs that support HTTP.
A UE-initiated Secure Connection shall be established using GBA as defined in TS 33.220.
GBA shall be used regardless if the Secure Connection is between the UE and SCS or between the UE and MTC Application Server. The SCS and the MTC Application Server shall act as NAFs. The Secure Connection key establishment using GBA is outlined as follows:
  • The UE runs a GBA bootstrapping with the BSF via the Ub interface. This bootstrapping results in that the UE and BSF share a session key Ks and an identifier associated with the Ks, called B-TID. The UE next generates a Ks_(ext/int)_NAF key from key Ks, and establishes a connection with the intended NAF over the Ua interface. The NAF function is performed by the SCS in the indirect model, and by the MTC Application Server in the direct model. At the start of the communication, the UE provides the NAF with the B-TID. The NAF requests the Ks_(ext/int)_NAF, corresponding to the B-TID from the BSF. The UE and SCS/MTC Application Server can then protect the Ua application protocol (i.e. the Secure Connection) using the shared Ks_(ext/int)_NAF key.
It depends on the used Ua application protocol how the Ks_(ext/int)_NAF keys are used in order to protect the communication between the UE and the SCS or between the UE and the MTC Application Server.
Up

7.3  Network initiated secure connectionp. 12

A network-initiated Secure Connection shall be established using GBAPush as defined in TS 33.223. GBAPush shall be used regardless if the Secure Connection is between the UE and SCS or between the UE and MTC Application Server. The SCS and the MTC Application Server shall act as Push NAFs.
The Secure Connection key establishment using GBAPush is outlined as follows:
  • The pushNAF, i.e. the SCS in the indirect model and the MTC Application Server in the direct model, determines the need to use GBAPush in order to establish keys for application security (i.e. a Secure Connection) with the UE. The pushNAF then requests a GBA Push-Info (GPI) and a Ks_(int/ext)_NAF key from the BSF and then forwards the GPI to the UE. The UE processes the GPI and generates a Ks_(ext/int)_NAF key from it. The UE and pushNAF can protect the Ua application protocol (i.e. the Secure Connection) using the shared Ks_(ext/int)_NAF key.
If the pushNAF (SCS or MTC Application Server) does not have IP connectivity with the UE, the GPI can be sent in the Device Trigger to the UE via the Tsp in case of SCS is the pushNAF and via Tsms in case of MTC Application Server (acting as SME) is the pushNAF. In this case the GPI can serve two purposes: it can be used to provide keys for the application protocol (i.e. Secure Connection) and it can also be used protect the device trigger itself in an end-to-end manner.
If the pushNAF (SCS or MTC Application Server) has IP connectivity with the UE, the GPI can be sent within the application protocol that the MTC application uses and used to provide keys for the Secure Connection.
It depends on the used Ua application protocol how the Ks_(ext/int)_NAF keys are used in order to protect the communication between the UE and the SCS or between the UE and the MTC Application Server.
Up

8  Security procedures for restricting the USIM to specific UEsp. 12

8.1  UE-based procedure with USAT application pairingp. 12

8.1.1  Generalp. 12

This clause specifies how the use of a USIM can be restricted to specific MEs thanks to UE-based solution relying on USAT application pairing. The solution is optional for implementation in the User Equipment and in the operator network.
To have USAT application pairing capable User Equipment, the ME shall support USAT, as specified in TS 31.111.

8.1.2  Security procedurep. 12

USAT application pairing is successful when the IMEI or IMEISV retrieved from the terminal matches the value or the range of values the UICC is configured with. USAT application pairing fails if the terminal does not support USAT command PROVIDE LOCAL INFORMATION.
An UE supporting USAT application pairing proceeds to Profile download as specified in TS 31.111. Then, the USIM requests IMEI(SV) using PROVIDE LOCAL INFORMATION proactive command. The ME sends the TERMINAL RESPONSE with its IMEI(SV).
The file EF IWL stores the IMEI(SV) or range of value to which the USIM is bound.
The file EF IPS stores the status of the last pairing check performed by the UICC. The UICC checks the combination of USIM and MTC ME and sets the status flag to "OK" in case of successful pairing check. The UICC also stores in the file EF IPD the IME(SV) value of the MTC ME. In case of unsuccessful pairing check, the USIM sets the status flag to "KO" in the file EF IPS and stores in the file EF IPD the IME(SV) value of the unauthorized MTC ME.
The status flag of pairing check (with value "OK" or "KO") stored in the file EF IPS can be read by any terminal hosting the UICC. But, the IMEI(SV) value stored in the file EF IPD is protected by ADM right, only the operator can retrieve this information. The information stored in the file EF IPD provide a mechanism to detect change of association between a USIM and a MTC ME. The information stored in the files EF IPS and EF IPD can be read out locally by the maintenance persons.
The UICC shall respond to any AUTHENTICATE command with error status words if:
  • IMEI or IMEISV provided by the ME is not in the corresponding white list configured in the USIM (EF IWL)
Or
  • ME has not provided either IMEI or IMEISV
If the AUTHENTICATE command had been executed before the pairing procedure has been successfully performed (in the case of pre-Rel-12 MEs), the UICC may need to trigger a network attachment procedure by sending a proactive command REFRESH(3G SESSION RESET).
UICC OTA mechanism (as specified in TS 31.115 / TS 31.116 and ETSI TS 102 225 [12] and TS 102 226 [13]) is used to update the file EF IWL stored in the USIM. This mechanism provides dynamic management of the pairing to change the allowed combinations of USIM and MTC ME(s) by adding or removing authorized IMEI(SV) values or IMEI(SV) ranges the file EF IWL.
Up

$  Change Historyp. 14


Up   Top