Content for  TS 33.180  Word version:  18.1.0

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.

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 TS 23.280. Figure 5.7.2-1 shows the security procedures for creating a security association for a group.

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 TS 23.280 is referenced. 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.

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).

The 'key download' procedure is used to send keys from the MCX server to the MC client. It is used to distribute Multicast Signalling Keys (MuSiKs) to the MC clients, and it is used to update both the CSKs and MuSiKs. Within the 'key download' procedure, keys (CSK or MuSiKs) are encrypted specifically to the MC user and signed using an identity representing the MC Server. Prior to group key distribution, each MC client shall be provisioned by the KMS with time-limited key material associated with the MC User as described clause 5.3. The MC Server shall also be provisioned by the MC KMS with key material for an identity which is authorised to act as an MCX Server. The key (CSK or MuSiK) is distributed from the MCX Server to a MC client using the security mechanism described in clause 5.2.2, transported over the SIP bearer. End-point diversity is not required as end-points do not encrypt data, hence the extension in clause 5.2.3 is not 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 initiating entity shall be the initiating MCX Server and the receiving entity shall be the terminating MC user. The initiating entity URI shall be the FQDN of the MCX Server (e.g. MDSI of the MC Domain) and the receiving entity URI shall be the MC Service ID of the terminating user. The distributed key, K, shall be the CSK or MuSiK and the key identifier K-ID shall be the CSK-ID or MuSiK-ID (respectively). As a result of this 'key download' mechanism, the MC clients receive a new signalling key, CSK or MuSiK, identified by the 4 most significant bits of the key ID. The MCData Service server may use the Key Download procedure to indicate or modify the algorithm used to protect the MCData signalling fields (i.e. MCData signaling parameters, Data signaling payload and End to end security parameters) by including a 'signalling algorithm' parameter. The 'signalling algorithm' to be used shall be selected by the MCData Service server based on the local policy and/or regional regulatory requirement (for example, to enforce use of 128-bits or 256-bits key length). Based on the selected algorithm, the key used shall be derived as described in Annex F.1.5. The 'signalling algorithm' parameter is described in clause 8.5.4.1. The available algorithms shall be as defined in clause 8.5.4.2.

The procedure for key download is described in Figure 5.8.2-1:

To prevent the exposure of mission critical keys and key material, the following guidelines shall be followed to ensure that mission critical keys and key material are protected within the UE. Persistence of keys and key material through transistional states of the UE are defined in clause 5.11.2. All long term keys and private certificates used to establish secure communications with MC domain servers such as the IdMS, KMS, and MC domain proxies (e.g. CS proxies and MC domain proxies) shall be stored in a protected state within the UE while not actively in use. The method used to protect these keys and certificates is out of scope of this document. These long term keys and key material include, but are not limited to the TrK, InK, and TLS private certificates. CSK(s), GMK(s) and MuSiK(s) shall be stored in a protected state within the UE while not actively in use. The method used to protect these keys is out of scope of this document. Identity based key material, e.g. KMS Key Set(s), shall be stored in a protected state within the UE while not actively in use. The method used to protect these keys is out of scope of this document. Identity based tokens, such as the ID token, access token(s), refresh token(s), and security token(s) shall be stored in a protected state within the UE while not actively in use. The method used to protect these tokens is out of scope of this document. Dynamic keys used for MCPTT, MCData and MCVideo signalling and media protection such as the MKFC, MSCCK and PCK and any derived keys (e.g. DPCK, SRTP Master Keys, XML keys, AES keys) should be securely stored as dictated by the operational needs of these keys and shall be securely deleted when these keys are no longer operationally needed.

Static and semi-static keys and key material such as CSK(s), GMK(s), TrK, InK, TLS private certificates, IPsec private certificates, KMS Key Sets, ID token, access token(s), refresh token(s), and security token(s) shall be securely stored and maintained through UE power cycles. These static and semi-static keys and key material shall also be maintained through user log-off and log-on cycles. This ensures that the UE maintains the credentials, keys and key material for the user through various UE transitional states including on-network to off-network transitions. This is especially critical for identity based key material and GMK(s) that are used for off-network communications. When the current user logs off and a different user logs onto the UE, all keys and key material associated to the previous user shall either be securely deleted from the UE or alternatively, a method to securely partition user's keys and key material from other users shall be implemented. Keys and key material that remain in the UE through log-off and log-on cycles and during usage by mulitiple users shall be securely stored and accessible only to the user to which the keys and key material are associated. The method used to securely partition user's keys and key material is out of scope of this document. Dynamic keys for MCPTT, MCData and MCVideo media and signalling protection such as the MKFC, MSCCK, and PCK and any derived keys (e.g. DPCK, SRTP Master Keys, XML keys, AES keys) shall be securely deleted from the UE at UE power down, log off of the current user, expiry of any associated access tokens (for technical or authentication reasons), or as dictated by the operational needs of these keys. Dynamic keys and tokens may be renegotiated during establishment of follow-on communications. When an access token expires because the IdMS cannot or will not refresh the existing access token for technical or authentication reasons, the following mission critical static, semi-static and dynamic keys shall be securely deleted from the UE; CSK(s), GMK(s), MuSiK, MKFC, MSCCK, KFC, DPPK, PCK, and identity based tokens (i.e. access tokens, refresh tokens, and security tokens). Expired access tokens, refresh tokens or security tokens may require re-authentication of the user with the IdM services and MC domain.

There are two distinct authentication and authorization mechanisms required in order to allow an MC Client residing on an MC gateway UE or an MC Client residing on a non-3GPP device (connecting via an MC gateway UE) access to MC Services. The first mechanism is 3GPP network device authentication and the second mechanism is MC Client authentication and authorization. The MC gateway UE requires authentication by the 3GPP network prior to obtaining MC Services. If the 3GPP network authentication procedures are successful and the MC gateway UE is granted 3GPP network access and connectivity, then the MC gateway UE may provide the non-3GPP device access to MC Services via MC Clients. Two different types of non-3GPP devices are supported, those which can host MC Clients and those which cannot host MC Clients. Regardless of whether the MC Client is hosted on the MC gateway UE or on the non-3GPP device, every MC Client shall follow the authentication and authorization procedures defined in clause 5.1 in order to access MC Services. Figure 5.12.1-1 provides a summary of the steps required to authenticate and authorize the use of an MC gateway UE and MC Clients.

The authentication and authorization mechanisms shown in Figure 5.12.1.1-1 are described here:

1. Authentication of the MC gateway UE device onto the 3GPP network. The 3GPP device authentication of the MC gateway UE device follows the procedures defined in TS 33.501. This is to establish 3GPP network connectivity and network routing.
2. Establishment of connectivity between the non-3GPP device and the MC gateway UE. Specification of the protocol and security used on the interface between the MC gateway UE and the non-3GPP device is out of scope of 3GPP. The connectivity between the MC gateway UE and the non-3GPP device may be established prior to Step 1.
3. Authentication and authorization of the MC Client for MC services with the MC System. The MC Client, residing either on the MC gateway UE or on the non-3GPP device, shall follow the authentication and authorization security framework as defined in clause 5.1 of the present document. If the MC Client resides on the non-3GPP device, the MC gateway UE supports the authentication and authorization of the MC Client by forwarding all messages (unmodified) between the MC Client on the non-3GPP device and the MC System.

Upon successful completion of the authentication and authorization of the MC Client onto the MC System (Step 3), the MC gateway UE hosting an MC Client or the non-3GPP device hosting an MC Client may now access MC Services as allowed by their access token(s) obtained from the MC IdMS and the associated user profile obtained from the CMS.