WO2021094349A1

WO2021094349A1 - Multi-step service authorization for indirect communication in a communication system

Info

Publication number: WO2021094349A1
Application number: PCT/EP2020/081705
Authority: WO
Inventors: Nagendra Bykampadi
Original assignee: Nokia Technologies Oy
Priority date: 2019-11-14
Filing date: 2020-11-11
Publication date: 2021-05-20

Abstract

A service request with an access token is received, wherein the service request is received from a service consumer and is a request to access at least one service of a service producer of a service type and wherein the access token corresponds to the service type. A determination is made to use a subset of target service producers of the service type for the service request, and at least one target service producer in the subset is determined. A decision is made whether to use the access token received from the service consumer or to obtain and use another access token. The service request is sent toward the at least one target service producer with the decided access token.

Description

MULTI-STEP SERVICE AUTHORIZATION FOR INDIRECT

COMMUNICATION IN A COMMUNICATION SYSTEM

Field

The field relates generally to communication systems, and more particularly, but not exclusively, to security management within such systems.

Background

This section introduces aspects that may be helpful in facilitating a better understanding of the inventions. Accordingly, the statements of this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art.

Fourth generation (4G) wireless mobile telecommunications technology, also known as Long Term Evolution (LTE) technology, was designed to provide high capacity mobile multimedia with high data rates particularly for human interaction. Next generation or fifth generation (5G) technology is intended to be used not only for human interaction, but also for machine type communications in so-called Internet of Things (IoT) networks.

While 5G networks are intended to enable massive IoT services (e.g., very large numbers of limited capacity devices) and mission-critical IoT services (e.g., requiring high reliability), improvements over legacy mobile communication services are supported in the form of enhanced mobile broadband (eMBB) services providing improved wireless Internet access for mobile devices.

In an example communication system, user equipment (5G UE in a 5G network or, more broadly, a UE) such as a mobile terminal (subscriber) communicates over an air interface with a base station or access point referred to as a gNB or a WLAN access point as part of the 5G network. The access point (e.g., gNB) is illustratively part of an access network of the communication system. For example, in a 5G network, the access network is referred to as a 5G System and is described in 5G Technical Specification (TS) 23.501, V16.2.0, entitled “Technical Specification Group Services and System Aspects; System Architecture for the 5G System,” the disclosure of which is incorporated by reference herein in its entirety. In general, the access point (e.g., gNB) provides access for the UE to a core network (CN), which then provides access for the UE to other UEs and/or a data network such as a packet data network (e.g., Internet).

TS 23.501 goes on to define a 5G Service-Based Architecture (SB A) which models services as network functions (NFs) that communicate with each other using representational state transfer application programming interfaces (Restful APIs).

Furthermore, 5G Technical Specification (TS) 33.501, V16.0.0, entitled “Technical Specification Group Services and System Aspects; Security Architecture and Procedures for the 5G System,” the disclosure of which is incorporated by reference herein in its entirety, further describes security management details associated with a 5G network.

Security management is an important consideration in any communication system. For example, authorization of access to services is one example of security management in a 5G network. However, service access authorization presents several challenges in existing 5G approaches as 5G is based on a service-based architecture and introduces new types of intermediate nodes and is structured to support IoT usage scenarios.

Summary

Illustrative embodiments provide improved techniques for security management in communication systems particularly with respect to service access authorization.

For example, in one illustrative embodiment, a method comprises the following steps. A service request with an access token is received, wherein the service request is received from a service consumer and is a request to access at least one service of a service producer of a service type and wherein the access token corresponds to the service type. A determination is made to use a subset of target service producers of the service type for the service request, and at least one target service producer in the subset is determined. A decision is made whether to use the access token received from the service consumer or to obtain and use another access token. The service request is sent toward the at least one target service producer with the decided access token. For example, this method can be performed by a service communication proxy element on a service consumer side of the communication system.

In another embodiment, a method comprises the following steps. A service request is received from a service consumer. The service request is a request to access at least one service of a service producer. A target service producer determination is performed based on the service request, and a granularity is determined for an access token based on the target service producer determination. A response is sent to the service consumer indicating the determined granularity for the access token, and a subsequent service request is received from the service consumer including an access token obtained by the service consumer consistent with the determined granularity. The subsequent service request is sent toward the at least one target service producer with the access token obtained by the service consumer consistent with the determined granularity. For example, this method can also be performed by a service communication proxy element on the service consumer side.

In yet another embodiment, a method comprises the following steps. A service request with an access token associated with a service consumer is received, wherein the service request is a request to access at least one service of a service producer of a service type. The access token is verified and the service request is forwarded without the access token to the service producer when the method is performed in a deployment that is a service mesh configuration, otherwise, the service request with the access token is forwarded to the service producer for verification by the service producer. For example, this method can be performed on a service producer side of the communication system.

Further illustrative embodiments are provided in the form of non-transitory computer-readable storage medium having embodied therein executable program code that when executed by a processor causes the processor to perform the above steps. Still further illustrative embodiments comprise apparatus with a processor and a memory configured to perform the above steps.

These and other features and advantages of embodiments described herein will become more apparent from the accompanying drawings and the following detailed description.

Brief Description of the Drawings

FIG. 1 illustrates a communication system with which one or more illustrative embodiments are implemented.

FIG. 2 illustrates network elements/functions for providing security management with which one or more illustrative embodiments are implemented. FIG. 3 illustrates a communication system architecture with network functions interacting within a network with which one or more illustrative embodiments are implemented.

