Content for  TS 33.434  Word version:  18.2.0

To enable security for VAL services, a SEAL KM client (located in either a VAL UE or VAL server) may request key material applicable to a particular VAL service, VAL client or user. Prior to making a key management request to the SEAL KMS (SKM-S), the VAL client or VAL user shall be authenticated by the SEAL identity management service (clause 5.2). In addition, secure connections shall be established between the SEAL client and the SKM-S (reference point KM-UU) and the VAL server and the SKM-S (reference point KM-S) prior to any associated key management requests. As a result of the SEAL identity management authentication procedure, an access token scoped for key management services is provisioned to the SEAL UE. This access token is provided with each and every key management request to the SKM-S. A VAL server is provisioned with an access token scoped for SEAL key management services and is provided with each and every key management request to the SKM-S. The method for provisioning this access token into the VAL server is out of scope of the present document. Figure 5.3.1-1 shows the SEAL key management procedure. A SKM client may send a SEAL KM Request message to the SKM-S. The SKM-S validates and processes the request and responds with a SEAL KM Response message. The response contains key management material specific to the SEAL service or the VAL server request, or alternatively, an error code if the SKM-S encounters a failure condition.

The procedure in Figure 5.3.1-1 is described here: As a successful result of this procedure, the VAL UE or VAL Server has securely obtained service specific key material for use within the VAL system.

A SKM-C may send a SEAL KM Request message to the SKM-S. This request shall be protected (using the mechanism specified in clause 5.1.1.4) and shall contain the access token acquired during the SEAL identity management authentication procedure (clause 5.2). The content of the SEAL KM Request is shown in Table 5.3.2-1.

The identities listed in Table 5.3.2-1 map to SEAL identities defined in TS 23.434. Namely, the ServiceID maps to the VAL service identity (VAL service ID), the ClientID maps to the VAL client or client on the VAL server, the DeviceID maps to the VAL UE identity (VAL UE ID), and the UserID maps to the VAL user identity (VAL user ID). The 'Version' field identifies the version of the SEAL KM Request message. The current version is defined as "1.0.0". The 'Date/Time' field is used primarily as an anti-replay mechanism for SEAL key management requests and responses. If the 'Date/Time' field is significantly out of range (more than a few seconds), this could indicate a replay attack. Upon receipt of a SEAL KM Request message, the SKM-S shall verify that:

• the access token is valid;
• the signature is valid;
• the SKmsUri is the SKM-S URI of the target SEAL KMS where the key information is stored; and
• the Date/Time is within a recent time window (e.g. 5 seconds).

If valid, the request is accepted and processed by the SKM-S. A standalone ServiceID, or a ServiceID in combination with a ClientID, DeviceID, or UserID may be present in the SEAL KM Request message. This combination may be used by the KMS to identify a specific key material record. Each key management record may be unique to a VAL application or VAL service. The format and content of a key management record is defined and securely provisioned into the SEAL KMS by the VAL application or VAL service owner/operator. A SEAL KM client (SKM-C) located in the VAL server may use the SEAL key provisioning procedure described in clause 5.8 to provision the VAL service or VAL application key material into the KMS. The method used to organize, manage, and maintain VAL service or VAL application key material within the KMS is out of scope of the present document.

The SEAL KM Response message is sent to the SKM-C in response to a SEAL KM Request message. A successful SEAL key management procedure results in a SEAL KM Response message, which typically includes a payload containing key management information uniquely applicable to the requested service, client or user. If an error occurs, an error code may be returned in the SEAL KM Response message. The SEAL KM Response message shall be protected in transit using the mechanism specified in clause 5.1.1.4. The Payload within a SEAL KM Response message may be protected end-to-end between the SKM-C and SKM-S depending on the applicability of the underlying VAL service making the request. The method for securing a Payload end-to-end between the SKM-C and the SKM-S is outside the scope of the present document. The key material contents provided in a Payload are defined by the underlying VAL service and are outside the scope of the present document. The content of a SEAL KM Response message is shown in Table 5.3.3-1.

The identities listed in Table 5.3.3-1 are described in clause 5.3.2. If the SKM-S does not encounter an error during processing of the SEAL KM Request message, the SEAL KM Response message carries a set of security parameters contained in the "Payload" field. If the SKM-S encounters an error while processing the SEAL KM Request message, an error value described in Table 5.3.3-2 shall be returned in the 'ErrorCode' field of the SEAL KM Response message and the 'Payload' field shall not be present. In the event of an error, the user and/or the operator of the VAL service, UE, or client may be notified.

