7.3 Group call key distribution

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

7.3.1 General

To create the group’s security association, a Group Master Key (GMK) and associated identifier (GMK-ID) is distributed to MCPTT UEs by a Group Management Server (GMS). The GMK is distributed encrypted specifically to a user and signed using an identity representing the Group Management Server. Prior to group key distribution, each MCPTT UE within the group shall be provisioned by the MCPTT Key Management Server (KMS) with time-limited key material associated with the MCPTT User as described in clause 7.2. The Group Management Server shall also be provisioned by the MCPTT KMS with key material for an identity which is authorized to create groups.

The GMK is distributed within a Group Key Transport payload. 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 GMK is distributed with a 32-bit Group User Key Identifier (GUK-ID). The GUK-ID is generated from the GMK-ID and a User Salt derived from the user’s MCPTT ID.

The GMK is encrypted to the user identity (UID) associated to the MCPTT UE. The UID used to encrypt the data will be derived from the user’s MCPTT ID and a time stamp as described in clause 7.2. The user’s MCPTT ID is added to the recipient field (IDRr) of the message.

The Group Key Transport payload is signed using (the KMS-provisioned key associated to) the identity of the Group Management Server (GMS). This identity is derived from the GMS’s URI (e.g. sip:gp.manager@mcptt.example.org) and a time stamp. The GMS’s URI is added to the initiator field (IDRi) of the message.

The GMK is provided together with an activation time, which is the time from which the key should be used for transmission of group communications, replacing previous keys assigned to that group; the group identity for confirmation of the association of the GMK to the group; and an optional text payload which may be used to provide user-readable text. These associated parameters are encrypted by the GMK and carried in the MIKEY-SAKKE I_Message in the group key transport payload.

The security processes are summarized in figure 7.3.1-1 and further detailed below.

Figure 7.3.1-1: Generation of a group key transport message (encapsulation of GMK)

At the MCPTT UE, the GMS’s URI is extracted from the initiator field (IDRi) of the message. Along with the time, this is used to check the signature on the Group Key Transport message. If valid, the UE extracts and decrypts the encapsulated GMK using the (KMS-provisioned) user’s UID key. The MCPTT UE also extracts GUK-ID and xors the GUK-ID and User Salt together to extract the GMK-ID. If the Status field in the GMK parameters indicate the GMK has been revoked, the GMK and GMK-ID shall not be used.

The extraction procedure is described in figure 7.3.1-2.

Figure 7.3.1-2: Processing of a group key transport message (extraction of GMK)

Following successful extraction of the GMK, the MCPTT UE decrypts and extracts the MCPTT group ID carried in the encapsulated associated parameters payload. The MCPTT UE stores the GMK together with the group identity, activation time and optional text field. If the decryption process for the encapsulated associated parameters fails, the GMK is rejected.

The Group Key Transport payload includes the Group User Key Identifier (GUK-ID) within the CSB-ID field. The GMK is unique within the MCPTT system and is identified by a GMK Identifier (GMK-ID) from which the GUK-ID is derived. On creating the GMK, the Group Manager generates a GMK-ID as follows. The 4 most significant bits of the GMK-ID is the ‘purpose tag’ which defines the purpose of the GMK. The 28 least significant bits of the GMK-ID is a 28-bit randomly-generated value.

For each user, the GMS creates a 28-bit User Salt by hashing the user’s MCPTT ID through a KDF using the GMK as the key as defined in clause F.1.3. The User Salt is xor’d with the 28 least-significant bits of the GMK-ID to create the 32‑bit GUK-ID. The process for generating the GUK-ID is summarized in figure 7.3.1-3.

Figure 7.3.1-3: Generating the GUK-ID

The GUK-ID is placed in the CSB ID field within the header of the I_MESSAGE.

NOTE: Knowledge of the GUK-ID, GMK-ID and User Salt does not reveal the MCPTT ID to receivers without the GMK for the group.

7.3.2 Security procedures for GMK provisioning

This procedure distributes a MIKEY payload from the GMS to MCPTT UEs within the group. The payload is transported as part of the ‘Notify group configuration request’ message defined in clause 10.1.5.3 of 3GPP TS 23.179 [2].

Figure 7.3.2-1 shows the security procedures for creating a security association for a group.

Figure 7.3.2-1: Security configuration for groups

A description of the procedures depicted in figure 7.3.2-1 follows. For clarity, step 1 corresponds to step 2 in figure 10.1.5.3-2 of clause 10.1.5.3 of 3GPP TS 23.179 [2].