FIG. 4 illustrates a communication system architecture with network functions interacting between a visited network and a home network with which one or more illustrative embodiments are implemented.

FIG. 5 illustrates an authentication protocol architecture using service communication proxy elements with which one or more illustrative embodiments are implemented.

FIG. 6A illustrates a methodology for obtaining an access token for use in service access authorization in a communication system, according to an illustrative embodiment.

FIG. 6B illustrates a methodology for service access authorization in a communication system, according to an illustrative embodiment.

Detailed Description

Embodiments will be illustrated herein in conjunction with example communication systems and associated techniques for providing security management in communication systems. It should be understood, however, that the scope of the claims is not limited to particular types of communication systems and/or processes disclosed. Embodiments can be implemented in a wide variety of other types of communication systems, using alternative processes and operations. For example, although illustrated in the context of wireless cellular systems utilizing 3 GPP system elements such as a 3 GPP next generation system (5G), the disclosed embodiments can be adapted in a straightforward manner to a variety of other types of communication systems.

In accordance with illustrative embodiments implemented in a 5G communication system environment, one or more 3 GPP technical specifications (TS) and technical reports (TR) provide further explanation of user equipment and network elements/functions and/or operations that interact with one or more illustrative embodiments, e.g., the above-referenced 3 GPP TS 23.501 and 3 GPP TS 33.501. Other 3 GPP TS/TR documents provide other conventional details that one of ordinary skill in the art will realize. However, while illustrative embodiments are well-suited for implementation associated with the above- mentioned 5G-related 3GPP standards, alternative embodiments are not necessarily intended to be limited to any particular standards.

Furthermore, illustrative embodiments will be explained herein in the context of the Open Systems Interconnection model (OSI model) which is a model that conceptually characterizes communication functions of a communication system such as, for example, a 5G network. The OSI model is typically conceptualized as a hierarchical stack with a given layer serving the layer above and being served by the layer below. Typically, the OSI model comprises seven layers with the top layer of the stack being the application layer (layer 7) followed by the presentation layer (layer 6), the session layer (layer 5), the transport layer (layer 4), the network layer (layer 3), the data link layer (layer 2), and the physical layer (layer 1). One of ordinary skill in the art will appreciate the functions and interworkings of the various layers and, thus, further details of each layer are not described herein. However, it is to be appreciated that while illustrative embodiments are well-suited for implementations that utilize an OSI model, alternative embodiments are not necessarily limited to any particular communication function model.

Illustrative embodiments are related to security management associated with the Service-Based Architecture (SBA) for 5G networks. Prior to describing such illustrative embodiments, a general description of main components of a 5G network will be described below in the context of FIGS. 1 and 2.

FIG. 1 shows a communication system 100 within which illustrative embodiments are implemented. It is to be understood that the elements shown in communication system 100 are intended to represent main functions provided within the system, e.g., UE access functions, mobility management functions, authentication functions, serving gateway functions, etc. As such, the blocks shown in FIG. 1 reference specific elements in 5G networks that provide these main functions. However, other network elements are used in other embodiments to implement some or all of the main functions represented. Also, it is to be understood that not all functions of a 5G network are depicted in FIG. 1. Rather, functions that facilitate an explanation of illustrative embodiments are represented. Subsequent figures depict some additional elements/functions.

Accordingly, as shown, communication system 100 comprises user equipment (UE) 102 that communicates via an air interface 103 with an access point (gNB) 104. In alternative embodiments, access may be through a 4G access point (eNB). The UE 102 in some embodiments is a mobile station, and such a mobile station may comprise, by way of example, a mobile telephone, a computer, or any other type of communication device. The term “user equipment” as used herein is therefore intended to be construed broadly, so as to encompass a variety of different types of mobile stations, subscriber stations or, more generally, communication devices, including examples such as a combination of a data card inserted in a laptop or other equipment such as a smart phone or other cellular device. In one or more alternative embodiments, user equipment refers to an IoT device and/or a device that executes ultra-reliable low latency communication (URLLC) application software where computing resources on the UE are limited or performance and timing requirements are very stringent. Such communication devices are also intended to encompass devices commonly referred to as access terminals.

In one embodiment, UE 102 is comprised of a Universal Integrated Circuit Card (UICC) part and a Mobile Equipment (ME) part. The UICC is the user-dependent part of the UE and contains at least one Universal Subscriber Identity Module (USIM) and appropriate application software. The UICC may be removable, embedded (eUICC), or integrated (iUICC). The USIM securely stores the permanent subscription identifier and its related key, which are used to identify and authenticate subscribers to access networks. The ME is the user-independent part of the UE and contains terminal equipment (TE) functions and various mobile termination (MT) functions.

Note that, in one example, the permanent subscription identifier is an International Mobile Subscriber Identity (IMSI) of a UE. In one embodiment, the IMSI is a fixed 15-digit length and consists of a 3-digit Mobile Country Code (MCC), a 3-digit Mobile Network Code (MNC), and a 9-digit Mobile Station Identification Number (MSIN). In a 5G communication system, an IMSI is referred to as a Subscription Permanent Identifier (SUPI). In the case of an IMSI as a SUPI, the MSIN provides the subscriber identity. Thus, only the MSIN portion of the IMSI typically needs to be encrypted. The MNC and MCC portions of the IMSI provide routing information, used by the serving network to route to the correct home network. When the MSIN of a SUPI is encrypted, it is referred to as a Subscription Concealed Identifier (SUCI).

