Patent Description:
In <NUM>, a service based architecture is introduced to model services as network functions (NFs) that communicate with each other using RESTful APIs. In the scenario where the two communicating NFs are in two different PLMNs, communication happens over a roaming interface between the two participating PLMNs.

To protect NF specific content in the messages that are sent over the roaming interface, each <NUM> PLMN has a Security Edge Proxy (SEPP) as the entity sitting at the perimeter of the PLMN network and acting as a gateway that protects all the traffic going out of the network. The SEPP implements application layer security for data exchanged between two inter-network NFs at the service layer.

Application layer security involves protecting information sent in various parts of the HTTP message, including HTTP Request/Response Line, HTTP header and HTTP Payload. However, some parts of this message may need to be modified by the intermediaries (IPX providers) between the two SEPPs. Document XP051394670 discloses security of service based architecture of <NUM>, wherein integrity protection is provided in conjunction with requirements for intermediate nodes.

Various aspects of examples of are set out in the claims.

According to a first example aspect, there is provided an apparatus;.

The modification tracking with integrity protecting may allow modification by another entity while enabling detecting what was modified and which entity has performed the modification.

The forming of the second message parts from the features and optional sub-features of the first message parts may be performed according to the security structure definition.

At least one second message part may be subjected to encrypting or integrity protecting; and at least one second message part may be subjected to modification tracking with integrity protecting.

One first message part may be divided into more than one different second message parts. The second message parts may each be subjected to at least one of: encrypting; integrity protecting; or modification tracking with integrity protecting. One or more sub-features of one feature may be subjected to different protection than the feature itself, wherein the protection is selected from a group consisting of: encrypting; integrity protecting; or modification tracking with integrity protecting.

The second message may be subsequently modifiable by one or more intermediate nodes. The second message may be subsequently modifiable by one or more intermediate nodes up to an extent defined by the security structure definition.

The first network function may be an Access and Mobility Function, AMF. The second network function may be an Authentication Server Function, AUSF.

According to a second example aspect, there is provided a method comprising:.

According to a third example aspect, there is provided an intermediate node comprising:.

The security structure definition may be obtained by reading from a memory. Alternatively, the security structure definition may be obtained by receiving from another entity. A portion of the security structure definition may be encoded to computer program code. The portion of the security structure definition encoded to computer program code may be loaded from a memory together with the program code.

The modifying of said given message part may be performed by adding a cryptographically verified record in an array of modifications within the second message.

The modifying of said given message part may be performed differentially by expressing a change.

The modifying of said given message part may be performed by changing the second message and recording an indication of how the second message was changed.

According to a fourth example aspect, there is provided a method in a node, comprising:.

According to a fifth example aspect, there is provided an apparatus;
wherein the apparatus is a security edge proxy comprising:.

The third message may comprise the first message and any changes made to the first message except those that were made by the intermediate nodes and not found acceptable.

The determining how the second message differs from the first message may comprise determining whether the second message does differ from the first message.

According to a sixth example aspect, there is provided a method comprising:.

According to a seventh example aspect, there is provided a computer program comprising computer executable program code configured to execute a method of any preceding example aspect.

The computer program may be stored in a computer readable memory medium.

Any foregoing memory medium may comprise a digital data storage such as a data disc or diskette, optical storage, magnetic storage, holographic storage, opto-magnetic storage, phase-change memory, resistive random access memory, magnetic random access memory, solid-electrolyte memory, ferroelectric random access memory, organic memory or polymer memory. The memory medium may be formed into a device without other substantial functions than storing memory or it may be formed as part of a device with other functions, including but not limited to a memory of a computer, a chip set, and a sub assembly of an electronic device.

According to an eighth example aspect, there is provided a system comprising two or more of the following: the apparatus of the first example aspect; the intermediate node of the third example aspect; the apparatus of the fifth example aspect; and the computer program of the seventh example aspect; and the memory medium.

The embodiments in the foregoing are used merely to explain selected aspects or steps that may be utilized in implementations.

For a more complete understanding of example embodiments, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:.

An example embodiment and its potential advantages are understood by referring to <FIG> of the drawings. In this document, like reference signs denote like parts or steps.

<FIG> shows an architectural drawing of a system <NUM> of an example embodiment. <FIG> shows two PLMNs <NUM> equipped with a first Network Function <NUM> that in a sending case is, for example, an Access and Mobility Function (AMF). The PLMNs each further comprise a Security Edge Proxy (SEPP) <NUM>. The SEPP of one PLMN acts as a sending SEPP <NUM> or sSEPP and another one as a receiving SEPP <NUM> or rSEPP for one message. The SEPP <NUM> is a network node at the boundary of an operator's network that receives a message such as an HTTP request or HTTP response from the network function AMF <NUM>, applies protection for sending, and forwards the reformatted message through a chain of intermediate nodes such as IP eXchanges (IPX) <NUM> towards the rSEPP <NUM>.

