5.2.8 KMS Redirect Responses (KRRs)

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

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.2.8.1 Overview of KMS Redirect Response procedure (KRR)

5.2.8.1.1 General

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

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

5.2.8.2.1 Content of KRRs

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

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).

1) The KRR initiator list is populated as follows:

a) 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.

b) 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).

2) The KRR receiver list is populated as follows:

a) 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.

b) 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

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:

1. 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.

2. 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:

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

2. the receiver KMS URI list is ‘ANY’.

NOTE 1: This case is primarily used where the initiator has migrated out of the domain, meaning that the user’s traffic is transiting the domain, but ultimately enters/exits the domain via an IS Proxy.

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:

1. the initiator KMS URI list is ‘ANY’.

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

NOTE 2: This case is primarily used where the receiver has migrated out of the domain, meaning that the user’s traffic is transiting the domain, but ultimately enters/exits the domain via an IS Proxy.

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

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:

1. the initiator list is unchanged.

2. 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:

1. the initiator list is unchanged.

2. 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:

1. 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).

2. 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:

1. 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).

2. 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

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:

1. For the initiator KMS list, the initiator shall:

a. If the initiator KMS list is ‘ANY’ the initiator shall populate the KMS list with the Home KMS and with all provisioned Migration KMSs.

b. 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:

i. 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

ii. If the KMS list contains the initiator’s Home KMS URI; the initiator shall use the Home KMS (to sign the MIKEY message); else

ii. The initiator shall select the first KMS URI from the list. The initiator shall use the selected KMS (to sign the MIKEY message);

d. If the reduced list contains no KMS URIs, then the communication fails.

2. For the receiver KMS list, the initiator shall:

a. 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.

b. 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:

i. 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

ii. If the KMS list contains the initiator’s Home KMS URI; the initiator shall use the Home KMS (to encrypt the MIKEY message); else

ii. The initiator shall select the first KMS URI from the list. The initiator shall use the selected KMS (to encrypt the MIKEY message);

d. 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

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.

Figure 5.2.8.3-1: Security domain redirection

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.

1. 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.

2. 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.

3. 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.

4. 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.

NOTE 1: It is possible that the MC client receives a KRR either unsigned or signed using a KMS URI that is not recognised/provisioned. In this case, it is subject to policy (determined by the Home KMS) whether the redirect is accepted, see clause 5.2.8.5.

NOTE 2: Under the most stringent policy, the KMS a policy may be implemented that requires the client to hold the communication until the Home KMS has responded with notification that the redirect is acceptable, see clause 5.2.8.5.

5.2.8.4 Security Procedures for reporting external security domain use

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

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.