Method and apparatus for security protection

Abstract

Embodiments of the present disclosure provide method and apparatus for security protection. A method performed by a first network node in a first network may comprise sending, to a second network node in a second network, a first message comprising a list of ciphered information and at least one of a path part of a first universal resource identifier (URI) or a parameter part of the first URI. The path part of the first URI may comprise a first reference to encrypted first information in the list of ciphered information and / or the parameter part of the first URI may comprise a second reference to encrypted second information in the list of ciphered information.

Description

METHOD AND APPARATUS FOR SECURITY PROTECTIONTECHNICAL FIELDThe non-limiting and exemplary embodiments of the present disclosure generally relate to the technical field of communications, and specifically to methods and apparatuses for security protection.BACKGROUNDThis section introduces aspects that may facilitate a better understanding of the disclosure. 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.In communication networks such as fifth generation system (5GS) as defined by 3rd Generation Partnership Project (3GPP) , various security protection functionalities may be implemented in various network interfaces. For example, a network interface may provide message protection of the information exchanged between a first network node such as network function (NF) service consumer and a second network node such as NF service producer and forwarding of the application layer protected message from a first network node to the second network node.For example, 3GPP Technical Specification (TS) 29.573 V18.5.0, the disclosure of which is incorporated by reference herein in its entirety, has specified the interconnect interfaces used between the Public Land Mobile Networks (PLMNs) and / or Standalone Non-Public Networks (SNPNs) for transporting the service based interface message exchanges. As described in 3GPP TS 29.573 V18.5.0, the N32 interface may be used between Security Edge Protection Proxies (SEPPs) of different PLMNs for both roaming and PLMN interconnect scenarios. The N32 interface may also be used between SEPPs from an SNPN and another SNPN or PLMN, for SNPN interconnect scenarios. The security protection functionalities may be implemented in the N32 interface.SUMMARYThis summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.There may be some limitations in current security protection functionalities.For example, certain sensitive information can not be integrity protected or encrypted. For example, as defined in 3GPP TS 29.573 V18.5.0, certain sensitive information may be included in resource path, e.g. in Unified Data Management (UDM) Application Programming Interface (API) :{apiRoot}  / nudm-uecm / v1 /  {ueId}  / registrations / smf-registrations /  {pduSessionId}In this example, one of the parameters is the user equipment (UE) identity (ID) (ueId) , which also happens to be potentially sensitive according to Table 6.1.5.3.5-1 in 3GPP TS 29.573 V18.5.0. However, it is not possible to define a protection policy for such sensitive information in the resource path according to 3GPP TS 29.573 V18.5.0.Table 6.1.5.3.5-1: Enumeration IeTypeIt is not specified how to format the sensitive information contained in the resource path and / or query parameters. For example, 3GPP TS 29.573 V18.5.0 currently specified that the formatted message can contain the reference to the encrypted blocks for Hypertext Transfer Protocol (HTTP) headers or HTTP payload / contents. An encrypted HTTP header may contain the header name and the value part may contain the index to the encrypted block. An encrypted JavaScript Object Notation (JSON) information element (IE)  / Body contains the IE path as the JSON pointer of the encrypted IE and the value part contains the index to the encrypted block. However it is not specified how to format the sensitive information contained in the resource path and / or query parameters in the formatted messages via N32.To overcome or mitigate at least one of above mentioned problems or other problems, the embodiments of the present disclosure propose a solution for security protection.In a first aspect of the disclosure, there is provided a method performed by a first network node in a first network. The method may comprise sending, to a second network node in a second network, a first message comprising a list of ciphered information and at least one of a path part of a first universal resource identifier (URI) or a parameter part of the first URI.In an embodiment, the path part of the first URI may comprise a first reference to encrypted first information in the list of ciphered information and / or the parameter part of the first URI may comprise a second reference to encrypted second information in the list of ciphered information.In an embodiment, the list of ciphered information may comprise a list of array items of encrypted information, and wherein the encrypted information comprises the encrypted first information and the encrypted second information.In an embodiment, the method may comprise receiving a second message comprising a second URI from a third network node in the first network.In an embodiment, the method may comprise reformatting the second message to the first message by at least one of encrypting the first information located in the path part of the second URI and / or the second information located in the parameter part of the second URI; adding the encrypted first information and / or the encrypted second information into the list of ciphered information; and generating the path part of the first URI and / or the parameter part of the first URI by reformatting the first information located in the path part of the second URI with the first reference and / or reformatting the second information located in the parameter part of the second URI with the second reference.In an embodiment, the first information and the second information may comprise sensitive information.In an embodiment, the sensitive information may comprise at least one of a user equipment identifier, key material, authentication material, authorization token, or a user equipment location.In an embodiment, a query parameter may comprise a name of the query parameter and the second information, and the name of the query parameter and the second reference to the encrypted second information are carried in an array item in the first message.In an embodiment, the method may comprise sending, to the second network node, a fifth message indicating that the first network node supports protection of the first information in URI.In an embodiment, the method may comprise receiving, from the second network node, a sixth message indicating that the second network node supports protection of the first information in URI.In an embodiment, the method may comprise sending, to the second network node, a third message.In an embodiment, the method may comprise receiving, from the second network node, a fourth message.In an embodiment, the third message and / or the fourth message comprise at least one of information indicating the first information is located in the URI path part and information indicating the first information.In an embodiment, the information indicating the first information may comprise at least one of a pattern of the first information, an index of a segment of the first information in the URI path part, or a name of the first information in the URI path part.In an embodiment, the pattern of the first information may comprise at least one of a regular expression of the first information, or a specific prefix of the first information.In an embodiment, the first network node may comprise a security edge protection proxy in the first network and the second network node may comprise a security edge protection proxy in the second network.In a second aspect of the disclosure, there is provided a method performed by a second network node in a second network. The method may comprise receiving, from a first network node in a first network, a first message comprising a list of ciphered information and at least one of a path part of a first universal resource identifier (URI) or a parameter part of the first URI.In an embodiment, the path part of the first URI may comprise a first reference to encrypted first information in the list of ciphered information and / or the parameter part of the first URI may comprise a second reference to encrypted second information in the list of ciphered information.In an embodiment, the method may comprise generating a second message comprising a second URI based on the first message by at least one of decrypting the encrypted first information and / or the encrypted second information and generating the path part of the second URI and / or the parameter part of the second URI by at least replacing the first reference with the first information and / or replacing the second reference with the second information.In an embodiment, the method may comprise sending the second message comprising the second URI to a fourth network node in the second network.In an embodiment, the first information and the second information may comprise sensitive information.In an embodiment, the sensitive information may comprise at least one of a user equipment identifier, key material, authentication material, authorization token, or a user equipment location.In an embodiment, a query parameter may comprise a name of the query parameter and the second information, and the name of the query parameter and the second reference to the encrypted second information are carried in an array item in the first message.In an embodiment, the method may comprise receiving, from the first network node, a fifth message indicating that the first network node supports protection of the first information in URI.In an embodiment, the method may comprise sending, to the first network node, a sixth message indicating that the second network node supports protection of the first information in URI.In an embodiment, the method may comprise receiving, from the first network node, a third message.In an embodiment, the method may comprise sending, to the first network node, a fourth message.In a third aspect of the disclosure, there is provided a first network node in a first network. The first network node may comprise a processor and a memory coupled to the processor. Said memory contains instructions executable by said processor. Said first network node is operative to send, to a second network node in a second network, a first message comprising a list of ciphered information and at least one of a path part of a first universal resource identifier (URI) or a parameter part of the first URI. The path part of the first URI may comprise a first reference to encrypted first information in the list of ciphered information and / or the parameter part of the first URI comprises a second reference to encrypted second information in the list of ciphered information.In an embodiment, said first network node is operative to perform any of the method of the first aspect of the disclosure.In a fourth aspect of the disclosure, there is provided a second network node in a second network. The second network node comprises a processor and a memory coupled to the processor. Said memory contains instructions executable by said processor. Said second network node is operative to receive, from a first network node in a first network, a first message comprising a list of ciphered information and at least one of a path part of a first universal resource identifier (URI) or a parameter part of the first URI. The path part of the first URI may comprise a first reference to encrypted first information in the list of ciphered information and / or the parameter part of the first URI comprises a second reference to encrypted second information in the list of ciphered information.In an embodiment, said first network node is operative to perform any of the method of the second aspect of the disclosure.In another aspect of the disclosure, there is provided a computer program product comprising instructions which when executed by at least one processor, cause the at least one processor to perform the method according to any one of the first or second aspect.In another aspect of the disclosure, there is provided a computer-readable storage medium storing instructions which when executed by at least one processor, cause the at least one processor to perform the method according to any one of the first or second aspect.Embodiments herein may provide many advantages, of which a non-exhaustive list of examples follows. In some embodiments herein, the proposed solution provides a flexible mechanism to allow the network node (such as SEPP / intermediaries via N32) to configure and exchange protection policies for sensitive information in the resource path. In some embodiments herein, the proposed solution can enable the network node to reformat and forward a (e.g. HTTP) message containing sensitive information in the resource path and / or query parameters. The embodiments herein are not limited to the features and advantages mentioned above. A person skilled in the art will recognize additional features and advantages upon reading the following detailed description.BRIEF DESCRIPTION OF THE DRAWINGSThe above and other aspects, features, and benefits of various embodiments of the present disclosure will become more fully apparent, by way of example, from the following detailed description with reference to the accompanying drawings, in which like reference numerals or letters are used to designate like or equivalent elements. The drawings are illustrated for facilitating better understanding of the embodiments of the disclosure and not necessarily drawn to scale, in which:FIG. 1a schematically shows roaming 5G System architecture-local breakout scenario in service-based interface representation;FIG. 1b schematically shows roaming 5G system architecture-home routed scenario in service-based interface representation;FIG. 2a schematically shows an example of N32-c Interface;FIG. 2b schematically shows an example of N32-f Interface;FIG. 2c schematically shows a flowchart of Security Capability Negotiation Procedure;FIG. 2d schematically shows a flowchart of Parameter Exchange Procedure for Cipher Suite Negotiation;FIG. 2e schematically shows a flowchart of Message Forwarding between SEPP on N32-f;FIG. 3 and 4a show flowcharts of methods according to embodiments of the present disclosure;FIG. 4b shows an example of JSON representation of a reformatted HTTP message;FIG. 4c shows an example of Transformation of HTTP Header and Content to Encrypt into CipherText;FIG. 4d, 4e, 5a, 5b, 5c and 5d show flowcharts of methods according to embodiments of the present disclosure;FIG. 6 shows a flowchart of protection policy exchange and message forwarding with protection policy according to another embodiment of the present disclosure; andFIG. 7 is a block diagram showing an apparatus suitable for practicing some embodiments of the disclosure.DETAILED DESCRIPTIONThe embodiments of the present disclosure are described in detail with reference to the accompanying drawings. It should be understood that these embodiments are discussed only for the purpose of enabling those skilled persons in the art to better understand and thus implement the present disclosure, rather than suggesting any limitations on the scope of the present disclosure. Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present disclosure should be or are in any single embodiment of the disclosure. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present disclosure. Furthermore, the described features, advantages, and characteristics of the disclosure may be combined in any suitable manner in one or more embodiments. One skilled in the relevant art will recognize that the disclosure may be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the disclosure.As used herein, the term “network” refers to a network following any suitable communication standards such as new radio (NR) , long term evolution (LTE) , LTE-Advanced, wideband code division multiple access (WCDMA) , high-speed packet access (HSPA) , Code Division Multiple Access (CDMA) , Time Division Multiple Address (TDMA) , Frequency Division Multiple Access (FDMA) , Orthogonal Frequency-Division Multiple Access (OFDMA) , Single carrier frequency division multiple access (SC-FDMA) and other wireless networks. A CDMA network may implement a radio technology such as Universal Terrestrial Radio Access (UTRA) , etc. UTRA includes WCDMA and other variants of CDMA. A TDMA network may implement a radio technology such as Global System for Mobile Communications (GSM) . An OFDMA network may implement a radio technology such as Evolved UTRA (E-UTRA) , Ultra Mobile Broadband (UMB) , IEEE 802.11 (Wi-Fi) , IEEE 802.16 (WiMAX) , IEEE 802.20, Flash-OFDMA, Ad-hoc network, wireless sensor network, etc. In the following description, the terms “network” and “system” can be used interchangeably. Furthermore, the communications between two devices in the network may be performed according to any suitable communication protocols, including, but not limited to, the communication protocols as defined by a standard organization such as 3GPP. For example, the communication protocols may comprise the first generation (1G) , 2G, 3G, 4G, 4.5G, 5G, 6G communication protocols, and / or any other protocols either currently known or to be developed in the future.The term “network device” or “network node” or “network function” refers to any suitable function which can be implemented in a network entity (physical or virtual) of a communication network. For example, the network function can be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g. on a cloud infrastructure. For example, the 5G system (5GS) may comprise a plurality of NFs such as Access and Mobility Management Function (AMF) , Session Management Function (SMF) , Authentication Service Function (AUSF) , Unified Data Management (UDM) , Policy Control Function (PCF) , Application Function (AF) , Network Exposure Function (NEF) , User plane Function (UPF) and Network Repository Function (NRF) , radio access network (RAN) , service communication proxy (SCP) , network data analytics function (NWDAF) , network slice Selection Function (NSSF) , network slice-Specific Authentication and Authorization Function (NSSAAF) , etc. In other embodiments, the network function may comprise different types of NFs for example depending on a specific network. For example, the 4G system (such as Long Term Evolution (LTE) ) may include Mobile Management Entity (MME) , home subscriber server (HSS) , PCRF (Policy and Charging Rules Function) , PGW (Packet Data Network Gateway) , PGW control plane (PGW-C) , PGW user plane (PGW-U) Serving gateway (SGW) , SGW control plane (SGW-C) , SGW user plane (SGW-U) , E-UTRAN Node B (eNB) , etc. In other embodiments, the network function may comprise different types of NFs for example depending on a specific network.Virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to a provider edge node and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components (e.g., via one or more applications, components, functions, virtual machines or containers executing on one or more physical processing nodes in one or more networks) .In some embodiments, some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines implemented in one or more virtual environments hosted by one or more of hardware nodes. Further, in embodiments in which the virtual node is not a radio access node or does not require radio connectivity (e.g., a core network node) , then the provider edge node or PE may be entirely virtualized.The functions may be implemented by one or more applications (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc. ) operative to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein. Applications are run in virtualization environment which provides hardware comprising processing circuitry and memory. Memory contains instructions executable by processing circuitry whereby application is operative to provide one or more of the features, benefits, and / or functions disclosed herein.Virtualization environment, comprises general-purpose or special-purpose network hardware devices comprising a set of one or more processors or processing circuitry, which may be commercial off-the-shelf (COTS) processors, dedicated Application Specific Integrated Circuits (ASICs) , or any other type of processing circuitry including digital or analog hardware components or special purpose processors. Each hardware device may comprise memory which may be non-persistent memory for temporarily storing instructions or software executed by processing circuitry. Each hardware device may comprise one or more network interface controllers (NICs) , also known as network interface cards, which include physical network interface. Each hardware device may also include non-transitory, persistent, machine-readable storage media -having stored therein software and / or instructions executable by processing circuitry. Software may include any type of software including software for instantiating one or more virtualization layers (also referred to as hypervisors) , software to execute virtual machines as well as software allowing it to execute functions, features and / or benefits described in relation with some embodiments described herein.Virtual machines, comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer or hypervisor. Different embodiments of the instance of virtual appliance may be implemented on one or more of virtual machines, and the implementations may be made in different ways.During operation, processing circuitry executes software to instantiate the hypervisor or virtualization layer, which may sometimes be referred to as a virtual machine monitor (VMM) . Virtualization layer may present a virtual operating platform that appears like networking hardware to virtual machine.References in the specification to “one embodiment, ” “an embodiment, ” “an example embodiment, ” and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.It shall be understood that although the terms “first” and “second” etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term “and / or” includes any and all combinations of one or more of the associated listed terms.As used herein unless expressly stated to the contrary, the phrase “at least one of A and B” or “at least one of A or B” should be understood to mean any of the following “only A, only B, or both A and B. ” The phrase “A and / or B” should be understood to mean any of the following “only A, only B, or both A and B” .As used herein unless expressly stated to the contrary, the phrase “a plurality of” followed by a conjunctive list of enumerated items (e.g., “A and B” , “A, B, and C” ) is intended to mean “multiple items, with each item selected from the list consisting of” the enumerated items. For example, “a plurality of A and B” is intended to mean any of the following: more than one A; more than one B; or at least one A and at least one B.The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms “a” , “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” , “comprising” , “has” , “having” , “includes” and / or “including” , when used herein, specify the presence of stated features, elements, and / or components etc., but do not preclude the presence or addition of one or more other features, elements, components and / or combinations thereof.It is noted that these terms as used in this document are used only for ease of description and differentiation among nodes, devices or networks etc. With the development of the technology, other terms with the similar / same meanings may also be used.In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.Although the subject matter described herein may be implemented in any appropriate type of system using any suitable components, the embodiments disclosed herein are described in relation to a communication system complied with the exemplary system architecture illustrated in FIGs. 1a and 1b. For simplicity, the system architecture of FIGs. 1a and 1b only depicts some exemplary elements. In practice, a communication system may further include any additional elements suitable to support communication between terminal devices or between a wireless device and another communication device, such as a landline telephone, a service provider, or any other network node or terminal device. The communication system may provide communication and various types of services to one or more terminal devices to facilitate the terminal devices’ access to and / or use of the services provided by, or via, the communication system.FIG. 1a schematically shows roaming 5G System architecture-local breakout scenario in service-based interface representation. The architecture of FIG. 1a is same as Figure 4.2.4-1 of 3GPP TS 23.501 V18.4.0, the disclosure of which is incorporated by reference herein in its entirety.FIG. 1b schematically shows roaming 5G system architecture-home routed scenario in service-based interface representation. The architecture of FIG. 1b is same as Figure 4.2.4-3 of 3GPP TS 23.501 V18.4.0.The system architecture of FIGs. 1a-1b may comprise a plurality of network functions (NFs) such as Access and Mobility Management Function (AMF) , Session Management Function (SMF) , Authentication Service Function (AUSF) , Unified Data Management (UDM) , Policy Control Function (PCF) , Application Function (AF) , Network Exposure Function (NEF) , User plane Function (UPF) and Network Repository Function (NRF) , (radio) access network ( (R) AN) , Network Slice Selection Function (NSSF) , network slice-specific authentication and authorization function (NSSAAF) , network slice admission control function (NSACF) , visited Security Edge Protection Proxy (SEPP) (vSEPP) , home SEPP (hSEPP) , etc. VPLMN denotes visited PLMN. HPLMN denotes home PLMN.In accordance with an exemplary embodiment, the UE can establish a signaling connection with the AMF over the reference point N1, as illustrated in FIGs. 1a-1b. This signaling connection may enable NAS (Non-access stratum) signaling exchange between the UE and the core network, comprising a signaling connection between the UE and the (R) AN and the N2 connection for this UE between the (R) AN and the AMF. The (R) AN can communicate with the UPF over the reference point N3. The UE can establish a protocol data unit (PDU) session to the DN (data network, e.g. an operator network or Internet) through the UPF over the reference point N6.As further illustrated in FIGs. 1a-1b, the exemplary system architecture also contains the service-based interfaces such as Nnrf, Nnef, Nausf, Nudm, Npcf, Namf, Nnsacf, Nnssf, Nnwdaf, Nnssaaf and Nsmf exhibited by NFs such as the NRF, the NEF, the AUSF, the UDM, the PCF, the AMF, the NSACF, the NSSF, the NWDAF, NSSAAF and the SMF. In addition, FIGs. 1a-1b also shows some reference points such as N1, N2, N3, N4, N6, N32 and N9, which can support the interactions between NF services in the NFs. For example, these reference points may be realized through corresponding NF service-based interfaces and by specifying some NF service consumers and providers as well as their interactions in order to perform a particular system procedure.Various NFs shown in FIGs. 1a-1b may be responsible for functions such as session management, mobility management, authentication, security, etc. The AUSF, AMF, DN, NEF, NRF, NSSF, PCF, SMF, UDM, UPF, AF, UE, (R) AN, SCP, NSACF, NSSAAF may include the functionality for example as defined in clause 6.2 of 3GPP TS 23.501 V18.4.0.3GPP TS 23.501 V18.4.0 has specified defined SEPP for inter-Public Land Mobile Network (PLMN) Service Based Interface (SBI) traffic between PLMNs. When an NF communicates with another NF in a different PLMN using SBI interface, the SBI message may be relayed via a N32 interface by a pair of SEPPs. When SBI messages are exchanged between SEPPs, 3GPP has required that sensitive information (e.g. in Table 6.1.5.3.5-1) shall be protected and encrypted on N32.The SEPP that is on the NF service consumer side may be called the c-SEPP and the SEPP that is on the NF service producer may be called the p-SEPP. The NF service consumer or SCP may be configured with the c-SEPP or discover the c-SEPP by querying the NRF. The NF service producer or SCP may be configured with the p-SEPP or discover the p-SEPP by querying the NRF.The N32 interface can be logically considered as 2 separate interfaces as given below.-N32-c, a control plane interface between the SEPPs for performing initial handshake and negotiating the parameters to be applied for the actual N32 message forwarding.-N32-f, a forwarding interface between the SEPPs which is used for forwarding the communication between the NF service consumer and the NF service producer after applying application level security protection or TLS security protection.FIG. 2a schematically shows an example of N32-c Interface, which is the same as Figure 4.2.2-1 of 3GPP TS 29.573 V18.5.0.The N32-c interface may provide the following functionalities:-Initial handshake procedure between the SEPP in PLMN A (called the initiating SEPP) and the SEPP in PLMN B (called the responding SEPP) , that involves capability negotiation and parameter exchange as specified in 3GPP TS 33.501 V18.4.0, the disclosure of which is incorporated by reference herein in its entirety.In an embodiment, the subject matter described herein may be implemented in the roaming reference architecture as defined in clause 4.2.4 of 3GPP TS 23.501 V18.4.0 or the roaming architecture as defined in clause 4.2.2 of 3GPP TS 23.401 V18.4.0, the disclosure of which is incorporated by reference herein in its entirety.FIG. 2b schematically shows an example of N32-f Interface, which is the same as Figure 4.2.3-1b of 3GPP TS 29.573 V18.5.0.The N32-f interface may be used to forward the HTTP / 2 messages of the NF service producers and the NF service consumers in different PLMN, through the SEPPs of the respective PLMN. The application layer security protection functionality of the N32-f may be used only if the PRotocol for N32 INterconnect Security (PRINS) is negotiated between the SEPPs using N32-c.The N32-f interface may provide the following application layer security protection functionalities:-Message protection of the information exchanged between the NF service consumer and the NF service producer across PLMNs by applying application layer security mechanisms as specified in 3GPP TS 33.501 V18.4.0.-Forwarding of the application layer protected message from a SEPP in one PLMN to a SEPP in another PLMN. Such forwarding may involve Internet protocol (IP) Exchange Service (IPX) providers on path.-If IPX providers are on the path from SEPP in PLMN A to SEPP in PLMN B, the forwarding on the N32-f interface may involve the insertion of content modification instructions which the receiving SEPP applies after verifying the integrity of such modification instructions.If Transport Layer Security (TLS) is the negotiated security policy between the SEPP, then the N32-f shall involve only the forwarding of the HTTP / 2 messages of the NF service producers and the NF service consumers without any reformatting at the SEPPs and / or the IPXs.3GPP TS 29.573 V18.5.0 has specified that the security parameters including the protection policies will be exchanged between SEPP / Intermediaries via N32-c negotiation.The protection policies specified the sensitive IEs to be integrity protected and cyphered, where the sensitive IEs can be in URI queries, headers or HTTP contents.FIG. 2c schematically shows a flowchart of Security Capability Negotiation Procedure, which is the same as Figure 5.2.2-1 of 3GPP TS 29.573 V18.5.0.The initiating SEPP shall initiate a Security Capability Negotiation procedure towards the responding SEPP to agree on a security mechanism to use for protecting NF service related signaling over N32-f. An end to end TLS connection shall be setup between the SEPPs before the initiation of this procedure. This procedure may also be used to tear down the N32-f TLS connection if the remote SEPP indicated support of the feature NFTLST during the setup of the N32-c connection.The steps of FIG. 2c are described in clause 5.2.2 of 3GPP TS 29.573 V18.5.0 as follow.1. The initiating SEPP issues a HTTP POST request towards the responding SEPP with the request body containing the "SecNegotiateReqData" IE carrying the following information:-Supported security capabilities (i.e., PRINS and / or TLS) ;-Whether the 3gpp-Sbi-Target-apiRoot HTTP header is supported, if TLS security is supported;-Sender PLMN ID (s) or SNPN ID (s) ;-Target PLMN ID or SNPN ID;-Purpose of the intended usage of N32 connection.-The senderN32fFqdn IE, if the initiating SEPP wishes the responding SEPP to establish the N32-f connection towards a specific FQDN (of the initiating SEPP) .-The senderN32fPortList IE, if the initiating SEPP wishes the responding SEPP to establish the N32-f connection using a specific port number. When present, the list shall contain one port number per supported security capability (i.e., PRINS and / or TLS) .If different PLMNs or SNPNs are represented by different PLMN IDs or SNPN IDs (respectively) supported by a SEPP, then the SEPP shall use separate N32-connections for each pair of local and remote PLMN or SNPN. Both SEPPs shall store the mapping between the N32 connections and their pair of PLMN IDs or SNPN IDs.NOTE 1: If SEPPs support separate FQDN per PLMN or SNPN, then Target PLMN Id or Target SNPN Id is not required as target PLMN or SNPN can be selected by the FQDN.To tear down the N32-f connection when negotiated security scheme is TLS, the "SecNegotiateReqData" IE shall contain:-Supported security capability set to "NONE"2a. On successful processing of the request, the responding SEPP shall respond to the initiating SEPP with a "200 OK" status code and a POST response body that contains "SecNegotiateRspData" IE carrying the following information:-Selected security capability (i.e., PRINS or TLS) ;-Whether the 3gpp-Sbi-Target-apiRoot HTTP header is supported, if TLS security is selected;-Sender PLMN ID (s) or SNPN ID (s) .-Purpose of the accepted usage of N32 connection.-The senderN32fFqdn IE, if the responding SEPP wishes the initiating SEPP to establish the N32-f connection towards a specific FQDN (of the responding SEPP) .-The senderN32fPort IE, if the responding SEPP wishes the initiating SEPP to establish the N32-f connection using a specific port number.NOTE 2: Same SEPP endpoints can serve all accepted purposes over the same N32-f connection established as the result of request / response messages.The responding SEPP compares the initiating SEPP's supported security capabilities to its own supported security capabilities and selects, based on its local policy, a security mechanism, which is supported by both the SEPPs. If the selected security capability indicates any other capability other than PRINS, then the HTTP / 2 connection initiated between the two SEPPs for the N32 handshake procedures shall be terminated. The negotiated security capability shall be applicable on both the directions. If the selected security capability is PRINS, then the two SEPPs may decide to create (if not available)  / maintain HTTP / 2 connection (s) where each SEPP acts as a client towards the other (which acts as a server) . This may be used for later signaling of N32-f error reporting procedure (see clause 5.2.5) and N32-f context termination procedure (see clause 5.2.4) .If different PLMNs or SNPNs are represented by different PLMN IDs or SNPN IDs (respectively) supported by a SEPP, then the SEPP shall use separate N32-connections for each pair of local and remote PLMN or SNPN. Both SEPPs shall store the mapping between the N32 connections and their pair of PLMN IDs or SNPN IDs.The SEPP shall select the PLMN or SNPN from the list of supported PLMN (s) or SNPN (s) based on the received Target PLMN ID or SNPN ID, or based on PLMN or SNPN specific FQDN used in the request, and provide the selected PLMN's PLMN Id (s) in the plmnIdList or the selected SNPN's SNPN Id (s) in the snpnIdList.In case no purposes are exchanged, the receiving SEPP shall assume by default that purposes are for Roaming and inter-PLMN mobility as described in clause 6.1.5.3.9.The initiating SEPP and / or responding SEPP may enable the establishment of an N32 connection for the purpose of Disaster Roaming only during disaster conditions.When the request is for tearing down the existing N32-f TLS connection, the "SecNegotiateRspData" IE shall contain:-Supported security capability set to "NONE"and, subsequently, both SEPP shall terminate the N32-c and N32-f TLS connection.If the initiating SEPP receives the senderN32fFqdn IE and / or the senderN32fPort IE from the responding SEPP, the initiating SEPP shall establish the N32-f connection towards the responding SEPP using the received N32-f FQDN and / or the senderN32fPort IE.If the responding SEPP receives the senderN32fFqdn IE and / or the senderN32fPortList IE from the initiating SEPP, the responding SEPP shall establish the N32-f connection towards the initiating SEPP using the received N32-f FQDN and / or the N32-f port number received in the senderN32fPortList IE corresponding to the selected security capability (i.e., TLS or PRINS) .If the N32-f context exists between the peer SEPPs, and the N32 exchange capability request is not for tearing down the N32-f connections, the responding SEPP shall:-stop sending any further messages over the N32-f towards the initiating SEPP;-delete the current N32-f context and terminate any N32-f connection with the initiating SEPP; and-process the received exchange capability request.2b. On failure or redirection, the responding SEPP shall respond to the initiating SEPP with an appropriate status code as specified in clause 6.1.4.2.If the responding SEPP has sent an outgoing Security Capability Negotiation request to the initiating SEPP, the responding SEPP shall compare the FQDN of the initiating SEPP that has been received in the incoming Security Capability Negotiation request message with the FQDN of the responding SEPP that has been sent in the outgoing Security Capability Negotiation request. If the responding SEPP's FQDN lexicographically precedes, it shall reject the incoming HTTP request message with the cause "N32C_EXCHANGE_CAPABILITY_ONGOING" and it shall continue with its initiated procedure and vice versa.EXAMPLE: assuming SEPP A's FQDN is "sepp. 5gc. mnc345. mcc012.3gppnetwork. org" and SEPP B's FQDN is "sepp. 5gc. mnc346. mcc012.3gppnetwork. org" , then SEPP A's FQDN precedes SEPP B's FQDN and SEPP A proceeds with its exchange capability procedure.A SEPP may be configured to accept an HTTP request from a given PLMN and not to send an HTTP request for exchange capability towards that PLMN.FIG. 2d schematically shows a flowchart of Parameter Exchange Procedure for Cipher Suite Negotiation, which is the same as Figure 5.2.3.2-1 of 3GPP TS 29.573 V18.5.0.The parameter exchange procedure for cipher suite negotiation shall be performed after the security capability negotiation procedure if the selected security policy is PRINS. If there is a change in the cipher suite and the SEPP wants to renegotiate it, then the SEPP may reuse the parameter exchange procedure to override what was exchanged before.The steps of FIG. 2d are described in clause 5.2.3.2 of 3GPP TS 29.573 V18.5.0 as follow.1. The initiating SEPP issues a HTTP POST request towards the responding SEPP with the request body containing the "SecParamExchReqData" IE carrying the following information-Supported cipher suites;The supported cipher suites shall be an ordered list with the cipher suites mandated by 3GPP TS 33.501 V18.4.0 appearing at the top of the list.The initiating SEPP also provides a N32-f context identifier for the responding SEPP to use towards the initiating SEPP for subsequent JOSE Protected Message Forwarding procedures over N32-f (see clause 5.3.3 of 3GPP TS 29.573 V18.5.0) when the responding SEPP acts as the forwarding SEPP.2a. On successful processing of the request, the responding SEPP shall respond to the initiating SEPP with a "200 OK" status code and a POST response body that contains the following information-Selected cipher suiteThe responding SEPP compares the initiating SEPP's supported cipher suites to its own supported cipher suites and selects, based on its local policy, a cipher suite, which is supported by both the SEPPs. The responding SEPP's supported cipher suites shall be an ordered list with the cipher suites mandated by 3GPP TS 33.501 V18.4.0 appearing at the top of the list. The selected cipher suite is applicable for both the directions of communication between the SEPPs.The responding SEPP also provides a N32-f context identifier for the initiating SEPP to use towards the responding SEPP for subsequent JOSE Protected Message Forwarding procedures over N32-f (see clause 5.3.3 of 3GPP TS 29.573 V18.5.0) when the initiating SEPP acts as the forwarding SEPP.If the receiving SEPP already has a previously negotiated cipher suite, the SEPP shall overwrite it with the new one.2b. On failure, the responding p-SEPP shall respond to the initiating SEPP with an appropriate 4xx / 5xx status code as specified in clause 6.1.4.3 of 3GPP TS 29.573 V18.5.0. If the SEPP already has a previously negotiated cipher suite, the SEPP shall continue to use the same.NOTE : If a SEPP already has a previously negotiated cipher suite and a new cipher suite is also received, the SEPP starts applying the new cipher suite immediately and also continues with the old cipher suite for a limited time period. This allows messages with old policies to be completed gracefully.If the initiating SEPP receives a security parameter exchange request from the responding SEPP before receiving a response for its request (i.e. security parameter exchange procedure collision) , the initiating SEPP shall compare its FQDN that was sent in its request with the FQDN of the responding SEPP that is received in the security parameter exchange request message. If the initiating SEPP's FQDN lexicographically precedes, it shall reject the incoming HTTP request message with the cause "SECURITY_PARAM_EXCHANGE_COLLISION" and it shall continue with its initiated procedure and vice versa.EXAMPLE: Assuming SEPP A's FQDN is "sepp. 5gc. mnc345. mcc012.3gppnetwork. org" and SEPP B's FQDN is "sepp. 5gc. mnc346. mcc012.3gppnetwork. org" , then SEPP A's FQDN precedes SEPP B's FQDN and SEPP A proceeds with its security parameter exchange procedure.FIG. 2e schematically shows a flowchart of Message Forwarding between SEPP on N32-f, which is the same as Figure 5.3.2.4-1 of 3GPP TS 29.573 V18.5.0.When the HTTP messages to be forwarded, the SEPP / intermediaries will perform reformatting of the message according to the protection policy, i.e. for sensitive IEs, they are encrypted and inserted them into an array, and for each IE a place holder will be put in plain text with the reference to the array item of the encrypted IE.The steps of FIG. 2e are described in clause 5.3.2.4 of 3GPP TS 29.573 V18.5.0 as follow.Once a SEPP reformats the HTTP / 2 message into the "N32ReformattedReqMsg"  /  "N32ReformattedRspMsg" JSON object as specified in clause 5.3.2 of 3GPP TS 29.573 V18.5.0, the SEPP forwards the message to the receiving SEPP by invoking a HTTP POST method.1. The initiating SEPP issues a HTTP POST request towards the responding SEPP with the request body containing the "N32ReformattedReqMsg" IE carrying the reformatted HTTP / 2 message. The request message shall contain the "n32fContextId" information provided by the responding SEPP to the initiating SEPP earlier during the parameter exchange procedure (see clause 5.2.3) . The responding SEPP shall use the "n32fContextId" information to:-Locate the agreed cipher suite and protection policy;-Locate the n32ContextId to be used in the response.If the HTTP request / response message to be forwarded over N32-f includes an 3gpp-Sbi-Message-Priority header, the initiating / responding SEPP should additionally insert a 3gpp-Sbi-Message-Priority header in the N32-f message with the same contents as the 3gpp-Sbi-Message-Priority header encoded within the "N32ReformattedReqMsg"  / N32ReformattedRspMsg IE respectively.NOTE 1: Replicating the information in a N32-f message header enables the receiving SEPP to determine the priority of the forwarded HTTP request / response without having to parse the N32-f message content.The HTTP request content may be compressed hop by hop over N32-f, if the initiating SEPP or IPX and its next hop (IPX or SEPP) support gzip coding (see Internet Engineering Task Force (IETF) Request For Comments (RFC) 1952

