7.2 Private communications

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

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

7.2.1 Key management

7.2.2 Security procedures (on-network)

The following private communication 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.379 [2] describes manual and automatic commencement for private MCPTT communications in both a single MC system and across multiple MC systems, while 3GPP TS 23.281 [37] describes manual and automatic commencement for private MCVideo communications within a single MC system.

Securing of on-network private MCPTT or MCVideo communications is summarized in the following sub clauses and applies to the aforementioned MCPTT and MCVideo private call use cases.

The private call setup message used to establish these security procedures may be pre-generated to increase the efficiency of the communication. Additionally, the MC UE may attach a second SAKKE component which encrypts the PCK to the initiating user (in addition to the terminating user) for use in the ‘SAKKE-to-self’ procedure.

The security procedure for an on-network MCPTT or MCVideo private call within a single MC system is summarized in figure 7.2.2-1, The security procedure for securing an on-network MCPTT private call between multiple MC systems is summarized in figure 7.2.2-2. The intent of these on-network security procedures is to transfer a PCK and PCK-ID to the terminating UE in order to provide end-to-end security of the media.

Figure 7.2.2-1: Private call security procedure for on-network PCK distribution for single domain

The procedure in figure 7.2.2-1 is now described step-by-step.

0. Prior to beginning this procedure it is assumed that the MC UEs have an authenticated MC user and that the MC UEs have been provisioned with key material associated with a user’s MC service ID by a KMS as described in clause 5.3.

1. The initiating MC UE generates the PCK and sends a private call request to the terminating MC UE. The message is sent to the primary MC server of the initiating UE where it is forwarded to the intended receipient UE. Within this message includes an SDP offer which contains a MIKEY-SAKKE I_MESSAGEs as defined in IETF RFC 6509 [11]. The I_MESSAGE encapsulates the PCK for the terminating MC 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.

a) If the choice of initiator KMS (IDRkmsi) or receiver KMS (IDRkmsr) within the MIKEY message is unacceptable, a KMS Redirect Response may be returned to the initiating client providing KMS information. In this case, the initiating client may re-attempt the above procedures.

2. Further session signalling occurs as defined in 3GPP TS 23.379 [2] for MCPTT and 3GPP TS 23.281 [39] for MCVideo.

Figure 7.2.2-2: Private call security procedure for on-network PCK distribution between multiple domains

The procedure in figure 7.2.2-2 is now described step-by-step.

1. The initiating MC UE generates the PCK and sends a private call request addressed to the terminating MC UE. The message is first routed to the primary MC server of the initiating UE. The primary MC server routes the private call request to the partner server (home of the intended receipient UE), which is then routed to the receipient UE. The private call request message includes an SDP offer which contains a MIKEY-SAKKE I_MESSAGE as defined in IETF RFC 6509 [11]. The I_MESSAGE encapsulates the PCK for the terminating MC 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.

2. Further session signalling occurs as defined in 3GPP TS 23.379 [2].

It is possible that the terminating MC client may be represented by an MC Security Gateway (as defined in Annex L), rather than using full end-to-end security. In this case, the user’s KMS Certificate will have the ‘IsSecurityGateway’ attribute set to ‘true’ (see clause D.3.2.2). Should the terminating client be represented by an MC Security Gateway, the initiating MC client shall warn the MC user that an MC Security Gateway is in use during the private call.

With the PCK and PCK-ID shared between the initiating and terminating users, the media communicated between the UEs may be end-to-end protected using the PCK.

7.2.3 Security procedures (off-network)

3GPP TS 23.379 [2] describes manual and automatic commencement for private off-network MCPTT communications, while 3GPP TS 23.281 [37] describes manual and automatic commencement for private off-network MCVideo communications.

Securing off-network private MCPTT or MCVideo communications is summarized in the following sub clauses and applies to the aforementioned MCPTT and MCVideo off-network private call use cases.

The security procedure for securing an off-network private call is summarized in figure 7.2.3-1. As part of this process, the PCK and PCK-ID are securely transferred to the terminating UE.

Figure 7.2.3-1: Private Call security procedure for off-network PCK distribution

The procedure in figure 7.2.3-1 is now described step-by-step.

0. Prior to beginning this procedure the MC UEs may have performed a discovery procedure. Additionally, the MC UEs have been provisioned with key material associated with a user’s MC Service user IDs by a KMS as described in clause 5.3.