0) Prior to beginning this procedure the MCPPT client shall be provisioned with identity-specific key material by a MCPTT KMS as described in clause 7.2. The GMS shall also be securely provisioned with identity-specific key material for an identity that is authorized to create groups.

1) The GMS shall send a MIKEY payload to MCPTT clients within the group within a ‘Notify group configuration request’ message. The message shall encapsulate a GMK for the group. The payload shall be encrypted to the user identity (MCPTT ID) associated to the MCPTT client and shall be signed by the GMS. The message shall also provide the GUK-ID. Parameters associated with the GMK shall be encrypted using the GMK, and sent in the MIKEY payload together with the encapsulated GMK. This process is shown in Figure 7.1.1-1.

2) On receipt of a MIKEY message, the MCPTT client shall check the signature on the payload, verify that the GMS is authorized to create groups, extract the GMK, GUK-ID and GMK-ID and check that the GMK-ID is not a duplicate for an existing GMK. The MCPTT client shall also extract the group identity, activation time and text from the encapsulated associated parameters in the payload using the GMK, and check that decryption is successful. This process is shown in Figure 7.1.1-2.Should any of these checks fail, an error shall be returned to the GMS. Upon successful receipt and processing, the MCPTT UE shall store the GMK, GMK-ID and GUK-ID and respond to the GMS with a ‘Notify group configuration response’ message.

Where multicast floor control is required on the downlink from the MCPTT Server to the MCPTT client, the procedure may be performed twice, once for obtaining a GMK for the protection of media, and once for obtaining a different key for the protection of multicast floor control, the Multicast Floor Control Key (MKFC). Alternatively, the GMS may distribute the two different keys (GMK, MKFC) in one procedure by embedding the two MIKEY payloads in the message. The MKFC shall be treated as a GMK for transport, using the security procedures defined in clause 7.3.1 and being encapsulated as defined in Annex E.2.

To revoke a security context, the group management server repeats the above steps with the Status field of the GMK parameters indicating that the GMK has been revoked.

7.3.3 Key Identification and purpose tags

The ‘purpose tag’ within the key identifier (e.g. GMK-ID) shall be the most significant four bits of the key and shall be used to indicate the use of the key.

– 0: the GMK shall be used for group communications.

– 1: the PCK shall be used to protect Private Call communications.

– 2: the CSK shall be used to protect application signalling (XML and SRTCP) between the MCPTT client and MCPTT domain.

– 3: the SPK shall be used to protect application signalling (XML and SRTCP) between servers in MCPTT domain(s).

– 4: The MKFC shall be used to protect multicast floor control signalling from the MCPTT Server to MCPTT clients.

– 5: The MSCCK shall be used to protect MBMS subchannel control messages from the MCPTT Server to MCPTT clients.

– 6-15: not defined.

In this way, the MCPTT UE is able to identify the purpose of the key.

7.3.4 Group creation procedure

Group creation procedure is described in clause 10.4.3 of 3GPP TS 23.179 [2]. To create the security context for the group, the GMS follows the procedures in clause 7.3.1, creating a new GMK and GMK-ID for the temporary group.

An encapsulated GMK and GUK-ID is sent to group members by the GMS within a notification message (step 4 within clause 10.4.3 of 3GPP TS 23.179 [2]). The procedure is equivalent to that described in clause 7.3.2.

7.3.5 Dynamic group keying

7.3.5.1 General

In the GMK distribution procedures described in this clause, the GMS is provisioned with the same information as any MCPTT UE by the KMS as described in clause 7.2; the only distinguishing feature is that the GMS’s identity is authorized to create groups.

NOTE: This authorization could be conveyed within the identity itself. For example, via a specific string within the URI such as ‘group’. For example, the identity sip:user.001.group@mcptt.example.org may be authorized to create a group, whereas sip:user.001@mcptt.example.org may not.

Additionally, 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 group procedures within 3GPP TS 23.179 [2].

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

7.3.5.2 Group regrouping procedures (within a single MCPTT system)

Group Regroup procedures are described in clause 10.6.2.1 of 3GPP TS 23.179 [2]. To create the security context for the temporary group, the GMS follows the procedures in clause 7.3.1, creating a new GMK and GMK-ID for the temporary group.

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

7.3.5.3 Group regrouping procedures (involving multiple MCPTT systems)

Group Regroup procedures involving multiple MCPTT systems are described in clause 10.6.2.2 of 3GPP TS 23.179 [2]. figure 7.3.5.3-1.

Figure 7.3.5.3-1: Group Regroup security procedures (multiple MCPTT systems)

