5.7 Key management for group communications (GMK)

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

5.7.1 General

To create the group’s security association, a Group Master Key (GMK) and associated identifier (GMK-ID) is distributed to MCX 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 MCX UE within the group shall be provisioned by the MCX Key Management Server (KMS) with time-limited key material associated with the MCX user as described in clause 5.3. The Group Management Server shall also be provisioned by the MCX KMS with key material for the GMS’s identity (the GMS Server URI).

The GMK is distributed from the GMS to a MCX client using the security mechanism described in clause 5.2.2, transported over the SIP bearer. For GMKs, end-point diversity is required and hence the extension in clause 5.2.3 is applied. Additional parameters may be included as defined in clause 5.2.4. The SAKKE-to-self extension may be included as defined in clause 5.2.5. Identity hiding may be supported as defined in clause 5.2.6. The receiving MCX client and any MCX Server through which the SIP INVITE is routed, may respond with a KMS Redirect Response (KRR) as described in clause 5.2.8.

GMKs may be managed individually per Group ID or the same GMK may be assigned to multiple MC Group IDs (using the MIKEY general extension payload defined in Clause E.6). This means that each specified MC Group ID in the MIKEY general extension payload shall use this GMK for group communications. Assigned MC Group IDs may include any combination of MCPTT Group IDs, MCData Group IDs or MCVideo Group IDs. Assigning the same GMK to multiple Group IDs does not prevent individual key management at a later time or vice versa.

An MC client may have multiple active GMKs associated with a Group ID. When this occurs, the MC client shall use the active GMK with the most recent Activation Time (as defined in Clause E.6.4) when encrypting group media.

The initiating entity shall be the initiating GMS. The initiating entity URI shall be the URI of the GMS (e.g. sip: gp.manager@mcptt.example.org). The receiving entity shall be the terminating MCX user. The receiving entity URI shall be the MCX service ID of the terminating user. The distributed key, K, shall be the GMK, the key identifier K-ID shall be the GMK-ID and the end-point-specific key identifier, UK-ID shall be the GUK-ID.

Clause E.3 provides MIKEY message structure for GMK distribution.

5.7.2 Security procedures for GMK provisioning

This procedure uses a MIKEY payload to distribute a GMK from the GMS to the MC UEs within the group. The payload is transported as part of the ‘Notify group configuration request’ message defined in clause 10.1.2.7 of 3GPP TS 23.280 [36].

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

Figure 5.7.2-1: Security configuration for groups

A description of the procedures depicted in figure 5.7.2-1 follows. For clarity, figure 10.1.5.3-2 in clause 10.1.5.3 of 3GPP TS 23.280 [36] is referenced.

0) Prior to beginning this procedure the MC client shall be provisioned with identity-specific key material by a MC KMS as described in clause 5.3. The GMS shall also be securely provisioned with identity-specific key material for the GMS’s Server URI.

1) The GMS shall send a MIKEY payload to MC 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 (MCX service user ID) associated to the MC 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 5.2.4-1.

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

2) On receipt of a MIKEY message, the MC client shall check the signature on the payload, extract the GMK, GUK-ID and GMK-ID and check that the GMK-ID is not a duplicate for an existing GMK. The MC 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. The MC client shall lookup the Group ID in its user profile data and verify that the GMS identity corresponds with the Server URI for that Group ID. This process is shown in Figure 5.2.4-2. Should any of these checks fail, an error shall be returned to the GMS. Upon successful receipt and processing, the MC UE shall store the GMK, GMK-ID, GUK-ID and associated parameters, and respond to the GMS with a ‘Notify group configuration response’ message.

It is recommended that a mechanism is used to ensure that no two Group IDs from different servers collide.

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.

It is possible that an MC user in the group 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 any client in the group be represented by an MC Security Gateway, the GMS shall indicate to all users 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).

Should an MC client receive a GMK with the ‘Security Gateway’ bit set, the initiating MC client shall warn the MC user that an MC Security Gateway is in use during the group’s comunications.

5.7.3 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 the user configuration record indicates the user has been added to a new or existing group, the user shall be authorised for group management services to the GMS followed by the client subscribing to group updates from the GMS. The user shall be authorised 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 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).