Method and apparatus for two-factor authentication

Abstract

This application provides a method and apparatus for secondary authentication. The method includes: a core network function entity obtaining an identity identifier of a first terminal device, the identity identifier of the first terminal device being an identifier of a first network; the core network function entity sending the identity identifier of the first terminal device to an authentication device in a second network, the identity identifier of the first terminal device being used to determine the identity identifier of the second network for secondary authentication of a first user, the identity identifier of the first user being different from the identity identifier of the first terminal device. In the above technical solution, the core network function entity can send the identity identifier of the first terminal device to the authentication device in the second network, and the identity identifier of the first user can be determined through the identity identifier of the first terminal device. The implicit transmission of the identity identifier of the first user can enhance the security protection of the user's identity identifier during the secondary authentication process.

Description

Technical Field

[0001] This application relates to the field of communications, and more specifically, to a method and apparatus for secondary authentication. Background Technology

[0002] With the rapid development of communication technology, in order to meet the diverse needs of users, operators can deploy many network slices in their networks to satisfy the needs of different applications and vertical industries. Before a terminal device is allowed to access the network or network slice, it needs to perform two-way authentication with the network and / or network slice and obtain authorization from the network and / or network slice.

[0003] Currently, the 3rd generation partnership project (3GPP) network can simultaneously support both Level 1 and Level 2 authentication mechanisms. Level 1 authentication is the authentication between the terminal device and the operator's network, while Level 2 authentication is the authentication between the terminal device (or the user using the terminal device) and a third-party network.

[0004] During the secondary authentication process, the third-party network needs to obtain the user's identity identifier. However, this user's identity identifier is usually requested by the operator network from the terminal device and then forwarded to the third-party network. During the entire process of sending the user's identity identifier, there is a risk of leakage. Summary of the Invention

[0005] This application provides a method and apparatus for secondary authentication, which can enhance the security protection of user identity during the secondary authentication process.

[0006] In a first aspect, a method for secondary authentication is provided, comprising: a core network function entity obtaining an identity identifier of a first terminal device, wherein the identity identifier of the first terminal device is an identifier of a first network; the core network function entity sending the identity identifier of the first terminal device to an authentication device in a second network, wherein the identity identifier of the first terminal device is used to determine the identity identifier of the second network for secondary authentication of a first user, wherein the identity identifier of the first user is different from the identity identifier of the first terminal device.

[0007] In the technical solution provided in this application embodiment, the core network function entity sends the identity identifier of the first terminal device to the authentication device in the second network. The identity identifier of the first terminal device is used to determine the identity identifier of the second network for secondary authentication of the first user. This eliminates the need for the core network function entity to directly send the identity identifier of the first user for secondary authentication to the authentication device in the second network. This implicit sending method enhances the security protection of the first user's identity identifier and can protect the first user's identity identifier more efficiently and effectively.

[0008] Furthermore, in the prior art, the identity identifier of the first user is requested by the core network function entity to the first terminal device, and the first terminal device sends the identity identifier of the first user to the core network function entity in the request response. The secondary authentication method provided in this application directly sends the identity identifier of the first terminal device to the authentication device in the second network through the core network function entity. The out-of-band transmission method can save the message used to request the identity identifier of the first user from the first terminal device, thereby improving the efficiency of signaling and data interaction in the network, optimizing the secondary authentication process, optimizing network resources, and reducing the waste of network resources.

[0009] In conjunction with the first aspect, in one possible implementation, the core network function entity sending the identity identifier of the first terminal device to the authentication device in the second network includes: the core network function entity sending a secondary authentication request to the authentication device in the second network, the secondary authentication request including the identity identifier of the first terminal device but not including the identity identifier of the first user; and the method further includes: the core network function entity receiving a secondary authentication response message sent by the authentication device in the second network, the secondary authentication response message being used to instruct the first terminal device and the second network to perform secondary authentication for the first user.

[0010] In conjunction with the first aspect, one possible implementation further includes: the core network function entity sending a first message to the first terminal device, the first message being used to request the identity identifier of the first user; the core network function entity receiving a second message sent by the first terminal device; when the second message does not include the identity identifier of the first user, the core network function entity performing secondary authentication on the first user based on the identity identifier of the first terminal device.

[0011] In this embodiment, the core network function entity needs to request the identity identifier of the first user from the first terminal device. However, the first terminal device may not send the identity identifier of the first user to the core network function entity. The core network function entity can obtain the identity identifier of the first terminal device. In this way, the core network function entity can perform secondary authentication for the first user based on the identity identifier of the first terminal device. By implicitly sending the identity identifier of the first user out of band, the security protection of the first user's identity identifier is enhanced, which can protect the first user's identity identifier more efficiently and effectively. At the same time, it can be compatible with the secondary authentication process of new terminal devices and old terminal devices.

[0012] In conjunction with the first aspect, one possible implementation further includes: before performing secondary authentication on the first user, the core network function entity obtains the capability information of the first terminal device, and the capability information of the first terminal device is used to instruct the core network function entity to perform secondary authentication on the first user based on the identity identifier of the first terminal device.

[0013] In this embodiment, before performing secondary authentication on the first terminal device, the core network function entity sends the capability information of the first terminal device to the core network function. Based on the capability information of the first terminal device, the core network function entity can determine whether it is necessary to request the identity identifier of the first user from the first terminal device. However, the core network function entity can obtain the identity identifier of the first terminal device. Thus, the core network function entity can perform secondary authentication on the first user based on the identity identifier of the first terminal device. By implicitly sending the first user's identity identifier out of band, the security protection of the first user's identity identifier is enhanced, enabling more efficient and effective protection of the first user's identity identifier. Simultaneously, it is compatible with the secondary authentication process of both new and old terminal devices.

[0014] Furthermore, the secondary authentication method provided in this application embodiment can save the message used to request the identity identifier of the first user from the first terminal device, thereby improving the efficiency of signaling and data interaction in the network, optimizing the secondary authentication process, optimizing network resources, and reducing the waste of network resources.

[0015] In conjunction with the first aspect, in one possible implementation, the capability information of the first terminal device is carried in the registration request message during the first-level authentication process between the first terminal device and the first network.

[0016] The capability information of the first terminal device is carried outside the secondary authentication process, which can save network resources and improve the utilization rate of existing network resources.

[0017] In conjunction with the first aspect, in one possible implementation, the identity identifier of the first terminal device corresponds to the identity identifier of the second network for secondary authentication of multiple users, wherein the identity identifiers of the multiple users include the identity identifier of the first user, and the method further includes: the core network function entity obtaining a first indication, wherein the first indication is used to determine the identity identifier of the first user from the identity identifiers of the multiple users.

[0018] In conjunction with the first aspect, one possible implementation further includes: the core network function entity selecting a first authentication method for the secondary authentication, wherein the first authentication method is an authentication method supported by both the first terminal device and the authentication device in the second network.

[0019] In this embodiment, the core network function entity selects an authentication method supported by both the first terminal device and the authentication device in the second network, and sends it to the authentication device in the second network as the authentication method negotiated by the first terminal device and the authentication device in the second network. This is equivalent to the core network function entity and the first terminal device completing the authentication algorithm negotiation process, without the need for negotiation between the first terminal device and the authentication device in the second network. This can shorten the message interaction process, reduce latency, and save network resources.

[0020] In conjunction with the first aspect, in one possible implementation, the core network function entity selects a first authentication method for the secondary authentication, comprising: the core network function entity acquiring a first authentication method set and a second authentication method set, wherein the first authentication method set includes an authentication method preferred by the first terminal device, and the second authentication method set includes an authentication method preferred by the authentication device in the second network; the core network function entity determining the first authentication method based on the first authentication method set and the second authentication method set, wherein the first authentication method is an authentication method preferred by both the first terminal device and the authentication device in the second network; and the core network function entity sending the first authentication method to the authentication device in the second network.

[0021] In conjunction with the first aspect, in one possible implementation, the second authentication method set is stored in the core network function entity, and / or the first authentication method set is stored in the first terminal device and / or the core network function entity.

[0022] In conjunction with the first aspect, one possible implementation further includes: the core network acquiring a first authentication method set and a second authentication method set, wherein the first authentication method set includes the authentication method preferred by the first terminal device, and the second authentication method set includes the authentication method preferred by the authentication device in the second network; when the first authentication method set and the second authentication method set do not overlap, the core network sends the first authentication method set or a second indication to the authentication device in the second network, wherein the second indication is used to instruct the authentication device in the second network to negotiate authentication methods with the first terminal device.

[0023] When the first authentication method set and the second authentication method set do not overlap, by providing the authentication devices in the second network with a list of authentication methods preferred by the first terminal device, the authentication devices in the second network can select authentication methods that they can support, thereby reducing the negotiation and interaction process and latency with the first terminal device.

[0024] Secondly, a method for secondary authentication is provided, comprising: receiving an identity identifier of a first terminal device sent by a core network function entity, wherein the identity identifier of the first terminal device is an identifier of a first network; determining an identity identifier of a first user based on the identity identifier of the first terminal device and a mapping relationship between the identity identifier of the first terminal device and an identity identifier of a second network for secondary authentication of a first user, wherein the identity identifier of the first user is different from the identity identifier of the first terminal device; and performing secondary authentication on the first user based on the identity identifier of the first user.

[0025] In this embodiment, the authentication device in the second network can determine the identity of the first user through the identity identifier of the first terminal device and the mapping relationship between the identity identifier of the first terminal device and the identity identifier of the first user. This eliminates the need for the core network function entity to request the identity identifier of the first user from the first terminal device. The implicit transmission of the identity identifier of the first user can improve the security protection of the identity identifier of the first user and reduce or eliminate the risk of leakage of the user's identity identifier.

[0026] In conjunction with the second aspect, in one possible implementation, receiving the identity identifier of the first terminal device sent by the core network function entity includes: receiving a secondary authentication request sent by the core network function entity, wherein the secondary authentication request includes the identity identifier of the first terminal device but does not include the identity identifier of the first user; performing secondary authentication on the first user based on the identity identifier of the first user includes: sending a secondary authentication response message to the core network function entity, wherein the secondary authentication response message is used to instruct the first terminal device and the second network to perform secondary authentication on the first user.

[0027] In conjunction with the second aspect, in one possible implementation, the identity identifier of the first terminal device corresponds to the identity identifier of the second network for secondary authentication of multiple users, wherein the identity identifiers of the multiple users include the identity identifier of the first user, and the method further includes: receiving a first indication sent by a core network function entity, wherein the first indication is used to determine the identity identifier of the first user from the identity identifiers of the multiple users.

[0028] In conjunction with the second aspect, one possible implementation further includes: receiving a first authentication method sent by a core network function entity, wherein the first authentication method is an authentication method supported by both the first terminal device and the authentication device in the second network; and performing secondary authentication on the first user according to the first authentication method.

[0029] In conjunction with the second aspect, one possible implementation further includes: receiving a first set of authentication methods sent by a core network function entity, the first set of authentication methods including an authentication method preferred by the first terminal device; selecting a second authentication method from the first set of authentication methods, the second authentication method being an authentication method supported by an authentication device in the second network; and performing secondary authentication on the first user according to the second authentication method.

[0030] In conjunction with the second aspect, one possible implementation further includes: receiving a second instruction sent by a core network function entity, the second instruction being used to instruct the authentication device in the second network to negotiate an authentication method with the first terminal device.

[0031] Thirdly, a two-level authentication method is provided, comprising: establishing a mapping relationship between the identity identifier of a first terminal device and the identity identifier of a second network for two-level authentication of a first user, wherein the identity identifier of the first terminal device is the identifier of the first network; sending the identity identifier of the first terminal device to a core network function entity, or sending the identity identifier of the first terminal device and a first indication to the core network function entity, wherein the first indication is used to determine the identity identifier of the first user among the identity identifiers of multiple users for two-level authentication in the second network.

[0032] In conjunction with the third aspect, one possible implementation further includes: before performing secondary authentication on the first user, sending capability information of the first terminal device to the core network function entity, wherein the capability information of the first terminal device is used to instruct the core network function entity to perform secondary authentication on the first user based on the identity identifier of the first terminal device.

[0033] In conjunction with the third aspect, one possible implementation further includes: sending a first set of authentication methods to the core network function entity, wherein the first set of authentication methods includes the authentication method preferred by the first terminal device.

[0034] Fourthly, a method for secondary authentication is provided, comprising: a core network function entity selecting a first authentication method for secondary authentication, wherein the first authentication method is an authentication method supported by both a first terminal device and an authentication device in the second network; and the core network function entity sending the first authentication method to the authentication device in the second network.

[0035] In this embodiment, the core network function entity selects an authentication method supported by both the first terminal device and the authentication device in the second network, and sends it to the authentication device in the second network as the authentication method negotiated by the first terminal device and the authentication device in the second network. This is equivalent to the core network function entity and the first terminal device completing the authentication algorithm negotiation process, without the need for negotiation between the first terminal device and the authentication device in the second network. This can shorten the message interaction process, reduce latency, and save network resources.

[0036] In conjunction with the fourth aspect, in one possible implementation, the core network function entity selects a first authentication method for the secondary authentication, comprising: the core network function entity acquiring a first authentication method set and a second authentication method set, wherein the first authentication method set includes an authentication method preferred by the first terminal device, and the second authentication method set includes an authentication method preferred by the authentication device in the second network; the core network function entity determining the first authentication method based on the first authentication method set and the second authentication method set, wherein the first authentication method is an authentication method preferred by both the first terminal device and the authentication device in the second network.

[0037] In conjunction with the fourth aspect, in one possible implementation, the second authentication method set is stored in the core network function entity, and / or the first authentication method set is stored in the first terminal device and / or the core network function entity.

[0038] In conjunction with the fourth aspect, one possible implementation further includes: the core network function entity acquiring a first authentication method set and a second authentication method set, wherein the first authentication method set includes the authentication method preferred by the first terminal device, and the second authentication method set includes the authentication method preferred by the authentication device in the second network; when the first authentication method set and the second authentication method set do not intersect, the core network function entity sends the first authentication method set or a second indication to the authentication device in the second network, wherein the second indication is used to instruct the authentication device in the second network to negotiate authentication methods with the first terminal device.

