L.4 Security procedures for the MC Security Gateway (SeGy)

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

L.4.1 General

The following procedures describe how a MC Security Gateway performs security functions on behalf of an external system (e.g. LMR) or unprotected MC system. For the purposes of these procedures it is assumed that a protected MC system is interconnecting with the encrypted interface, and an unprotected MC system is interconnected with the unencrypted interface.

For all these procedures, signalling sent on the unencrypted interface is not protected. Signalling sent on the encrypted interface may be protected with a SPK shared with a partner protected MC system.

L.4.2 Security procedures for private communication (initiated in the protected MC system)

The following private communication security procedures provide a mechanism for establishing a security context as part of the following private communication requests:

– Private Call Request (MCPTT)

– Private Call Request (MCVideo)

– MCData standalone data request

– MCData session data request

– MCData FD request

These requests are sent from an initiating MC client (on the unencrypted interface) to the terminating MC client (on the encrypted interface) via the MC Security Gateway.

The security procedure for a private communication via an MC Security Gateway is summarized in Figure L.4.2-1, In these procedures, the initiating client follows the security procedures defined in Clause 7.2.2 (MCPTT or MCVideo) or Clause 8.3 (MCData). The terminating client on the unencrypted interface does not use the MC security procedures defined in Clause 7 and 8. Prior to beginning this procedure, it is assumed that the initiating MC client has been provisioned with key material associated with a user’s MC service ID by the initiating user’s KMS as described in clause 5.3. It is also assumed that the SeGy has established its own ‘pseudo KMS’. Finally, it is assumed that the SeGy’s KMS Certificate has been provisioned as an External KMS Certificate to the initiating client by the initiating user’s KMS (as defined in Clause 5.3). The SeGy’s KMS Certificate shall have the ‘IsSecurityGateway’ attribute set to ‘true’.

Figure L.4.2-1: Private call security procedure for SeGy (call initiated on the encrypted interface)

The procedure in Figure L.4.2-1 is now described step-by-step.

1a. The initiating MC client generates the PCK and sends a private call request to the terminating entity as defined in Clause 7.2.2 (MCPTT and MCVideo) or Clause 8.3 (MCData). The message is routed via a SeGy. The SeGy receives the I_MESSAGE and generates the terminating user’s decryption key material using its ‘pseudo KMS’. The SeGy uses this key material to decrypt the PCK and stores the PCK and the PCK-ID for future use.

1b. The SeGy removes the I_MESSAGE from the communication request and extracts the PCK. The SeGy forwards the modified communication request towards the terminating MC client.

2a. Further session signalling that occurs between the client and MCX server is protected using the CSK and protected from the MCX server to the SeGy using the SPK.

2b. Further session signalling that occurs between the SeGy and the unprotected MC domain is unencrypted.

3. Communication media sent and received on the encrypted interface is encrypted using the PCK (3a) as defined in Clause 7.5 or 8.5. Communication media sent and received on the unencrypted interface is unencrypted (3b). On receipt of media on the encrypted interface, the SeGy decrypts the media using the PCK and forwards the media on the unencrypted interface. On receipt of media on the unencrypted interface, the SeGy encrypts the media using the PCK and forwards the media on the encrypted interface.

The initiating MC client is aware a MC Security Gateway is in use based upon the ‘IsSecurityGateway’ flag in the KMS Certificate used by the SeGy. During the communication, the initiating MC client shall warn the MC user that the communication is via an MC Security Gateway.

L.4.3 Security procedures for private communication (initiated in the unprotected MC system)

The following private communication security procedures provide a mechanism for establishing a security context between the SeGy and a MC client as part of the following private communication requests:

– Private Call Request (MCPTT).

– Private Call Request (MCVideo).

– MCData standalone data request.

– MCData session data request.

– MCData FD request.

These requests are sent from an initiating MC client (on the unencrypted interface) to the terminating MC client (on the encrypted interface) via the MC Security Gateway.

The security procedure for an on-network MCPTT or MCVideo private call via an MC Security Gateway is summarized in Figure L.4.3-1, In these procedures, the terminating client follows the security procedures defined in Clause 7.2.2 (MCPTT and MCVideo) or Clause 8.3 (MCData). The initiating client on the unencrypted interface does not use the MC security procedures defined in Clause 7 and 8.

