TS 33.558
Security aspects of enhancement of support for enabling Edge Applications

3GPP‑Page ETSI‑search CONTENT_↓

V18.1.0 (PDF) 2023/12 … p.

V17.3.0 2022/12 13 p.

Rapporteur:: Dr. Zhang, Bo
HUAWEI TECHNOLOGIES Co. Ltd.

Content for TS 33.558 Word version: 17.3.0

1 Scope p. 6

The present document specifies the security features and mechanisms to support the application architecture for enabling Edge Applications in 5G, i.e. security for the interfaces, procedures for the authentication and authorization between the entities of the application architecture, and procedures for the EES capability exposure.

2 References p. 6

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.

References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.

[1]

TR 21.905: "Vocabulary for 3GPP Specifications".

[2]

TS 33.210: "3G security; Network Domain Security (NDS); IP network layer security".

[3]

TS 33.501: "Security architecture and procedures for 5G System".

[4] Void

[5]

TS 23.558: "Architecture for enabling Edge Applications."

[6]

TS 23.222: "Functional architecture and information flows to support Common API Framework for 3GPP Northbound APIs; Stage 2".

[7]

TS 33.122: "Security aspects of Common API Framework (CAPIF) for 3GPP northbound APIs"

[8] Void

[9] Void

[10]

TS 33.310: "Network Domain Security (NDS); Authentication Framework (AF)".

[11]

TS 33.535: "Authentication and Key Management for Applications (AKMA) based on 3GPP credentials in the 5G System (5GS)".

[12]

TS 33.222: "Generic Authentication Architecture (GAA); Access to network application functions using Hypertext Transfer Protocol over Transport Layer Security (HTTPS)".

[13] Void

[14] Void

[15]

RFC 6749: "The OAuth 2.0 Authorization Framework".

[16]

RFC 6750: "The OAuth 2.0 Authorization Framework: Bearer Token Usage".

[17]

RFC 7519: "JSON Web Token (JWT)".

[18]

RFC 7515: "JSON Web Signature (JWS)".

[19]

RFC 9113: "HTTP/2".

[20]

RFC 9110: "HTTP Semantics".

3 Definitions of terms, symbols and abbreviations p. 7

3.1 Terms p. 7

For the purposes of the present document, the terms given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.

3.2 Symbols p. 7

Void.

3.3 Abbreviations p. 7

For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.

4 Overview p. 7

The overall application architecture for enabling Edge Applications that is given in TS 23.558, includes several entities, such as 3GPP core network, Edge Enabler Client (EEC) deployed in the UE, Edge Configuration Server (ECS), Edge Enabler Server (EES), and Edge Application Server (EAS). The application architecture for enabling Edge Applications, is defined in clause 6.2 of TS 23.558.

This specification captures the following security requirements and procedures:

Security for the EDGE interfaces: the set of security features that enable network nodes to exchange signalling data and user plane data securely.
Authentication and Authorization between EEC and ECS/EES: the set of security features that enable the authentication between EEC and ECS/EES, and enable the EEC to be authorized by the ECS/EES.
Authentication and Authorization between EES and ECS: the set of security features that enable the authentication between EES and ECS, and enable the EES to be authorized by the ECS.
Authentication and Authorization in EES capability exposure: the set of security features that enable the EAS to be authenticated and authorized by the EES in EES capability exposure.
Authentication and Authorization in 3GPP Core Network capability exposure: the set of security features that enable the ECS/EES/EAS to be authenticated and authorized by the 3GPP Core Network in 3GPP Core Network capability exposure.

5 Security requirements p. 7

5.1 General security requirements p. 7

The Edge application architecture defined in the TS 23.558 shall satisfy the following requirements.

5.1.1 Authentication and authorization p. 7

Authentication and Authorization between Edge Enabler Client (EEC) and Edge Configuration Server (ECS):

Edge Configuration Server (ECS) shall be able to provide mutual authentication with Edge Enabler Client (EEC) over EDGE-4 Interface. ECS shall determine whether EEC is authorized to access ECS's services.

Authentication and Authorization between EEC and EES:

Edge Enabler Server (EES) shall provide mutual authentication with EEC over EDGE-1 Interface. EES shall determine whether EEC is authorized to access EES's services.

Authentication and Authorization between Edge Enabler Server (EES) and ECS:

ECS shall provide mutual authentication with EES over EDGE-6 Interface. ECS shall determine whether EES is authorized to access ECS's services.

Authentication and Authorization between EESs:

EES shall provide mutual authentication with another EES over EDGE-9 Interface. EES shall determine whether peer EES is authorized to access EES's services.

Authentication and Authorization in EES capability exposure to EAS:

EES shall provide mutual authentication with EAS over EDGE-3 Interface. EES shall determine whether EAS is authorized to access EES's services and expose EEC Capabilities. The Edge application architecture shall support EASs to obtain the user's authorization to access sensitive information (e.g. user's location).

5.1.2 Interface security p. 8

Confidentiality, integrity, and replay protection shall be supported on the EDGE-1-4 and EDGE 6-9 interfaces.

The privacy requirements AR-5.2.6.2-h defined in TS 23.558 are implicitly supported, since all the interfaces will be confidentiality and integrity protected.

5.1.3 User consent requirements p. 8

User consent for edge computing shall comply with TS 33.501 (Annex V).

If EES, trusted by the 3GPP Core Network, is utilizing 5GC services without NEF, the EES acts as the consent enforcing entity. Otherwise, if the EES is utilizing 5GC services via NEF, the NEF acts as the consent enforcing entity.

User consent architecture in the present document is only applicable when EES or NEF and data provider are operated by the same entity.

6 Procedures p. 8

6.1 Security for the EDGE interfaces p. 8

For the interfaces (EDGE-1/4), the EEC, EES and ECS shall support and use HTTP/2 with "https" URIs as specified in RFC 9113 and RFC 9110. In addition, the TLS profile shall be compliant with the profile given in clause 6.2 of TS 33.210 .

For the interfaces EDGE-2/7/8,

If the NEF APIs are selected, security aspects of Network Exposure Function including the protection of NEF-AF interface and support of CAPIF defined in clause 12 of TS 33.501 shall be reused, i.e., use of TLS.
If the SCEF APIs are selected, the Security procedures for reference point SCEF-SCS/AS defined in clause 5.5 of TS 33.187 can be reused here, i.e., use of TLS.

For the interfaces (EDGE-3/6/9), the EAS, EES and ECS shall support and use HTTP/2 with "https" URIs as specified in RFC 9113 and RFC 9110. In addition, the TLS profile shall be compliant with the profile given in clause 6.2 of TS 33.210 .

6.2 Authentication and authorization between EEC and ECS p. 9

The ECS shall be configured with the information of authorization methods (token-based authorization or local authorization) used by EESes.

Authentication between EEC and ECS shall be done during the execution of the TLS handshake protocol.. Details of the authentication method (e.g., TLS certificates, usage of AKMA [11] or GBA [12] as methods to arrange the PSK for TLS) are out of scope of the present document. If the EEC sends the GPSI to the ECS, then the ECS shall also authenticate the GPSI. The details of how to authenticate the GPSI is out of scope of the present document.

After successful authentication, the ECS shall authorize the EEC by its local authorization policy.

After successful authentication and authorization, the ECS decides whether OAuth 2.0 [15] access tokens are required for the candidate EESes using the configuration information and issues separate EES access tokens to be used for each candidate EESes that use token-based authorization. The ECS, EEC and EES respectively assume the role of authorization server, client and resource server roles defined in [15]. "Client Credentials" grant type and bearer tokens [16] shall be used. JSON Web Token (JWT) as specified in IETF RFC 7519 for encoding and the JSON signature profile as specified in IETF RFC 7515 for protection of tokens shall be followed. This token profile also applies for clause 6.3 of the present document. The claims of the EES service tokens in the form of JWT [17] shall include the ECS FQDN (issuer), EEC ID (client_id), GPSI (subject), expected EES service name(s) (scope), EES FQDN (audience), expiration time (expiration). The ECS shall send the service response back to the EEC, which may include EES access token(s).

6.3 Authentication and authorization between EEC and EES p. 9

Authentication between EEC and EES shall be done during the execution of the TLS handshake protocol.. Details of the authentication method (e.g., TLS certificates, usage of AKMA [11] or GBA [12] as methods to arrange the PSK for TLS) are out of scope of the present document. If the EEC sends the GPSI to the EES, then the EES shall also authenticate the GPSI. The details of how to authenticate the GPSI is out of scope of the present document.

For authorization of EEC by the EES, the EEC shall send the OAuth 2.0 [15] access token, if received from the ECS, to the EES. The token profile is specified in clause 6.2 of the present document. If the EES requires access token for authorization, then the EES shall authorize the EEC by using the token. Otherwise, the EES shall authorize the EEC by its local authorization policy.

After successful authentication and authorization, the EES shall process the request and sends the service response back to the EEC.

6.4 Authentication and authorization between EES and ECS p. 9

6.4.1 General p. 9

The detailed service procedures between EES and ECS are described in TS 23.558.

6.4.2 Procedure for the authentication and authorization between EES and ECS p. 9

Pre-requisite:

EES obtains onboarding information within the same PLMN domain or from a third-party domain. The information includes the Edge Configuration Server Address and Root CA certificate details, it may include an enrolment token.

NOTE 1:
The provisioning and usage of the onboarding information are out of the scope of this document.
The EES and ECS are provisioned with credentials for the mutual authenticated TLS.

TLS shall be used to provide integrity protection, replay protection, and confidentiality protection for the interface between the EES and the ECS.

Security profiles for TLS implementation and usage shall follow the profiles given in clause 6.2 of TS 33.210 . The certificates shall follow the profile 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. Identities in the end-entity certificate shall be based on endpoint information (e.g., URI, FQDN, IP address) as described in the TS 23.558.

The ECS shall authorize the EES based on local authorization policy.

6.5 Authentication and authorization in EES capability exposure p. 10

According to clause 8.7.3 of TS 23.558, the EES may re-expose the network capabilities of the 3GPP core network to the EAS(s) as per the CAPIF architecture specified in TS 23.222. If the CAPIF architecture is used, the CAPIF functional security model specified in TS 33.122 shall be used for Authentication and authorization in EES capability exposure.

If CAPIF is not used, mutual authentication with TLS certificates using TLS shall be used. The TLS and certificates shall follow the profiles defined in TS 33.210 and TS 33.310, and the authorization is based on local authorization policy at the EES.

6.6 Authentication and Authorization between EESs p. 10

As specified in clause 6.1, TLS is used for EDGE-9 reference point (between edge enabler servers) security. For authentication between EESs, X.509 certificates shall be used. The certificates shall follow the profile 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. Identities in the end-entity certificate shall be based on endpoint information (e.g., URI, FQDN, IP address) as described in TS 23.558.

Authorization between EESs is based on local authorization policy.