WO2020012065A1

WO2020012065A1 - Security management for unauthorized requests in communication system with service-based architecture

Info

Publication number: WO2020012065A1
Application number: PCT/FI2019/050528
Authority: WO
Inventors: Nagendra S BYKAMPADI; Silke Holtmanns; Ian Justin Oliver
Original assignee: Nokia Technologies Oy
Priority date: 2018-07-12
Filing date: 2019-07-05
Publication date: 2020-01-16
Also published as: EP3821562A1; EP3821562A4

Abstract

In a communication system comprising a first network operatively coupled to a second network, wherein the first network comprises a first network element operatively coupled to a second network element of the second network, the first network element sends a first message to the second network element in accordance with a transport layer security procedure, wherein the first message comprises hardware-specific location information identifying the first network element. The first network element receives a second message from the second network element, wherein the second message comprises hardware-specific location information identifying the second network element. The first network element combines the hardware-specific location information of the first message with the hardware- specific location information of the second message to form an identifier.

Description

SECURITY MANAGEMENT FOR UNAUTHORIZED REQUESTS IN COMMUNICATION SYSTEM WITH SERVICE-BASED ARCHITECTURE

Field

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

Background

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

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

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

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

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

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

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

Summary

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

For example, in one illustrative embodiment, a method comprises the following steps. In a communication system comprising a first network operatively coupled to a second network, wherein the first network comprises a first network element operatively coupled to a second network element of the second network, the first network element sends a first message to the second network element in accordance with a transport layer security procedure, wherein the first message comprises hardware-specific location information identifying the first network element. The first network element receives a second message from the second network element, wherein the second message comprises hardware-specific location information identifying the second network element. The first network element combines the hardware-specific location information of the first message with the hardware- specific location information of the second message to form an identifier.

In a further embodiment, the first network element uses the identifier to generate a key value useable to securely send one or more subsequent messages to the second network element. Further illustrative embodiments are provided in the form of non-transitory computer-readable storage medium having embodied therein executable program code that when executed by a processor causes the processor to perform the above steps. Still further illustrative embodiments comprise apparatus with a processor and a memory configured to perform the above steps.

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

Brief Description of the Drawings

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

FIG. 2 illustrates network elements/functions for providing security management with which one or more illustrative embodiments may be implemented.

FIG. 3 illustrates a communication system architecture with security edge protection proxies between a visited network and a home network with which one or more illustrative embodiments may be implemented.

FIG. 4 illustrates a portion of a communication system with network functions communicating through security edge protection proxies between a first network and a second network with which one or more illustrative embodiments may be implemented.

FIG. 5 illustrates one example of a message flow for preventing unauthorized requests in a service-based architecture according to an illustrative embodiment.

FIG. 6 illustrates end-to-end security management in a service-based architecture according to an illustrative embodiment.

Detailed Description

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

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

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

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

Accordingly, as shown, communication system 100 comprises user equipment (UE) 102 that communicates via an air interface 103 with an access point (gNB) 104. The UE 102 may be a mobile station, and such a mobile station may comprise, by way of example, a mobile telephone, a computer, or any other type of communication device. The term“user equipment” as used herein is therefore intended to be construed broadly, so as to encompass a variety of different types of mobile stations, subscriber stations or, more generally, communication devices, including examples such as a combination of a data card inserted in a laptop or other equipment such as a smart phone. Such communication devices are also intended to encompass devices commonly referred to as access terminals.

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

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

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

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

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

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

It is to be appreciated that this particular arrangement of system elements is an example only, and other types and arrangements of additional or alternative elements can be used to implement a communication system in other embodiments. For example, in other embodiments, the system 100 may comprise other elements/functions not expressly shown herein.

Accordingly, the FIG. 1 arrangement is just one example configuration of a wireless cellular system, and numerous alternative configurations of system elements may be used. For example, although only single elements/functions are shown in the FIG. 1 embodiment, this is for simplicity and clarity of description only. A given alternative embodiment may of course include larger numbers of such system elements, as well as additional or alternative elements of a type commonly associated with conventional system implementations. It is also to be noted that while FIG. 1 illustrates system elements as singular functional blocks, the various subnetworks that make up the 5G network are partitioned into so-called network slices. Network slices (network partitions) comprise a series of network function (NF) sets (i.e., function chains) for each corresponding service type using network function virtualization (NFV) on a common physical infrastructure. The network slices are instantiated as needed for a given service, e.g., eMBB service, massive IoT service, and mission-critical IoT service. A network slice or function is thus instantiated when an instance of that network slice or function is created. In some embodiments, this involves installing or otherwise running the network slice or function on one or more host devices of the underlying physical infrastructure. UE 102 is configured to access one or more of these services via gNB 104.

