Provide backward compatibility for authentication protocols specified by user equipment

Abstract

Embodiments of this disclosure relate to providing backward compatibility with authentication protocols specified by a user equipment. One technique includes determining a given authentication method or protocol specified by a user equipment. The technique includes receiving an access request corresponding to the user equipment from a wireless access point device. The access request includes data representing an identity associated with the user equipment. The technique includes providing backward compatibility with the given authentication protocol in response to receiving the access request. Providing backward compatibility includes providing a second request to a mobile network-based authentication server, the second request including the identity data and including data representing the given authentication protocol. The mobile network-based authentication server is associated with a Mobile Network Authentication Service Standard (MLS), and the given authentication protocol is not associated with a MLS.

Description

Background Technology

[0001] User equipment (UFO) with Wireless Local Area Network (WLAN) enabled can connect to a wireless access point device for the purpose of accessing the network. When a UFO first connects to an access point device, the UFO and the access point device exchange packets or frames as part of the process for accessing the UFO. Attached Figure Description

[0002] Figure 1 This is a block diagram of an Extensible Authentication Protocol (EAP) framework implemented according to an example. The framework includes a proxy server that enables EAP authentication method aggregation and adapts to EAP authentication methods based on current and previous generation mobile networks.

[0003] Figure 2A and Figure 2B The authentication message flow using the EAP authentication method aggregation scheme is described based on the example implementation.

[0004] Figure 3 The sequence stream is depicted, illustrating an example implementation of integrating a mobile network-based authentication server into an EAP authentication method aggregation scheme.

[0005] Figure 4 It is a flowchart depicting a technique, implemented according to an example, for providing backward compatibility with authentication protocols specified by the user device.

[0006] Figure 5 This is a block diagram of a system with a mobile network-based authentication server, implemented according to an example, which generates authentication vectors with values ​​not defined by the authentication service standard associated with the authentication server.

[0007] Figure 6 This is an illustration of a storage medium containing hardware processor-readable instructions implemented according to an example. When executed by a hardware processor, these hardware processor-readable instructions cause a proxy server to send an authentication information object to a mobile network-based authentication server, causing the server to apply a non-mobile network authentication method not defined by the authentication service standard associated with that authentication server. Detailed Implementation

[0008] A WLAN access point device (referred to herein as a “wireless access point device”) can be used as an authenticator or gatekeeper to control access to a WLAN created by the device. A WLAN-enabled user equipment (referred to herein as a “wireless user equipment”) gains access to the WLAN by successfully undergoing the access process and may gain access to larger network infrastructures such as local area networks (LANs) or wide area networks (WANs) through the wireless access point device.

[0009] As part of the access process, the Wireless User Equipment (UFO) and the Wireless Access Point (WAP) exchange packets or frames. Frame exchange, in addition to achieving other results, allows the UFO to associate with the WAP, inform the WAP of its capabilities, and provide identification information to the WAP. During access, frame exchange also provides information that allows the UFO and WAP to authenticate each other. In this context, "authentication" of a first entity by a second entity typically refers to the verification of the first entity's identity by the second entity. Frame exchange during access also provides information that allows the UFO and WAP to independently generate session keys that protect data communication between them (assuming successful mutual authentication).

[0010] Business entities may have enterprise networks that include one or more WLAN access networks (commonly referred to as “WiFi”) conforming to the Institute of Electrical and Electronics Engineers (IEEE) 802.11 series of WLAN standards. The WLAN access networks of an enterprise network may conform to WiFi security protocols designed for the business environment, such as the Wireless Protected Access 2-Enterprise (or “WPA2-Enterprise”) security protocol. The WPA2-Enterprise security protocol is described in the IEEE 802.1X-2020 standard (referred to herein as the “IEEE 802.1X standard”), titled “IEEE Standard for Local and Metropolitan Area Networks – Port-Based Network Access Control” and released on February 28, 2020. The IEEE 802.1X standard defines an Extensible Authentication Protocol (EAP) encapsulated over WLANs and LANs.

[0011] The EAP framework comprises an authentication server and one or more access point devices, such as wireless access point devices. The wireless access point device acts as an authenticator or gatekeeper to control access to the network. Based on identification information and other information provided by the wireless user equipment (e.g., credentials, such as values ​​provided by the wireless user equipment in response to authentication challenges), the authentication server verifies the identity of the wireless user equipment. If the authentication server successfully verifies the identity of the wireless user equipment, the wireless access point device allows the wireless user equipment to access the network. Otherwise, the wireless access point device denies the wireless user equipment access to the network. The wireless user equipment can use information provided by the network to authenticate itself, and therefore, if the wireless user equipment fails to authenticate with the network, it is disconnected from the wireless access point device.

[0012] Enterprise networks can use one of several EAP authentication methods (also referred to herein as "EAP authentication protocols," "authentication methods," or "authentication protocols"). For user equipment equipped with a mobile network radio (or "cellular radio") and therefore mobile network enabled, the EAP framework can rely on a mobile network-based authentication server and make full use of the subscriber identity module (referred to herein as "identity module") of the wireless user equipment. In one example, the identity module can be a physical subscriber identity module or "SIM," and in another example, the identity module can be an embedded SIM or "eSIM." One type of EAP authentication method (also referred to herein as "shared secret-based EAP authentication method") can rely on a shared secret. The shared secret can be directly represented by or derived from data stored in the identity module. In an example, the shared secret can be a cryptographic hash derived from data stored in the identity module (e.g., data representing International Mobile Subscriber Identity (IMSI)). This secret is "shared" because both the wireless user equipment and the authentication server know the secret.

[0013] The EAP framework includes a proxy server that communicates on behalf of the enterprise network with a mobile network-based authentication server. The proxy server acts as a communication bridge, translating between the authentication and authorization messaging protocols used by the wireless access point devices and the application programming interface (API)-based communication protocols used by the mobile network-based authentication server.

[0014] In one approach, a mobile network-based authentication server is associated with a specific shared-secret-based EAP authentication method. In an example, for a fourth-generation (or “4G”) mobile network, the authentication server (referred to herein as the “4G authentication server”) may be limited to using the EAP authentication and key agreement (or “EAP-AKA”) authentication method for shared-secret-based EAP authentication. In another example, for a fifth-generation (5G) mobile network, the EAP-AKA authentication method has been superseded by the EAP-AKA' (or “EAP-AKA master”) authentication method. Unlike the EAP-AKA authentication method, the EAP-AKA' authentication method binds the generated session key to the access network name. Because the EAP-AKA authentication method has been superseded by the EAP-AKA' authentication method, the 5G mobile network-based authentication server (referred to herein as the “5G authentication server”) does not support the superseded EAP-AKA authentication method.

