As defined in TS 23.434, the SEAL-X1 reference point, exists between the key management server and the group management server and uses HTTP-1 as defined in TS 23.434 for the transport and routing of security related information to the group management server. The SEAL-X1 shall be protected using HTTPS as defined in RFC 6749, RFC 6750 and OpenID Connect 1.0 . The profile for TLS implementation and usage shall follow the provisions given in TS 33.310, Annex E.
The SEAL-X2 reference point enables the group management server to interact with the location management server as defined in TS 23.434. The SEAL-X2 shall be protected using HTTPS as defined in RFC 6749, RFC 6750 and OpenID Connect 1.0 . The profile for TLS implementation and usage shall follow the provisions given in TS 33.310, Annex E.
IM-UU reference point is used between the identity management client and the identity management server. The IM-UU between the Identity Management client and the Identity management server shall be protected using HTTPS as defined in RFC 6749, RFC 6750 and OpenID Connect 1.0 . The profile for TLS implementation and usage shall follow the provisions given in TS 33.310, Annex E.
The KM-UU and the KM-S are direct HTTP connections between the Key Management Server and Key Management Client and shall be protected using HTTP over TLS as defined in RFC 6749, RFC 6750 and OpenID Connect 1.0 . The profile for TLS implementation and usage shall follow the provisions given in TS 33.310, Annex E.
A SEAL client interacts with a SEAL server over the generic SEAL-UU reference point as defined in TS 23.434. The protection of this interface shall be supported according to NDS/IP as specified in TS 33.210.
The VAL client interacts with a SEAL client over the SEAL-C reference point as defined in TS 23.434. This reference point resides fully within the UE and therefore, security of this interface is left to the manufacturer and is out of scope for the present document.
In order to authenticate the HTTP-1 reference point, authentication mechanisms shall be performed between the HTTP client and VAL UE using either certificate based authentication or pre-shared key based authentication. Certificate based authentication shall follow in Annex B of TS 33.222, and the profiles given in TS 33.310. The usage of pre-shared key based ciphersuites is specified in the TLS profile given in TS 33.310, Annex E.
The HTTP-1 reference point exists between the VAL UE and the HTTP proxy. The HTTP-2 exists between the HTTP proxy and HTTP server. The HTTP-3 reference point exists between the HTTP proxies in different networks. The HTTP interfaces shall be protected using TLS. The profile for TLS implementation and usage shall follow the provisions given in TS 33.310, Annex E.
A VAL UE shall perform the authentication and security mechanisms as specified in TS 33.501 for 5G network access security.
To ensure security of the interfaces between network entities within a trusted domain and between trusted domains, TS 33.210 shall be applied to secure signalling messages on the reference points unless specified otherwise. SEG as specified in TS 33.210 may be used in the trusted domain to terminate the IPsec tunnel.
Figure 5.2.3-1 shows the Identity Management functional model which consists of the SEAL Identity Management Server (SIM-S) and SEAL Identity Management Client (SIM-C) of the UE. The IM-UU reference point between the SIM-S and SIM-C shall provide the interface for user authentication and shall support OpenID Connect 1.0  and OAuth 2.0 ,  to obtain an access token for the VAL UE.
SEAL Service Authorization procedure shall validate the VAL user to access the SEAL services. In order to gain access to SEAL services, the SEAL client shall present an access token to the SEAL server for each service of interest. If the access token is valid, then the client shall be granted to use the service.
The SEAL Identity Management Server (SIM-S) and the SEAL Identity Management Client (SIM-C) provide the endpoints for VAL user authentication as shown in the SEAL Identity Management functional model in figure 5.2.3-1.
The reference point IM-UU utilizes Uu reference point as described in TS 23.401 and TS 23.501. IM-UU shall support OpenID Connect 1.0  and OAuth 2.0  for VAL user authentication.
(not reproduced yet)
Figure 5.2.3-1: Functional model for SEAL Identity Management
In order to support VAL user authentication, the SIM-S shall be provisioned with the VAL user ID and VAL service IDs (usage of VAL user ID and VAL service ID is described in clause 7 of TS 23.434). A mapping between the VAL user ID and VAL service ID(s) shall be created and maintained in the SIM-S. When a VAL user wishes to authenticate for the VAL services, the VAL user ID and credentials are provided via the UE Identity management client to the SIM-S as per OpenID Connect 1.0 . The SIM-S receives and shall verify the VAL user ID and credentials. If verification is successful, then the SIM-S returns an ID token, refresh token and access token to the UE Identity management client. The SIM-C shall learn the user's VAL service ID(s) from the ID token. Table 5.2.3-1 shows the SEAL specific tokens and their usage.
Figure 5.2.4-1 describes the VAL Authentication Framework using the OpenID Connect protocol. It describes the steps by which a VAL UE authenticates to the SIM-S, resulting in a set of credentials delivered to the UE uniquely identifying the VAL service ID(s). The authentication framework supports extensible user authentication solutions based on the VAL service provider policy (shown as step 3). User authentication methods in support of step 3 (e.g. biometrics, secureID, etc.) are possible but not defined here.
(not reproduced yet)
Figure 5.2.4-1: OpenID Connect (OIDC) flow supporting VAL user authentication
SIM-S sends an OpenID Connect Token Response to the UE containing an ID token and an access token (each which uniquely identify the user of the VAL service or key management service). The ID token is consumed by the UE to personalize the VAL client for the VAL user, and the access token is used by the UE to communicate and authorize the identity of the VAL user to the VAL server(s) and the VAL services.
Authorization framework is shown in Figure 5.2.5-1. A secure HTTP tunnel using HTTPS between VAL UE and VAL server shall be established before VAL service authorization. Subsequent VAL service authorization messaging make use of this tunnel. The service clients in the VAL UE present the access tokens to the VAL server over HTTP. The VAL server authorizes the user for the requested services only if the access token is valid. The procedures may be repeated as necessary to obtain additional VAL user authorizations.
(not reproduced yet)
Figure 5.2.5-1: VAL User Service Authorization
After the VAL UE establishing a secure connection with the VAL server, the VAL UE sends an HTTP message containing the access token to the VAL server where service authorization is requested. The VAL server receives the message and validates the access token. If the access token is valid, The VAL server positively acknowledges the request. The VAL server may provide service related information to the VAL UE at this time.
To enable security for VAL services, a SEAL KM client (located in either a SEAL 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.
(not reproduced yet)
Figure 5.3.1-1: SEAL key management procedure
The procedure in Figure 5.3.1-1 is described here:
A SKM-C may send a SEAL KM Request message to the SKM-S. This request shall be protected (via the HTTPS tunnel) 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 version number of the SEAL key management request.
The URI of the SKM-S to which the request is sent.
A string representing the VAL service/application related to the VAL client request.
(Optional) A string representing the client. See note.
(Optional) A string representing the device. See note.
(Optional) A string representing the user. See note.
The Date and Time of the request. This number represents the number of seconds from 1970-01-01T0:0:0Z as measured in UTC.
Only one of these fields may be present in any given SEAL KMS Request message.
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. The method used to provision the VAL service or VAL application key material into the KMS is out of scope for the present document. 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 via the HTTPS tunnel. 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.
URI of the user for which the response is intended.
The URI of the SKM-S sending the response.
A string representing the VAL service/application related to the VAL client request. This is the same field as received in the SEAL KM Request message.
(Optional) The ID of the SKM-S providing the response message.
(Optional) A string representing the client (see note)
(Optional) A string representing the device (see note)
(Optional) A string representing the user. (see note)
The Date and Time of the response. This number represents the number of seconds from 1970-01-01T0:0:0Z as measured in UTC.
(Optional) Reason code indicating the failure of the requested action. If not present, the key management request is assumed to be successful.
(Optional) Key management payload specific to the VAL user, client or application. This field is not be present if an error occurs.
If this field is present in the SEAL KM Request message then this field shall be present in the SEAL KM Response message and shall be the same value.
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.
"500 Internal Server Error" as described in Table 5.2.6-1 of TS 29.122
Key Information not available for specified service, client, device or user.
"404 Not Found" as described in Table 5.2.6-1 of TS 29.122
"401 Unauthorized" as described in Table 5.2.6-1 of TS 29.122
Unable to validate request
"400 Bad Request" or "403 Forbidden" as described in Table 5.2.6-1 of TS 29.122
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).
Interconnection between a primary VAL system and a partner VAL system is specified in TS 23.434.
A VAL client shall perform user authorization only to VAL servers within their own VAL system. When communication is required by a VAL client from another interconnected VAL system, user authorization takes place in the serving VAL system and follows the VAL user service authorization procedures as defined in clause 5.2.
VAL systems should protect themselves at the system border from external attackers.