Privacy indicators for controlling authentication requests

Abstract

This document provides techniques for providing privacy features in communication systems. [Solution] A message equipped with a privacy indicator may be provided from a user device to an element or function in a communication network, where the privacy feature for processing the message is determined based on the privacy indicator. The message may comprise an attach request comprising a subscription identifier relating to a subscriber associated with the user device, and the privacy indicator comprises a flag indicating whether the subscription identifier in the attach request is privacy-protected.

Description

Technical Field

[0001] This application claims priority to U.S. Provisional Patent Application No. 62 / 502,266, entitled "Privacy Indicator for Controlling Authentication Requests," filed on May 5, 2017, the disclosure of which is hereby incorporated by reference in its entirety.

[0002] This field generally relates to communication systems, and more particularly, but not exclusively, to security within such systems.

Background Art

[0003] This section presents aspects that may be helpful in facilitating a better understanding of the present invention. Accordingly, the description of this section should be read from this perspective and should not be understood as an admission as to what is included or not included in the prior art.

[0004] The 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. The next-generation technology, i.e., the fifth generation (5G) technology, is intended to be used not only for human interaction but also for machine-type communication in so-called Internet of Things (IoT) networks.

[0005] While 5G networks are intended to enable a large number of IoT services (e.g., a very large number of devices with limited capacity) 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 intended to provide improved wireless Internet access to mobile devices.

[0006] In an exemplary communication system, user equipment such as a mobile terminal (subscriber) (5G UE in a 5G network, or more broadly, UE) communicates over a radio interface with a base station or access point called a gNB in ​​a 5G network or an eNB (Evolved Node B) in an LTE network. An access point (e.g., gNB / eNB) is exemplary part of the access network of a communication system. For example, in a 5G network, the access network is called the 5G system and is described in the 5G Technical Specification (TS) 23.501, V0.4.0, titled "Technical Specification Group Services and System Aspects; System Architecture for the 5G System," whose disclosure is incorporated herein by reference in its entirety. In an LTE network, the access network is an Evolved Universal Terrestrial Radio Access Network (E-UTRAN). Generally, an access point (e.g., gNB / eNB) provides access to the core network (CN) to the UE, which in turn provides access to other UEs and / or data networks such as the packet data network (e.g., the Internet) to the UE.

[0007] Privacy is a critical consideration in any communications system. Privacy is broadly addressed in the 5G Technical Report (TR) 33.899, V1.1.0, entitled “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on the security aspects of the next generation system (Release 14),” whose disclosure is incorporated herein in its entirety by reference. In detail, TR33.899 identifies subscription (UE) privacy as one of the most important security areas to address in 5G networks. [Prior art documents] [Non-patent literature]

[0008] [Non-Patent Document 1] 5G Technical Specification (TS) 23.501, V0.4.0, "Technical Specification Group Services and System Aspects; System Architecture for the 5G System" [Non-Patent Document 2] 5G Technical Report (TR) 33.899, V1.1.0, “3rd Generation Partnership Project;Technical Specification Group Services and System Aspects;Study on the security aspects of the next generation system(Release 14)” [Non-Patent Document 3] SA2 TS23.305 [Non-Patent Document 4] 3GPP TS29.272 (Section 8: "User identity to HSS resolution"), "3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Evolved Packet System (EPS); Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol (Release 14)" [Non-Patent Document 5] SA3 TS33.899 [Overview of the project] [Means for solving the problem]

[0009] An exemplary embodiment provides one or more privacy indicators for controlling authentication requests in a communication system.

[0010] For example, in one embodiment, the method comprises, in an element or function in a communication network, receiving a message from a user device of the communication network that includes one or more privacy indicators, and determining one or more privacy features for processing the message based on the one or more privacy indicators.

[0011] The message may include an attach request that includes a subscription identifier for a subscriber of a communication network associated with the user device, and one or more privacy indicators may include flags indicating whether the subscription identifier in the attach request is private. The private subscription identifier may include at least a portion of the subscriber's persistent subscription identifier.

[0012] In another embodiment, the method comprises determining one or more privacy features supported by the communication network in an element or function of the communication network; generating a message in the element or function of the communication network that includes one or more privacy indicators selected based on the determined one or more privacy features; and transmitting the generated message that includes one or more privacy indicators from the element or function of the communication network to a user device of the communication network.

[0013] One or more privacy features may have the capability of elements or functions in the communications network to handle privately protected subscription identifiers.

[0014] In another embodiment, the method comprises determining one or more privacy features for processing a message at a user device in a communication network, adding one or more privacy indicators to the message based on the determined one or more privacy features, and transmitting the message having one or more privacy indicators from the user device to an element or function in the communication network.

[0015] The message may include an attach request that includes a subscription identifier for a subscriber of a communication network associated with the user device, and one or more privacy indicators may include flags indicating whether the subscription identifier in the attach request is privacy-protected.