[0015] User equipment (UE) can be configured (e.g., by options in the UE's WPA2-Enterprise profile) to specify a particular EAP authentication method that will be used for WPA2-Enterprise authentication. The specified EAP authentication method is independent of the available mobile networks(s) and can be downgraded from the UE's full mobile network capabilities. It is not uncommon for 5G-enabled wireless UEs to specify the EAP-AKA authentication method (instead of the EAP-AKA authentication method defined by the 5G authentication service standard). Since a given wireless device can specify an EAP authentication method available on either a 4G authentication server or a 5G authentication server, the EAP framework's proxy server is constructed in one approach to accommodate either choice. In this way, in one approach, the EAP framework's proxy server has both a 4G mobile network interface (for communicating with the 4G authentication server) and a 5G mobile network interface (for communicating with the 5G authentication server). For a UE specifying the EAP-AKA authentication method, the proxy server uses its 4G mobile network interface to invoke the 4G network authentication function served by the 4G authentication server. For user equipment that uses the specified EAP-AKA authentication method, the proxy server uses its 5G mobile network interface to invoke the 5G authentication function provided by the 5G authentication server.

[0016] Supporting both 4G and 5G mobile network interfaces in an EAP framework can present certain challenges. For example, the communication protocol used by the proxy server to communicate with the 4G authentication server (e.g., the Diameter protocol) differs from the communication protocol used by the proxy server to communicate with the 5G authentication server (e.g., the Service-Based Interface (SBI) protocol). Therefore, supporting both 4G and 5G mobile network interfaces complicates parts of the enterprise network's EAP framework. Another challenge related to supporting both 4G and 5G mobile network interfaces is that user equipment information may be unavailable on the mobile network side. 4G authentication servers rely on a Home Subscriber Server (HSS), while 5G authentication servers rely on a User Identity Management (UDM) database. It is possible that wireless user equipment could attempt to wirelessly connect to a WPA2-based enterprise network in a geographic location where the serving mobile network does not allow authentication servers (e.g., 4G authentication servers) to access the appropriate user database (e.g., the HSS).

[0017] Based on the example implementation described in this paper, the EAP framework for enterprise networks relies on a single authentication server (e.g., a 5G authentication server) to handle both the EAP-AKA and EAP-AKA' authentication methods. This simplifies the design of proxy servers for enterprise networks by using a single authentication server to handle both EAP-AKA and EAP-AKA' authentication methods. Furthermore, using a single authentication server corresponds to using a single database (e.g., a UDM database) to retrieve user equipment identification information. Therefore, by using a 5G authentication server (as an example), the EAP-AKA authentication method can be used without relying on the availability of 4G HSS.

[0018] According to the example implementation, the EAP framework includes a 5G authentication server and a proxy server (referred to as the "proxy server" in this document) that enables authentication method aggregation. The 5G Authentication Service Standard defines an API for accessing authentication functions provided by the 5G Authentication Server. More specifically, API calls to 5G authentication functions pass an authentication information object (e.g., a JavaScript Object Notation (JSON) object) that defines the properties of the requested authentication. The 5G Authentication Service Standard defines the authentication type as one of the properties of the authentication information object. In the schema definition for the authentication information object, the 5G Authentication Service Standard defines an enumeration string type and lists specific enumeration strings for that enumeration string type (e.g., "5G_AKA", "EAP_AKA_PRIME", "EAP_TLS", and "EAP_TTLS"). The enumeration strings correspond to the respective authentication methods supported or associated with the 5G Authentication Service Standard. Because the EAP-AKA authentication method in the 5G Authentication Service Standard is replaced by the EAP-AKA' authentication method, the EAP-AKA authentication method is not supported or associated with the 5G Authentication Service Standard. Therefore, the 5G authentication service standard does not define an enumeration string for the EAP-AKA authentication method, such as "EAP_AKA" (or a variant thereof).

[0019] According to the example implementation described herein, the proxy server leverages the features of the schema definition for authentication information objects in the 5G Authentication Service standard to notify the 5G Authentication Server to use the EAP-AKA authentication method. More specifically, according to the example implementation, the schema definition (in addition to defining enumerated string types) defines non-enumerated generic string types for authentication types. The proxy server is constructed to use a string corresponding to the non-enumerated string type to notify the 5G Authentication Server when to use the EAP-AKA authentication method. In this way, in response to a wireless user equipment specifying the use of the EAP-AKA authentication method, the proxy server includes a specific non-enumerated string (e.g., EAP_AKA) in the authentication object as the authentication type to inform the 5G Authentication Server to use the EAP-AKA authentication method. According to the example implementation, the proxy server is also constructed to notify the 5G Authentication Server to use the standard-supported "EAP_AKA_PRIME" enumerated string in response to a wireless user equipment specifying the use of the EAP-AKA authentication method.

[0020] Among the potential advantages of the EAP authentication aggregation technology described in this paper is its backward compatibility, enabling the EAP-AKA authentication method specified by the user equipment to be applied by the 5G authentication server even if the 5G authentication server is not associated with the EAP-AKA authentication method. Another benefit of the EAP authentication aggregation technology described in this paper is that the proxy server has a single mobile network interface, which simplifies the proxy server design. Yet another benefit is that the EAP authentication aggregation technology provides backward compatibility in a manner that conforms to and therefore does not modify the 5G authentication service standard.

[0021] refer to Figure 1 As a more specific example, according to some implementations, the EAP framework 99 controls WLAN access to the enterprise network 100 by user equipment (also referred to as "user equipment", "user facility", "client station", "mobile station", "mobile device", "requester" or "requester device") that has enabled WLAN and mobile networks. Figure 1 An example user equipment 110 (referred to herein as "wireless user equipment 110") is depicted, which has both WLAN and mobile network radios that allow the wireless user equipment 110 to wirelessly connect to and communicate with both a WLAN and a mobile network. Figure 1 A wireless user equipment 110 is depicted that is connected to a wireless access point device 158 of an enterprise network 100 via a WLAN link 154.

[0022] Wireless User Equipment 110 includes an identity module 114 (e.g., a physical SIM or eSIM) that stores data representing identification information associated with a mobile device subscriber of Wireless User Equipment 110. In one example, the identification information includes data representing a Network Access Identity (NAI) 119 (e.g., a network domain associated with Corporate Network 100, such as “@CompanyABC.com”). In another example, the identification information includes data representing an International Mobile Subscriber Identifier (IMSI) 121.

[0023] EAP framework 99 includes an authentication server 183 (e.g., a 5G authentication server) hosted by mobile network resource 174. According to the example implementation, authentication server 183 is configured to perform authentication and key agreement services to manage network access for wireless user equipment (such as wireless user equipment 110). For this purpose, according to the example implementation, the identity module 114 of wireless user equipment 110 stores data corresponding to an authentication secret 118 shared with authentication server 183.

[0024] In this example, authentication secret 118 is a cryptographic hash or cryptographic key directly represented by the data stored in identity module 114. On the mobile network side, authentication server 183 retrieves the authentication secret from UDM service 190 based on, for example, the IMSI 121 of the wireless user equipment. In another example, authentication secret 118 is not directly represented by the data stored in identity module 114, but instead, authentication secret 118 is a cryptographic hash derived from the data stored in identity module 114 (e.g., a key cryptographic hash of IMSI 121). On the mobile network side, authentication server 183 applies the same cryptographic hash to obtain authentication secret 118.

[0025] In addition to storing data, according to the example implementation, the identity module 114 is configured to perform operations related to access of the wireless user equipment 110. In another example, the operations include communicating EAP frames with the wireless access point device 158. In this example, the operations include actions corresponding to the algorithm used to perform the EAP authentication method.

[0026] Wireless User Equipment 110 is configured to specify a particular EAP authentication method (i.e., a specific EAP authentication method that will be used by Wireless User Equipment 110 and by the authentication server). In the example, the specified EAP authentication method corresponds to a user-selectable WPA2-Enterprise option (e.g., selected via input provided by the user) that forms part of the Wireless User Equipment's WPA2-Enterprise profile. In another example, the manufacturer of Wireless User Equipment 110 configures Wireless User Equipment 110 to specify a particular EAP authentication method. In yet another example, the mobile network operator (MNO) associated with Wireless User Equipment 110 configures Wireless User Equipment 110 to specify a particular EAP authentication method. Regardless of how Wireless User Equipment 110 is configured to specify its EAP authentication method, according to the example configuration, Wireless User Equipment 110 stores data 120 representing the specified EAP authentication method.

[0027] According to the example implementation described herein, the specified EAP authentication method is a shared-secret-based EAP authentication method, such as the EAP-AKA authentication method or EAP-AKA' authentication method. Shared-secret-based EAP authentication methods contrast with certificate-based EAP authentication methods (e.g., EAP-TLS or EAP-TTLS authentication methods), which rely on digital certificates stored on the user's device. The EAP-AKA authentication method is described in Request for Comments (RFC) No. 4187, published by the Network Working Group (January 2006), entitled "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)". The EAP-AKA authentication method is described in RFC No. 5448, titled "Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')," published by the Network Working Group (May 2009).

[0028] In addition to authentication server 183, EAP framework 99 also includes components of enterprise network 100, including a proxy server (referred to herein as "proxy server 164") with EAP authentication method aggregation enabled and one or more wireless access point devices 158. Wireless access point device 158 acts as an authenticator or gatekeeper to control whether associated wireless user equipment (such as wireless user equipment 110) can connect to the WLAN (access network) created by wireless access point device 158. Wireless access point device 158 can also control user equipment access to the larger network infrastructure behind wireless access point device 158 (e.g., one or more LANs, WANs, etc. of enterprise network 100) based on the access permissions of the wireless user equipment.

[0029] To access WLAN-enabled user equipment (such as wireless user equipment 110), wireless access point device 158 and WLAN-enabled user equipment wirelessly transmit packets or frames according to the EAP or "EAPoL" protocol over the LAN. According to the example implementation, proxy server 164 and wireless access point device 158 communicate with each other using the messaging protocol described in RFC No. 2865, entitled "Remote Authentication Dial-In Service (RADIUS)," published by the Network Working Group (June 2000). Proxy server 164 can typically be characterized as a RADIUS server, with its authentication and authorization functions offloaded to authentication server 183.

[0030] According to the example implementation, mobile network resource 174 corresponds to a 5G telecommunications system defined by the technical specifications standards stipulated by the 3rd Generation Partnership Project (3GPP). Mobile network resource 174 is part of the 5G mobile network core and is associated with a specific MNO. Enterprise network 100 is not defined by 3GPP standards and is not associated with an MNO. From the perspective of the mobile network, enterprise network 100 can be regarded as an untrusted 3GPP network because enterprise network 100 is not under the control of the mobile network MNO. Authentication server 183 provides 3GPP authentication and authorization services to manage non-3GPP network access made by radio user equipment (such as radio user equipment 110).

[0031] According to the example implementation, authentication server 183 provides authentication services as defined herein by standards referred to as the “5G Authentication Service Standard,” such as version 18 or a variant of 3GPP Technical Specification (TS) 29.509 entitled “Authentication Server Services,” version 18.5.0 (June 2024), published in the United States by the Telecommunications Industry Technology Solutions Alliance (ATIS). Furthermore, as described herein, according to the example implementation, authentication server 183 provides additional services besides the authentication services defined by the 5G Authentication Service Standard (such as providing operations corresponding to the algorithm performing the EAP-AKA authentication method). Since the EAP authentication method is associated with controlling access to non-3GPP networks that do not conform to 3GPP standards, the EAP authentication method may be referred to as a non-3GPP authentication method, or it may also be referred to as a “non-mobile network authentication method.”

[0032] According to the example implementation, authentication server 183 provides or serves front-end authentication server functionality 184 (referred to herein as "AUSF 184") to provide authentication and authorization services to manage non-3GPP access, such as managing WLAN access to an enterprise network (e.g., enterprise network 100). As further described herein, proxy server 164 communicates with AUSF 184 using API 186 provided by authentication server 183. According to the example implementation, in addition to serving AUSF 184, authentication server 183 also serves back-end authentication certificate and repository functionality 185 (referred to herein as "ARPF 185"). According to the example implementation, AUSF 184 can invoke ARPF 185 to generate authentication vector values ​​conforming to a specific EAP authentication method specified by the user equipment.

[0033] In the context used herein, an Application Programming Interface, or “API,” refers to a collection of software components that establish relationships between inputs and outputs. For this purpose, the software components collectively provide one or more functions, operations, or actions. As described herein, an API request (or “API call”) is input provided by a requester (such as proxy server 164) and intended to invoke one or more functions, operations, or actions of a specific API to produce one or more outputs. In response to a specific API request, the API can provide output, referred to as an “API response,” which is sent back to the requester. In the example, AUSF 184 provides a Service-Based Interface (SBI); and API requests and API responses, similar to the Representational State Transfer (REST) ​​protocol, are transmitted between proxy server 164 and authentication server 183 using Hypertext Transfer Protocol 2 (or “HTTP / 2”) messaging.

[0034] As shown below Figure 2A , Figure 2B and Figure 3 As described in more detail, EAP frameworks (such as EAP Framework 99) use sequences of operations to mutually authenticate user equipment and the enterprise network. Still refer to Figure 1 In summary, the wireless access point device 158 initiates authentication-related operations for the wireless user equipment 110 by sending a request to the proxy server 164 to authenticate the wireless user equipment 110. In response to receiving the authentication request, the proxy server 164 uses the authentication server 183 to initiate a session referred to herein as an "EAP authentication session" (or "EAP session").

[0035] In the context used herein, "session" generally refers to a temporary communication period that begins when a user equipment (e.g., wireless user equipment 110) is associated with an access point device (e.g., wireless access point device 158) and ends when the user equipment is no longer associated with the access point device. A session key generally refers to a cryptographic artifact generated specifically for use in a particular session. In the example, a session key may be used to encrypt and / or decrypt communication between the user equipment and the access point device. In another example, a session key may be a seed key or ancestor key of a cryptographic key hierarchy from which one or more other keys are derived. An EAP session with authentication server 183 refers to a temporary communication period associated with the authentication of a user equipment (e.g., wireless user equipment 110).

[0036] As part of initiating an EAP session, proxy server 164 instructs authentication server 183 to apply a specific EAP authentication method selected by wireless user equipment 110. More specifically, according to the example implementation, proxy server 164 submits an API call to API 186 to invoke AUSF 184 and initiate an EAP session. The API call provides authentication information to authentication server 183, including information identifying wireless user equipment 110 and data identifying the EAP authentication method specified by wireless user equipment 110. In the example, proxy server 164 providing the API call corresponds to proxy server 164 providing an authentication information object (e.g., a JSON object) via HTTP / 2 POST to the " / ue authentication" path of the URL corresponding to AUSF 184. This authentication information object includes a string that represents or corresponds to the EAP authentication method type (referred to as "AuthType") specified by wireless user equipment 110.

[0037] In one example, Wireless User Equipment 110 specifies the EAP-AKA' authentication method, and AuthType corresponds to the string "EAP_AKA_PRIME". The EAP-AKA' authentication method is associated with the 5G Authentication Service Standard. In this context, an authentication method (or "authentication protocol", "EAP authentication method", or "EAP authentication protocol") is "associated" with a standard such as the 5G Authentication Service Standard, referring to an authentication method identified (e.g., mentioned) by that standard. For example, the EAP-AKA' authentication method is one of four enumerated method types identified by the 5G Authentication Service Standard (e.g., 5G AKA, EAP-AKA', EAP-TLS, and EAP-TTLS), while other non-enumerated authorization method types (such as the EAP-AKA authentication method) are not identified or mentioned by the 5G Authentication Service Standard. In this example, the 5G Authentication Service Standard specifies an enumeration set of five strings for the AuthType of the authentication information object (e.g., "5G_AKA", "EAP_AKA_PRIME", "EAP_TLS", and "EAP_TTLS").

