WO2023223118A1 - Identification d'abonnement dans des réseaux - Google Patents

Identification d'abonnement dans des réseaux Download PDF

Info

Publication number
WO2023223118A1
WO2023223118A1 PCT/IB2023/054020 IB2023054020W WO2023223118A1 WO 2023223118 A1 WO2023223118 A1 WO 2023223118A1 IB 2023054020 W IB2023054020 W IB 2023054020W WO 2023223118 A1 WO2023223118 A1 WO 2023223118A1
Authority
WO
WIPO (PCT)
Prior art keywords
identifier
domain
wireless communication
communication device
concealed
Prior art date
Application number
PCT/IB2023/054020
Other languages
English (en)
Inventor
Karl Norrman
Monica Wifvesson
Helena VAHIDI MAZINANI
Cheng Wang
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Publication of WO2023223118A1 publication Critical patent/WO2023223118A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H04L63/0414—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden during transmission, i.e. party's identity is protected against eavesdropping, e.g. by using temporary identifiers, but is known to the other party or parties involved in the communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/40—Security arrangements using identity modules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/69—Identity-dependent
    • H04W12/72—Subscriber identity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/04—Terminal devices adapted for relaying to or from another terminal or user

Definitions

  • the disclosed subject matter relates to subscription identification in networks.
  • a User Equipment When connecting to a Fifth Generation (5G) serving network, a User Equipment (UE) must identify its subscription to the network, in part to enable a Unified Data Management (UDM) in a home network to obtain credentials for authentication.
  • UDM Unified Data Management
  • each subscription is associated with a corresponding permanent identifier of type Subscription Permanent Identifier (SUPI).
  • SUPI Subscription Permanent Identifier
  • the UE may identify the subscription, not by sending the SUPI to the network, but instead by sending a temporary identifier of a type called a Subscription Concealed Identifier (SUCI).
  • the SUCI identifier is a randomized encryption of the subscription’s SUPI.
  • each transmitted SUCI is for all practical purposes indistinguishable from any other SUCI in the eyes of an eavesdropper.
  • the SUCI is encrypted with the public key of the home network in which the UDM resides, and the home network can therefore decrypt it to obtain the corresponding SUPI.
  • the UDM passes the associated subscription’s SUPI to the SEAF/AMF in the serving network.
  • the SEAF/AMF is the function in the serving network that controls the security of the UE during its connection. Used this way, the UDM acts as a translation service, translating SUCIs into SUPIs for SEAF/AMF functions.
  • the Security Anchor Function SEAF/AMF
  • AMF Access and Mobility Management Function
  • GUI Globally Unique Temporary UE Identity
  • the UE Before the UDM passes the SUPI to the SEAF/AMF, the UE is authenticated. However, for the purpose of the disclosed subject matter, we ignore that aspect. Hence, we can view the UDM as a type of identity resolution server despite its other capabilities.
  • the UE is “authenticated”. In reality, the process is more complicated because the UE comprises two parts, the Mobile Equipment (ME) and the Universal Subscriber Identity Module (USIM). Both parts play roles in the authentication and in the SUCI computation.
  • ME Mobile Equipment
  • USIM Universal Subscriber Identity Module
  • 3GPP Third Generation Partnership Project
  • TS Technical Specification
  • a 5G ProSe Remote UE can provide a SUCI as part of 5G ProSe UE- to-Network Relay Communication setup procedure, as shown in step 3 of the Figure (FIG.) 1, which is a reproduction of FIG. 6.3.3.2.2-1 from 3GPP TS 33.503.
  • the 5G ProSe Remote UE's SUCI is further sent to the ProSe Key Management Function (PKMF) of the 5G ProSe Remote UE via to a 5G ProSe UE-to-Network Relay, in steps 4a and 4b.
  • PKMF ProSe Key Management Function
  • the PKMF of the 5G Prose Remote UE needs to ask the network, i.e. UDM / Subscription Identifier De-concealing Function (SIDE), to de-conceal SUCI and get a SUPI before the PKMF of the 5G Prose Remote UE is able to proceed with the rest of procedures, see FIG. 1. Further description of the procedure of FIG. 1 can be found in Section 6.3.3.2.2 of 3GPP TS 33.503.
  • a method performed in a wireless communication device for identification comprises determining a domain of a service access point associated to the domain, obtaining or computing a concealed identifier for the wireless communication device based on at least an identifier associated with the wireless communication device and a domain identifier of the domain, and transmitting a service access message to the service access point, the service access message comprising the concealed identifier.
  • the concealed identifier enables the service access point to obtain the identifier and associate the identifier with the wireless communication device.
  • obtaining or computing the concealed identifier comprises associating the domain identifier for the domain with the identifier associated with the wireless communication device, computing a cryptographic binding token based on the domain identifier and the identifier associated with the wireless communication device, and encoding the cryptographic binding token into the concealed identifier.
  • the concealed identifier is a type of SUCI computed based on a plaintext block that comprises the domain identifier for the domain.
  • the concealed identifier is a type of SUCI computed based on a MAC computation that covers (e.g., is based on) the domain identity for the domain.
  • the concealed identifier is a type of SUCI computed based on a new key K’ that is derived from a Eph shared key wherein K’ is used to compute a MAC over at least the domain identity for the domain and the MAC is included in the concealed identifier.
  • the concealed identifier is a type of SUCI computed based on a new key K’ that is derived from a Eph shared key wherein K’ is used to compute a MAC over at least the domain identity for the domain and the MAC and the domain identity are included in the concealed identifier.
  • a method performed by a service access point for wireless communication device identification comprises receiving a first message from a wireless communication device, the first message comprising a concealed identifier of the wireless communication device. The method further comprises transmitting a second message comprising the concealed identifier to an identity resolution function, receiving a third message comprising a deconcealed identifier corresponding to the concealed identifier, associating the deconcealed identifier with the wireless communication device, and providing service to the wireless communication device based on the association of the deconcealed identifier with the wireless communication device.
  • providing the service comprises providing the service under an assumption that the identity resolution server associates the wireless communication device with the deconcealed identifier.
  • the second message comprising the concealed identifier further comprises an identifier for a domain to which the service access point is associated.
  • a method performed by an identity resolution function comprise receiving a first message from a service access point, the first message comprising a concealed identifier.
  • the method further comprises determining a domain associated with the service access point and verifying that the concealed identifier is computed based on at least the domain associated with the service access point from which the first message is received.
  • the method further comprises, responsive to verifying that the concealed identifier is computed based on at least the domain associated with the service access point from which the first message is received, computing a deconcealed identifier associated to the concealed identifier and transmitting a second message comprising the deconcealed identifier to the service access point.
  • Embodiments of a network that that implements a service access point or an identity resolution function are also disclosed herein.
  • FIG. 1 is a reproduction of FIG. 6.3.3.2.2-1 from 3GPP TS 33.503.
  • FIG. 2 illustrates one example of a cellular communications system according to some embodiments of the disclosed subject matter.
  • FIGs. 3 and 4 illustrate example embodiments in which the cellular communication system of FIG. 2 is a Fifth Generation (5G) System (5GS).
  • 5G Fifth Generation
  • 5GS Fifth Generation
  • FIG. 5 illustrates a system in accordance with some embodiments of the disclosed subject matter.
  • FIG. 6 illustrates a signaling flow showing identification of device to IRF as well as to SAP in accordance with some embodiments of the disclosed subject matter. Authentication of the device towards the IRF may be required before the IRF releasing the SUPI’, but that is out of scope of the disclosed subject matter, which focuses on identification.
  • FIG. 7 illustrates the legacy computation of SUCI and is a reproduction of a corresponding figure from 3GPP TS 33.501, clause C.3.2.
  • FIGs. 8, 9, and 10 are schematic block diagrams of a network node according to some embodiments of the disclosed subject matter.
  • FIGs. 11 and 12 are schematic block diagrams of a wireless communication device according to some embodiments of the disclosed subject matter.
  • Radio Node As used herein, a “radio node” is either a radio access node or a wireless communication device.
  • Radio Access Node As used herein, a “radio access node” or “radio network node” or “radio access network node” is any node in a Radio Access Network (RAN) of a cellular communications network that operates to wirelessly transmit and/or receive signals.
  • RAN Radio Access Network
  • a radio access node examples include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high-power or macro base station, a low-power base station (e.g., a micro base station, a pico base station, a home eNB, or the like), a relay node, a network node that implements part of the functionality of a base station or a network node that implements a gNB Distributed Unit (gNB-DU)) or a network node that implements part of the functionality of some other type of radio access node.
  • a base station e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B
  • Core Network Node is any type of node in a core network or any node that implements a core network function.
  • Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), a Home Subscriber Server (HSS), or the like.
  • MME Mobility Management Entity
  • P-GW Packet Data Network Gateway
  • SCEF Service Capability Exposure Function
  • HSS Home Subscriber Server
  • a core network node examples include a node implementing an Access and Mobility Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like.
  • AMF Access and Mobility Function
  • UPF User Plane Function
  • SMF Session Management Function
  • AUSF Authentication Server Function
  • NSSF Network Slice Selection Function
  • NEF Network Exposure Function
  • NRF Network Exposure Function
  • NRF Network Exposure Function
  • PCF Policy Control Function
  • UDM Unified Data Management
  • a “communication device” is any type of device that has access to an access network.
  • Some examples of a communication device include, but are not limited to: mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or Personal Computer (PC).
  • the communication device may be a portable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and/or data via a wireless or wireline connection.
  • Wireless Communication Device One type of communication device is a wireless communication device, which may be any type of wireless device that has access to (i.e., is served by) a wireless network (e.g., a cellular network).
  • a wireless communication device include, but are not limited to: a User Equipment device (UE) in a 3GPP network, a Machine Type Communication (MTC) device, and an Internet of Things (loT) device.
  • UE User Equipment
  • MTC Machine Type Communication
  • LoT Internet of Things
  • Such wireless communication devices may be, or may be integrated into, a mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or PC.
  • the wireless communication device may be a portable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and/or data via a wireless connection.
  • Network Node As used herein, a “network node” is any node that is either part of the RAN or the core network of a cellular communications network/system.
  • the UE can connect to the 5G network via other access points than the regular gNB/SEAF/AMF path, e.g., via self-backhauling relay nodes or via WiFi. While WiFi may be treated as a so-called untrusted access, which is carefully integrated with 5G, other possibilities are being discussed.
  • a UE can also access certain specific services that are provided or enabled by AS/AF (Application Server, Application Function). These AS/AF can be deployed either by the Mobile Network Operator (MNO) or a 3 rd party service provider. When accessing these services, the identification of UE towards the AS/AF could be yet provided by the 5G network, e.g. based on its subscription identifier SUPI. For example, there may be a 5G ProSe Remote UE utilizing connectivity provided by 5G ProSe UE-to-Network Relay Communication service, via another 5G Prose UE-to-Network Relay. In this example, the 5G ProSe Remote UE needs to identify itself to the network offering the 5G ProSe UE-to- Network Relay Communication service. As mentioned above, the 5G ProSe Remote UE can then use SUCI as its identification.
  • AS/AF Application Server, Application Function
  • GBA Generic Bootstrapping Architecture
  • IP Internet Protocol Multimedia Subsystem
  • the UE does not use the SUPI or the SUCI mechanism but resorts to other service- specific identifiers and privacy enhancing mechanisms.
  • the UE identifies itself towards the Boot Strapping Function (BSF) in the GBA by either an IP Multimedia Private Identity (IMPI), which is a long-term identifier from the IMS framework, or a special temporary identifier TMPI.
  • IMPI IP Multimedia Private Identity
  • TMPI temporary identifier
  • Each IMS device has a private identifier (IMPI) and a public identifier (IMPU). These are fixed, and there is no privacy enhancement like the SUCI. Every time the UE presents the IMPI, privacy is at risk. However, it is less of an issue for IMS compared to 5G radio access because IMS traffic is encrypted by the radio link-layer protection - something which is not possible when the UE transmits the SUCPSUPI.
  • IMPI private identifier
  • IMPU public identifier
  • a common method for identifying the subscription would harmonize subsystems in 3GPP. Granted, this would take time to accomplish in standardization.
  • One exemplary technical benefit is that the same solution can be used for several services, harmonizing the design, and at the same time ensure that if servers in one domain are compromised, they cannot use the UDM as a general SUCI-to-SUPI translator to resolve SUCIs generated for a different domain. The latter is especially useful to avoid that they collect SUCIs transmitted for 5G access and later resolve these with the UDM to track which users where at in a certain location.
  • the SUCI is bound to the specific domain in which the UE intends to use it. This binding is integrated in the existing SUCI generation construction.
  • a new type of SUCI is proposed, so that the regular SUCIs and the new SUCIs can be separated in a backwards compatible way.
  • a UE identifies its subscription towards services it connects to by presenting a new type of SUCI, referred to herein as SUCI’, to a service access point belonging to a domain. Similar to SUCI, SUCI’ is computed from SUPI. SUCI’ is however securely bound to the service domain to which the UE intends to connect. Upon reception of a request to resolve the SUCI’, the UDM verifies that request comes from the domain bound to the SUCI’, and only returns the SUPI if the verification succeeds.
  • SUCI new type of SUCI
  • embodiments of the disclosed subject matter may provide a number of advantages of existing solution(s). Three example advantages that may be provided by embodiments of the disclosed subject matter are as follows:
  • Embodiments of the disclosed subject matter separate service access points into different domains, ensuring that SUCIs generated for one domain cannot be resolved by service access points from another domain, thus preventing compromised service access points from one domain to use the identity resolution function as a general purpose SUCI-to- SUPI translation service.
  • Embodiments of the disclosed subject matter provide a uniform and privacy preserving method based on the existing SUCI scheme for subscriber identification to essentially any service in 5G and beyond. This harmonizes the identification process, and services such as GBA, IMS, 5G ProSe UE-to-Network Relay Communication can migrate towards the common scheme.
  • Embodiments of the disclosed subject matter may allow different domains to obtain different SUPI-like identifiers. This improves user privacy further, especially when the identity resolution function and/or the device have very different levels of trust in different domains.
  • FIG. 2 illustrates one example of a cellular communications system 200 in which embodiments of the disclosed subject matter may be implemented.
  • the cellular communications system 200 is a 5G system (5GS) including a Next Generation RAN (NG-RAN) and a 5G Core (5GC); however, the disclosed subject matter may be extended to other types of wireless communications systems.
  • the RAN includes base stations 202-1 and 202-2, which in the 5GS include NR base stations (gNBs) and optionally next generation eNBs (ng-eNBs) (e.g., LTE RAN nodes connected to the 5GC), controlling corresponding (macro) cells 204-1 and 204-2.
  • gNBs NR base stations
  • ng-eNBs next generation eNBs
  • LTE RAN nodes connected to the 5GC
  • controlling corresponding (macro) cells 204-1 and 204-2 controlling corresponding (macro) cells 204-1 and 204-2.
  • the base stations 202-1 and 202-2 are generally referred to herein collectively as base stations 202 and individually as base station 202.
  • the (macro) cells 204-1 and 204-2 are generally referred to herein collectively as (macro) cells 204 and individually as (macro) cell 204.
  • the RAN may also include a number of low power nodes 206-1 through 206-4 controlling corresponding small cells 208-1 through 208- 4.
  • the low power nodes 206-1 through 206-4 can be small base stations (such as pico or femto base stations) or RRHs, or the like.
  • one or more of the small cells 208-1 through 208-4 may alternatively be provided by the base stations 202.
  • the low power nodes 206-1 through 206-4 are generally referred to herein collectively as low power nodes 206 and individually as low power node 206.
  • the small cells 208-1 through 208-4 are generally referred to herein collectively as small cells 208 and individually as small cell 208.
  • the cellular communications system 200 also includes a core network 210, which in the 5G System (5GS) is referred to as the 5GC.
  • the base stations 202 (and optionally the low power nodes 206) are connected to the core network 210.
  • the base stations 202 and the low power nodes 206 provide service to wireless communication devices 212-1 through 212-5 in the corresponding cells 204 and 208.
  • the wireless communication devices 212-1 through 212-5 are generally referred to herein collectively as wireless communication devices 212 and individually as wireless communication device 212.
  • the wireless communication devices 212 are oftentimes UEs, but the disclosed subject matter is not limited thereto.
  • FIG. 3 illustrates a wireless communication system represented as a 5G network architecture composed of core Network Functions (NFs), where interaction between any two NFs is represented by a point-to-point reference point/interface.
  • NFs core Network Functions
  • FIG. 3 can be viewed as one particular implementation of the system 200 of FIG. 2.
  • the 5G network architecture shown in FIG. 3 comprises a plurality of UEs 212 connected to either a RAN 202 or an Access Network (AN) as well as an AMF 300.
  • the R(AN) 202 comprises base stations, e.g. such as eNBs or gNBs or similar.
  • the 5GC NFs shown in FIG. 3 include a NSSF 302, an AUSF 304, a UDM 306, the AMF 300, a SMF 308, a PCF 310, and an Application Function (AF) 312.
  • the N 1 reference point is defined to carry signaling between the UE 212 and AMF 300.
  • the reference points for connecting between the AN 202 and AMF 300 and between the AN 202 and UPF 314 are defined as N2 and N3, respectively.
  • N4 is used by the SMF 308 and UPF 314 so that the UPF 314 can be set using the control signal generated by the SMF 308, and the UPF 314 can report its state to the SMF 308.
  • N9 is the reference point for the connection between different UPFs 314, and N14 is the reference point connecting between different AMFs 300, respectively.
  • N15 and N7 are defined since the PCF 310 applies policy to the AMF 300 and SMF 308, respectively.
  • N12 is required for the AMF 300 to perform authentication of the UE 212.
  • N8 and N10 are defined because the subscription data of the UE 212 is required for the AMF 300 and SMF 308.
  • the 5GC network aims at separating UP and CP.
  • the UP carries user traffic while the CP carries signaling in the network.
  • the UPF 314 is in the UP and all other NFs, i.e., the AMF 300, SMF 308, PCF 310, AF 312, NSSF 302, AUSF 304, and UDM 306, are in the CP.
  • Separating the UP and CP guarantees each plane resource to be scaled independently. It also allows UPFs to be deployed separately from CP functions in a distributed fashion. In this architecture, UPFs may be deployed very close to UEs to shorten the Round Trip Time (RTT) between UEs and data network for some applications requiring low latency.
  • RTT Round Trip Time
  • the core 5G network architecture is composed of modularized functions.
  • the AMF 300 and SMF 308 are independent functions in the CP. Separated AMF 300 and SMF 308 allow independent evolution and scaling.
  • Other CP functions like the PCF 310 and AUSF 304 can be separated as shown in FIG. 3.
  • Modularized function design enables the 5GC network to support various services flexibly.
  • Each NF interacts with another NF directly. It is possible to use intermediate functions to route messages from one NF to another NF.
  • a set of interactions between two NFs is defined as service so that its reuse is possible. This service enables support for modularity.
  • the UP supports interactions such as forwarding operations between different UPFs.
  • FIG. 4 illustrates a 5G network architecture using service-based interfaces between the NFs in the CP, instead of the point-to-point reference points/interfaces used in the 5G network architecture of FIG. 3.
  • the NFs described above with reference to FIG. 3 correspond to the NFs shown in FIG. 4.
  • the service(s) etc. that a NF provides to other authorized NFs can be exposed to the authorized NFs through the service-based interface.
  • the service based interfaces are indicated by the letter “N” followed by the name of the NF, e.g. Namf for the service based interface of the AMF 300 and Nsmf for the service based interface of the SMF 308, etc.
  • the NEF 400 and the NRF 402 in FIG. 4 are not shown in FIG. 3 discussed above. However, it should be clarified that all NFs depicted in FIG. 3 can interact with the NEF 400 and the NRF 402 of FIG. 4 as necessary, though not explicitly indicated in FIG. 3.
  • the AMF 300 provides UE-based authentication, authorization, mobility management, etc.
  • a UE 212 even using multiple access technologies is basically connected to a single AMF 300 because the AMF 300 is independent of the access technologies.
  • the SMF 308 is responsible for session management and allocates Internet Protocol (IP) addresses to UEs. It also selects and controls the UPF 314 for data transfer. If a UE 212 has multiple sessions, different SMFs 308 may be allocated to each session to manage them individually and possibly provide different functionalities per session.
  • the AF 312 provides information on the packet flow to the PCF 310 responsible for policy control in order to support QoS.
  • the PCF 310 determines policies about mobility and session management to make the AMF 300 and SMF 308 operate properly.
  • the AUSF 304 supports authentication function for UEs or similar and thus stores data for authentication of UEs or similar while the UDM 306 stores subscription data of the UE 212.
  • the Data Network (DN) not part of the 5GC network, provides Internet access or operator services and similar.
  • An NF may 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., a cloud infrastructure.
  • FIG. 5 illustrates a system 500 in accordance with some embodiments of the disclosed subject matter.
  • the system 500 is or includes a 5GS.
  • the system 500 includes a wireless communication device (WCD) 502 (e.g., a UE), a set of Service Access Points (S APs) 504- 1 though 504-4 (generally referred to herein individually as SAP 504 and collectively as SAPs 504), and an Identity Resolution Function (IRF) 506 (e.g., a UDM).
  • WCD wireless communication device
  • SAP APs Service Access Points
  • SAPs 504- 1 though 504-4 generally referred to herein individually as SAP 504 and collectively as SAPs 504
  • IRF Identity Resolution Function
  • the WCDs 502 are mobile devices (e.g., UEs)
  • the IRF 506 is a UDM
  • the SAPs 504-1 through 504-4 are service access points that provide services in a mobile network.
  • the SAPs 504-1 through 504-4 are partitioned into domains 508-1 and 508-2 (generally referred to herein individually as domain 508 and collectively as domains 508). While two domains are shown in this example, there may be any number of two or more domains.
  • Each domain 508 may contain one or more SAPs 504.
  • Different domains 504 may represent different service types, e.g., ProSe, GBA, or IMS. Domains 504 may present different network types, e.g. EPC, 5GC, SNPN, or the like. Domains 504 may also represent geographical areas, Application Server/Function, which services are appropriate for certain UE types or for certain subscriptions, or the like.
  • a special service type is network access. While the description provided herein is provided in the 5G network setting, it should be clear that any network access setting is equally suitable.
  • the SUCI mechanism enhances user privacy when their devices connect to the 5G radio access service.
  • this legacy functionality is represented by the legacy UDM functionality 510.
  • FIG. 5 also shows that IRF 506 includes new proposed functionality for a domain separated SUCI mechanism, which is referred to in the example of FIG. 5 as enhanced domain aware UDM functionality 512.
  • the new type of SUCI disclosed herein is distinguished herein from the legacy SUCI by naming it SUCI’; however, SUCI’ is only one example name and should be understood as encompassing this new disclosed identity regardless of its name.
  • the IRF 506 is, in some embodiments, collocated with the UDM, it is to be understood that the IRF 506 may be located elsewhere (e.g., in a new NF or incorporated into another existing NF), possibly using the UDM as a backend.
  • the UDM acts as a backend for the IRF 506, the IRF 506 behaves as a proxy-translator for SUCI’-to-SUPI, and the UDM can reject direct requests from the SAPs 504.
  • a new separate SUCI’ type is introduced herein. This type allows legacy UDMs to reject resolution requests for SUCI’, since it would be of an unrecognizable format and type. It also allows the legacy UDM, or a filtering function added in front of it, to reject requests not coming from authorized SEAF/AMF or SAP functions. Authorization and authentication of SEAF/AMF and SAP functions can be based on the existing Service Based Architecture (SB A).
  • SB A Service Based Architecture
  • the SBA is extended to provide this functionality.
  • SBA transactions are protected by the TLS protocol using certificate-based authentication. Applying best current practices, this solves the issue of identifying and authenticating the requesting function.
  • the filtering function logically groups SEAF/AMF and SAPs 504 into domains 508. This grouping can for example be pre-configured or obtained from an external policy node. Because each request can be tied to the identity of the requestor (via the identification and authentication provided by TLS), the filtering function can verify whether the requestor is part of the domain 508 that the SUCI’ belongs to, or in case the request includes a legacy SUCI, whether the requestor is of type AMF/SEAF.
  • the filtering function may further verify whether an AMF/SEAF is allowed to resolve a SUCI at all.
  • the filtering function may either reject requests, or forward information about the verification result to the UDM.
  • the filtering function may also be part of the IRF 506 or updated UDM. Again, the IRF 506 may be part of the UDM.
  • SAPs may be maliciously implemented, act out of ignorance or convenience, or have exploitable flaws that make them vulnerable to become tools for SUCI-to-SUPI resolution. Not all SAPs may follow equally strong security assurance requirements as SEAF/AMF and could therefore be more susceptible to exploit.
  • the WCD 502 must be aware of which domain 508 it intends to connect to and ensure that it binds the SUCI’ to that domain 508. Failing to do so risks producing a SUCI’ that can be misused by a compromised SAP 504 of a different domain.
  • the mechanism can prevent attacks from SAPs against other SAPs in the same domain by also binding the SUCI’ to an SAP identifier of the associated SAP 504.
  • an identifier may be available to the WCD 502 and the IRF 506 for some services but cannot be expected to the present for all services.
  • the binding of the SAP identifier could be performed in the same way as binding to the domain, which is described in more detail below.
  • the identifier that is bound in the SUCI’ may not be identical to the identifier the IRF 506 uses for the SAP, but both identifiers point to the same entity.
  • Adversaries are assumed to have access to the SUCI-to-SUPI resolution interface of the IRF 506; they are assumed to have access to the response interface of the SAPs 504, and to the device-facing interface of the SAPs 504. Adversaries are further assumed to have access to the radio interface of the WCD 502.
  • FIG. 6 shows the signaling flow for device identification to IRF 506 and SAP 504 in accordance with one example embodiment of the disclosed subject matter.
  • the SAP is SAP 504-3 in domain 508-2.
  • the WCD 502 determines a domain identity for the domain 508-2 of the SAP 504-3 (step 600).
  • the WCD 502 may determine the domain identity in any desired manner. While details regarding some example embodiments are described below, as one example, the WCD 502 determines the domain identity of the SAP 504-3 by receiving the domain identity or information indicative of the domain identity from the SAP 504-3 (e.g., via a broadcast notification). The WCD 502 obtains or computes a SUCI’ that is bound to the domain 508-2 (e.g., obtains or computes the SUCI’ based on the domain identity determined in step 600) (step 602).
  • the WCD 502 is a UE, which includes a ME and USIM.
  • the ME may compute the SUCI’ directly or obtain the SUCI’ by calling a function of the USIM, where the USIM computes the SUCI’ and returns the SUCI’ to the ME. Both of these variations fall within the scope of step 602. Details regarding various embodiments for how the SUCI’ is computed and bound to the domain 508-2 are described below.
  • the WCD 502 sends the SUCI’ to the SAP 504-3 (step 604), and the SAP 504-3 sends a request including the SUCI’ to the IRF 506 (step 606).
  • the IRF 506 determines the domain 508-2 associated with the SAP 504-3 and verifies the SUCI’ (step 608). More specifically, the IRF 506 determines whether the SUCI’ is received from an SAP that is in the domain 508-2 to which the SUCI’ is bound. If so, the SUCI’ is verified; otherwise, the request is rejected. Assuming that the SUCI’ is verified, the IRF 506 computes a respective SUPI (or SUPF as described below) based on the SUCI’ (step 610) and returns the SUPI to the SAP 504- 3 (step 612). The SAP 504-3 may then use the SUPI or SUPI’ to perform one or more operational tasks associated to the operation of the SAP 504-3.
  • a respective SUPI or SUPF as described below
  • the SAP 504-3 may associate the SUPI or SUPI’ with the WCD 502 (step 614) and provide service to the WCD 502 based on the association of the SUPI or SUPI’ with the WCD 502 (e.g., under the assumption that the IRF 506 associates the WCD 502 with the SUPI or SUPI’) (step 616).
  • the WCD 502 binds the domain 508-2, to which the SAP 504-3 belongs, to the SUCI’ by a cryptographic computation.
  • the computation is such that the IRF 506 can verify that the WCD 502 generated the SUCI’ for the specific domain 508-2 and that the SAP 504-3 from which IRF 506 received the resolution request in step 606 are a match.
  • the word “match” is used because it may be the case that the WCD 502 refers to the domain 508-2 by one identifier and the IRF 506 refers to the domain 508-2 by another identifier. What matters is that the IRF 506 can deduce that the intended domain is the same.
  • one SAP may announce a service as “Vegan restaurants in this area, brought to you by BrandName A”, and the WCD 502 binds the SUCI’ to this identifier.
  • Another SAP announces a service “Notifications when celebrities posts on social media about this location, brought to you by BrandName B”, and the WCD 502 binds the SUCI’ to that identifier.
  • the IRF 506 may know that both these brands and their services are instances of a single mobile operator’ s services, all operated from the same server farm. The IRF 506 knows this domain as “Operator C’s sever farm”. In this case the SUCI’ can be considered bound to the same domain even though different identifiers were used by the WCD 502 when computing the SUCI’ and the IRF 506 when verifying it.
  • the domain identifier used by the WCD 502 is referenced by the letter D.
  • SUCI’ computation and verification can be based on the existing legacy SUCI computation shown in FIG. 7, which is reproduced from 3GPP TS 33.501, Clause C.3.2. As discussed above, the computation can be done in the WCD 502 and the verification in the IRF 506.
  • binding the domain identifier to the SUCI’ requires a key.
  • This key is preferably obtained from the generation procedure for the SUCI used in legacy 5G. The embodiments are described in reference to FIG. 7.
  • D is part of the plaintext block of the SUCI computation, and the binding derives from that Message Authentication Code (MAC) function.
  • the verification comprises checking the MAC and that D in the plaintext block corresponds to the domain identifier for the SAP from which the request was received.
  • D is covered by the MAC computation, but not included in the plaintext block.
  • the verification comprises computing the MAC using the domain identifier for the SAP from which the request was received.
  • a new key K’ is derived from the Eph shared key in FIG. 7.
  • K’ is used to compute a MAC over at least D and include this in the Final output in FIG. 7.
  • the verification comprises deriving the key K’ in the same way, computing the MAC locally in the same way except that the domain of the SAP sending the resolution request is used, match that the received MAC matches the locally computed MAC.
  • a fourth embodiment is equal to the third embodiment except that the WCD 502 also includes D in the Final output, and the verification process uses that D during its local computation of the MAC. The verification process also verifies that the domain of the SAP sending the request matches D.
  • SUPI computation. So far, only the SUPI has been discussed as a long-term identifier.
  • different service domains learn different identifiers for the WCD 502. For example, while some services may require the SUPI for lawful intercept reasons, some services may be operated in unregulated business environments, and it may be better to provide them with an identifier they cannot connect to the SUPI itself. Thus, in some embodiments, different identifiers for the WCD 502 are used for different domains 508. [0090] Taking this idea one step further, in some embodiments, different SAPs 504 within the same domain 508 may be provided with different identifiers for the WCD 502. In yet another embodiment, different identifiers for the WCD 502 may be provided to the same SAP 504 at different times or procedure runs.
  • the IRF 506 computes an identifier SUPI’ in step 610, which it returns to the SAP 504 in step 612.
  • the identify function is introduced here just to get a uniform presentation, an IRF computing the identity function could be implemented by doing no computation and just return the SUPI as is.
  • Examples of computing SUPI’ are:
  • the key may be global and would then allow the IRF to deanonymize the SUPI’ at a later stage if needed, e.g., for lawful intercept reasons.
  • the IRF may keep a table mapping the random value to the SUPI; the IRF may generate the value using the SUPI as a seed to the PRNG or input to the PRF, KDF or hash function;
  • FIG. 8 is a schematic block diagram of a network node 800 according to some embodiments of the disclosed subject matter. Optional features are represented by dashed boxes.
  • the network node 800 may be, for example, a network node that implements all or part of the functionality of the SAP 504 or IRF 506 or UDM described herein.
  • the network node 800 includes one or more processors 804 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory 806, and a network interface 808.
  • the one or more processors 804 are also referred to herein as processing circuitry.
  • the one or more processors 804 operate to provide one or more functions of the network node 800 as described herein (e.g., one or more functions of the SAP 504 or IRF 506 or UDM described herein).
  • the function(s) are implemented in software that is stored, e.g., in the memory 806 and executed by the one or more processors 804.
  • FIG. 9 is a schematic block diagram that illustrates a virtualized embodiment of the network node 800 according to some embodiments of the disclosed subject matter. Again, optional features are represented by dashed boxes.
  • a “virtualized” network node is an implementation of the network node 800 in which at least a portion of the functionality of the network node 800 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)).
  • the network node 800 includes one or more processing nodes 900 coupled to or included as part of a network(s) 902.
  • Each processing node 900 includes one or more processors 904 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 906, and a network interface 908.
  • functions 910 of the network node 800 described herein e.g., one or more functions of the AMF 300, the SMF 308, or the NSACF 404 described herein
  • some or all of the functions 910 of the network node 800 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 900.
  • a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the network node 800 or a node (e.g., a processing node 900) implementing one or more of the functions 910 of the network node 800 in a virtual environment according to any of the embodiments described herein is provided.
  • a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non- transitory computer readable medium such as memory).
  • FIG. 10 is a schematic block diagram of the network node 800 according to some other embodiments of the disclosed subject matter.
  • the network node 800 includes one or more modules 1000, each of which is implemented in software.
  • the module(s) 1000 provide the functionality of the network node 800 described herein. This discussion is equally applicable to the processing node 900 of FIG. 9 where the modules 1000 may be implemented at one of the processing nodes 900 or distributed across multiple processing nodes 900.
  • FIG. 11 is a schematic block diagram of a wireless communication device 1100 (e.g., the WCD 502) according to some embodiments of the disclosed subject matter.
  • the wireless communication device 1100 includes one or more processors 1102 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 1104, and one or more transceivers 1106 each including one or more transmitters 1108 and one or more receivers 1110 coupled to one or more antennas 1112.
  • the transceiver(s) 1106 includes radio-front end circuitry connected to the antenna(s) 1112 that is configured to condition signals communicated between the antenna(s) 1112 and the processor(s) 1102, as will be appreciated by on of ordinary skill in the art.
  • the processors 1102 are also referred to herein as processing circuitry.
  • the transceivers 1106 are also referred to herein as radio circuitry.
  • the functionality of the wireless communication device 1100 e.g., functionality of the WCD 502 or UE described above may be fully or partially implemented in software that is, e.g., stored in the memory 1104 and executed by the processor(s) 1102. Note that the wireless communication device 1100 may include additional components not illustrated in FIG.
  • one or more user interface components e.g., an input/output interface including a display, buttons, a touch screen, a microphone, a speaker (s), and/or the like and/or any other components for allowing input of information into the wireless communication device 1100 and/or allowing output of information from the wireless communication device 1100
  • a power supply e.g., a battery and associated power circuitry
  • a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the wireless communication device 1100 according to any of the embodiments described herein is provided.
  • a carrier comprising the aforementioned computer program product is provided.
  • the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).
  • FIG. 12 is a schematic block diagram of the wireless communication device 1100 according to some other embodiments of the disclosed subject matter.
  • the wireless communication device 1100 includes one or more modules 1200, each of which is implemented in software.
  • the module(s) 1200 provide the functionality of the wireless communication device 212 (e.g., functionality of the WCD 502 or UE) described herein.
  • any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses.
  • Each virtual apparatus may comprise a number of these functional units.
  • These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processors (DSPs), special-purpose digital logic, and the like.
  • the processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc.
  • Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein.
  • the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the disclosed subject matter.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Un dispositif de communication sans fil effectue des opérations consistant à déterminer un domaine d'un point d'accès de service associé au domaine, à obtenir ou à calculer un identifiant caché correspondant au dispositif de communication sans fil sur la base d'au moins un identifiant associé au dispositif de communication sans fil et d'un identifiant de domaine du domaine, et à transmettre un message d'accès de service au point d'accès de service, le message d'accès de service comprenant l'identifiant caché. De cette manière, des points d'accès de service sont séparés en différents domaines, garantissant que des identifiants cachés (par exemple, SUCI) générés pour un domaine ne peuvent pas être résolus par des points d'accès de service à partir d'un autre domaine, empêchant ainsi des points d'accès de service compromis d'un domaine d'utiliser la fonction de résolution d'identité en tant que service de traduction à usage général.