The rSEPP <NUM> receives a re-arranged and potentially modified protocol message from an intermediate node <NUM>, re-assembles the message (e.g. HTTP request or response), and forwards the re-assembled message towards a second network function within its operator's network, e.g. an Authentication Server Function (AUSF) <NUM>. The re-assembled message can alternatively be sent towards any other network function of the second network.

The intermediate node <NUM> or intermediary in short is, for example, a network node outside the operator's network that receives (directly or indirectly via other intermediaries) a reformatted message from the sSEPP <NUM>, that may selectively modify the message according to the method for integrity protection with modification tracking, and that forwards the message towards another intermediary <NUM> or to the rSEPP <NUM>.

Notice that the rSEPP <NUM> and sSEPP <NUM> may simultaneously act in both roles and that their structure may also be similar or identical, so both are denoted by same reference sign <NUM> while their role in delivery of a particular message is identified by use of the prefix "s" or "r" indicating whether they send or receive.

Data re-arrangement according to an example embodiment is next described. Assuming the message being an HTTP message that complies to HTTP protocol, the message includes three protocol elements:.

All three parts may contain parameters of a higher-layer protocol that is carried over HTTP, which may be of interest to the intermediaries for reading and/or modifying them.

For each part, the data are re-arranged (for instance by defining a suitable intermediate JSON structure or JSON structures) such that one of the three protection methods defined in the next part can be applied to them (or to desired one or more sub-parts such as given attributes or nested attributes).

Methods of protection of different parts can be freely chosen, while following standardized methods are disclosed for example:.

The integrity protection with modification tracking is configured to store the original data structure together with a signature of the sSEPP <NUM>, and to additionally store the modification chain, one entry per intermediary, and sign each modification chain entry with the signature of the intermediary that has performed the modification. This way, the rSEPP <NUM> can subsequently determine separately for each change whether it was performed by an authorized intermediary <NUM> and whether it complies with the policy for that intermediary.

In an embodiment, the original data structure is dynamic such that each intermediate node <NUM> adds a new field to a modified item so forming a growing array.

<FIG> shows a flow chart of a process of an example embodiment. The process is performed on the JSON objects that are protected with the modE2eProt method, i.e. that require integrity protection but may also be modifiable by the intermediary <NUM>.

NOTE: steps <NUM> and <NUM> can be performed in any order.

<FIG> shows a flow chart of a process of an example embodiment in an sSEPP <NUM>, comprising:.

In an example embodiment, the forming of the second message parts from the features and sub-features of the first message parts is performed according to the security structure definition.

The forming of the second message parts comprises in an example embodiment modifying the content of the first message parts. The modifying of the content of the first message parts may effectively modify the first message. This modifying is performed in an example embodiment before the applying of the encrypting; integrity protecting; or modification tracking with integrity protecting. In an example embodiment, the sSEPP modifies the second message corresponding to the intermediate nodes <NUM> (as will be described in the following). The sSEPP may first form and cryptographically protect the second message and then perform modifications and cryptographically protect them. The cryptographic protecting may comprise using integrity protecting or modification tracking with integrity protecting.

<FIG> shows a flow chart of a process of an example embodiment in an intermediate node <NUM>, comprising:.

<FIG> shows a flow chart of a process an example embodiment in an rSEPP <NUM>, comprising:.

In an example embodiment, only one of rejecting the second message or rejecting some changes is provided for.

A use case is next presented for exemplifying some example embodiments:.

Different first message parts (e.g. a request line or a response line; at least one header; and payload) may be included in the different JSON objects for the different protection types (encryption, integrity protection and modification tracking with integrity protection). In some cases (e.g. in case of some messages and/or some originating network functions), different sub-parts or attributes of one message part are included in different ones of the JSON objects for respective different protection. Each of the objects, e.g. of the JSON objects, may also be embodiments of the second message parts.

NOTE: There may be only a loose relationship between the granularity of the JSON objects stored as being part of the modifiableIntegrityProtectedPayload and the actually allowed modification which might have finer granularity.

Additional binary payloads in multipart messages from the first network function are represented as separate binaryPayload objects.

The SEPP <NUM> executes encryption operation (enc) to encrypt the complete encryptedPayload (and, if applicable, binaryPayload) JSON object.