FIG. 2 is a block diagram of network elements/functions for providing security management in an illustrative embodiment. System 200 is shown comprising a first network element/function 202 and a second network element/function 204. It is to be appreciated that the network elements/functions 202 and 204 represent any network elements/functions that are configured to provide security management and other techniques described herein, for example, but not limited to, AMF, SEAF, UDM, AUSF, NSSF, NEF, NRF, PCF and AF. Further, one or both of the first network element/function 202 and the second network element/function 204 may also represent a Security Edge Protection Proxy (SEPP), which will be described in further detail below.

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

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

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

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

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

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

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

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

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

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

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

FIG. 3 depicts a 5G architecture 300 in a configuration comprising a visited public land mobile network (VPLMN) 310 operatively coupled to a home public land mobile network (HPLMN) 320. More particularly, FIG. 3 illustrates the presence of a Security Edge Protection Proxy (SEPP) at the edge of each PLMN, i.e., vSEPP 312 in VPLMN 310 and hSEPP 322 in HPLMN 320. It is to be appreciated that the various network functions shown in the VPLMN 310 and the HPLMN 320 are known and described in detail in various 5G specifications such as, but not limited to, the above -referenced TS 23.501 and TS 33.501.

As mentioned above, in 5G, SBA is introduced to model services as network functions (NLs) that communicate with each other using Restful application programming interfaces (Representational State Transfer APIs). In the scenario where the two communicating NLs are in two different PLMNs (e.g., VPLMN 310 and HPLMN 320), such as when a UE is roaming (e.g., connecting to a visited or visiting network that communicates with the home network of the UE), communication happens over a roaming inter-network interface (N32) between the two participating PLMNs.

To protect NL specific content in the messages that are sent over the roaming inter network interface, 5G introduces the SEPP as the entity residing at the perimeter of the PLMN network to protect the PLMN from outside traffic and additionally implements transport layer security and application layer security for all the signalling and data exchanged between two inter-network network functions at the service layer. Lor example, the SEPP performs security management functions on information elements (IE) in HyperText Transport Protocol (HTTP) messages before the messages are sent externally over the roaming N32 interface.

Application layer security involves protecting information sent in various parts of the HTTP message including, but not limited to, HTTP Request/Response Line, HTTP header and HTTP Payload. However, some parts of this message may need to be modified by intermediaries (Inter-network Packet exchange (IPX) providers not expressly shown in PIG. 3) between the two SEPPs.

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

Proposals for security management in network function messaging utilizing SEPPs have been made. For example, mechanisms have been proposed for SEPPs to apply protection to HTTP requests and responses exchanged between two NFs in different PLMNs. FIG. 4 shows a system 400 in an example embodiment. The system 400 of FIG. 4 includes two PLMNs 410-1 and 410-2. The PLMN 410-1 is equipped with a first NF 420 that in a sending case is, for example, an AMF. The PLMN 410-1 further comprises a SEPP 430-1. In the FIG. 4 example, the SEPP 430-1 of PLMN 410-1 acts as a sending SEPP or sSEPP for a given message. The PLMN 410-2 includes another SEPP 430-2 that acts as a receiving SEPP or rSEPP for the given message. The SEPPs 430-1 and 430-2 (collectively, SEPPs 430) are network nodes at the boundary of an operator’s network that receive messages such as HTTP requests or HTTP response messages from respective NFs in the PLMNs 410-1 and 410-2 (collectively, PLMNs 410). More particularly in the FIG. 4 example, the sSEPP 430-1 receives a message (e.g., an HTTP request or HTTP response) from the network function AMF 420, applies protection for sending, and forwards a reformatted message through a chain of intermediate nodes such as IP exchanges (IPX) 440-1 and 440-2 (collectively, intermediate nodes 440) towards the rSEPP 430-2.