The access point 104 is illustratively part of an access network of the communication system 100. Such an access network comprises, for example, a 5G System having a plurality of base stations and one or more associated radio network control functions. The base stations and radio network control functions in some embodiments are logically separate entities, but in some embodiments are implemented in the same physical network element, such as, for example, a base station router or cellular access point.

The access point 104 in this illustrative embodiment is operatively coupled to mobility management functions 106. In a 5G network, the mobility management function is implemented by an Access and Mobility Management Function (AMF). A Security Anchor Function (SEAF) in some embodiments is also implemented with the AMF connecting a UE with the mobility management function. A mobility management function, as used herein, is the element or function (i.e., entity) in the core network (CN) part of the communication system that manages or otherwise participates in, among other network operations, access and mobility (including authentication/authorization) operations with the UE (through the access point 104). The AMF is also referred to herein, more generally, as an access and mobility management entity.

The AMF 106 in this illustrative embodiment is operatively coupled to home subscriber functions 108, i.e., one or more functions that are resident in the home network of the subscriber. As shown, some of these functions include the Unified Data Management (UDM) function, as well as an Authentication Server Function (AUSF). The AUSF and UDM (separately or collectively) are also referred to herein, more generally, as an authentication entity. In addition, home subscriber functions include, but are not limited to, Network Slice Selection Function (NSSF), Network Exposure Function (NEF), Network Repository Function (NRF), Policy Control Function (PCF), and Application Function (AF).

Note that a UE, such as UE 102, is typically subscribed to what is referred to as a Home Public Land Mobile Network (HPLMN) in which some or all of the home subscriber functions 108 reside. If the UE is roaming (not in the HPLMN), it is typically connected with a Visited Public Land Mobile Network (VPLMN) also referred to as a visited or serving network. Some or all of the mobility management functions 106 may reside in the VPLMN, in which case, functions in the VPLMN communicate with functions in the HPLMN as needed. However, in a non-roaming scenario, mobility management functions 106 and home subscriber functions 108 can reside in the same communication network. Furthermore, one or more of subscriber functions 108 can be part of a VPLMN if appropriate in certain circumstances. The access point 104 is also operatively coupled to a serving gateway function, i.e., Session Management Function (SMF) 110, which is operatively coupled to a User Plane Function (UPF) 112. UPF 112 is operatively coupled to a Packet Data Network, e.g., Internet 114. As is known in 5G and other communication networks, the user plane (UP) or data plane carries network user traffic while the control plane (CP) carries signaling traffic. SMF 110 supports functionalities relating to UP subscriber sessions, e.g., establishment, modification and release of PDU sessions. UPF 112 supports functionalities to facilitate UP operations, e.g., packet routing and forwarding, interconnection to the data network (e.g., 114 in FIG. 1), policy enforcement, and data buffering.

It is to be appreciated that FIG. 1 is a simplified illustration in that not all communication links and connections between NFs and other system elements are illustrated in FIG. 1. One ordinarily skilled in the art given the various 3GPP TSs/TRs will appreciate the various links and connections not expressly shown or that may otherwise be generalized in FIG. 1.

Further typical operations and functions of certain network elements are not described herein in detail when they are not the focus of illustrative embodiments but can be found in appropriate 3 GPP 5G documentation. It is to be appreciated that the particular arrangement of system elements in FIG. 1 is an example only, and other types and arrangements of additional or alternative elements can be used to implement a communication system in other embodiments. For example, in other embodiments, the system 100 comprises other elements/functions not expressly shown herein. Also, although only single elements/functions are shown in the FIG. 1 embodiment, this is for simplicity and clarity of illustration only. A given alternative embodiment may include larger numbers of such system elements, as well as additional or alternative elements of a type commonly associated with conventional system implementations.

It is also to be noted that while FIG. 1 illustrates system elements as singular functional blocks, the various subnetworks that make up the 5G network are partitioned into so-called network slices. Network slices (network partitions) comprise a series of network function (NF) sets (i.e., function chains) for each corresponding service type using network function virtualization (NFV) on a common physical infrastructure. The network slices are instantiated as needed for a given service, e.g., eMBB service, massive IoT service, and mission-critical IoT service. A network slice or function is thus instantiated when an instance of that network slice or function is created. In some embodiments, this involves installing or otherwise running the network slice or function on one or more host devices of the underlying physical infrastructure. UE 102 is configured to access one or more of these services via gNB 104. NFs can also access services of other NFs.

Note further that, in various embodiments, a single NF instance can either serve a single Network Slice Selection Assistance Information (NSSAI) slice or a single shared NF instance for multiple NSSAI slices, but single or multiple NF instances can also be deployed as a single or multiple virtual network function (VNF) instances. Still further, alternative embodiments also contemplate bare metal implementations for NFs.

FIG. 2 is a block diagram of network elements/functions for providing security management in an illustrative embodiment. System 200 is shown comprising a first network element/function 202 and a second network element/function 204. It is to be appreciated that one or both of the network elements/functions 202 and 204 may represent any network elements/functions that are configured to provide security management and other techniques described herein, for example, but not limited to, AMF, SEAF, UDM, AUSF, NSSF, NEF, NRE, PCF and AF.

