Content for TS 33.180 Word version: 17.8.0

1… 4… 4.3.4 4.3.5 5… 5.1.3 5.1.4… 5.2… 5.2.3 5.2.4 5.2.5 5.2.6… 5.3… 5.4… 6… 7… 7.3… 8… 9… 9.4… 10… A… B… C… D… E… F… J… L…

5.2.6 Key distribution with identity hiding 5.2.7 Key distribution across multiple security domains 5.2.8 KMS Redirect Responses (KRRs)
...

5.2.6 Key distribution with identity hiding p. 45

The key distribution mechanism defined in clauses 5.2.2, 5.2.3, 5.2.4 and 5.2.5 may be extended to allow identities to be masked within the MIKEY payload. This is achieved by adding the UID, rather than the URI to the payload as described in Annex E.7 and shown in Figure 5.2.6-1.

Copy of original 3GPP image for 3GPP TS 33.180, Fig. 5.2.6-1: Common key distribution mechanism with identity hiding

Figure 5.2.6-1: Common key distribution mechanism with identity hiding
(⇒ copy of original 3GPP image)

On receipt of a MIKEY payload with identities hidden, the receiving entity should recognise the receiver UID in the packet. If not, the I_MESSAGE shall be rejected. Based on the initiator UID, the receiver checks the validity of the I_MESSAGE signature. At this point the initiator is anonymous to the receiver. If this check fails, the I_MESSAGE shall be rejected. The receiver then extracts the key K. This may be used to decrypt other parts of the packet and extract the initiator URI. Once the initiator URI is extracted, this shall be used to generate the initiator UID and check that it is the one provided in the I_MESSAGE. If not, the I_MESSAGE shall be rejected. This procedure is shown in Figure 5.2.6-2

Copy of original 3GPP image for 3GPP TS 33.180, Fig. 5.2.6-2: Common key extraction mechanism with identity hiding

Figure 5.2.6-2: Common key extraction mechanism with identity hiding
(⇒ copy of original 3GPP image)

5.2.7 Key distribution across multiple security domains p. 46

5.2.7.1 General p. 46

5.2.7.2 Identification of External Security Domains p. 46

To support multiple security domains, the security domain used by each user is recorded alongside the user's MC Service ID within configuration parameters in the MC system. Furthermore, the security domain of the GMS is recorded alongside the GMS FQDN and the security domain of the MCX Server is recorded alongside the MCX Server FQDN. Security domains are identified by a unique identifier, the 'KMSUri'. Specifically, the following describes the situations where security domain information is needed:

The MCX Server(s) requires knowledge of the security domain (KMSUri) of users connected to the server.

2.1)

On initiating a MCPTT private call, the initiating UE requires knowledge of the security domain (KMSUri) of the receiving user.

2.2)

On receiving a MCPTT private call, the receiving UE requires knowledge of the security domain (KMSUri) of the initiating user.

3.1)

On initiating a MCVideo private call, the initiating UE requires knowledge of the security domain (KMSUri) of the receiving user.

3.2)

On receiving a MCVideo private call, the receiving UE requires knowledge of the security domain (KMSUri) of the initiating user.

4.1)

On initiating a MCData one-to-one SDS or file transfer, the initiating UE requires knowledge of the security domain (KMSUri) of the receiving user.

4.2)

On receiving a MCData one-to-one SDS or file transfer, the receiving UE requires knowledge of the security domain (KMSUri) of the initiating user.

The Group Management Server requires knowledge of the security domain (KMSUri) of each member of the group.

Group members require knowledge of the security domain (KMSUri) of the group management server.

MC users require knowledge of the security domain (KMSUri) of the MCX Server(s) to which they connect.

5.2.7.3 Using multiple security domains p. 47

On encrypting to an entity within the MC System using an I_MESSAGE, the client shall lookup the KMSUri from the appropriate configuration data, then lookup the appropriate KMS Certificate with that KMSUri from the certificate cache downloaded from it's home KMS. The security parameters within the KMS Certificate are used to perform encryption. The KMSUri is added to the I_MESSAGE within the IDRkmsr field.