1. The initiating UE generates the PCK and sends a Call Setup Request to the terminating UE. Within this message, the initiating UE includes a MIKEY-SAKKE I_MESSAGEs as defined in IETF RFC 6509 [11]. The I_MESSAGE encapsulates the PCK for the terminating UE, 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.

2. A Call Setup Response is returned to the initiating UE as defined in 3GPP TS 23.379 [2] for MCPTT and as defined in TS 23.281 [37] for MCVideo.

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.2.4 First-to-answer security and key management

7.2.4.1 Overview

A ‘first-to-answer’ call as defined in clause 10.15 of TS 23.379 [2], is a call request sent to multiple users inviting them into a private call, and where the first user to answer the request is brought into the private call with the initiator while the rest of the invited users are subsequently rejected. Consequently, a specific key management solution is required.

The following defines a method for performing key distribution for a first-to-answer call. From a security point-of-view, the approach is to perform a private call key distribution from the answering client to the initiating client of the call.

The first-to-answer messages are routed over the signalling reference points. Consequently, the security mechanisms for protecting signalling between the MC Domain and the MC UE are applied to these messages. This includes the security mechanisms defined in clause 6. Where application signalling security is supported, the security mechanisms defined in clause 5.3 are used, ensuring that the user identities (MCPTT IDs) are confidentiality protected with the CSK or SPK as per clause 5.3.

7.2.4.2 First-to-answer request and response

The first-to-answer request (containing the list of target MCPTT IDs) is sent by an initiating UE to the MCPTT server. No key material is provided in the first-to-answer request.

The first-to-answer response is sent by a target UE in response to a first-to-answer request. The first-to-answer response contains both an encapsulatedPCK for the private call and a pair of MCPTT IDs corresponding to the participants (intiator and target) of the private call.

The PCK is encapsulated as defined in clause 5.6. In this case, the ‘initiating entity’ shall be the MC user who provides the first-to-answer response. The initiating entity URI shall be the MC Service user ID of the user who made the first-to-answer response. The receiving entity shall be the MC user who made the first-to-answer request. The receiving entity URI shall be the MC Service user ID of the user who made the first-to-answer request.

7.2.4.3 First-to-answer call setup with security

Figure 7.2.4.3-1 below illustrates the first-to-answer call setup procedure with security.

Figure 7.2.4.3-1: First-to-answer call setup and key management

1 to 6. First-to-answer call signalling occurs as defined in TS 23.379 [2]. These messages do not contain security-related key material.

7. MCPTT user at MCPTT client 2 accepts the call, which causes the MCPTT client 2 to send a first-to-answer call response to the MCPTT server. Included in the response, is the PCK (PCK_1) encapsulated to the user associated with the initiating client, MCPTT client 1. The PCK is then included in the SDP content of the response.

NOTE 1: If the choice of initiator KMS (IDRkmsi) or receiver KMS (IDRkmsr) within the MIKEY message is unacceptable, a KMS Redirect Response may be returned to the responding client providing KMS information. In this case, the responding client may re-attempt the above procedures.

8. The MCPTT server forwards the first-to-answer call response to MCPTT client 1 indicating that the MCPTT user at MCPTT client 2 has accepted the call. MCPTT client 1 extracts the PCK from the message.

9. The media plane for communication is now established and protected with the shared PCK.

10. MCPTT user at MCPTT client 3 accepts the call and sends a first-to-answer call response to the MCPTT server. MCPTT client 3 also includes an encapsulated PCK (PCK_2) in the response.

11. Since the first-to-answer call response from MCPTT client 2 has already been accepted, the MCPTT server sends a MCPTT first-to-answer call cancel request to MCPTT client 3. The encapsulated PCK provided by MCPTT client 3 (PCK_2) is discarded.

12-16. First-to-answer call signalling occurs as defined in TS 23.379 [2]. These messages do not contain security-related key material.

7.2.4.4 First-to-answer media protection

The first-to-answer media plane shall be protected as for a private call. Clause 7.4.1 is applied to convert the PCK into the SRTP Master Key/Salt, and clause 7.5 is applied for the protection of the first-to-answer media.

7.2.5 Ambient listening call

Ambient listening is a required feature for public safety users. Where the MC client may be used by non-public safety users, the feature shall not be implemented on the MC client and it shall not be possible to enable its use.

Ambient listening is described in clause 10.14 of 23.379 [2] and allows an authorised user to establish a “listening” private voice call with a target user without an indication that the communication is taking place. There are two types of ambient listening; the first type consists of the authorised user “listening” to a target user and the second type consists of the authorised user transmitting to a target user. Both types are intiated by the authorised user.