However, in one or more illustrative embodiments, one or both of first network element/function 202 and a second network element/function 204 represent a Service Communication Proxy (SCP), more generally referred to herein as a “service communication proxy element.” The SCP is defined in Release 16 (Rel-16) of the above-referenced 3GPP TS 23.501. Note that another name for a service communication proxy element is a “SECOP.” SECOP is the name used in 3GPP SA3 specifications, and SCP is the name used in 3GPP SA2 specifications. As illustratively used herein, SCP is also understood to refer to a SECOP.

As will be further described herein, Rel-16 introduces an indirect communication model in which an NF communicates via an SCP, which is an intermediate function/element to assist in routing messages (e.g., CP messages such as Diameter Routing Agent (DRA) messages) between two NFs. Illustrative embodiments will be described herein that address OAuth 2.0 protocols used for service authorization in the context of the indirect communication model and the presence of SCPs. OAuth 2.0 is described in Internet Engineering Task Force (IETF) Request for Comment (RFC) 6749, the disclosure of which is incorporated by reference herein in its entirety. As illustratively used herein, OAuth 2.0 may be more simply referred to as OAuth. However, it is to be understood that embodiments are not limited to OAuth 2.0 or any particular authentication protocol.

The network element/function 202 comprises a processor 212 coupled to a memory 216 and interface circuitry 210. The processor 212 of the network element/function 202 includes a security management processing module 214 that may be implemented at least in part in the form of software executed by the processor. The processing module 214 performs security management (e.g., service authorization) described in conjunction with subsequent figures and otherwise herein. The memory 216 of the network element/function 202 includes a security management storage module 218 that stores data generated or otherwise used during security management operations.

The network element/function 204 comprises a processor 222 coupled to a memory 226 and interface circuitry 220. The processor 222 of the network element/function 204 includes a security management processing module 224 that may be implemented at least in part in the form of software executed by the processor 222. The processing module 224 performs security management described in conjunction with subsequent figures and otherwise herein. The memory 226 of the network element/function 204 includes a security management storage module 228 that stores data generated or otherwise used during security management operations.

Note that storage modules 218 and 228 provide persistence and may, in some embodiments, be clustered providing some security management data that can be shared by multiple network functions/elements.

The processors 212 and 222 of the respective network elements/functions 202 and 204 may comprise, for example, microprocessors, application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs) or other types of processing devices or integrated circuits, as well as portions or combinations of such elements. Such integrated circuit devices, as well as portions or combinations thereof, are examples of “circuitry” as that term is used herein. A wide variety of other arrangements of hardware and associated software or firmware may be used in implementing the illustrative embodiments.

The memories 216 and 226 of the respective network elements/functions 202 and 204 may be used to store one or more software programs that are executed by the respective processors 212 and 222 to implement at least a portion of the functionality described herein. For example, security management operations and other functionality as described in conjunction with subsequent figures and otherwise herein may be implemented in a straightforward manner using software code executed by processors 212 and 222.

A given one of the memories 216 or 226 may therefore be viewed as an example of what is more generally referred to herein as a computer program product or still more generally as a processor-readable storage medium that has executable program code embodied therein. Other examples of processor-readable storage media may include disks or other types of magnetic or optical media, in any combination. Illustrative embodiments can include articles of manufacture comprising such computer program products or other processor-readable storage media.

The memory 216 or 226 may more particularly comprise, for example, an electronic random-access memory (RAM) such as static RAM (SRAM), dynamic RAM (DRAM) or other types of volatile or non-volatile electronic memory. The latter may include, for example, non-volatile memories such as flash memory, magnetic RAM (MRAM), phase- change RAM (PC-RAM) or ferroelectric RAM (FRAM). The term “memory” as used herein is intended to be broadly construed, and may additionally or alternatively encompass, for example, a read-only memory (ROM), a disk-based memory, or other type of storage device, as well as portions or combinations of such devices.

The interface circuitries 210 and 220 of the respective network elements/functions 202 and 204 illustratively comprise transceivers or other communication hardware or firmware that allows the associated system elements to communicate with one another in the manner described herein.

It is apparent from FIG. 2 that network element/function 202 is configured for communication with network element/function 204 and vice-versa via their respective interface circuitries 210 and 220. This communication involves network element/function 202 sending data to the network element/function 204, and the network element/function 204 sending data to the network element/function 202. However, in alternative embodiments, other network elements may be operatively coupled between, as well as to, the network elements/functions 202 and 204. The term “data” as used herein is intended to be construed broadly, so as to encompass any type of information that may be sent between network elements/functions (as well as between user equipment and a core network) including, but not limited to, messages, tokens, identifiers, keys, indicators, user data, control data, etc. Each of network elements/functions 202 and 204, as well as other parts of communication systems mentioned herein, are considered examples of “a network component,” “a network node,” “a network entity” (all of which can be used interchangeably herein).

Thus, in one example, network element/function 202 is a NF, such as an AMF, and network element/function 204 is a SCP. In such case, the AMF and the SCP participate in a service access authorization methodology and exchange messages/data as needed. Such service access authorization methodology will be further described below. FIG. 2 can alternatively represent two SCPs in communication with one another, or an SCP in communication with an NF such as the NRF or the UDM/AUSF.

It is to be appreciated that the particular arrangement of components shown in FIG. 2 is an example only, and numerous alternative configurations are used in other embodiments. For example, any given network element/function can be configured to incorporate additional or alternative components and to support other communication protocols.

Other system elements such as UE 102 and gNB 104 may each also be configured to include components such as a processor, memory and network interface. These elements need not be implemented on separate stand-alone processing platforms, but could instead, for example, represent different functional portions of a single common processing platform.

