How can security be guaranteed when using services provided by a network function in a 5G network? That's what we will be looking at in this video, and we'll start by looking at authorization within one 5G network. An SBI interface is based on two main principles. First, services are provided by a network function by managing resources: by either creating them or reading their state. In addition, a network function is meant to provide services which can be used by any NF. There are of course, restrictions for security reasons. The NF must only be able to use services if it is authorized to do so. Let's imagine that a consumer NF wants to use the services of a producer NF. That is to say, to access resources. We want to control authorization for accessing these resources. We know that there is a key function in a 5G network: the "Network-function Repository Function", or NRF. Each instance of NF establishes mutual authentication with the NRF. There is therefore mutual authentication between the consumer NF and the NRF, as well as with the producer NF. This authentication is certificate-based. Authorization is managed with OAuth 2.0 for "Open Authorization". You have probably already used OAuth when you have a user account for a web service but you use the login password of your social networking account or search engine account. Three parties are involved in OAuth 2.0. First, the client who wants to access the resources. Second, the resource owner, which here is the producer, NF. Third, an authorization server, which here is the NRF. The NRF creates an access token signed using cryptographic mechanisms based on asymmetric cryptography. For any request, the consumer NF inserts this token, which is then checked by the producer NF, the resource owner. This assumes that the producer NF has indicated which services are accessible and who can access them. This is done during the registration mechanism. Let's look a little more closely at how that works in an example. Here, we have an instance of an AMF, an instance of a UDM. During initialization, this instance was registered with the NRF. Each instance has a unique UUID identity that is used as the instance identity. Here, nfinstanceid1 and nfinstanceid2 for UDM. In the registration request, the instance of UDM indicates its profile, the services which are accessible, and who can access them. Registration is done in advance and at a given moment, (it can be much later) the AMF may, for example, need to dialogue with a UDM instance to use its services. For this, the AMF will use the discovery service provided by the NRF and materialized by the API nnrf-disc. In this request, it will pass on the type of NF being searched for the criteria and in return the NRF will indicate the identity of the instance nfinstanceId2 along with either the Fully Qualified Domain Name (FQDN) or the IP address of this instance. Upon receiving the 200 OK message, the instance of AMF uses the authorization service. The instance sends a post, indicating the service OAuth2.0 as the API. It then requests the creation of a resource, in this case, a token. The ID of the instance making the request is included within the request along with the identity of the instance for which authorization is requested, nudm being the type of NF and we also have the services that the AMF wants to use. From the UDM profile, the NRF makes the required checks and creates an access token with a cryptographic signature. It then sends a 200 OK message, including this token and an expiry date. Once the instance of AMF has the token, it can send all of the GETs, POSTs, and PUTs that it wants as long as this access token is included. The UDM checks the integrity of the token, verifies that the AMF is authorized for the service it is requesting and, if that's the case, it executes the service and sends, for example, a 200 OK message. When the token reaches its expiry date, the UDM instance sends a 300 redirect message requesting a new access token.