[0039] In conjunction with the fourth aspect, in one possible implementation, the core network function entity selects a first authentication method for the secondary authentication, comprising: the core network function entity sending a second authentication method set to a first terminal device, the second authentication method set including authentication methods preferred by authentication devices in the second network; the core network function entity receiving a first authentication method set determined by the first terminal device based on the second authentication method set, the first authentication method set including authentication methods preferred by the first terminal device.

[0040] In conjunction with the fourth aspect, in one possible implementation, the first authentication method set includes multiple authentication methods, including the first authentication method, and the method further includes: the core network function entity determining the first authentication method based on the first authentication method set.

[0041] Fifthly, an apparatus is provided, comprising a module or unit for performing the method of the first aspect or any possible implementation thereof; or the apparatus comprises a module or unit for performing the method of the fourth aspect or any possible implementation thereof.

[0042] A sixth aspect provides an apparatus comprising a module or unit for performing the method of the second aspect or any possible implementation thereof.

[0043] A seventh aspect provides an apparatus comprising a module or unit for performing the method of the third aspect or any possible implementation thereof.

[0044] Eighthly, a communication device is provided, which can be a core network function entity in the above-described method design, or a chip disposed in the core network function entity. The communication device includes: a processor coupled to a memory, which can be used to execute instructions in the memory to implement the method executed by the core network function entity in the first aspect and any possible implementation thereof, or the method executed by the core network function entity in the fourth aspect and any possible implementation thereof. Optionally, the communication device further includes a memory. Optionally, the communication device further includes a communication interface, and the processor is coupled to the communication interface.

[0045] When the communication device is a core network function entity, the communication interface can be a transceiver or an input / output interface.

[0046] When the communication device is a chip configured in a core network function entity, the communication interface can be an input / output interface.

[0047] A ninth aspect provides a communication device, which can be an authentication device in a second network designed in the above method, or a chip disposed in an authentication device in the second network. The device includes: a processor coupled to a memory, configured to execute instructions in the memory to implement the method performed by the access network device in the second aspect and any possible implementation thereof. Optionally, the device further includes a memory. Optionally, the communication device further includes a communication interface, to which the processor is coupled.

[0048] When the communication device is an authentication device in a second network, the communication interface can be a transceiver or an input / output interface.

[0049] When the communication device is a chip in an authentication device configured in a second network, the communication interface can be an input / output interface.

[0050] In a tenth aspect, a communication device is provided, which can be a first terminal device in the above-described method design, or a chip disposed in the first terminal device. The device includes: a processor coupled to a memory, configured to execute instructions in the memory to implement the method executed by the first terminal device in the third aspect and any possible implementation thereof; or, optionally, the communication device further includes a memory. Optionally, the communication device also includes a communication interface, with the processor coupled to the communication interface.

[0051] When the communication device is the first terminal device, the communication interface can be a transceiver or an input / output interface.

[0052] When the communication device is a chip configured in the first terminal device, the communication interface can be an input / output interface.

[0053] Eleventhly, a computer-readable storage medium is provided, wherein instructions are stored therein, which, when executed on a computer, cause the computer to perform any of the methods of the first to fourth aspects and their possible implementations.

[0054] In a twelfth aspect, a computer program product containing instructions is provided, which, when run on a computer, causes the computer to perform any of the methods described in the first to fourth aspects and their possible implementations.

[0055] In a thirteenth aspect, a communication system is provided, which includes the aforementioned core network functional entity, the aforementioned authentication device in the second network, and the aforementioned first terminal device. Attached Figure Description

[0056] Figure 1 This is a schematic diagram of the network system architecture according to an embodiment of this application;

[0057] Figure 2 This is a schematic diagram of the authentication process between the terminal device and the network in an embodiment of this application;

[0058] Figure 3 This is a schematic flowchart of a method for secondary authentication provided in one embodiment of this application;

[0059] Figure 4 This is a schematic flowchart of a secondary authentication method provided in another embodiment of this application;

[0060] Figure 5 This is a schematic flowchart of a secondary authentication method provided in another embodiment of this application;

[0061] Figure 6 This is a schematic flowchart of a secondary authentication method provided in another embodiment of this application;

[0062] Figure 7 This is a schematic flowchart of a secondary authentication method provided in another embodiment of this application;

[0063] Figure 8 This is a schematic flowchart of a secondary authentication method provided in another embodiment of this application;

[0064] Figure 9 This is a schematic flowchart of a secondary authentication method provided in another embodiment of this application;

[0065] Figure 10 This is a schematic flowchart of a secondary authentication method provided in another embodiment of this application;

[0066] Figure 11 This is a schematic flowchart of a secondary authentication method provided in another embodiment of this application;

[0067] Figure 12 This is a schematic flowchart of a secondary authentication method provided in another embodiment of this application;

[0068] Figure 13 This is a schematic structural diagram of a device provided in one embodiment of this application;

[0069] Figure 14 This is a schematic structural diagram of a communication device provided in one embodiment of this application;

[0070] Figure 15 This is a schematic structural diagram of a device provided in another embodiment of this application;

[0071] Figure 16 This is a schematic structural diagram of a communication device provided in another embodiment of this application;

[0072] Figure 17 This is a schematic structural diagram of a device provided in yet another embodiment of this application;

[0073] Figure 18 This is a schematic structural diagram of a communication device provided in another embodiment of this application. Detailed Implementation

[0074] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0075] The technical solutions of this application embodiment can be applied to various communication systems, such as: Global System for Mobile Communication (GSM) system, Code Division Multiple Access (CDMA) system, Wideband Code Division Multiple Access (WCDMA) system, General Packet Radio Service (GPRS), Long Term Evolution (LTE) system, LTE Frequency Division Duplex (FDD) system, LTE Time Division Duplex (TDD) system, Universal Mobile Telecommunication System (UMTS), Worldwide Interoperability for Microwave Access (WiMAX) system, 5th Generation (5G) system or New Radio (NR) system, and future 6th Generation communication systems, etc.

[0076] In various communication systems, the portion operated by the operator can be referred to as the operator network. The operator network can also be called a public land mobile network (PLMN) network, which is a network established and operated to provide land mobile communication services to the public. It is primarily a public network where mobile network operators (MNOs) provide mobile broadband access services to users. The operator network or PLMN network described in this application embodiment can specifically be a network that conforms to the 3rd Generation Partnership Project (3GPP) standard requirements, abbreviated as 3GPP network. Typically, 3GPP networks are operated by operators, including but not limited to 5th-generation (5G) networks, 4th-generation (4G) networks, 3rd-generation (3G) networks, and 2nd-generation wireless telephone technology (2G) networks. For ease of description, this application embodiment will use an operator network (i.e., an MNO network) as an example for illustration.

[0077] As mobile bandwidth access services expand, the MNO's network will also evolve to better support diverse business models and meet the needs of more diverse applications and industries. To provide better and more comprehensive services to more industries, the next-generation network (i.e., the 5G network) has also undergone network architecture adjustments compared to the 4G network. For example, the 5G network splits the Mobility Management Entity (MME) in the 4G network into multiple network functions, including the Access and Mobility Management Function (AMF) and the Session Management Function (SMF).

[0078] Figure 1 The diagram illustrates a network architecture according to an embodiment of this application, taking the service-based 5G network architecture defined during the 3GPP standardization process as an example. Figure 1 As shown, the network architecture can include three parts: terminal equipment, carrier network, and data network (DN).

[0079] The terminal equipment portion includes terminal equipment 110, which can also be referred to as user equipment (UE). In this embodiment, terminal equipment 110 is a device with wireless transceiver capabilities, capable of communicating with one or more core networks (CNs) via access network (AN) 140. Terminal equipment 110 can also be referred to as an access terminal, terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, wireless network equipment, user agent, or user device, etc. Terminal equipment 110 can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; it can also be deployed on water (such as on ships); and it can also be deployed in the air (e.g., on airplanes, balloons, and satellites). Terminal device 110 can be a cellular phone, cordless phone, session initiation protocol (SIP) phone, smartphone, mobile phone, wireless local loop (WLL) station, personal digital assistant (PDA), or a handheld device with wireless communication capabilities, computing device or other device connected to a wireless modem, in-vehicle device, wearable device, drone device or terminal in the Internet of Things, vehicle network, fifth generation (5G) network and any form of terminal in future networks, relay user equipment or terminal in future evolved public land mobile network (PLMN), etc. Among them, relay user equipment can be, for example, a 5G residential gateway (RG). For example, terminal device 110 can be a virtual reality (VR) terminal, an augmented reality (AR) terminal, a wireless terminal in industrial control, a wireless terminal in self-driving, a wireless terminal in remote medical care, a wireless terminal in a smart grid, a wireless terminal in transportation safety, a wireless terminal in a smart city, a wireless terminal in a smart home, etc. This application embodiment does not limit this.

[0080] The operator network may include network exposure function (NEF) 131, network function repository function (NRF) 132, policy control function (PCF) 133, unified data management (UDM) network element 134, application function (AF) 135, authentication server function (AUSF) 136, access and mobility management function (AMF) 137, session management function (SMF) 138, user plane function (UPF) 139, and (radio)access network ((R)AN) 140, etc. In the above-mentioned operator network, the part other than the (radio)access network 140 can be referred to as the core network (CN) part or core network part. For ease of explanation, this application embodiment uses (R)AN 140 as an example for illustration.

[0081] A data network DN 120, also known as a packet data network (PDN), is typically a network located outside the carrier's network, such as a third-party network. A carrier's network can connect to multiple data networks DN 120. Various services can be deployed on a data network DN 120, providing data and / or voice services to terminal devices 110. For example, a data network DN 120 could be a private network in a smart factory. Sensors installed in the workshop of the smart factory can be terminal devices 110. A control server for the sensors is deployed in the data network DN 120, providing services to the sensors. The sensors can communicate with the control server, receive instructions from the control server, and transmit the collected sensor data to the control server according to the instructions. As another example, a data network DN 120 could be an internal office network of a company. Employees' mobile phones or computers can be terminal devices 110, and employees' mobile phones or computers can access information and data resources on the company's internal office network.

[0082] Terminal device 110 can establish a connection with the operator network through an interface (such as N1) provided by the operator network and use data and / or voice services provided by the operator network. Terminal device 110 can also access data network DN 120 through the operator network and use operator services deployed on data network DN 120, and / or services provided by third parties. These third parties can be service providers other than the operator network and terminal device 110, and can provide other data and / or voice services to terminal device 110. The specific form of these third parties can be determined according to the actual application scenario and is not limited here.

[0083] The following is a brief introduction to the network functions in the operator's network.

[0084] Access network RAN ​​140 is a sub-network of the operator network, serving as the implementation system between service nodes and terminal equipment 110 within the operator network. For terminal equipment 110 to access the operator network, it first passes through RAN 140, and then connects to service nodes in the operator network via RAN 140. The access network equipment (RAN equipment) in this application embodiment is a device that provides wireless communication functions for terminal device 110. It can also be referred to as a network device. RAN equipment includes, but is not limited to: next-generation node basestations (gNBs) in 5G systems, evolved node Bs (eNBs) in long-term evolution (LTE), radio network controllers (RNCs), node Bs (NBs), base station controllers (BSCs), base transceiver stations (BTSs), home base stations (e.g., home evolved node Bs, or home node Bs (HNBs)), base band units (BBUs), transmitting and receiving points (TRPs), transmitting points (TPs), small cell equipment (picos), mobile switching centers, or network equipment in future networks. It should be understood that this document does not limit the specific type of access network equipment. In systems employing different wireless access technologies, the names of devices with access network equipment functions may differ. For ease of description, in all embodiments of this application, the apparatus that provides wireless communication function for terminal device 110 is collectively referred to as access network device.

[0085] Access and Mobility Management Function (AMF) 137 (also known as AMF network function or AMF network function entity) is a control plane network function provided by the operator network. It is responsible for access control and mobility management of terminal equipment 110 accessing the operator network, including functions such as mobility state management, assigning temporary user identity identifiers, authenticating and authorizing users.

[0086] The Session Management Function (SMF) 138 (also known as the SMF Network Function or SMF Network Function Entity) is a control plane network function provided by the operator network, responsible for managing the Protocol Data Unit (PDU) sessions of terminal equipment 110. A PDU session is a channel used to transmit PDUs; terminal equipment needs to exchange PDUs with the data network DN 120 through PDU sessions. The SMF Network Function 138 is responsible for establishing, maintaining, and deleting PDU sessions. The SMF Network Function 138 includes session management (such as session establishment, modification, and release, including tunnel maintenance between User Plane Function UPF 139 and Access Network AN 140), selection and control of UPF Network Function 139, service and session continuity (SSC) mode selection, roaming, and other session-related functions.

[0087] User plane function (UPF) 139 (also known as UPF network function or UPF network function entity) is a gateway provided by the operator, serving as the gateway for communication between the operator's network and the data network DN 120. UPF network function 139 includes user plane-related functions such as packet routing and transmission, packet inspection, traffic usage reporting, quality of service (QoS) processing, uplink packet inspection, and downlink packet storage.

[0088] The Unified Data Management Network Element (UDM) 134 (also known as UDM Network Function or UDM Network Function Entity) is a control plane function provided by the operator, responsible for storing information such as the subscriber permanent identifier (SUPI), credential, security context, and subscription data of subscribed users in the operator's network. The SUPI is encrypted during transmission; the encrypted SUPI is called the subscription concealed identifier (SUCI). This information stored by the UDM network function 134 can be used for authentication and authorization of terminal equipment 110 accessing the operator's network. Specifically, the subscribed user in the operator's network can be a user using services provided by the operator's network, such as a user using a China Telecom mobile phone SIM card or a China Mobile mobile phone SIM card. The subscriber's SUPI can be the SIM card number, etc. The credential and security context can be small files containing the SIM card's encryption key or information related to the SIM card's encryption, used for authentication and / or authorization. The aforementioned security context can be data (cookies) or tokens stored on the user's local terminal (e.g., a mobile phone). The subscribed user's subscription data can be the associated services of the mobile phone SIM card, such as the SIM card's data plan or network usage. It should be noted that permanent identifiers, trust certificates, security contexts, authentication data (cookies), and tokens, as well as other authentication and authorization-related information, are not distinguished or limited in this application embodiment for ease of description. Unless otherwise specified, this application embodiment will use security context as an example for description, but this application embodiment is also applicable to authentication and / or authorization information expressed in other ways.