As mentioned above, Rel-16 of the above-referenced 3GPP TS 23.501 provides an indirect communication model for NFs through the introduction of the SCP. One of the architectural options introduced in Rel-16 is Option D. Option D is based on indirect communication between NFs. In other words, the NFs do not directly communicate with each other. This also includes interactions between an NF and the NRF. Furthermore, in this option, NFs implement application logic while all non-application logic including discovery of a target NF for a given service, selecting a target NF from a list of available NFs based on load balancing, service authorization, etc. are delegated to the SCP. Note that prior to Rel-16 (i.e., Rel-15 of TS 23.501), NFs queried the NRF to discover and communicate with each other over application programming interfaces (APIs). Rel-16 now has the SCP serve as the intermediary for the NFs for such discovery, selection, and authorization functions. In Rel-15, OAuth client authentication between OAuth client (NF consumer) and OAuth Server (NRF) is implicitly based on the underlying Transport Layer Security (TLS) between the OAuth client (i.e., NF consumer or NFc) and OAuth server (i.e., the NRF). This is no longer possible with Option D of the indirect communication model because of the presence of SCP in between NFs (including between NFc and NRF).

In Rel-15, the OAuth client (NFc) directly obtains the access token from the NRF, which plays the role of the OAuth Authorization server, once it discovers and selects which target NF producer(s) (NFp) it uses to obtain the desired service. But in Option D, the discovery and selection of the target NFp(s) are delegated to the SCP. Therefore, NFc cannot obtain access tokens directly.

In other words, the existing OAuth service access authorization solution in Rel-15 does not work for the indirect communication model where SCPs are present, particularly in the Option D architectural option.

Further details about the SCP are described in 3GPP TR 33.855, VI.8.0, entitled “Technical Specification Group Services and System Aspects; Security Aspects; Study on Security Aspects of the 5G Service Based Architecture,” the disclosure of which is incorporated by reference herein in its entirety. In particular, solution #21 in TR 33.855 describes an OAuth 2.0 based authorization for indirect communication with delegated discovery (Model D).

