6.7 Security Mechanisms

29.5003GPP5G SystemRelease 17Stage 3Technical Realization of Service Based ArchitectureTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.7.1 General

The security mechanisms for service based interfaces are specified in clause 13 of 3GPP TS 33.501 [17].

Security Protection Edge Proxy (SEPP), as specified in 3GPP TS 33.501 [17], shall be used between service based interfaces across PLMNs. The NFs in a PLMN shall use the SEPP as a HTTP/2 proxy for the HTTP/2 messages that carry ":authority" pseudo header with a uri-host formatted as specified in clause 6.1.4.3.

6.7.2 Transport layer security protection of messages

As specified in clause 13.1 of 3GPP TS 33.501 [17], TLS shall be used for the security protection of messages at the transport layer for the service based interfaces if network security is not provided by other means.

6.7.3 Authorization of NF service access

Clause 13 in 3GPP TS 33.501 [17] specifies two alternative authorization mechanisms:

– Static authorization, which is based on local authorization policy at the NRF and the NF Service Producer (see clause 13.3.0);

– Token based authorization, when NRF acts as the Authorization Server and provides access (see clause 13.3.1).

As specified in clause 13.4.1 of 3GPP TS 33.501 [17] OAuth 2.0 (see IETF RFC 6749 [22]) may be used for authorization of NF service access. All NFs and the NRF shall support the OAuth 2.0 authorization framework with "Client Credentials" grant type as specified in clause 4.4 of IETF RFC 6749 [22] , except that there is no "Authorization" HTTP request header in the access token request.

The NRF shall act as the Authorization Server providing "Bearer" access tokens (IETF RFC 6750 [23]) to the NF service consumers to access the services provided by the NF service providers.

If an NF service (i.e. API) receives an OAuth 2.0 access token in the "Authorization" HTTP request header field, the NF service shall validate the access token, its expiry and its access scope before allowing access to the requested resource, as specified in clause 7 of IETF RFC 6749 [22].

The access scope required to get access to a given resource may be, based on local configuration of the NF service producer, either:

– the service name of the NF Service; this scope grants generic access to a given API, for those operations on resources that don’t require a specific authorization, or

– both, the service name of the NF Service, and a string that uniquely represents the type of operation (e.g. create/modify/read), the resource and the service; those two scopes, together, grant access to those operations on resources that require a specific authorization.

An NF service consumer shall support OAuth 2.0.

For request/response semantics service operations and for the subscribe and unsubscribe operations of subscribe/notify semantics service operations, an NF service consumer may use OAuth 2.0 for the authorization of the API access, based on local configuration. The NF service consumer discovers the additional scopes (resource/operation-level scopes) that might be required to invoke a certain service operation, based on the authorization information registered in NRF by the NF service producer in its NF profile.

When Oauth2 authorization is used, the NF service consumer shall use the token received from NRF as a "Bearer" token and include it in the Authorization header of the HTTP service requests, as described in IETF RFC 6750 [23] clause 2.1.

An NF service producer shall decide to accept or reject an API request without the OAuth2.0 access token in the "Authorization" HTTP request header field, based on local configuration.

If an NF service producer rejects an API request without the OAuth2.0 access token or an API request with an invalid OAuth2.0 access token, it shall return the HTTP "401 Unauthorized" status code together with the "WWW-Authenticate" header as specified in IETF RFC 7235 [21], where:

– the scheme for challenge in the "WWW-Authenticate" header shall be set to "Bearer" (IETF RFC 6750 [23]),

– the "realm" attribute shall be set to the URI of the service (i.e. API URI) for which the access failed, in the case of request / response service operations,

– the "error" attribute shall be set to "invalid_token", as described in IETF RFC 6750 [23], if the request contained a token which was deemed as invalid by the NF service producer (e.g. it is expired, malformed…); if the request did not contain a token, the "error" attribute shall not be included.

If an NF service producer rejects an API request with an OAuth2.0 access token not having the required scopes to invoke the service operation, it shall return the HTTP "403 Forbidden" status code together with the "WWW-Authenticate" header, where:

– the scheme for challenge in the "WWW-Authenticate" header shall be set to "Bearer",

– the "realm" attribute shall be set to the URI of the service (i.e API URI) for which the access failed, in the case of request / response service operations,

– the "error" attribute shall be set to "insufficient_scope" as described in IETF RFC 6750 [23],

– the "scope" attribute shall be set with the scope(s) necessary to access the protected resource.

For the notify operation of subscribe/notify semantics service operations, in this release of this specification OAuth 2.0 access token is not used.

When an NF service consumer receives a "401 Unauthorized" or a "403 Forbidden" status code with a "WWW-Authenticate" header containing "Bearer" as the scheme for challenge it shall not repeat the same request without an OAuth2.0 access token or with an access token that has been already used. The NF service consumer may repeat the same request with a new OAuth 2.0 access token.

NOTE: If a NF service producer accepts a request without the OAuth 2.0 access token, based on local policy, it is assumed that such accesses are allowed based on trust relationships and hence full access to the resource as it would have been otherwise allowed, is provided.

6.7.4 Application layer security across PLMN

6.7.4.1 General

HTTP/2 messages sent across the PLMN between the SEPPs shall follow the application layer security procedures specified in clause 13.2 of 3GPP TS 33.501 [17].

6.7.4.2 N32 Procedures

As specified in clause 13.2 of 3GPP TS 33.501 [17], the following procedures shall be supported across N32

– Capability Negotiation Request and Response;

– Parameter Exchange Request and Response;

– forwarding of the JOSE (see IETF RFC 7516 [25] and IETF RFC 7515 [26]) protected messages over N32.

Based on the capability negotiation and parameters exchanged between the SEPPs, the service based interface messages sent across N32 interface shall be subjected to JOSE based protection (see IETF RFC 7516 [25] and IETF RFC 7515 [26]) as specified in clause 13.2.4 of 3GPP TS 33.501 [17].

3GPP TS 29.573 [27] specifies protocol for the exchange of the messages described above over N32, the format of the JOSE (see IETF RFC 7516 [25] and IETF RFC 7515 [26]) protected messages and the procedure for forwarding of the JOSE protected messages over N32.

6.7.5 Client credentials assertion and authentication

The Client credentials assertion (CCA) and authentication procedure specified in clause 13.3.8 of 3GPP TS 33.501 [17] may be used to enable the NRF or the NF Service Producer to authenticate the NF Service Consumer, when using indirect communication.

If so, an HTTP request shall include the 3gpp-Sbi-Client-Credentials header (see clause 5.2.3.2.11) containing the client credentials assertion. The verification of the client credentials assertion shall be performed by the receiving entity as specified in clause 13.3.8.3 of 3GPP TS 33.501 [17].

If the verification of the CCA fails at the receiving entity (e.g. NRF or NF service producer), a "403 Forbidden" response shall be returned with the cause attribute set to "CCA_VERIFICATION_FAILURE".

If the subject claim (i.e., the NF Instance Id of the NF Service Consumer) in the access token does not match the subject claim in the CCA at the receiving entity (e.g. NRF or NF service producer), a "403 Forbidden" response shall be returned with the cause attribute set to " TOKEN_CCA_MISMATCH ".