The rSEPP 430-2 receives a potentially modified protocol message from one of the intermediate nodes 440, re-assembles the message (e.g., an HTTP request or HTTP response), and forwards the re-assembled message towards a second NF within its operator’s network, such as the AUSF 450 in the FIG. 4 example. The re-assembled message can alternatively be sent towards any other NF in the PLMN 410-2.

The intermediate nodes 440 or intermediaries, in short, are network nodes outside the operator’s network that receive (directly or indirectly via other intermediaries) a reformatted message from the sSEPP 430-1, that may selectively modify the message according to a method for integrity protection with modification tracking, and that forward the modified message towards another intermediary 440 or to the rSEPP 430-2. The sSEPP 430-1 and rSEPP 430-2 may simultaneously act in both the“sender” and “receiver” roles, and their structure may also be similar or identical. The roles of the SEPPs 430 in delivery of a particular message are identified by the use of the prefix“s” or“r” indicating whether they send or receive a particular message.

Assuming that a message to be transmitted is an HTTP message that complies to HTTP protocol, the message includes three protocol elements:

A) A request line or a response line. The request line consists, for example, of 1) an HTTP method, 2) a request Uniform Resource Identifier (URI) that may contain an authority (host and port), a hierarchical part, a query and a fragment part, and 3) a protocol identifier. The response line consists, for example, of a protocol identifier, a status code and a status text;

B) A set of HTTP headers; and

C) An optional payload body, for instance formatted as JavaScript Object Notation (JSON) or Extensible Markup Language (XML).

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

However, before two participating SEPPs (e.g., vSEPP 312 and hSEPP 322 in FIG. 3, or sSEPP 430-1 and rSEPP 430-2) can exchange protected HTTP messages, it is realized herein that it is important that the SEPPs first mutually authenticate each other and then exchange a set of parameters over a secure connection between the two entities. For example, the set of parameters that the two SEPPs agree on includes capability exchange, cipher suites to use for protection of HTTP message payload, protection policies that indicate which parameters to encrypt in each HTTP message, and so on. Such parameters therefore comprise one or more configuration parameters and/or one or more security parameters. Further examples of such parameters will be described below.

Illustrative embodiments provide a framework in the form of a handshake procedure that enables SEPPs to set up a secure mutually authenticated connection (secure channel) and exchange the set of parameters beneficial for setting up security of HTTP messages. In addition, the SEPPs also exchange configuration information such as a provisioning file, etc. In illustrative embodiments, this procedure therefore becomes a prerequisite before the two SEPPs are ready to implement Transport Layer Security (TLS) or Application Layer Security (ALS) as mentioned above. As compared with the above-mentioned proposed mechanism for remote provisioning of protection policies, illustrative embodiments described herein exchange a protection policy during the initial handshake between the two SEPPs whereas the above-mentioned proposed mechanism updates remote SEPPs with a protection policy dynamically whenever the policy gets updated/revised in the SEPP of the home PLMN.

Furthermore, in accordance with the above architecture and techniques, the SBA communication model enables an“NF service consumer” (a network function acting as a service client) to be authenticated and authorized to access a service provided by or otherwise associated with an“NF service producer” (a network function acting as a service server). In such scenarios when the NFs are in different PLMNs, security is enabled by the above- described SEPPs of both networks, referred to in these scenarios as cSEPP and pSEPP (where“c” is for consumer or consuming and“p” is for producer or producing).

As mentioned above, there are intermediaries (IPX providers) between SEPPs that need to view and manipulate information in the RESTful API message (HTTP message). The cIPX is the IPX provider trusted by cSEPP, while the pIPX is the IPX provider trusted by pSEPP. However, there is no secure end-to-end (e2e) connection between cSEPP and pSEPP. There is only hop by hop security between two SEPPs. The SEPPs therefore implement ALS to protect the N32 interface. SEPPs ensure integrity and confidentiality protection for those elements on the application layer that are to be protected while allowing authorized IPX providers to view and modify elements in the HTTP message.

The Service Based Architecture in 5G is flexible in the sense, that it is easy to add new service and network functions by just“plugging them” into the bus (i.e., line to which all the network functions are connected). Each network node can call via the bus each other network node’s generic RESTful API.

