5.2.2 Common key distribution

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

The security mechanism described in this clause allows a key, K, to be distributed from an initiating party to a receiving party. It provides confidentiality of the key, and integrity and authenticity of the payload. It is used within a number of different security procedures in this specification.

The key, K, is distributed encrypted specifically to the receiving entity and signed by the initiating entity. Prior to call commencement, both MCX UEs shall be provisioned by the KMS with time-limited key material associated with the MCX entity’s URI. The key is distributed with a 32-bit Key Identifier (K-ID). This payload is a MIKEY-SAKKE I_MESSAGE, as defined in IETF RFC 6509 [11], which ensures the confidentiality of the key, plus integrity and authenticity of the payload.

The key is encrypted to the user identity (UID) associated to the receiving MCX entity using the security domain parameters provided in the public values in the certificate received from the KMS. The UID used to encrypt the data is derived from the receiving entity’s URI (e.g. sip:user.002@mcptt.example.org) and a time-related parameter (e.g. the current year and month). The terminating entity’s URI is added to the recipient field (IDRr) of the message.

The payload includes the encrypted key and the key identifier (K-ID). The key is unique within the MC domain. On creating the key, the initiator generates a 32-bit key identifier (K-ID). The 4 most significant bits of the K-ID shall indicate the purpose of the key, the other 28-bits shall be randomly generated. The key identifier (K-ID) is stored in the CSB-ID field of the MIKEY I_MESSAGE.

The payload is signed using (the KMS-provisioned key associated to) the identity of the initiating entity. The UID used to sign the data is derived from the initiating entity’s URI (e.g. sip:user.001@mcptt.example.org) and a time-related parameter (e.g. the current year and month). The initiating entity’s URI is added to the initiator field (IDRi) of the message.

NOTE: This solution is for the end-to-end protection of keys and does not protect the identities transmitted. Identities may be masked by transmitting the UID within the MIKEY ID fields as described in Annex E.7.

The security processes are summarized in figure 5.2.2-1.

Figure 5.2.2-1: Common key distribution mechanism

Via this mechanism, the key distribution is confidentiality protected, authenticated and integrity protected.

It is possible that the key has been distributed using an unacceptable KMS, either for the initiator’s KMS or for the receiver’s KMS. This is particularly likely for communications being sent across multiple MC Systems (where KMS information may not have been shared prior to beginning the key distribution procedure). In this case, a KMS Redirect Response (KRR) may be sent back to the initiator. The KRR provides the initiator with information about which KMS may be acceptable. KRR procedures are described in clause 5.2.8.

Assuming that acceptable KMS(s) have been used, the I_MESSAGE will be processed by the receiving entity. The initiating entity’s URI is extracted from the initiator field (IDRi) of the message. This is converted to a UID and used to check the signature on the MIKEY-SAKKE I_MESSAGE. If valid, the UE extracts and decrypts the encapsulated key, K, using the (KMS-provisioned) entity’s UID key. The MCX entity also extracts the K-ID. This process is shown in figure 5.2.2-2.

Figure 5.2.2-2: Common key extraction mechanism

With the key successfully shared between the two MCX entities, the entities are able to use the shared security context to protect communications.