Patent Description:
This section introduces aspects that may be helpful to facilitating a better understanding of the inventions.

Fourth generation (<NUM>) 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 (<NUM>) 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 <NUM> networks are intended to enable massive loT services (e.g., very large numbers of limited capacity devices) and mission-critical loT 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 (<NUM> UE in a <NUM> 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 in a <NUM> network. The access point (e.g., gNB) is illustratively part of an access network of the communication system. For example, in a <NUM> network, the access network is referred to as a <NUM> System and is described in <NUM> Technical Specification (TS) <NUM>, V15. <NUM>, entitled "Technical Specification Group Services and System Aspects; System Architecture for the <NUM> System,". 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 <NUM> goes on to define a <NUM> Service-Based Architecture (SBA) which models services as network functions (NFs) that communicate with each other using representational state transfer application programming interfaces (Restful APIs).

Furthermore, <NUM> Technical Specification (TS) <NUM>, V0. <NUM>, entitled "Technical Specification Group Services and System Aspects; Security Architecture and Procedures for the <NUM> System,", further describes security management details associated with a <NUM> network.

A protection mechanism is discussed that allows selective protection of a payload while allowing other unprotected payload to be modified by intermediaries.

Security management is an important consideration in any communication system. However, due to continuing attempts to improve the architectures and protocols associated with a <NUM> network in order to increase network efficiency and/or subscriber convenience, security management issues can present a significant challenge.

Illustrative embodiments provide improved techniques for security management in communication systems.

For example, in one illustrative embodiment, a method comprises the following steps. A receiving security edge protection proxy element is provided in a first network operatively coupled to a second network in a communication system, wherein the receiving security edge protection proxy element is operatively coupled to a sending security edge protection proxy element of the second network. The receiving security edge protection proxy element receives a message from the sending security edge protection proxy element. The receiving security edge protection proxy element detects one or more error conditions associated with the received message. The receiving security edge protection proxy element determines one or more error handling actions to be taken in response to the one or more detected error conditions. One of said one or more error handling actions comprises sending a message by the receiving security edge protection proxy element to the sending security edge protection proxy element, wherein the message comprises instructions to trigger renegotiation of a security mechanism with the sending security edge protection proxy element using different security parameters.

In another embodiment, a method comprises the following steps. A sending security edge protection proxy element is provided in a second network operatively coupled to a first network, wherein the sending security edge protection proxy element is operatively coupled to a receiving security edge protection proxy element of the first network, and in response to detection of one or more error conditions associated with a message sent by the sending security edge protection proxy element to the receiving security edge protection proxy element, the sending security edge protection proxy element receives an error handling message from the receiving security edge protection proxy element. The error handling message comprises instructions to trigger renegotiation of a security mechanism with the sending security edge protection proxy element using different security parameters. The sending security edge protection proxy element at least one of initiates and performs one or more error handling actions at the sending security edge protection proxy element in response to the error handling message.

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.

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 3GPP system elements such as a 3GPP next generation system (<NUM>), 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 <NUM> communication system environment, one or more 3GPP technical specifications (TS) and technical reports (TR) may provide further explanation of network elements/functions and/or operations that may interact with parts of the inventive solutions, e.g., the above-referenced 3GPP TS <NUM> and 3GPP TS <NUM>. Other 3GPP TS/TR documents may provide other conventional details that one of ordinary skill in the art will realize. However, while well-suited for <NUM>-related 3GPP standards, embodiments are not necessarily intended to be limited to any particular standards.

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

<FIG> shows a communication system <NUM> within which illustrative embodiments are implemented. It is to be understood that the elements shown in communication system <NUM> 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> reference specific elements in <NUM> networks that provide these main functions. However, other network elements may be used to implement some or all of the main functions represented. Also, it is to be understood that not all functions of a <NUM> network are depicted in <FIG>. Rather, functions that facilitate an explanation of illustrative embodiments are represented. Subsequent figures may depict some additional elements/functions.

Accordingly, as shown, communication system <NUM> comprises user equipment (UE) <NUM> that communicates via an air interface <NUM> with an access point (gNB) <NUM>. The UE <NUM> may be 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. Such communication devices are also intended to encompass devices commonly referred to as access terminals.

In one embodiment, UE <NUM> 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 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 <NUM>-digit length and consists of a <NUM>-digit Mobile Country Code (MCC), a <NUM>-digit Mobile Network Code (MNC), and a <NUM>-digit Mobile Station Identification Number (MSIN). In a <NUM> 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 Subscription Concealed Identifier (SUCI).

The access point <NUM> is illustratively part of an access network of the communication system <NUM>. Such an access network may comprise, for example, a <NUM> System having a plurality of base stations and one or more associated radio network control functions. The base stations and radio network control functions may be logically separate entities, but in a given embodiment may be implemented in the same physical network element, such as, for example, a base station router or femto cellular access point.

The access point <NUM> in this illustrative embodiment is operatively coupled to mobility management functions <NUM>. In a <NUM> network, the mobility management function is implemented by an Access and Mobility Management Function (AMF). A Security Anchor Function (SEAF) can also be 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 <NUM>). The AMF may also be referred to herein, more generally, as an access and mobility management entity.

