8 MCData
33.1803GPPRelease 17Security of the Mission Critical (MC) serviceTS
8.1 Overview
MCData SDS allows transmission of short data messages (SDS), either private or group, over both the signalling plane (reference point MCData-SDS-1) and media plane (reference point MCData-SDS-2).
MCData File Distribution (FD) also allows for transmission of files, either private or group, over the media plane or using HTTP. When distributed using HTTP, binary data representing the file is uploaded and downloaded using HTTP POST and HTTP GET.
MCData signalling parameters for SDS and File Distribution are routed within SIP messages. Protection for these signalling messages and files when distributed using HTTP, use the same key material as for MCPTT and MCVideo.
The MCData SDS or FD messages may also contain a MCData Data signalling payload or a MCData Data payload or both. These payloads may be within a SIP message should the signalling plane be used, or within a MSRP message should the media plane be used. The MCData Data payload may be end-to-end confidentiality and integrity protected according to an end to end security context payload.
The file when distributed using HTTP may be end-to-end confidentiality and integrity protected according to an end to end security context payload before being uploaded.
Components of MCData messages:
– MCData signalling parameters: generic Mission Critical Services signalling elements e.g. MCData Group ID, MCData user ID. These parameters are confidentiality protected between the MCData Client and the MCData server with signalling plane security mechanisms.
– MCData Data signalling payload: information elements necessary for identification and management of the MCData messages e.g. conversation identifiers, session identifiers, transaction identifiers, disposition requests, etc. This payload is confidentiality protected between the MCData Client and the MCData server with signalling plane security mechanisms.
– End to end security parameters: information specifying the cryptographic elements used to protect the data payload).
– MCData Data payload: the actual user payload for MCData user or application consumption. This payload is end to end confidentiality and integrity protected.
Components of the MCData message (MCData signalling parameters and MCData Data signalling payload) are integrity protected between the MCData Client and the MCData server with the signalling plane security mechanisms.
Figure 8.1-1: MCData message components
For one-to-one communications the PCK is used to protect the MCData data payload or the file when distributed using HTTP. For group communications, the GMK is used to protect the MCData data payload or the file when distributed using HTTP. The data payload or the file when distributed using HTTP may also be authenticated by the initiator.
Distribution of the PCK is within the signalling channel setup for the MCData private message (either SDS or FD). Distribution of the GMK is as defined in clause 5.7.
8.2 Key Management
Key management for MCData follows the same model as MCVideo and MCPTT. Where a key is used for protection of MCData or MCVideo data, the same type of key shall be used in the same circumstance for MCData. Each key used for protection of MCData payloads is known as the MCData Payload Protection Key (DPPK).
MCData signalling parameters and Data signaling payloads are protected as follows:
– Unicast MCData signalling parameters and Data signaling payloads between client and server are protected using the CSK (e.g. the DPPK is the CSK).
– Multicast MCData signalling parameters and Data signaling payloads from server to client are protected using a MuSiK (e.g. the DPPK is a MuSiK).
– MCData signalling parameters and Data signaling payloads between servers are protected using the SPK (e.g. the DPPK is the SPK).
– MCData signalling parameters and Data signaling payloads between two off-network clients are protected using a PCK (e.g. the DPPK is the PCK).
– MCData signalling parameters and Data signaling payloads between a group of off-network clients are protected using a GMK (e.g. the DPPK is the GMK).
MCData Data payloads are protected as follows:
– MCData Data payloads end-to-end protected between two online clients are protected using a PCK (e.g. the DPPK is the PCK).
– MCData Data payloads end-to-end protected between two off-network clients are protected using a PCK (e.g. the DPPK is the PCK).
– MCData Data payloads end-to-end protected between a group of online clients are protected using a GMK distributed by a GMS (e.g. the DPPK is the GMK).
– MCData Data payloads end-to-end protected between a group of off-network clients are protected using a GMK distributed by a GMS (e.g. the DPPK is the GMK).
– MCData Data payloads are end-to-end authenticated based on SSK, PVT and KPAK distributed by a KMS.
Files when distributed using HTTP are protected as follows:
– Files end-to-end protected between two online clients when distributed using HTTP are protected using a PCK (e.g. the DPPK is the PCK).
– Files end-to-end protected between a group of online clients when distributed using HTTP are protected using a GMK distributed by a GMS (e.g. the DPPK is the GMK).
NOTE: The DPPK is not a new type of key, it describes how the MC system’s existing key types are used to protect MCData. Consequently, there will be multiple DPPKs in the MC System depending on the communication channel. Furthermore, while a PCK and a GMK may both be used as a DPPK to protect MCData in different channels, the PCK and the GMK are not the same key.
8.3 One-to-one communications
The purpose of key management is to establish a MCData Payload Protection Key (DPPK) for the one-to-one communication channel between the pair of communicating clients. In the case of a one-to-one communication, the DPPK shall be the PCK. The PCK is used for end-to-end protection of one-to-one (private) SDS or FD data payloads.
The PCK and PCK-ID are distributed within the SIP message used to initiate the session.
The PCK and PCK-ID is distributed using service-specific signalling. For all MCData services, SIP signalling is used to establish or send the MCData communication. The PCK and PCK-ID is distributed within a MIKEY payload contained within the SDP offer sent from the initiator to the receiver in the same way as for MCPTT and MCVideo. The procedures for PCK distribution are defined within clause 5.6.
For off-network MCData operations, an MCData payload containing a MIKEY_SAKKE I-MESSAGE (clause 8.5.4.1) is used to distribute an MCData DPPK (PCK) from the initiating MCX client to the terminating MCX client.
This key distribution mechanism applies to the following messages defined in TS 23.282 [38]:
– MCData standalone data request
– MCData session data request
– MCData FD request
When required by the MCData service provider, protection shall be applied to the MCData Data payloads using the PCK. Payload authentication may also be applied. The mechanisms used to secure these payloads are described in clause 8.5.
Once the PCK is established between the source and destination, SDS and FD exchanges between this same source and destination may continue to use the same PCK for subsequent MCData communications by simply providing the PCK-ID in every SDS message.
8.4 Group communications
The purpose of key management is to establish a MCData Payload Protection Key (DPPK) for the group communication between the group of communicating clients. In the case of group communication, the DPPK shall be the GMK. The GMK is distributed in the same way as for MCPTT and MCVideo group communications, as defined in clause 5.7.
When required by the MCData service provider, protection shall be applied to the MCData Data payloads using the GMK. Payload authentication may also be applied. The mechanisms used to secure these payloads are described in clause 8.5.
8.5 MCData payload protection
8.5.1 General
The protection applied to the MCData payload is indicated by the ‘Message Type’ of the MCData payload. If the payload is protected (encrypted and integrity protected), Bit ‘7’ of the Message Type shall be ‘1’ (otherwise it shall be ‘0’), if the payload is authenticated, Bit ‘8’ of the Message Type shall be ‘1’ (otherwise it shall be ‘0’). See Clause 15.2.2 of TS 24.282 [50].
The following protected (encrypted and integrity protected) payloads are defined for MCData SDS and file distribution:
– Protected SDS Signalling Payload.
– Protected FD Signalling Payload.
– Protected Data Payload.
– Protected SDS notification message.
– Protected FD notification message.
– Protected FD network notification message.
– Protected Communication release message.
– Protected binary data representing the file.
The following authenticated payloads are defined for MCData SDS and file distribution:
– Authenticated Data Payload.
The following authenticated and protected (encrypted and integrity protected) payloads are defined for MCData SDS and file distribution:
– Authenticated and Protected Data Payload.
In this case both the procedures for protecting a payload and authenticating a payload are applied
8.5.2 Prequisites
8.5.2.1 Prequisites for protected payloads
The prequisites for encryption and integrity protection of a protected payload is that the MC client(s) or MC server(s) have a shared MCData Payload Protection Key (DPPK). This shall be the CSK, SPK, MuSiK, GMK or PCK depending on the payload that will be protected. The DPPK will also have a shared key identifier, the DPPK-ID. This shall be the CSK-ID, MuSiK-ID, SPK-ID, GMK-ID or PCK-ID respectively, based upon the type of key used.
8.5.2.2 Prequisites for authenticated payloads
The prequisites for authentication of an authenticated payload is that the MC client will have been keyed (SSK, PVT and KPAK) by a KMS as defined in clause 5.3.
8.5.3 Key derivation for protected payloads
Before protecting an MCData payload, the DPPK is hashed through a KDF (similar to the process used for XML protection for application signalling), to produce a MCData Payload Cipher Key (DPCK). The KDF is defined in Annex F.1.5.
8.5.4 Payload protection
8.5.4.1 Format of protected payloads
All protected payloads shall have the format defined in table 8.5.4.1-1:
Table 8.5.4.1-1: MCData Protected Payload message content
|
Information Element |
Type/Reference |
Presence |
Format |
Length |
|
Message Type |
Message type |
M |
V |
1 |
|
Date and Time |
Date and Time of creation of protected payload message. |
M |
V |
5 |
|
Payload ID |
The identifier for the payload. |
M |
V |
4 |
|
Payload sequence number |
The sequence number of the protected payload. |
M |
V |
1 |
|
Payload algorithm |
See 8.5.4.2 |
M (NOTE 5) |
V |
1 |
|
Signalling algorithm |
See 8.5.4.2 |
O (NOTE 6) |
V |
1 |
|
IV |
Initialisation vector (or nonce) for message |
M |
V |
16 |
|
DPPK-ID |
Key identifier |
M |
V |
4 |
|
Payload |
Protected Payload (Ciphertext) |
M |
TLV-E |
x |
|
MIKEY_SAKKE I-MESSAGE |
DPPK(PCK) encapsulated within MIKEY_SAKKE I-MESSAGE |
O (NOTE 4) |
TLV-E |
x |
Where ‘Payload’ will be the encrypted and integrity-protected payload encoded in a binary format.
NOTE 1: Date and Time is included as plaintext to allow the MCData server to order end-to-end protected messages and assess whether end-to-end protected messages may have expired.
NOTE 2: Payload ID and Payload sequence number allow protected payloads to be split over multiple SIP messages.
NOTE 3: When file is distributed using HTTP, MCData Protected Payload message is distributed as part of protected FD Signalling Payload and the protected binary data representing the file is uploaded using HTTP.
NOTE 4 This information element applies only to off-network communications. It is optionally included, for example, when the originating client does not have an active PCK for the terminating client.
NOTE 5 This field applies to the protection of the data payload field.
NOTE 6 This field applies to the protection of the MCData signalling parameters field, Data signalling payload field, and End to end security parameters fields. This field defaults to DP_AES_128_GCM (as defined in clause 8.5.4.2) if not present.
8.5.4.2 Encryption of protected payloads
Protection of payloads shall support the following algorithms (cipher suites):
Table 8.5.4.2-1: DP_AES_128_GCM algorithm parameters
|
Parameter |
Value/Reference |
|
Algorithm ID |
DP_AES_128_GCM |
|
Cipher |
AEAD_AES_128_GCM (as defined in RFC 5116 [43]) |
|
DPCK Key length |
128 bits |
|
IV length |
128 bits |
|
AEAD authentication tag length |
128 bits |
Table 8.5.4.2-2: DP_AES_256_GCM algorithm parameters
|
Parameter |
Value/Reference |
|
Algorithm ID |
DP_AES_256_GCM |
|
Cipher |
AEAD_AES_256_GCM (as defined in RFC 5116 [43]) |
|
DPCK Key length |
256 bits |
|
IV length |
256 bits |
|
AEAD authentication tag length |
128 bits |
In using the above cipher suites as defined in RFC 5116 [43], the plaintext, P, shall be the full original plaintext payload. The associate data (AD) shall be the Message Type, Date and Time, Payload ID, Payload sequence number, Algorithm, IV, and DPPK-ID fields within the MCData Protected Payload message content defined in clause 8.5.4.1.
8.5.5 Payload authentication
Authenticated payloads shall have the format defined in table 8.5.5-1:
Table 8.5.5-1: MCData Authenticated Payload message content
|
Information Element |
Type/Reference |
Presence |
Format |
Length |
|
Original Payload |
Original Payload (unchanged) |
M |
TLV-E |
x |
|
Algorithm |
Algorithm used to sign the message |
M |
V |
1 |
|
Signing Data |
Signature data |
M |
TLV-E |
x |
|
Signature |
Based on algorithm |
M |
TLV-E |
x |
The signature shall be on the entire payload excluding the value of the signature element. However, the type and length of the signature element shall be included in the signature. The signature value shall be encoded in binary format.
The ECCSI signature algorithm as defined in RFC 6507 [9] shall be supported by MC clients.
The contents of the Signing Data field is determined by the signature algorithm. For ECCSI, the signing data shall be as defined in table 8.5.5-2:
Table 8.5.5-2: ECCSI Signing Data content
|
Information Element |
Type/Reference |
Presence |
Format |
Length |
|
Signing UID |
Signers UID as defined in Annex F.2.1 |
M |
TLV |
x |
|
Signing KMS |
Signer’s KMS URI |
M |
TLV |
x |
After signature vertification, the verifier shall extract the sender’s URI from elsewhere in the message and check that this corresponds to the UID contained in the Signing UID field above. If not, signature verification shall have failed.
8.6 MCData message store security
8.6.0 Functional model
The functional model for the MCData message store is shown in figure 8.6.0-1.
Figure 8.6.0-1: MCData message store functional model
In the functional model shown in figure 8.6.0-1, the reference points MCData-7 and MCData-8 provide direct communications with the MCData message store from the MCData UE message store client and the MCData server capabilities function, respectively. Reference point(s) MCData-cap-n provide MCData message store functionality between the MCData client capabilities function and the MCData message store via the MCData server capabilities function. Security for the MCData message store reference points are described in clause 8.6.1.
HTTP requests from the MCData message store client to the MCData message store shall include an appropriately scoped access token for MCData. If the access token cannot be validated by the MCData message store, the HTTP request shall be rejected. To validate access tokens, the MCData message store shall validate the signature of the access token. The method used to provision the MCData message store with the IdMS signature validation credentials is out of scope of this document.
The MCData message store may be configured with an authorized MCData server list and the MCData server may be configured with an authorized MCData message store server list. When supported, the authorized MCData server list in the MCData message store contains the allowed public service identities of MCData servers of the MC service provider for the MCData Client.
NOTE: Handling (creating and revocation) of the lists is out of scope of the present document and left to implementation.
HTTP requests from the MCData capabilities function client to the MCData server capabilities function shall include an appropriately scoped access token for MCData. If the access token cannot be validated by the MCData server, the HTTP request shall be rejected.
If required by the MC domain operator, data and information stored at the MCData message store related to the SDS, FS or DS services shall be stored protected. The mechanism used to protect the data and information while not actively in use is out of scope of this document.
8.6.1 MCData message store reference points
8.6.1.1 Reference point MCData-7 (between the Message store client and MCData message store)
The MCData-7 reference point exists between the Message store client and the MCData message store and is used by the Message store client as defined in 3GPP TS 23.282 [38].
For HTTP messaging on the MCData-7 reference point, HTTPS as defined in clause 6.1.2 shall be used.
For SIP messaging on the MCData-7 reference point, SIP interface protection mechanisms as defined in clause 6.2.2 shall be used.
8.6.1.2 Reference point MCData-8 (between the MCData message store and MCData server)
The MCData-8 reference point, which exists between the MCData server and the MCData message store, is used by the MCData server as defined in 3GPP TS 23.282 [38]. Reference point MCData-8 shall be a direct connection between the MCData server and the MCData message store, i.e. MCData-8 does not pass through the HTTP proxy for HTTP messaging.
For HTTP messaging on the MCData-8 reference point, HTTPS as defined in clause 6.1.2 shall be used.
For SIP messaging on the MCData-8 reference point, SIP interface protection mechanisms as defined in clause 6.2.2 shall be used.
8.6.1.3 Reference point MCData-cap-n (between the MCData server and the MCData client)
The MCData-cap-n reference point(s) support varying functionality depending on the capabilities function (i.e. SDS, FS or SD) as described in 3GPP TS 23.282 [38].
If HTTP messaging is used on the specified MCData-cap-n reference point, HTTPS as defined in clause 6.1.2 shall be used.
If SIP messaging is used on the specified MCData-cap-n reference point, SIP protection mechanisms as defined in clause 6.2.2 shall be used.