The MCPTT server provides the control and authorisation verification associated with an ambient listening call.

The security for an ambient listening call is established similar to that of a secure private call, i.e. a PCK is created for the session and provided securely in the ambient listening call request from the authorised user to the target user as per clause 7.2.2 for on-network private calls and clause 7.2.3 for off-network private calls.

When required by the MCX operator, sensitive application signalling parameters (e.g. MCPTT IDs) shall be protected as described in clause 9.3.

The media plane for ambient listening shall be protected as for a private call using a PCK. Clause 7.4.1 is applied to convert the PCK into the SRTP Master Key/Salt, and clause 7.5 is applied for the protection of the ambient listening media.

Floor control signalling for an ambient listening call shall be protected as described in clause 9.4.

7.2.6 Ambient viewing call

Ambient viewing is a required feature for public safety users. Where the MC client may be used by non-public safety users, the feature shall not be implemented on the MC client and it shall not be possible to enable its use.

Ambient viewing is described in clause 7.6 of 23.281 [37] and allows an authorised user to establish a “viewing” private video call with a target user without an indication that the communication is taking place. There are two types of ambient viewing; the first type consists of the authorised user “viewing” to a target user and the second type consists of the authorised user transmitting or “viewing to” a target user. Both types are intiated by the authorised user.

The MCVideo server provides the control and authorisation verification associated with an ambient viewing call.

The security for an ambient vewing communication is established similar to that of a secure private video communication, i.e. a PCK is created for the session and provided securely in the ambient viewing call request from the authorised user to the target user as per clause 7.2.2 for on-network private video communications and clause 7.2.3 for off-network video private communications.

When required by the MCX operator, sensitive application signalling parameters (e.g. MCPTT IDs) shall be protected as described in clause 9.3.

The media plane for ambient viewing shall be protected as for a private video communication using a PCK. Clause 7.4.1 is applied to convert the PCK into the SRTP Master Key/Salt, and clause 7.5 is applied for the protection of the ambient viewing media.

Transmission control signalling for an ambient viewing communication shall be protected as described in clause 9.4.

7.2.7 Private video pull

7.2.7.1 One-to-one video pull

One-to-one video pull is described in clause 7.3.2.3 of 23.281 [37] and consists of a private unidirectional video transmission from the called party to the calling party. Off-network video pull (video pull to self) is described in clause 7.3.3 of 23.281 [37].

The security for a one-to-one video pull communication is established similar to that of a secure private video call, i.e. a PCK is created for the session and provided securely in the Private call request from the calling user to the called user as per clause 7.2.2 for on-network private calls and clause 7.2.3 for off-network (video pull to self) calls.

When required by the MCX operator, sensitive application signalling parameters (e.g. MCVideo IDs) shall be protected as described in clause 9.3.

The media plane for one-to-one video pull shall be protected as for a private video call using a PCK. Clause 7.4.1 is applied to convert the PCK into the SRTP Master Key/Salt, and clause 7.5 is applied for the protection of the video media.

Trnasmission control signalling for a one-to-one video pull communication shall be protected as described in clause 9.4, while transmission control signalling for off-network video pull to self communications shall be protected as described in clause 9.4.4.

7.2.7.2 One-from-server video pull

One-from-server video pull is described in clause 7.3.2.4 of 23.281 [37] and consists of a private unidirectional video transmission pulled by the calling party from the MCVideo server. Figure 7.2.7.2-1 shows the messaging for a one-from-server video pull.

Figure 7.2.7.2-1 – One-from-server video pull

The security for a one-from-server video pull communication is established similar to that of a secure private video call, i.e. a PCK is created for the session and provided securely in the MCVideo pull from server request sent from the MCVideo client to the MCVideo server. Clause 7.2.2 applies for on-network one-from-server video commnications. Note that the PCK shall be encrypted to the identity of the MCVideo server rather than to that of another MCVideo user.

Off-network operation is not supported for one-from-server video pull communications.

When required by the MCX operator, sensitive application signalling parameters (e.g. MCVideo IDs) shall be protected as described in clause 9.3.

The media plane for one-to-one video pull shall be protected as for a private call using a PCK. Clause 7.4.1 is applied to convert the PCK into the SRTP Master Key/Salt, and clause 7.5 is applied for the protection of the video media.

Transmission control signalling for a one-from-server video pull communication shall be protected as described in clause 9.4.

7.2.8 Private video push

