D.2 KMS requests

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

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

D.2.1 General

Requests to the KMS are made to specific resource URIs. Requests are made using a HTTP POST request to a URI. The content of the URI indicates the type of request. Resource URIs are rooted under the tree "/keymanagement/identity/v1" for a particular domain.

For example, the resource path to initialize a user within the domain "example.org" is:

EXAMPLE:

http://example.org/keymanagement/identity/v1/init

D.2.2 KMS request security

The content of the KMS Request Type XML payload is:

Table D.2.2-1: Contents of a KMS Request Type XML

Name	Description
Version	(Attribute) The version number of the key provision XML (1.1.0).
UserUri	URI of the user for which is making the request.
KmsUri	The URI of the KMS to which the request is sent.
ClientId	(Optional) A string representing the client
DeviceId	(Optional) A string representing the device
Time	Date/time that the request is made by the client.
ClientReqUrl	The resource URI to which the HTTP POST request is sent.
KrrList	(Optional) Zero or more KMS Redirect Responses (KRRs). Only used when posting to the ‘redirect’ subdirectory.
ClientError	(Optional) If a previous failure had occurred, this complex type can provide error information to the KMS
TrK-ID	(Optional) The ID of the TrK used for confidentiality protection of key management payloads.
Signature-ID	(Optional) The ID of the key used to sign KMS messages.

When application confidentiality is required by the MC operator, the TrK-ID of the TrK currently residing in the MC UE shall be included in the KMS request message as shown in Table D.2.2-1.

When a signature is applied to the KMS request, the Signature-ID field in Table D.2.2-1 shall be present and indicate either the InK-ID if the InK is used or the TrK-ID if the TrK is used. When a signature is applied and the InK is present, the InK shall be used. When a signature is applied and an InK is not present but a TrK is present, then the TrK shall be used.

The XML schema for the SignedKmsRequestType is provided in Clause D.3.5.1.

An optional security extension may be used to authenticate the KMS request from the client. To use the optional security extension, the POST request shall be accompanied with an XML payload MIME type containing details of the request, signed by the shared InK or TrK.

If the KMS supports authenticated requests, upon receipt of a SignedKmsRequestType attached to a KMS Request, the KMS shall verify that:

– the signature is valid, based on the UserUri and the InK or TrK used to sign the message.

– the XML is valid.

– the KmsUri is the KMS’s KMS URI.

– the Time is within a recent time window (e.g. 5 seconds).

– the ClientReqUrl is the same as the resource URI to which the HTTP POST request is sent.

If so, the request is accepted and processed.

D.2.3 KMS Initialize request

To make a "KMS Initialize" request the key management client shall make a HTTP POST request to the subdirectory "init" i.e. Request-URI takes the form of:

EXAMPLE:

…/keymanagement/identity/v1/init

D.2.4 KMS KeyProvision request

To make a "KMS KeyProvision" request the key management client shall make a HTTP POST request to the subdirectory "keyprov" i.e. Request-URI takes the form of

EXAMPLE1:

…/keymanagement/identity/v1/keyprov

Optionally, the Request-URI of the POST request may contain a specific user or group URI which the key management client would like the KMS to provision. The URI shall be within a subdirectory of "keyprov". For example, the user URI "sip:user@example.org" is provisioned via a request to: "/keymanagement/identity/v1/keyprov/sip%3Auser%40example.org". Additionally, if the Request-URI contains a specific URI, the client may also request a specific time which the client would like the KMS to provision. The time URI shall be the same time as used in the MIKEY payload, a NTP-UTC 64-bit timestamp as defined in IETF RFC 5905 [29]. For example, if the user required keys specifically for 23^rd Feb 2014 at 08:39:14.000 UTC, the request would be:

EXAMPLE 2:

…/keymanagement/identity/v1/keyprov/sip%3Auser%40example.org/D6B4323200000000

D.2.5 KMS CertCache request

To make a "KMS CertCache" request the key management client shall make a HTTP POST request to the subdirectory "certcache". For example, the request-URI takes the form of "/keymanagement/identity/v1/certcache". If a cache has been previously received, the request URI may optionally be directed to the subdirectory indicating the number of the client’s latest version of the cache. For example, the request-URI takes the form of

EXAMPLE:

…/keymanagement/identity/v1/certcache/12345

D.2.6 KMS Cert request

"KMS Cert" requests are used to request the KMS certificate of a specific external KMS, referenced by the KMS’s KMS URI.

To make a "KMS Cert" request the key management client shall make a HTTP POST request to the subdirectory "cert". Within the subdirectory "cert", the POST request shall contain a specific KMS URI of the External KMS. For example, the request-URI takes the form:

EXAMPLE:

…/keymanagement/identity/v1/cert/kms.example.org

D.2.7 KMS Lookup request

"KMS Discovery Lookup" requests are used to request the KMS certificate of a specific entity, referenced by the entity’s URI.

To make a "KMS Discovery Lookup" request the key management client shall make a HTTP POST request to the subdirectory "lookup". Within the subdirectory "lookup", the POST request shall contain a specific SIP URI of the entity. For example, the request-URI takes the form:

EXAMPLE:

…/keymanagement/identity/v1/lookup/user%40example.org

The KMS responds with a list of permitted KMS URIs for the target entity.

D.2.8 KMS Redirect Upload

"KMS Redirect Upload" messages are used to upload KMS Redirect Responses (KRRs) to the KMS for audit purposes.

To send a "KMS Redirect Upload" message the key management client shall make a HTTP POST request to the subdirectory "redirect". Within the subdirectory "redirect", the POST request shall contain a specific SIP URI of the entity that resulted in the received KRR. For example, the request-URI takes the form:

EXAMPLE:

…/keymanagement/identity/v1/redirect/user%40example.org

The POST message shall be accompanied with an MIME type containing a "KMS Request Type" XML payload (as defined in Clause D.2.2). The XML payload shall contain one or more KMS Redirect Responses (KRRs). The "KMS Request Type" XML payload may also be signed as defined in Clause D.2.2.