Content for TS 33.434 Word version: 17.3.0

5.1 Security for the SEAL interfaces 5.1.1 Security for the Application plane interfaces 5.1.2 Security for the Signalling control plane interfaces 5.1.3 Security for the network domain interfaces 5.2 User authentication and authorization 5.3 SEAL key management procedure 5.4 Security procedures for interconnection 5.5 Authentication and authorization of devices over LWP interfaces
...

5 Procedures p. 9

5.1 Security for the SEAL interfaces p. 9

5.1.1 Security for the Application plane interfaces p. 9

5.1.1.1 SEAL-X1 p. 9

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 [5]. The profile for TLS implementation and usage shall follow the provisions given in TS 33.310, Annex E.

5.1.1.2 SEAL-X2 p. 9

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 [3], [4] and [5] . The profile for TLS implementation and usage shall follow the provisions given in TS 33.310, Annex E.

5.1.1.3 IM-UU p. 9

IM-UU reference point is used between the identity management client and the identity management server. The security mechanism of SEAL-UU shall also be used for IM-UU.

The security established between the identity management server and the identity management client should be end-to-end. When this is not possible, then all sensitive material transferred between the identity management server and identity management client should be end-to-end protected with a mechanism that is out of scope of this document.

5.1.1.4 KM-UU and KM-S p. 10

The KM-UU reference point is used between the Key Management Client and Key Management Server. The security mechanism of SEAL-UU shall also be used for KM-UU.

The KM-S reference point is a direct HTTP connection used between the VAL server and the key management server and shall be protected with the same mechanism used for the SEAL-S reference point.

The security established between the KM Server and the KM client should be end-to-end. When this is not possible, then all client related material transferred between the KM server and KM client should be end-to-end protected with a mechanism that is out of scope of the present document.

5.1.1.5 SEAL-UU p. 10

A SEAL client interacts with a SEAL server over the generic SEAL-UU reference point as defined in TS 23.434.. This interface shall be protected using HTTPS as defined in [3], [4] and [5] when using HTTP. The profile for TLS implementation and usage shall follow the provisions given in TS 33.310, Annex E. When using CoAP [18], the SEAL-UU between the SEAL client and the SEAL server shall be protected as defined in [19] (e.g., DTLS, TLS or OSCORE) with the additional security enhancements specified in [22]. When (D)TLS is used with CoAP, the (D)TLS and certificate profiling shall follow TS 33.210 and TS 33.310. When OSCORE is used with CoAP, the mandatory to implement provisions given by RFC 8613 shall be followed.

5.1.1.6 VAL-UU p. 10

The VAL client interacts with VAL server over VAL-UU reference point as defined in TS 23.434.

5.1.1.7 SEAL-C p. 10

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.

5.1.1.8 SEAL-S p. 10

The VAL server interacts with SEAL server over SEAL-S 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.

When CAPIF is not used, then TLS and OAuth 2.0 [3] shall be supported. When TLS is used, mutual authentication based on client and server certificates shall be performed between the SEAL server and VAL server using TLS. Certificate based authentication shall follow the profiles given in clause 6.1.3a of TS 33.310. The identities in the end entity certificates shall be used for authentication and policy checks. The structure of the PKI used for the certificate is out of scope of the present document. TLS shall be used to provide integrity protection, replay protection and confidentiality protection for the interface between the SEAL server and the VAL server. Security profiles for TLS implementation and usage shall follow the provisions given in clause 6.2 of TS 33.210. After the authentication, the SEAL server determines whether the VAL server is authorized to send requests to the SEAL server. The SEAL server shall authorize the requests from VAL server using OAuth-based authorization mechanism, the specific authorization mechanisms shall follow the provisions given in RFC 6749.

When CAPIF is used as specified in TS 23.434, the security mechanism for CAPIF specified in TS 33.122 shall be followed. CAPIF core function shall choose the appropriate CAPIF-2e security method as defined in the clause 6.5.2 of TS 33.122 for mutual authentication and protection of the SEAL server - VAL server interface. Before invoking the API exposed by the SEAL server, the VAL server as API invoker shall negotiate the security method (TLS-PSK, PKI or TLS with OAuth token) with CAPIF core function and ensure the SEAL server has information to authenticate the VAL server.

5.1.1.9 SEAL-E p. 10

A SEAL server interacts with another SEAL server over SEAL-E 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.

5.1.2 Security for the Signalling control plane interfaces p. 11

5.1.2.1 Security for HTTP interfaces p. 11

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.

5.1.2.2 Security for LWP interfaces |R17| p. 11

Security mechanisms to be used to secure the LWP interfaces depend on the realization of the interfaces. The Annex B in the present document defines security mechanism for the realizations of LWP defined in Annex C of TS 23.434.

5.1.3 Security for the network domain interfaces p. 11

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.

5.2 User authentication and authorization p. 11

5.2.1 VAL user authentication p. 11

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 [5] and OAuth 2.0 [9], [10] when using HTTPS to obtain an access token for the VAL UE.

5.2.2 SEAL service authorization p. 11

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.

5.2.3 Identity management functional model p. 11

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 [5] and OAuth 2.0 [9] for VAL user authentication when using HTTPS.

Copy of original 3GPP image for 3GPP TS 33.434, Fig. 5.2.3-1: Functional model for SEAL Identity Management

Figure 5.2.3-1: Functional model for SEAL Identity Management
(⇒ copy of original 3GPP image)

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 [5] when using HTTPS. 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.

