E.2 MIKEY message structure for GMK distribution
33.1803GPPRelease 17Security of the Mission Critical (MC) serviceTS
E.2.1 General
In the Common Header payload, the CSB ID field of MIKEY common header shall be the GUK-ID.
Where no crypto sessions are included in the payload, (CS# is 0), the default security profile defined in Annex E.2.2 shall be used, and no Secuirty Properties payload (SP) is required. The profile in Annex E.2.2 is mandatory to support.
Identity payloads shall be IDR payloads as defined in section 6.6 of IETF RFC 6043 [25]. The IDRi payload shall contain the MCX service identifier associated with the group management server. The IDRr payload shall contain the MC Service user ID associated to the group management client. The message shall also include IDRkmsi and IDRkmsr that contains the URI of the MC KMS used by the group management server and MC 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.
The SAKKE payload shall encapsulate the GMK to the UID generated from the MC Service user ID of the group management client. Only one GMK key shall be transported in the SAKKE payload. The same GMK shall be encapsulated to each member of the group.
A SAKKE-to-SELF payload may be included. It is recommended that where the GMK is being transported beyond a single MC system, the message should include a SAKKE-to-SELF payload as described in clause E.5.
A ‘Key Properties’ payload (Annex E.6) should be included to provide details of the GMK.
The signature shall use the UID generated from the identifier associated with the group management server.
E.2.2 Default SRTP security profile for GMK use
The default security profile is used to support MCPTT and MCVideo communications. It defines the mandatory to support security settings for distribution and use of the GMK. 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 ‘4’ for MCPTT and ‘5’ for MCVideo. The ‘Prot Type’ shall be ‘0’ (SRTP).
The Security Policies are shown in Table E.2-1.
Table E.2.2-1: MIKEY Group call SRTP Default Profile
SRTP Type |
Meaning |
Value |
Meaning |
0 |
Encryption Algorithm |
6 |
AES-GCM |
1 |
Session encryption key length |
16 |
16 octets |
2 |
Authentication algorithm |
4 |
RCCm3 (Use of unauthenticated ROC) |
4 |
Session salt key length |
12 |
12 octets |
5 |
SRTP PRF |
0 |
AES-CM |
6 |
Key derivation rate |
0 |
No session key refresh. |
13 |
ROC transmission rate |
1 |
ROC transmitted in every packet. |
18 |
SRTP Authentication tag length |
4 |
4 octets for transmission of ROC |
19 |
SRTCP Authentication tag length |
0 |
ROC need not be transmitted in SRTCP. |
20 |
AEAD authentication tag length |
16 |
16 octets |
Should a security profile be provided by the GMS, the mapping is provided in a GENERIC-ID component of the MIKEY HDR. The CS-ID shall be ‘4’ for MCPTT and/or ‘5’ for MCVideo. Consequently, the CS# shall be ‘1’ or ‘2’. The ‘Prot Type’ shall be ‘0’ (SRTP).
In each GENERIC-ID crypto session, ‘#P’ shall be 1 (a single security policy shall be referenced). The ‘Session Data length’ shall be ‘0’ as SSRCs are not provided by the GMS. The MKI (GMK-ID || GUK-ID) may be included in the SPI field.