[0016] In another embodiment, the method comprises, in a user device of a communication network, receiving a message from an element or function in the communication network that includes one or more privacy indicators, and using the one or more privacy indicators to determine one or more privacy features supported by the communication network.

[0017] One or more privacy indicators may include an indication of whether a communication network is configured to handle privacy-protected subscription identifiers. The method may further include refraining from sending an attach request to an element or function in the communication network in response to one or more privacy indicators indicating that the communication network is not configured to handle privacy-protected subscription identifiers.

[0018] These and other techniques described herein are applicable to various communication networks, but are particularly suitable for 5G and next-generation communication networks.

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

Brief Description of the Drawings

[0020] [Figure 1] A diagram showing a communication system in an exemplary embodiment. [Figure 2] A diagram showing in more detail a server location determination function and a home subscriber server in an exemplary embodiment. [Figure 3] A diagram showing a message flow regarding a user equipment authentication procedure for an LTE network in an exemplary embodiment. [Figure 4] A diagram showing a message flow regarding a user equipment authentication procedure for a 5G network in an exemplary embodiment. [Figure 5] A diagram showing a message flow regarding a user equipment authentication procedure for a hybrid LTE / 5G network in an exemplary embodiment. [Figure 6] A diagram showing a message flow regarding a user equipment authentication procedure for a 5G network in another exemplary embodiment. [Figure 7] This figure shows the message flow for a user device accessing a 5G network via non-3GPP access and authentication in an exemplary embodiment. [Modes for carrying out the invention]

[0021] Embodiments are illustrated herein, along with exemplary communication systems and associated techniques, for managing authentication requests in a manner that protects the privacy of user subscription identification. However, it should be understood that the claims are not limited to the specific 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, while embodiments are illustrated in the context of wireless cellular systems utilizing 3GPP system elements such as LTE Evolutionary Packet Core (EPC) and 3GPP Next Generation Systems (5G), the disclosed embodiments can be adapted in a straightforward manner to a wide variety of other types of communication systems, including but not limited to WiMAX systems and Wi-Fi systems.

[0022] As mentioned earlier, the privacy of subscription identifiers has been a critical issue for 2G / 3G / 4G networks when communicating over a wireless interface between user devices and network access points. Efforts have been made to address this critical issue in 5G networks. The need to address these privacy requirements is recognized even when down bidding attacks (for example, an attacker impersonating a user device to negotiate a lower security capability with a network access point) are inevitable and could force 5G UEs to attach to lower-generation networks.

[0023] TR33.899, referenced above, describes several solutions for providing privacy on wireless interfaces, which fall into the following three solution classes: 1) A pseudonym solution based on a symmetric cryptographic system, which requires the UE's home subscriber server / function on the home network to map a changing pseudonym to the UE's persistent subscription identifier; 2) Encryption of the UE's persistent subscription identifier using the home network operator's public key; and 3) Encryption of the UE's persistent subscription identifier using the Serving Network Operator's public key. It is generally possible to group them as follows.

[0024] Note that in one example, the International Mobile Subscriber Identification Number (IMSI) is the UE's Persistent Subscription Identifier (Subscriber Identifier). In one embodiment, the IMSI is a fixed 15-digit number consisting of a 3-digit Mobile Country Code (MCC), a 3-digit Mobile Network Code (MNC), and a 9-digit Mobile Station Identification Number (MSIN).

[0025] Furthermore, it should be noted that in LTE networks, the home subscriber server / function is called a home subscriber server (HSS), and in 5G networks, it is called a user data management (UDM), which may include authentication and security functions (AUSF) and authentication credential repository and processing functions (ARPF) as part of its UDM functionality.

[0026] Several exemplary embodiments are described herein in terms of a second solution class (i.e., home network public key-based solutions), but alternative embodiments may be implemented with respect to the other two solution classes. See SA2 TS23.502 and SA3 TS33.899, whose disclosures are incorporated herein by reference in their entirety.

[0027] In a home network public key-based solution, the home operator provides its public key to all home network subscribers. The home network subscribers use it to encrypt subscriber identification, which is, for example, the MSIN portion of the IMSI. Only the MSIN portion needs to be encrypted because the MNC+MCC is required by the serving network to route to the correct home network. Only the home HSS can decrypt its messages, as it possesses the private key corresponding to the public key. Once the IMSI is identified, the HSS / AuC (where AuC is the authentication center portion of the HSS) will create an authentication vector (AV) based on a separate, shared root key K between the user (subscriber) and the HSS / AuC. Similarly, in a 5G network, a UDM / ARPF creates the AV requested via the AUSF. The AUSF and UDM may be juxtaposed for optimization reasons.

[0028] An operator may have multiple HSS implementations in his network, allowing him to manage separate sets of users in different HSS / UDMs. For multiple HSSs, a Server Location Function (SLF) may be implemented ahead of the set of HSSs. Note that the SLF may also be called a Subscriber Location Function. The SLF analyzes user authentication requests received from the MME / AMF and routes them to the correct HSS.