PCT/IB2023/054020 2022-05-16 2023-04-20 Identification d'abonnement dans des réseaux WO2023223118A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CNPCT/CN2022/093014 2022-05-16
CN2022093014 2022-05-16

Publications (1)

Publication Number Publication Date
WO2023223118A1 true WO2023223118A1 (fr) 2023-11-23

Family

ID=86328870

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2023/054020 WO2023223118A1 (fr) 2022-05-16 2023-04-20 Identification d'abonnement dans des réseaux

Country Status (1)

Country Link
WO (1) WO2023223118A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200296660A1 (en) * 2018-01-15 2020-09-17 Telefonaktiebolaget Lm Ericsson (Publ) Network Function Instance Selection
US20220104009A1 (en) * 2019-01-18 2022-03-31 Fuji Corporation A method for establishing a secure connection between a ue and a network, a user equipment and a communication system

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200296660A1 (en) * 2018-01-15 2020-09-17 Telefonaktiebolaget Lm Ericsson (Publ) Network Function Instance Selection
US20220104009A1 (en) * 2019-01-18 2022-03-31 Fuji Corporation A method for establishing a secure connection between a ue and a network, a user equipment and a communication system

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on enhanced support of non-public networks (Release 17)", 30 October 2020 (2020-10-30), XP051949928, Retrieved from the Internet <URL:https://ftp.3gpp.org/tsg_sa/WG2_Arch/Latest_SA2_Specs/Latest_draft_S2_Specs/23700-07-110.zip 23700-07-110rm.docx> [retrieved on 20201030] *
3GPP TS 33.501
3GPP TS 33.503

