E.4 MIKEY message structure for CSK and MuSiK distribution

33.1803GPPRelease 17Security of the Mission Critical (MC) serviceTS

E.4.1 General

The CSK and MuSiK shall only be used to protect SRTCP payloads and shall not be used to protect SRTP payloads.

In the Common Header payload, the CSB ID field of MIKEY common header for CSK and MuSiK distribution shall be the CSK-ID or MuSiK-ID (resp).

Where no crypto sessions are included in the payload, (CS# is 0), the default security profile defined in Annex E.4.2 shall be used, and no Secuirty Properties payload (SP) is required. The profile in Annex E.4.2 is mandatory to support.

Identity payloads shall be IDR payloads as defined in section 6.6 of IETF RFC 6043 [25].

For CSK upload, the IDRi payload shall contain the MC Service user ID associated with the initiating user. The IDRr payload shall contain the MDSI of the MCX Domain. The message shall also include IDRkmsi and IDRkmsr that contains the URI of the KMS used by the initiating user and MCX Domain respectively.

For CSK and MuSiK download, the IDRi payload shall contain the MDSI of the MCX Domain. The IDRr payload shall contain the MC Service user ID associated with the initiating user. The message shall also include IDRkmsi and IDRkmsr that contains the URI of the KMS used by the MCX Domain and initiating user respectively.

NOTE: In some deployments MC Service user IDs (i.e. MCPTT ID, MCVideo ID, MCData ID) within these payloads may be treated as private. In this case, these identities may be hidden using the mechanism in clause E.7.

For CSK upload, the SAKKE payload shall encapsulate the CSK to the UID generated from the MDSI of the MCX Domain, and the current time period. For CSK or MuSiK download, the SAKKE payload shall encapsulate the key to the UID generated from the user ID associated with the initiating user and the current time period.

A ‘Key Properties’ payload (Annex E.6) may be included to provide details of the CSK or MuSiK.

For CSK Upload, the signature shall use the UID generated from the identifier associated with MC Service user ID associated with the initiating user. For CSK and MuSiK download, the signature shall use the UID generated from the identifier associated with MDSI of the MCX Domain.

E.4.2 Default SRTCP security profile for CSK and MuSiK

The default security profile is used to support SRTCP for MCPTT and MCVideo communications. It defines the mandatory to support security settings for distribution and use of the CSK and MuSiK. It is the profile that should be used should no information (Crypto session information or security policies) be provided in the MIKEY message.

The CS-ID (for input into the MIKEY PRF) shall be ‘6’ for CSK use within MCPTT (floor control and media control), ‘7’ for MuSiK use within MCPTT, ‘8’ for CSK use within MCVideo (transmission control), and ‘9’ for MuSiK use within MCVideo. The ‘Prot Type’ shall be ‘0’ (SRTP).

The Security Policies are shown in Table E.4.2-1.

Table E.4.2-1: MIKEY Default Profile for CSK and MuSiK

SRTP Type	Meaning	Value	Meaning
0	Encryption Algorithm	6	AES-GCM
1	Session encryption key length	16	16 octets
4	Session salt key length	12	12 octets
5	SRTP PRF	0	AES-CM
6	Key derivation rate	0	No session key refresh.
20	AEAD authentication tag length	16	16 octets

E.4.3 Providing a SRTCP security profile for CSK or MuSiK

Should a security profile be provided, the mapping is provided in a GENERIC-ID component of the MIKEY HDR. For CSK transmission, the CS-ID shall be ‘6’ for CSK use within MCPTT (floor control and media control) and ‘8’ for CSK use within MCVideo (transmission control),. For MuSiK transmission, the CS-ID shall be ‘7’ for MuSiK use within MCPTT and ‘9’ for MuSiK use within MCVideo. Consequently, the CS# shall be ‘1’ or ‘2’ for either CSK or MuSiK transmission.

In each GENERIC-ID crypto session, ‘#P’ shall be 1 (a single security policy shall be referenced). The MC Server may provide SSRCs for SRTCP within the Session Data. The MKI (GMK-ID || GUK-ID) may be included in the SPI field.