[0023] ) .2a. On successful processing of the request, the responding SEPP shall:-decompress the N32-f HTTP request content, if it is compressed;-reconstruct the HTTP / 2 message towards the NF service producer;-compress the reconstructed HTTP request if the reconstructed HTTP content contains a Content-Encoding header indicating gzip compression;-forward the reconstructed HTTP / 2 message to the NF service producer;-wait for the response from the NF service producer; and then-once the response from the NF service producer is received, respond to the initiating SEPP with a "200 OK" status code and a POST response body that contains the "N32ReformattedRspMsg" . The "N32ReformattedRspMsg" shall contain the reformatted HTTP response message from the responding PLMN. The response message shall contain the "n32fContextId" information provided by the initiating SEPP to the responding SEPP earlier during the parameter exchange procedure (see clause 5.2.3 of 3GPP TS 29.573 V18.5.0) .NOTE 2: For unsuccessful processing of the request with "PLMNID_MISMATCH" , see clause 5.3.2.1 of 3GPP TS 29.573 V18.5.0.The responding SEPP shall be able to map the response received from the NF service producer to the HTTP / 2 stream ID for the corresponding response it needs to generate towards the initiating SEPP. The HTTP / 2 stream ID and the HTTP / 2 connection information on either side shall be used to derive this mapping.The HTTP response content may be compressed hop by hop over N32-f, if the responding SEPP or IPX and its next hop (IPX or SEPP) support gzip coding (see IETF RFC 1952

[0023] ) .2b. On failure or unsuccessful processing of the request, the responding SEPP shall respond to the initiating SEPP with an appropriate 4xx / 5xx status code, the message body shall contain a ProblemDetails structure with the "cause" attribute set to one of the application error as specified in clause 6.2.4.2. The "cause" attribute shall be set to "UNSPECIFIED" , if the responding SEPP fails to process the reconstructed message, and the error is reported by N32f error reporting procedure as specified in clause 5.2.5 of 3GPP TS 29.573 V18.5.0.Table 6.1.5.2.6-1 of 3GPP TS 29.573 V18.5.0 describes the definition of type ProtectionPolicy.Table 6.1.5.2.6-1: Definition of type ProtectionPolicyTable 6.1.5.2.7-1 of 3GPP TS 29.573 V18.5.0 describes the definition of type ApiIeMapping.Table 6.1.5.2.7-1: Definition of type ApiIeMappingTable 6.1.5.2.8-1 of 3GPP TS 29.573 V18.5.0 describes the definition of type IeInfo.Table 6.1.5.2.8-1: Definition of type IeInfoTable 6.1.5.2.6-1 of 3GPP TS 29.573 V18.5.0 describes the Enumeration IeLocation.Table 6.1.5.3.6-1: Enumeration IeLocationTable 6.2.5.2.5-1 of 3GPP TS 29.573 V18.5.0 describes the definition of type DataToIntegrityProtectBlock.Table 6.2.5.2.5-1: Definition of type DataToIntegrityProtectBlockTable 6.2.5.2.6-1 of 3GPP TS 29.573 V18.5.0 describes the definition of type RequestLine.Table 6.2.5.2.6-1: Definition of type RequestLineTable 6.2.5.2.7-1 of 3GPP TS 29.573 V18.5.0 describes the definition of type HttpHeader.Table 6.2.5.2.7-1: Definition of type HttpHeaderTable 6.2.5.2.8-1 of 3GPP TS 29.573 V18.5.0 describes the definition of type HttpPayload.Table 6.2.5.2.8-1: Definition of type HttpPayloadThere are some limitations in current definition of 3GPP TS 29.573 V18.5.0.Issue 1. It is not possible to define a protection policy for such sensitive information in the resource path. For example, certain sensitive information may be included in resource path, e.g. in UDM API:{apiRoot}  / nudm-uecm / v1 /  {ueId}  / registrations / smf-registrations /  {pduSessionId}In this example, one of the parameters is the ueId, which also happens to be potentially sensitive according to Table 6.1.5.3.5-1 in 3GPP TS 29.573 V18.5.0. However, it is not possible to define a protection policy for such sensitive information in the resource path.Issue 2. It is not specified how to format the sensitive information contained in the resource path and / or query parameters in the formatted messages via N32.Currently 3GPP TS 29.573 V18.5.0 specified the formatted message which can contain the reference to the encrypted blocks for HTTP headers or HTTP payload / contents. An encrypted HTTP header contains the header name and the value part contains the index to the encrypted block. An encrypted JSON IE / Body contains the IE path as the JSON pointer of the encrypted IE and the value part contain the index to the encrypted block. However it is not specified how to format the sensitive information contained in the resource path and / or query parameters in the formatted messages via N32.For issue 1, it is proposed to define the new specification on the protection policy for sensitive IEs in the resource path.In an embodiment, it defines the new protection policies for sensitive information in the resource path by adding "URI PATH" as valid IE location and defining the patterns to detect the sensitive information (with regular expression, prefix tagging or URI Variant Name) .In an embodiment, it may extend the IeLocation with new value for IEs in resource PATH, e.g. "URI_PATH" .In an embodiment, it may define the key factors for the detection of the sensitive IEs in the resource path.In an embodiment, it may use regular expression of the sensitive IEs, e.g. SBI encoding ( "imsi- [0-9] {5, 15} " ) of IMSI format to detect UE ID using IMSI value.In an embodiment, it may use specific prefix of the sensitive IEs, e.g. SBI encoding prefix ( "imsi-" ) of IMSI format to detect UE ID using IMSI value.In an embodiment, it may use resource path (e.g. ApiSignature) and URI Variant Name. E.g. with resource path:" {apiRoot}  / nudm-uecm / v1 /  {ueId}  / registrations / smf-registrations /  {pduSessionId} " , the " {ueId} " variant name can be used to indicate the UE ID.For issue 2, it is proposed to encrypt the sensitive info in resource path and query parameters (like HTTP headers) and embed the reference to encrypted blocks in the requestLine and queryFragment directly to encode the sensitive data encrypted in reformatted message.In an embodiment, it specifies how the sensitive information in resource URI and / or query parameters can be reformatted and forwarded between SEPPs via N32, by encrypting the sensitive information into encrypted block and allow reference to encrypted blocks embedded in the plain text resource path and query fragment (or with a new query parameter list) .In an embodiment, it is also possible to carry the query parameters separately as an array, with each array item containing the name and the value of one query parameter, the value part can then contain the reference to the encrypted block if sensitive info exists and encrypted.FIG. 3 shows a flowchart of a method according to an embodiment of the present disclosure, which may be performed by an apparatus implemented in or at or as a first network node in a first network or communicatively coupled to the first network node. As such, the apparatus may provide means or modules or circuits for accomplishing various parts of the method 300 as well as means or modules or circuits for accomplishing other processes in conjunction with other components.At block 302, the first network node may send, to a second network node in a second network, a first message comprising a list of ciphered information and at least one of a path part of a first universal resource identifier (URI) or a parameter part of the first URI.The first network may be any suitable network or network slice. The second network may be any suitable network or network slice. The first network and the second network may be the same network or different networks.In an embodiment, the first network may be a VPLMN and the second network may be HPLMN or vice versa.In an embodiment, the first network may be a PLMN and the second network may be SNPN or vice versa.The first network node may be deployed in any suitable network. In an embodiment, the first network node may be deployed in a fourth generation system (4GS) or a fifth generation system (5GS) or a sixth generation system (6GS) as defined by 3GPP.The second network node may be deployed in any suitable network. In an embodiment, the second network node may be deployed in a 4GS or a 5GS or a 6GS as defined by 3GPP.The first network node may be any suitable network device or network node or network function or network entity. For example, the first network node may provide message protection of the information exchanged between the first network node and the second network node.In an embodiment, the first network node may be a security edge protection proxy in the first network. For example, the security edge protection proxy may be same as or similar to SEPP as described in various 3GPP specifications such as 3GPP TS 23.501 V18.4.0 or 3GPP 6G specification.The second network node may be any suitable network device or network node or network function or network entity. For example, the second network node may provide message protection of the information exchanged between the first network node and the second network node.In an embodiment, the second network node may be a security edge protection proxy in the second network. For example, the security edge protection proxy may be same as or similar to SEPP as described in various 3GPP specifications such as 3GPP TS 23.501 V18.4.0 or 3GPP 6G specification.The first message may be any suitable message such as new message or existing message e.g. HTTP / 2 request message, HTTP / 2 response message, HTTP / 2 notification request message, HTTP / 2 notification response message, etc. In an embodiment, the first message may be the message of step 1 or 2a of FIG. 2e.The list of ciphered information may comprise at least one ciphered information which may be generated by encrypting any suitable information in a message to be sent to the second network node. For example, the list of ciphered information may be generated by encrypting an IE in JSON body, a URI query parameter, an HTTP header value, a parameter in a path part of a URI. Each ciphered information may be identified by an index or a reference. The ciphered information may be generated in various ways and the present disclosure has no limit on it. For example, clause 5.3.2.3 of 3GPP TS 29.573 V18.5.0 describes the transformation of HTTP Header and Payload to Encrypt into CipherText. Clause 5.3.2.3 of 3GPP TS 29.573 V18.5.0 may be revised for the transformation of the information located in the path part of the URI to Encrypt into CipherText e.g. by replacing the HTTP header value or the value of a JSON payload IE with the information located in the path part of the URI.The URI may be any suitable URI and the present disclosure has no limit on it. A path part of URI may comprise a sequence of path segments separated by a slash ( / ) . A parameter part of URI may be preceded by a question mark (?) and comprise at least one query parameter. A query parameter may comprise an attribute-value pair. When two or more query parameters are comprised in the parameter part of URI, two or more attribute–value pairs may be separated by a delimiter. In an embodiment, the URI may be the API URI as defined in 3GPP TS 29.573 V18.5.0.For example, the URI may be as follow:  / nNf-service1 / v1 /  (ueId)  / service-operation-1? ue-loc= {ueLocation} . The URI path part may be  / nNf-service1 / v1 /  (ueId)  / service-operation-1. The URI parameter part may be ue-loc= {ueLocation} . The attribute (or name) is “ue-loc” and the value is “ueLocation” .In an embodiment, the path part of the first URI may comprise a first reference to encrypted first information in the list of ciphered information.The first reference may be located in any suitable location in the path part. For example, before encryption, the path part of the first URI comprises the first information to be encrypted. After the first information is encrypted and moved to the list of ciphered information, the first reference may occupy the location of the first information in the path part of the first URI.The first information may be any information (e.g. path segment) in the URI path part.In an embodiment, the first information may comprise sensitive information.The sensitive information may comprise any suitable sensitive information and the present disclosure has no limit on it. In an embodiment, the sensitive information may comprise at least one of a user equipment identifier, key material, authentication material, authorization token, a user equipment location. For example, the user equipment identifier may comprise the "UEID" in Table 6.1.5.3.5-1. The key material may comprise the "KEY_MATERIAL" in Table 6.1.5.3.5-1. The authentication material may comprise the "AUTHENTICATION_MATERIAL" in Table 6.1.5.3.5-1. The authorization token may comprise the "AUTHORIZATION_TOKEN" in Table 6.1.5.3.5-1. The user equipment location may comprise the "LOCATION" in Table 6.1.5.3.5-1.In an embodiment, the path part of the first URI may comprise two or more first references to respective two or more encrypted first information in the list of ciphered information.In an embodiment, the parameter part of the first URI may comprise a second reference to encrypted second information in the list of ciphered information.The second reference may be located in any suitable location in the parameter part of the first URI. For example, before encryption, the parameter part of the first URI comprises the second information to be encrypted. After the second information is encrypted and moved to the list of ciphered information, the second reference may occupy the location of the second information in the parameter part of the first URI.The second information may be any information (e.g. parameter) in the URI parameter part. In an embodiment, the second information may comprise sensitive information.The sensitive information may comprise any suitable sensitive information and the present disclosure has no limit on it. In an embodiment, the sensitive information may comprise at least one of a user equipment identifier, key material, authentication material, authorization token, a user equipment location as described above.In an embodiment, the parameter part of the first URI may comprise two or more second references to respective two or more encrypted second information in the list of ciphered information.The path part of the first URI may be carried in any suitable data structure in the first message and the present disclosure has no limit on it. The parameter part of the first URI may be carried in any suitable data structure in the first message and the present disclosure has no limit on it.In an embodiment, a query parameter may comprise a name of the query parameter and the second information (e.g. an attribute-value pair) , and the name of the query parameter (e.g. the attribute) and the second reference to the encrypted second information are carried in an array item in the first message.In an embodiment, the second information may comprise a query parameter which may comprise a name of the query parameter and the second information (e.g. an attribute-value pair) , and the second reference to the encrypted second information may be carried in an array item in the first message.In an embodiment, the list of ciphered information may comprise a list of array items of encrypted information, and wherein the encrypted information comprises the encrypted first information and the encrypted second information.FIG. 4a shows a flowchart of a method according to another embodiment of the present disclosure, which may be performed by an apparatus implemented in or at or as a first network node or communicatively coupled to the first network node. As such, the apparatus may provide means or modules or circuits for accomplishing various parts of the method 400 as well as means or modules or circuits for accomplishing other processes in conjunction with other components. For some parts which have been described in the above embodiments, the description thereof is omitted here for brevity.At block 402, the first network node may receive a second message comprising a second URI from a third network node in the first network.The third network node may be deployed in any suitable network. In an embodiment, the third network node may be deployed in a 4GS or a 5GS or a 6GS as defined by 3GPP.The third network node may be any suitable network device or network node or network function or network entity. For example, the third network node may comprise an NF service consumer or an NF service producer such as network functions as described in 3GPP TS 23.501 V18.4.0 or 3GPP 6G specification.The second message may be any suitable message such as new message or existing message e.g. HTTP / 2 request message, HTTP / 2 response message, HTTP / 2 notification request message, HTTP / 2 notification response message, etc. For example, the second message may be any suitable message which can be sent to a network node in the second network via SEPP.The second URI may be any suitable URI and the present disclosure has no limit on it. In an embodiment, the second URI may be the API URI as defined in 3GPP TS 29.573 V18.5.0.For example, the second URI may be as follow:  / nNf-service1 / v1 /  (ueId)  / service-operation-1? ue-loc= {ueLocation} . The URI path part may be  / nNf-service1 / v1 /  (ueId)  / service-operation-1. The URI parameter part may be ue-loc= {ueLocation} . The attribute is “ue-loc” and the value is “ueLocation” .At block 404, the first network node may reformat the second message to the first message by at least one of encrypting the first information located in the path part of the second URI and / or the second information located in the parameter part of the second URI; adding the encrypted first information and / or the encrypted second information into the list of ciphered information; and generating the path part of the first URI and / or the parameter part of the first URI by reformatting (e.g. replacing) the first information located in the path part of the second URI with the first reference and / or reformatting (e.g. replacing) the second information located in the parameter part of the second URI with the second reference.In an embodiment, the message reformatting may be similar to the Message Reformatting as described in clause 5.3.2.3 of 3GPP TS 29.573 V18.5.0.For example, the first network node such as SEPP on the sending side PLMN may apply message reformatting in at least one of the following cases:-When it receives a HTTP / 2 request message from an NF service consumer to a an NF service producer in another PLMN;-When it receives a response HTTP / 2 response message from an NF service producer to an NF service consumer in another PLMN.-When it receives a HTTP / 2 notification request message from an NF service producer to an NF service consumer in another PLMN;-When it receives a HTTP / 2 notification response message from an NF service consumer to an NF service producer in another PLMN.The first network node such as SEPP may reformat the HTTP / 2 message by encapsulating the whole message into the body of a new HTTP POST message. The body of the HTTP POST request / response message may contain the reformatted original HTTP / 2 request / response message respectively. The HTTP POST request / response body may be encoded as the "N32fReformattedReqMsg"  /  "N32fReformattedRspMsg" JSON bodies respectively, as specified in clause 6.2.5 of 3GPP TS 29.573 V18.5.0.FIG. 4b shows an example of JSON representation of a reformatted HTTP message, which is same as Figure 5.3.2.3-1 of 3GPP TS 29.573 V18.5.0. The "N32fReformattedReqMsg"  /  "N32fReformattedRspMsg" are structured as given in FIG. 4b.FIG. 4c shows an example of Transformation of HTTP Header and Content to Encrypt into CipherText, which is same as Figure 5.3.2.3-2 of 3GPP TS 29.573 V18.5.0.The "cipherText" part of the reformatted message in FlatJweJson may be prepared as given in FIG. 4c.Step 1. Based on the protection policy exchanged between the SEPPs, the sending SEPP prepares an input for the JWE ciphering and integrity protection as an array of arbitrary types in the "DataToIntegrityProtectAndCipher" block with each entry containing either a HTTP header value or the value of a JSON payload IE of the API message being reformatted. The index value "encBlockIdx" in the content part of DataToIntegrityProtectBlock shall point to the index of a header value or IE value in this input array.Step 2. The input block is fed into an encryption function along with the other required inputs for JWE as specified in IETF RFC 7516