[0029] As a simple example, the operation of SLF is described in 3GPP TS29.272 (Section 8: "User identity to HSS resolution"), titled "3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Evolved Packet System (EPS); Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol (Release 14)," whose disclosure is incorporated herein by reference in its entirety. SLF provides User Identity (IMSI)-to-HSS resolution using a locally maintained subscriber profile database and routes Diameter messages containing user authentication requests as a Diameter proxy to a selected HSS. Note that in 5G, similar functionality is still required if the 5G core network protocol differs from Diameter, for example, by using an HTTP proxy. In the following description, it is assumed that SLF covers both 4G-based DRA (Diameter Routing Agent) solutions or any other proxy-related solutions, depending on the protocol decision regarding the 5G core network.

[0030] It is recognized herein that when a home operator uses an SLF to split a set of subscribers, the SLF must first evaluate the received identifier. Therefore, in a 5G network where persistent subscriber identification (e.g., IMSI) is encrypted by one of the methods, the SLF must take over the decryption of the MSIN portion of the IMSI. Furthermore, the SLF must maintain a database of all subscriber profiles along with routing information; that is, the profile must map the subscriber's persistent identification (e.g., IMSI) to one of the HSSs in the network and forward the authentication request after decrypting the received (encrypted) IMSI. Therefore, it is advantageous to perform the decryption of the encrypted IMSI in the SLF rather than in the HSS. Hence, instead of the HSS storing the secret key, the SLF now needs to store and use the network secret key. The SLF resides in the home operator's domain and is considered trustworthy. Generally, SLFs can be assumed in large operator networks. The use of SLF simplifies new privacy management regarding HSS / UDM in 5G networks to the point where the HSS / UDM remains completely unchanged to protect the subscription identifier on the radio interface. However, SLF still requires further functionality in decrypting encrypted IMSI and then performing IMSI-to-HSS resolution.

[0031] Accordingly, the exemplary embodiments described herein address the problem of how an HSS / UDM or SLF can efficiently handle a newly introduced privacy feature, namely, the requirement that received attach requests must first be decrypted. If this is not addressed, the HSS / UDM or SLF will waste computational resources by receiving requests and attempting to process them.

[0032] Privacy depends on country-specific regulations, and therefore, HSS / UDM or SLF must be implemented to handle both cases of requests regarding authentication vectors, i.e., to handle or forward "normal" attach requests when the 5G UE does not enforce privacy, or to handle "privacy" attach requests.

[0033] In a first exemplary embodiment, the 5G UE adds an identification privacy flag (i.e., a privacy indicator) to indicate that the MSIN is provided in an encrypted form if it wishes to protect its privacy.

[0034] It should be understood that privacy indicators can be "explicit" privacy indicators, such as flags or fields, but can also be "implicit" privacy indicators. An implicit privacy indicator means that the privacy feature is communicated by the UE to the network element / function via the algorithm used to encrypt the message. Thus, the network element / function receiving the message from the UE is informed about the privacy feature by the fact that the message is encrypted using a particular encryption algorithm. This also applies to the NULL encryption scheme. In the NULL encryption scheme, the input is equal to the output, and the SUPI (Subscription Permanent Identifier of the UE) is not encrypted, i.e., format-preserved. It is possible to interpret this as the SUPI (or IMSI) always being encrypted, but NULL encryption is used when privacy is not "on" at all. Thus, the privacy indicator is implicitly present in the algorithm scheme used (e.g., NULL encryption or the algorithm that actually encrypts the message).

[0035] It may be suggested that the HSS or SLF would resolve the request and, if encrypted, would deduce after the first attempt to decrypt it, even without this privacy indicator. However, one important reason to explicitly display such an indication is that it saves processing time and requires fewer processing resources. For this reason, in this first exemplary embodiment, the SLF can decide what to do by looking at this flag. If not set, the SLF assumes that the provided IMSI is unencrypted, performs IMSI-to-HSS resolution, and forwards it to the correct HSS / UDM, i.e., compatibility with 4G operation is maintained. If the flag is set, the SLF recognizes that the provided IMSI is encrypted, decrypts the MSIN portion using the network secret key to form a truly unencrypted IMSI, performs IMSI-to-HSS resolution, and then forwards the authentication request to the correct HSS / UDM. If the SLF is not used, the same principle can be used by the HSS / UDM. In other words, the HSS / UDM must first check whether the 5G UE has set a flag, and then determine whether decryption is required.

[0036] This first exemplary embodiment can be applied to a 5G UE attaching to a 5G core network (CN) via a 5G RAN (Radio Access Network). However, 3GPP has identified that, as an immediate deployment scenario, a 5G UE should attach to a 4G CN via a 5G RAN. If the UE sets indicators, the 4G CN will need to be enhanced to understand the identification privacy flag or other privacy indicators.

