7.3 Group communications

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

7.3.1 General

To support MCPTT and MCVideo group communications, group security procedures are used to establish and distribute keys to the members of predefined or dynamically defined groups.

Key material (GMK and GMK-ID) for a predefined group is created and distributed by the GMS to the members of the group via the common key distribution mechanisms defined in clause 5.7.

Key material for dynamically created groups is created and distributed by the GMS to the members of the group via the security mechanisms defined in the following sub clauses.

NOTE: Void

7.3.2 Group creation security procedure

The group creation procedure is described in clause 10.2.3 of 3GPP TS 23.280 [36] and applies to the MCPTT scenario of normal group creation by an MC administrator and user regrouping operations by an authorized user/dispatcher. To establish the security context for the group, the GMS follows the procedures in clause 5.7 to create a new GMK and GMK-ID.

The encapsulated GMK and GUK-ID is sent to group members by the GMS within a notification message (step 4 in clause 10.2.3 of 3GPP TS 23.280 [36]). The procedure is equivalent to that described in clause 5.7 of this specification.

7.3.3 Dynamic group keying

7.3.3.1 General

In the GMK distribution procedures described in this clause, the GMS shall be provisioned with the same information as any MC UE by the KMS as described in clause 5.3; the only distinguishing feature is that the GMS’s identity is a Server URI rather than an MC Service ID.

NOTE 1: Void.

In addition to authorisation, the only information the GMS requires to create the group are the MCPTT IDs of the group members. These two features combined allow groups to be created and keyed at any time, by any authorized entity.

Such flexibility is required to support a number of MCPTT group procedures within 3GPP TS 23.280 [36].

NOTE 2: The dynamic group keying mechanisms may not support off-network scenarios.

7.3.3.2 Group regrouping security procedure (within a single MC domain)

Group Regroup procedures for the MC system are described in clause 10.2.4.1 of 3GPP TS 23.280 [36]. To create the security context for the temporary group, the GMS follows the procedures in clause 5.7, creating a new GMK and GMK-ID for the temporary group.

An encapsulated GMK and GUK-ID is sent to the temporary group members by the GMS within a notification message (step 5 in clause 10.2.4.1 of 3GPP TS 23.280 [36]). The procedure is equivalent to that described in clause 5.7.

7.3.3.3 Group regrouping security procedure (involving multiple MC domains)

The MCPTT group regroup security procedure (shown below in figure 7.3.3.3-1) involves multiple MC users from multiple MC domains and is an integrated component of the MCPTT group regrouping procedure described in clause 10.2.4.2 of 3GPP TS 23.280 [36].

Figure 7.3.3.3-1: Group regroup security procedure (multiple MC domains)

Prior to beginning the procedure, the MC UEs, primary GMS and partner GMS are provisioned by a KMS as described in clause 5.3.

1-5: These steps are as defined in clause 10.2.4.2 of 3GPP TS 23.280 [36].

6: To create the security context for the temporary group, the primary GMS creates a new GMK and GMK-ID for the temporary group along with other group related information.

7,8: The primary GMS notifies the partner GMS of the group regroup operation. The primary GMS includes a Group Key Transport payload following the procedures in clause 5.7, treating the partner GMS as another user within the group. Accordingly, the payload encrypts the new GMK to the identity of the partner GMS and is signed using the identity of the primary GMS. The GUK-ID is derived using the User Salt generated from the partner GMS’s URI.

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 primary GMS providing KMS information. In this case, the primary GMS may re-attempt the above procedures.

9,10: These steps are as defined in clause 10.2.4.2 of 3GPP TS 23.280 [36].

11: The partner GMS extracts the GMK and GMK-ID from the notification. The partner GMS then notifies the affiliated users within the partner MC domain. The partner GMS re-encrypts the GMK to the identity of the affiliated users in the partner system, generates new GUK-IDs for each user and signs using its identity (the identity of the partner GMS) following the procedure in clause 5.7.

12,13: These steps are as defined in clause 10.2.4.2 of 3GPP TS 23.280 [36].