Equivalently, when verifying a received I_MESSAGE, the receiving client shall extract the KMSUri from the I_MESSAGE (if present) and check this matches the KMSUri from the appropriate configuration data. The client shall then lookup the appropriate KMS Certificate with that KMSUri from the certificate cache downloaded from it's home KMS. The security parameters within the KMS Certificate are used to perform verification.

Should a matching certificate not be found, the client may request the certificate based on the KmsUri from it's home KMS using an appropriate KMS Cert request, as defined in Clause D.2.6.

5.2.8 KMS Redirect Responses (KRRs) |R15| p. 47

5.2.8.1 Overview of KMS Redirect Response procedure (KRR) p. 47

5.2.8.1.1 General p. 47

The purpose of KMS Redirect Response procedures is to allow key distribution where the KMS used by the receiver is not known. It also allows policy to be applied to ensure the KMS used by the receiver and initiator is acceptable along the path of the communication.

The key message is a KMS Redirect Response (KRR) which conveys KMS policy to the initator. The initiator could be a MC client or GMS. Sometimes multiple MIKEY messages and KRR exchanges will be required to establish a suitable choice of (KMS initiator, KMS receiver) pair. It is also possible that there is no acceptable choice, and as a result of the process the communication fails.

The partner (external) security domains (KMS URIs) and certificates are typically provisioned to the UE by the user's Home KMS (see Annex D). The KRR procedure does not provision KMS certificates, but shares information about which KMS may be used with the target key management client.

The following scenarios may trigger a KRR procedure in order to communicate KMS information to the initiating entity:

The KMS URI (IDRkmsr) used in the MIKEY message may be incorrect for the target; or
While the specified KMS URI may be correct for the receiver, the primary or partner application server may for various reasons still disallow communications with the target entity using the specified receiver KMS URI (IDRkmsr); or
While the specified KMS URI may be correct for the receiver, the primary or partner application server may for various reasons still disallow communications with the receiver using the specified initiator KMS URI (IDRkmsi);

The KRR procedure may be initiated by application servers in the signalling path or it may be initiated by the terminating MCX entity. Client shall support receipt of KRRs, and may process or ignore the KRR based on local policy.

5.2.8.1.2 KMSs and KMS URIs p. 48

The KMS URI is the URI used to identify a logical KMS. This represents a security domain of users with shared trust. A logical KMS supports exactly one security domain, hence there is a one-to-one correspondence between KMS URIs, security domains and logical KMSs.

The types and uses of KMSs are described in Clause 5.3.

5.2.8.2 Use of KRRs p. 48

5.2.8.2.1 Content of KRRs p. 48

The KMS Redirect Response (KRR) contains a list of KMS URIs for both the initiator and the receiver. Both the initiator list and receiver list is an ordered list, with the preferred KMS URIs first. The KMS URI list can also be 'Any' meaning that any KMS is acceptable.

The content of a KRR is:

An identifier for this type of response.
The date and time.
The identity of the KRR creator.
The MIKEY initiating identity used within the MIKEY message (IDRi).
The MIKEY initiator's KMS URI used within the MIKEY message (IDRkmsi).
The MIKEY receiving identity used within the MIKEY message (IDRr).
The MIKEY receiving's KMS URI used within the MIKEY message (IDRkmsr).
The initiator list containing a list of acceptable KMS URIs (List of IDRkmsi options).
The receiver list containing a list of acceptable KMS URIs (List of IDRkmsr options).
An embedded received KRR (if this KRR is generated as a result of a received KRR).
A signature (using the originating identity) over the entire message (optional, but recommended).

All fields, except for the signature, are required content.

5.2.8.2.2 KRR creation procedure by a receiver p. 48

The KRR initiator and receiver lists (as defined in clause 5.2.8.2.1) are populated based on the received MIKEY message from the initiator. The message contains an initiating KMS URI (IDRkmsi) and receiving KMS URI (IDRkmsr).

The KRR initiator list is populated as follows:
If this is the first received MIKEY message from the initiator, the receiver may respond with a preferred list of KMS URIs based on local policy. If IDRkmsi corresponds to one of the receiver's External KMSs, the initiator list shall contain, at minimum, the IDRkmsi.
Otherwise, the IDRkmsi does not correspond to one of the receiver's External KMSs, and a list of KMS URIs corresponding to External KMSs is provided based on local policy (not all KMS URIs need be included).