NOTE: This assumes that an object as a whole is protected completely. Selective encryption of a nested object is also possible.

The sSEPP <NUM> executes e2eProt operation to integrity protect the complete e2eIntegrityProtectedPayload object.

For those JSON objects inside modifiableIntegrityProtectedPayload that require integrity protection but may also be modifiable by an intermediary <NUM>, the procedure defined with reference to <FIG> is executed.

If the validation of the integrity and authenticity of the updates, and their checking against the policy by the rSEPP <NUM> were successful, the rSEPP <NUM> re-assembles the HTTP Request or HTTP Response from the RequestLine or ResponseLine information, the HttpHeaders information, the consolidated JSON object and the remaining E2E protected or encrypted parts of the payload, and forwards it to the second network function <NUM>.

This is an e2e protocol between two SEPP <NUM>. Thus, e2e verification of the message, including authenticity of the intermediaries and validity of their updates, are performed by the rSEPP <NUM>.

For the sSEPP <NUM>, this may be defined e.g. by configuration. The rSEPP <NUM> can learn the applied protection from the structure of the message, and is e.g. configured with policies that define the permitted modifications and authorized intermediaries.

<FIG> shows an example of request message travel. <FIG> illustrates how the original HTTP request message (i.e. first message) is transformed (to a second message) as it traverses in this example from an Access and Mobility Function (AMF) in the operator network via the sSEPP <NUM> at the edge and over an N32 interface through two IPX providers which modify a given Information element (IE4 is used here as an example) in the message. The rSEPP <NUM> verifies the received (second) message, and reassembles the HTTP request message with the modified IE4 (to a third message, which may be same or different by content than the second depending e.g. on whether all modifications were acceptable), before forwarding (third message) it to the second network function <NUM> (e.g. AUSF).

rSEPP <NUM> receives the first or initial message from the first network function <NUM>. In this example:.

Attributes or information elements IE3 and IE4 are integrity protected but may also be modified by the intermediary <NUM>. Hence sSEPP <NUM> generates arrays (IE3_Mod_Chain and IE4_Mod_Chain) to store possible updates by the intermediaries.

Each JWS object created by sSEPP <NUM> contains: protected Header, protected payload, signature. In this context, the header and payload naturally refer to parts of the JWS object.

IPX <NUM> IE4. It creates a patch request, protects it with JWS and inserts it into IE4_Mod_Chain. The example below illustrates the use of the "JSON Merge Patch" format" to capture the forward delta. In the patchRequest object, values of "a" and "Route" are modified to <NUM> and value1 respectively by IPX <NUM>. In addition, a new element is added called "New Element <NUM>". The patchRequest is used as payload by the intermediary <NUM> when creating the JWS object for addition to the IE4_Mod_Chain.

IPX <NUM> updates IE4 including addition of a new element called "New Element <NUM>", integrity protects it with JWS and adds to IE4_Mod_Chain.

rSEPP <NUM> reassembles the message and sends it to the second network function <NUM>.

Once rSEPP <NUM> individually verifies the updates and its validity (process of <FIG>, step <NUM>), the rSEPP <NUM> re-assembles the HTTP Request or HTTP Response from the Request_Line or Response_Line information, the HTTP_Header information, the consolidated JSON object and the remaining E2E protected or encrypted parts of the payload, and forwards it to the second network function <NUM>.

<FIG> shows an example message flow across N32 based on integrity protection with modification tracking based on Forward Delta.

In steps <NUM> to <NUM>, the visited SEPP <NUM> (vSEPP) acts as a sending SEPP <NUM> (sSEPP) and the home SEPP <NUM> (hSEPP) acts as the receiving SEPP <NUM> (rSEPP), whereas in steps <NUM> to <NUM>, the roles are reversed.

The vSEPP <NUM> receives an HTTP request (first message).

The vSEPP <NUM> shall encapsulate the HTTP request line into a JSON object called Request_Line containing an element each for the method, the URI, and the protocol of the request.

The vSEPP <NUM> shall encapsulate the header of the request into a JSON array called HTTP_Header, with each value in the array a JWS object for the header in the original request. The payload for the JWS object includes all headers in the original request.

For those JSON objects that require e2e confidentiality protection between two SEPPs, the vSEPP <NUM> executes JWE to encrypt the object. JWE object replaces the original object in the second message.

For those JSON objects that require e2e integrity protection, vSEPP <NUM> executes JWS to integrity protect the object. JWS object replaces the original object in the second message.

