E.1 General aspects

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

E.1.1 Introduction

MIKEY-SAKKE as defined in IETF RFC 6509 [11] is used to transport Group Master Keys (GMKs) from a Group Management Server to a Group Management Client on a MC UE, Private Call Keys (PCKs) between MC UEs, Client-Server keys (CSKs) between MCX Server and MC client, and Multicast Signalling Keys (MuSiK) from MCX Servers to MC clients.

The GMK is encrypted to the UID generated from the receiving user’s MC Service user ID and current time period. It is signed using the UID generated from the URI associated to the Group Management Server and current time period. Similarly, the PCK is encrypted to the UID generated from the receiving user’s MC Service user ID and current time period. It is signed using the UID generated from the initiating user’s MC Service user ID and current time period. When uploaded, the CSK is encrypted to the UID generated from the MCX Server’s FQDN and current time period and signed using the UID of the MC user. When downloaded, the CSK and MuSiK is encrypted to the UID of the MC user and signed using the UID of the MCX Server. Details of this process are defined in IETF RFC 6508 [10] and IETF RFC 6507 [9]. The generation of the MIKEY-SAKKE UID is defined in clause F.2.1.

The GMK, PCK, CSK and MuSiK shall be 16 octets in length.

E.1.2 MIKEY common fields

All MIKEY-SAKKE messages shall include the Common Header payload (HDR), Timestamp payload (TS), RAND payload, IDRi payload, IDRr payload, IDRkmsi payload, IDRkmsr payload, SAKKE payload and a SIGN (ECCSI) payload.

Optionally, the MIKEY-SAKKE message may contain a Security Properties payload (SP), a second SAKKE payload (SAKKE-to-self specified in Annex E.5), and a key parameter payload (specified in Annex E.6)

In the MIKEY HDR, the ‘data type’ shall be ’26’ (as this is a MIKEY-SAKKE message). The ‘V’ bit shall be ‘0’. The ‘PRF func’ may be ‘1’ indicating the use of ‘PRF-HMAC-SHA-256’ (‘PRF-HMAC-SHA-256’ is the only PRF algorithm that is mandatory to support). The ‘CS#’ may be 0 or more.

– Where the ‘CS#’ is ‘0’, the ‘CS ID map type’ shall be ‘1’ (empty map) and ‘CS ID Map Info’ shall have length ‘0’. This shall imply that default security policies shall be applied (as defined in further clauses).

– Where the ‘CS#’ is greater than ‘0’, the ‘CS ID map type’ shall be ‘2’ (GENERIC-ID as defined in RFC 6043 [25]).

Each MIKEY message contains the timestamp field (TS). The timestamp field shall be TS type NTP-UTC (TS type 0), and hence is a 64-bit UTC time.

The ID Scheme in the SAKKE payload shall be ‘3GPP MCX hashed UID ‘ to reflect the generation scheme defined in clause F.2.1.

The ID Scheme ‘3GPP MCX hashed UID’ takes on the IANA assigned value of ‘2’ [52].

The entire MIKEY message shall be signed by including an Signature payload (SIGN) providing authentication of the origin of the message. The signature (S type) field shall be of type ‘2’ (ECCSI) and the Signature length field shall be "32", indicating a signature length of 32 bytes (i.e. 256 bits). The signature shall then be calculated over the entire MIKEY message (including the S type field and Signature length field of the Signature payload) followed by concatenation of the signature to the end of the MIKEY message as described in RFC 3830 [22] section 5.2..

E.1.3 Crypto Session Identifiers

The MIKEY payload defines the use of Crypto Sessions. Each Crypto Session is identified by a CS-ID. To ensure that a crypto session can be assigned to a specific use within the MC System, the Crypto Session identifiers are defined in Table E.1.3-1.

Table E.1.3-1: CS-ID assignment

CS-ID	Use
0	Initiator’s MCPTT Private Call
1	Receiver’s MCPTT Private Call
2	Initiator’s MCVideo Private Call
3	Receiver’s MCVideo Private Call
4	MCPTT Group Call
5	MCVideo Group Call
6	CSK SRTCP protection for MCPTT
7	MuSiK SRTCP protection for MCPTT
8	CSK SRTCP protection for MCVideo
9	MuSiK SRTCP protection for MCVideo

In Table E.1.3-1, CS-ID ‘0’ and ‘2’ are used for SRTP/SRTCP streams originating from the initator of the private call. CS-ID ‘1’ and ‘3’ are used for SRTP/SRTCP streams originating from the receiver of the private call.