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.

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 MTC-IWF SCEF

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.

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.

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.

The security requirements for MTC include the following:

• MTC optimizations shall not degrade security compared to non-MTC communications TS 22.368

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

The functionality of the MTC-IWF includes the following:

• support ability to satisfy security requirements on Tsp reference point in clause 4.5.

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.

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

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

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

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

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.

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.

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.