We assume that not all servers might be under full operator control (e.g., outsourced, third party or even hacked nodes). Also, in international operators, one of those servers may be deployed in one network and used by the subsidiary in another network directly (very common scenario when new services are rolled out to see first if the service gains customer acceptance). This problem becomes severe in the context of interconnect networks where there is no e2e secure connection between two SEPPs. There is only hop by hop security between two SEPPs. Thus, the receiving SEPP in a network does not know for sure whether the HTTP message received on the N32 message is from a genuine/authorized SEPP.

When a malicious server wants to fetch information, to which it is not entitled, the malicious server can either:

(i) call a server the malicious server is allowed to talk to and just request“more” information than the actual NF interface would allow; or

(ii) call any server on the bus and request information.

One or more illustrative embodiments solve both cases (i) and (ii) with one approach based on binding of underlying physical information of the hardware/server with the TLS connection and then using the Exported Keying Material (EKM) from the TLS connection as the pre-shared key for server authorization. This ensures that the underlying TLS connection is bound to the server and the EKM thus obtained is ensured.

More particularly, one or more illustrative embodiments bind the actual location information (e.g., lower layer trusted platform module (TPM)/machine signature) into the TLS tunnel, so that a server can only request the information to which it is entitled and the information providing node knows from where the request is coming.

In the case of 5G SBA, illustrative embodiments provide the following enhancements to interconnect security aspects:

a. Binding physical/hardware information during TLS setup

This aspect has two sub-parts:

a) Binding hardware information of both server endpoints when obtaining EKM from the underlying TLS connection between two server endpoints.

b) Exchanging hardware information between two server endpoints during TLS handshake.

These are applicable in the following two scenarios in 5G SBA Interconnect security where TLS connection is established:

• SEPP to SEPP negotiation plane

• SEPP to IPX on the N32 data plane

b. Use hardware bound EKM to authorize the SEPP a) The SEPPs provide proof of possession (POP) of the EKM from its “negotiation plane” TLS connection, in every“data plane” message it sends over its N32 interface with a peer SEPP. The POP may be sent in a separate 3GPP specific header in the HTTP message. The receiving SEPP verifies that the POP belongs to the SEPP that inserted the POP into the N32 message

c. Use hardware bound EKM to authorize IPX modifications

This aspect has the following sub-parts:

a) SEPP exchanging EKM, established with its trusted IPX provider, with the peer SEPP

b) The receiving SEPP using the EKM obtained from the peer SEPP to authorize modifications made by the IPX provider trusted by the peer SEPP.

c) IPX provider uses EKM it has established with its trusted SEPP as a symmetric key to integrity protect its modifications in the N32 message on the“data plane”.

Background on 5 G Interconnect security

This section gives a background on the 3GPP Rel-l5 Service Based Architecture and Interconnect security used on the N32 interface between two operators.

a. Architecture

Recall in FIG. 3, the SEPP is a non-transparent proxy that protects inter-PLMN service layer messages between service consumers and service producers. These messages are transported across the N32 interface between two networks. The SEPP sits at the perimeter of the network and communicates with the SEPP of the roaming partner network over the N32 interface.

b. Interconnect security

Interconnect security refers to the protection applied on the N32 interface for both SEPP to SEPP messages, which are used typically for negotiation, and inter-PLMN NF to NF messages that use the N32 interface for communication.

b.1. Protection of SEPP to SEPP messages

The first step that is executed after discovering each other is that the two SEPPs perform an initial handshake to negotiate capability parameters, protection policy, cipher suites etc. This step is a pre-requisite to protecting inter-PLMN service layer messages between NFs.

As described in S3-181937 which is a TS 33.501 draft CR, the disclosure of which is incorporated herein by reference in its entirety, the initial handshake is performed over a mutually authenticated TLS connection between two SEPPs. The resulting EKM is used as a pre-shared key for deriving the necessary session keys (for confidentiality protection, integrity protection) for protecting NF to NF service layer messages.

b.2. Protection of inter-PLMN NF to NF service layer messages

Once the initial handshake is completed, the two SEPPs have all the necessary information to implement Application Layer Security (ALS) to protect inter-PLMN NF to NF service layer messages that are transported over the N32 interface via the local SEPP.

The ALS is a process by which:

a) the sending SEPP (sSEPP or cSEPP) transforms the incoming HTTP message (from a NF within the network) into a N32 message, by protecting the HTTP message using JavaScript Object Signing and Encryption (JOSE). The N32 message is over the N32 interface.

