7.5 Media protection profile

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

7.5.1 General

The following mechanism shall be used to protect MCPTT and MCVideo communications which use the Real-Time Transport Protocol (RTP), cf. IETF RFC 3550 [12]. The integrity and confidentiality protection for MCPTT and MCVideo communications using RTP shall be achieved by using the Secure Real-Time Transport Protocol (SRTP), IETF RFC 3711 [13].

The key management mechanism for SRTP is described elsewhere. As a result of this mechanism, those communicating will have shared the following:

1) A SRTP Master Key.

2) A SRTP Master Salt.

3) A SRTP Master Key Identifier (MKI) referencing the above two values.

The mechanism described in IETF RFC 3711 [13] is used to encrypt the RTP payload. A diagram of the key derivation mechanism (as described in IETF RFC 3711) is shown in figure 7.5.1-1.

Figure 7.5.1-1: Security mechanism for media stream protection

The AES-CM-128 algorithm as defined in IETF RFC 3711 [13] shall be supported as the SRTP PRF (which is used to derive the SRTP session key and salt). A SRTP key derivation rate of 0 shall be used to indicate that session keys and salts shall not be refreshed. The AEAD_AES_128_GCM algorithm as defined in IETF RFC 7714 [26] shall be supported for providing confidentiality and data authentication of SRTP packets. The AEAD_AES_128_GCM algorithm requires that the SRTP session key is 16 octets in length, and the SRTP session salt is 12 octets in length.

Unless provided in the MIKEY message used to distribute the SRTP Master Key, the SSRC shall be randomly generated for each session. For group communications, the GMS shall not provide SSRCs, and hence the SSRC shall be randomly generated.

Care should be taken to avoid SSRC repetition when a user uses the SRTP Master Key for more than one session. In particular, SSRCs shall not be generated in a way which could cause collisions (e.g. from the same seed).

The SRTP authentication tag may be appended to every ‘rth’ packet as defined in IETF RFC 4771 [24] to provide the SRTP ROC counter to MC UEs performing a late-entry to the communication. A ‘mode 3’ integrity transform (RCCm3) shall be supported for transmitting the ROC within a 4 octet SRTP authentication tag.

NOTE: The ROC and MKI fields of the SRTP packet are not authenticated as part of the AEAD_AES_128_GCM algorithm. However, modification of these fields would cause a failure to validate the AEAD authentication tag which would cause the packet to be correctly rejected by the receiver. If an unauthenticated SRTP encryption mode be used, there will be a security impact of a malicious modification of the ROC or MKI packets.

7.5.2 Security procedures for media stream protection

Media stream protection does not require any signalling mechanism to convey information. The information is provided within each SRTP Packet.

Figure 7.5.2-1: Security procedure for media stream protection

Figure 7.5.2-1 shows the security mechanism.

0) Prior to beginning this procedure the MC UEs involved in the communication shall have established a security context (SRTP Master Key, SRTP Master Salt, MKI).

1) Transmitting UEs shall send SRTP packets using the format described in IETF RFC 3711 [13]. The packet shall include a Master Key Identifier (MKI) field which contains the information required to locate the SRTP Master Key and Master Salt, and may include the SRTP ROC as defined in IETF RFC 4771 [24]. On receipt of a SRTP packet, a terminating UE shall use the contents of the MKI to look up the appropriate SRTP Master Key and salt and generate the appropriate SRTP session key and salt if it satisfies the key derivation rate criteria as specified in IETF RFC3711. If it appears in the SRTP packet, the terminating UE shall use the contents of the SRTP authentication tag to establish the SRTP ROC as defined in IETF RFC 4771 [24].

NOTE 1: Assuming members of the group have been keyed/pre-provisioned at some point in the past, this security mechanism is entirely stateless.

NOTE 2: The receiver does not need to generate an appropriate SRTP session key and salt every time when it receives a SRTP packet. The key derivation rate defined in IETF RFC3711 [13] determines the session key generation frequency. Refer to RFC3711 for more information.

NOTE 3: As the SRTP synchronization source identifier (SSRC) is used for encryption and decryption, the SSRC value in the SRTP packet needs to be maintained from the transmitting UE to the receiving UE. This includes the uplink and the downlink, over unicast or multicast.

A diagram of the SRTP packet format is within figure 7.5.2-2.

Figure 7.5.2-2: SRTP packet format showing security parameters

The length of the MKI field is defined by the key distribution procedure used to create the original security context.