The security mechanisms for service based interfaces are specified in clause 13 of TS 33.501.
Security Protection Edge Proxy (SEPP), as specified in TS 33.501, 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.
As specified in clause 13.1 of TS 33.501, 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.
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 TS 33.501 OAuth 2.0 (see RFC 6749) 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 Section 4.4 of RFC 6749, 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 (RFC 6750) 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 Section 7 of RFC 6749.
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 Section 2.1 of RFC 6750.
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 RFC 9110, where:
the scheme for challenge in the "WWW-Authenticate" header shall be set to "Bearer" (RFC 6750),
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 RFC 6750, 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 the request contains an invalid OAuth2.0 access token due to missing claims, the NF service producer may additionally include a ProblemDetails object in the 401 Unauthorized response with the cause attribute set to "ACCESS_TOKEN_CLAIM_MISSING" and with the invalidParams attribute indicating the missing claim name(s) necessary to access the protected resource (the invalidParams attribute may additionally indicate the "WWW-Authenticate" header as erroneous).
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 RFC 6750,
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.
As specified in clause 13.2 of TS 33.501, the following procedures shall be supported across N32
Capability Negotiation Request and Response;
Parameter Exchange Request and Response;
forwarding of the JOSE (see RFC 7516 and RFC 7515) 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 RFC 7516 and RFC 7515) as specified in clause 13.2.4 of TS 33.501.
TS 29.573 specifies protocol for the exchange of the messages described above over N32, the format of the JOSE (see RFC 7516 and RFC 7515) protected messages and the procedure for forwarding of the JOSE protected messages over N32.
The Client credentials assertion (CCA) and authentication procedure specified in clause 13.3.8 of TS 33.501 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 TS 33.501.
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".
Requirements for authentication and authorization of NF Service Consumers for data access via DCCF are specified in clause X.2 of TS 33.501.
From the perspective of the NF Service Producer, the NF Service Consumer defined in clause X.2 of TS 33.501 correspond to the Source NF Instance, and the DCCF corresponds to the NF Service Consumer, defined in TS 29.510 and in this specification.
The following requirements shall apply when the source NF Instance and/or the DCCF need to signal their own respective CCAs towards the NF Service Producer:
In the service request from the source NF instance to the DCCF:
the 3gpp-Sbi-Client-Credentials shall convey the client credentials assertion of the source NF Instance.
In the service request from the DCCF to the NF Service Producer:
the 3gpp-Sbi-Client-Credentials shall convey the client credentials assertion of the DCCF; and
the 3gpp-Sbi-Source-NF-Client-Credentials shall convey the client credentials assertion of the source NF Instance.
If the verification of the 3gpp-Sbi-Client-Credentials 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 verification of the 3gpp-Sbi-Source-NF-Client-Credentials 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 "SOURCE_NF_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 3gpp-Sbi-Client-Credentials 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".
If the sourceNfInstanceId claim (i.e., the NF Instance Id of the Source NF Instance) in the access token does not match the subject claim in the 3gpp-Sbi-Source-NF-Client-Credentials 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_SOURCE_NF_CCA_MISMATCH".
If a source NF Instance requests the DCCF to access data for which the DCCF already created a subscription to the NF Service Producer, the DCCF shall proceed as defined in Figure X.2-1 of TS 33.501, where the NF Service Request in step 10 shall be a PATCH or PUT request (as supported by the corresponding NF service) targeting the existing subscription, including the 3gpp-Sbi-Client-Credentials and the 3gpp-Sbi-Source-NF-Client-Credentials as described above. The PATCH or PUT request may modify the subscription to satisfy the requirements of the new Source NF Instance; if the current subscription already satisfies the requirements of the new Source NF Instance, the PATCH or PUT request may extend the expiry time of the subscription (see clause 4.6.2.2 of TS 29.501), or may request to patch an attribute of the subscription to its current value (for a PATCH request), or may provide the same subscription information (for a PUT request). The DCCF shall consider that the source NF Instance is authorized to access the data if the request is accepted.
The requirements for security for AI/ML model storage and sharing are specified in clause X.10 of TS 33.501.
From the perspective of the NF Service Producer, the ML model consumer (e.g. NWDAF containing AnLF) defined in clause X.10 of TS 33.501 correspond to the Source NF Instance, and the NWDAF containing MTLF, or in short MTLF, corresponds to the NF Service Consumer, defined in TS 29.510 and in this specification.
The following requirements apply when the source NF Instance and/or the MTLF need to signal their own respective CCAs towards the NF Service Producer:
In the service request from the source NF instance to the MTLF:
the 3gpp-Sbi-Client-Credentials conveys the client credentials assertion of the source NF Instance.
In the service request from the MTLF to the NF Service Producer:
the 3gpp-Sbi-Client-Credentials shall convey the client credentials assertion of the MTLF; and
if received from the source instance NF, the 3gpp-Sbi-Source-NF-Client-Credentials shall convey the client credentials assertion of the source NF Instance.
The "403 Forbidden" response with the cause attribute values described in clause 6.7.5.2 is applicable.
The primary usage of SBI Message Priority (SMP) is to provide guidance to 5GC NF acting as HTTP/2 clients or servers and HTTP/2 proxies when making throttling decisions related to overload control. The priority information may also be used for routing in proxies. Eventually a server may use the priority information to process higher-priority requests before lower-priority requests.
The SMP mechanism defined in this clause uses the "3gpp-Sbi-Message-Priority" custom HTTP header defined in clause 5.2.3.2.1 to set and carry the message priority between the client and the server.
The SMP mechanism should not use the stream priority mechanism, because that is deprecated in Section 5.3 of RFC 9113.
HTTP/2 clients, servers and proxies implementing SBIs shall support the custom HTTP header and may support the stream priority.
A client, proxy and server shall use the "3gpp-Sbi-Message-Priority" value (see clause 5.2.3.2.1) when setting or evaluating the priority of a message.
The client shall assign the request priority by adding the "3gpp-Sbi-Message-Priority" custom HTTP header (see clause 5.2.3.2.1) to the message and setting its value.
If the "3gpp-Sbi-Message-Priority" custom HTTP header is not present in a response message then the HTTP nodes shall use the priority indicated in the "3gpp-Sbi-Message-Priority" of the associated request message.
If the server wants to assign a different priority to the response message than the request one then the server shall assign the response priority by adding the "3gpp-Sbi-Message-Priority" custom HTTP header to the message and setting its value.
The purpose of HTTP/2 stream priority is to allow an endpoint to prioritize streams for transmitting frames when there is limited capacity for sending and to express how it would prefer its peer to allocate resources when managing concurrent streams. Setting the stream priority indicates a priority treatment to a message between the two endpoints of an HTTP/2 connection.
Section 5.3 of the RFC 9113 deprecates the HTTP/2 stream priority signaling.
For interoperability with implementations complying with earlier releases, 5GC NFs shall support receiving priority info in HEADER or PRIORITY frames to the extent that headers or frames containing stream priority information shall not be rejected, but processed as if they contained no stream priority information, i.e. the stream priority information is ignored.
The recommendations provided in this clause are compliant with Section 10 of RFC 7944]. The priority value range defined over SBIs spans from 0 to 31 (decimal), where 0 indicates the highest priority and 31 indicates the lowest priority. The recommendations have been adapted to 5G services and Service Based Architecture.
The priorities defined for all messages across all SBIs used in an HTTP/2 administrative domain must be defined in a consistent and coordinated fashion, taking the default priority (see below for default priority values) into account.
The following are some guidelines to be considered when defining the SMPs to be used in SBA networks that support HTTP/2 nodes handling multiple services.
As with any prioritization scheme, it is possible for higher-priority messages to block lower-priority messages from ever being handled. In 5GC, this will often result in the messages being retried. This may result in more traffic than the network would have handled without use of the SMP mechanism.
One potential guideline to prevent unwanted starving of lower-priority messages is to have higher-priority messages represent a relatively small portion of messages handled by the 5GC under normal scenarios. The Multimedia Priority Service (see clause 5.16.5 of TS 23.501) and the Mission Critical Service (see clause 5.16.6 of TS 23.501) typically generate little traffic compared to the total traffic of a 5GC.
The Multimedia Priority Service (MPS) and the Mission Critical Service (MCX) require the blocking of lower-priority services.
A network entity (e.g., the AMF) that has received an RRC Establishment Cause associated with priority service (e.g., mps-PriorityAccess, mcs-PriorityAccess, or highPriorityAccess) or has determined that the UE has a priority subscription (e.g., MPS, MCX) in the UDM/UDR, shall select an SMP value appropriate for the priority service (e.g., MPS, MCX) for use in requests and responses.
When setting priorities for Multimedia Priority Services, Mission Critical Services or Emergency calls, it is important to use the same priority values across all APIs and services exposed by the 5GC. For instance, if the MPS priority levels of [1; n] are assigned the values of [k; k+n-1], then the same values shall be defined in the same order on all SBIs for the same service.
Messages related to MPS, MCX and Emergency calls may be ranked according to their priority (e.g., based on ARP priority level, 5QI priority level, MPS Priority) based on regional/national regulatory and operator policies when it is known by the application sending the message. Otherwise MPS and MCX should have higher priorities than Emergency calls. Emergency call related messages should have higher priority than the rest of the messages. The ranking can be used to select SMP values.
The following are general requirements:
Requests without the "3gpp-Sbi-Message-Priority" header shall be assigned the default priority value of "24".
When defining priorities of the messages of a service, the same rules apply independently of the application, the SBI and the service:
When there is a series of request/response required to complete a procedure, it is appropriate to mark request/responses that occur later in the series at a higher priority than those that occur early in the series.
The requests that establish new sessions should have a lower priority than the requests that update or end a session.
The requests that will result in deregistering users if they failed (e.g., due to authentication vector retrieval, or update location) shall have a higher priority than the requests of a non-registered user.
Request/responses of optional procedures and of delay tolerant services should have lower priority than those of mandatory procedures.
The client sending a request shall determine its required priority according to clause 6.8.4. It shall include a "3gpp-Sbi-Message-Priority" header (see clause 5.2.3.2.1) indicating the required priority level in the request and shall prioritise the requests according to the required priority level. If the client also uses the stream priority at the HTTP/2 connection level then it shall map the header value into a Weight and include it in the HEADERS of the request message.
When the client receives a response with the "3gpp-Sbi-Message-Priority" header, it shall prioritise the received response according to the priority level received, otherwise according to the priority level of the corresponding request. This includes determining the order in which responses are handled and resources that are applied to the handling of the responses.
The server should use the "3gpp-Sbi-Message-Priority" header (see clause 5.2.3.2.1) to determine how to handle the request. This includes determining the order in which requests are handled and resources that are applied to the handling of the request.
Servers should use "3gpp-Sbi-Message-Priority" value when making overload throttling decisions.
Servers should not use stream priority information when making overload throttling decisions at the connection level.
When the priority of the response message needs to have a different value than the request, a server shall include a "3gpp-Sbi-Message-Priority" header in the response message which value is set to the response required priority level.
A server should not set the stream priority as described in RFC 9113, via priority information in the HEADERS frame or in a PRIORITY frame.
A proxy should forward request and response without removing the "3gpp-Sbi-Message-Priority" header or changing its value.
While done only in exceptional circumstances, a proxy may modify priority information when relaying request and response by changing the "3gpp-Sbi-Message-Priority" value. For example, a SEPP may modify the priority set by a roaming partner.
Proxies should use the request priority information (respectively response priority information) according to the "3gpp-Sbi-Message-Priority" value when making overload throttling decisions to a request (respectively a response).
Proxies may use the priority information according to the "3gpp-Sbi-Message-Priority" value when relaying a request or a response messages. This includes the selection of routes (only for the requests) and the ordering of messages relayed.
A client, proxy or server may prioritize traffic at IP level by placing messages into different traffic classes and marking them with an appropriate Differentiated Services Code Point (DSCP).
Multiple HTTP/2 connections between two HTTP/2 end points are necessary: one per DSCP value. All messages sent over a connection are assigned the same traffic class and receive the same DSCP marking. The "3gpp-Sbi-Message-Priority" value shall be considered in the selection of the appropriate connection to send the message.
The OPTIONS method, as described in Section 9.3.7 of RFC 9110, may be used by a NF Service Consumer to determine the communication options supported by a NF Service Producer for a target resource.
Clause 6.9.2.1 describes example communication options that may be discovered using the OPTIONS method.
The Accept-Encoding header, as described in Section 12.5.3 of RFC 9110, may be used by a NF Service Producer to determine the communication options supported by a NF Service Consumer.
Clause 6.9.2.2 describes example communication options that may be discovered using the Accept-Encoding header.
Certain service operations may result in large HTTP request contents, e.g. to register NF profiles in the NRF (see TS 29.510) or to update the NSSF with the available S-NSSAIs supported by Tracking Areas (see TS 29.531). Gzip coding (see RFC 1952) may be supported to optimally reduce the content size of HTTP requests in this case.
A NF Service Consumer may determine the content-encodings supported by the NF Service Producer in HTTP requests targeting a particular resource by:
sending an HTTP OPTIONS request targeting the resource of the NF Service Producer; and/or
receiving an "Accept-Encoding" header in HTTP responses from the NF Service Producer for requests targeting the resource.
A NF Service Producer that receives an HTTP OPTIONS request for a target resource shall include an "Accept-Encoding" header in the HTTP 200 OK response (see RFC 9110), if specific content-encodings, e.g. Gzip coding (e.g. see RFC 1952) are supported in HTTP requests targeting the resource.
A NF Service Producer that receives an HTTP request with a content-encoding that it does not support shall reject the request with the status code "415 Unsupported Media Type" and include an "Accept-Encoding" header in the response indicating the supported encodings in HTTP requests, as described in Section 12.5.3 of RFC 9110.
A NF Service Producer may include an "Accept-Encoding" header in the HTTP 2xx response for requests other than HTTP OPTIONS if specific content-encodings, e.g. Gzip coding (e.g. see RFC 1952), are supported in HTTP requests targeting the resource, to optimize future interactions, e.g. when the request content was big enough to justify use of a compression coding but the client did not do so.
For notification requests, a NF Service Producer may determine the content-encodings supported by the NF Service Consumer from the 3gpp-Sbi-Notif-Accepted-Encoding HTTP header, defined in clause 5.2.3.3.6, included in the received subscription request.
Certain service operations may result in large HTTP response contents, e.g. to send NF profiles by the NRF (see TS 29.510) or to send the available S-NSSAIs supported by Tracking Areas by the NSSF (see TS 29.531). Gzip coding (see RFC 1952) may be supported to optimally reduce the content size of HTTP responses in this case (see "Content-Encoding" header in Table 5.2.2.2-2).
A NF Service Consumer may include an "Accept-Encoding" header in HTTP requests to indicate the content-encodings, e.g. Gzip coding (e.g. see RFC 1952), that are supported for the associated HTTP responses, as specified in Table 5.2.2.2-1 and in Section 12.5.3 of RFC 9110.
A NF Service Producer may determine the content-encodings supported by the NF Service Consumer in HTTP responses by receiving an "Accept-Encoding" header in the associated HTTP requests from the NF Service Consumer.