7.4 Private call key distribution
33.1793GPPRelease 13Security of Mission Critical Push To Talk (MCPTT) over LTETS
7.4.1 General
The purpose of this procedure is to allow two MCPTT UEs to create an end-to-end security context to protect an MCPTT private call. To create the security context, the initiating MCPTT UE generates a Private Call Key (PCK) and securely transfers this key, along with a key identifier (PCK-ID), to the terminating MCPTT UE.
The PCK is distributed encrypted specifically to the terminating user and signed by the initiating user. Prior to call commencement, both MCPTT UEs shall be provisioned by the KMS with time-limited key material associated with the MCPTT User. The PCK is distributed with a 32-bit Key Identifier (PCK-ID) within a MIKEY payload within the SDP content of the Private Call Request. This payload is a MIKEY-SAKKE I_MESSAGE, as defined in IETF RFC 6509 [11], which ensures the confidentiality, integrity and authenticity of the payload.
The PCK is encrypted to the user identity (UID) associated to the terminating MCPTT UE. The UID used to encrypt the data will be derived from the terminating user’s URI (e.g. sip:user.002@mcptt.example.org) and a time-related parameter (e.g. the current year and month). The terminating user’s URI is added to the recipient field (IDRr) of the message.
The payload includes the encrypted PCK and the key identifier (PCK-ID). The PCK is unique within the MCPTT system. On creating the PCK, the initiator generates a 32-bit PCK Identifier (PCK-ID). The 4 most significant bits of the PCK-ID shall indicate the purpose of the PCK is to protect Private call communications, the other 28-bits shall be randomly generated.
The payload is signed using (the KMS-provisioned key associated to) the identity of the initiating user. This identity is derived from the initiating user’s URI (e.g. sip:user.001@mcptt.example.org) and a time-related parameter (e.g. the current year and month). The initiating user’s URI is added to the initiator field (IDRi) of the message.
The security processes are summarized in figure 7.4.1-1.
Figure 7.4.1-1: Security information within a Private Call Request
Via this mechanism, PCK distribution is confidentiality protected, authenticated and integrity protected.
At the terminating MCPTT UE, the initiating user’s URI is extracted from the initiator field (IDRi) of the message. This is converted to a UID and used to check the signature on the MIKEY-SAKKE I_MESSAGE. If valid, the UE extracts and decrypts the encapsulated PCK using the (KMS-provisioned) user’s UID key. The MCPTT UE also extracts the PCK-ID. This process is shown in figure 7.4.1-2.
Figure 7.4.1-2: Processing the security content of a private call request
With the PCK successfully shared between the two MCPTT UEs, the UEs are able to use SRTP/SRTCP to create an end-to-end secure session.
NOTE: This solution is for the end-to-end protection of PCKs and does not protect the identities transmitted. These may be protected by other means.
7.4.2 Security procedures (on-network)
The security procedures provide a mechanism for establishing a security context as part of the Private Call Request sent from the initiating UE to the terminating UE. 3GPP TS 23.179 [2] contains four procedures for the commencing a MCPTT private call; manual or automatic commencement for a single or multiple MCPTT systems. As the security procedures are the same in each of these cases, the procedures below apply to each of the four procedures in 3GPP TS 23.179 [2].
The security processes for securing an on-network private call are summarized in figure 7.4.2-1. The intent of these procedures is to transfer a PCK and PCK-ID to the terminating UE.
Figure 7.4.2-1: Private Call security procedures for on-network PCK distribution
The procedure in figure 7.4.2-1 is now described step-by-step.
0. Prior to beginning this procedure it is assumed that the MCPTT UEs have an authenticated MCPTT user and that the MCPTT UEs have been provisioned with key material associated with a user’s MCPTT IDs by a MCPTT KMS as described in clause 7.2.
1. The initiating MCPTT UE generates the PCK and sends a MCPTT private call request to the terminating MCPTT UE. This message is created in Step 3 of clause 10.10.2.1.1, clause 10.10.2.1.2, clause 10.10.2.2.1 and clause 10.10.2.2.2 within 3GPP TS 23.179 [2]. The message is transferred via one or more MCPTT Servers, for example steps 3, 5, 8 of Clause 10.10.2.2.2 within 3GPP TS 23.179 [2]. Within this message is a SDP offer within which the initiating MCPTT UE includes a MIKEY-SAKKE I_MESSAGEs as defined in IETF RFC 6509 [11]. The I_MESSAGE encapsulates the PCK for the terminating MCPTT user, encrypting the key to the UID of the terminating user (derived from the user’s URI). The I_MESSAGE also contains an identifier for the PCK (PCK-ID). The I_MESSAGE is signed using (the key associated with) the initiating user’s UID.
NOTE 1: This message may be pre-generated to increase the efficiency of the communication.
NOTE 2: Optionally, the MCPTT UE may attach an additional SAKKE component which encrypts the PCK to the initiating user (in addition to the terminating user).
2. Further session signalling occurs as defined in 3GPP TS 23.179 [2].
With the PCK and PCK-ID shared between the initiating and terminating users, the media communicated between the UEs may be protected using the PCK.
7.4.3 Security procedures (off-network)
The security processes for securing an off-network private call are summarized in figure 7.4.3-1. As part of this process, the PCK and PCK-ID are securely transferred to the terminating UE.
Figure 7.4.3-1: Private Call security procedures for off-network PCK distribution
The procedure in figure 7.4.3-1 is now described step-by-step.
0. Prior to beginning this procedure the MCPTT UEs may have performed a discovery procedure. Additionally, the MCPTT UEs have been provisioned with key material associated with a user’s MCPTT IDs by a MCPTT KMS as described in clause 7.2.
1. The initiating MCPTT UE generates the PCK and sends a Call Setup Request to the terminating MCPTT UE (Step 4 of Clause 10.10.3.1 within 3GPP TS 23.179 [2]). Within this message, the initiating MCPTT UE includes a MIKEY-SAKKE I_MESSAGEs as defined in IETF RFC 6509 [11]. The I_MESSAGE encapsulates the PCK for the terminating MCPTT user, encrypting the key to the UID of the terminating user (derived from the user’s URI). The I_MESSAGE also contains an identifier for the PCK (PCK-ID). The I_MESSAGE is signed using (the key associated with) the initiating user’s UID.
NOTE 1: This message may be pre-generated to increase the efficiency of the communication.
NOTE 2: Optionally, the MCPTT UE may attached an additional SAKKE component which encrypts the PCK to the initiating user (in addition to the terminating user).
2. A Call Setup Response is returned to the initiating UE as defined in 3GPP TS 23.179 [2].
With the PCK and PCK-ID shared between the initiating and terminating users, the media communicated between the UEs may be protected using the PCK.
7.4.4 Derivation of SRTP/SRTCP master keys
As a result of this mechanism, the group members share a PCK and PCK-ID. The PCK shall be used as the MIKEY Traffic Generating Key (TGK), the PCK-ID shall be used as the MIKEY CSB ID. These shall be used to generate the SRTP Master Key and SRTP Master Salt as specified in IETF RFC 3830 [22]. The key derivation function defined in section 4.1. 3 of RFC 3830 [22] using the PRF-HMAC-SHA-256 Pseudo-Random Function as described in IETF RFC 6043 [25], section 6.1 shall be supported for generating the SRTP Master Key and Salt.
Figure 7.4.4-1: Key Derivation for media stream protection
To identify the security context from the media stream a SRTP Master Key Identifier (MKI) is required. The MKI shall be the32-bit PCK-ID which has a purpose tag of ‘1’.
When the MCPTT client is operating off network, the PCK is used to derive keys for floor and media control (SRTCP). Thus, the Master Key and Master Salt used for SRTCP is the same with the Master Key and Master Salt used for SRTP, so is the MKI.
See clause 9.4 for key derivation procedures for floor and media control (SRTCP) when the MCPTT client is operating on-network.