[0089] The Authentication Server Function (AUSF) 136 (also known as the AUSSF Network Function or AUSSF Network Function Entity) is a control plane function provided by the operator, typically used for Level 1 authentication, i.e., authentication between terminal device 110 (the subscriber) and the operator's network. After receiving an authentication request from the subscriber, AUSF Network Function 136 can authenticate and / or authorize the subscriber using the authentication and / or authorization information stored in UDM Network Function 134, or generate the subscriber's authentication and / or authorization information using UDM Network Function 134. AUSF Network Function 136 can then send the authentication and / or authorization information back to the subscriber.

[0090] The Network Open Function (NEF) 131 (also known as NEF Network Function or NEF Network Function Entity) is a control plane function provided by the operator. NEF Network Function 131 securely opens the operator's network to external interfaces for third parties. When SMF Network Function 138 needs to communicate with third-party network functions, NEF Network Function 131 can act as a relay for communication between SMF Network Function 138 and the third-party network entity. As a relay, NEF Network Function 131 can translate the identification information of subscribed users and the identification information of third-party network functions. For example, when NEF Network Function 131 sends a subscribed user's SUPI from the operator's network to a third party, it can translate the SUPI into its corresponding external identity (ID). Conversely, when NEF Network Function 131 sends an external ID (the third party's network entity ID) to the operator's network, it can translate it into a SUPI.

[0091] The Policy Control Function (PCF) 133 (also known as PCF Network Function or PCF Network Function Entity) is a control plane function provided by the operator to provide policies for PDU sessions to the SMF Network Function 138. These policies may include billing-related policies, QoS-related policies, and authorization-related policies.

[0092] The network slice selection function (NSSF) (not shown in the figure) is responsible for determining network slice instances and selecting AMF network function 137, etc.

[0093] Figure 1 Nnef, Nausf, Nnrf, Npcf, Nudm, Naf, Namf, Nsmf, N1, N2, N3, N4, and N6 are interface sequence numbers. The meanings of these interface sequence numbers can be found in the definitions provided in the 3GPP standard protocols, and are not limited here. It should be noted that... Figure 1 The example provided only uses terminal device 110 as the UE. Figure 1 The interface names between the various network functions in this example are merely one example. In a specific implementation, the interface names of this system architecture may be other names, and this application does not impose any specific limitations on them.

[0094] The mobility management network function in this application embodiment can be Figure 1The AMF network function 137 shown can also be other network functions with the aforementioned AMF network function 137 in future communication systems. Alternatively, the mobility management network function in this application can also be a mobility management entity (MME) in long term evolution (LTE), etc.

[0095] For ease of explanation, this embodiment uses Mobility Management Network Function (AMF) network function 137 as an example. Furthermore, AMF network function 137 will be abbreviated as AMF, and terminal device 110 will be referred to as UE. That is, in this embodiment, AMF can be replaced by Mobility Management Network Function, and UE can be replaced by Terminal Device.

[0096] Figure 1 The network architecture shown (such as the 5G network architecture) adopts a service-based architecture and a common interface. Traditional network element functions are decomposed into several self-contained, self-managed, and reusable network function service modules based on network function virtualization (NFV) technology. By flexibly defining the set of service modules, customized network function reconstruction can be achieved, and business processes can be formed externally through a unified service call interface. Figure 1 The network architecture diagram shown can be understood as a service-based 5G network architecture diagram in a non-roaming scenario. In this architecture, different network functions can be combined in an orderly manner as needed according to specific scenario requirements, enabling the customization of network capabilities and services. This allows for the deployment of dedicated networks for different services, realizing 5G network slicing. Network slicing technology enables operators to respond to customer needs more flexibly and quickly, supporting the flexible allocation of network resources.

[0097] Network slicing, simply put, involves dividing an operator's physical network into multiple virtual end-to-end networks. Each virtual network, including its devices, access, transmission, and core network, is logically independent; a failure in one virtual network will not affect other virtual networks. Currently, diverse scenarios present different demands on the 3rd Generation Partnership Project (3GPP) ecosystem, such as billing, policy, security, and mobility requirements. 3GPP emphasizes that network slices should not interfere with each other; for example, a sudden surge in meter reading traffic should not affect normal mobile broadband services. To meet diverse needs and ensure isolation between slices, relatively independent management and operation are required for services, along with tailored service functions and analytical capabilities. Instances of different types of services can be deployed on different network slices, and different instances of the same service type can also be deployed on different network slices.

[0098] A network slice in 5G is a virtual private network composed of a set of network functions and subnetworks. For example, Figure 1 The sub-networks RAN 140, AMF network function 137, SMF network function 138, and UPF network function 139 can form a slice. Figure 1 Each network function is illustrated only in one example; in actual network deployments, there can be multiple, dozens, or even hundreds of each network function or subnetwork. Many network slices can be deployed in a carrier network, each with different performance characteristics to meet the needs of different applications and vertical industries. Carriers can "tailor-make" a slice according to the needs of different vertical industry customers. Carriers can also allow some industry customers to have greater autonomy and participate in some slice management and control functions. Slice-level authentication is a network control function involving industry customers, i.e., authenticating and authorizing end-user access to the slice; this embodiment can be simply referred to as "slice authentication."

[0099] Still with Figure 1For example, when the core network (CN) deploys network slices, and UE 110 needs to access a certain network slice, UE 110 can provide the requested network slice to the core network. The network slice requested by UE 110 can be represented by a set of requested network slices, or it can be represented by requested network slice selection assistance information (requested NSSAI). The network slice set includes one or more network slices. The requested NSSAI is represented by one or more single network slice selection assistance information (S-NSSAI), each S-NSSAI identifying a network slice type. It can also be understood that S-NSSAI identifies a network slice, or it can be understood as the identification information of a network slice. For ease of understanding, in the following description, this application embodiment does not strictly distinguish between "network slice" and "S-NSSAI," and both can be used equally. In this application embodiment, "network slice" can also be called "slice" or "network slice instance," all three having the same meaning, and will be uniformly explained here without further elaboration.

[0100] After UE 110 sends a registration request to the network, the core network functions (such as AMF network function 137 or NSSF network function) comprehensively determine the set of network slices that UE 110 is allowed to access based on UE 110's subscription data, UE 110's requested NSSAI, roaming protocol, and local configuration information. The set of network slices allowed to access can be represented by allowed NSSAIs, where all S-NSSAIs included are S-NSSAIs currently allowed by the operator's network.

[0101] Before being allowed to access a network or network slice, UE 110 needs to undergo two-way authentication with the network and / or network slice and obtain authorization from the network and / or network slice. Currently, in the 5G standard, the authentication and authorization of UE 110 by the network is directly performed by the operator network. This type of authentication and authorization method is called primary authentication.

[0102] With the development of vertical industries and the Internet of Things (IoT), it is foreseeable that data networks DN 120 outside of carrier networks (such as DNs serving vertical industries) will also have authentication and authorization requirements for UE 110 devices accessing these DN 120s. For example, a commercial company provides a gaming platform, offering gaming services to players through a carrier network. On one hand, since the UE 110 used by players accesses the gaming platform through the carrier network, the carrier network needs to authenticate and authorize the UE 110, i.e., Level 1 authentication. The game players are customers of the commercial company, and the commercial company also needs to authenticate and authorize them. If this authentication is based on network slicing, or in other words, authentication is done on a slice-by-slice basis, then this authentication can be called slice authentication, Level 2 authentication, or slice-specific authentication.

[0103] It's important to clarify that both Level 1 and Level 2 authentication refer to the authentication between the UE 110 (or a user using the UE 110) and the network (carrier network or third-party network). For example, Level 1 authentication refers to the authentication between the UE and the carrier network. During the UE 110 registration process, the carrier network performs Level 1 authentication on the UE 110. If the Level 1 authentication is successful, a security context for the UE 110 can be established. On the other hand, Level 2 authentication refers to the authentication between the UE 110 (or the user using the UE 110) and a network outside the carrier network (i.e., a third-party network). The third-party network will notify the carrier network of the Level 2 authentication result so that the carrier network can authorize or deny the UE 110's access to the carrier network serving the third-party network.

[0104] It should be noted that in this embodiment, secondary authentication can also be referred to as secondary authentication for a slice, slice authentication, or authentication of the user (the user using UE 110). Its meaning is that secondary authentication is performed between UE 110 (or the user using UE 110) and a third-party network, and the authentication result will determine whether the operator network authorizes the UE to access the slice. It should also be understood that the method applied to secondary authentication in this embodiment is also applicable to scenarios such as session-based secondary authentication or slice-based secondary authentication, which will not be detailed here.

[0105] Figure 2A schematic diagram of the authentication process between a terminal device and a network is shown. The authentication process includes a primary authentication process and a secondary authentication process. The primary authentication process is the authentication process between the UE and the operator's network, and the secondary authentication process is the authentication process between the user of the UE or a user of the UE and a third-party network. In this embodiment, the description of "the secondary authentication process between the UE and the third-party network" can be understood as the secondary authentication process between a user of the UE and the third-party network. Figure 2 As illustrated, the primary authentication process is the authentication process between UE 210 and core network CN 230, and the secondary authentication process is the authentication process between the user using UE 210 and data network DN 220. Both the primary and secondary authentication processes can be understood as part of the registration process of UE 110. For ease of understanding and description, this embodiment uses the authentication device in DN 220 as an authentication, authorization, and accounting (AAA) server as an example. The AAA server can be represented as AAA-S (AAA server), and the AAA-proxy function (AAA-F) network element can be located in core network CN 230.

[0106] refer to Figure 2 The main steps of the UE 210 registration process can be summarized as follows:

[0107] Step 1: The terminal device sends a registration request to the network to access the network, carrying the terminal device's identity information. For example, UE 210 can send an access request to AMF network function entity 237 in the core network CN 230, carrying UE 210's identity information, such as encrypted identity information SUCI or temporary identity information such as globally unique temporary identifier (GUTI).

[0108] Step 2: The network determines whether to initiate Level 1 authentication between the network and the terminal device based on the identity information sent by the terminal device. For example, AMF network function entity 237 can forward the encrypted identity information SUCI received from UE 210 to UDM network function entity 234. UDM network function entity 234 decrypts the SUCI to restore the true identity information SUPI of UE 210, and then returns the SUPI to AMF network function entity 237. AMF network function entity 237 initiates the Level 1 authentication process between the network and UE 210 based on the true identity SUPI of UE 210.

[0109] Step 3: After successful Level 1 authentication between the terminal device and the network, the network can authorize the terminal device to access the operator's network. For example, after successful Level 1 authentication, AMF network function entity 237 authorizes UE 210 to access the network.

[0110] After steps 1 to 3, the primary authentication process between the terminal device and the network can be considered complete. On the other hand, if the UE sends a temporary identity information (GUTI) in step 1, then in step 2, the AMF checks the validity of the GUTI on the network side. If it is valid, it indicates that the previous primary authentication is still valid, and primary authentication is not necessary.

[0111] Step 4: The network determines whether the terminal device needs further secondary authentication. For example, AMF network function entity 237 determines whether the slice accessed by UE 210 needs further slice authentication (i.e., secondary authentication) based on information from AMF network function entity 237 or UDM network function entity 234.

[0112] Step 5: If the terminal device requires secondary authentication, the network can trigger a secondary authentication process between the terminal device and the data network (DN). For example, when UE 210 requires secondary authentication, AMF network function entity 237 triggers a secondary authentication process between UE 210 and DN 220. This embodiment uses secondary authentication as a slice authentication example. This slice authentication process can be based on the Extensible Authentication Protocol (EAP) standard developed by the Internet Engineering Task Force (IETF) as the basic authentication mechanism. This EAP mechanism has great flexibility and can support dozens of specific EAP authentication methods.

[0113] It should be understood that the terminal device described in this application embodiment needs to perform secondary authentication, which can be understood as a user using the terminal device needing to perform secondary authentication. Taking slice authentication as an example, the need for UE 210 to perform secondary authentication can be understood as a user using UE 210 needing to perform secondary authentication.

[0114] Step 6: The terminal device and the data network complete secondary authentication through multiple rounds of signaling interaction. The data network then notifies the operator network of the secondary authentication result, allowing the operator network to continue executing other processes based on the result, such as the remaining registration process, the termination registration process, or other related processes, which are not listed here. For example, taking slice authentication as an example, when a user using UE 210 performs secondary authentication with DN 220, multiple rounds of signaling interaction are required to complete slice authentication. DN 220 needs to obtain the user identity information subscribed between UE 110 and DN 220, i.e., the identity information of the user using UE 210 mentioned above. For ease of description, this user identity information is referred to as the DN user identity (DUI) in this embodiment. In some embodiments, it can also be referred to as the user ID. The user ID used for secondary authentication is the subscription information between the terminal device and an external network other than the operator network; the operator network may not necessarily have this information. Figure 2 As shown in the example, UE 210 sends the DUI to AMF network function entity 237 in core network CN230. AMF network function entity 237 can forward the DUI to the authentication device in DN 220 (e.g., AAA-S 221 shown in the figure). After successful secondary authentication, the authentication device in DN 220 notifies AMF network function entity 237 of the secondary authentication result. It should be noted that in some embodiments, the DUI information is placed in a message container and sent to AMF, and AMF directly forwards the container to DN, i.e., "transparent transmission". In this case, AMF does not parse the DUI information in the container, that is, AMF does not know the user's DUI information. In addition, in some embodiments, the DUI can be forwarded from AMF network function entity 237 to the authentication device in DN 220 through AAA-F 238. At this point, the primary and secondary authentication processes between the terminal device and the network are completed, and the operator network can continue with other registration processes for the terminal device.