The AMF <NUM> in this illustrative embodiment is operatively coupled to home subscriber functions <NUM>, 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) may also be referred to herein, more generally, as an authentication entity. In addition, home subscriber functions may 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).

The access point <NUM> is also operatively coupled to a serving gateway function, i.e., Session Management Function (SMF) <NUM>, which is operatively coupled to a User Plane Function (UPF) <NUM>. UPF <NUM> is operatively coupled to a Packet Data Network, e.g., Internet <NUM>. Further typical operations and functions of such network elements are not described here since they are not the focus of the illustrative embodiments and may be found in appropriate 3GPP <NUM> documentation.

It is to be appreciated that this particular arrangement of system elements 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 <NUM> may comprise other elements/functions not expressly shown herein.

Accordingly, the <FIG> arrangement is just one example configuration of a wireless cellular system, and numerous alternative configurations of system elements may be used. For example, although only single elements/functions are shown in the <FIG> embodiment, this is for simplicity and clarity of description only. A given alternative embodiment may of course 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> illustrates system elements as singular functional blocks, the various subnetworks that make up the <NUM> 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 <NUM> is configured to access one or more of these services via gNB <NUM>.

<FIG> is a block diagram of network elements/functions for providing security management in an illustrative embodiment. System <NUM> is shown comprising a first network element/function <NUM> and a second network element/function <NUM>. It is to be appreciated that the network elements/functions <NUM> and <NUM> 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, NRF, PCF and AF. Further, one or both of the first network element/function <NUM> and the second network element/function <NUM> may also represent a Security Edge Protection Proxy (SEPP), which will be described in further detail below.

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

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

The processors <NUM> and <NUM> of the respective network elements/functions <NUM> and <NUM> 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 <NUM> and <NUM> of the respective network elements/functions <NUM> and <NUM> may be used to store one or more software programs that are executed by the respective processors <NUM> and <NUM> 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 <NUM> and <NUM>.

A given one of the memories <NUM> or <NUM> 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 <NUM> or <NUM> 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 <NUM> and <NUM> of the respective network elements/functions <NUM> and <NUM> 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> that network element/function <NUM> is configured for communication with network element/function <NUM> and vice-versa via their respective interface circuitries <NUM> and <NUM>. This communication involves network element/function <NUM> sending data to the network element/function <NUM>, and the network element/function <NUM> sending data to the network element/function <NUM>. However, in alternative embodiments, other network elements may be operatively coupled between the network elements/functions <NUM> and <NUM>. 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, identifiers, keys, indicators, user data, control data, etc..

It is to be appreciated that the particular arrangement of components shown in <FIG> is an example only, and numerous alternative configurations may be 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 <NUM> and gNB <NUM> 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.

Given the general concepts described above, illustrative embodiments that address certain security management issues will now be described. More particularly, illustrative embodiments provide security management techniques for <NUM> systems. The architecture for <NUM> systems is currently being standardized in 3GPP. As mentioned above, the 3GPP TS <NUM> defines the <NUM> system architecture as service-based, e.g., Service-Based Architecture (SBA).

<FIG> depicts a <NUM> architecture in a configuration comprising a visited public land mobile network (VPLMN) <NUM> operatively coupled via an intermediate Internetwork Packet Exchange (IPX) network <NUM> to a home public land mobile network (HPLMN) <NUM>. Note that there can be more than one IPX network operatively coupled between VPLMN <NUM> and HPLMN <NUM>. More particularly, <FIG> illustrates the presence of a Security Edge Protection Proxy (SEPP) at the edge of each PLMN, i.e., vSEPP <NUM> in VPLMN <NUM> and hSEPP <NUM> in HPLMN <NUM>. It is to be appreciated that the various network functions shown in the VPLMN <NUM> and the HPLMN <NUM> are known and described in detail in various <NUM> specifications such as, but not limited to, the above-referenced TS <NUM> and TS <NUM>.