0) Prior to beginning the procedure, the MCPTT UEs, primary GMS and partner GMSare provisioned by a KMS as described in clause 7.2.

1) To create the security context for the temporary group, the primary GMS creates a new GMK and GMK-ID for the temporary group. The primary GMS notifies the affiliated users within its own MCPTT system (Step 8 of clause 10.6.2.2 in 3GPP TS 23.179 [2]). Within this message, the primary GMS includes a Group Key Transport payload including a GMK and GUK-ID following the procedures in clause 7.3.1. The GMK is encrypted to the identity of the MCPTT user and is signed using the identity of the primary GMS.

2) The MCPTT UEs acknowledge the notification.

3) The primary GMS then notifies the partner GMS of the group regroup operation (Step 9 of clause 10.6.2.2 in 3GPP TS 23.179 [2]). Within this message, the primary GMS includes a Group Key Transport payload following the procedures in clause 7.3.1, 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.

4) The partner GMS extracts the GMK and GMK-ID from the notification. The partner GMS then notifies the affiliated users within the partner MCPTT system (Step 11 of clause 10.6.2.2 in 3GPP TS 23.179 [2]). 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 7.3.1.

5) The partner MCPTT UEs acknowledge the notification.

6) The partner GMS acknowledges the notification to the primary GMS.

Where multicast floor control is required on the downlink from the MCPTT Server to the MCPTT client, the procedure may be performed twice, once for obtaining a GMK for the protection of media, and once for obtaining a different key for the protection of multicast floor control, the Multicast Floor Control Key (MKFC). Alternatively, the GMS may distribute the two different keys (GMK, MKFC) in one procedure by embedding the two MIKEY payloads in the message. The MKFC shall be treated as a GMK for transport, using the security procedures defined in clause 7.3.1 and being encapsulated as defined in Annex E.2. For transport, the GMK-ID shall be the MKFC-ID and an all-zero user salt shall be used such that that GUK-ID is also the MKFC-ID.

7.3.6 Derivation of SRTP/SRTCP master keys

As a result of this mechanism, the group members share a GMK and GUK-ID. The GMK shall be used as the MIKEY Traffic Generating Key (TGK), the GUK-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 IETF 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.3.6-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 should be a 64-bit value formed by concatenating the GMK-ID with the GUK-ID (GMK-ID || GUK-ID). The GMK-ID shall have a purpose-tag of ‘0’.

Where the transmitting user is known through other means, the MKI may be solely the 32-bit GMK-ID. In this case the terminating user extracts the GUK-ID by calculating the User Salt and xor’ing this value with the GMK-ID.

When the MCPTT client is operating off network, the GMK 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.

7.3.7 Group member GMK management

In some situations, the membership of a group may be modified whereby an MC user may be added to or removed from an MCX group. Users are alerted to these changes by a user profile update from the CMS for which they are subscribed. The updated user configuration profile indicates the group ID to which the group membership change is associated.

When users are added to a new or existing group they may be implicitly affiliated to that group in which case the user is automatically subscribed to group configuration updates from the GMS. The user shall be authorised for group management services to the GMS before the GMS provides the associated group management records and the GMK. Once the user is authorised, the GMS sends the group management record as well as the GMK to the UE. The user may join in on the group communication immediately after receiving the group update and GMK.

When the user configuration record indicates the user has been added to a new or existing group but is required to explicitly affiliate to the group, the MCX client shall authorise the user to the GMS for group management services followed by a subscription to group updates from the GMS. The authorisation for group management services and the subscription shall be validated before the GMS provides group management records and the GMK. Once the user is authorised and the subscription processed by the GMS, the GMS sends the group management record and the GMK to the UE. The user may then join in on the group communication immediately after receiving the group update and GMK.

When a new user is added to an existing group, the Group Management Server may choose to update the GMK associated with the group ID (depending on the security profile of the group) to ensure previous group communications are separately protected from the new user.

When a user is removed from a group, the UE receives a user profile update from the CMS indicating the user is no longer a member of the specified group ID(s). Upon receiving the user profile update, ending of any group communication(s) associated with that group, and if the GMK associated with the group ID is not associated with another group that the user remains a member, the UE shall immediately and securely delete the GMK associated with that group ID. If the group ID is associated to more than one service (i.e. MCPTT, MCData and/or MCVideo) then upon the ending of any group communication(s) associated with that group ID, and if the GMKs associated with that group ID is not associated with another group that the user remains a member, the GMKs associated with that group ID shall be immediately and securely deleted.

When a user is removed from the group, the Group Management Server may choose to update the GMK associated with the group ID (depending on the security profile of the group).