7.2.8.1 One-to-one video push

One-to-one video push is described in clause 7.4.2.3 of 23.281 [37] and consists of a private unidirectional video transmission from the calling party to the called party. Off-network video push to another MCVideo user is described in clause 7.4.3.3 of 23.281 [37].

The security for a one-to-one video push communication is established similar to that of a secure private video call, i.e. a PCK is created for the session and provided securely in the Private call request from the calling user to the called user as per clause 7.2.2 for on-network private calls and clause 7.2.3 for off-network private calls.

When required by the MCX operator, sensitive application signalling parameters (e.g. MCVideo IDs) shall be protected as described in clause 9.3.

Transmission control signalling for a one-to-one video push communication shall be protected as described in clause 9.4, while transmission control signalling for off-network video push to another MCVideo user communications shall be protected as described in clause 9.4.4.

7.2.8.2 One-to-server video push

One-to-server video push is described in clause 7.4.2.4 of 23.281 [37] and consists of a private unidirectional video transmission pushed from the calling party to the MCVideo server. Figure 7.2.8.2-1 shows the messaging for a one-from-server video push.

Figure 7.2.8.2-1 – One-to-server video push

The security for a one-to-server video push communication is established similar to that of a secure private video call (i.e. a PCK is created for the session and provided securely in the MCVideo push to server request sent from the MCVideo client to the MCVideo server). Clause 7.2.2 applies for on-network one-to-server video communications. Note this requires that the PCK shall be encrypted to the identity of the MCVideo server rather than to that of another MCVideo user.

Off-network operation is not supported for one-to-server video push communications.

When required by the MCX operator, sensitive application signalling parameters (e.g. MCVideo IDs) shall be protected as described in clause 9.3.

The media plane for one-to-server video push shall be protected as for a private call using a PCK. Clause 7.4.1 is applied to convert the PCK into the SRTP Master Key/Salt, and clause 7.5 is applied for the protection of the video media.

Transmission control signalling for a one-to-server video push communication shall be protected as described in clause 9.4.

7.2.8.3 Remotely initiated video push

On-network remotely intiated video push is described in clause 7.4.2.5 of 23.281 [37] and consists of an authorised MCVideo user initiating a private unidirectional video transmission from a source MCVideo user and a destination MCVideo user.

Off-network remotely initiated video push is described in clause 7.4.3.4 of 23.281 [37] and consists of an authorised MCVideo user initiating a private unidirectional video transmission from a source MCVideo user to a destination MCVideo user without the MCVideo serving the call setup and media transmission.

Figure 7.2.8.3-1 shows the messaging for an on-network remotely initiated video push communication.

Figure 7.2.8.3-1: On-network remotely initiated video push

The security context for an on-network remotely initiated video push communication is established during step 4 of figure 7.2.8.3-1 between MCVideo client 1 and MCVideo client 2 and is similar to that of a secure private video call, i.e. a PCK is created for the session and provided securely in the Private communication request from MCVideo client 1 to MCVideo client 2 as described in clause 7.2.2.

In figure 7.2.8.3-2, the remote video push request message from MCVideo client 3 does not establish a security context for the call; however it does provide the MCVideo IDs of participating MCVideo client 1 and MCVideo client 2.

Figure 7.2.8.3-2 shows the messaging for an off-network remotely initiated video push communication.

Figure 7.2.8.3-2: Off-network remotely initiated video push

The security context for an off-network remotely initiated video push communication is established during step 3 of figure 7.2.8.3-2 between MCVideo client B and MCVideo client C and is similar to that of a off-network secure private video call, i.e a PCK is created for the session and provided securely as described in clause 7.2.3.

In figure 7.2.8.3-2, the remote video push request message from MCVideo client A does not establish a security context for the call; however it does provide the MCVideo IDs of participating MCVideo client B and MCVideo client C.

When required by the MCX operator, sensitive application signalling parameters (e.g. MCVideo IDs) shall be protected as described in clause 9.3 for both on-network and off-network operation.

For both on-network and off-network, the media plane for a remotely initiated video push communication shall be protected as for a one-to-one video push communication using a PCK. Clause 7.4.1 is applied to convert the PCK into the SRTP Master Key/Salt, and clause 7.5 is applied for the protection of the video media.

Transmission control signalling for a remotely initiated video push communication shall be protected as for a one-to-one video push communication, as described in clause 9.4, while transmission control signalling for off-network remotely initiated video push communications shall be protected as described in clause 9.4.4.