14: The primary GMS notifies the affiliated users within its own MC domain. The primary GMS includes a Group Key Transport payload including a GMK and GUK-ID following the procedures in clause 5.7. The GMK is encrypted to the identity of the MC user and is signed using the identity of the primary GMS.

15: This step is as defined in clause 10.2.4.2 of 3GPP TS 23.280 [36].

It is possible that a partner GMS 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 partner GMS’s KMS Certificate will have the ‘IsSecurityGateway’ attribute set to ‘true’ (see clause D.3.2.2). Should a partner GMS be represented by an MC Security Gateway, the primary GMS shall indicate to all group users and partner GMS(s) that the GMK is shared with an MC Security Gateway. This is achieved by setting the ‘Security Gateway’ bit in the ‘Status’ field of the GMK’s key parameters (see clause E.6.9).

7.3.4 Broadcast group call

Broadcast group call is described in clause 10.6.2.5.2 of 23.379 [2] and consists of a group transmission where the initiating user expects no response from the other group members. When the initiating user’s transmission is complete, the broadcast group communication ends.

The security context for a broadcast group communication is established similar to that of a secure group communication where the GMK associated to the broadcast group shall be converted into the SRTP Master Key/Salt per clause 7.4.2. Clause 7.5 shall be applied to establish protection of the broadcast group media.

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

Floor control signalling for on-network broadcast group communications shall be protected as described in clause 9.4.6 while floor control signalling for off-network broadcast group communications shall be protected as described in clause 7.4.2.

7.3.5 Group-broadcast group call

Group-broadcast group call is described in clause 10.6.2.5.2.1 of 23.379 [2] and consists of a group transmission to a set of groups rather than to a set of users. Like a broadcast group communication, the initiating user expects no response from the target groups. When the initiating user’s transmission is complete, the group-broadcast group communication ends.

The security context for a group-broadcast group communication is similar to that of a secure group communication, i.e. the group-broadcast group ID is predefined and assigned a GMK. The GMK associated to the group-broadcast group shall be converted into the SRTP Master Key/Salt per clause 7.4.2. Clause 7.5 shall be applied to establish protection of the group-broadcast group media.

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

Floor control signalling for on-network group-broadcast group communications shall be protected as described in clause 9.4.6 while floor control signalling for off-network group-broadcast group communications shall be protected as described in clause 7.4.2.

7.3.6 Emergency group call

An emergency group call is described in clause 10.6.2.6.1 of 23.379 [2] and consists of a group communication where the priority of the transmission or group is set to an emergency status. An existing group call may be elevated to an emergency status or a separate designated emergency group may be used.

When an existing group call is elevated to emergency status, there should be no change to the ongoing security context for that group. Media protection, floor control protection, and application signalling protection continue to use the existing keys and mechanisms that were in place prior to elevating the group to emergency status. However, the call may be downgraded to clear to ensure the emergency group call is setup by the MCX system.

When a designated emergency group is used and the user intiates an emergency call, the emergency group is established and a new security context set up shall be attempted (assuming the emergency group is not already active). If the security context setup is successful the emergency group call shall proceed with security, otherwise based on MCX operator policy the call may default to unencrypted.

For either existing or designated call types, a secured emergency group call uses group communication mechanisms where a GMK associated with the emergency group is distributed to the affiliated members per clause 5.7. The GMK is used to encrypt the media for on-network and off-network, unicast or multicast, emergency group communications. The GMK shall be converted into the SRTP master key and master salt as described in clause 7.4.2 and the emergency group media shall be encrypted using the SRTP master key and master salt as defined in clause 7.5.1.

For either existing or designated call types, floor control signalling for a on-network and off-network secured emergency group communication shall be protected as described in clause 9.4.

For either existing or designated call types, when required by the MCX service provider, sensitive application signalling parameters (e.g. MCX Service User IDs and MCX Group IDs) shall be protected as described in clause 9.3.

7.3.7 Imminent peril group call

An imminent peril group call is described in clause 10.6.2.6.2 of 23.379 [2] and consists of a group communication where the priority of the transmission is elevated to imminent peril status. The imminent peril transmission may be sent within an existing group call or alternatively a separate designated imminent peril group may be used.

