6 Procedures
33.5583GPPRelease 17Security aspects of enhancement of support for enabling edge applicationsTS
6.1 Security for the EDGE interfaces
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 [19] and RFC 9110 [20]. In addition, the TLS profile shall be compliant with the profile given in clause 6.2 of TS 33.210 [2] .
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 [2] 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 [3] 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 [19] and RFC 9110 [20]. In addition, the TLS profile shall be compliant with the profile given in clause 6.2 of TS 33.210 [2] .
6.2 Authentication and authorization between EEC and ECS
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 [17] for encoding and the JSON signature profile as specified in IETF RFC 7515 [18] 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
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
6.4.1 General
The detailed service procedures between EES and ECS are described in TS 23.558 [5].
6.4.2 Procedure for the authentication and authorization between EES and ECS
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.
NOTE1: 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 [2] . The certificates shall follow the profile given in clause 6.1.3a of TS 33.310 [10]. 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 [5].
The ECS shall authorize the EES based on local authorization policy.
6.5 Authentication and authorization in EES capability exposure
According to clause 8.7.3 of TS 23.558 [5], 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 [6]. If the CAPIF architecture is used, the CAPIF functional security model specified in TS 33.122 [7] 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 [2] and TS 33.310 [10], and the authorization is based on local authorization policy at the EES.
NOTE: Void
6.6 Authentication and Authorization between EESs
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 [10]. 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 [5].
Authorization between EESs is based on local authorization policy.
Annex A (informative):
Change history
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2022-03 |
SA#95e |
SP-220189 |
Presented for information and approval |
1.0.0 |
|||
|
2022-03 |
SA#95e |
Upgrade to change control version |
17.0.0 |
||||
|
2022-06 |
SA#96 |
SP-220558 |
0001 |
2 |
F |
Editorial corrections and technical clarifications |
17.1.0 |
|
2022-06 |
SA#96 |
SP-220558 |
0002 |
1 |
F |
Clarification of access token usage in EC |
17.1.0 |
|
2022-09 |
SA#97e |
SP-220879 |
0006 |
– |
F |
Corrections and clarifications on the usage of HTTPS and X.509 certificates |
17.2.0 |
|
2022-12 |
SA#98e |
SP-221158 |
0008 |
– |
F |
Addressing authentication and authorization for EDGE-9 |
17.3.0 |