b) the receiving SEPP (rSEPP or pSEPP) transforms the N32 message into a HTTP message by undoing the protection. The HTTP message is forwarded to the target NF.

S3-181937 has a proposal for implementing ALS between two SEPPs.

In addition, sometime before SEPP-to-SEPP protection setup, the SEPP establishes a secure TLS based connection with its trusted IPX provider. This connection is used when transferring protected HTTP message

Illustrative embodiments will now be further described in multiple parts, i.e., Parts 1 through 6.

Part 1: Exchange hardware/physical location information of both TLS endpoints during TLS handshake TLS supports the concept of “extensions” which allow TLS Clients to request extended functionality from servers by sending data in the extensions field in the ClientHello and ServerHello messages during handshake.

Here are the structures of the ClientHello and ServerHello messages in TLS 1.3 (see draft RFC entitled“The Transport Layer Security (TLS) Protocol Version 1.3” draft-ietf-tls- tlsl 3-28, the disclosure of which is incorporated by reference herein in its entirety):

struct {

ProtocolVersion legacy_version = 0x0303; /* TLS vl.2 */

Random random;

opaque legacy_session_id<0..32>;

CipherSuite cipher_suites<2..2^A16-2>;

opaque legacy_compression_methods<1..2^A8-l>;

Extension extensions<8..2^A16-l>;

} ClientHello; struct {

ProtocolVersion legacy_version = 0x0303; /* TLS vl.2 */

Random random;

opaque legacy_session_id_echo<0..32>;

CipherSuite cipher_suite;

uint8 legacy_compression_method = 0;

Extension extensions<6..2^A16-l>;

} ServerHello;

The extensions field in the above structures is used during the TLS handshake by both the endpoints to convey their hardware/physical location information to each other.

Once the two endpoints exchange their hardware specific location information, each endpoint combines its local location information with the remote location information obtained from handshake, into a single identifier that is used in Part 2 (below) when obtaining EKM from the TLS connection. The 3 GPP specific extension name can be registered with the Internet Assigned Numbers Authority (I ANA).

An alternative embodiment for TLS 1.3 is to use the Encrypted Extensions message by the server endpoint to convey the server’s hardware/physical information.

The structure of the EncryptedExtensions message in TLS 1.3 is: struct { Extension extensions<0..2^A16-l>;

} EncryptedExtensions;

An alternative embodiment introduces a new element in the ClientHello and ServerHello messages that allows a higher layer to send non-TLS specific data in these messages. For example, below is an embodiment of a modified ClientHello message with a new element for sending application layer information: struct {

ProtocolVersion legacy_version = 0x0303; /* TLS vl.2 */

Random random;

opaque legacy_session_id<0..32>;

CipherSuite cipher_suites<2..2^A16-2>;

opaque legacy_compression_methods<1..2^A8-l>;

Extension extensions<8..2^A16-l>;

ApplicationLayerlnfo informationo

} ClientHello;

Yet another alternative embodiment exchanges hardware specific location information after TLS setup. That is, the two endpoints may also exchange the two endpoints through a separate SEPP to SEPP N32 messaging“after” TLS connection is setup. This may occur as part of the Initial Handshake procedure that is specified by 3GPP between two SEPPs.

The following are some examples of hardware specific location information that is exchanged during TLS handshake in one or more illustrative embodiments:

1. Hardware (TPM) backed identifier (ID)

2. Endorsement key (unique to all TPMs)

3. Attestation key (e.g., signing key, unique to all TPMs, derived from endorsement with some privacy guarantees)

4. External supplied but“wrapped” by EK, AK or any other derived TPM generated key.

Part 2: Bind hardware/physical location information when obtaining EKM The TLS Exporter function is used in 3 GPP Rel-l5 Interconnect security to setup a pre-shared key in two participating SEPPs based on the EKM function in TLS 1.2 (RFC 5705, the disclosure of which is incorporated by reference herein in its entirety).

Illustrative embodiments bind hardware/physical information into the computation of the EKM for the underlying TLS connection.

More particularly, the combined location information, derived in Part 1 above, is used as input to the exporter function in TLS. The per-association context value is used to input to the combined location information into the TLS exporter function.

The following is the extract from RFC 5705 which depicts inputs to the exporter function:

The exporter takes three input values:

• a disambiguating label string,

• a per-association context value provided by the application using the exporter, and

• a length value.

If context is provided, it computes:

PRF(SecurityParameters.master_secret, label,

SecurityParameters.client_random +

SecurityParameters.server_random +

context_value_length + context_value

)[length]

The obtained EKM value is now bound to the two endpoints of the TLS tunnel.

Since both endpoints obtain EKM from the underlying TLS connection, they both have the same secret key that may further be used to setup session keys.

There are multiple scenarios in 5G Interconnect security where TLS connection is setup between two endpoints and illustrative embodiments described in Part 1 and in Part 2 are used:

a) TLS connection between a SEPP and its trusted IPX provider.

b) TLS connection between two SEPPs during the initial handshake.

Part 3: SEPPs exchange EKM established with its trusted IPX provider with SEPP-SEPP messaging In Rel-l5, 3 GPP specifies that the connection between a SEPP and its trusted IPX provider be secured by TLS.

As such, one or more illustrative embodiments provide the following:

a. Part 2 be executed between a SEPP and its trusted IPX provider resulting in a hardware bound EKM value shared between the two.

b. SEPPs exchange this EKM with the peer SEPP.

Part 3.b may use the 3 GPP Rel-l5 Initial Handshake procedure between two SEPPs to exchange the EKM value obtained in Part 3. a.

As an alternative embodiment, two SEPPs may exchange this EKM independently after the initial handshake through a different procedure. This is useful, for example, whenever a new TLS connection is established between a SEPP and its trusted IPX provider.

Illustrative embodiments also generate a symmetric key from the EKM after step (a) and exchange this symmetric key with the peer SEPP. In this scenario, Part 5 and Part 6 below will use the IPX generated symmetric key to integrity protect IPX updates.

Part 4: Using EKM to authorize SEPP by checking proof-of-possession (POP)

Illustrative embodiments provide that the SEPPs provide proof of possession (POP) of the EKM from its“negotiation plane” TLS connection, in every“data plane” message it sends over its N32 interface with a peer SEPP.

For every N32 message that is sent over the N32 interface, the sending SEPP (cSEPP) sends, as a proof of possession, the EKM from its TLS connection used during the initial handshake. The EKM is digitally signed using the sender’s private key and included as one of the header parameters in the HTTP message (over N32).

The receiving SEPP (pSEPP) verifies the signature using sending SEPP's public key. A 3GPP specific HTTP header is used to convey the signed EKM in the N32 message sent over the N32 interface.

In some embodiments, SEPP use a“Token binding over HTTP" mechanism to include the signed EKM in every message (i.e., separate HTTP header similar to“Sec- Token-Binding” header). An alternative embodiment sends this signature in the HTTP payload, e.g., within the proposed metadata element in the N32 message payload (refer to Figure 13.2.4.2.1-1 in the above-referenced 3GPP draft CR S3-181937).

Part 5: IPX provider uses EKM as symmetric key to integrity protect its modifications

As described in the above-referenced S3- 181937 in the clause on Message formatting (13.2.4.2), the SEPP generates an N32 message payload from the received HTTP message. In the N32 message, modificationsBlock is used to capture updates by the intermediate IPX providers.

Illustrative embodiments provide that the IPX providers use the hardware-bound EKM value, obtained from its TLS connection with its trusted SEPP (Part 3. a. above), as the symmetric key to integrity protect its updates in the modificationsBlock element of the N32 message payload.

The generated MAC is captured in the patchRequest object generated by the IPX provider, which is then included in the modificationsBlock element of the N32 message payload (as described in S3-181937).

Part 6: Using EKM to authorize IPX modifications

As indicated in part 3.b. above, the receiving SEPP already is aware of the EKM value of the IPX provider associated with the sending SEPP. It can therefore verify that the updates are from the authorized IPX provider.

Referring now to FIGS. 5 and 6, some example message flows and methodologies associated with illustrative embodiments described above.

1. Exchanging EKM and Hardware Info between SEPPs during the Initial Handshake

FIG. 5 illustrates one example of a message flow 500 for preventing unauthorized requests in a service-based architecture according to an illustrative embodiment.

