Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x
Top   in Index   Prev   Next

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

V17.2.0 (PDF)2022/09  13 p.
Rapporteur:
Dr. Zhang, Bo
HUAWEI TECHNOLOGIES Co. Ltd.

Content for  TS 33.558  Word version:  17.0.0

Here   Top

1  ScopeWord‑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  ReferencesWord‑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]
TS 33.187: "Security aspects of Machine-Type Communications (MTC) and other mobile data applications communications enhancements".
[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]
RFC 5246:  "The Transport Layer Security (TLS) Protocol Version 1.2".
[9]
RFC 8446:  "The Transport Layer Security (TLS) Protocol Version 1.3".
[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)".
Up

3  Definitions of terms, symbols and abbreviationsWord‑p. 6

3.1  TermsWord‑p. 6

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  SymbolsWord‑p. 7

Void.

3.3  AbbreviationsWord‑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  OverviewWord‑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 TS 23.558, clause 6.2.
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.
Up

5  Security requirementsWord‑p. 7

5.1  General security requirementsWord‑p. 7

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

5.1.1  Authentication and Authorization.Word‑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 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).
Up

5.1.2  Interface securityWord‑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 securely protected.
Up

5.1.3  User Consent RequirementsWord‑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.
Up

6  ProceduresWord‑p. 8

6.1  Security for the EDGE interfacesWord‑p. 8

For the interfaces (EDGE-1/4), TLS specified in TS 33.210 shall be used if HTTP protocol is selected.
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 TS 33.501, clause 12 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 TS 33.187, clause 5.5 can be reused here, i.e., use of TLS.
For the interfaces (EDGE-3/6/9), TLS shall be used as specified in TS 33.210, unless security is provided by other means, e.g. physical security.
Up

6.2  Authentication and Authorization between EEC and ECSWord‑p. 8

The ECS shall be configured with the information of authorization methods (token-based authorization or local authorization) used by EESes.
For authentication between EEC and ECS, TLS authentication methods shall be used. Details of TLS authentication methods (e.g., client certificate, AKMA [11], GBA [12]) are out of scope of the current 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 current document.
After successful authentication, the ECS shall authorize the EEC by its local authorization policy.
After successful authentication and authorization, the ECS decides whether 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 claims of the EES service tokens shall include the ECS FQDN (issuer), EEC ID (subject), expected EES service name(s) (Scope), EES FQDN (audience), expiration time (expiration). The ECS sends the service response back to the EEC, which may include EES access token(s).
Up

6.3  Authentication and Authorization between EEC and EESWord‑p. 9

For authentication between EEC and EES, TLS authentication methods shall be used. Details of TLS authentication methods (e.g., client certificate, AKMA [11], GBA [12]) are out of scope of the current 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 current document.
For authorization of EEC by the EES, the EEC shall send the access token, if received from the ECS, to the EES and the EES shall authorize the EEC by using the token. Otherwise, the ECS shall authorize the EEC by its local authorization policy.
After successful authentication and authorization, the EES processes the request and sends the service response back to the EEC.
Up

6.4  Authentication and Authorization between EES and ECSWord‑p. 9

6.4.1  GeneralWord‑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 ECSWord‑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.
    - 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 TS 33.210 Annex E and F, and 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.
Up

6.5  Authentication and Authorization in EES capability exposureWord‑p. 9

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 defined in RFC 5246 and RFC 8446 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.
Up

$  Change historyWord‑p. 11


Up   Top