For those JSON objects that require integrity protection but may also be modifiable by the intermediary <NUM>, the vSEPP <NUM> creates to the second message an array per each of those JSON objects. For each of those identified objects, the vSEPP <NUM> shall integrity protect the original object using JWS, and insert the resulting JWS object as the first element of the corresponding array.

The vSEPP <NUM> shall use HTTP POST to send the protected request or second message towards the first intermediary <NUM> (visited network's IPX provider).

The first intermediary <NUM> (e.g. visited network's IPX provider) determines which IEs require updates. For each identified IE, it does the following:.

The first intermediary <NUM> sends the encapsulated request (once modified second message) to the second intermediary <NUM> (home network's IPX) as in step <NUM>.

The second intermediary <NUM> repeats the steps as in step <NUM>.

The second intermediary <NUM> sends the encapsulated request (twice modified second message) to the hSEPP <NUM> as in step <NUM>.

Note: The behaviour of the intermediate nodes is not normative, but the hSEPP <NUM> assumes that behaviour for processing the resulting request.

The hSEPP <NUM> receives the second message with all updates by the intermediate nodes <NUM> stored in corresponding arrays but not applied yet to the original value.

The hSEPP <NUM> verifies integrity and authenticity of each update individually. The hSEPP <NUM> also checks whether the modifications performed by the intermediate nodes were permitted by the policy.

The hSEPP <NUM> then applies patches in order and creates an HTTP Request.

The hSEPP <NUM> sends the HTTP Request resulting from step <NUM> to the home network's second network function <NUM>.

Steps <NUM> to <NUM>: These steps shall be analogous to steps <NUM> to <NUM>, but treating the HTTP response like the HTTP request.

<FIG> shows a block diagram of an apparatus <NUM> according to an embodiment. The apparatus may be used as a first network function <NUM>, a SEPP <NUM>, an intermediate node <NUM>, or a second network function <NUM>.

The apparatus <NUM> comprises a memory <NUM> including a persistent memory <NUM> that comprises computer program code <NUM> and data <NUM>, and work memory <NUM>. The apparatus <NUM> further comprises a processor <NUM> for controlling the operation of the apparatus <NUM> using the computer program code <NUM>, a communication circuitry <NUM> for communicating with other entities. The communication circuitry <NUM> comprises, for example, a local area network (LAN) port; a wireless local area network (WLAN) circuitry; Bluetooth circuitry; cellular data communication circuitry; or satellite data communication circuitry. The processor <NUM> comprises, for example, any one or more of: a master control unit (MCU); a microprocessor; a digital signal processor (DSP); an application specific integrated circuit (ASIC); a field programmable gate array; and a microcontroller.

Without in any way limiting the scope, interpretation, or application of the claims appearing below, a technical effect of one or more of the example embodiments disclosed herein is that inter-network network function messaging can be flexibly protected. Another technical effect of one or more of the example embodiments disclosed herein is that configuration of a <NUM> network can be dynamically changed even from one network function message to another depending on, for example, the network function in question and / or intermediate nodes needed for message traversal to destination network function. Yet another technical effect of one or more of the example embodiments disclosed herein is that the receiving the intermediate nodes need not be configured to be capable of validating outputs of other intermediate nodes or of the sSEPP. The validating of the first message content transferred by the intermediate nodes may be performed by the rSEPP independently of the intermediate nodes.

Embodiments may be implemented in software, hardware, application logic or a combination of software, hardware and application logic. In the context of this document, a "computer-readable medium" may be any non-transitory media or means that can contain, store, communicate, propagate or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer, with one example of a computer described and depicted in <FIG>. A computer-readable medium may comprise a computer-readable storage medium that may be any media or means that can contain or store the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer.

Moreover, where reference is made to one component or entity, its functions may be distributed to or more sub-units, e.g. instead of one processor, a plurality of processors may perform some, though not necessarily all, operations of one entity.

Although various aspects are set out in the independent claims, other aspects comprise other combinations of features from the described embodiments and/or the dependent claims with the features of the independent claims, and not solely the combinations explicitly set out in the claims.

Claim 1:
An intermediate node comprising means for performing:
receiving a second message comprising a plurality of second message parts, originating from a security edge proxy and addressed to a second network function;
the second message parts each including one or more features and optional sub-features;
obtaining a security policy for the intermediate node and a security structure definition that defines a required security measure for each of the features and sub-features;
checking if both a) the node has a need to change a given message part and b) said given message part is modifiable according to the security structure definition and the security policy, and if both conditions were met, then modifying said given feature or sub-feature with evidence of identity of the node and change made; and
forwarding the second message towards the second network function.