In the currently proposed Rel-16 Option D authorization solution (i.e., solution #21 in TR 33.855 as cited above), on the consumer side, the SCP plays the role of the OAuth client instead of the NF consumer (NFc). The NFc invokes the necessary API for the desired service. The SCP connected to the NFc (referred to herein as SCPc) obtains all the required information related to the target NF producer (NFp) from the NRF. Once it selects the target NFp, it issues another request to the NRF to obtain an access token specific to the NFc and the selected target NFp.

Note that if there already exists an access token for this pair of NFc-NFp which has not expired, then the SCPc may reuse that access token (i.e., cached token), and no access token request to the NRF is needed.

On the producer side, the SCP connected with the target NFp (referred to herein as SCPp) verifies the access token on behalf of the NFp. SCPp has all the necessary information needed to verify the integrity of the access token and verify claims inside the token. An indication may be sent by SCPp to inform NFp that the request was authorized by SCPp.

FIGS. 3 and 4 depict two SCP -based scenarios. More particularly, FIG. 3 illustrates an intra-PLMN inter-SCP scenario 300. As shown, communication network 310 (managed by network operator 1) comprises an NFp 312 operatively coupled to an SCPp 314. SCPp 314 is operatively coupled to NRF1 316 and SCPc 318, while SCPc 318 is operatively coupled to NFc 320 and NRF2 322.

FIG. 4 illustrates an inter-PLMN roaming scenario 400. In this scenario, it is assumed that communication network 410 is a HPLMN (managed by network operator 1) which is coupled via an Internetwork Packet Exchange (IPX) provider(s) network 420 to a VPLMN 430 (managed by network operator 2). Note that alternative intermediate networks may couple the VPLMN and HPLMN networks. Thus, with regard to a given UE, it is assumed that HPLMN 410 is the home network of the UE (the network with which the UE is a subscriber) and VPLMN 430 is a visited network with which the UE is currently attached. FIG. 4 also illustrates the presence of a Security Edge Protection Proxy (SEPP) at the edge of each PLMN, i.e., hSEPP 411 in HPLMN 410 and vSEPP 431 in VPLMN 430. The SEPP is an entity residing at the perimeter of a PLMN network to protect the PLMN from outside traffic and additionally to implement transport layer security (TLS) and application layer security (ALS) for all the data and signalling exchanged between two inter network network functions at the service layer. For example, the SEPP performs security functions on information elements (IE) in HyperText Transport Protocol (HTTP) messages before the messages are sent externally over the roaming N32 interface. Still further, as shown, HPLMN 410 comprises an NFp 412 operatively coupled to an SCPp 414. SCPp 414 is operatively coupled to hNRF 416 and to SCPc 434 in VPLMN 430 (through hSEPP 411, IPX provider(s) network 420, and vSEPP 431). SCPc 434 is operatively coupled to NFc 432 and vNRF 436.

Recall as mentioned above, solution #21 in TR 33.855 describes an OAuth 2.0 based authorization for indirect communication with delegated discovery (Model D). In one proposed implementation, an SCP based OAuth 2.0 authorization mechanism includes the following features. On the consumer side, the SCP performs the role of the OAuth client instead of the NF consumer (NFc). The SCP obtains an access token on behalf of the NFc. The NFc invokes the necessary API for the desired service. The SCP, that is connected to the NFc and referred to as SCPc, obtains the required information related to the target NF producer (NFp) from the NRF. Once the SCPc selects the target NFp, it issues another request to the NRF to obtain an access token specific to the NFc and the selected target NFp.

On the producer side, the SCP connected with the target NFp, referred to as SCPp, verifies the access token on behalf of the NFp. SCPp has the information needed to verify the integrity of the access token and verify claims inside the token.

The above proposed implementation applies to all SCP deployment models including deployments where the NF and the connected SCP are in the same deployment unit as a service mesh. A “service mesh” is, by way of example only, an infrastructure layer designed to handle network-based inter-process communication among microservices to ensure that such communication is fast, reliable, and secure. In some scenarios, a proxy element (“sidecar proxy”) is associated with a microservice and routes requests to proxies of other microservices (other sidecar proxies). Together, these sidecar proxies form a service mesh. A service mesh can provide communication support for critical functionalities including, but not limited to, service discovery, load balancing, encryption, observability, traceability, authentication and authorization. Thus, in some scenarios, when NFs and SCPs are configured as part of a given service mesh, they are said to be in the same deployment unit; otherwise they are considered to be in different deployment units. However, there are two issues with the above proposed implementation.

First, when the deployment model is such that the NF and the connected SCP are in different deployment units (i.e., not as a service mesh), the above proposed implementation has a problem in that on the producer side, the SCP connected to the target NFp does not necessarily have all the information to verify all the claims in the access token on behalf of the NFp. For example, the SCP is unlikely to have information of all the services offered in the target NFp, without which it cannot verify the “scope” claim in the access token.

Second, model D does not prohibit the NFc from directly communicating with the OAuth Server (NRF). For example, during registration, an NFp may directly register with the NRF without going through an SCP. An NFc, therefore, may communicate directly with the NRF to get an access token. The above proposed implementation, however, proposes delegated authorization where the SCP obtains an access token on behalf of the NFc.

Illustrative embodiments will now be described that provide improved service authorization in the indirect communication model via SCPs that address the two issues associated with the above proposed implementation, as well as other issues. As mentioned, while the OAuth protocol for Option D in Rel-16 will be used as an example embodiment, alternative embodiments apply to other forms of service authorization.

As will be explained in further detail below, illustrative embodiments perform token verification as follows. The NFp performs access token verification in deployments where the SCP and NFs are in different deployment units in which the SCP is not setup as a sidecar proxy for the NF in a service mesh configuration.

Furthermore, illustrative embodiments obtain access tokens as follows.

In one option, the NFc, by default, obtains an access token for an NF type, i.e., the access token will be applicable for all NFs of a given NF type (i.e., an example of what is more generally referred to herein as a “service type”). However, if the SCPc determines that it has to restrict the granularity to a subset of NFs of the NF type (identified by an NF Set Identifier or Id), the SCPc will replace the NFc-provided access token with a new access token it obtains for the required granularity (applicable only to the NF Set). An NF Set is an example of what is more generally referred to herein as a “subset of target service producers.”

In a second option, the NFc always obtains an access token. However, the NFc waits for the discovery/selection result from the SCP before obtaining the access token at the correct granularity (i.e., NF Instance Id or NF Set or NF type). More particularly, the NFc first triggers the SCP to perform discovery and selection. An existing service request API may be used or a new API may be designed for this purpose. The SCP performs discovery/selection and returns a response back to the NFc. The NFc determines the correct granularity and obtains an access token for that granularity. The NFc will send the service request with the correct access token.

An illustrative embodiment is now described wherein the NFc obtains an access token for the NF type and the SCP replaces the access token with another access token, if required, as will be further explained herein. Such an illustrative embodiment will be further described in terms of message flows in the context of FIGS. 6A and 6B. There are multiple parts to the proposed solution as outlined below.

1. The NFc obtains an access token for an NF type, and includes it in the service request it sends to SCPc. 2. The SCPc performs discovery and selection of the target NFp instance. As part of this procedure, the SCPc may decide to use an NF Set to service the request. In such a scenario, the SCPc will select a producer instance within the NF Set.

3. If the SCPc decides to use an NF Set, it obtains a new access token from the NRF and replaces it in the service request originated by the NFc. The SCPc caches this access token until it receives the service response back from the NFp.

4. The SCPc forwards the request towards the selected NFp.

5. If the NFp is directly reachable without an SCP in the front (Rel-15 architecture), the access token verification is performed by the NFp.

6. If there is an SCPp in the path (Rel-16 architecture): a. If the SCPp is configured as a sidecar proxy to the NFp (service mesh-based deployment), the SCPp may decide to verify the access token. If it does, it may strip the access token before forwarding the service request to the NFp. b. If the SCPp is not a sidecar proxy (SCP is independently deployed of NFp), the SCPp forwards the service request to the NFp, and the NFp verifies the access token.

7. The SCPc includes the access token in the service response towards the NFc.

8. For subsequent requests, the NFc has the option to reuse the SCPc-provided access token.

9. The SCPc repeats step 2. If there is any change in the selection, the SCPc obtains a new access token as in step 3.

The proposed solution is further described in the following parts: a) OAuth architecture for Option D architecture in Rel-16

The SCP implements OAuth based service access authorization of NFs when the Option D architectural option is used. NFs do not support OAuth based functionality in Option D.

FIG. 5 illustrates a hierarchy 500 with OAuth protocol roles. The OAuth protocol roles are performed as follows:

NRF 502 is the OAuth authorization server (Auth Server).

SCPc 504 (SCP on the consumer side).

SCPp 506 (SCP on the producer side). One or more NFcs 508 (“OAuth clients”) communicate directly with SCPc 504, while one or more NFps 510 (OAuth resource servers) communicate directly with SCPp 506.

More particularly, for Option D indirect communication model (model D), the NFc 508 implements the consumer side of the OAuth-based service access authorization of NFs by obtaining an access token from the NRF 502. The SCPc 504 may obtain an access token if required. The NFp 510 implements OAuth-based access token verification. The SCPp 506 may verify the access token in service mesh deployments where it is configured as a service proxy. It is assumed that the NFp 510 and the SCPp 506 have the required NRF key to either perform integrity check of the access token or decrypt the encrypted access token b) Obtaining an access token on the consumer side

FIG. 6A depicts methodology 600 which describes the process of obtaining an access token on the consumer side (on behalf of the NFc). Depicted in FIG. 6A (with reference to the architecture 500 in FIG. 5) are Authorization Server (NRF) 502, SCPc 504, and NF Service Consumer (NFc) 508.

Step 602: a mutually authenticated TLS connection is established between NFc 508 and SCPc 504, a mutually authenticated TLS connection is established between SCPc 504 and NRF 502 (authorization server or, more generally, “authorization entity”), and a mutually authenticated TLS connection is established between NFc 508 and NRF 502.

Step 604: NFc 508 sends an Access Token Request including an NF type of target NFp and its own NFc instance Id toward NRF 502. The NFc 508 then receives an Access Token Response with an access token from NRF 502.

Step 606: NFc 508 invokes the API requesting a specific service towards the SCPc. The NF Service Request includes the access token NFc 508 received in step 604.

Step 608: SCPc 504 performs service discovery and selection of target NFps if required (i.e., if the target NF details are not included in step 606).

If the SCPc decides to obtain an access token for an NF Set:

Step 610: SCPc 504 sends an Access Token Request including an NF Set Id and the NFc Instance Id to the NRF 502.

Step 612: The SCPc 504 receives an Access Token Response including an access token and an expiration time for the access token from the NRF 502. Further, if the SCPc 504 decides to get a new access token for an NF Set, it caches the access token until it receives the corresponding Service Response from the NFp.

It is to be appreciated that the SCPc decision to use an NF Set and obtain a new access token, in one or more illustrative embodiments, can be based on one or more factors (e.g., security, performance, availability, etc.), which can be dynamically determined and configured during implementation by a system and/or an administrator.

Step 614: SCPc 504 replaces the old access token with the new access token in the service request message that it forwards towards the NFp (see FIG. 6B described below). c) Validating the access token on the producer side

FIG. 6B depicts methodology 620 which describes validation of the access token on the producer side. Note that while not expressly illustrated in FIG. 6B, it is assumed that a mutually authenticated TLS connection is established between the SCPp 506 and the NFp 510, similar to NFc and SCPc. Furthermore, SCPc 504 to SCPp 506 connection may be based on TLS or, in alternative embodiments, could also be Network Domain Security /Internet Protocol or NDS/IP (IPSec) or also implicit if going through a SEPP (for inter-roaming scenarios). SCPc 504 and SCPp 506 trust each other based on a mutually authenticated secure connection between them either directly or indirectly via SEPP.

Step 622: The SCPp 506 receives the NF Service Request with the access token from the SCPc 504. Recall from FIG. 6A that the access token can be the one received from the NFc 508 or, if the SCPc 504 obtained an access token, the one it obtained. The SCPp 506 forwards the request with the access token to the NFp 510. Note that if the SCPp 506 is configured as a sidecar proxy to the NFp 510, the SCPp 506 may decide to verify the access token. If it does, the SCPp 506 may strip the access token before forwarding the service request to the NFp 510.

Step 624: The NFp 510 verifies the integrity of the access token.

Step 626: The NFp 510 extracts and validates claims in the token (self-contained or using an API with NRF).

Step 628: If verification in step 626 is successful, the NFp 510 notifies SCPc 504.

After successful authentication/authorization of the NFc 508 (FIG. 6A), the NFc 508 is given access to the service of the NFp 510. Illustrative embodiments described in FIGS. 6A and 6B are applicable in Option D scenarios, where the SCP by definition is fully in-charge of discovering and selecting the target NF producer. In addition to those, illustrative embodiments also provide a mechanism for the SCP to perform required procedures for OAuth based service access authorization. Alternative embodiments are also applicable in Option C (of TS 23.501) scenarios when the NFs delegate OAuth based service access authorization to the SCP.

Note that FIG. 6 A depicts an intra-PLMN scenario. For an inter-PLMN scenario, Rel-15 specifications in the above-referenced TS 33.501 clause 13.4.1 are followed where the authorization server is located in the other network, and the local NRF forwards the request to the other NRF, as specified in clause 13.4.1 in TS 33.501.

Note that a given NF may be an NFc in one instance and an NFp in another instance as it may provide services to other network functions, but also requests and needs services from other network functions. As such, the trusted SCP associated with the given NF can function as an SCPc or an SCPp depending on the context.

The particular processing operations and other system functionality described in conjunction with the message flow diagrams of FIGS. 6A and 6B are presented by way of illustrative example only, and should not be construed as limiting the scope of the disclosure in any way. Alternative embodiments can use other types of processing operations and messaging protocols. For example, the ordering of the steps may be varied in other embodiments, or certain steps may be performed at least in part concurrently with one another rather than serially. Also, one or more of the steps may be repeated periodically, or multiple instances of the methods can be performed in parallel with one another.