When an imminent peril transmission is sent on an existing group call, there should be no change to the ongoing security context for that group. Media protection, floor control protection, and application signalling protection continue to use the existing keys and mechanisms that were in place prior to the imminent peril transmission. However, the call may be downgraded to clear to ensure the emergency alert is setup by the MCX system.

When a designated imminent peril group is used and the user initiates an imminent peril transmission, the imminent peril group is established and a new security context set up shall be attempted (assuming the imminent peril group is not already active). If the security context setup is successful the imminent peril group call shall proceed with security, otherwise based on MCX operator policy the call may be downgraded to unencrypted.

For either existing or designated call types, a secured imminent peril group call uses group communication mechanisms where a GMK associated with the existing or imminent peril group is distributed to the affiliated members per clause 5.7. The GMK is subsequently used to encrypt the media for on-network and off-network, unicast or multicast, imminent peril group communications. The GMK shall be converted into the SRTP master key and master salt as described in clause 7.4.2 and the imminent peril group media shall be encrypted using the SRTP master key and master salt as defined in clause 7.5.1.

For either existing or designated call types, floor control signalling for an on-network and off-network secured imminent peril group communication shall be protected as described in clause 9.4.

For either existing or designated call types, when required by the MCX service provider, sensitive application signalling parameters (e.g. MCX Service User IDs and MCX Group IDs) shall be protected as described in clause 9.3.

7.3.8 Emergency Alert

An emergency alert is described in clause 10.6.2.6.3 of 23.379 [2] and consists of a group communication where at least one user has issued an emergency alert indication, elevating that user to an emergency state. A transmission by a user while in the emergency state has elevated priority and may be sent within an existing group call or alternatively a separate designated emergency group.When an existing group call is used as the emergency group, there should be no change to the ongoing security context for that group. Media protection, floor control protection, and application signalling protection continue to use the existing keys and mechanisms that were in place prior to the emergency alert. However, the call may be downgraded to clear to ensure the emergency alert is setup by the MCX system

When a designated emergency group is used and the user intiates an emergency alert and transmission, the assigned emergency group is established and a new security context set up is attempted (assuming the emergency group is not already active). If the security context setup is successful, the imminent peril group call shall proceed with security, otherwise based on MCX operator policy the call may default to unencrypted.

For either existing or designated call types, a secured emergency alert issued emergency group call uses group communication mechanisms where a GMK associated with the emergency group is distributed to the affiliated members per clause 5.7. The GMK is used to encrypt the media for on-network and off-network, unicast or multicast, emergency group communications. The GMK shall be converted into the SRTP master key and master salt as described in clause 7.4.2 and the emergency group media shall be encrypted using the SRTP master key and master salt as defined in clause 7.5.1.

For either existing or designated call types, floor control signalling for an on-network and off-network secured emergency group communication shall be protected as described in clause 9.4.

For either existing or designated call types, when required by the MCX service provider, sensitive application signalling parameters (e.g. MCX Service User IDs and MCX Group IDs) shall be protected as described in clause 9.3.

7.3.9 Remotely initiated video push to group

On-network remotely intiated video push to group is described in clause 7.4.2.6 of 23.281 [37] and consists of an authorised MCVideo user initiating a broadcast video transmission sourced from a second MCVideo user.

Off-network remotely initiated video push to a group is described in clause 7.4.3.5 of 23.281 [37] and consists of an authorised MCVideo user initiating a broadcast video transmission sourced from a second MCVideo user without the MCVideo serving the call setup and media transmission.

Figure 7.3.11.1-1 shows the messaging for on-network remotely initiated video push to group communication.

Figure 7.3.11.1-1: On-network remotely initiated video push to group

The security context for an on-network remotely initiated video push to group communication is established in step 4 of figure 7.3.11.1-1 by the target MCVideo user (MCVideo client 2) similar to that of a secure group broadcast communication where a GMK associated to the broadcast group shall be converted into the SRTP Master Key/Salt per clause 7.4.2. Clause 7.5 shall be applied to establish protection of the broadcast group media.

In figure 7.3.11.1-1, the remote video push request message does not establish a security context for the broadcast call but does however provide the group ID for the broadcast group.

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

Figure 7.3.11.1-2: Off-network remotely initiated video push to group