Similar Documents

Publication Publication Date Title
US10681545B2 (en) Mutual authentication between user equipment and an evolved packet core
US20200153830A1 (en) Network authentication method, related device, and system
US10631162B2 (en) Method and apparatus to perform device to device communication in wireless communication network
US11582602B2 (en) Key obtaining method and device, and communications system
US11974132B2 (en) Routing method, apparatus, and system
US20190007835A1 (en) Profile installation based on privilege level
JP2022078325A (ja) 第１のネットワーク装置及び第１のネットワーク装置のための方法
EP3883279A1 (fr) Procédé de communication et produit associé
US20200187000A1 (en) Systems and methods for using gba for services used by multiple functions on the same device
US20240080316A1 (en) Methods and apparatus for provisioning, authentication, authorization, and user equipment (ue) key generation and distribution in an on-demand network
US20220303767A1 (en) User Equipment Authentication and Authorization Procedure for Edge Data Network
WO2019001713A1 (fr) Procédé d&#39;authentification d&#39;un dispositif radio à longue portée
WO2016095698A1 (fr) Procédé, dispositif et système pour acquérir une adresse d&#39;un serveur d&#39;applications
WO2023223118A1 (fr) Identification d&#39;abonnement dans des réseaux
CN115942305A (zh) 一种会话建立方法和相关装置
US20240236675A9 (en) User Equipment Authentication and Authorization Procedure for Edge Data Network
US20240137764A1 (en) User Equipment Authentication and Authorization Procedure for Edge Data Network
US11968530B2 (en) Network authentication for user equipment access to an edge data network
WO2023185513A1 (fr) Procédé de communication, appareil et système
WO2024092624A1 (fr) Procédé et dispositif de transfert de clé de chiffrement pour des utilisateurs itinérants dans des réseaux de communication
WO2024032226A1 (fr) Procédé de communication et appareil de communication
WO2022237838A1 (fr) Procédé de communication et dispositif de communication
WO2023010576A1 (fr) Procédures d&#39;authentification d&#39;identification de client de facilitateur de périphérique
WO2023141945A1 (fr) Mécanisme d&#39;authentification pour accès à un réseau de données de périphérique basé sur tls-psk
WO2024094319A1 (fr) Premier nœud, deuxième nœud, troisième nœud, quatrième nœud et procédés exécutés par ceux-ci pour gérer l&#39;enregistrement du deuxième nœud

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23721786

Country of ref document: EP

Kind code of ref document: A1