As mentioned above, in <NUM>, SBA is introduced to model services as network functions (NFs) that communicate with each other using Restful application programming interfaces (Representational State Transfer APIs). In the scenario where the two communicating NFs are in two different PLMNs (e.g., VPLMN <NUM> and HPLMN <NUM>), communication happens over a roaming inter-network interface (N32) between the two participating PLMNs.

To protect NF specific content in the messages that are sent over the roaming inter-network interface, <NUM> introduces the SEPP as the entity residing at the perimeter of the 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 management functions on information elements (IE) in HyperText Transport Protocol (HTTP) messages before the messages are sent externally over the roaming N32 interface. The protected HTTP messages are referred to as N32 messages. Protection such as ALS involves protecting information sent in various parts of the HTTP message including, but not limited to, HTTP Request/Response Line, HTTP header and HTTP Payload. However, some parts of this message may need to be modified by intermediaries (e.g., network provider of IPX <NUM> as shown in <FIG>) between the two SEPPs.

Thus, in <NUM> SBA, the PLMN operator deploys a SEPP at the edge of its network to interoperate and obtain services from network functions in its roaming partner networks. The SEPP interfaces with one or more other SEPPs in one or more other networks over the N32 interface. As an edge proxy, the SEPP implements ALS as mentioned above to protect HTTP messages exchanged between a network function in its network and another network function in the roaming partner network.

For example, <FIG> illustrates an example of a message passing from a network function in a visited network to a network function in a home network via security edge protection proxies. More particularly, example <NUM> in <FIG> depicts a VPLMN <NUM> operatively coupled via an IPX network <NUM> to an HPLMN <NUM>. Assume that AMF NF <NUM> in VPLMN <NUM> invokes an API request on the AUSF NF <NUM> in HPLMN <NUM>. The message flow is as follows:.

More generally, N32 messages are exchanged between two SEPPs sitting at the perimeter of the two networks. The N32 messages are generated by a sending SEPP (sSEPP) by reformatting and protecting the received HTTP message sent by an internal network function (e.g., AMF NF <NUM>) in its network to another network function (e.g., AUSF NF <NUM>) via a receiving SEPP (rSEPP) in the roaming partner network. Note that in one scenario, vSEPP <NUM> is the sSEPP and hSEPP <NUM> is the rSEPP, while in another scenario, hSEPP <NUM> is the sSEPP and vSEPP <NUM> is the rSEPP.

In one or more embodiments, ALS involves protecting information sent in various parts of the HTTP message including, but not limited to, HTTP Request/Response Line, HTTP header and HTTP Payload. Protection of the N32 message is achieved by integrity protection of the complete HTTP message with optional encryption of selected fields in the HTTP message. In addition, selected fields in the HTTP message are eligible for modification by authorized IPX providers (e.g., IPX <NUM>) present in the interconnect network connecting the two operators. At the rSEPP, in one embodiment, the received N32 message is verified in a phased manner and then forwarded to the target NF in the roaming network.

In the rSEPP, the received N32 message is first verified through a series of steps before it is accepted for reassembly into a HTTP message. This process of verification may fail (i.e., result in an error condition) for many reasons. The error could be, by way of example only, due to a malicious intermediate node manipulating the N32 message resulting in an integrity check failure, packet loss due to congestion, a malicious man-in-the-middle (MITM) attacker consciously deleting part of the message related to subscription and identities or service authorization, etc..

In such an event, illustrative embodiments provide for the rSEPP to take corrective actions, which may involve reporting this event to the sSEPP for further action on its end and/or taking necessary actions locally such as, for example, logging the event for offline analysis, etc. More particularly, illustrative embodiments provide security management techniques that comprise an error handling framework. In one or more embodiments, the error handling framework comprises four parts: (<NUM>) the rSEPP detects an error and decides how to resolve the error; (<NUM>) error handling actions initiated by or otherwise performed by the rSEPP; (<NUM>) signaling flow to update (inform) the sSEPP; and (<NUM>) error handling actions initiated by or otherwise performed by the sSEPP.