[0037] From a network architecture perspective for operators with evolving 4G to 5G networks, both 4G and 5G access and core networks need to be supported for a considerable period of time. This means that the current 4G HSS needs to be supported while supporting the new 5G HSS functionality for decrypting encrypted MSINs. In some embodiments, having an SLF that can identify and decrypt encrypted MSINs before routing authentication requests to the HSS helps manage the coexistence of 4G and 5G cores in the operator network. Strengthening the SLF to support the new identification 5G privacy feature is more advantageous than strengthening the HSS. If the HSS is extended, in a large network with multiple HSSs, all HSSs need to be updated along with the ability to decrypt encrypted MSINs. This can be more cumbersome to handle than solving the problem in a single central node (e.g., the SLF). Advantageously, in the first exemplary embodiment, a down-bid attack in 5G (to 4G) would not be beneficial if the same feature is also deployed in 4G, thereby using a strengthened SLF to implement this feature.

[0038] In a second exemplary embodiment, to instruct the 5G UE that the network can handle privacy-protected identifiers, another privacy indicator is provided, which the operator may decide to add to the Network Master Information Block (MIB) / System Information Block (SIB) broadcast, for example, a flag indicating that privacy is expected, can be handled, or desired. If this indicator is not transmitted, it is left to the policy implemented / configured by the 5G UE whether or not to attach to the network in the first place. The indicator on the 4G / 5G network side will then indicate country / region-specific regulatory needs, i.e., whether to turn privacy on or off. While the UE is roaming in the destination network, UE authentication requests from the destination network are forwarded to the home network, and an identification privacy indicator for this (as described in the first exemplary embodiment above) is described, but it should be noted that it also needs to be adapted for the serving network. The MME / SEAF (SEAF being the security anchor function) must handle the enhanced initial attach message from the UE, form a UE authentication request message, and route it to the home network to request AV. If the subscription identifier is encrypted, the size of the message field for the encrypted IMSI may differ from today's 4G IMSI field (depending on the chosen solution class).

[0039] Furthermore, it should be noted that the destination network may also indicate its availability and, where applicable, whether it will use privacy. This information can be broadcast, for example, as part of a SIB or other information block, or sent as an explicit request message to each UE.

[0040] In a third exemplary embodiment, the UE is configured to manage a privacy indicator that can be configured to prevent the 5G UE from responding to IMSI paging. Therefore, if the UE wishes to attach to the network and the network requests true identification of the UE, the privately configured 5G UE, which is configured to have this privacy indicator, will not respond.

[0041] Given the privacy indicators described above, a wide variety of network configurations can be employed to implement them. Figures 1-7 illustrate some of these network configurations. However, it should be noted that embodiments are not limited to the network configurations illustrated here or otherwise described below. Figure 1 shows a communication system 100 in which an exemplary embodiment is implemented. It should be understood that the elements shown in communication system 100 are intended to represent the main functions provided within the system, such as UE access functions, mobility management functions, serving gateway functions, and others. For this reason, the blocks drawn in Figure 1 refer to specific elements in LTE and 5G networks that provide the main functions. However, other network elements may be used to implement some or all of the main functions represented. It should also be understood that not all functions of an LTE or 5G network are shown in Figure 1. Rather, functions that facilitate the explanation of the exemplary embodiment are represented.

[0042] Accordingly, as shown, the communication system 100 includes a user equipment (UE) 102 that communicates with an access point (eNB / gNB) 104 via a radio interface 103. The UE 102 may be a mobile station, such a mobile station may comprise, for example, a mobile phone, a computer, or any other type of communication device. In an LTE-V2X implementation, one or more UEs may be deployed in a given vehicle. Accordingly, as used herein, the term “user equipment” is intended to be interpreted broadly to encompass a variety of different types of mobile stations, subscriber stations, or, more generally, communication devices, including, for example, a combination of a laptop or other device (e.g., a vehicle) with a data card inserted. Such communication devices are also intended to encompass devices commonly referred to as access terminals.

[0043] In one embodiment, the UE102 consists of a general-purpose IC card (UICC) and a mobile device (ME). The UICC is the user-dependent part of the UE and houses at least one Universal Subscriber Identity Module (USIM) and appropriate application software. The USIM securely stores an International Mobile Subscriber Identification Number (IMSI) number and a key associated with the IMSI, which is used to identify and authenticate subscribers accessing the network. The ME is the user-independent part of the UE and houses terminal device (TE) functions and various mobile terminal (MT) functions.

[0044] Access point 104 is, exemplary, part of the access network of communication system 100. Such an access network may comprise, for example, an E-UTRAN or 5G system (or hybrid) having multiple 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, they may be implemented in the same physical network element, such as a base station router or a femtocellular access point.

