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

3GPP‑Page ETSI‑search CONTENT_↓

V18.2.0 (PDF) 2024/06 14 p.

V17.3.0 2022/12 13 p.

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

Content for TS 33.558 Word version: 18.2.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).

Authentication and Authorization between Application Client (AC) and EEC:

EEC should provide mutual authentication with the Application Client over EDGE-5 interface, and the EEC should determine whether Application client is authorized to access EEC's service.

Authentication and Authorization between V-ECS and H-ECS:

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

Authentication and Authorization between ECS and ECS-ER:

ECS-ER shall provide mutual authentication with ECS over EDGE-10 interface. ECS-ER shall determine whether ECS is authorized to access ECS-ER's services.

Authentication and Authorization between ECS-ERs:

ECS-ERs shall provide mutual authentication over EDGE-10 interface. ECS-ER shall determine whether other ECS-ERs are authorized to access ECS-ER's services.

5.1.2 Interface security p. 8

Confidentiality, integrity, and replay protection shall be supported on the EDGE-1-4 and EDGE 6-10 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. 9

6.1 Security for the EDGE interfaces p. 9

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/10), the EAS, EES, ECS, and ECS-ER 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. Server side certificate-based TLS authentication shall be supported. A mutual authentication method should be supported and used between EEC and ECS (e.g., TLS certificates (client and server certificate based authentication), usage of AKMA [11] or GBA [12] as methods to arrange the PSK for TLS). Details of such authentication method performed during the execution of the TLS handshake protocol are out of scope of the present document.

The authentication method negotiation mechanism shall re-use the existing TLS v1.3 negotiation. UE may receive the supported authentication method of the ECS optionally as part of the ECS configuration information. Details of the ECS configuration information are specified in TS 23.558. If the UE has the information about the authentication method supported by the ECS, then the EEC/UE may use this information for the authentication method negotiation.

If the GPSI is required, the ECS shall retrieve the GPSI from the core network no matter whether the EEC sends the GPSI to the ECS.

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

Authentication between EEC and EES shall be done during the execution of the TLS handshake protocol. Server side certificate-based TLS authentication shall be supported. 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.

The authentication method negotiation mechanism shall re-use the existing TLS v1.3 negotiation. UE may receive the supported authentication method of the EES optionally as part of the EES configuration information. Details of the EES configuration information are specified in TS 23.558. If the UE has the information about the authentication method supported by the EES, then the EEC/UE may use this information for the authentication method negotiation.

If the GPSI is required, the EES shall retrieve the GPSI from the core network no matter whether the EEC sends the GPSI to the ECS.

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

6.4.1 General p. 10

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

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

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

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.

6.7 Authentication and authorization between V-ECS and H-ECS |R18| p. 11

The V-ECS and H-ECS are provisioned with credentials (e.g., certificate, shared keys/secrets) for mutual authentication. The mutual authentication between V-ECS and H-ECS shall be done based on the preconfigured credentials. The V-ECS shall authorize the H-ECS based on local authorization policy.

6.8 Authentication and Authorization between AC and EEC |R18| p. 11

Authentication and authorization between AC and EEC in UE are based on local policy.

6.9 Authentication and authorization between ECS and ECS-ER and between ECS-ERs |R18| p. 11

Same mechanism in clause 6.7 applies for authentication and authorization between ECS and ECS-ER and between ECS-ERs.