[0115] The secondary authentication process between the terminal device and the data network, as mentioned above, can be based on the EAP authentication mechanism, which supports dozens of specific EAP authentication methods. Different terminal devices may support different or the same EAP authentication methods for the same data network; the same terminal device may support different or the same EAP authentication methods for different data networks; different data networks may support different or the same EAP authentication methods. For a single terminal device, it may support one or more EAP authentication methods; for a single data network, it may support one or more EAP authentication methods. However, secondary authentication between the terminal device and the data network requires the use of an EAP authentication method supported by both the terminal device and the data network. It should be understood that in this embodiment, the EAP authentication method supported by the data network can also be understood as the EAP authentication method supported by the authentication device in the data network; both expressions have the same meaning, and this embodiment does not strictly distinguish between them.

[0116] For example, taking the EAP (EAP-transportlayer security, EAP-TLS) authentication method between the terminal device and the data network as an example, the secondary authentication process between the terminal device and the data network is briefly explained.

[0117] The following diagram illustrates the interaction process between the authentication client and the authentication network. The authentication client (Authenticating Peer) can be understood as... Figure 1 Terminal equipment 110 or Figure 2 In UE 210, the aforementioned authentication network terminal (Authenticator) can be understood as... Figure 1 AMF network function 137 or Figure 2 The AMF 237 is mentioned in the text. The following interactive process only illustrates a portion of the secondary authentication process between the terminal device and the data network, namely the interaction process between the terminal device and the operator network. It should be understood that the secondary authentication process between the terminal device and the data network also includes the interaction process between the operator network and the data network, such as the interaction process between the AMF network function and the AAA server.

[0118] AuthenticatingPeer Authenticator

[0119] EAP-Request /

[0120] Identity

[0121] EAP-Response /

[0122] Identity (MyID)﹣﹥

[0123] ﹤﹣ EAP-Request /

[0124] EAP-Type=EAP-TLS

[0125] (TLS Start)

[0126] EAP-Response /

[0127] EAP-Type=EAP-TLS

[0128] (TLS client_hello)﹣﹥

[0129] ﹤﹣ EAP-Request /

[0130] EAP-Type=EAP-TLS

[0131] (TLS server_hello,

[0132] TLS certificate,

[0133] [TLS server_key_exchange,]

[0134] TLS certificate_request,

[0135] TLS server_hello_done)

[0136] EAP-Response /

[0137] EAP-Type=EAP-TLS

[0138] (TLS certificate,

[0139] TLS client_key_exchange,

[0140] TLS certificate_verify,

[0141] TLS change_cipher_spec,

[0142] TLS finished)﹣﹥

[0143] ﹤﹣ EAP-Request /

[0144] EAP-Type=EAP-TLS

[0145] (TLS change_cipher_spec,

[0146] TLS finished)

[0147] EAP-Response /

[0148] EAP-Type=EAP-TLS﹣﹥

[0149] EAP-Success

[0150] As can be seen from the interaction process between the authentication client and the authentication network described above, based on the EAP-TLS authentication method, four rounds of bidirectional signaling interaction are required to complete authentication. In the first round of signaling interaction in the authentication process, the authentication network typically sends a user ID request message to the authentication client, requesting the identity identifier (such as the UID or user ID mentioned above) of a user using the authentication client. After receiving the user ID request message, the authentication client reports its own ID to the authentication network, which then forwards the user ID to the authentication device (such as the AAA server) in the data network. Throughout this process, the user ID is sent from the authentication client to the authentication network, and then from the authentication network to the authentication device in the data network. During the process of sending the user ID from the authentication client to the authentication device in the data network, the security protection of the user ID needs to be considered; otherwise, the user ID may be at risk of being leaked.

[0151] In existing EAP authentication mechanisms, the method of sending user IDs varies depending on the EAP authentication method used. For example, user IDs can be sent in plaintext, partially, anonymously, or encrypted. Different EAP authentication methods require different user ID sending methods. To protect user IDs and enhance their security during transmission, different levels of security enhancement are needed for different authentication methods. For instance, for authentication methods that originally sent user IDs in plaintext, it's necessary to protect the user IDs before transmission. However, for authentication methods that already have user ID security protection, no further protection mechanism is needed. In other words, the system needs to adopt different user ID sending strategy modifications for different authentication methods. As mentioned above, the EAP authentication mechanism supports dozens of authentication methods. If different user ID sending strategy modifications are required for different EAP authentication methods, it will undoubtedly make the secondary authentication process more complex. Therefore, more effective protection of user IDs is an urgent problem to be solved.

[0152] This application provides a method for secondary authentication, which can perform secondary authentication between terminal devices and the network without directly sending the user ID, thus efficiently ensuring the security of the user ID. The following describes the method in conjunction with... Figure 3 The embodiments of this application will be described in detail.

[0153] Figure 3 A schematic flowchart of a method for secondary authentication according to an embodiment of this application is shown. Figure 3 Method 300 can be executed by a core network function entity. This core network function entity could be, for example, a core network function entity... Figure 1 The AMF network function entity 137 or SMF network function entity 138 shown. The method 300 may include steps S310 to S340.

[0154] In step S310, the core network function entity obtains the identity identifier of the first terminal device.

[0155] The identity identifier of the first terminal device is the identifier of the first network. The identity identifier of the first terminal device can also be understood as the identity identifier used by the first network to authenticate the first terminal device, or as the identity identifier used by the first network for first-level authentication of the first terminal device. In some embodiments, the identity identifier of the first terminal device can be referred to as the UE ID.

[0156] Optionally, the first network can be the operator network mentioned above, such as a 5G network, a 4G network, a 3G network, etc. The core network function entity is the network function entity in the first network. In some embodiments, the core network function entity can also be referred to as a core network element.

[0157] Optionally, the core network function entity can be the Access and Mobility Management Function (AMF) (also known as the AMF network function) or the Unified Data Management Element (UDM) (also known as the UDM network function).

[0158] There are multiple ways for core network function entities to obtain the identity of the first terminal device.

[0159] As an example, the core network function entity can directly obtain the identity identifier of the first terminal device from the first terminal device. For instance, in step S310, the first terminal device can send its identity identifier to the core network function entity.

[0160] As another example, the core network function entity can indirectly obtain the identity identifier of the first terminal device. For example, in step S310, the core network function entity includes a first core network function entity and a second core network function entity. The first terminal device sends its identity identifier to the first core network function entity, which then sends the identity identifier to the second core network function entity. Thus, the second core network function entity obtains the identity identifier of the first terminal device indirectly.

[0161] As another example, the identity identifier of the first terminal device can be directly stored in the core network function entity, so the core network function entity can directly obtain the identity identifier of the first terminal device from its own storage device.

[0162] The identity of the first terminal device can take various forms. For example, it can be a subscriber permanent identifier (SUPI), a subscription concealed identifier (SUCI), a globally unique temporary identifier (GUTI), or a generic public subscription identifier (GPSI) for a subscribed user (i.e., the first terminal device) in the first network. All of these can be referred to as UE IDs. For the first terminal device, its SUPI, SUCI, GUTI, and GPSI can all be used to uniquely identify it, differing only in their representation, and there is a corresponding relationship between them. Optionally, when the identity of the first terminal device is GPSI, the specific form of GPSI can be defined by the first network.

[0163] For example, taking the GPSI as the identifier of the first terminal device, the process by which the core network function entity obtains the GPSI of the first terminal device can be as follows: The core network function entity can first obtain the SUPI of the first terminal device, and then determine the GPSI of the first terminal device based on the SUPI of the first terminal device and the correspondence between the SUPI and the GPSI of the first terminal device. In other words, the core network function entity can map the obtained SUPI of the first terminal device to the GPSI of the first terminal device according to the mapping relationship between SUPI and GPSI.

[0164] Furthermore, optionally, the core network function entity can first obtain the SUCI of the first terminal device, then decrypt and restore the SUCI of the first terminal device to the SUPI of the first terminal device, and then determine the GPSI of the first terminal device based on the SUPI of the first terminal device and the correspondence between the SUPI of the first terminal device and the GPSI of the first terminal device.

[0165] For example, if the identifier of the first terminal device is GPSI, and the core network function entity is AMF, then the first terminal device can send its SUCI to the AMF. The AMF then sends the SUCI to the UDM for decryption. The UDM decodes the SUCI back to its SUPI and sends the SUPI to the AMF. The AMF then maps the SUPI to its GPSI, thus obtaining the identifier of the first terminal device. Alternatively, the UDM can also perform this mapping. In other words, after decoding the SUCI, the UDM directly maps the SUPI to the GPSI and sends the resulting GPSI to the AMF. In some embodiments, the SUPI of the first terminal device may be stored in the AMF network function entity or the UDM network function entity. The first terminal device may send indication information to the AMF network function entity or the UDM network function entity to indicate the SUPI of the first terminal device. Then, the AMF network function entity or the UDM network function entity may map the stored SUPI of the first terminal device corresponding to the indication information to the GPSI of the first terminal device.

[0166] Using GPSI as the identity identifier for the first terminal device can ensure the privacy of the first terminal device's identity identifier. This is because GPSI has a corresponding relationship with SUPI, and this relationship is known only to the operator and is not disclosed to the public. Therefore, when GPSI is used in public networks or external data networks, it will not cause privacy leakage issues.

[0167] It should be understood that the aforementioned core network function entity, which is either an AMF network function entity or a UDM network function entity, is merely an example. The core network function entity can also be other network function entities. Mapping the SUPI of the first terminal device to the GPSI of the first terminal device can also be accomplished by other network function entities. This application embodiment does not impose specific limitations.

[0168] Optionally, the identity identifier of the first terminal device may be obtained by the core network function entity during the first-level authentication process for the first terminal device, or it may be obtained by the core network function entity through other processes. This application embodiment does not impose specific limitations.

[0169] In step S320, the core network function entity sends the identity identifier of the first terminal device to the authentication device in the second network.

[0170] The identity identifier of the first terminal device is used to determine the identity identifier of the second network for secondary authentication of the first user. In this embodiment, the identity identifier of the second network for secondary authentication of the first user can be understood as the identity identifier of the first user, wherein the identity identifier of the first user is different from the identity identifier of the first terminal device. The identity identifier of the first user can be understood as the identifier of the second network, or it can be understood as the identifier of the subscribed user (i.e., the first user) in the second network. In other words, the identity identifier of the first terminal device can be the identity identifier of the first network for primary authentication of the first terminal device, and the identity identifier of the first user can be the identity identifier of the second network for secondary authentication of the first user.

[0171] It should be understood that when the core network function entity sends the identity identifier of the first terminal device to the authentication device in the second network, it can be interpreted as the core network function entity sending the identity identifier of the first terminal device to the second network.

[0172] Optionally, the core network function entity sends the identity identifier of the first terminal device to the authentication device in the second network, including: the core network function entity sending a secondary authentication request to the authentication device in the second network, wherein the secondary authentication request includes the identity identifier of the first terminal device but does not include the identity identifier of the first user. In other words, the identity identifier of the first terminal device can be included in the secondary authentication request, and the core network function entity can send only the identity identifier of the first terminal device to the authentication device in the second network, without sending the identity identifier of the first user.

[0173] Optionally, the second network can be a data network (DN), and the authentication device in the second network can be an AAA server (or AAA-S).

[0174] In step S330, the authentication device in the second network determines the identity of the first user based on the identity identifier of the first terminal device and the mapping relationship between the identity identifier of the first terminal device and the identity identifier of the second network for secondary authentication of the first user.

[0175] In this embodiment of the application, the authentication device in the second network can pre-establish or store the mapping relationship between the identity identifier of the first terminal device and the identity identifier of the subscribed user of the second network (i.e., the identity identifier of the first user). Then, the authentication device in the second network can determine the identity identifier of the subscribed user of the second network (i.e., the identity identifier of the first user) based on the identity identifier of the first terminal device and the mapping relationship.

[0176] It should be understood that the mapping relationship between the identity identifier of the first terminal device and the identity identifier of the first user in the embodiments of this application can also be understood as the mapping relationship between the first terminal device and the first user, that is, the first terminal device and the first user can be conceptually separated. For example, the first terminal device can be a physical device, and different terminal devices have their own identity identifiers, the identity identifier of the first terminal device is used to identify the first terminal device; the first user can be an account or account number, etc., and different users have their own identity identifiers, the identity identifier of the first user is used to identify the first user.

[0177] On the other hand, it should be understood that the mapping relationship between the identity identifier of the first terminal device and the identity identifier of the first user in the embodiments of this application can also be understood as the mapping relationship between the contracted user (with the operator of the first network) using the first terminal device in the first network and the contracted user (with the operator of the second network) using the first terminal device in the second network. That is, the use of the first terminal device in the first network and the use of the first terminal device in the second network can be conceptually separated.

[0178] Optionally, the identity identifier of the first terminal device and the identity identifier of the first user can be mapped one-to-one, many-to-one, or one-to-many.

[0179] As an example, the identity identifier of the first terminal device and the identity identifier of the first user have a one-to-one mapping relationship. In other words, the mapping from the identity identifier of the first terminal device to the identity identifier of the first user is one-to-one, meaning that the identity identifier of the first terminal device can uniquely identify the identity identifier of the first user. Thus, after the authentication device in the second network receives the identity identifier of the first terminal device, it can directly obtain the identity identifier of the first user by querying the pre-stored mapping relationship.

[0180] As another example, the identity identifier of the first terminal device and the identity identifier of the first user have a many-to-one mapping relationship. In other words, the mapping from the identity identifier of the first terminal device to the identity identifier of the first user is many-to-one, meaning that the identity identifiers of multiple terminal devices can be mapped to the identity identifier of the first user. These multiple terminal device identity identifiers include the first terminal device's identity identifier, but for any one of the multiple terminal devices, the first user's identity identifier can be uniquely identified based on that single terminal device's identity identifier. Thus, after the authentication device in the second network receives the identity identifier of the first terminal device, it can also directly obtain the first user's identity identifier by querying the pre-stored mapping relationship.

