Content for  TS 33.180  Word version:  17.8.0

This clause details the key management procedures for MCX users. It allows entities in MCX systems to establish a security association to support future communications. The primary purpose of these procedures is to allow MCX entities to communicate with each other using end-to-end security. End-to-end security provides assurance to MCX users that no unauthorized access to communications is taking place within the MCX network. End-to-end communication security may be applied to media when operating on-network and media, floor control, transmission control, and media control when operating off-network. A security domain is managed by a Key Management Server (KMS). The KMS is a component of the Common Services Core within the MCX system architecture. For any end-point to use or access end-to-end secure communications, it needs to be provisioned with key material associated to its identity by the KMS. Through the use of the KMS, MC administrators are able to manage the use of, and access to, secure communications within the MCX network. Key provisioning for groups is performed by a Group Management Server (GMS), authorized and provisioned by the KMS. The Group Management Server is responsible for distributing the key material to MCX users within the group. This establishes a group security context. With the group security context established, MCX users can communicate using end-to-end security. Prior to protecting group communications during off-network operation, the UE shall acquire the necessary group key material either while operating on-network or through off-network provisioning. Key provisioning for private communications is performed by the initiating UE as the communication is setup. This creates an end-to-end security context that is unique to the pair of users involved in the call. With a security context established, it may be used to encrypt media when on-network and, when off-network, media, floor control, transmission control, and media control traffic between the end-points. Prior to protecting private calls during off-network operation, the UE shall acquire the necessary individual key material either while operating on-network or through off-network provisioning. The key provisioning procedures described in this specification use common security methodologies for key distribution.

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 RFC 6509, 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. The security processes are summarized in Figure 5.2.2-1.

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.

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