[0038] In another example, wireless user equipment 110 specifies the EAP-AKA authentication method, and for this example, AuthType corresponds to the string "EAP_AKA". The 5G Authentication Service Standard is neither associated with the EAP-AKA authentication method nor does it reference or define a string such as "EAP_AKA" for AuthType that references the EAP-AKA authentication method. However, the 5G Authentication Service Standard's Authentication Information Object schema defines a generic string type for AuthType. Proxy server 164 notifies authentication server 183 that the EAP-AKA authentication method will be used to leverage this generic string type by setting AuthType to "EAP_AKA" in the Authentication Information Object.

[0039] Authentication server 183 responds to API calls by generating authentication vector components (or values) according to the specified EAP authentication method. An authentication vector is a set of authentication-related tokens (or values) used to authenticate wireless user equipment 110, authenticate enterprise network 100, and obtain session keys to protect communication between wireless user equipment 110 and wireless access point device 158. Therefore, authentication server 183 authenticates wireless user equipment 110 based on the authentication vector, and wireless user equipment 110 authenticates enterprise network 100 based on the same authentication vector. As described herein, both authentication server 183 and wireless user equipment 110 independently apply the specified EAP authentication method to generate authentication vector values. To generate authentication vector values ​​on the mobile network side, according to the example implementation, AUSF 184 calls backend ARPF 185, which returns the authentication vector values ​​to AUSF 184.

[0040] Authentication server 183 responds to API calls initiated by an EAP session from proxy server 164 by providing an API response. The API response contains data representing a generated resource URL. The resource URL is a URL path corresponding to a specific EAP session identifier (ID) and serves as the destination for other API calls made by proxy server 164 in relation to the EAP session. The API response also contains data representing attributes corresponding to specific tokens or values ​​in the authentication vector, which are components of the authentication challenge request for wireless user equipment 110. As further described herein, the authentication challenge request is routed to wireless user equipment 110, and the corresponding authentication challenge response from the wireless user equipment is routed back to proxy server 164.

[0041] More specifically, in response to receiving an authentication challenge response from a wireless user equipment (UAE), proxy server 164 provides another API call to authentication server 183 for the same EAP session. This API call transmits the token from the authentication challenge response to AUSF function 184. In this example, the API call corresponds to proxy server 164 providing an HTTP / 2POST to the resource URL identified in the previous API response provided by authentication server 183. The HTTP / 2POST provides data representing the token from the UAE's authentication challenge response. In response to the HTTP / 2POST, authentication server 183 applies the specified EAP authentication method to verify the authentication challenge response. Authentication server 183 provides an API response indicating the authentication result (e.g., an API response indicating successful or failed authentication). In response to successful authentication of UAE 110, the API response includes an encryption key (e.g., MSK), from which a session key protecting data communication over WLAN link 154 can be obtained.

[0042] The mobile network resources 174 of access point device 158, proxy server 164, and managed authentication server 183 are interconnected via network structure 160. According to the example implementation, network structure 160 can be associated with one or more types of communication networks, such as a compute eXpress link (CXL) structure, a private management network, a local area network (LAN), a wide area network (WAN), a wireless network, or any combination thereof. Network structure 160 can include a private network structure of enterprise network 100, a private network structure associated with mobile network resources 174, and a public network structure.

[0043] Wireless User Equipment 110 can have any of many different architectures according to a number of possible implementations. Depending on some implementations, Wireless User Equipment 110 can be a computer platform, which may or may not be portable. In the examples, Wireless User Equipment 110 can be a mobile phone device, an Internet of Things (IoT) device; a sensor; a wearable computer; a process controller; an access point device; a Wi-Fi pod device; a Wi-Fi extender device; a desktop computer, a portable computer, a laptop computer, a tablet computer, a smartphone, a wearable computer, or any other electronic device having an identity module and a communication interface capable of communicating with the access point device.