[0181] As another example, the identity identifier of the first terminal device and the identity identifier of the first user have a one-to-many mapping relationship. In other words, the mapping from the identity identifier of the first terminal device to the identity identifier of the first user is one-to-many, meaning that the identity identifier of the first terminal device can be mapped to the identity identifiers of multiple users, where the identity identifiers of these multiple users include the identity identifier of the first user. Therefore, for the first terminal device, the identity identifiers of multiple users can be determined based on the identity identifier of the first terminal device, and these multiple user identity identifiers are all identifiers of the second network. Therefore, it is also necessary to determine the identity identifier of the first user from these multiple user identity identifiers.

[0182] Therefore, optionally, when the identity identifier of the first terminal device corresponds to the identity identifier of the second network for secondary authentication of multiple users, and the identity identifiers of the multiple users include the identity identifier of the first user, the core network function entity can obtain a first indication. This first indication is used to determine the identity identifier of the first user among the identity identifiers of the multiple users, or it can be understood that the first indication is used to indicate the identity identifier of the first user among the identity identifiers of the multiple users. It should be understood that there is a one-to-one correspondence between the multiple users and their identity identifiers, meaning that each user among the multiple users corresponds to one identity identifier. For example, a sequence number can be pre-assigned to the identity identifiers of multiple users mapped to the same terminal device (i.e., the first terminal device). The first indication can include the sequence number corresponding to the identity identifier of the first user. In addition to sending the identity identifier of the first terminal device, the first indication also needs to be sent. Based on the sequence number of the first user's identity identifier in the first indication, the identity identifier of the first user used for secondary authentication can be uniquely determined from the identity identifiers of the multiple users.

[0183] The core network function entity can simultaneously obtain the identity identifier of the first terminal device and the aforementioned first indication, for example, by simultaneously obtaining the identity identifier of the first terminal device and the aforementioned first indication in step S310; the core network function entity can also obtain the identity identifier of the first terminal device and the aforementioned first indication separately, which is not specifically limited in this embodiment. When the identity identifier of the first terminal device and the aforementioned first indication are obtained separately, the first indication can also be used to indicate the correspondence with the identity identifier of the first terminal device.

[0184] Accordingly, the core network function entity sends the first instruction to the authentication device in the second network. The authentication device in the second network can uniquely determine the identity of the first user based on the identity of the first terminal device and the first instruction. Optionally, the core network function entity can send the identity of the first terminal device and the first instruction to the authentication device in the second network simultaneously, or it can send the identity of the first terminal device and the first instruction to the authentication device in the second network separately. This embodiment does not impose specific limitations.

[0185] Optionally, when the identity identifier of the first terminal device and the identity identifier of the first user have a one-to-many mapping relationship, since the identity identifier of the first terminal device can be mapped to the identity identifiers of multiple users, the first terminal device can establish a mapping relationship between the identity identifier of the first terminal device and the identity identifier of the second network for secondary authentication of the first user. In this way, when the first terminal device sends the identity identifier of the first terminal device to the core network function entity, it can specify the identity identifier of the first user who needs to be authenticated using the first terminal device, that is, the first terminal device can determine the first instruction.

[0186] In step S340, the authentication device in the second network performs secondary authentication on the first user based on the first user's identity identifier.

[0187] In this step, the secondary authentication process can follow the standard-defined EAP authentication procedure. For example, the authentication device in the second network may negotiate the EAP authentication method with the first terminal device; these details will not be elaborated upon here.

[0188] In step S320, the core network function entity sends a secondary authentication request to the authentication device in the second network. Correspondingly, in step S340, the authentication device in the second network can send a secondary authentication response message to the core network function entity. The secondary authentication response message is used to instruct the first terminal device and the second network to perform secondary authentication for the first user.

[0189] In the secondary authentication method provided in this application embodiment, the core network function entity sends the identity identifier of the first terminal device to the authentication device in the second network. This first terminal device's identity identifier is used to determine the identity identifier for secondary authentication of the first user in the second network. This implicit transmission method eliminates the need for the core network function entity to directly send the first user's identity identifier for secondary authentication to the authentication device in the second network, enhancing the security protection of the first user's identity identifier and providing more efficient and effective protection. Furthermore, in the prior art, the first user's identity identifier is requested from the first terminal device by the core network function entity, and the first terminal device sends its identity identifier to the core network function entity in the request response. The secondary authentication method provided in this application embodiment directly sends the first terminal device's identity identifier to the authentication device in the second network through the core network function entity. This out-of-band transmission method saves the message used to request the first user's identity identifier from the first terminal device, thereby improving the efficiency of signaling and data interaction in the network, optimizing the secondary authentication process, optimizing network resources, and reducing network resource waste.

[0190] It should be understood that out-of-band transmission means that the transmission of the identity identifier of the first terminal device is not in the secondary authentication process, that is, not in the EAP process, and therefore does not belong to the EAP message.

[0191] If all terminal devices support the Level 2 authentication method provided in this application embodiment, then it can be done according to... Figure 3 The illustrated secondary authentication method 300 performs a secondary authentication process on a terminal device. When some terminal devices do not support the secondary authentication method 300 provided in this embodiment, another embodiment of this application provides a secondary authentication method 400, which will be discussed below. Figure 4 Please provide an explanation.

[0192] Figure 4 A schematic flowchart illustrating a method for secondary authentication according to another embodiment of this application is shown. Figure 4 Method 400 can be executed by a first terminal device. The first terminal device may be, for example, a... Figure 1 The terminal device 100 shown or Figure 2 The UE 210 shown. The method 400 may include steps S410 to S440 and steps S401 to S403.

[0193] Compared with method 300, steps S410 to S440 in method 400 are the same as steps S310 to S340 in method 300. For the sake of brevity, they will not be described again here. Steps S401 to S403 will be described in detail below.

[0194] In this embodiment, based on the smooth evolution of the communication system, two different types of terminal devices are allowed to exist in the system: one is the legacy UE, and the other is the new UE. The legacy UE supports the existing two-level authentication process, while the new UE supports... Figure 3 The illustrated secondary authentication method 300 means that the system is compatible with both new and old terminal devices.

[0195] For new terminal devices, this application embodiment takes the first terminal device as an example of a new terminal device. When the first terminal device needs to be authenticated at level 2, the core network function entity initiates the level 2 authentication process.

[0196] In step S401, the core network function entity sends a first message to the first terminal device.

[0197] The first message is used to request the identity identifier of the first user from the first terminal device.

[0198] In step S402, the first terminal device sends a second message to the core network function entity.

[0199] The second message indicates whether the first terminal device has sent the identity identifier of the first user. When the second message does not include the identity identifier of the first user, the core network function entity can perform secondary authentication on the first user based on the identity identifier of the first terminal device. In other words, when the second message does not include the identity identifier of the first user, the core network function entity executes steps S410 to S440, that is, the core network function entity obtains the identity identifier of the first terminal device and sends the identity identifier of the first terminal device to the authentication device in the second network, so that the authentication device in the second network executes step S430, and determines the identity identifier of the first user based on the identity identifier of the first terminal device and the mapping relationship between the identity identifier of the first terminal device and the identity identifier of the second network for secondary authentication of the first user. For a detailed description, please refer to [link to details]. Figure 3 The relevant description of the Level 2 authentication method 300 will not be repeated here.

[0200] When the first terminal device is a new type of terminal device, there are several ways in which the second message indicates that the first terminal device has not sent the identity identifier of the first user.

[0201] For example, the second message can indicate that the first terminal device did not send the first user's identity information by not including the first user's identity information in the second message.

[0202] For example, the second message may include null information, which is used to indicate that the first terminal device has not sent the identity identifier of the first user, or to indicate that the second message does not include the identity identifier of the first user.

[0203] For example, the second message may include an indicator that indicates that the first terminal device has not sent the identity identifier of the first user, or that the second message does not include the identity identifier of the first user.

[0204] Accordingly, in step S403, the core network function entity sends a second message to the authentication device in the second network.

[0205] After receiving the second message, the authentication device in the second network can determine whether the second message includes the identity identifier of the first user. When the second message does not include the identity identifier of the first user, the authentication device in the second network determines the identity identifier of the first user based on the identity identifier of the first terminal device received in step S420, thereby performing secondary authentication for the first user.

[0206] For older terminal devices, the existing secondary authentication process can be followed when performing secondary authentication on them. Specifically, in step S402, the second message sent by the first terminal device to the core network function entity includes the first user's identity identifier. The core network function entity forwards this second message to the authentication device in the second network. The authentication device in the second network can then obtain the first user's identity identifier based on the second message and directly perform secondary authentication on the first user based on that identifier. For details, please refer to [link / reference]. Figure 2 For the sake of brevity, the relevant descriptions will not be repeated here.

[0207] In this embodiment, the secondary authentication process for older terminal devices can be the same as the existing process. The secondary authentication process for newer terminal devices is partially optimized. That is, assuming the first terminal device is a newer terminal device, the core network function entity still needs to request the identity identifier of the first user from the first terminal device. However, the first terminal device may not send the identity identifier of the first user to the core network function entity. The core network function entity can obtain the identity identifier of the first terminal device. In this way, the core network function entity can perform secondary authentication for the first user based on the identity identifier of the first terminal device. By implicitly sending the identity identifier of the first user out of band, the security protection of the first user's identity identifier is enhanced, which can effectively protect the identity identifier of the first user. At the same time, it can be compatible with the secondary authentication process of both newer and older terminal devices.

[0208] Figure 4In the method 400 shown, when the first terminal device is a new type of terminal device, it has the capability to optimize the secondary authentication process, that is, it can increase the security protection of the identity of the first user. The first terminal device notifies the core network function entity that it has the capability to optimize the secondary authentication process during the secondary authentication process. Of course, the first terminal device can notify the core network function entity that it has the capability to optimize the secondary authentication process before the secondary authentication process.

[0209] Figure 5 A schematic flowchart illustrating a method for secondary authentication according to another embodiment of this application is shown. Figure 5 Method 500 can be executed by a first terminal device. The first terminal device may be, for example, a... Figure 1 The terminal device 100 shown or Figure 2 The UE 210 shown. The method 500 may include steps S510 to S540 and step S501.

[0210] Steps S510 to S540 in method 500 are the same as steps S310 to S340 in method 300 and steps S410 to S440 in method 400. For the sake of brevity, they will not be described again here. Step S501 will be described in detail below.

[0211] In this embodiment, based on the smooth evolution of the communication system, two different types of terminal devices are allowed to exist in the system: one is the legacy UE, and the other is the new UE. The legacy UE supports the existing two-level authentication process, while the new UE supports... Figure 3 The illustrated secondary authentication method 300 means that the system is compatible with both new and old terminal devices.

[0212] For new terminal devices, this application embodiment takes the first terminal device as an example of a new terminal device. Before performing secondary authentication on the first terminal device, the first terminal device notifies the core network function entity that it has the capability to optimize the secondary authentication process.

[0213] That is, in step S501, the first terminal device sends the capability information of the first terminal device to the core network function entity.

[0214] The capability information of the first terminal device is used to instruct the core network function entity to perform secondary authentication on the first terminal device based on its identity. In other words, the core network function entity determines to execute steps S510 to S540 based on the capability information of the first terminal device, without needing to execute steps S401 and S402 in a similar method 400.

[0215] Optionally, the first terminal device may carry the registration request message during the first-level authentication process between the first terminal device and the first network. Of course, the first terminal device may also carry the information in any interactive message during or after the first-level authentication process between the first terminal device and the first network; this application does not impose specific limitations. In other words, the transmission of the first terminal device's capability information is not in the second-level authentication process, i.e., not in the EAP process.

[0216] For older terminal devices, since they lack process optimization capabilities, they are not supported. Figure 3 The method 300 shown eliminates the need to send information about relevant process optimization capabilities to the core network function entities.

[0217] In this embodiment, the secondary authentication process for older terminal devices can be the same as the existing process. The secondary authentication process for newer terminal devices is optimized. Specifically, assuming the first terminal device is a newer device, the core network function entity sends the capability information of the first terminal device to the core network function before performing secondary authentication. Based on this capability information, the core network function entity can determine that the first terminal device is a newer device and does not need to request the first user's identity identifier from the first terminal device. However, the core network function entity can obtain the first terminal device's identity identifier. This allows the core network function entity to perform secondary authentication for the first user based on the first terminal device's identity identifier. By implicitly sending the first user's identity identifier out of band, the security protection of the first user's identity identifier is enhanced, providing more efficient and effective protection. Simultaneously, it is compatible with the secondary authentication processes for both newer and older terminal devices. Furthermore, the secondary authentication method provided in this application embodiment directly sends the identity identifier of the first terminal device to the authentication device in the second network through the core network function entity, which can save the message used to request the identity identifier of the first user from the first terminal device, thereby improving the efficiency of signaling and data interaction in the network, optimizing the secondary authentication process, optimizing network resources, and reducing the waste of network resources.

[0218] The secondary authentication process for the first user in the second network, in addition to the aforementioned process of requesting the first user's identity, also includes a process of negotiating the authentication algorithm between the first terminal device and the authentication device in the second network. Since the EAP algorithms currently used for secondary authentication support dozens of authentication algorithms, the first terminal device and the authentication device in the second network need to negotiate and determine an authentication algorithm to complete the authentication process. Currently, the commonly used algorithm negotiation process involves the authentication server in the second network initiating the negotiation process, which is conducted between the first terminal device and the authentication device in the second network. This process suffers from problems such as long interaction times, high network resource consumption, and long latency. This application provides a secondary authentication method that can shorten the authentication algorithm negotiation interaction process, reduce latency, and save network resources. The following describes a method for secondary authentication... Figure 6 Provide a detailed description.

[0219] Figure 6 A schematic flowchart of a method for secondary authentication according to yet another embodiment of this application is shown. Figure 6 Method 600 can be executed by a core network function entity. This core network function entity could be, for example, a core network function entity... Figure 1 The AMF network function entity 137 or SMF network function entity 138 shown. The method 600 may include steps S610 to S640, wherein step S640 includes steps S641 to S643.