The KRR receiver list is populated as follows:
1. If this is the first received MIKEY message from the initiator, the receiver may respond with a preferred list of KMS URIs based on local policy. If the IDRkmsr corresponds to one of the receiver's Home KMS or a provisioned Migration KMS, the receiver list shall include, at a minimum, the IDRkmsr.
2. Otherwise, the IDRkmsr does not correspond to one of the receiver's Home KMS or a provisioned Migation KMS, and a list of KMS URIs corresponding to the Home KMS and Migration KMSs is provided based upon local policy (not all KMS URIs need be included).

5.2.8.2.3 KRR creation procedure by a MCX server or signalling proxy p. 49

A MCX Server or Signalling proxy can create a KRR on receipt of a MIKEY message from the initiator en route to the receiver. The message contains an initiating KMS URI (IDRkmsi) and receiving KMS URI (IDRkmsr). A KRR is created under the following conditions.

Case A)

For MIKEY messages entering from a MC client (inbound CS Proxy), a KRR is created if the IDRkmsi is not acceptable. This could be either that the KMS is not supported within the domain, or that the KMS is not supported for the user given the user's current state, location or juristriction. In this case:

the initiator KMS URI list contains a list of acceptable KMS URIs supported by the domain for the user based on the user's current state.
the receiver KMS URI list shall be 'ANY'.

Case B)

For MIKEY messages entering/leaving a domain (IS Proxy), if the initiating user (IDRi) relates to this domain and the IDRkmsi is not acceptable then:

the initiator KMS URI list contains a list of acceptable Home and Migration KMS URIs used by the IDRi for this domain..
the receiver KMS URI list is 'ANY'.

Case C)

For MIKEY messages entering/leaving a domain (IS Proxy), if the receiving user (IDRr) relates to this domain and the IDRkmsr is not acceptable then:

the initiator KMS URI list is 'ANY'.
the receiver KMS URI list contains a list of acceptable Home and Migration KMS URIs used by the IDRr for this domain.

Case D)

For MIKEY messages exiting towards a MC client (outbound CS Proxy), a KRR is created if the IDRkmsr is not acceptable. This could be as the KMS is not supported given the user's current state, location or juristriction. In this case:

the initiator KMS URI list shall be 'ANY'
the receiver KMS URI list contains a list of acceptable KMS URIs supported by the domain based on the user's (IDRr) current state.

Should any network entity create a KRR, the network entity shall drop the received MIKEY message. Entities in the path receiving a KRR shall forward the KRR towards the initiating IDRi.

5.2.8.2.4 Processing a KRR at a MCX server or signalling proxy p. 49

A MCX Server or Signalling proxy can create a new KRR on receipt of a KRR. The content of the KRR is based on local policy of which KMSs are supported within the domain. A new KRR is created under the following conditions:

Case A)

For KRRs entering the domain from a MC client (inbound CS Proxy), a new KRR is created if the contents of the receiver KMS URI list contains a KMS URI that is not acceptable. This could be as the KMS is not supported given the user's current state, location or juristriction. Within the new KRR in this case:

the initiator list is unchanged.
the receiver list is reduced to remove the unacceptable KMS URIs. If the list is empty, an empty list is returned within the KRR (and consequently, the communication will fail).

Case B)

For KRRs entering/existing the domain towards another domain (IS Proxy), a new KRR is created if the receiving user (IDRr) relates to this domain and the receiver list contains a KMS that is not acceptable then within the new KRR:

the initiator list is unchanged.
the receiver list is reduced to remove the unacceptable KMS URIs. If the list is empty, an empty list is returned within the KRR (and consequently, the communication will fail).

Case C)

For KRRs entering/exiting the domain from another domain (inbound IS Proxy), a new KRR is created if the initiating user (IDRi) relates to this domain and the initiator list contains a KMS that is not acceptable then within the new KRR:

the initiator list is reduced to remove the unacceptable KMS URIs. If the list is empty, an empty list is returned within the KRR (and consequently, the communication will fail).
the receiver list is unchanged.

Case D)

For KRRs exiting the domain towards a MC client domain (outbound CS Proxy), a new KRR is created if the contents of the initiator KMS URI list contains a KMS URI that is not acceptable. This could be as the KMS is not supported given the user's current state, location or juristriction. Within the new KRR in this case:

the initiator list is reduced to remove the unacceptable KMS URIs. If the list is empty, an empty list is returned within the KRR (and consequently, the communication will fail).
the receiver list is unchanged.

Should the network entity create a new KRR, the received KRR is dropped and the new KRR is forwarded to the initiator. Entities in the path receiving a KRR shall forward the KRR towards the initiating IDRi.

The new KRR contains the received KRR. Consequently, the KRR could contain multiple sub-KRRs. It is recommended that a maximum of 5 sub-KRRs are supported.

5.2.8.2.5 KMS Selection at the initiator p. 50

Where the initiator is distributing a key to a receiver (e.g. at the beginning of a private call) it is possible that a KMS selection procedure needs to be performed by the initiator. The KMS selection procedure results in the choice of an initiator and receiver KMS (IDRkmsi and IDRkmsr) for the MIKEY message.

The KMS selection procedure is only required in two situations:

Initial distribution of a key where the receiver's KMS is not known (e.g. the receiver's KMS is not listed in the user profile, the group document, or known due to previous communication).
Upon receipt of a KRR due to a previous attempt to distribute a key.

In the first case, (ANY, ANY) is used as the initiator KMS list and receiver KMS list pair. Otherwise the initiator KMS list and receiver KMS list is provided within the KRR.

Using the provided initiator KMS list and receiver KMS list, the initiator shall select the initiator KMS and receiver KMS based on the following procedure:

For the initiator KMS list, the initiator shall:
1. If the initiator KMS list is 'ANY' the initiator shall populate the KMS list with the Home KMS and with all provisioned Migration KMSs.
2. If the KMS list is not empty, the initiator shall create a reduced list of all KMS URIs that do not belong to the initiator's Home KMS or to a provisioned Migration KMS. If the reduced list still contains at least one KMS URI; then:
  1. The initiator may apply local policy to select a KMS URI from the reduced list; the initiator shall use the selected KMS (to sign the MIKEY message); else
  2. If the KMS list contains the initiator's Home KMS URI; the initiator shall use the Home KMS (to sign the MIKEY message); else
  3. The initiator shall select the first KMS URI from the list. The initiator shall use the selected KMS (to sign the MIKEY message);
3. If the reduced list contains no KMS URIs, then the communication fails.
For the receiver KMS list, the initiator shall:
1. If the receiver KMS list is 'ANY' the initiator shall populate the receiver KMS list with the initiator's Home KMS, with all provisioned Migration KMSs and with all provisioned External KMSs.
2. If the receiver KMS list is not empty, the initiator shall create a reduced list of all KMS URIs that do not belong to the initiator's Home KMS, to a provisioned Migration KMSs or to an External KMS. If the reduced list still contains at least one KMS URI; then:
  1. The initiator may apply local policy to select a KMS URI from the reduced list; the initiator shall use the selected KMS (to encrypt the MIKEY message); else
  2. If the KMS list contains the initiator's Home KMS URI; the initiator shall use the Home KMS (to encrypt the MIKEY message); else
  3. The initiator shall select the first KMS URI from the list. The initiator shall use the selected KMS (to encrypt the MIKEY message);
3. If the reduced list contains no KMS URIs, then the communication fails.

If an initiating and receiving KMS has been successfully selected, the initiator shall send a new MIKEY message using the selected KMSs. If not, the communication fails.

The purpose of KMS Discovery / Redirection procedures is to allow session key distribution where the KMS used by the receiver is not known. It also allows policy to be applied to ensure the KMS used by the receiver and initiator is acceptable along the path of the communication.

The key message is a KMS Redirect Response (KRR) which conveys KMS policy to the initator. The initiator could be a MC client or GMS. Sometimes multiple messages and KRR exchanges will be required to establish a suitable choice of (KMS initiator, KMS receiver) pair. It is also possible that there is no acceptable choice, and as a result of the process the communication fails.

5.2.8.3 Security procedures for KMS Redirection Response p. 51

The KMS Redirect Response (KRR) procedure allows for MC Services to negotiate and inform an MCX entity about which security domains (KMS URIs) are acceptable for an MCX session.

Prior to beginning this process, it is assumed that:

The initiating user has been provisioned by its Home KMS with some information on the permitted external security domains, including the KMS certificate of External KMSs.
The terminating user has been provisioned by its Home KMS with some information on the permitted external security domains, including the KMS certificate of External KMSs.

A user shall only communicate with its Home KMS. External KMS Certificates shall be manually loaded onto the Home KMS and distributed to the user as part of the KMS's user key management processes.

The procedure for security domain redirection is shown in Figure 5.2.8.3-1.

Copy of original 3GPP image for 3GPP TS 33.180, Fig. 5.2.8.3-1: Security domain redirection

Figure 5.2.8.3-1: Security domain redirection
(⇒ copy of original 3GPP image)

The procedures in Figure 5.2.8.3-1 are now described in detail. Where the security domains (KMS URIs) used by the initiating client are acceptable to the MC Service(s) and terminating client, communication proceeds as normal. However, where the initiating client uses security domain(s) (KMS URIs) that are rejected along the signalling path or by the terminating client, the following procedures take place:

The initiating client or function initiates a session with a user or function. It is assumed that the receiver's KMS is not known (not listed in the initiator's user profile or group document and there has not been a previous successful communication), hence the the client performs the procedure in clause 5.2.8.2.5 to select the KMS URIs to use in the MIKEY message.

The initiating client sends the communication request to the initiating application server. Under normal conditions the server routes the request on the normal signalling path.

1a)

Should the incorrect security domain(s) (KMS URIs) be used (based on local policy or the policies of the terminating security domain), the server will not forward on the request and may send a KRR message back to the client using the procedures in clause in 5.2.8.2.3.

If the communication request is forwarded on the normal signalling route, the other application server should receive the request.

2a)

Should an unacceptable security domain(s) be used (based on local policy or the policies of the terminating security domain), the other application server shall not forward on the request and may send a KRR message to the initiating application server using the procedures in clause in 5.2.8.2.3.

2b)

Upon receiving a KRR message from the other application server, the application server may replace the 'security domain redirect response' message with another KRR message using the procedures in clause 5.2.8.2.4, before forwarding the message down the normal signalling path.

Should the request be forwarded on the normal signalling route to the terminating client or function, the terminating MCX entity should receive the request.

3a)

The terminating client may determine that the security domains used by the initiating client are not permitted. In this case, the terminating client may send a KRR message containing permitted security domains back to the initiating client using the procedures in clause 5.2.8.2.2.

3b)

Upon receiving a KRR message and based on local policy, the other application server may replace the KRR message using the procedures in clause 5.2.8.2.4, before forwarding the message down the normal signalling path to the initial application server.

3c)

Upon receiving a KRR message and based on local policy, the initial application server may replace the KRR using the procedures in clause 5.2.8.2.4, before forwarding the message down the normal signalling path to the client.

On receiving a KRR, the initiator will perform the procedures in clause 5.2.8.2.5, and may repeat the above procedure from step 1. Upon next connection to the Home KMS, the initiating client should upload the received KRR message to allow fraud detection.

A MC client shall only accept external security domains that have been permitted by the home security domain and provisioned by the Home KMS. The Home KMS may also provision policy around the use of external security domains, see clause 5.2.8.5.

5.2.8.4 Security Procedures for reporting external security domain use p. 53

Domain administrators should only allow users to communicate with trusted external security domains. Should an external security domain be misused, it is possible that users could be impersonated within the MCX system (in the same way that misuse of a CA compromises communications that trust that CA). To allow such misuse to be detected, and the associated KMS certificates to be revoked, clients should report the use of external security domains to the Home KMS.

5.2.8.5 Policy around use of external security domains p. 53

The following are policies that the Home KMS may apply around the use of external security domains.

Allow KRRs (yes/no). If no, all KRRs shall be ignored.
Report KRRs to the Home KMS (yes/no).
Require signed KRRs (yes/no). If no, all unsigned KRRs shall be ignored.
Request unknown KMS certificates (yes/no). If yes, should an unknown external KMS certificate be in the list of receiving KMS URI(s) in the KRR, the client shall request this certificate from the Home KMS as defined in Annex D.
Hold communication until KMS acceptance (yes/no). If yes, the client will not act upon any KRRs until the Home KMS has provided a notification that the redirect is acceptable (or otherwise), as defined in Annex D.