D.2 KMS requests

33.1793GPPRelease 13Security of Mission Critical Push To Talk (MCPTT) over LTETS

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

Requests to the KMS are made to specific resource URIs. 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 1:

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

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

…/keymanagement/identity/v1/init

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

EXAMPLE 3:

…/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 "u sip:ser@example.org" is provisioned via a request to: "/keymanagement/identity/v1/keyprov/usip%3Aser%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 4:

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

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 5:

…/keymanagement/identity/v1/certcache/12345

If the optional security extension is used, requests may be authenticated using the shared Transport Key (TrK). To achieve this, the request should be accompanied with an XML payload containing details of the request, signed by the shared TrK.