[0220] Compared to method 300, steps S610 to S630 in method 600 are the same as steps S310 to S330 in method 300, and for simplicity, they will not be described again here. Steps S641 to S643 in step S640 will be described in detail below. It should be noted that in some embodiments, steps S641 to S643 in method 600 can also be executed in an existing secondary authentication process, without executing steps S620 and S630 in the embodiments of this application.

[0221] Step S640 includes steps S641 to S643.

[0222] In step S641, the core network function entity selects a first authentication method for performing secondary authentication on the first user.

[0223] The first authentication method is an authentication method supported by both the first terminal device and the authentication devices in the second network.

[0224] In step S642, the core network function entity sends the first authentication method to the authentication device in the second network.

[0225] In step S643, the authentication device in the second network determines the first authentication method as the negotiated authentication method, and then performs authentication according to the first authentication method.

[0226] In this embodiment, the core network function entity selects an authentication method supported by both the first terminal device and the authentication device in the second network, and sends it to the authentication device in the second network as the authentication method negotiated by the first terminal device and the authentication device in the second network. This is equivalent to the core network function entity completing the authentication algorithm negotiation process without the need for negotiation between the first terminal device and the authentication device in the second network, thereby shortening the message interaction process, reducing latency, and saving network resources.

[0227] Figure 7 A schematic flowchart illustrating a second-level authentication method according to yet another embodiment is shown. The diagram exemplifies the process by which a core network functional entity selects a first authentication method.

[0228] refer to Figure 7 , Figure 7 The method 700 shown includes steps S710 to S740, wherein step S740 includes steps S741 to S744c. Steps S710 to S730 are the same as steps S610 to S630 in method 600, and for the sake of brevity, they will not be described again here. Steps S741 to S744c in step S740 will be described in detail below.

[0229] In step S741, the core network function entity obtains the first authentication method set and the second authentication method set.

[0230] The first set of authentication methods includes the authentication methods preferred by the first terminal device, and the second set of authentication methods includes the authentication methods preferred by the authentication devices in the second network.

[0231] The first set of authentication methods may be stored in the first terminal device and / or the core network functional entity; the second set of authentication methods may be stored in the core network functional entity and the authentication device in the second network.

[0232] In step S742a, the core network function entity determines the first authentication method based on the first authentication method set and the second authentication method set, that is, the core network function entity selects the first authentication method.

[0233] If there is an intersection between the first authentication method set and the second authentication method set, the core network functional entity can determine that the intersection of the first authentication method set and the second authentication method set is the authentication method preferred by both the first terminal device and the authentication device in the second network.

[0234] In step S743a, the core network function entity sends the first authentication method to the authentication device in the second network.

[0235] In step S744a, the authentication device in the second network performs authentication according to the first authentication method.

[0236] There are several ways to determine the first authentication method.

[0237] For example, in step S743a, the core network function entity can select an authentication method as the first authentication method from the intersection of the first authentication method set and the second authentication method set. The first authentication method can be any authentication method in the intersection, or the authentication method with the highest priority in the intersection, or the authentication method ranked higher in the intersection.

[0238] For example, in step S743a, the core network function entity can select at least two authentication methods from the intersection of the first authentication method set and the second authentication method set, and send the at least two authentication methods to the authentication device in the second network. Correspondingly, in step S744a, the authentication device in the second network can arbitrarily select one of the at least two authentication methods as the first authentication method, and perform authentication according to the first authentication method.

[0239] If there is no intersection between the first authentication method set and the second authentication method set, then steps S742a to S744a can be skipped after step S741, and instead steps S743b to S744b can be executed.

[0240] In step S743b, the core network function entity sends the first set of authentication methods to the authentication device in the second network.

[0241] In step S744b, the authentication device in the second network selects a second authentication method from the first authentication method set and performs authentication according to the second authentication method.

[0242] The second authentication method is the authentication method supported by the authentication device in the second network.

[0243] In other words, when there is no intersection between the first authentication method set and the second authentication method set, the core network function entity sends the authentication method preferred by the first terminal device (i.e., the first authentication method set) to the authentication device in the second network. Although the authentication method preferred by the first terminal device is not the authentication method preferred by the authentication device in the second network, it may be an authentication method supported by the authentication device in the second network. Therefore, the authentication device in the second network can select an authentication method supported by the authentication device in the second network from the authentication method preferred by the first terminal device as the second authentication method for the authentication process.

[0244] Optionally, in step S744b, the authentication device in the second network may also select a second authentication method from the second authentication method set and perform authentication according to the second authentication method.

[0245] Since the authentication device in the second network knows its preferred authentication method (i.e., the second authentication method set), even though the second authentication method set is not the preferred authentication method of the first terminal device, it may be an authentication method supported by the first terminal device. Therefore, the authentication device in the second network can select an authentication method supported by the first terminal device from the authentication methods preferred by the authentication device in the second network as the second authentication method for the authentication process.

[0246] If there is no intersection between the first authentication method set and the second authentication method set, then steps S742a to S744a can be skipped after step S741, and instead steps S743c to S744c can be executed.

[0247] In step S743c, the core network function entity sends a second instruction to the authentication device in the second network.

[0248] The second instruction is used to instruct the authentication device in the second network to negotiate the authentication method with the first terminal device.

[0249] In step S744c, the authentication device in the second network negotiates the authentication method with the first terminal device.

[0250] In other words, when there is no intersection between the first authentication method set and the second authentication method set, the core network function entity will then use a second instruction to notify the authentication device in the second network to negotiate the authentication method with the first terminal device.

[0251] Optionally, the first set of authentication methods may include authentication methods supported by the first terminal device, and / or the second set of authentication methods may include authentication methods supported by authentication devices in the second network. The corresponding process is similar to that described above and will not be repeated here.

[0252] refer to Figure 6 In method 600, steps S641 to S643 can be executed before step S640 (equivalent to steps S641 to S643 being executed before step S340 in method 300). Optionally, steps S641 to S643 can also be executed before step S440 in method 400, or before step S540 in method 500.

[0253] Similarly, refer to Figure 7In method 700, steps S741 to S744c can be executed before step S740 (equivalent to steps S741 to S744c being executed before step S340 in method 300). Optionally, steps S741 to S744c can also be executed before step S440 in method 400, or before step S540 in method 500.

[0254] Optionally, before performing step S741, the AMF may send the network-preferred second authentication method set to the UE. After receiving the second authentication method set, the UE may select the UE's preferred authentication method set (including one or more authentication methods) based on the received second authentication method set and the EAP authentication methods supported by the UE, and send it to the AMF.

[0255] For example, the UE selects or determines a preferred authentication method based on a second set of authentication methods. This preferred authentication method can be one that the UE supports or prefers, and also one preferred by the authentication device in the second network. The UE sends this preferred authentication method to the AMF (Authentication Center), which can then directly forward it to the authentication device in the second network. The authentication device in the second network can then use this preferred authentication method as the authentication method negotiated between the authentication device in the second network and the first terminal device.

[0256] For example, the UE selects or determines multiple preferred authentication methods based on a second set of authentication methods. This preferred set includes multiple authentication methods that are either supported or preferred by the UE, and are also preferred by the authentication device in the second network. The UE sends these multiple preferred authentication methods to the AMF, which can then select one method to send to the authentication device in the second network. The authentication device in the second network can then use the selected method as the authentication method negotiated between the authentication device in the second network and the first terminal device.

[0257] In some embodiments, steps S641 to S643 in method 600 can also be executed in an existing secondary authentication process, without executing steps S620 and S630 in the embodiments of this application; steps S741 to S744c in method 700 can also be executed in an existing secondary authentication process, without executing steps S720 and S730 in the embodiments of this application. The process is the same as described above, and for the sake of brevity, it will not be repeated. For details, please refer to the relevant description above.

[0258] The following is in conjunction with the appendix Figures 8 to 11The present application provides a more detailed description of some specific, non-limiting examples of embodiments thereof. Figures 8 to 11 This example uses the UE as the first terminal device, the AMF (or AMF for short) as the core network network functional entity, the GPSI as the identifier of the first terminal device, and the user ID as the identifier for secondary authentication of the first user in the second network. The first network is the operator network, the second network is the data network, and the authentication device in the second network is AAA-S (i.e., AAA server), with the EAP authentication mechanism as the secondary authentication mechanism. However, it should be understood that… Figures 8 to 11 The illustrated secondary authentication process is merely illustrative. The first terminal device, the core network functional entity, the identity identifier of the first terminal device, the identity identifier of the second network for secondary authentication of the first user, the first network, the second network, and the authentication device in the second network can also be the situations mentioned above, which will not be elaborated here.

[0259] Figure 8 A schematic flowchart illustrating a method for secondary authentication according to another embodiment of this application is shown. (See reference...) Figure 8 This application embodiment optimizes the initial EAP message (i.e., EAP request / response) in the EAP authentication mechanism, specifically by not sending ID request and ID response in the EAP message. It should be understood that the ID request and ID response referred to here are the user ID request and user ID response, respectively. The user ID information obtained by AAA-S is obtained through the GPSI sent by AMF to AAA-S, not through a request from AMF to the UE. Method 800 includes steps S810 to S840, where step S840 includes steps S841 to S847, the specific process of which is as follows... Figure 8 As shown.

[0260] In step S810, the UE sends a registration request to the AMF to access the network, carrying identity information, such as encrypted identity information SUCI.

[0261] It should be understood that UE can be understood as a specific example of the first terminal device in methods 300 to 700; AMF can be understood as a specific example of the core network function entity in methods 300 to 700.

[0262] In step S820, the UE and AMF perform Level 1 authentication and NAS security protection.

[0263] For example, the specific process can be as follows: The AMF determines whether to initiate a Level 1 authentication process between the network and the UE based on the identity information sent by the UE. For instance, if the UE sends a SUCI to the AMF, the AMF forwards the SUCI to the UDM, which decrypts the SUCI to restore the UE's true identity SUPI, and then sends the SUPI back to the AMF. The AMF then initiates Level 1 authentication based on the SUPI.

[0264] After step S820, i.e., after successful Level 1 authentication, the AMF authorizes the UE to access the network. The AMF determines whether the UE needs further Level 2 authentication based on information from the AMF or UDM.

[0265] In step S830, the AMF determines that the UE needs to undergo secondary authentication.

[0266] In step S840, the AMF triggers the secondary authentication process between the UE and the DN (i.e., AAA-S) to perform secondary authentication.

[0267] During the secondary authentication process for the UE, step S840 may also include steps S841 to S847.

[0268] In step S841, AMF sends GPSI to the AAA server (AAA-S) located in DN.

[0269] Optionally, the AMF sends a user ID indication to AAA-S located in the DN. This user ID indication can be understood as the first indication described above.

[0270] Optionally, the AMF sends an authentication instruction to the AAA-S located in the DN.

[0271] In step S842, AAA-S determines that the received message is an EAP authentication request message based on the message type and / or authentication indication. AAA-S obtains the user ID for secondary authentication based on the GPSI or based on the GPSI and user ID indication. For example, AAA-S pre-stores the mapping between GPSI (or including the user ID indication) and user IDs, and obtains the user ID required for secondary authentication based on this mapping and the GPSI. This user ID can be understood as the identity identifier of the first user mentioned above, and the GPSI can be understood as a specific example of the identity identifier of the first terminal device mentioned above.

[0272] In step S843, AAA-S initiates the EAP authentication process based on the obtained user ID used for secondary authentication. AAA-S sends an EAP request to AMF, which includes the EAP authentication method selected by AAA-S, such as authentication method 1.

[0273] In step S844, after receiving the EAP request from AAA-S, the AMF forwards the EAP request message to the UE via the NAS message of the operator network.

[0274] In step S845, the UE replies to the AMF with an EAP response message. If the UE agrees to use authentication method 1, it replies that it agrees to use authentication method 1.

[0275] In step S846, the AMF forwards the EAP response message to the AAA-S. Meanwhile, the remaining authentication steps between the AAA-S and the UE continue to be performed (as indicated by the ellipsis in the diagram).

[0276] In step S847, if authentication is successful, AAA-S sends an EAP authentication success message to AMF. AMF can then proceed with other registration processes.

[0277] It should be noted that the interaction between AAA-S and AMF can also be proxied and relayed through the proxy function AAA-F.

[0278] It should also be noted that step S841 is not included in the EAP process and is not part of the EAP message. The EAP message begins at step S843. In the conventional method, the first EAP message (i.e., EAP request(ID)) is sent from the AMF, that is, before step S841, and the first message is sent from the AMF to the UE, requesting the UE to send its user ID (i.e., EAPresponse(ID)). In this embodiment, the process of sending the user ID between the UE and AAA-S (i.e., the initial EAP authentication message EAP request(ID) / EAP response(ID)) is saved. Instead, the user ID is obtained by the AAA server through out-of-band, implicit transmission. This is equivalent to reusing the information exchange of the existing 3GPP network and the existing interaction messages between the 3GPP network and the AAA server to notify the AAA server of the user ID used by the UE in secondary authentication, avoiding the problem of leaking user privacy by sending the user ID and saving network resources. Specifically, after the 3GPP network establishes a connection with the AAA server, before (or during) secondary authentication of the UE, the UE ID, rather than the secondary authentication user ID, is sent to the AAA server outside the EAP process. If a mapping from the UE ID to the secondary authentication user ID is established on the AAA server, the AAA server can directly convert the UE ID to the user ID without needing to use EAP request and EAP response message interactions to obtain the user ID during the EAP process. This saves network resources and efficiently ensures the security of the user ID.

[0279] Figure 9 A schematic flowchart illustrating a method for secondary authentication according to another embodiment of this application is shown. (See reference...) Figure 9 This application embodiment optimizes the initial EAP message (i.e., EAP request / response) in the EAP authentication mechanism. In this embodiment, the system allows two different types of UEs: one is the legacy UE, which still uses the original EAP method, and the other is the new UE, which allows for optimization of the initial EAP message. This assumption is mainly based on the smooth evolution of the system, that is, simultaneous compatibility with legacy UEs and new UEs. Method 900 includes steps S910 to S940, where step S940 includes steps S941 to S949, and the specific process is as follows.

