Content for TS 33.434 Word version: 18.2.0
5 Procedures
5.0 General
5.1 Security for the SEAL interfaces
5.1.1 Security for the application plane interfaces
5.1.1.0 General
5.1.1.1 SEAL-X1
5.1.1.2 SEAL-X2
5.1.1.3 IM-UU
5.1.1.4 KM-UU and KM-S
5.1.1.5 SEAL-UU
5.1.1.6 VAL-UU
5.1.1.7 SEAL-C
5.1.1.8 SEAL-S
5.1.1.9 SEAL-E
5.1.2 Security for the Signalling control plane interfaces
5.1.2.1 Security for HTTP interfaces
5.1.2.2 Security for LWP interfaces
5.1.3 Security for the network domain interfaces
5.1.4 Security for the network domain interfaces in EPS
5.2 User authentication and authorization
5.2.1 VAL user authentication
5.2.2 SEAL service authorization
5.2.3 Identity management functional model
5.2.4 Authentication framework
5.2.5 Authorization framework
5.2.6 VAL service authorization
...
...
5 Procedures p. 9
5.0 General |R18| p. 9
The security procedures in this clause also applies to SEALDD as specified in TS 23.433. In the SEALDD scenario, the SEAL client, SEAL server and SEAL service are replaced by the SEALDD client, SEALDD server and SEALDD service, respectively.
5.1 Security for the SEAL interfaces p. 9
5.1.1 Security for the application plane interfaces p. 9
5.1.1.0 General |R18| p. 9
The security for the SEAL-UU, SEAL-C, SEAL-S and SEAL-E interfaces in this clause also applies to the corresponding SEALDD interfaces (i.e. SEALDD-UU, SEALDD-C, SEALDD-S and SEALDD-E) as specified in TS 23.433.
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. 10
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. 10
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. 11
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
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.1.4 Security for the network domain interfaces in EPS |R18| p. 11
A VAL UE shall perform the authentication and security mechanisms as specified in TS 33.401 for LTE 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. 12
5.2.1 VAL user authentication p. 12
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. 12
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. 12
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.
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. These tokens are further defined in clause A.2.
| 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. 13
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.
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. 14
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.
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.