It should therefore again be emphasized that the various embodiments described herein are presented by way of illustrative example only and should not be construed as limiting the scope of the claims. For example, alternative embodiments can utilize different communication system configurations, user equipment configurations, base station configurations or technologies, key pair provisioning and usage processes, messaging protocols and message formats than those described above in the context of the illustrative embodiments. These and numerous other alternative embodiments within the scope of the appended claims will be readily apparent to those skilled in the art.

Claims

I/We Claim:

1. An apparatus comprising: at least one processor; at least one memory including computer program code; the at least one memory and the computer program code being configured to, with the at least one processor, cause the apparatus at least to: receive a service request with an access token, wherein the service request is received from a service consumer and is a request to access at least one service of a service producer of a service type and wherein the access token corresponds to the service type; determine to use a subset of target service producers of the service type for the service request and determine at least one target service producer in the subset; decide whether to use the access token received from the service consumer or to obtain and use another access token; and send the service request toward the at least one target service producer with the decided access token.

2. The apparatus of claim 1, wherein the other access token is obtained for the subset of target service producers of the service type or for an individual target service producer of the service type.

3. The apparatus of claim 1, wherein the apparatus comprises a service communication proxy element for performing one or more of the receiving, determining, deciding and sending operations.

4. The apparatus of claim 1, wherein the subset of target service producers of the service type has a unique identifier associated therewith.

5. The apparatus of claim 1, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the apparatus at least to send an access token request to an authorization entity for the set of target service producers of the service type.

6. The apparatus of claim 5, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the apparatus at least to receive an access token response from the authorization entity, wherein the access token response comprises an access token for the set of target service producers of the service type.

7. The apparatus of claim 1, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the apparatus at least to send the service request with the decided access token to a service communication proxy element associated with the at least one target service producer.

8. The apparatus of claim 1, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the apparatus at least to cache the sent access token.

9. A method comprising: receiving a service request with an access token, wherein the service request is received from a service consumer and is a request to access at least one service of a service producer of a service type and wherein the access token corresponds to the service type; determining to use a subset of target service producers of the service type for the service request and determine at least one target service producer in the subset; deciding whether to use the access token received from the service consumer or to obtain and use another access token; and sending the service request toward the at least one target service producer with the decided access token.

10. The method of claim 9, wherein the other access token is for the subset of target service producers of the service type.

11. The method of claim 9, wherein the other access token is for an individual target service producer of the service type.

12. The method of claim 9, wherein the subset of target service producers of the service type has a unique identifier associated therewith.

13. An article of manufacture comprising a non-transitory computer-readable storage medium having embodied therein executable program code that when executed by a processor causes the processor to perform the steps of claim 9.

14. An apparatus comprising: at least one processor; at least one memory including computer program code; the at least one memory and the computer program code being configured to, with the at least one processor, cause the apparatus at least to: receive a service request, wherein the service request is received from a service consumer and is a request to access at least one service of a service producer; perform a target service producer determination based on the service request; determine a granularity for an access token based on the target service producer determination; send a response to the service consumer indicating the determined granularity for the access token; receive a subsequent service request from the service consumer including an access token obtained by the service consumer consistent with the determined granularity; and send the subsequent service request toward the at least one target service producer with the access token obtained by the service consumer consistent with the determined granularity.

15. The apparatus of claim 14, wherein the granularity for an access token comprises one of a target service producer, a set of target service producers, and a service type of target service producers.

16. A method comprising: receiving a service request, wherein the service request is received from a service consumer and is a request to access at least one service of a service producer; performing a target service producer determination based on the service request; determining a granularity for an access token based on the target service producer determination; sending a response to the service consumer indicating the determined granularity for the access token; receiving a subsequent service request from the service consumer including an access token obtained by the service consumer consistent with the determined granularity; and sending the subsequent service request toward the at least one target service producer with the access token obtained by the service consumer consistent with the determined granularity.

17. The method of claim 16, wherein the granularity for an access token comprises one of a target service producer, a set of target service producers, and a service type of target service producers.

18. An article of manufacture comprising a non-transitory computer-readable storage medium having embodied therein executable program code that when executed by a processor causes the processor to perform the steps of claim 16.

19. An apparatus comprising: at least one processor; at least one memory including computer program code; the at least one memory and the computer program code being configured to, with the at least one processor, cause the apparatus at least to: receive a service request with an access token associated with a service consumer, wherein the service request is a request to access at least one service of a service producer of a service type; and verify the access token and forward the service request without the access token to the service producer when the apparatus is deployed as part of a service mesh configuration, otherwise, forward the service request with the access token to the service producer for verification by the service producer.

20. The apparatus of claim 19, wherein when the apparatus is deployed as part of a service mesh configuration, the apparatus functions as a communication proxy for the service producer.

21. A method comprising: receiving a service request with an access token associated with a service consumer, wherein the service request is a request to access at least one service of a service producer of a service type; and verifying the access token and forward the service request without the access token to the service producer when the method is performed in a deployment that is a service mesh configuration, otherwise, forward the service request with the access token to the service producer for verification by the service producer.

22. An article of manufacture comprising a non-transitory computer-readable storage medium having embodied therein executable program code that when executed by a processor causes the processor to perform the steps of claim 21.