[0045] In this exemplary embodiment, access point 104 is operably coupled to a mobility management function 106. In an LTE network, this function is typically implemented by a mobility management element (MME), while in a 5G network, it is implemented by an access and mobility management function (AMF). Although not explicitly shown, SEAF can be implemented using an AMF that connects the UE to mobility management. As used herein, a mobility management function is an element or function in the CN portion of a communication system that manages, among other things, access and authentication operations with the UE (through access point 104) within the network operation.

[0046] In this exemplary embodiment, the MME / AMF 106 is operably coupled to the SLF 107. In the exemplary embodiment, the SLF 107 is configured as described above to respond to one or more privacy indicators set in a message received by the SLF 107. As described above, the SLF 107 may, depending on one or more privacy indicators, decrypt subscriber identification or simply forward encrypted information to the appropriate home network of the UE 102. For this purpose, as shown, the SLF 107 is operably coupled to a plurality of HSS / UDM 108-1, 108-2, ..., 108-N. These HSS / UDMs represent the home networks of UEs that may be attached to the communication system 100. The SLF 107 is configured to provide UE information to the appropriate HSS / UDM 108.

[0047] Furthermore, the access point 104 is operably coupled to a serving gateway function 110 (e.g., a serving gateway (SGW) in an LTE network, and a session management function (SMF) in a 5G network), which is operably coupled to a packet data network (PDN) gateway (PGW) 112. The PGW 112 is operably coupled to the packet data network, e.g., the internet 114. The MME / AMF 106 and SLF 107 may be considered part of the CN. The MME / AMF 106 and SLF 107 may also be part of the serving network. Further normal operation and functionality of such network elements are not described here, as they may be found in appropriate 3GPP LTE or 5G literature and are not the focus of this exemplary embodiment.

[0048] This particular arrangement of system elements is merely an example, and it should be recognized that further or alternative elements of other types and arrangements may be used to implement the communication system in other embodiments. For example, in other embodiments, system 100 may include authentication elements and other elements not explicitly shown herein.

[0049] Therefore, the configuration in Figure 1 is merely one exemplary configuration of a wireless cellular system, and numerous alternative configurations of system elements may be used. For example, although only a single UE, eNB / gNB, MME / AMF, SLF, SGW / SMF, and PGW element is shown in the embodiment of Figure 1, this is only for the sake of simplicity of explanation. A given alternative embodiment may, of course, include a greater number of such system elements, as well as further or alternative elements of the types commonly associated with conventional system implementations.

[0050] Furthermore, while Figure 1 illustrates system elements as individual functional blocks, it should be noted that the various subnetworks that make up a 5G network are divided into so-called network slices. A network slice (network partition) comprises a set of functionalities (i.e., a functional chain) for each corresponding service type that uses Network Functionality Virtualization (NVF) on a common physical infrastructure. Network slices are instantiated as needed for a given service, e.g., eMBB services, large-scale IoT services (e.g., V2X services), and mission-critical IoT services. Thus, a network slice or functional is instantiated when an instance of that network slice or network functional is created. In some embodiments, this involves installing the network slice or functional on one or more host devices of the underlying physical infrastructure, or otherwise running it on such host devices. UE102 is configured to access one or more of these services via eNB / gNB104.

[0051] Figure 2 shows a more detailed diagram of the SLF107 and one HSS / UDM108 in an exemplary embodiment. Each HSS / UDM108 (108-1, 108-2, ..., 108-N) in Figure 1 can be configured as shown in Figure 2. The SLF107 comprises a processor 200 coupled to memory 202 and interface circuitry 204. The processor 200 of the SLF107 includes an authentication processing module 210, which may be at least partially implemented in the form of software executed by the processor 200. The authentication processing module 210 performs the authentication operations of the processes described herein, in conjunction with the following figures. The memory 202 of the SLF107 includes an authentication storage module 212 that stores authentication and associated data generated during authentication operations, or otherwise used.

[0052] The HSS / UDM108 comprises a processor 220 coupled to memory 222 and interface circuitry 224. The processor 220 of the HSS / UDM108 includes an authentication processing module 230, which may be at least partially implemented in the form of software executed by the processor 220. The authentication processing module 230 performs the authentication operations of the processes otherwise described herein, as described in conjunction with the following figures. The memory 222 of the HSS / UDM108 includes an authentication storage module 232 that stores authentication data and related data generated during or otherwise used in the authentication operations.

[0053] The SLF107 and HSS / UDM108 processors 200 and 220, respectively, may comprise, for example, a microprocessor, an application-specific integrated circuit (ASIC), a digital signal processor (DSP), or other types of processing devices, and parts or combinations of such elements.

[0054] The memories 202 and 222 of the SLF107 and HSS / UDM108, respectively, may be used to store one or more software programs executed by processors 200 and 220, respectively, to implement at least a portion of the functions described herein. For example, the authentication operations and other functions described herein, as described in conjunction with the following figures, may be implemented in a straightforward manner using software code executed by processors 200 and 220.

