7.6 Protection of offline floor and media control signalling (SRTCP)

33.1793GPPRelease 13Security of Mission Critical Push To Talk (MCPTT) over LTETS

7.6.1 General

Floor control signalling is sent from the MCPTT UE to a Floor Arbitrator. The Floor Arbitrator will be part of the MCPTT server when MCPTT group communications are online. When MCPTT group communications are offline, the Floor Arbitrator will be an MCPTT client. Floor control signalling is transmitted using MBCP or TBCP, both of which use RTCP, cf. IETF RFC 3550 [12]. The integrity and confidentiality protection for one-to-many communications using RTCP may be achieved by using SRTCP, IETF RFC 3711 [13]. Media control signalling is also protected using SRTCP.

For online communications, the connection between the MCPTT UE and the Floor Arbitrator (MCPTT Server) is protected by using SRTCP which key agreement is specified in clause 9.4. This clause provides a mechanism for protecting offline floor control signalling during the group call or the private call.

When the MCPTT client is operating off network, the key management as well as the Master Key and Master Salt for SRTCP is the same with that for SRTP. As a result of this mechanism, the group members in the group call or MCPTT UEs in the private call share a Master Key, a Master Salt and an MKI for the protection of SRTCP.

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

Figure 7.6.1-1: Security mechanism for floor control protection

The AES-CM-128 algorithm as defined in IETF RFC 3711 [13] shall be supported as the SRTCP PRF (which is used to derive the SRTCP 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 SRTCP packets. The AEAD_AES_128_GCM algorithm requires that the SRTCP session key is 16 octets in length and the session salt is 12 octets in length.

NOTE: Some SRTCP implementations are not compliant with RFC 3711 [13] due to the size of the SRTCP index, as discussed in RFC 3711 Errata ID 3712 [40].

7.6.2 Security procedures for offline floor and media control protection

Floor and media control protection does not require any signalling mechanism to convey information. The information is provided within each SRTCP Packet.

Figure 7.6.2-1: Security procedure for media stream protection

Figure 7.6.2-1 shows the security mechanism.

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

1) Transmitting UEs shall send SRTCP 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 Master Key and Master Salt. On receipt of a SRTCP packet, a terminating UE shall use the contents of the MKI to look up the appropriate Master Key and Salt and generate the appropriate SRTCP session key and salt if it satisfies the key derivation rate criteria as specified in IETF RFC 3711 [13].

NOTE 1: Assuming members of the group or private call MCPTT UEs 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 SRTCP session key and salt every time when it receives a SRTCP packet. The key derivation rate defined in IETF RFC 3711 [13] determines the session key generation frequency. Refer to RFC3711 for more information.

A diagram of the SRTCP packet format is within figure 7.6.2-2.

Figure 7.6.2-2: SRTCP packet format showing security parameters

The length of the MKI is determined by the key distribution mechanism.