[0044] Enterprise network 100 can have any of many different architectures and purposes. In one example, enterprise network 100 is an edge computing system. In another example, enterprise network 100 is a private cloud-based computing system. In this context, "cloud-based computing system" refers to a collection of resources that can be scaled up or down as needed. In another example, enterprise network 100 is a hybrid cloud-based computing system, which includes a private cloud-based computing system and one or more public cloud-based computing systems. In yet another example, enterprise network 100 is a non-cloud-based computing system. In addition to the wireless access point devices(s) 158, proxy servers 164, and network infrastructure components, enterprise network 100 also has various network components 161, such as servers, client devices, storage devices, and so on.

[0045] According to the example implementation, proxy server 164 includes one or more hardware processors. A specific hardware processor corresponds to one or more physical processing cores 166 (e.g., a central processing unit (CPU) core). In one example, proxy server 164 corresponds to one or more virtual machines. In another example, proxy server 164 corresponds to a container hosted on a virtual machine. In another example, proxy server 164 corresponds to a container pod. In another example, proxy server 164 corresponds to an orchestrated container cluster. In another example, proxy server 164 corresponds to a bare metal environment. In yet another example, proxy server 164 corresponds to one or more physical servers (e.g., one or more blade servers, rack servers, or tower servers).

[0046] In addition to having one or more physical processing cores 166, the proxy server 164 also includes a memory 168. The memory 168 stores hardware processor-readable instructions 169, which, when executed by the hardware processor, cause the proxy server 164 to perform the operations described herein. Proxy server 164 receiving and processing one or more requests sent by wireless access point device 158 is an example of such operation. Proxy server 164 generating and sending requests or responses to wireless access point device 158 is an example of such operation. Proxy server 164 determining the EAP authentication method selected by wireless user equipment 110 is another example of such operation. Proxy server 164 communicating with authentication server 183, including performing operations associated with an EAP session (e.g., providing API calls and receiving API responses), is another example of such operation. Proxy server 164 generating an authentication information object and embedding an AuthType string representing the authentication method specified by the wireless user equipment is another example of such operation. Another example of this operation is that proxy server 164 includes a generic string in the authentication information object to represent the specified EAP authentication method and sends the authentication information object to authentication server 183. Another example of this operation is that proxy server 164 includes an enumerated string in the authentication information object to represent the specified EAP authentication method and sends the authentication information object to authentication server 183.

[0047] Typically, memory 168 and other memories and storage media described herein can be formed of non-transient memory devices, such as semiconductor memory devices, flash memory devices, memristors, phase-change memory devices, and combinations of one or more of the aforementioned memory technologies. Furthermore, memory devices can be volatile memory devices (e.g., dynamic random access memory (DRAM) devices, static random access memory (SRAM) devices, etc.) or non-volatile memory devices (e.g., flash memory devices, read-only memory (ROM) devices, etc.), unless otherwise stated herein.

[0048] According to the example implementation, mobile network resource 174 is associated with the mobile core network and is under the control of the MNO. Mobile network resource 174 includes one or more hardware processors. A given hardware processor may include one or more physical processing cores 178 (e.g., CPU cores), which may reside on one or more processing nodes 176. Authentication server 183 may correspond to one or more processing nodes 176. In one example, processing node 176 corresponds to one or more virtual machines. In another example, processing node 176 corresponds to a container hosted on a virtual machine. In another example, processing node 176 corresponds to a container pod. In another example, processing node 176 corresponds to an orchestrated container cluster. In another example, processing node 176 corresponds to a bare metal environment. In yet another example, processing node 176 corresponds to a physical server (e.g., a blade server, rack server, or tower server).

[0049] In addition to having one or more physical processing cores 178, the processing node 176 also includes memory 180. Memory 180 stores hardware processor readable instructions 182, which, when executed by the hardware processor, enable the authentication server 183 to provide APIs, such as API 186.

[0050] In a more specific example, when executed by the hardware processor, instruction 182 causes the hardware processor to provide one or more API handlers to provide AUSF-related services. In another example, when executed by the hardware processor, instruction 182 causes the hardware processor to provide ARPF-related services. In yet another example, when executed by the hardware processor, instruction 182 causes the hardware processor to service API calls to apply the EAP authentication method selected by the user equipment (e.g., wireless user equipment 110) to generate authentication vector values ​​and provide corresponding API responses. In this example, providing the API response includes providing data representing a challenge request to wireless user equipment 110 and data representing a URL resource path for the EAP session.

[0051] In another example, when executed by the hardware processor, instruction 182 provides an API handler to cause the hardware processor to serve API calls pointing to a URL resource path corresponding to an EAP session. The API handler verifies the challenge response provided by the user equipment (such as wireless user equipment 110) and provides an API response (e.g., an API response including data indicating the result of authentication and / or data indicating from which a higher-level encryption key is obtained for the session key). In another example, when executed by the hardware processor, instruction 182 provides an API handler to cause the hardware processor to serve API calls that generate one or more encryption keys.

[0052] Figure 2A and Figure 2B This describes an authentication and key agreement sequence stream 200 based on an example implementation, depicting the actions and messaging performed by components of the EAP framework. (Reference) Figure 2A The EAP framework includes components of enterprise network 207: a proxy server 212 (referred to herein as "proxy server 212") that enables EAP authentication method aggregation and a wireless access point device 208. Additionally, the EAP framework includes an authentication server 216 (e.g., a 5G authentication server) hosted by resources of mobile network 215.

[0053] According to sequence stream 200, wireless access point device 208 and wireless user equipment 204 exchange frames corresponding to requests and responses. In the example, wireless user equipment 204 has a WLAN radio and a mobile network radio. Wireless user equipment 204 also includes an identity module (e.g., SIM or eSIM). The identity module stores data that directly represents the authentication secret or information from which the authentication secret can be obtained. Wireless user equipment 204 also stores data representing the key-based EAP authentication method specified for device 204. In the following discussion, it is assumed that wireless user equipment 204 specifies the EAP-AKA authentication method or the EAP-AKA' authentication method. In the example, wireless access point device 208 is a WiFi device that conforms to the IEEE 802.11 series of standards and establishes a WLAN network.

[0054] To enable wireless user equipment 204 to access enterprise network 207, wireless user equipment 204 and wireless access point device 208 exchange EAP frames. EAP frames correspond to EAP messages and EAP responses. Among other uses, EAP messages and EAP responses provide information for exchanging information that allows enterprise network 207 to authenticate wireless user equipment 204 and allows wireless user equipment 204 to authenticate enterprise network 207. Furthermore, through the exchange of EAP frames, wireless user equipment 204 and wireless access point device 208 agree on a session key, which will be used to ensure secure communication between wireless user equipment 204 and wireless access point device 208 (assuming successful mutual authentication). In the example, Figure 1 The wireless user equipment 110, wireless access point equipment 158, proxy server 164 and authentication server 183 correspond to wireless user equipment 204, wireless access point equipment 208, proxy server 212 and authentication server 216, respectively.

[0055] At the start of the access procedure, Wireless User Equipment 204 is initially in a state where it is neither authenticated nor associated with Wireless Access Point Device 208. Wireless User Equipment 204 initiates the access procedure by wirelessly connecting to Wireless Access Point Device 208 to initiate an association sub-procedure. According to the example implementation, Wireless Access Point Device 208 initially restricts communication between Wireless User Equipment 204 and Wireless Access Point Device 208 to EAP management-related frames (e.g., Wireless Access Point Device 208 discards any data frames sent by Wireless User Equipment 204). In response to Wireless User Equipment 204 transitioning to a state where it is associated with Wireless Access Point Device 208 and has passed what is referred to herein as “Advanced Authentication,” Wireless Access Point Device 208 removes the restrictions.

[0056] As a more specific example, the access process includes the wireless user equipment 204 first communicating with the wireless access point device 208 to perform "low-level authentication." As an example, low-level authentication could be Open Systems Authentication as described in the IEEE 802.11 standard. As a more specific example, the wireless user equipment 204 could send an IEEE 802.11 authentication frame to the wireless access point device 208. The wireless access point device 208 could then respond to the authentication frame with an authentication response frame, placing the wireless user equipment 204 in a state where it has undergone low-level authentication but is not yet associated with the wireless access point device 208.