[0055] Therefore, a given one of the memories 202 or 222 may be considered, more generally, an example of what is referred to herein as a computer program product, or even more generally, a processor-readable storage medium in which executable program code is embodied. Other examples of processor-readable storage media may include, in any combination, disks, or other types of magnetic or optical media. Exemplary embodiments may include products comprising such computer program products or other processor-readable storage media.

[0056] Memory 202 or 222 may more specifically comprise, for example, 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 memory such as flash memory, magnetic RAM (MRAM), phase-change RAM (PC-RAM), or ferroelectric RAM (FRAM). As used herein, the term “memory” is intended to be interpreted broadly and may further, or alternatively, include, for example, read-only memory (ROM), disk-based memory, or other types of storage devices, and parts or combinations of such devices.

[0057] The interface circuits 204 and 224 of the SLF107 and HSS / UDM108, respectively, include, exemplarily, transceivers or other communication hardware or communication firmware that enable the associated system elements to communicate with each other in the manner described herein.

[0058] It is evident from Figure 2 that the SLF107 is configured for communication with the HSS / UDM108, and vice versa, via interface circuits 204 and 224, respectively. This communication involves the SLF107 transmitting data to the HSS / UDM108 and the HSS / UDM108 transmitting data to the SLF107. However, in alternative embodiments, other network elements may be operably coupled between the SLF and the HSS / UDM. As used herein, the term “data” is intended to be interpreted broadly to encompass any type of information that may be transmitted between user equipment and the core network via base station elements, including, but not limited to, identification data, authentication data, control data, audio, video, multimedia, and others.

[0059] It should be noted that the specific arrangement of components shown in Figure 2 is merely an example, and numerous alternative configurations may be used in other embodiments. For example, user equipment and mobility management functions can be configured to incorporate additional or alternative components and to support other communication protocols.

[0060] Furthermore, other system elements such as UE102, eNB / gNB104, MME / AMF106, SGW / SMF110, and PGW112 may each be configured to include components such as a processor, memory, and network interface. These elements do not need to be implemented on separate standalone processing platforms; instead, they can represent different functional parts of a single common processing platform, for example. Such a processing platform may further comprise at least a portion of the eNB / gNB and associated wireless network control functions.

[0061] Figures 3-7 illustrate message flows and network configurations in which one or more of the privacy indicators described above may be implemented. These message flows and network configurations are understood to be illustrative embodiments.

[0062] Figure 3 illustrates a high-level UE authentication procedure 300 in LTE using unencrypted IMSI, SLF, and multiple HSSs, according to one exemplary embodiment.

[0063] More specifically, Figure 3 shows UE302, RAN304, MME306, SLF308, HSS1 310-1, and HSS2 310-2. Although only two HSSs are depicted, any number of HSSs may be implemented according to the embodiments described herein. In step 1 of the UE authentication procedure flow in Figure 3, UE302 sends an Attach Request (IMSI) to MME306 via RAN304. In step 2, MME306 then sends an Authentication Request (IMSI) to SLF308. In step 3, SLF308 selects an HSS based on the IMSI mapping to the HSS. In step 4, SLF308 sends an Authentication Request (IMSI) to the selected HSS, which is HSS1 310-1, as indicated in Figure 3. In step 5, HSS1 310-1 generates an Authentication Vector (AV) based on the root key. In step 6, HSS1 310-1 sends an authentication response (AV) to SLF308, and in step 7, SLF308 sends an authentication response (AV) to MME306. The authentication response may include a random challenge (RAND), an authentication token (AUTN), and a key set identifier (KSI). In step 9, MME306 sends an attach response to UE302 via RAN304.

[0064] Figure 4 illustrates a high-level UE authentication procedure 400 in 5G using encrypted IMSI, SLF, and multiple UDMs. Performing IMSI decryption in the SLF instead of the UDM helps to maintain the core authentication functionality without modification, according to one exemplary embodiment. Where used herein, the acronym EAP refers to Extensible Authentication Protocol, and the acronym AKA refers to Authentication and Key Agreement.

[0065] More specifically, Figure 4 shows UE402, (R)AN404, AMF406, SLF408, AUSF / UDM410-1, and AUSF / UDM410-2. Although only two AUSF / UDMs are depicted, any number of AUSF / UDMs may be implemented according to the embodiments described herein. In step 1 of the UE authentication procedure flow in Figure 4, UE402 sends a registration request (encrypted IMSI) to AMF406 via (R)AN404. Note that by referring to the encrypted IMSI, this can typically refer to the portion of the IMSI that is encrypted, e.g., the MSIN, or all or other portions of the IMSI. In step 2, AMF406 sends an authentication request (encrypted IMSI) to SLF408. Step 3 includes substeps 3a and 3b. In step 3a, SLF408 decrypts the encrypted IMSI. In one embodiment, the SLF408 decrypts the encrypted IMSI using the provisioned certificate. In step 3b, the SLF408 selects an HSS based on the IMSI mapping to the UDM. In step 4, the SLF408 sends an authentication request (IMSI) to the selected UDM, which is AUSF / UDM410-1, as indicated in Figure 4. In step 5, the AUSF / UDM410-1 generates an authentication vector (AV) based on the root key. In step 6, the AUSF / UDM410-1 performs EAP AKA authentication or EAP AKA * Authentication (AKA) * The AKA (which refers to a larger home control) is initiated. In step 7, the AUSF / UDM410-1 sends an Authentication Response (AV) to the SLF408, and in step 8, the SLF408 sends an Authentication Response (AV) to the AMF406. In step 9, the AMF406 sends an Authentication Request to the UE402 via (R)AN404.