Table 5.2.3-1: VAL UE authentication token

Token Type	Consumer of the Token	Description
ID token	VAL UE client(s)	Contains the VAL service ID for at least one authorized VAL service.
Access token	SKM-S, SEAL service server(s)	Short-lived token (definable in the SIM-S) that conveys the UE's identity. This token contains the VAL service ID for at least one authorized service.
Refresh token	SIM-S (Authorization Server)	Allows VAL UE to obtain a new access token without forcing user to log in again.

To support the VAL service identity functional model, the VAL service ID(s):

Shall be provisioned into the SEAL Identity management database and mapped to VAL UE IDs.
Shall be provisioned into the SEAL Key management server (SKM-S) and mapped to UE specific key material.

5.2.4 Authentication framework p. 12

Figure 5.2.4-1 describes the VAL Authentication Framework using the OpenID Connect protocol. When using HTTPS, 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.

Copy of original 3GPP image for 3GPP TS 33.434, Fig. 5.2.4-1: OpenID Connect (OIDC) flow supporting VAL user authentication

Figure 5.2.4-1: OpenID Connect (OIDC) flow supporting VAL user authentication
(⇒ copy of original 3GPP image)

Step 1.

VAL UE establishes a secure tunnel with the SIM-S.

Step 2.

VAL UE sends an OpenID Connect Authentication Request to the SIM-S. The request may contain an indication of authentication methods supported by the UE.

Step 3.

User Authentication is performed between VAL UE and the SIM-S.

Step 4.

SIM-S sends an OpenID Connect Authentication Response to the UE containing an authorization code.

Step 5.

UE sends an OpenID Connect Token Request to the SIM-S, passing the authorization code.

Step 6.

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.

5.2.5 Authorization framework p. 13

Authorization framework when using HTTP 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.

Copy of original 3GPP image for 3GPP TS 33.434, Fig. 5.2.5-1: VAL User Service Authorization

Figure 5.2.5-1: VAL User Service Authorization
(⇒ copy of original 3GPP image)

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.

5.2.6 VAL service authorization p. 14

The VAL service authorization procedure shall validate the VAL user authorized to access the VAL services. In order to gain access to VAL services, the VAL client shall present an access token to the VAL server for each VAL service of interest (see clause 5.2.5). If the access token is valid, then the VAL client shall be granted use of the requested VAL service.

5.3 SEAL key management procedure p. 14

5.3.1 General p. 14

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.

Copy of original 3GPP image for 3GPP TS 33.434, Fig. 5.3.1-1: SEAL key management procedure

Figure 5.3.1-1: SEAL key management procedure
(⇒ copy of original 3GPP image)

The procedure in Figure 5.3.1-1 is described here:

Step 1.

The SKM-C establishes a secure connection, using the mechanism specified in clause 5.1.1.4, to the SKM-S. Steps 2 and 3 are within this secure connection.

Step 2.

The SKM-C sends a SEAL KM Request message to the SKM-S. The request contains the authorization credentials obtained during authentication and message content specified in clause 5.3.2.

Step 3.

The SKM-S authorizes the request and if valid, sends a SEAL KM Response message containing the requested key material (or error code) as specified in clause 5.3.3.

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.

5.3.2 SEAL KM Request message p. 15

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.

Table 5.3.2-1: Contents of a SEAL KM Request

Name	Description
Version	The version number of the SEAL key management request.
SKmsUri	The URI of the SKM-S to which the request is sent.
ServiceID	A string representing the VAL service/application related to the VAL client request.
ClientID	(Optional) A string representing the client. See note.
DeviceID	(Optional) A string representing the device. See note.
UserID	(Optional) A string representing the user. See note.
Date/Time	The Date and Time of the request. This number represents the number of seconds from 1970-01-01T0:0:0Z as measured in UTC.
NOTE: 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.

5.3.3 SEAL KM Response message p. 16

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.

Table 5.3.3-1: Contents of a SEAL KM Response message

Name	Description
UserUri	URI of the user for which the response is intended.
SKmsUri	The URI of the SKM-S sending the response.
ServiceID	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.
SKmsID	(Optional) The ID of the SKM-S providing the response message.
ClientID	(Optional) A string representing the client (see note)
DeviceID	(Optional) A string representing the device (see note)
UserID	(Optional) A string representing the user. (see note)
Date/Time	The Date and Time of the response. This number represents the number of seconds from 1970-01-01T0:0:0Z as measured in UTC.
ErrorCode	(Optional) Reason code indicating the failure of the requested action. If not present, the key management request is assumed to be successful.
Payload	(Optional) Key management payload specific to the VAL user, client or application. This field is not be present if an error occurs.
NOTE: 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.

Table 5.3.3-2: 'ErrorCode' values

ErrorCode	Description	Maps To
01	Unspecified error	"500 Internal Server Error" as described in Table 5.2.6-1 of TS 29.122
02	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
03	Request rejected	"401 Unauthorized" as described in Table 5.2.6-1 of TS 29.122
04	Unable to validate request	"400 Bad Request" or "403 Forbidden" as described in Table 5.2.6-1 of TS 29.122
05-FF	Reserved	N/A

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

5.4 Security procedures for interconnection p. 17

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.

5.5 Authentication and authorization of devices over LWP interfaces |R17| p. 17

Authentication and authorization mechanism for devices over LWP interfaces depends on the application protocol. The Annex B in the present document defines authentication and authorization procedures for the realizations of application protocols defined in Annex C of TS 23.434.