Prior to beginning this procedure, it is assumed that the terminating MC client has been provisioned with key material associated with a user’s MC service ID by the terminating user’s KMS as described in Clause 5.3. It is also assumed that the SeGy has established its own ‘pseudo KMS’. Finally, it is assumed that the SeGy’s KMS Certificate has been provisioned as an External KMS Certificate to the terminating client by the terminating user’s KMS (as defined in Clause 5.3). The SeGy’s KMS Certificate shall have the ‘IsSecurityGateway’ attribute set to ‘true’.

Figure L.4.3-1: Private call security procedure for SeGy (call initiated on the unencrypted interface)

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

1a. The initiating client sends a private communication request to the terminating MC client. The message is routed via a SeGy. The SeGy receives the message and generates a PCK and PCK-ID. The SeGy creates an I_MESSAGE and encapsulates the PCK and PCK-ID as defined in Clause 5.6. The SeGy attaches the I_MESSAGE to the received communication request within an SDP offer as defined in IETF RFC 6509 [11]. The modified communication request is forwarded towards the terminiating MC client.

1b. The terminating MC client receives the communication request and processes it as described in Clause 7.2.2 (MCPTT and MCVideo) or Clause 8.3 (MCData).

2a. Further session signalling that occurs between the SeGy and MCX server is protected using the SPK and protected between the MCX server and terminating MC UE client using the CSK.

2b. Further session signalling that occurs between the SeGy and the unprotected MC domain is unencrypted.

3. Communication media sent and received on the encrypted interface is encrypted using the PCK (3a) as defined in Clause 7.5 or 8.5. Communication media sent and received on the unencrypted interface is unencrypted (3b). On receipt of media on the encrypted interface, the SeGy decrypts the media using the PCK and forwards the media on the unencrypted interface. On receipt of media on the unencrypted interface, the SeGy encrypts the media using the PCK and forwards the media on the encrypted interface.

The terminating MC client is aware a MC Security Gateway is in use based upon the ‘IsSecurityGateway’ flag in the KMS Certificate used by the SeGy. During the communication, the terminating MC client shall warn the MC user that the communication is via an MC Security Gateway.

L.4.4 Security procedures for group communications (group homed in the protected MC system)

This procedure uses a MIKEY payload to distribute a GMK from the GMS to another GMS to support group interconnection. The GMS follows the procedures in Clause 5.7 and 11.1.2.2. In this clause, it is assumed that at least one group member is in the unprotected system and hence the Notify group request containing the GMK is routed to the GMS in the unprotected system.

Prior to beginning this procedure, it is assumed that the GMS has been provisioned by its KMS with key material associated with its identity. It is also assumed that the SeGy has established its own ‘pseudo KMS’. Finally, it is assumed that the SeGy’s KMS Certificate has been provisioned as an External KMS Certificate to the GMS by the GMS’s KMS (as defined in Clause 5.3). The SeGy’s KMS Certificate shall have the ‘IsSecurityGateway’ attribute set to ‘true’.

Figure L.4.4-1 shows the security procedures for creating a security association for a group with a SeGy.

Figure L.4.4-1: Security configuration for MC groups (where a group member is behind a SeGy)

A description of the procedures depicted in figure L.4.4-1 follows:

1a. The GMS shall send a MIKEY payload containing a GMK to the GMS in an interconnected system within a ‘Group information notify request’ message as defined in Clause 11.1.2.2. Where the interconnected system is unprotected and hence is behind a SeGy, the ‘Group information notify request’ is sent via the SeGy. The SeGy shall generate the Pseudo GMS’s identity-based key material using its pseudo-KMS and use this key material to extract the GMK and GMK-ID from the I_MESSAGE within the ‘Notify group request’.

1b. The SeGy shall remove the I_MESSAGE from the ‘Group information notify request’ and forward the modified request towards the unprotected MC system’s GMS.

2. The SeGy shall forward on further signalling invisibly (including the ‘Notify response’).

3a. Group media sent and received on the encrypted interface is encrypted using the GMK (3a) as defined in Clause 7.5 or 8.5. Group signalling sent and received on the encrypted interface is protected as defined in clause 9. On receipt of media on the encrypted interface, the SeGy decrypts the media using the GMK and GMK-ID and forwards the media on the unencrypted interface.