The selection of the key material returned in the Payload of a SEAL KM Response message is determined by the ServiceID and (optionally) the ClientID, DeviceID or UserID. The combination of the ServiceID with the ClientID, DeviceID or UserID allows the VAL service to request a more specific set of key material. For example, if a ClientID is included in the SEAL KM Request message, the KMS may return a Payload that contains a set of client specific key material applicable to the ClientID within the requesting VAL service (ServiceID). If the DeviceID is included, the KMS may return a Payload that contains device specific key material applicable to the DeviceID within the requesting VAL service (ServiceID). If the UserID is included, the KMS may return a Payload that contains user specific key material applicable to that UserID within the requesting VAL service (ServiceID).

The SEAL key provisioning procedure may be used by a SEAL KM client (SKM-C) located in a VAL server to provision key information applicable to a particular VAL service, VAL client, VAL device, or VAL user. A VAL server shall be provisioned with an access token scoped for SEAL key provisioning services. The method for provisioning this access token into the VAL server is out of scope of the present document. The VAL server using the SKM-C shall provide this access token with every key provisioning request made to the SKM-S. In addition, a secure connection shall be established between the SKM-C and the SKM-S prior to any associated key provisioning requests. The KMS shall authenticate and validate the presented access token (i.e. verifying that the SKeyProv parameter defined in clause A.2.2.3 is provided and correct), and shall validate that the requesting SKM-C has the authorization to perform key provisioning. Figure 5.8.1-1 shows the SEAL key provisioning procedure. A SKM-C may send a SEAL Key Provisioning Request message to the SKM-S. The SKM-S shall validate and process the request and respond with a SEAL KP Response message. The request contains key information specific to a particular VAL service, VAL client, VAL device, or VAL user. The SEAL KP Response message provides either an acknowledgement or an error code (if the SKM-S encounters a failure condition).

The procedure in figure 5.8.1-1 is described here: As a successful result of this procedure, the VAL Server has securely provisioned specific key information for use within the VAL system for a particular VAL service, VAL device, VAL client, or VAL user.

An authorized SKM-C may send a SEAL KP Request message to the SKM-S. This request shall be protected (using the mechanism specified in clause 5.1.1.4) and shall contain the access token scoped for SEAL key provisioning (clause A.2). The content of the SEAL KM Request is shown in Table 5.8.2-1.

The identities listed in Table 5.8.2-1 map to SEAL identities defined in TS 23.434, and identify the endpoints targets of the key information (Payload). Namely, the ServiceID maps to the VAL service identity (VAL service ID), the ClientID maps to the VAL client or client on the VAL server, the DeviceID maps to the VAL UE identity (VAL UE ID), and the UserID maps to the VAL user identity (VAL user ID). The 'Version' field identifies the version of the SEAL KP Request message. The current version is defined as "1.0.0". The 'Date/Time' field is primarily as an anti-replay mechanism for SEAL key provisioning requests and responses. If the 'Date/Time' field is significantly out of range (more than a few seconds), this could indicate a replay attack. Upon receipt of a SEAL KP Request message, the SKM-S shall verify that:

• the access token is valid and contains the SKeyProv field;
• the signature is valid;
• the requesting SKM-C is authorized for key provisioning;
• the SKmsUri is the SKM-S URI of the target SEAL KMS where the key information shall be stored; and
• the Date/Time is within a recent time window (e.g. 5 seconds).

If valid, the request is accepted and processed by the SKM-S. A standalone ServiceID, or a ServiceID in combination with a ClientID, DeviceID, or UserID may be present in the SEAL KP Request message. This combination may be used by the KMS to map the key material in the Payload with a specific client, device, or user. The format and content of a key provisioning Payload is defined by the VAL application or VAL service owner/operator and is out of scope of this document. For example, such content may include VAL specific keys, additional tokens, credentials, or other important security related information. The method used to organize, manage, and maintain VAL service or VAL application key material within the KMS is out of scope of the present document.

The SEAL KP Response message is sent by the SKM-S to the SKM-C in response to a SEAL KP Request message. A successful SEAL key provisioning procedure results in the KMS sending a SEAL KP Response message containing an acknowledgement indicating the KMS successfully received and processed the SEAL KP Request message. If the KMS is unable to successfully process the SEAL KP Request message, the KMS may instead return an error code in the SEAL KP Response message. The SEAL KP Response message shall be protected in transit using the mechanism specified in clause 5.1.1.4. The content of a SEAL KP Response message is shown in Table 5.8.3-1.

The identities listed in Table 5.8.3-1 are described in clause 5.8.2. If the SKM-S encounters an error while processing the SEAL KP Request message, an error value described in Table 5.8.3-2 should be returned in the 'ErrorCode' field of the SEAL KP Response message. In the event of an error, the user and/or the operator of the VAL service may be notified.