That is, as shown, the 3 GPP defined Initial Handshake may be is used in one embodiment to exchange cEKM and pEKM between two SEPPs, i.e., cSEPP 512 and pSEPP Step 1 : exchange hardware specific location information. Hardware information is exchanged between two SEPPs either during the TLS handshake or separately in the parameter exchange handshake. Step 1 comprises steps 2 and 3.

Step 2: cSEPP 512 sends Parameter Exchange Request as shown in FIG. 5.

Step 3: pSEPP 522 sends Parameter Exchange Response as shown in FIG. 5.

Steps 4 and 5: Each SEPP combines its local hardware (HW) location information with the obtained HW location information from the peer SEPP and uses this combined identifier as the“context value” input to the exporter function (in one or more embodiments, an exporter function resides on each SEPP). The exporter function generates an EKM value. The generated EKM value is thus bound to both TLS endpoints.

2. e2e authorization of SEPP and IPX provider updates for an example HTTP message from AMF to A USF

FIG. 6 illustrates an end-to-end security management methodology 600 in a service- based architecture according to an illustrative embodiment. The methodology involves AMF 612, AUSF 614, and cSEPP 616 in the PLMN of the service consumer, cIPX 618 which is the IPX provider trusted by cSEPP 616, AMF 622, AUSF 624, and pSEPP 626 in the PLMN of the service producer, and pIPX 628 which is the IPX provider trusted by pSEPP 626.

The figure depicts authorization of cSEPP and IPX provider updates on N32 data plane.

In step 630, cSEPP 616 generates a Proof of Possession (POP) signature on the EKM value it shares with pSEPP 626 and appends this signature in the N32 message (either in the header or in the metadata section of the payload).

In steps 632 and 634, intermediary IPX providers 618 and 628 use EKMs to integrity protect their updates. The generated MAC (message authentication code) is added to the modificationsBlock in the N32 message.

In step 636, pSEPP 626 verifies cSEPP’s signature using the public key of cSEPP 616. Additionally, pSEPP 636 verifies cIPX 618 and pIPX 628 updates using its local copy of cEKM and pEKM. It is to be understood that pEKM is EKM corresponding to the TLS tunnel between pIPX 628 and pSEPP 626, while cEKM is EKM corresponding to the TLS tunnel between cIPX 618 and cSEPP 616. Note that cEKM is shared earlier by cSEPP 616 either during the initial handshake or explicitly with a SEPP-to-SEPP negotiation plane message (e.g., whenever a new TLS connection is established between a SEPP and a trusted IPX provider).

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

Claims

I/We Claim:

1. A method comprising:

in a communication system comprising a first network operatively coupled to a second network, wherein the first network comprises a first network element operatively coupled to a second network element of the second network;

the first network element sending a first message to the second network element in accordance with a transport layer security procedure, wherein the first message comprises hardware-specific location information identifying the first network element;

the first network element receiving a second message from the second network element, wherein the second message comprises hardware-specific location information identifying the second network element; and

the first network element combining the hardware-specific location information of the first message with the hardware-specific location information of the second message to form an identifier.

2. The method of claim 1, further comprising the first network element using the identifier to generate a key value useable to securely send one or more subsequent messages to the second network element.

3. The method of claim 2, wherein the generated key value comprises a keying material value such that the hardware-specific location information of the first and second network elements is bound to the keying material value.

4. The method of claim 3, wherein the keying material value is computed by an exporter function associated with the transport layer security procedure.

5. The method of claim 2, wherein the first network element comprises a security edge protection proxy element of the first network and the second network element comprises a security edge protection proxy element of the second network.

6. The method of claim 5, wherein the one or more subsequent messages comprise one or more messages sent on a negotiation plane from the security edge protection proxy element of the first network to the security edge protection proxy element of the second network.

7. The method of claim 5, wherein the first message further comprises a separate key value bound to an underlying transport connection between the first network element and an intermediary packet exchange provider trusted by the first network.

8. The method of claim 7, wherein the second message further comprises a separate key value bound to an underlying transport connection between the second network element and an intermediary packet exchange provider trusted by the second network.

9. The method of claim 2, wherein the first network element comprises a security edge protection proxy element of the first network and the second network element comprises a node of an intermediary packet exchange provider.

10. The method of claim 9, wherein the one or more subsequent messages comprise one or more messages sent on a roaming inter-network interface plane from the security edge protection proxy element to the node of the intermediary packet exchange provider.