[0057] Next, as part of the access procedure, as depicted at 222, access point device 208 associates with wireless user equipment 204, and as part of the association, access point device 208 determines the EAP authentication method specified by wireless user equipment 204. More specifically, wireless access point device 208 and wireless user equipment 204 perform association-related messaging 218. In the example, association-related messaging 218 includes wireless user equipment 204 first sending an association request frame to wireless access point device 208. The association request frame may contain data representing the capabilities of wireless user equipment 204 (e.g., encryption type, supported rates, supported channels, quality of service (QoS) capabilities, and other attributes). In the example implementation, the association request frame contains data representing the EAP authentication method specified by wireless user equipment 204 (e.g., EAP-AKA or EAP-AKA').

[0058] Assuming the capabilities of wireless user equipment 204 match those of wireless access point device 208, then as part of association-related message passing 218, wireless access point device 208 sends an association frame containing the association identifier (ID) of wireless user equipment 204. At this point, association message passing 218 is complete, wireless user equipment 204 has a low-level authentication status, and wireless user equipment 204 is associated with wireless access point device 208.

[0059] Next, sequence 200 includes the exchange of frames corresponding to Advanced Mutual Authentication (EMA), providing information that the enterprise network 207 can authenticate the wireless user equipment 204 and that the wireless user equipment 204 can authenticate the enterprise network 207. The exchange of frames begins with the wireless access point device 208 sending an EAP Identity Request 224 to the wireless user equipment 204, requesting identification information from the wireless user equipment 204. The wireless user equipment 204 responds to the EAP Identity Request 224 by sending an EAP Identity Response 226 to the wireless access point device 208. In this example, the EAP Identity Response 226 includes data representing the NAI and IMSI associated with the wireless user equipment 204. In this example, the processing of the EAP Identity Request 224 (including the generation of the EAP Identity Response 226) is handled by the identity module of the wireless user equipment.

[0060] In response to receiving the EAP identity response 226, the wireless access point device 208 generates an authentication request 230 (e.g., a RADIUS access request message) and sends it to the proxy server 212 (as depicted at 228). The authentication request 230 contains data representing information that the authentication server 216 processes to generate an authentication vector component and a token for an authentication challenge request to the wireless user equipment 204. In this example, the authentication request 230 contains data representing identification information of the wireless user equipment 204, such as data representing the NAI and IMSI of the wireless user equipment 204. In this example, the authentication request 230 also contains data representing the EAP authentication method specified by the wireless user equipment 204.

[0061] The authentication request 230 may also include data representing information specific to the specified EAP authentication method. For example, if the wireless user equipment 204 specifies the EAP-AKA authentication method, the wireless access point device 208 includes data in the authentication request 230 representing the access network name (e.g., the name of the corresponding WLAN), because the EAP-AKA authentication method binds the encryption key to the access network name. In other words, the EAP-AKA authentication method binds the authentication vector to the access network name, because some values ​​of the authentication vector are bound to the access network name. In another example, regardless of the specific EAP authentication method specified, the wireless access point device 208 includes data representing the access network name in the authentication request 230, and the authentication server 216 may or may not use this information.

[0062] Sending an authentication request 230 to proxy server 212 prompts proxy server 212 (as depicted at 232) to provide API call 234 to authentication server 216 to initiate an EAP session. In the example, when preparing to provide API call 234, proxy server 212 determines the EAP authentication method specified by wireless user equipment 204 and generates an authentication information object (e.g., a JSON object). Proxy server 212 includes a string (corresponding to the AuthType property of the authentication information object) in the authentication information object that identifies the EAP authentication method. In the example, providing API call 234 involves proxy server 212 sending an HTTP / 2 POST request to the URL path (e.g., " / ue authentication") corresponding to the AUSF of authentication server 216.

[0063] Proxy server 212 embeds additional information in the authentication object associated with API call 234, depending on the specific EAP authentication method specified. In the example, for the EAP-AKA authentication method, proxy server 212 includes the user equipment's NAI and IMSI as an example. In another example, for EAP-AKA authentication, proxy server 212 includes, in addition to the user equipment's NAI and IMSI, the access network name (e.g., the WLAN name associated with access point device 208).

[0064] In response to API call 234, authentication server 216 (as depicted at 236) determines the authentication vector value, determines the attributes of the challenge request to wireless user equipment 204, and provides a corresponding API response 240 (which is sent back to proxy server 212). More specifically, according to the example implementation, in response to API call 234, the authentication server's AUSF relies on the backend ARPF to generate the authentication vector value using the specified EAP authentication method. In the context used herein, the attribute corresponding to the authentication vector value refers to an attribute containing data representing that authentication vector value. Attributes may also contain data representing additional information besides the authentication vector value (e.g., data corresponding to the attribute identifier, data indicating the length of the attribute, etc.).

[0065] The authentication vector of the EAP-AKA authentication method can be described as follows:<RAND,AUTN,RES,CK,IK> The authentication server 216 uses the EAP-AKA authentication method to generate the RAND, AUTN, CK, and IK values ​​of the authentication vector. The authentication vector of the EAP-AKA authentication method can be described as follows:<RAND,AUTN,RES,CK',IK'> The authentication server 216 uses the EAP-AKA authentication method to generate the RAND, AUTN, CK', and IK' values ​​of the authentication vector.

[0066] The RAND and AUTN values ​​correspond to the AT_RAND and AT_AUTN attributes, respectively. The AT_AUTN attribute is verified by the wireless user equipment 204 so that the wireless user equipment 204 can authenticate the network 207. The AT_RAND and AT_AUTN attributes are included in the authentication challenge request to the wireless user equipment 204. The authentication server 216 generates a RAND value randomly or pseudo-randomly, which serves as the authentication challenge value for the wireless user equipment 204. The wireless user equipment 204 applies a key cryptographic hash algorithm that receives the AT_RAND attribute as input and a key input corresponding to the user equipment's secret to produce a challenge response value called "RES". The authentication server 216 expects the RES value to be equal to the expected RES value, which is called the "XRES value".

[0067] API response 240 includes data representing an authentication challenge request to wireless user equipment 204. In addition to the AT_RAND and AT_AUTN attributes, the authentication challenge request also includes a Message Authentication Code (MAC) attribute called “AT_MAC,” which wireless user equipment 204 processes to authenticate the authentication challenge request. Besides the authentication challenge request, API response 240 also includes data representing a URL resource path, which includes the EAP session ID and is used by proxy server 212 to POST the authentication challenge response from wireless user equipment 204, as further described herein.

[0068] The CK and IK values ​​correspond to the encryption key and integrity key generated by the EAP-AKA authentication method, respectively. The CK and IK values ​​correspond to the high-level session keys in the session key hierarchy. The low-level session keys in the session key hierarchy are derived from the CK and IK values ​​and are used to ensure secure data communication between user equipment 204 and wireless access point equipment 208 (assuming successful mutual authentication).

[0069] According to the EAP-AKA authentication method, authentication server 216 obtains an encryption key from the CK and IK values. For example, authentication server 216 obtains a key based on the CK and IK values, which serves as the key input for an encryption hash algorithm that generates the MAC value and the corresponding AT_MAC attribute. Furthermore, using the EAP-AKA authentication method, authentication server 216 obtains another session key (e.g., MSK) from the CK and IK values. From this other session key, a low-level pairwise transient key (PTK) for unicast service encryption / decryption can be obtained, and a group transport key (GTK) for multicast service encryption / decryption can also be obtained.

[0070] Similar to the CK and IK values, the CK' and IK' values ​​correspond to the higher-level session keys at the session key level; and the lower-level session keys at the session key level are derived from the CK' and IK' values ​​for various uses. For example, authentication server 216 uses the CK' and IK' values ​​to obtain a key that acts as the key input to the cryptographic hash algorithm that generates the MAC value (from which the AT_MAC token is obtained). In another example, authentication server 216 uses the CK' and IK' values ​​to obtain a session key to ensure secure data communication between user equipment 204 and wireless access point device 208 (assuming successful mutual authentication).

[0071] Unlike the CK and IK values, the CK' and IK' values ​​are bound to the network access name (e.g., the name of the WLAN associated with the wireless access point device 208). More specifically, according to the EAP-AKA' authentication method, the authentication server 216 obtains the CK' and IK' values ​​by first determining the CK and IK values ​​(similar to the process of obtaining them via the EAP-AKA authentication method) and then based on the CK' and IK' values ​​obtained from the CK and IK attributes. Specifically, the CK' and IK' values ​​are obtained from the CK and IK attributes as described in version 14 of TS133 402, titled "Security Aspects of Non-3GPP Accesses," version 14.3.0 (October 2017), published by ATIS in the United States.

[0072] In response to receiving API response 240, proxy server 212 sends an authentication challenge request 243 (e.g., a RADIUS access challenge message) to wireless access point device 208. Authentication challenge request 243 includes AT_RES, AT_AUTN, and AT_MAC attributes. In response to receiving authentication challenge request 243, wireless access point device 208 sends an EAP challenge request 246 containing AT_RAND, AT_MAC, and AT_AUTN attributes to wireless user equipment 204.

[0073] Combination Figure 2A refer to Figure 2B As depicted at 252, Wireless User Equipment 204 authenticates Enterprise Network 207 based on EAP Challenge Request 246. For this purpose, Wireless User Equipment 204 independently generates components of the authentication vector, including the expected AUTN value, using its specified EAP authentication method. Furthermore, Wireless User Equipment 204 independently generates CK and IK values ​​(for the EAP-AKA authentication method) or CK' and IK' values ​​(for the EAP-AKA' authentication method) using the specified EAP authentication method. Wireless User Equipment 204 also uses the specified EAP authentication method to determine the expected AT_MAC attribute of EAP Challenge Request 246. Wireless User Equipment 204 uses the expected AT_MAC attribute and the expected AT_AUTN attribute to verify the identity of Network 207. If Wireless User Equipment 204 determines that it is included in EAP Challenge Request 246 ( Figure 2A If both the AUTN and AT_MAC attributes in the data structure are as expected, then enterprise network 207 passes the authentication of the wireless user equipment. If authentication of wireless user equipment 204 fails, wireless user equipment 204 is disconnected from access point equipment 208.

[0074] Otherwise, if the wireless user equipment 204 successfully authenticates the enterprise network 207, the wireless user equipment 204 continues, as depicted at 254, by generating and sending an EAP challenge response 255. The EAP challenge response message 255 contains the AT_RES attribute (corresponding to the RES value) and the AT_MAC attribute (corresponding to the MAC value) of the EAP challenge response 255. In response to the EAP challenge response 255, the wireless access point device 208 sends a challenge response 257 (RADIUS access request message) containing the AT_RES and AT_MAC attributes to the proxy server 212. As depicted at 258, in response to the access request message 257, the proxy server 212 provides an API call 260 to the authentication server 216. In the example, the proxy server 212 makes an API response 240 ( Figure 2A The HTTP / 2 POST is performed on the URL resource path identified in (). The POST data includes the AT_RES and AT_MAC attributes provided by the wireless user equipment 204. As depicted at 262, the authentication server 216 authenticates the wireless user equipment 204 (i.e., verifies the AT_RES and AT_MAC attributes), and in response to successful authentication, the authentication server 216 provides an API response 264 indicating successful authentication for this example.

[0075] According to the example implementation, in addition to indicating successful authentication, API response 264 also includes data representing a session key (e.g., MSK). As depicted at 266, in response to API response 264, proxy server 212 sends access acceptance notification 267 (e.g., RADIUS access acceptance message) to wireless access point device 208. According to the example implementation, access acceptance notification 267, in addition to indicating that authorized wireless user equipment 204 joins enterprise network 207, also includes data representing a session key (e.g., MSK from which a low-level session key used for encrypting and decrypting communications can be obtained). In response to success notification 267, wireless access point device 208 sends EAP success message 270 to wireless user equipment 204, indicating acceptance of joining enterprise network 207. Due to the application of the specified EAP authentication method by wireless user equipment 204, wireless user equipment 204 possesses the same session key (e.g., MSK) that has been provided to wireless access point device 208. Then, using the EAPoL four-way handshake, the wireless user equipment 204 and the wireless access point equipment 208 can exchange management frames, which allow each of the devices 204 and 208 to obtain a PTK for unicast encryption / decryption and possibly a GTK for multicast encryption / decryption.

[0076] Figure 3This describes a sequence stream 300 depicting the selection of an authentication server based on a mobile network and the application of an EAP authentication method specified by the user equipment to obtain the authentication vector and challenge attributes, according to an example implementation. (Reference) Figure 3 The proxy server of the enterprise network responds to an authorization request (e.g., a RADIUS access request message) received from the wireless access point device by executing a 304 response. Figure 3 The actions described herein. Proxy server 304 communicates with mobile network-based authentication server 308 to obtain the attributes of the access challenge sent back to the wireless access point device by proxy server 304. Figure 1 Proxy server 164 and proxy server 212 in Figure 2 are Figure 3 An example of a proxy server returning a 304 error. Figure 1 The authentication server 183 and the authentication server 216 in Figure 2 are Figure 3 Example of an authentication server 308.

[0077] In response to the authentication request, proxy server 304 first determines the EAP authentication method specified by the wireless user equipment, as depicted at 316. In this example, this determination includes proxy server 304 determining whether the wireless user equipment has specified the EAP-AKA authentication method or the EAP-AKA' authentication method. Next, as depicted at 320, proxy server 304 creates a JSON authentication information object to pass relevant authentication information to authentication server 308.

[0078] In the example, the JSON authentication information object includes data identifying the authentication type corresponding to the EAP authentication method specified by the wireless user equipment. According to the example implementation, proxy server 304 constructs the JSON authentication information object to contain an AuthType string of either "EAP_AKA_PRIME" (for cases where the wireless user equipment specifies the EAP-AKA authentication method) or "EAP_AKA" (for cases where the wireless user equipment specifies the EAP-AKA authentication method). In the example, authentication server 308 is a 5G server, and the 5G authentication service standard defines enumeration strings for the corresponding EAP authentication methods identified by that standard. The "EAP_AKA_PRIME" string is a specific enumeration string specified in the 5G authentication service standard and corresponds to the EAP-AKA authentication method defined in that standard. The "EAP_AKA" string is not one of the enumeration strings specified in the 5G authentication service standard because this identifier corresponds to EAP-AKA authentication, which is replaced by the EAP-AKA authentication method in the standard. However, the object schema defined in the 5G authentication service standard does allow for a generic string type for the AuthType attribute of the authentication information object. The authentication proxy server 304 uses this feature to indicate to the authentication server 308 the EAP-AKA authentication method to be used, by including the string "EAP_AKA" for AuthType.

[0079] As depicted at 324, proxy server 304 POSTs a JSON authentication information object to authentication server 308 in order to provide API call 328. In the example, API call 328 corresponds to proxy server 304, which provides the JSON authentication information object via HTTP / 2 POST to the " / ue authentication" path corresponding to the URL of AUSF served by authentication server 308. In response to API call 328, authentication server 308 determines (as depicted at 332) the specific selected EAP authentication method based on the AuthType string contained in the JSON authentication information object.

[0080] For the EAP-AKA authentication method, authentication server 308 determines the corresponding authentication vector (as depicted at 340), and returns the corresponding challenge attributes of the wireless user equipment to proxy server 304 via API response 345. For the EAP-AKA authentication method, authentication server 308 determines the corresponding authentication vector (as depicted at 344), and returns the corresponding challenge attributes of the wireless user equipment to proxy server 304 via API response 345.

[0081] refer to Figure 4According to the example implementation, technology 400 includes a given authentication protocol specified by the user equipment, determined by the proxy server (block 404). In the example, the proxy server is a RADIUS server whose authentication and authorization functions are offloaded to a mobile network-based authentication server. In the example, the proxy server is configured to aggregate 4G and 5G authentication methods.

[0082] In one example, the given authentication protocol is the EAP-AKA authentication method. In another example, the given authentication protocol is the EAP-AKA authentication method. In one example, the given authentication protocol is specified as part of the user equipment's WPA-2 enterprise profile. In one example, the authentication protocol is specified by the user equipment manufacturer. In one example, the given authentication protocol is specified by the MNO. In one example, the given authentication protocol is selected by the user of the user equipment.

[0083] In the example, a wireless user equipment can be a mobile phone device, an Internet of Things (IoT) device; a sensor; a wearable computer; a process controller; an access point device; a Wi-Fi pod device; a Wi-Fi extender device; a desktop computer, a portable computer, a laptop computer, a notebook computer, a tablet computer, a smartphone, a wearable computer, or any other electronic device having an identity module and a communication interface capable of communicating with the access point device.

[0084] Technique 400 includes receiving (block 408) an access request corresponding to a user equipment from a wireless access point device via a proxy server. The access request includes data representing the identity associated with the user equipment. In the example, the wireless access point device creates a WLAN. In the example, receiving the access request occurs after the user equipment has associated with the wireless access point device. In the example, the identity includes the IMSI. In the example, the access request corresponds to a RADIUS access request message.

[0085] Technology 400 includes, according to block 412, providing backward compatibility for a given authentication protocol in response to receiving an access request. Providing backward compatibility includes the proxy server providing a second request to the mobile network-based authentication server. The second request includes data representing an identity and data representing the given authentication protocol. In the example, the authentication server is a 5G authentication server. In the example, providing the second request includes invoking an API provided by the authentication server. In the example, providing the second request includes invoking AUSF. In the example, providing the second request includes the proxy server providing an HTTP / 2 POST to a URL associated with the authentication server. In the example, providing the second request includes POSTing an authentication information object to the URL associated with the authentication server. In the example, the authentication information object is a JSON object. In the example, the JSON object includes an authorization type attribute specifying the authentication protocol. In the example, providing the second request includes the proxy server setting the authorization type to a generic string representing the given authentication protocol.

[0086] In the example, a second request is provided to cause the authentication server to provide an API response. In the example, the API response includes attributes corresponding to the authentication challenge of the user's device. In the example, the attributes of the authentication challenge include randomly or pseudo-randomly generated values. In the example, the attributes of the user's device's authentication challenge correspond to the MAC address.

[0087] As depicted in block 412, the authentication server is associated with a Mobile Network Authentication Service Standard (MLS), and a given authentication protocol is not associated with a MLS. In the example, the MLS is the 5G Authentication Service Standard. In the example, the 5G Authentication Service Standard supports the EAP-AKA authentication method, and the given authentication protocol is an EAP-AKA authentication protocol that is not supported by the 5G Authentication Service Standard. In the example, the 5G Authentication Service Standard defines a set of enumerated strings corresponding to the respective authentication methods supported by the 5G Authentication Service Standard. In the example, the 5G Authentication Service Standard has an object schema that defines an enumerated string type having enumerated strings corresponding to the authentication methods supported by the 5G Authentication Service Standard, and the object schema also allows for generic string types. In the example, the proxy server providing the second request corresponds to a proxy server that provides an authentication information object having a string corresponding to a generic string type and representing the given authentication protocol.

[0088] refer to Figure 5According to the example implementation, system 500 includes a proxy server 504 and an authentication server 508 associated with a mobile network and with an authentication service standard. In the example, proxy server 504 is a proxy server with EAP authentication method aggregation enabled, adapting to EAP authentication methods based on current and previous generation mobile networks. In the example, authentication server 508 is a 5G authentication server. In the example, the authentication service standard is the 5G authentication service standard.

[0089] The proxy server 504 is used to determine the authentication method specified by the user equipment. In this example, the authentication method is the EAP-AKA authentication method. In another example, the authentication method is EAP-AKA' authentication method. In this example, the wireless user equipment can be a mobile phone device, an IoT device; a sensor; a wearable computer; a process controller; an access point device; a Wi-Fi pod device; a Wi-Fi extender device; a desktop computer, a portable computer, a laptop computer, a notebook computer, a tablet computer, a smartphone, a wearable computer, or any other electronic device having an identity module and a communication interface capable of communicating with the access point device.

[0090] The user equipment (UE) associates with the access point device (APD) via a WLAN connection. The APD is associated with an access network name. Proxy server 504 provides an authentication request corresponding to the UE. In this example, the authentication request corresponds to the proxy server invoking the AUSF function provided by authentication server 508. In this example, the proxy server provides the authentication request by POSTing an authentication information object to the URL path associated with authentication server 508.

[0091] The authentication request includes data representing the identity of the user device, and also includes data representing the authentication type that identifies the authentication method. In the example, the identity corresponds to IMSI. In the example, the data representing the authentication type corresponds to a string. In the example, the data representing the authentication type corresponds to a generic string type defined by the object schema of the authentication service standard.

[0092] The authentication method is not associated with an authentication service standard. Authentication server 508 receives authentication requests and generates an authentication vector based on the authentication type. In the example, authentication server 508 generates the authentication vector by applying the EAP-AKA authentication method. In the example, the authentication vector includes random or pseudo-random values ​​used as challenges to the user equipment. In the example, the authentication vector includes values ​​used by the user equipment to authenticate to the network. In the example, the authentication value includes an encryption key not bound to a network access name. Authentication server 508 authenticates the user equipment based on the authentication vector.

[0093] refer to Figure 6According to the example implementation, the non-transient storage medium 600 stores hardware processor readable instructions 604. In the example, the hardware processor includes one or more CPU cores. In the example, the non-transient storage medium includes one or more semiconductor storage devices.

[0094] When executed by the hardware processor, instruction 604 causes the agent server to determine that the user equipment has specified a first non-mobile network authentication method. In the example, the non-mobile network authentication method corresponds to the control of non-3GPP access. In the example, the first non-mobile network authentication method is the EAP-AKA authentication method.

[0095] When executed by the hardware processor, instruction 604 also causes the hardware processor to send an authentication request to the authentication path corresponding to the URL of the authentication server on the mobile network, in order to initiate an authentication session corresponding to the user equipment. In the example, the authentication session corresponds to an EAP session, and the authentication server assigns a session ID to this authentication session. In the example, the authentication server responds to the authentication request with a response including data identifying the resource associated with the session ID. In the example, the resource path is a URL path.

[0096] The authentication server is associated with an authentication service standard related to a second non-mobile network authentication method. In the example, the second non-mobile network authentication method is the EAP-AKA authentication method. This authentication service standard is not associated with the first non-mobile network authentication method, and the authentication request includes an authentication information object to cause the authentication server to apply the first non-mobile network authentication method to provide an authentication challenge. In the example, the authentication information object is a JSON object. In the example, the JSON object includes an authorization type corresponding to a string identifying the first non-mobile network authentication method. In the example, the authentication challenge includes a randomly or pseudo-randomly generated number. In the example, the authentication server generates an expected response from the user device to this number. In the example, the expected response corresponds to a response generated using the randomly or pseudo-randomly generated number and a secret possessed by the user device.

[0097] When instruction 604 is executed by the hardware processor, the hardware processor must also receive an authentication challenge from the authentication server. In the example, the authentication challenge corresponds to an API response generated by AUSF served by the authentication server.

[0098] When executed by the hardware processor, instruction 604 also causes the hardware processor to send the authentication challenge to the user equipment in response to receiving the authentication challenge. In the example, sending the authentication challenge to the user equipment includes the proxy server providing a RADIUS authentication challenge message to the wireless access point device, and the wireless access point device sending a corresponding EAP request to the user equipment.

[0099] According to the example implementation, the mobile network authentication service standard specifies a set of enumeration strings corresponding to the enumeration authentication service associated with the mobile network standard. Providing backward compatibility for a given authentication protocol includes the proxy server providing the authentication server with data representing a non-enumeration string that is not in the enumeration string set and represents the given authentication protocol. Among the potential benefits is that the authentication method can be applied by the authentication server associated with an authentication service standard that does not support a particular authentication method.

[0100] Based on the example implementation, the Mobile Authentication Service Standard specifies a pattern for a generic string type defined for enumerated authentication services. Non-enumerated strings correspond to this generic string type. Among the potential benefits is that authentication methods can be applied by authentication servers associated with authentication service standards that do not support specific authentication methods.

[0101] According to the example implementation, providing backward compatibility with the authentication protocol also includes: the proxy server and the authentication server receiving a response to the second request. This response contains data representing the challenge value generated by the authentication server. Providing backward compatibility also includes the proxy server sending a challenge request to the user equipment to the wireless access point device. This challenge request contains data representing the challenge value. Among the potential benefits is that the authentication method can be applied by the authentication server associated with an authentication service standard that does not support a particular authentication method.

[0102] According to the example implementation, the response to the second request includes data representing the URL corresponding to the resource associated with the authentication session. Providing backward compatibility with the authentication protocol also includes the proxy server providing data to the URL representing the user device's response to the challenge value. Among the potential benefits is that the authentication method can be applied by an authentication server associated with an authentication service standard that does not support a particular authentication method.

[0103] According to the example implementation, the proxy server receives the authentication result in response to providing data representing the user device's response to the challenge value. Among the potential benefits is that the authentication method can be applied by an authentication server associated with an authentication service standard that does not support a particular authentication method.

[0104] According to the example implementation, a mobile authentication service standard is associated with a second authentication protocol, which is associated with a first authentication vector, and the second authentication protocol binds the authentication vector to a network access name. A given authentication protocol is associated with a second authentication vector, but the given authentication vector does not bind the second authentication vector to a network access name. Among the potential benefits is that the authentication method can be applied by an authentication server associated with an authentication service standard that does not support a particular authentication method.

[0105] According to the example implementation, the first authentication vector includes a first session key, and a given authentication vector includes a second session key that is bound to the access network name and derived from the first session key. Among the potential benefits is that the authentication method can be applied by an authentication server associated with an authentication service standard that does not support a particular authentication method.

[0106] According to the example implementation, the mobile network authentication service standard specifies a set of enumeration strings corresponding to the enumeration authentication service associated with the mobile network standard. Providing backward compatibility for a given authentication protocol includes the proxy server providing the authentication server with data representing a non-enumeration string that is not in the enumeration string set and represents the given authentication protocol. Among the potential benefits is that the authentication method can be applied by the authentication server associated with an authentication service standard that does not support a particular authentication method.

[0107] In the context used herein, a "hash" (which may also be referred to as a "digest," "hash value," or "hash digest") is generated by applying a cryptographic hash algorithm to an input value. The cryptographic hash algorithm receives the input value and generates a hexadecimal string (digest or hash) to match it. In the example, the input value may include a string of data (e.g., a data structure in memory represented by a start memory address and an end memory address). In this example, based on the string of data, the cryptographic hash algorithm outputs a hexadecimal string (digest or hash). Any small change to the input value alters the output hexadecimal string. In the example, the cryptographic hash function may be a Secure Hash Algorithm (SHA), a Federal Information Processing Standard (FIPS) approved hash algorithm, a National Institute of Standards and Technology (NIST) approved hash algorithm, or any other cryptographic hash algorithm. In some examples, an alternative format string may be used instead of the hexadecimal format.

[0108] In the context used herein, "key hashing algorithm" refers to a function that uses a cryptographic hashing algorithm (e.g., SHA, FIPS-approved hashing algorithms, NIST-approved hashing algorithms, or other hashing algorithms) to generate a digest or hash based on a cryptographic key input and a second input (referred to as "message input"). The key hashing algorithm derives its input from the cryptographic key and the message input. The key hashing algorithm can obtain a digest or hash using a single round or multiple iterations of the algorithm. In one example, the key hashing algorithm may form the input value of the cryptographic hashing algorithm based on a concatenation of the cryptographic key and the message input. In another example, the input of the key hashing algorithm is formed by a concatenation of a key obtained from the cryptographic key and the message input. In yet another example, a first key (also referred to as the "internal key") and a second key (also referred to as the "external key") are obtained from the cryptographic key. In the first iteration or round (also referred to as the "internal round") of the key hashing algorithm, the first key and the message input are combined to provide a first input value for the key hashing algorithm, which provides a first digest (also referred to as the "internal digest result"). In the second iteration or round (also known as the “outer round”) of the key hash algorithm, the second key and the first digest are combined to provide a second input value for the hash algorithm, which provides the second digest, which is the output or result.

[0109] The detailed description set forth herein is with reference to the accompanying drawings. Where possible, the same reference numerals are used in the drawings and the foregoing description to refer to the same or similar parts. However, it will be clearly understood that the drawings are for illustrative and descriptive purposes only. While several examples are described in this document, modifications, adjustments, and other implementations are possible. Therefore, the detailed description does not limit the disclosed examples. Rather, the appropriate scope of the disclosed examples may be defined by the appended claims.

[0110] The terminology used herein is for the purpose of describing particular examples only and is not intended to be restrictive. As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. The term “multiple” as used herein is defined as two or more. The term “another” as used herein is defined as at least a second or more. The term “connection” as used herein is defined as a connection, whether direct without any intermediate elements or indirect with at least one intermediate element, unless otherwise stated. Two elements may be mechanically coupled, electrically coupled, or linked in communication via a communication channel, path, network, or system. The term “and / or” as used herein refers to and covers any and all possible combinations of the associated listed items. It will also be understood that although the terms first, second, third, etc., may be used herein to describe various elements, these elements should not be limited by these terms, as they are used only to distinguish one element from another unless otherwise stated or the context indicates otherwise. As used herein, the term “comprising” means including but not limited to, and the term “including” means including but not limited to. The term “based on” means at least partially based on.

[0111] While this disclosure has been described with respect to a limited number of implementations, those skilled in the art who benefit from it will appreciate numerous modifications and variations arising therefrom. The appended claims are intended to cover all such modifications and variations.

Claims

1. A method comprising: The proxy server determines the given authentication protocol specified by the user equipment. The proxy server receives an access request corresponding to the user equipment from the wireless access point device, wherein the access request includes data representing the identity associated with the user equipment; as well as In response to receiving the access request, backward compatibility is provided for the given authentication protocol, wherein providing backward compatibility includes the proxy server providing a second request to the mobile network-based authentication server, the second request including data representing the identity and data representing the given authentication protocol, wherein the mobile network-based authentication server is associated with the Mobile Network Authentication Service Standard (MLSS), and wherein the given authentication protocol is not associated with the MLSS.

2. The method according to claim 1, wherein: The mobile network authentication service standard specifies a set of enumeration strings corresponding to the enumeration authentication service associated with the mobile network standard; and Providing backward compatibility for the given authentication protocol includes the proxy server providing the authentication server with data representing a non-enumerated string that is not in the enumerated string set and representing the given authentication protocol.

3. The method according to claim 2, wherein: The mobile network authentication service standard specifies a pattern for a generic string type defined for the enumerated authentication service; and The non-enumerated string corresponds to the general string type.

4. The method of claim 1, wherein providing backward compatibility for the authentication protocol further comprises: The proxy server receives a response to the second request from the authentication server, wherein the response includes data representing a challenge value generated by the authentication server; and The proxy server sends a challenge request to the wireless access point device for the user equipment, wherein the challenge request includes data representing the challenge value.

5. The method according to claim 4, wherein: The response to the second request includes data representing a Uniform Resource Locator URL corresponding to a resource associated with the authentication session; and Providing backward compatibility with the authentication protocol also includes the proxy server providing data to the URL representing the response of the user equipment to the challenge value.

6. The method according to claim 5, further comprising: In response to providing the data representing the response of the user equipment to the challenge value, the proxy server receives the authentication result from the authentication server.

7. The method according to claim 1, wherein: The mobile network authentication service standard is associated with the second authentication protocol; The second authentication protocol is associated with the first authentication vector; The second authentication protocol binds the authentication vector to the network access name; The given authentication protocol is associated with the second authentication vector; and The given authentication vector does not bind the second authentication vector to the network access name.

8. The method according to claim 7, wherein: The first authentication vector includes the first session key; and The given authentication vector includes a second session key that is bound to the access network name and obtained from the first session key.

9. The method according to claim 1, wherein: The given authentication protocol includes a first shared secret-based authentication protocol, which generates a first authentication vector value and does not bind the first authentication vector value to a network access name associated with the wireless access point device. and The mobile network authentication service standard is associated with a second shared secret-based authentication protocol, which generates a second authentication vector value and binds the second authentication vector value to the network access name.

10. A system comprising: Proxy servers are used for: Determine an authentication method specified by a user equipment, wherein the user equipment is associated with the access point device via a wireless local area network (WLAN) connection to the access point device, and wherein the access point device is associated with an access network name; and Provide an authentication request corresponding to the user equipment, wherein the authentication request includes data representing the identity of the user equipment, and wherein the authentication request includes data representing the authentication type identifying the authentication method; as well as An authentication server, associated with a mobile network and with an authentication service standard, wherein the authentication service standard is not associated with the authentication method, and the authentication server is used for: Receive the authentication request; Based on the authentication type, an authentication vector is generated, wherein the authentication vector includes a value corresponding to a key that is not bound to an access network name; as well as The user equipment is authenticated based on the authentication vector.

11. The system of claim 10, wherein the proxy server is further configured to: Select a string that corresponds to the generic string type defined by the authentication service standard; and The string is included in the authentication information object of the authentication request to indicate the authentication type.

12. The system according to claim 10, wherein: The authentication server is further configured to: generate challenge attributes in response to the request, and provide the challenge attributes to the proxy server; and The proxy server is also used to send an authentication challenge, including the challenge attributes, to the access point device.

13. The system according to claim 12, wherein: The proxy server is further configured to: send a challenge response corresponding to the challenge attribute to the authentication server; and The authentication server is used to: authenticate the user equipment in response to the challenge response.

14. The system of claim 12, wherein the proxy server is further configured to: Receive data representing a URL path corresponding to a resource associated with the authentication session from the authentication server and in connection with the authentication challenge; and In response to receiving a response from the user equipment to the authentication challenge, an application programming interface (API) call including data representing the response from the user equipment to the authentication challenge is sent to the URL path.

15. The system according to claim 10, wherein: The authentication service standard specifies a set of enumeration strings corresponding to the enumeration authentication services associated with the authentication service standard; and The proxy server is also configured to: send an application programming interface (API) call to the authentication server, which includes data representing a non-enumerated string not in the enumerated string set and representing the authentication method.

16. The system according to claim 10, wherein: The authentication methods include Extensible Authorization Protocol (EAP) authentication and Key Agreement-AKA (EAP-AKA) authentication; and The certification service standard supports the EAP-AKA master certification method.

17. A non-transient storage medium for storing hardware processor-readable instructions, which, when executed by a hardware processor, cause a proxy server to: Determine the user equipment to specify the first non-mobile network authentication method; An authentication request is sent to the authentication path of the Uniform Resource Locator URL corresponding to the authentication server based on the mobile network to initiate an authentication session corresponding to the user equipment, wherein the authentication server is associated with an authentication service standard associated with a second non-mobile network authentication method, wherein the authentication service standard is not associated with the first non-mobile network authentication method, and wherein the authentication request includes an authentication information object to enable the authentication server to apply the first non-mobile network authentication method to provide authentication challenges. Receive the authentication challenge from the authentication server; as well as In response to receiving the authentication challenge, the authentication challenge is sent to the user equipment.

18. The storage medium according to claim 17, wherein: The authentication service standard specifies a pattern of a general string type defined for an enumerated set of authentication services; and When executed by the hardware processor, the instruction also causes the proxy server to include a non-enumerated string corresponding to the general string type in the authentication request.

19. The storage medium according to claim 17, wherein: The authentication service standard specifies a set of enumeration strings corresponding to the enumeration authentication services associated with the authentication service standard; and When executed by the hardware processor, the instruction also causes the proxy server to send an application programming interface (API) call to the authentication server, which includes data representing a non-enumerated string not in the enumerated string set and representing the first non-mobile network authentication method.

20. The storage medium of claim 17, wherein the instructions, when executed by the hardware processor, further cause the proxy server to: Receive data representing the URL path corresponding to the resource associated with the authentication session from the authentication server and in connection with the authentication challenge; and In response to receiving a response from the user equipment to the authentication challenge, an application programming interface (API) call including data representing the response from the user equipment to the authentication challenge is sent to the URL path.

Images