3b. Group media sent and received on the unencrypted interface is unencrypted (3b). Group signalling sent and received on the unencrypted interface is unprotected. On receipt of media on the unencrypted interface, the SeGy encrypts the media using the GMK and forwards the media on the encrypted interface.

The GMS is aware a MC Security Gateway is in use based upon the ‘IsSecurityGateway’ flag in the KMS Certificate used by the SeGy. When any group member is behind a Security Gateway, the GMS shall set the ‘Security Gateway’ flag within the ‘Status’ field of the group GMK’s key parameters (as defined in Clause E.6.9).

The MC group clients within the protected MC system are aware the MC Security Gateway is in use based upon the ‘Security Gateway’ flag within the ‘Status’ field of the GMK’s key parameters (as defined in Clause E.6.9). During a communication encrypted with the GMK, the MC group client shall warn the MC user that the communication may be via an MC Security Gateway.

L.4.5 Security procedures for group communications (group homed in the unprotected MC system)

In this clause, it is assumed that the group is owned by a GMS inside the unprotected system and group members and their GMS are inside the protected domain. The GMS in the protected domain follows the procedures in Clause 5.7 and 11.1.2.2. A Notify group request is routed from the GMS in the unprotected domain to the GMS in the protected system.

Prior to beginning this procedure, it is assumed that the GMS in the protected domain has been provisioned by its KMS with key material associated with its identity. It is also assumed that the SeGy has established its own ‘pseudo KMS’. Finally, it is assumed that the SeGy’s KMS Certificate has been provisioned as an External KMS Certificate to the GMS in the protected system by the GMS’s KMS (as defined in Clause 5.3). The SeGy’s KMS Certificate shall have the ‘IsSecurityGateway’ attribute set to ‘true’.

Figure L.4.5-1 shows the security procedures for creating a security association for a group with a SeGy.

Figure L.4.5-1: Security configuration for MC groups (where group is homed in an unprotected domain)

A description of the procedures depicted in figure L.4.5-1 follows:

1a. The GMS in the unprotected system send a Group Notify to the GMS in an interconnected system within a ‘Group information notify request’ message as defined in Clause 11.1.2.2. Where the interconnected system is protected and hence is behind a SeGy, the ‘Group information notify request’ is sent via the SeGy.

1b. On receipt of a Notify group request on the unencrypted interface, the SeGy shall generate a GMK and GMK-ID and encrypt the GMK to the GMS in the protected system using the SeGy’s Pseudo GMS’s identity-based key material. SeGy shall set the ‘Security Gateway’ flag within the ‘Status’ field of the group GMK’s key parameters (as defined in Clause E.6.9). The encapsulated GMK and GMK-ID is attached to the ‘Notify group request’ within an I_MESSAGE as defined in Clause 5.7. The modified ‘Notify group request’ is sent on by the SeGy to the GMS in the protected system.

2. The SeGy shall forward on further signalling invisibly (including the ‘Notify response’).

3a. Group media sent and received on the encrypted interface is encrypted using the GMK (3a) as defined in Clause 7.5 or 8.5. Group signalling sent and received on the encrypted interface is protected as defined in clause 9. On receipt of media on the encrypted interface, the SeGy decrypts the media using the GMK and GMK-ID and forwards the media on the unencrypted interface.

3b. Group media sent and received on the unencrypted interface is unencrypted (3b). Group signalling sent and received on the unencrypted interface is unprotected. On receipt of media on the unencrypted interface, the SeGy encrypts the media using the GMK and forwards the media on the encrypted interface.

The GMS in the protected system is aware a MC Security Gateway is in use based upon the ‘IsSecurityGateway’ flag in the KMS Certificate used by the SeGy and as the ‘Security Gateway’ flag will be set within the ‘Status’ field of the group GMK’s key parameters (as defined in Clause E.6.9).

On receipt of the GMK, the GMS in the protected domain shall distribute the key to group clients as defined in Clause 5.7. MC group clients in the protected system are aware the MC Security Gateway is in use based upon the ‘Security Gateway’ flag within the ‘Status’ field of the GMK’s key parameters (as defined in Clause E.6.9). During a communication encrypted with the GMK, the MC group client shall warn the MC user that the communication may be via an MC Security Gateway.