11. The method of claim 1, wherein the first and second messages are part of an initial handshake procedure associated with the transport layer security procedure.

12. The method of claim 11, wherein the hardware-specific location information in each of the first and second messages is inserted into an extensions field associated with the initial handshake procedure.

13. The method of claim 11, wherein the hardware-specific location information in each of the first and second messages is inserted into a field dedicated to the hardware- specific location information.

14. The method of claim 1, wherein the first and second messages are part of an encrypted extensions message exchange.

15. The method of claim 1, wherein the first and second messages are exchanged after an initial handshake procedure associated with the transport layer security procedure.

16. The method of claim 1, wherein the hardware-specific location information comprises a value attributable to the physical computing device on which the first network element resides.

17. The method of claim 16, wherein the value comprises a trusted platform module identifier.

18. The method of claim 16, wherein the value comprises a trusted platform module key.

19. The method of claim 2, wherein the first network element sends a proof of possession of the generated key value with the one or more subsequent messages sent to the second network element.

20. The method of claim 19, wherein proof of possession comprises a digital signature of the generated key value in the first network element.

21. The method of claim 2, wherein the first network element uses the generated key value to verify one or more subsequent messages it receives from the second network element.

22. The method of claim 21, wherein the one or more subsequent messages comprise one or more modifications made to the content of the one or more subsequent messages by one or more nodes of one or more intermediary packet exchange providers.

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

24. Apparatus comprising:

at least one processor, coupled to a memory, of the first network element configured to:

send a first message to the second network element in accordance with a transport layer security procedure, wherein the first message comprises hardware-specific location information identifying the first network element; receive a second message from the second network element, wherein the second message comprises hardware-specific location information identifying the second network element; and

combine the hardware-specific location information of the first message with the hardware-specific location information of the second message to form an identifier.

25. The apparatus of claim 24, wherein the first network element is further configured to use the identifier to generate a key value useable to securely send one or more subsequent messages to the second network element.

26. The apparatus of claim 25, wherein the generated key value comprises a keying material value such that the hardware-specific location information of the first and second network elements is bound to the keying material value.

27. The apparatus of claim 24, wherein the first network element comprises a security edge protection proxy element of the first network and the second network element comprises a security edge protection proxy element of the second network.

28. The apparatus of claim 24, wherein the first network element comprises a security edge protection proxy element of the first network and the second network element comprises a node of an intermediary packet exchange provider.

29. The apparatus of claim 24, wherein the first and second messages are part of an initial handshake procedure associated with the transport layer security procedure.

30. The apparatus of claim 24, wherein the first and second messages are part of an encrypted extensions message exchange.

31. The apparatus of claim 24, wherein the first and second messages are exchanged after an initial handshake procedure associated with the transport layer security procedure.

32. The apparatus of claim 24, wherein the hardware-specific location information comprises a value attributable to the physical computing device on which the first network element resides.

33. The apparatus of claim 25, wherein the first network element sends a proof of possession of the generated key value with the one or more subsequent messages sent to the second network element.

34. The apparatus of claim 25, wherein the first network element uses the generated key value to verify one or more subsequent messages it receives from the second network element.

35. The apparatus of claim 34, wherein the one or more subsequent messages comprise one or more modifications made to the content of the one or more subsequent messages by one or more nodes of one or more intermediary packet exchange providers.

36. A method comprising:

in a communication system comprising a first network operatively coupled to a second network through an intermediary packet exchange network, wherein the first network comprises a security edge protection proxy element operatively coupled to a node of the intermediary packet exchange network, and the node of the intermediary packet exchange network is operatively coupled to a security edge protection proxy element of the second network;

the node of the intermediary packet exchange network receiving a message from the security edge protection proxy element of the first network;

the node of the intermediary packet exchange network modifying content of the received message;

the node of the intermediary packet exchange network integrity-protecting the modified content using a key value bound to an underlying transport connection between itself and the security edge protection proxy element of the first network and wherein the security edge protection proxy element of the second network is previously made aware of the key value;

the node of the intermediary packet exchange network sending the message with the integrity-protected modified content to the security edge protection proxy element of the second network.

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

38. Apparatus comprising at least one processor coupled to a memory to form the node of the intermediary packet exchange network such that the processor is configured to perform the steps of claim 36.