<FIG> illustrates an error handling framework in the context of a methodology <NUM> for interconnect security in a communication system architecture with security edge protection proxies between a visited network and a home network, according to an illustrative embodiment. More particularly, as shown, a network function <NUM> sends an HTTP Request message to sending SEPP (sSEPP) <NUM> in step <NUM>. As explained above, sSEPP <NUM> generates the N32 message (containing the HTTP Request message) and sends it to receiving SEPP (rSEPP) <NUM> in step <NUM>. There may be one or more IPX networks in between the sSEPP <NUM> and rSEPP <NUM> but are not expressly shown for purposes of simplicity.

It is assumed that one or more errors occur with respect to the N32 message sent by sSEPP <NUM>. The one or more errors could be caused by one or more of the above-mentioned reasons (e.g., an integrity check failure, a packet loss, an MITM attacker, etc.) or some other reason. In accordance with illustrative embodiments, the four-part error handling framework operates as follows:.

This section describes an illustrative embodiment of part one of the four-part error handling framework. Alternative or additional steps may be implemented as needed for a particular error condition.

In step <NUM>, rSEPP <NUM> detects the one or more errors and generates one or more appropriate error codes.

In accordance with illustrative embodiments, the error detection in rSEPP <NUM> may occur in one of two ways:.

One or more error codes are generated. The error code generated depends on the type of error detection used (e.g., multi-level or one-step). For example, when multi-level error detection is used, the error code captures all the errors detected. rSEPP <NUM> analyzes the error code(s) and decides on the next action, as explained below.

This section describes an illustrative embodiment of part two of the four-part error handling framework. Alternative or additional steps may be implemented as needed for a particular error condition.

In step <NUM>, rSEPP <NUM> executes local actions. The kind of actions taken by rSEPP <NUM> may be either based on configuration or analytical tools that are available in rSEPP <NUM>.

By way of example only, the following are types of actions that may be taken by rSEPP <NUM>:.

This section describes an illustrative embodiment of part three of the four-part error handling framework. Alternative or additional steps may be implemented as needed for a particular error condition.

The existing N32 based interconnect interface is used by rSEPP <NUM> to send an N32 signaling message to sSEPP <NUM>. This is denoted as step <NUM> in <FIG>.

In one or more illustrative embodiments, a new SEPP-to-SEPP N32 signaling message is created for this purpose. For example, in one embodiment, the new message comprises the error code(s) generated in part one of the framework, with an additional set of elements or indicator flags that direct sSEPP <NUM> to initiate and/or perform a certain set of recovery actions on its end.

The indicator flags, when set by rSEPP <NUM>, are checked (step <NUM>) and used in sSEPP <NUM> to execute a specific set of actions. The following are some non-limiting examples of indicator flags used and the actions they represent:.

These messages are protected by the SEPP's application layer security mechanism.

This section describes an illustrative embodiment of part four of the four-part error handling framework. Alternative or additional steps may be implemented as needed for a particular error condition.

The sSEPP reviews the obtained error code(s) (step <NUM>) and takes appropriate actions:.

It is to be appreciated that one or more of the parts of the error handling framework illustratively described above in the context of <FIG>, as well as in alternative embodiments, may overlap with one or more other parts of the error handling framework.

It is to be further appreciated that, in one or more illustrative embodiments, two SEPPs may discover each other based on one or more procedures including, but not limited to, Dynamic Host Configuration Protocol (DHCP) or local configuration and uniform resource identifier (URI)-enabled Name Authority Pointer (U-NAPTR) resource records in a Domain Name System (DNS), FQDN configuration in a local database, etc..

Claim 1:
A method performed by a receiving security edge protection proxy element (<NUM>) provided in a first network operatively coupled to a second network in a communication system, wherein the receiving security edge protection proxy element is operatively coupled to a sending security edge protection proxy element of the second network, the method comprising:
receiving a message at the receiving security edge protection proxy element (<NUM>) from the sending security edge protection proxy element (<NUM>);
detecting, at the receiving security edge protection proxy element (<NUM>), one or more error conditions associated with the received message; and
determining, at the receiving security edge protection proxy element (<NUM>), one or more error handling actions to be taken in response to the one or more detected error conditions, wherein one of said one or more error handling actions comprises:
sending a message by the receiving security edge protection proxy element to the sending security edge protection proxy element (<NUM>), wherein the message comprises instructions to trigger renegotiation of a security mechanism with the sending security edge protection proxy element (<NUM>) using different security parameters.