[0280] Steps S910 to S930 are the same as steps S810 to S830 in method 800, and their descriptions are omitted here. For details, please refer to the relevant descriptions above.

[0281] After the AMF determines that the UE needs to perform secondary authentication, in step S940, the AMF triggers the secondary authentication process between the UE and the DN to perform secondary authentication. During the secondary authentication process for the UE, step S940 may also include steps S941 to S949.

[0282] In step S941, the AMF initiates the EAP authentication process, just like existing authentication methods, that is, it sends an EAP request message to the UE, requesting the UE to send its user ID for secondary authentication.

[0283] In step S942a, for the existing UE (i.e., the old UE), the UE still uses the existing authentication method to return an EAP response message to the AMF, which includes the user ID for secondary authentication. This message is forwarded by the AMF to the AAA-S in step S943a. In step S944, the AAA-S directly obtains the user ID.

[0284] In step S942b, for a UE with optimization capabilities (i.e., a new UE), the EAP response message does not include user ID information, or includes a null message or an indicator to indicate that the message does not contain user ID information. This message is forwarded to AAA-S in step S943b.

[0285] It should be noted that in the forwarding message of S943b, in addition to the EAP message, a GPSI can be sent to AAA-S simultaneously, with the GPSI indicating the user ID used. In step S944, AAA-S can convert the GPSI into a user ID, thus allowing the remaining EAP authentication process to continue.

[0286] Steps S945 to S949 are the same as steps S843 to S847 in method 800, and their descriptions are omitted here. For details, please refer to the relevant descriptions above.

[0287] In this embodiment of the application, the secondary authentication process of the old UE has not been improved. However, in order to be compatible with the needs of the old UE, the EAP process of the new UE has been partially optimized. That is, the two initial messages of EAP still need to be sent, but the user ID is protected by privacy.

[0288] Figure 10 A schematic flowchart illustrating a method for secondary authentication according to another embodiment of this application is shown. (See reference...) Figure 10 This application embodiment optimizes the initial EAP message (i.e., EAP request / response) in the EAP authentication mechanism. In this embodiment, the system allows two different types of UEs: one is the legacy UE, which still uses the original EAP method, and the other is the new UE, which allows for optimization of the initial EAP message. This assumption is mainly based on the smooth evolution of the system, that is, simultaneous compatibility with legacy UEs and new UEs. Method 1000 includes steps S1010 to S1040, where step S1040 includes steps S1041 to S1049, and its specific process is as follows.

[0289] Steps S1010 to S1030 are similar to steps S810 to S830 in method 800. Only the differences are described here. For details, please refer to the relevant description above.

[0290] Step S1010 is similar to step S810 in method 800, except that in this step, the UE can include information indicating whether it has EAP process optimization capabilities (i.e., the EAP initial message does not contain EAP request ID and EAP response ID messages) in the registration request message. For legacy UEs, this message does not contain this capability indication.

[0291] Step S1030 is similar to step S830 in method 800, except that in this step, the AMF can determine whether the UE has the ability to optimize for EAP. If the UE is a legacy UE and does not have the optimization capability, then steps S1041, S1042, and S1043a are executed; if the UE is a new UE and has the optimization capability, then step S1043b is executed.

[0292] Steps S1041, S1042, and S1043a are similar to steps S941, S942a, and S943a in method 900, respectively. Their detailed descriptions are omitted here, but please refer to the above text for details.

[0293] Steps S1043b and S1044 are similar to steps S943b and S944 in method 900, and their detailed descriptions are omitted here. For details, please refer to the above text.

[0294] Steps S1045 to S1049 are the same as steps S945 to S949 in method 900, and their descriptions are omitted here. For details, please refer to the relevant descriptions above.

[0295] It should be noted that the indication information for the UE to report optimization capabilities in step S1010 can also be included in messages from other steps to notify the AMF. For example, there will be multiple information exchanges between the UE and the AMF in step S1020, and this indication can be included in any of these messages to notify the AMF; there are no restrictions here.

[0296] Figure 11 A schematic flowchart illustrating a method for secondary authentication according to another embodiment of this application is shown. (See reference...) Figure 11 This embodiment optimizes the EAP authentication algorithm negotiation process. This embodiment primarily uses the operator network as a proxy to complete the authentication algorithm negotiation, thereby shortening the message interaction process, reducing latency, and saving network resources. Method 1100 of this embodiment includes steps S1110 to S1160, where step S1150 includes steps S1151 to S1156, and step S1160 includes steps S1161 to S1167. The specific process is as follows.

[0297] Steps S1110 to S1130 are similar to steps S810 to S830 in method 800. Only the differences are described here. For details, please refer to the relevant description above.

[0298] Step S1110 is similar to step S810 in method 800, except that the UE may include its preferred EAP authentication method list (“UE preferred authentication method list”) in the registration request message at this time. The preferred authentication method may be different for each slice (i.e., S-NSSAI), or the preferred method may be the same for all S-NSSAIs.

[0299] Step S1130 is similar to step S830 in method 800, except that in this step, the AMF needs to further query (either the AMF itself or the UDM) the list of preferred AAA-S authentication methods for the UE ("DN preferred authentication method list"). The two lists are compared to determine if they overlap, thus identifying an EAP authentication method preferred by both. If there are more than one method, the method ranked higher or with higher priority is selected.

[0300] The “UE Preferred Authentication Method List” can be understood as the first set of authentication methods mentioned above, and the “DN Preferred Authentication Method List” can be understood as the second set of authentication methods mentioned above.

[0301] In step S1140, if the preferred authentication method was determined in step S1130 (which can be understood as the first authentication method described above), then the specific steps in step S1150 are executed. If the preferred authentication method cannot be determined in step S1130, then the specific steps in step S1160 are executed.

[0302] Step S1150 may include steps S1151 to S1156. Step S1150 may be an existing EAP process based on a certain authentication method "Authentication Method 2", which will not be described in detail here.

[0303] Step S1160 may include steps S1161 to S1167. Step S1160 follows the existing EAP process of negotiating an authentication method before performing authentication. The difference is that in step S1163, the AMF sends the UE's preferred authentication method list to the AAA-S. This allows the AAA-S to first check if a method supported by the AAA-S exists in the preferred list. If supported, a method can be selected as the negotiated authentication method. Otherwise, all methods in the list are excluded, and the selection of an authentication algorithm begins in step S1164.

[0304] It should be noted that the authentication algorithm can continue to select methods from the AAA-S preferred list, because although they are not preferred by the UE, they may be methods that the UE can support. Alternatively, AAA-S can exclude all methods from the AAA-S preferred list and only select other AAA-S supported methods outside the list to negotiate with the UE. This application embodiment does not impose specific limitations on this.

[0305] It should also be noted that the "UE Preferred Authentication Method List" reported by the UE in step S1110 can also be included in messages from other steps to notify the AMF. For example, in step S1120, there will be multiple information exchanges between the UE and the AMF, and this indication can be included in any of these messages to notify the AMF; there are no restrictions here.

[0306] Method 1100 in the embodiments of this application can be used in conjunction with method 800, method 900 and method 1000 respectively.

[0307] Figure 12 A schematic flowchart illustrating a method for secondary authentication according to another embodiment of this application is shown. (See reference...) Figure 12 This embodiment optimizes the EAP authentication algorithm negotiation process. The method 1200 of this application embodiment includes steps S1210 to S1260, wherein step S1260 includes steps S1261 to S1264, and the specific process is as follows.

[0308] In step S1210, Level 1 authentication is performed on the UE (which can be understood as the aforementioned first terminal device).

[0309] In step S1220, the AMF determines that the UE needs to undergo secondary authentication.

[0310] In step S1230, the AMF sends the slices that need to be authenticated to the UE. That is, in this step, the AMF notifies the UE which slices need to be authenticated.

[0311] Optionally, in step S1230, the AMF may also send the AAA server's preferred authentication method set (which can be understood as the second authentication method set described above) to the UE. Before step S1230, the AMF may request the AAA server's preferred authentication method set from the AAA server, or it may directly obtain the AAA server's preferred authentication method set from other network function entities such as the UDM. This embodiment of the application does not limit this.

[0312] In step S1240, in the registration request, the UE sends its preferred authentication method set to the AMF. This preferred authentication method set may include one or more authentication methods. Unlike method 1100, in this embodiment, the UE sends its preferred authentication method set to the AMF after Level 1 authentication and before the EAP (Electronic Access Point) process, while in method 1100, the UE sends its preferred authentication method set to the AMF before (or during) Level 1 authentication.

[0313] For example, if the AMF does not send the AAA server's preferred authentication method set to the UE in step S1230, then the UE's preferred authentication method set sent to the MAF in step S1240 can be the UE's default preferred authentication method set.

[0314] For example, if the AMF sends the AAA server's preferred authentication method set to the UE in step S1230, then the UE's preferred authentication method set sent to the AMF in step S1240 can be determined based on the AAA server's preferred authentication method set. For instance, the UE can determine or select its preferred authentication method set from the AAA server's preferred authentication method set.

[0315] In step S1250, the AMF determines the authentication method.

[0316] In step S1260, the AMF triggers the secondary authentication process between the UE and the AAA server to perform secondary authentication.

[0317] Step S1260 may include steps S1261 to S1264, wherein steps S1261 and S1262 are optional steps, and their processes can refer to existing processes or the relevant descriptions of EAP requests and EAP responses in the aforementioned methods 300 to 1100.

[0318] In step S1263, the AMF sends the authentication method determined in step S1250, such as authentication method 1, to the AAA server. The AAA server can identify the authentication method determined in step S1250 as the authentication method negotiated between the AAA server and the UE, and then continue with the next process.

[0319] In step S1250, taking the authentication method determined by the AMF as authentication method 1 as an example, the AMF can determine the authentication method in various ways.

[0320] As an example, if the AMF sends the AAA server's preferred set of authentication methods to the UE in step S1230, then in step S1240, the UE can select or determine a UE-supported or preferred authentication method, such as authentication method 1, from the AAA server's preferred set of authentication methods and send it to the AMF. In step S1250, the AMF can directly forward the authentication method determined by the UE to the AAA server, and the AAA server will recognize the authentication method determined by the UE as the authentication method negotiated between the AAA server and the UE.

[0321] Alternatively, if the AMF sends the AAA server's preferred set of authentication methods to the UE in step S1230, then in step S1240, the UE can select or determine multiple authentication methods supported or preferred by the UE from the AAA server's preferred set of authentication methods and send them to the AMF. In step S1250, the AMF can directly determine one authentication method from the multiple authentication methods determined by the UE for secondary authentication and forward the determined authentication method to the AAA server. The AAA server then confirms the authentication method determined by the AMF as the authentication method negotiated between the AAA server and the UE.

[0322] As another example, if the AMF does not send the AAA server's preferred authentication method set to the UE in step S1230, then in step S1240, the UE may send the UE's preferred or supported authentication method set to the AMF. In step S1250, the AMF can determine an authentication method for secondary authentication based on the UE's preferred or supported authentication method set and the AAA server's preferred or supported authentication method set, and send the determined authentication method to the AAA server. The AAA server then recognizes the determined authentication method as the authentication method agreed upon by the AAA server and the UE.

[0323] Method 1200 in the embodiments of this application can be used in conjunction with method 800, method 900 and method 1000 respectively.

[0324] The embodiments of this application mainly involve the terminal device sending the set of authentication methods selected by the terminal device to the core network function entity before the EAP process of slice authentication. The authentication algorithm negotiation is completed through the operator network, thereby shortening the message interaction process, reducing latency, and saving network resources.

[0325] This application's embodiments do not alter the EAP process defined in the IETF standard. In the standard EAP process, EAP request / ID, EAP response / ID, and the EAP negotiation process are all optional steps. This application's embodiments avoid these optional steps by utilizing information exchange within the operator's network.

[0326] The above text combined Figures 1 to 12 The method embodiments of this application are described in detail below, in conjunction with... Figures 13 to 18 This application provides a detailed description of the apparatus embodiments. It should be understood that the descriptions of the method embodiments correspond to the descriptions of the apparatus embodiments; therefore, any parts not described in detail can be found in the preceding method embodiments.

[0327] Figure 13 This is a schematic structural diagram of a device provided in an embodiment of this application. Figure 13The device 1300 mentioned above can be the core network function entity mentioned earlier, for example, it can be... Figure 1 A specific example of AMF network function entity 137 or UDM network function entity 134 in the example. Figure 13 The device shown can be used to perform Figures 3 to 12 To avoid redundancy, the method will not be described again.

[0328] Figure 13 The communication device 1300 shown may include an acquisition module 1310 and a transmission module 1320.

[0329] The acquisition module 1310 is used to acquire the identity identifier of the first terminal device, which is the identifier of the first network.

[0330] The sending module 1320 is used to send the identity identifier of the first terminal device to the authentication device in the second network. The identity identifier of the first terminal device is used to determine the identity identifier of the second network for secondary authentication of the first user. The identity identifier of the first user is different from the identity identifier of the first terminal device.

[0331] Optionally, the sending module 1320 is specifically used to send a secondary authentication request to the authentication device in the second network. The secondary authentication request includes the identity identifier of the first terminal device but does not include the identity identifier of the first user.

[0332] Optionally, the device 1300 may further include a receiving module 1330, configured to receive a secondary authentication response message sent by an authentication device in the second network, the secondary authentication response message being used to instruct the first terminal device and the second network to perform secondary authentication for the first user.

[0333] Optionally, the sending module 1320 is used to send a first message to the first terminal device, the first message being used to request the identity identifier of the first user.

[0334] Optionally, the receiving module 1330 is configured to receive a second message sent by the first terminal device; when the second message does not include the identity identifier of the first user, the receiving module 1330 is configured to perform secondary authentication on the first user based on the identity identifier of the first terminal device.