[0066] Figure 5 illustrates Procedure 500 for a hybrid UDM and HSS core architecture supporting 4G LTE and 5G networks, according to one exemplary embodiment. IMSI decoding in the SLF helps manage both cores.

[0067] More specifically, Figure 5 shows UE502, gNB504, AMF / MME506, SLF508, AUSF / UDM510-1 and 510-2, and HSS512. Although only two AUSF / UDMs are depicted, any number of AUSF / UDMs may be implemented according to the embodiments described herein.

[0068] In step 1 of the procedure in Figure 5, UE502 sends an attach request (encrypted IMSI) to AMF / MME506 via gNB504. Note that by referring to the encrypted IMSI, this can typically refer to the portion of the IMSI to be encrypted, e.g., the MSIN, or all or other portions of the IMSI. Next, in step 2, AMF / MME506 sends an authentication request (encrypted IMSI) to SLF508. Step 3 includes substeps 3a and 3b. In step 3a, SLF508 decrypts the encrypted IMSI. In one embodiment, SLF508 decrypts the encrypted IMSI using a provisioned certificate. In step 3b, SLF508 selects an HSS based on the IMSI mapping to the HSS. In step 4, SLF508 sends the authentication request (IMSI) to the selected HSS, HSS512, via AUSF / UDM510-1 and 510-2. In step 5, the HSS512 generates an authentication vector (AV) based on the root key. In step 6, the HSS512 sends the authentication response (AV) to the SLF508 via AUSF / UDM510-1 and 510-2, and in step 7, the SLF508 sends the authentication response (AV) to the AMF / MME506. In step 8, the AMF / MME506 sends the attach response to the UE502 via the gNB504.

[0069] Figure 6 illustrates a high-level UE authentication procedure 600 in 5G using encrypted IMSI, SLF, and multiple UDMs, according to an exemplary embodiment. Performing IMSI decryption in the SLF instead of the UDM helps to maintain core authentication functionality without modification.

[0070] More specifically, Figure 6 shows UE602, (R)AN604, AMF606, AUSF608, SLF610, and UDM612-1 and 612-2. Although only two UDMs are depicted, any number of UDMs may be implemented according to the embodiments described herein. In step 1 of the high-level UE authentication procedure flow in Figure 6, UE602 sends a registration request (encrypted IMSI) to AMF606 via (R)AN604. Note that by referring to the encrypted IMSI, this can typically refer to the portion of the IMSI that is encrypted, e.g., the MSIN, or all or other portions of the IMSI. Next, in step 2, AMF606 sends an authentication request (encrypted IMSI) to AUSF608. In step 3, AUSF608 sends an authentication request (encrypted IMSI) to SLF610. In step 3a, SLF610 decrypts the encrypted IMSI. In one embodiment, SLF610 decrypts the encrypted IMSI using the provisioned certificate. In step 3b, SLF610 selects an HSS based on the IMSI mapping to the UDM. In step 4, SLF610 sends an authentication request (IMSI) to the selected UDM, which is UDM612-1, as shown in Figure 6. In step 5, UDM612-1 generates an authentication vector (AV) based on the root key. In step 6, UDM612-1 sends an authentication response (AV) to SLF610, and in step 7, SLF610 sends the authentication response (AV) to AUSF608. In step 8, AUSF608 performs EAP AKA authentication or EAP AKA *Authentication is initiated. In step 9, AUSF608 sends an authentication response to AMF606. In step 10, AMF606 sends an authentication request to UE602 via (R)AN604.

[0071] Figure 7 illustrates a procedure 700 relating to a UE accessing a 5G network via non-3GPP access (WLAN) and authentication, according to an exemplary embodiment. As used herein, the acronym AN refers to the access network, the acronym NAI refers to the network access identifier, and the acronym SUPI refers to the serialized unique product identifier of the UE.