[0014] .Step 3. The encryption function outputs the cipher text information. This cipher text is then subjected to BASE64URL transformation as specified in IETF RFC 4648

[0015] clause 5.Step 4. The output of the BASE64URL transform is them encoded as the ciphertext part of FlatJweJson IE specified in clause 6.2.5.2.11 of 3GPP TS 29.573 V18.5.0.Note that the operations as described in FIGs. 4b and 4c may be also applied for the information in the path part of the URI and / or the information in the parameter part of the URI to be encrypted.FIG. 4d shows a flowchart of a method according to another embodiment of the present disclosure, which may be performed by an apparatus implemented in or at or as a first network node or communicatively coupled to the first network node. As such, the apparatus may provide means or modules or circuits for accomplishing various parts of the method 410 as well as means or modules or circuits for accomplishing other processes in conjunction with other components. For some parts which have been described in the above embodiments, the description thereof is omitted here for brevity.At block 412, optionally, the first network node may send, to the second network node, a fifth message indicating that the first network node supports protection of the first information in URI.At block 414, optionally, the first network node may receive, from the second network node, a sixth message indicating that the second network node supports protection of the first information in URI.The fifth message may be any suitable message such as new message or existing message such as HTTP POST request message or HTTP POST response message. For example, the third message may be a message in a feature negotiation mechanism. In an embodiment, the third message may be the message of step 1 or 2a of FIG. 2c.The sixth message may be any suitable message such as new message or existing message such as HTTP POST request message or HTTP POST response message. For example, the fourth message may be a message in a feature negotiation mechanism. In an embodiment, the fourth message may be the message of step 1 or 2a of FIG. 2c.For example, the feature negotiation mechanism specified in clause 6.6 of 3GPP TS 29.500 V18.4.0 may be used to negotiate the optional features applicable between the c-SEPP and the p-SEPP, for the N32 Handshake service, if any. The c-SEPP may indicate the optional features it supports for the N32 Handshake service, if any, by including the supportedFeatures attribute in the HTTP POST request message for following service operations: Security Capability Negotiation procedure, as specified in clause 5.2.2 of 3GPP TS 29.573 V18.5.0 to negotiate the security capability. The p-SEPP may determine the supported features for the requested network as specified in clause 6.6 of 3GPP TS 29.500 V18.4.0 and may indicate the supported features by including the supportedFeatures attribute in payload of the HTTP response for the service operation.FIG. 4e shows a flowchart of a method according to another embodiment of the present disclosure, which may be performed by an apparatus implemented in or at or as a first network node or communicatively coupled to the first network node. As such, the apparatus may provide means or modules or circuits for accomplishing various parts of the method 420 as well as means or modules or circuits for accomplishing other processes in conjunction with other components. For some parts which have been described in the above embodiments, the description thereof is omitted here for brevity.At block 422, optionally, the first network node may send, to the second network node, a third message.At block 424, optionally, the first network node may receive, from the second network node, a fourth message.The third message may be any suitable message such as new message or existing message such as HTTP POST request message or HTTP POST response message. For example, the third message may be a message in a feature negotiation mechanism. In an embodiment, the third message may be the message of step 1 or 2a of FIG. 2d.The fourth message may be any suitable message such as new message or existing message such as HTTP POST request message or HTTP POST response message. For example, the fourth message may be a message in a feature negotiation mechanism. In an embodiment, the fourth message may be the message of step 1 or 2a of FIG. 2d.In an embodiment, the third message and / or the fourth message may comprise at least one of information indicating the first information is located in the URI path part and information indicating the first information.The information indicating the first information is located in the URI path part may be any suitable information such as string, bit, bitmap, flag, etc.The information indicating the first information may be any suitable information such as string, bit, bitmap, flag, etc.In an embodiment, the information indicating the first information may comprise at least one of a pattern of the first information, an index of a segment of the first information in the URI path part, or a name of the first information in the URI path part.In an embodiment, the pattern of the first information may comprise at least one of a regular expression of the first information or a specific prefix of the first information.For example, it may use regular expression of the first information (e.g. sensitive IEs) , e.g. SBI encoding ( "imsi- [0-9] {5, 15} " ) of IMSI format to indicate UE ID using IMSI value.For example, it may use specific prefix of the first information (e.g. sensitive IEs) , e.g. SBI encoding prefix ( "imsi-" ) of IMSI format to indicate UE ID using IMSI value.For example, it may use resource path (API Signature) and URI Variant Name, e.g. resource path " {apiRoot}  / nudm-uecm / v1 /  {ueId}  / registrations / smf-registrations /  {pduSessionId} " , the " {ueId} " and variant name can be used to indicate the UE ID.FIG. 5a shows a flowchart of a method according to another embodiment of the present disclosure, which may be performed by an apparatus implemented in or at or as a second network node in a second network or communicatively coupled to the second network node. As such, the apparatus may provide means or modules or circuits for accomplishing various parts of the method 500 as well as means or modules or circuits for accomplishing other processes in conjunction with other components. For some parts which have been described in the above embodiments, the description thereof is omitted here for brevity.At block 502, the second network node may receive, from a first network node in a first network, a first message comprising a list of ciphered information and at least one of a path part of a first universal resource identifier (URI) or a parameter part of the first URI.In an embodiment, the path part of the first URI may comprise a first reference to encrypted first information in the list of ciphered information and / or the parameter part of the first URI may comprise a second reference to encrypted second information in the list of ciphered information.For example, the first network node may send, to the second network node in the second network, the first message at block 302 of FIG. 3, and then the second network node may receive the first message from the second network node.The second network node may process the first message in various ways and the present disclosure has no limit on it. For example, the second network node may decrypt the list of ciphered information and generate a message comprising a URI which may be generated based on the decrypted list of ciphered information and the first URI.For example, when the first message is a request, the first network node is an initiating SEPP and the second network node is a responding SEPP, the responding SEPP may process the request as described with respect to step 2a or 2b of FIG. 2e.In an embodiment, the list of ciphered information may comprise a list of array items of encrypted information, and wherein the encrypted information comprises the encrypted first information and the encrypted second information.FIG. 5b shows a flowchart of a method according to another embodiment of the present disclosure, which may be performed by an apparatus implemented in or at or as a second network node or communicatively coupled to the second network node. As such, the apparatus may provide means or modules or circuits for accomplishing various parts of the method 510 as well as means or modules or circuits for accomplishing other processes in conjunction with other components. For some parts which have been described in the above embodiments, the description thereof is omitted here for brevity.At block 512, the second network node may generate a second message comprising a second URI based on the first message.For example, the second network node may decrypt the encrypted first information and / or the encrypted second information. The second network node may generate the path part of the second URI and / or the parameter part of the second URI by at least replacing the first reference with the first information and / or replacing the second reference with the second information. When the list of ciphered information comprises other ciphered information such as encrypted header or encrypted payload, etc., the second network node may perform similar operation.At block 514, the second network node may send the second message comprising the second URI to a fourth network node in the second network.The fourth network node may be deployed in any suitable network. In an embodiment, the fourth network node may be deployed in a 4GS or a 5GS or a 6GS as defined by 3GPP.The fourth network node may be any suitable network device or network node or network function or network entity. For example, the fourth network node may comprise an NF service consumer or an NF service producer such as network functions as described in 3GPP TS 23.501 V18.4.0 or 3GPP 6G specification.In an embodiment, the first information and the second information may comprise sensitive information.In an embodiment, the sensitive information may comprise at least one of a user equipment identifier, key material, authentication material, authorization token, a user equipment location.In an embodiment, a query parameter comprises a name of the query parameter and the second information, and the name of the query parameter and the second reference to the encrypted second information are carried in an array item in the first message.FIG. 5c shows a flowchart of a method according to another embodiment of the present disclosure, which may be performed by an apparatus implemented in or at or as a second network node or communicatively coupled to the second network node. As such, the apparatus may provide means or modules or circuits for accomplishing various parts of the method 520 as well as means or modules or circuits for accomplishing other processes in conjunction with other components. For some parts which have been described in the above embodiments, the description thereof is omitted here for brevity.At block 522, optionally, the second network node may receive, from the first network node, a fifth message indicating that the first network node supports protection of the first information in URI.At block 524, optionally, the second network node may send, to the first network node, a sixth message indicating that the second network node supports a protection of the first information in a URI path part.FIG. 5d shows a flowchart of a method according to another embodiment of the present disclosure, which may be performed by an apparatus implemented in or at or as a second network node or communicatively coupled to the second network node. As such, the apparatus may provide means or modules or circuits for accomplishing various parts of the method 530 as well as means or modules or circuits for accomplishing other processes in conjunction with other components. For some parts which have been described in the above embodiments, the description thereof is omitted here for brevity.At block 532, optionally, the second network node may receive, from the first network node, a third message.At block 534, optionally, the second network node may send, to the first network node, a fourth message.In an embodiment, the third message and / or the fourth message may comprise at least one of an information element location indicating the URI path part and information indicating the first information.In an embodiment, the information indicating the first information may comprise at least one of a pattern of the first information, an index of a segment of the first information in the URI path part, or a name of the first information in the URI path part.In an embodiment, the pattern of the first information may comprise at least one of a regular expression of the first information, or a specific prefix of the first information.FIG. 6 shows a flowchart of protection policy exchange and message forwarding with protection policy according to another embodiment of the present disclosure.In an embodiment, the protection policy for the sensitive information in URI path and / or query parameters can be exchanged between SEPPs. The sensitive information can be encrypted and carried in encrypted block in the reformatted message and with reference to the encrypted block embedded accordingly in the plain text in reformatted message. The sending SEPP can perform the encryption and the receiving SEPP can do the deciphering.Step 1. Security Negotiation (as Figure 5.2.2-1 of 3GPP TS 29.573 V18.5.0) .Step 2. Parameter Exchange (as Figure 5.2.3.2-1 of 3GPP TS 29.573 V18.5.0) .For example the Protection Policies may be as follow:{ieLoc: “URI_PATH” , reqIe: “ {ueId} ” } or{ieLoc: “URI_PATH” , reqIe: “ (imsi- [0-9] {5, 15} ” } ,{ieLoc: “URI_PARAM” , reqIe: “ue-loc” }Step 3. NF A in PLMN1 decides to send an SBI service request to NF B in PLMN2.Step 4. NF A in PLMN1 sends HTTP POST {NF B APIRoot}  / nNf-service1 / v1 /  (ueId)  / service-operation-1? ue-loc= {ueLocation} to SEPP in PLMN1.Step 5. SEPP in PLMN1 reformats the received message according to protection policy (e.g. encrypt the sensitive IE and embed Encrypted Data index in plain text of Request Line) .Step 6. SEPP in PLMN1 sends the reformatted message to SEPP in PLMN2 (as Figure 5.3.2.4-1 of 3GPP TS 29.573 V18.5.0) .For example, the reformatted message may be as follow:{ "requestLine" :{ "path" : " / nNf-service1 / v1 /  { "encBlockIndex" : 1}  / service-operation-1" ,"queryFragment" : "ue-loc= { "encBlockIndex" : 2} “} ,{ "dataToEncrypt" : [ <value of {ueId} > , <value of {ueLocation} > ] }Step 7. SEPP in PLMN2 decodes the reformatted message and restores the original HTTP message (e.g. decipher the sensitive IE and restore the Request Line according to the Encrypted Data index) .Step 8. SEPP in PLMN2 sends the HTTP POST {NF B APIRoot}  / nNf-service1 / v1 /  (ueId)  / service-operation-1? ue-loc= {ueLocation} to NF B in PLMN2.An example may be as follow:POST  / nNf-service1 / v1 /  (ueId)  / service-operation-1? ue-loc= {ueLocation}In the above HTTP request of FIG. 6,-One URI variant of the input HTTP / 2 message need to be integrity protected and ciphered, i.e. the UE ID.-One URI parameters of the input HTTP / 2 message need to be integrity protected and ciphered, i.e. UE location.-The headers and content in the input HTTP / 2 message need to be only integrity protected.The N32fReformattedReqMessage for this example may be as follow.The DataToIntegrityProtectBlock for this example may be as follow.The DataToIntegrityProtectAndCipherBlock for this example may be as follow.Embodiments herein may provide many advantages, of which a non-exhaustive list of examples follows. In some embodiments herein, the proposed solution provides a flexible mechanism to allow the network node (such as SEPP / intermediaries via N32) to configure and exchange protection policies for sensitive information in the resource path. In some embodiments herein, the proposed solution can enable the network node to reformat and forward a (e.g. HTTP) message containing sensitive information in the resource path and / or query parameters. The embodiments herein are not limited to the features and advantages mentioned above. A person skilled in the art will recognize additional features and advantages upon reading the following detailed description.FIG. 7 is a block diagram showing an apparatus suitable for practicing some embodiments of the disclosure. For example, the first network node or the second network node described above may be implemented as or through the apparatus 700.The apparatus 700 comprises at least one processor 721, such as a digital processor (DP) , and at least one memory (MEM) 722 coupled to the processor 721. The apparatus 700 may comprise a transmitter TX and receiver RX 723 coupled to the processor 721. The MEM 722 stores a program (PROG) 724. The PROG 724 may include instructions that, when executed on the associated processor 721, enable the apparatus 700 to operate in accordance with the embodiments of the present disclosure. A combination of the at least one processor 721 and the at least one MEM 722 may form processing means 725 adapted to implement various embodiments of the present disclosure.Various embodiments of the present disclosure may be implemented by computer program executable by one or more of the processor 721, software, firmware, hardware or in a combination thereof.The MEM 722 may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memories and removable memories, as non-limiting examples.The processor 721 may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples.In an embodiment where the apparatus is implemented as or at the first network node, the memory 722 contains instructions executable by the processor 721, whereby the first network node operates according to any of the methods performed by the first network node as described above.In an embodiment where the apparatus is implemented as or at the second network node, the memory 722 contains instructions executable by the processor 721, whereby the second network node operates according to any of the methods performed by the second network node as described above.With function units, the first network node or the second network node may not need a fixed processor or memory, any computing resource and storage resource may be arranged from the first network node or the second network node in the communication system. The introduction of virtualization technology and network computing technology may improve the usage efficiency of the network resources and the flexibility of the network.The term unit or module may have conventional meaning in the field of electronics, electrical devices and / or electronic devices and may include, for example, electrical and / or electronic circuitry, devices, modules, processors, memories, logic solid state and / or discrete devices, computer programs or instructions for carrying out respective tasks, procedures, computations, outputs, and / or displaying functions, and so on, as such as those that are described herein.According to an aspect of the disclosure it is provided a computer program product being tangibly stored on a computer readable storage medium and including instructions which, when executed on at least one processor, cause the at least one processor to carry out any of the methods as described above.According to an aspect of the disclosure it is provided a computer-readable storage medium storing instructions which when executed by at least one processor, cause the at least one processor to carry out any of the methods as described above.In addition, the present disclosure may also provide a carrier containing the computer program as mentioned above, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium. The computer readable storage medium can be, for example, an optical compact disk or an electronic memory device like a RAM (random access memory) , a ROM (read only memory) , Flash memory, magnetic tape, CD-ROM, DVD, Blue-ray disc and the like.The techniques described herein may be implemented by various means so that an apparatus implementing one or more functions of a corresponding apparatus described with an embodiment comprises not only prior art means, but also means for implementing the one or more functions of the corresponding apparatus described with the embodiment and it may comprise separate means for each separate function, or means that may be configured to perform two or more functions. For example, these techniques may be implemented in hardware (one or more apparatuses) , firmware (one or more apparatuses) , software (one or more modules) , or combinations thereof. For a firmware or software, implementation may be made through modules (e.g., procedures, functions, and so on) that perform the functions described herein.Exemplary embodiments herein have been described above with reference to block diagrams and flowchart illustrations of methods and apparatuses. It will be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, respectively, can be implemented by various means including computer program instructions. These computer program instructions may be loaded onto a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions which execute on the computer or other programmable data processing apparatus create means for implementing the functions specified in the flowchart block or blocks.Further, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the subject matter described herein, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable sub-combination.While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any implementation or of what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of particular implementations. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub-combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or variation of a sub-combination.It will be obvious to a person skilled in the art that, as the technology advances, the inventive concept can be implemented in various ways. The above described embodiments are given for describing rather than limiting the disclosure, and it is to be understood that modifications and variations may be resorted to without departing from the spirit and scope of the disclosure as those skilled in the art readily understand. Such modifications and variations are considered to be within the scope of the disclosure and the appended claims. The protection scope of the disclosure is defined by the accompanying claims.In an embodiment, 3GPP TS 29.573 V18.5.0 may be amended as follow.6.1.5.2.8 Type: IeInfoTable 6.1.5.2.8-1: Definition of type IeInfo6.1.5.3.6 Enumeration: IeLocationTable 6.1.5.3.6-1: Enumeration IeLocation6.1.7 Feature NegotiationThe feature negotiation mechanism specified in clause 6.6 of 3GPP TS 29.500 [4] shall be used to negotiate the optional features applicable between the c-SEPP and the p-SEPP, for the N32 Handshake service, if any.The c-SEPP shall indicate the optional features it supports for the N32 Handshake service, if any, by including the supportedFeatures attribute in the HTTP POST request message for following service operations:-Security Capability Negotiation procedure, as specified in clause 5.2.2 to negotiate the security capability;The p-SEPP shall determine the supported features for the requested network as specified in clause 6.6 of 3GPP TS 29.500 [4] and shall indicate the supported features by including the supportedFeatures attribute in content of the HTTP response for the service operation. The syntax of the supportedFeatures attribute is defined in clause 5.2.2 of 3GPP TS 29.571

[0012] . The following features are defined for the N32 Handshake service.Table 6.1.7-1: Features of supportedFeatures attribute used by N32 Handshake service6.2.5.2.6 Type: RequestLineTable 6.2.5.2.6-1: Definition of type RequestLineA. 2 N32 HANDSHAKE API*********************Text Skipped for Clarify ************************IeLocation:description: Location of the IE in a HTTP messageanyOf:-type: stringenum:-URI_PARAM-HEADER-BODY-MULTIPART_BINARY-URI_PATH-type: string*********************Text Skipped for Clarify ************************B. X INPUT MESSAGE CONTAINING SENSITIVE INFORMATION IN URI PATHAND / OR URI PARAMETER FRAGMENTConsider the following example:POST  / nNf-service1 / v1 /  (ueId)  / service-operation-1? ue-loc= {ueLocation}in the above HTTP request,-One URI variant of the input HTTP / 2 message need to be integrity protected and ciphered, i.e. the UE ID.-One URI parameters of the input HTTP / 2 message need to be integrity protected and ciphered, i.e. UE location.-The headers and content in the input HTTP / 2 message need to be only integrity protected.The N32fReformattedReqMessage for this example looks likeThe DataToIntegrityProtectBlock for this example looks likeThe DataToIntegrityProtectAndCipherBlock for this example looks likeIn an embodiment, 3GPP TS 29.573 V18.5.0 may be amended as follow.6.1.5.2.8 Type: IeInfoTable 6.1.5.2.8-1: Definition of type IeInfo6.1.5.3.6 Enumeration: IeLocationTable 6.1.5.3.6-1: Enumeration IeLocation6.1.7 Feature NegotiationThe feature negotiation mechanism specified in clause 6.6 of 3GPP TS 29.500 [4] shall be used to negotiate the optional features applicable between the c-SEPP and the p-SEPP, for the N32 Handshake service, if any.The c-SEPP shall indicate the optional features it supports for the N32 Handshake service, if any, by including the supportedFeatures attribute in the HTTP POST request message for following service operations:-Security Capability Negotiation procedure, as specified in clause 5.2.2 to negotiate the security capability;The p-SEPP shall determine the supported features for the requested network as specified in clause 6.6 of 3GPP TS 29.500 [4] and shall indicate the supported features by including the supportedFeatures attribute in content of the HTTP response for the service operation. The syntax of the supportedFeatures attribute is defined in clause 5.2.2 of 3GPP TS 29.571

[0012] . The following features are defined for the N32 Handshake service.Table 6.1.7-1: Features of supportedFeatures attribute used by N32 Handshake service6.2.5.2.6 Type: RequestLineTable 6.2.5.2.6-1: Definition of type RequestLineA. 2 N32 HANDSHAKE API*********************Text Skipped for Clarify ************************IeLocation:description: Location of the IE in a HTTP messageanyOf:-type: stringenum:-URI_PARAM-HEADER-BODY-MULTIPART_BINARY-URI_PATH-type: string*********************Text Skipped for Clarify ************************B. X INPUT MESSAGE CONTAINING SENSITIVE INFORMATION IN URI PATHAND / OR URI PARAMETER FRAGMENTConsider the following example:POST  / nNf-service1 / v1 /  (ueId)  / service-operation-1? ue-loc= {ueLocation}in the above HTTP request,-One URI variant of the input HTTP / 2 message need to be integrity protected and ciphered, i.e. the UE ID.-One URI parameters of the input HTTP / 2 message need to be integrity protected and ciphered, i.e. UE location.-The headers and content in the input HTTP / 2 message need to be only integrity protected.The N32fReformattedReqMessage for this example looks likeThe DataToIntegrityProtectBlock for this example looks likeThe DataToIntegrityProtectAndCipherBlock for this example looks like

Claims

1.A method (300) performed by a first network node in a first network, comprising:sending (302) , to a second network node in a second network, a first message comprising a list of ciphered information and at least one of a path part of a first universal resource identifier (URI) or a parameter part of the first URI,wherein the path part of the first URI comprises a first reference to encrypted first information in the list of ciphered information and / or the parameter part of the first URI comprises a second reference to encrypted second information in the list of ciphered information.2.The method according to claim 1, wherein the list of ciphered information comprises a list of array items of encrypted information, and wherein the encrypted information comprises the encrypted first information and the encrypted second information.3.The method according to claim 1 or 2, further comprising:receiving (402) a second message comprising a second URI from a third network node in the first network; andreformatting (404) the second message to the first message by at least one of:encrypting the first information located in the path part of the second URI and / or the second information located in the parameter part of the second URI;adding the encrypted first information and / or the encrypted second information into the list of ciphered information; andgenerating the path part of the first URI and / or the parameter part of the first URI by reformatting the first information located in the path part of the second URI with the first reference and / or reformatting the second information located in the parameter part of the second URI with the second reference.4.The method according to any of claims 1-3, the first information and the second information comprises sensitive information.5.The method according to claim 4, the sensitive information comprises at least one of:a user equipment identifier,key material,authentication material,authorization token, ora user equipment location.6.The method according to claims 1-5, wherein a query parameter comprises a name of the query parameter and the second information, and the name of the query parameter and the second reference to the encrypted second information are carried in an array item in the first message.7.The method according to any of claims 1-6, further comprising:sending (412) , to the second network node, a fifth message indicating that the first network node supports protection of sensitive information in URI; and / orreceiving (414) , from the second network node, a sixth message indicating that the second network node supports protection of the sensitive information in URI.8.The method according to claim 7, further comprising:sending (422) , to the second network node, a third message; and / orreceiving (424) , from the second network node, a fourth message.wherein the third message and / or the fourth message comprise at least one of:information indicating the first information is located in the URI path part and information indicating the first information.9.The method according to claim 8, wherein the information indicating the first information comprises at least one of:a pattern of the first information,an index of a segment of the first information in the URI path part, ora name of the first information in the URI path part.10.The method according to claim 9, wherein the pattern of the first information comprises at least one of:a regular expression of the first information, ora specific prefix of the first information.11.The method according to any of claims 1-10, wherein the first network node comprises a security edge protection proxy in the first network and the second network node comprises a security edge protection proxy in the second network.12.A method (500) performed by a second network node in a second network, comprising:receiving (502) , from a first network node in a first network, a first message comprising a list of ciphered information and at least one of a path part of a first universal resource identifier (URI) or a parameter part of the first URI,wherein the path part of the first URI comprises a first reference to encrypted first information in the list of ciphered information and / or the parameter part of the first URI comprises a second reference to encrypted second information in the list of ciphered information.13.The method according to claim 12, wherein the list of ciphered information comprises a list of array items of encrypted information, and wherein the encrypted information comprises the encrypted first information and the encrypted second information.14.The method according to claim 12 or 13, further comprising:generating (512) a second message comprising a second URI based on the first message by at least one of:decrypting the encrypted first information and / or the encrypted second information; andgenerating the path part of the second URI and / or the parameter part of the second URI by at least replacing the first reference with the first information and / or replacing the second reference with the second information; andsending (514) the second message comprising the second URI to a fourth network node in the second network.15.The method according to any of claims 12-14, the first information and the second information comprises sensitive information.16.The method according to claim 15, the sensitive information comprises at least one of:a user equipment identifier,key material,authentication material,authorization token, ora user equipment location.17.The method according to claims 12-16, wherein a query parameter comprises a name of the query parameter and the second information, and the name of the query parameter and the second reference to the encrypted second information are carried in an array item in the first message.18.The method according to any of claims 12-17, further comprising:receiving (522) , from the first network node, a fifth message indicating that the first network node supports protection of the first information in URI; and / orsending (524) , to the first network node, a sixth message indicating that the second network node supports protection of the first information in URI.19.The method according to any of claims 12-18, further comprising:receiving (532) , from the first network node, a third message; and / orsending (534) , to the first network node, a fourth message.wherein the third message and / or the fourth message comprise at least one of:information indicating the first information is located in the URI path part and information indicating the first information.20.The method according to claim 19, wherein the information indicating the first information comprises at least one of:a pattern of the first information,an index of a segment of the first information in the URI path part, ora name of the first information in the URI path part.21.The method according to claim 20, wherein the pattern of the first information comprises at least one of:a regular expression of the first information, ora specific prefix of the first information.22.The method according to any of claims 12-21, wherein the first network node comprises a security edge protection proxy in the first network and the second network node comprises a security edge protection proxy in the second network.23.A first network node (700) in a first network, comprising:a processor (721) ; anda memory (722) coupled to the processor (721) , said memory (722) containing instructions executable by said processor (721) , whereby said first network node (700) is operative to:send, to a second network node in a second network, a first message comprising a list of ciphered information and at least one of a path part of a first universal resource identifier (URI) or a parameter part of the first URI,wherein the path part of the first URI comprises a first reference to encrypted first information in the list of ciphered information and / or the parameter part of the first URI comprises a second reference to encrypted second information in the list of ciphered information.24.The first network node according to claim 23, wherein the first network node is further operative to perform the method of any one of claims 2 to 11.25.A second network node (700) in a second network, comprising:a processor (721) ; anda memory (722) coupled to the processor (721) , said memory (722) containing instructions executable by said processor (721) , whereby said second network node (700) is operative to:receive, from a first network node in a first network, a first message comprising a list of ciphered information and at least one of a path part of a first universal resource identifier (URI) or a parameter part of the first URI,wherein the path part of the first URI comprises a first reference to encrypted first information in the list of ciphered information and / or the parameter part of the first URI comprises a second reference to encrypted second information in the list of ciphered information.26.The second network node according to claim 25, wherein the second network node is further operative to perform the method of any one of claims 13 to 22.27.A computer-readable storage medium storing instructions which when executed by at least one processor, cause the at least one processor to perform the method according to any one of claims 1 to 22.28.A computer program product comprising instructions which when executed by at least one processor, cause the at least one processor to perform the method according to any one of claims 1 to 22.

Images