The security context for an off-network remotely initiated video push to group communication is established in step 3 of figure 7.3.11.1-2 by the target MCVideo user (MCVideo client B) similar to that of a secure group broadcast communication where a GMK associated to the broadcast group shall be converted into the SRTP Master Key/Salt per clause 7.4.2. Clause 7.5 shall be applied to establish protection of the broadcast group media.

In figure 7.3.11.1-2, the remote video push request message from MCVideo client A does not establish a security context for the broadcast call but does however provide the group ID for the broadcast group.

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

Transmission control signalling for on-network remotely initiated video push to group communications shall be protected as described in clause 9.4.6 while transmission control signalling for off-network remotely initiated video push to group communications shall be protected as described in clause 7.4.2.

7.3.10 Multi-talker configured MCPTT group

The requirements of the multi-talker feature for mission critical communications are defined in 22.179 [3] and may occur as part of multi-talker configured MCPTT group communications as decribed in 23.379 [2]. In a multi-talker configured MCPTT group communication, more than one media stream may be mixed together and simultaneously heard by a call participant.

When media protection is applied, the GMK assigned to the multi-talker configured MCPTT group is used to protect the group media as described in clauses 7.4.2 and 7.5, however because the controlling MCPTT server cannot decrypt the media streams (as it does not possess the GMK of the group), the controlling MCPTT server is therefore unable to mix media streams together prior to dissemination of the media to the members of the group. In this case, all protected and active media streams for the multi-talker configured group call shall be sent by the controlling MCPTT server to the participating MC UEs where each participating MC UE shall decrypt the received media streams. Once the media streams have been decrypted by the MC UE, the media may be mixed and presented to the user.

If media protection is not applied then the multi-talker configured group media shall be mixed and provided to the participating MC UEs as indicated in 23.379 [2].

When MC signaling protection is enabled, unicast delivery of signalling messages applicable to multi-talker configured MCPTT group communications shall be protected as defined in clause 9.4.2 and multicast delivery of these signaling messages shall be protected as defined in clause 9.4.3.

7.3.11 Group regroup with preconfigured group

Group regroup with preconfigured group is defined in TS 23.379 [2] and TS 23.280 [36]. The basis of this feature is to allow an authorized MC user to dynamically create a temporary group consisting of a set of predefined groups (i.e. the affiliated members of the predefined groups become members of this new regroup group). For common group configuration and security, the group regroup with preconfigured group uses a group that is common to all the invited users. TS 23.379 [2] and TS 23.280 [36] refer to this common group as a preconfigured group. All users invited to join a secure group regroup with preconfigured group call shall be members of the indicated preconfigured group and shall have obtained the preconfigured group configuration and GMK.

Security for group regroup with preconfigured group follows typical group security establishment procedures using the GMK and GMK-ID obtained through the preconfigured group configuration. The group configuration to be used (i.e. the GMK and GMK-ID) is identified in the initial preconfigured regroup request message. The GMK and the GMK-ID from the identified preconfigured group shall be used to derive the master key and master salt as described in clause 7.4.2 and used to secure the media as described in clause 7.5.

7.3.12 User regroup with preconfigured group

User regroup with preconfigured group is defined in TS 23.379 [2] and TS 23.280 [36]. The basis of this feature is to allow an authorized MC user to dynamically create a temporary group consisting of a specified set of users (i.e. the users identified in the user regroup become members of this new temporary group). For common group configuration and security, the user regroup with preconfigured group uses a group that is common to all the invited users. TS 23.379 [2] and TS 23.280 [36] refer to this common group as a preconfigured group. All users invited into a secure user regroup with preconfigured group call shall be members of the indicated preconfigured group and shall have obtained the preconfigured group configuration and GMK.

Security for user regroup with preconfigured group follows typical group security establishment procedures using the GMK and GMK-ID obtained through a preconfigured group configuration. The group configuration to be used (i.e. the GMK and GMK-ID) is identified in the initial preconfigured regroup request message. The GMK and the GMK-ID from the identified preconfigured group shall be used to derive the master key and master salt as described in clause 7.4.2 and used to secure the media as described in clause 7.5.