[0072] More specifically, Figure 7 shows UE702, non-3GPP AN704, AMF706, AUSF708, and UDM710. In step 1 of the procedure in Figure 7, UE702 sends a registration request to AMF706 via non-3GPP AN704. In step 2, AMF706 sends an authentication request (NAI,[EAP]) to AUSF708. AUSF708 then specifies the authentication type (e.g., EAP AKA authentication or EAP AKA * Determine authentication and act as an EAP server, using EAP AKA authentication or EAP AKA * Authentication is performed. In step 3, security materials are retrieved from UDM710 based on the NAI. In step 4, AUSF708 sends an authentication response ([EAP]) to AMF706, and AMF706 initiates UE authentication in step 5. As shown, during UE authentication, AMF706 sends authentication requests (SUPI,[EAP]) to AUSF708. Depending on the selected EAP authentication method, several authentication request messages may be requested between UE702 and AUSF708 (via AMF706). If UE authentication is successful, AUSF708 sends an authentication response ([EAP],Key) to AMF706. Key is a security key that may be used by AMF706 to generate security keys specific to the Non-Access Layer (NAS), Control Plane (CP), and User Plane (UP).

[0073] The techniques described herein provide one or more privacy indicators for authentication requests in a communication system. For example, such privacy indicators can be controlled (e.g., set) by using one or more bits in an information element or flag transmitted to an element of the communication system. Furthermore, methods and mechanisms are provided to address how the home network of the user equipment and other elements / functions in the core network (e.g., server location functions) can efficiently handle one or more privacy indicators. Advantageously, one or more privacy indicators save computing resources that would otherwise be wasted in one or more network configurations in which the privacy indicators are implemented.

[0074] It should be recognized that the naming of identifiers referred to herein, such as IMSI and others, is for illustrative purposes only. That is, identifiers relating to UEs may have different names or acronyms in different protocols and standards relating to different communication network technologies. For this reason, none of the specific names or acronyms given to these identifiers herein are intended to limit any embodiment in any way.

[0075] As previously indicated, the embodiments are not limited to LTE or 5G contexts, and the disclosed techniques can be adapted in a straightforward manner to a wide variety of other communication system contexts, including but not limited to other 3GPP and non-3GPP systems that employ identification (e.g., IMSI or equivalent) in the identification request process.

[0076] The processors, memories, controllers, and other components of user equipment or base station elements of a communication system disclosed herein may include well-known circuits that have been appropriately modified to implement at least a portion of the identification request functions described above.

[0077] As described above, embodiments may be implemented in the form of products comprising one or more software programs executed by processing circuits of user equipment, base stations, or other elements of a communication system. Conventional forms of such circuits are well known to those skilled in the art and are therefore not described in detail herein. Embodiments may also be implemented in one or more ASICs, FPGAs, or other types of integrated circuit devices in any combination. Such integrated circuit devices, and parts or combinations of integrated circuit devices, are examples of “circuits” when the term “circuit” is used herein. A wide variety of other arrangements of hardware and associated software or firmware may be used to implement exemplary embodiments.

[0078] Therefore, it must be emphasized again that the various embodiments described herein are presented only as illustrative examples and should not be construed as limiting the scope of the claims. For example, alternative embodiments may utilize different communication system configurations, user equipment configurations, base station configurations, identification request processes, messaging protocols, and message formats than those described above in the context of the exemplary embodiments. These, and many other alternative embodiments included in the appended claims, will be immediately apparent to those skilled in the art.

Claims

1. In an element or function of a communication network, receiving a message from a user device of the communication network that includes one or more privacy indicators, Determining one or more privacy features for processing a message based on one or more privacy indicators and A method that includes [a certain feature].

2. The method according to claim 1, wherein the message comprises an attach request comprising a subscription identifier relating to a subscriber of a communication network associated with a user device, and one or more privacy indicators comprising a flag indicating whether the subscription identifier in the attach request is privacy-protected.

3. The method according to claim 2, wherein the privacy-protected subscription identifier comprises at least a portion of the subscriber's persistent subscription identifier.

4. The method according to claim 2, wherein determining one or more privacy features for processing a message based on one or more privacy indicators comprises removing privacy protection from a subscription identifier in an attach request in response to a flag indicating that the subscription identifier is privacy protected.

5. The method according to claim 4, wherein an element or function in a communication network includes a server location function (SLF) that uses a subscription identifier to map attach requests to a home subscriber server (HSS) function or a user data management (UDM) function.

6. A privacy-protected identifier encrypted using the public key of a subscriber's home network operator in a communication network, according to claim 2.

7. An apparatus comprising a processor operably coupled to memory and configured to perform the method of claim 1.

8. In a communication network, determining one or more privacy features supported by the communication network, In a communication network element or function, generating a message that includes one or more privacy indicators selected based on one or more determined privacy features, Sending a generated message containing one or more private indicators from an element or function in a communication network to a user device of the communication network. A method that includes [a certain feature].

9. In a user device of a communication network, determining one or more privacy features for processing messages, Adding one or more privacy indicators to a message based on one or more determined privacy features, Sending a message containing one or more privacy indicators from a user device to an element or function in a communication network. A method that includes [a certain feature].

10. In a user device of a communication network, receiving a message containing one or more privacy indicators from an element or function of the communication network, Determining one or more privacy features supported by a communication network using one or more privacy indicators. A method that includes [a certain feature].

Images