Content for  TS 33.180  Word version:  17.8.0

Within the mission critical architecture, the Key Management Server (KMS) provisions key material associated with a specific MC identity (e.g. MCPTT ID). The KMS has interfaces with the key management clients. A key management client is responsible for making requests for identity-specific key material. Key provisioning clients are located in the MC UE, in the MCX Server(s) and in the Group Management Server(s). The reference points for the KMS are shown in Figure 5.3.2-1.

Figure 5.3.2-1 shows the CSC-8, CSC-9 and CSC-10 reference points for the Key Management Server within a MC domain. The KMS may or may not be located within the Common Services Core (CSC) of the MC domain and may or may not make use of the HTTP proxy. If the KMS does not make use of the HTTP proxy, then a secure HTTP connection (HTTPS) shall be established directly between the KMS and the KM client. In this case, each of CSC-8, CSC-9 and CSC-10 is a direct HTTP connection between the KMS and KM client in the MC UE, MCX Server or GMS (resp). The use of the TrK as defined in clause 9.3.3 may be used to protect the key material content in this configuration, and the InK may be used to integrity protect the key material content. If the KMS does connect to and employ the use of the HTTP proxy, then for public safety users the TrK shall be used as defined in clause 9.3.3 to protect the key material content and the InK should be used for integrity protection. In this case, each of CSC-8, CSC-9 and CSC-10 uses HTTP-1 and HTTP-2 between the KMS and KM client in the MC UE, MCX Server or GMS (resp). When a TrK is used to protect the transfer of key material between the KM client and KMS, the MC UE TrK identifier (TrK-ID) shall be provided by the KM client to the KMS during user KM authorization. If the InK-ID is not provided in the same user authorization request, then the TrK shall be used for integrity protection. If the InK-ID is provided in the same user authorization request, then the InK shall be used for integrity protection.

The procedure for the provision of identity-specific key material when the HTTP proxy is supported between the KMS and the KM client is described in Figure 5.3.3-1. The procedure is the same whether the key management client in the MC UE, an MCX Server or a Group Management Server is making the request.

The procedure in Figure 5.3.3-1 is now described step-by-step. The procedure for the provisioning of identity-specific key material when the HTTP proxy is not used between the KMS and the KM client is as described in Figure 5.3.3-2.

The procedure in Figure 5.3.3-2 is now described step-by-step: As a result of this procedure, the key management client has securely obtained key material for use within the MC system.

End-to-end communication security for either group or private calls requires the provisioning of key material from the KMS. The key material provisioned to each user is listed below:

• A KMSInit Response contains the KMS Certificate (domain specific key material associated to the KMS), and may contain:
  • An updated TrK for the user (to replace the off-network-provisioned, bootstrap TrK).
  • Policy around the use of KMS key material (Home KMS only)
  • Address to which 'KMSCertCache' requests should be sent.
  • Address to which 'KRRupload' messages should be sent.
• A KMSKeyProv Response contains zero, or more, KMSKeySets and may contain:
  • An updated TrK for the user (to replace existing TrK).
• A KMSCertCache Response may contain:
  • The KMS's Certificate(s) (current, updated or future).
  • Migration KMSs (KMS URIs, access addresses, provisional TrKs).
  • External KMS Certificates. This is domain specific key material associated with other KMSs. It is required to enable secure communications across security domains.
• A KMSCert Response may contain:
  • An External KMS Certificate. This is domain specific key material associated with the requested KMS URI. It is required to enable secure communications across security domains.
• A KMS Lookup Response does not contain key material, but may contain KMS URIs.

A KMS Certificate is defined in Annex D.3.2. A KMS Certificate contains the following:

• A Role of 'Home' or 'External', depending on whether the certificate is the issuing KMS's or is provided by another external KMS.
• The KMS Public Authentication Key (KPAK in RFC 6507 [9]).
• The KMS Public Confidentiality Key (Z_T in RFC 6508 [10]).
• The UID conversion (as described below).
• Choice of cryptographic domain parameters (such as those listed in RFC 6509 [8]).
• The time period for which this information is valid.

Certificates are identified by the KMS (KMSUri) and a unique identifier (CertUri). A (logical) KMS should only have a single KMS certificate active at any one time (based upon the KMSUri). Certificates may be updated using the CertURI. Should a client receive a certificate with a CertURI of an existing certificate, the client shall replace this existing certificate with the newly provisioned certificate. The UID conversion mechanism defines how UIDs are generated. Using this information a MC client can take a user identifier (e.g. an MCPTT ID), and the current time, (e.g. the year and month) and convert these to a UID. EXAMPLE: As a consequence, there is a one-to-one correspondence between MC Service IDs and UIDs during each time period.

KMSKeySet(s) are defined in Annex D.3.3.2 and contain the following:

• A user signing key for each UID for the current time period (SSK and PVT in RFC 6507).
• A user decryption key for each UID for the current time period (RSK in RFC 6508).
• The key period number associated with the current keys.
• Optionally, the time period, for which the user key material is valid (e.g. month).