[0335] Optionally, before performing secondary authentication on the first user, the acquisition module 1310 is used to acquire the capability information of the first terminal device. The capability information of the first terminal device is used to instruct the core network function entity to perform secondary authentication on the first user based on the identity identifier of the first terminal device.

[0336] Optionally, the capability information of the first terminal device is carried in the registration request message during the first-level authentication process between the first terminal device and the first network.

[0337] Optionally, the identity identifier of the first terminal device corresponds to the identity identifier of the second network for secondary authentication of multiple users, and the identity identifier of the multiple users includes the identity identifier of the first user. The acquisition module 1310 is used to acquire a first indication, which is used to determine the identity identifier of the first user among the identity identifiers of the multiple users.

[0338] Optionally, the device 1300 may further include a selection module. The selection module is used to select a first authentication method for the secondary authentication, wherein the first authentication method is an authentication method supported by both the first terminal device and the authentication device in the second network.

[0339] Optionally, the selection module is specifically used to obtain a first authentication method set and a second authentication method set, wherein the first authentication method set includes the authentication method preferred by the first terminal device, and the second authentication method set includes the authentication method preferred by the authentication device in the second network; the selection module is specifically used to determine the first authentication method based on the first authentication method set and the second authentication method set, wherein the first authentication method is the authentication method preferred by both the first terminal device and the authentication device in the second network; the sending module 1320 is specifically used to send the first authentication method to the authentication device in the second network.

[0340] Optionally, the second authentication method set is stored in the core network function entity, and / or the first authentication method set is stored in the first terminal device and / or the core network function entity.

[0341] Optionally, the acquisition module 1310 is used to acquire a first authentication method set and a second authentication method set, wherein the first authentication method set includes the authentication method preferred by the first terminal device, and the second authentication method set includes the authentication method preferred by the authentication device in the second network; when the first authentication method set and the second authentication method set do not overlap, the sending module 1320 is used to send the first authentication method set or a second indication to the authentication device in the second network, wherein the second indication is used to instruct the authentication device in the second network to negotiate authentication methods with the first terminal device.

[0342] Figure 14 This is a schematic structural diagram of the communication device provided in the embodiments of this application. Figure 14The communication device 1400 shown corresponds to the core network function entity described above. The communication device 1400 includes a processor 1402. In embodiments of this application, the processor 1402 is used to control and manage the operation of the core network function entity; for example, the processor 1402 is used to support the core network function entity in performing the actions described in the foregoing embodiments. Figures 3 to 11 The method, operation, or function shown. Optionally, the core network function entity may further include: a memory 1401 and a communication interface 1403; the processor 1402, communication interface 1403, and memory 1401 can be interconnected or interconnected via a bus 1404. The communication interface 1403 is used to support communication by the core network function entity, and the memory 1401 is used to store program code and data of the network device. The processor 1402 calls the code stored in the memory 1401 for control and management. The memory 1401 may or may not be coupled to the processor.

[0343] The processor 1402 can be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a digital signal processor and a microprocessor, etc. The communication interface 1403 can be a transceiver, circuit, bus, module, or other type of communication interface. The bus 1404 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 14 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0344] Figure 15 This is a schematic structural diagram of a device provided in an embodiment of this application. Figure 15 The device 1500 mentioned above can be the authentication device in the second network described above, for example, it can be... Figure 2 A specific example of AAA server 221 in the example. Figure 15 The device shown can be used to perform Figures 3 to 12 To avoid redundancy, the method will not be described again.

[0345] Figure 15The communication device 1500 shown may include a receiving module 1510, a determining module 1520, and an authentication module 1530.

[0346] The receiving module 1510 is used to receive the identity identifier of the first terminal device sent by the core network function entity, wherein the identity identifier of the first terminal device is the identifier of the first network.

[0347] The determining module 1520 is used to determine the identity of the first user based on the identity identifier of the first terminal device and the mapping relationship between the identity identifier of the first terminal device and the identity identifier of the second network for secondary authentication of the first user, wherein the identity identifier of the first user is different from the identity identifier of the first terminal device.

[0348] The authentication module 1530 is used to perform secondary authentication on the first user based on the first user's identity identifier.

[0349] Optionally, the receiving module 1510 is specifically used to receive a secondary authentication request sent by the core network function entity, wherein the secondary authentication request includes the identity identifier of the first terminal device but does not include the identity identifier of the first user.

[0350] The authentication module 1530 is specifically used to send a secondary authentication response message to the core network function entity. The secondary authentication response message is used to instruct the first terminal device and the second network to perform secondary authentication for the first user.

[0351] Optionally, the identity identifier of the first terminal device corresponds to the identity identifier of the second network for secondary authentication of multiple users, and the identity identifier of the multiple users includes the identity identifier of the first user. The receiving module 1510 is used to receive a first indication sent by the core network function entity, and the first indication is used to determine the identity identifier of the first user among the identity identifiers of the multiple users.

[0352] Optionally, the receiving module 1510 is used to receive a first authentication method sent by a core network function entity, wherein the first authentication method is an authentication method supported by both the first terminal device and the authentication device in the second network.

[0353] Optionally, the authentication module 1530 is used to perform secondary authentication on the first user according to the first authentication method.

[0354] Optionally, the receiving module 1510 is used to receive a first set of authentication methods sent by a core network function entity, the first set of authentication methods including the authentication methods preferred by the first terminal device.

[0355] Optionally, the receiving module 1510 is configured to select a second authentication method from the first authentication method set, wherein the second authentication method is an authentication method supported by the authentication device in the second network.

[0356] Optionally, the authentication module 1530 is used to perform secondary authentication on the first user according to the second authentication method.

[0357] Optionally, the receiving module 1510 is configured to receive a second instruction sent by a core network function entity, the second instruction being configured to instruct the authentication device in the second network to negotiate an authentication method with the first terminal device.

[0358] Figure 16 This is a schematic structural diagram of the communication device provided in the embodiments of this application. Figure 16 The communication device 1600 shown may correspond to the authentication device in the second network described above. The communication device 1600 includes a processor 1602. In embodiments of this application, the processor 1602 is used to control and manage the operation of the authentication device in the second network; for example, the processor 1602 is used to support the authentication device in the second network in performing the actions described in the foregoing embodiments. Figures 3 to 11 The method, operation, or function is illustrated. Optionally, the authentication device in the second network may further include: a memory 1601 and a communication interface 1603; the processor 1602, communication interface 1603, and memory 1601 can be interconnected or interconnected via a bus 1604. The communication interface 1603 is used to support communication between the authentication devices in the second network, and the memory 1601 is used to store the program code and data of the network devices. The processor 1602 calls the code stored in the memory 1601 for control and management. The memory 1601 may or may not be coupled to the processor.

[0359] The processor 1602 can be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a digital signal processor and a microprocessor, etc. The communication interface 1603 can be a transceiver, circuit, bus, module, or other type of communication interface. The bus 1604 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 16 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0360] Figure 17 This is a schematic structural diagram of a device provided in an embodiment of this application. Figure 17 The device 1700 mentioned above can be the first terminal device, for example, it can be... Figure 1 Terminal equipment 110 or Figure 2 A specific example of UE 210 in the example. Figure 17 The device shown can be used to perform Figures 3 to 12 To avoid redundancy, the method will not be described again.

[0361] Figure 17 The communication device 1700 shown may include an establishment module 1710 and a transmission module 1720.

[0362] The module 1710 is used to establish a mapping relationship between the identity identifier of the first terminal device and the identity identifier of the second network for secondary authentication of the first user, wherein the identity identifier of the first terminal device is the identifier of the first network.

[0363] The sending module 1720 is configured to send the identity identifier of the first terminal device to the core network function entity, or to send the identity identifier of the first terminal device and a first indication to the core network function entity, wherein the first indication is used for the second network to target

[0364] The identity of the first user is determined from the identity identifiers of multiple users undergoing secondary authentication.

[0365] Optionally, the sending module 1720 is used to send the capability information of the first terminal device to the core network function entity before performing secondary authentication on the first user. The capability information of the first terminal device is used to instruct the core network function entity to perform secondary authentication on the first user based on the identity identifier of the first terminal device.

[0366] Optionally, the sending module 1720 is used to send a first authentication method set to the core network function entity, the first authentication method set including the authentication method preferred by the first terminal device.

[0367] Figure 18 This is a schematic structural diagram of the communication device provided in the embodiments of this application. Figure 18 The communication device 1800 shown corresponds to the first terminal device described above. The communication device 1800 includes a processor 1802. In embodiments of this application, the processor 1802 is used to control and manage the actions of the first terminal device; for example, the processor 1802 is used to support the first terminal device in performing actions as described in the foregoing embodiments. Figures 3 to 11 The method, operation, or function shown. Optionally, the first terminal device may further include: a memory 1801 and a communication interface 1803; the processor 1802, the communication interface 1803, and the memory 1801 can be interconnected or interconnected via a bus 1804. The communication interface 1803 is used to support communication by the first terminal device, and the memory 1801 is used to store program code and data of the network device. The processor 1802 calls the code stored in the memory 1801 for control and management. The memory 1801 may or may not be coupled to the processor.

[0368] The processor 1802 can be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a digital signal processor and a microprocessor, etc. The communication interface 1803 can be a transceiver, circuit, bus, module, or other type of communication interface. The bus 1804 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 18The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0369] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0370] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0371] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0372] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0373] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0374] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0375] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method of two-factor authentication, characterized by, include: The authentication device in the second network receives the identity identifier of the first terminal device, and the identity identifier of the first terminal device corresponds to the identity identifier of the first network for first-level authentication of the first terminal device. The authentication device determines the identity identifier of the second network for secondary authentication of the first user based on the identity identifier of the first terminal device, wherein the identity identifier of the first user is different from the identity identifier of the first terminal device. The authentication device in the second network receives the identity identifier of the first terminal device, including: The authentication device in the second network receives a secondary authentication request, the secondary authentication request including the identity identifier of the first terminal device but excluding the identity identifier of the first user; and, The method further includes: The authentication device in the second network sends a secondary authentication response message, which instructs the first terminal device and the second network to perform secondary authentication for the first user.

2. The method according to claim 1, characterized in that, The identity identifier of the first terminal device is a publicly usable subscription identifier, GPSI.

3. The method according to claim 2, characterized in that, The identity identifier used by the first network for first-level authentication of the first terminal device is the user permanent identifier SUPI.

4. The method according to any one of claims 1 to 3, characterized in that, The first network is a carrier network, the second network is a data network, and the authentication device is the Authentication, Authorization and Accounting Server (AAA-S) in the data network.

5. The method according to any one of claims 1 to 3, characterized in that, The method further includes: The authentication device performs secondary authentication on the first user based on the first user's identity identifier.

6. The method according to claim 5, characterized in that, The secondary authentication is Extensible Authentication Protocol (EAP) authentication.

7. A method for two-level authentication, characterized in that, include: The core network function entity obtains the identity identifier of the first terminal device, and the identity identifier of the first terminal device corresponds to the identity identifier of the first network for first-level authentication of the first terminal device. The core network function entity sends the identity identifier of the first terminal device to the authentication device in the second network. The authentication device receives the identity identifier of the first terminal device and determines the identity identifier of the second network for secondary authentication of the first user based on the identity identifier of the first terminal device. The identity identifier of the first user is different from the identity identifier of the first terminal device. The core network function entity sends the identity identifier of the first terminal device to the authentication device in the second network, including: The core network function entity sends a secondary authentication request to the authentication device in the second network. The secondary authentication request includes the identity identifier of the first terminal device but excludes the identity identifier of the first user. The method further includes: The core network function entity receives a secondary authentication response message sent by the authentication device in the second network. The secondary authentication response message is used to instruct the first terminal device and the second network to perform secondary authentication for the first user. The core network function entity is the network function entity in the first network.

8. The method according to claim 7, characterized in that, The identity identifier of the first terminal device is a publicly usable subscription identifier, GPSI.

9. The method according to claim 8, characterized in that, The identity identifier used by the first network for first-level authentication of the first terminal device is the user permanent identifier SUPI.

10. The method according to any one of claims 7 to 9, characterized in that, The first network is a carrier network, the second network is a data network, and the authentication device is the Authentication, Authorization and Accounting Server (AAA-S) in the data network.

11. The method according to any one of claims 7 to 9, characterized in that, The method further includes: The authentication device performs secondary authentication on the first user based on the first user's identity identifier.

12. The method according to claim 11, characterized in that, The secondary authentication is Extensible Authentication Protocol (EAP) authentication.

13. The method according to any one of claims 7 to 9, characterized in that, The method further includes: The core network function entity sends a first message to the first terminal device, the first message being used to request the identity identifier of the first user; The core network function entity receives the second message sent by the first terminal device; When the second message does not include the identity identifier of the first user, the core network function entity performs secondary authentication on the first user based on the identity identifier of the first terminal device.

14. An authentication device, characterized in that, Includes modules or units for performing the method as described in any one of claims 1 to 6.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions that, when executed by a computer device, implement the method as described in any one of claims 1 to 6.

16. A network architecture, characterized in that, include: At least one of the core network functional entities and the authentication device in the second network. The core network function entity is used to obtain the identity identifier of the first terminal device, and the identity identifier of the first terminal device has a corresponding relationship with the identity identifier of the first network for first-level authentication of the first terminal device. The core network function entity is also used to send the identity identifier of the first terminal device to the authentication device in the second network. The authentication device is used to receive the identity identifier of the first terminal device and determine the identity identifier of the second network for secondary authentication of the first user based on the identity identifier of the first terminal device, wherein the identity identifier of the first user is different from the identity identifier of the first terminal device. The core network function entity is specifically used to send a secondary authentication request to the authentication device in the second network, wherein the secondary authentication request includes the identity identifier of the first terminal device but does not include the identity identifier of the first user; and The authentication device in the second network is further configured to send a secondary authentication response message, which instructs the first terminal device and the second network to perform secondary authentication for the first user.

17. The network architecture according to claim 16, characterized in that, The network architecture also includes a network opening function, which is used to securely open the external interface of the first network to the second network, wherein the first network is an operator network.

Images