Automatic client authentication for a wireless network protected by PEAP, EAP-TLS, or other extensible authentication protocols

The present invention is directed at providing a system and method for Automatic Client Authentication for a Wireless Network protected by PEAP, EAP-TLS, or other Extensible Authentication Protocols. The user doesn't have to understand the difference between the protocols in order to connect to the network. A default authentication protocol is automatically attempted. If not successful, then the authentication switches over to another authentication method if the network requests it.

FIELD OF THE INVENTION

The present invention relates generally to authentication, and more particularly to authentication for a wireless network.

BACKGROUND OF THE INVENTION

Wireless networks like 802.11b (also known as Wi-Fi or Wireless Ethernet) are more susceptible to hackers than wired networks since the hackers don't have to physically connect to the network. In response to the susceptibility of hackers, a variety of frameworks have been created to ensure authentication of wireless network users, especially for corporations. One of those frameworks is called 802.1×. Within the framework of 802.1×, there are multiple possible authentication protocols, and two of those include EAP-TLS (Extensible Authentication Protocol—Transport Layer Security) and PEAP (Protected Extensible Authentication Protocol). In order to use a wireless network protected by 802.1×, the wireless client has to support the right authentication protocol. Additionally, the user to select the correct authentication protocol before connecting.

SUMMARY OF THE INVENTION

The present invention is directed at providing a system and method for Automatic Client Authentication for a Wireless Network protected by PEAP, EAP-TLS, or other Extensible Authentication Protocols.

According to one aspect of the invention, a user does not have to understand the difference between the protocols in order to connect to the network.

Accord to another aspect of the invention, a default authentication protocol is automatically attempted to connect to the network. If the authentication method is not successful, then a switch to another authentication method is made if the network requests it.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The present invention is directed at providing a system and method for Automatic Client Authentication for a Wireless Network protected by PEAP, EAP-TLS, or other Extensible Authentication Protocols. A default authentication protocol is automatically attempted. If the authentication method is not successful, then a switch to another authentication method is made if the network requests it.

Throughout the specification, the term “wi-fi” is short for wireless fidelity and is meant to be used generically when referring of any type of 802.11 network, whether 802.11b, 802.11a, dual-band, and the like. The term “AP” refers to an access point used to connect wireless network devices to a network. The term “SSID” refers to Service Set Identifier.

Referring toFIG. 1, an exemplary system for implementing the invention includes a computing device, such as computing device100. In a basic configuration, computing device100typically includes at least one processing unit102and system memory104. Depending on the exact configuration and type of computing device, system memory104may be volatile (such as RAM), non-volatile (such as ROM, flash memory, and the like) or some combination of the two. System memory104typically includes an operating system105, one or more program modules106, and may include program data107. This basic configuration is illustrated inFIG. 1by those components within dashed line108.

FIG. 2illustrates a mobile computing device that may be used in one exemplary embodiment of the present invention. With reference toFIG. 2, one exemplary system for implementing the invention includes a mobile computing device, such as mobile computing device200. The mobile computing device200has a processor260, a memory262, a display228, and a keypad232. The memory262generally includes both volatile memory (e.g., RAM) and non-volatile memory (e.g., ROM, Flash Memory, or the like). The mobile computing device200includes an operating system264, such as the Windows CE operating system from Microsoft Corporation or other operating system, which is resident in the memory262and executes on the processor260. The keypad232may be a push button numeric dialing pad (such as on a typical telephone), a multi-key keyboard (such as a conventional keyboard). The display228may be a liquid crystal display, or any other type of display commonly used in mobile computing devices. The display228may be touch-sensitive, and would then also act as an input device.

One or more application programs266are loaded into memory262and run on the operating system264. Examples of application programs include phone dialer programs, email programs, scheduling programs, PIM (personal information management) programs, word processing programs, spreadsheet programs, Internet browser programs, and so forth. The mobile computing device200also includes non-volatile storage268within the memory262. The non-volatile storage268may be used to store persistent information which should not be lost if the mobile computing device200is powered down. The applications266may use and store information in the storage268, such as e-mail or other messages used by an e-mail application, contact information used by a PIM, appointment information used by a scheduling program, documents used by a word processing application, and the like. An authentication application also resides on the mobile computing device200and is programmed for authentication on a wireless network.

The mobile computing device200has a power supply270, which may be implemented as one or more batteries. The power supply270might further include an external power source, such as an AC adapter or a powered docking cradle that supplements or recharges the batteries.

The mobile computing device200is shown with two types of external notification mechanisms: an LED240and an audio interface274. These devices may be directly coupled to the power supply270so that when activated, they remain on for a duration dictated by the notification mechanism even though the processor260and other components might shut down to conserve battery power. The LED240may be programmed to remain on indefinitely until the user takes action to indicate the powered-on status of the device. The audio interface274is used to provide audible signals to and receive audible signals from the user. For example, the audio interface274may be coupled to a speaker for providing audible output and to a microphone for receiving audible input, such as to facilitate a telephone conversation.

The mobile computing device200also includes a wireless interface layer272that performs the function of transmitting and receiving communications, such as radio frequency communications. The wireless interface layer272facilitates wireless connectivity between the mobile computing device200and the outside world, via a communications carrier or service provider. Transmissions to and from the wireless interface layer272are conducted under control of the operating system264. In other words, communications received by the wireless interface layer272may be disseminated to application programs266via the operating system264, and vice versa.

FIG. 3is a functional block diagram generally illustrating one embodiment for an authentication system300, in accordance with the present invention. In this implementation, the server340is a computing device such as the one described above in conjunction withFIG. 1, and the mobile device320is a mobile computing device such as the one described above in conjunction withFIG. 2. Authentication application342is configured to perform the authentication process between server340and mobile device320. In the embodiment illustrated, authentication applications342and344are resident on server340and mobile device320.

Mobile device320maintains mobile data322locally in its storage268(shown inFIG. 2). During an authentication session, mobile device320and the server340exchange information relating to the authentication.

Exemplary Log-In Process

Most corporations that currently use wi-fi utilize 802.1× and support a variety of authentication algorithms. Three of the authentication algorithms include EAP-TLS (certificates), PEAP, and Wi-Fi Protected Access WPA. The EAP-TLS authentication uses certificates and RADIUS servers. PEAP authentication does not use certificates but uses RADIUS servers. WPA is perceived by some to be more secure than WEP because it utilizes TKIP encryption, but in practice, they both appear to be secure in the 802.1× because the keys rotate. WPA has an added benefit over PEAP/EAP-TLS because WPA does not utilize back-end RADIUS servers. WPA still uses either PEAP or EAP-TLS for authentication.

According to one aspect of the invention, the wi-fi login process is improved for networks that use 802.1×. The following are exemplary descriptions according to aspects of the invention.

First Time Connect (802.1× PEAP Network) Example

Ray takes his wi-fi device into the range of his corporate wi-fi network (CORPSSID), which uses 802.1×. A dialog bubble appears on Ray's device asking Ray if he wishes to connect to CORPSSID (SeeFIG. 7for an exemplary bubble). Ray clicks connect. A dialog appears asking for the information used to logon onto the network. According to one embodiment, this information includes the username, password, and domain (SeeFIG. 8for an exemplary dialog). Ray enters this information and logs onto the network.

Ray takes his integrated wi-fi device into the range of his corporate wi-fi network (CORPSSID), which uses 802.1×. A bubble appears asking Ray if he wishes to connect to CORPSSID. Ray clicks connect. A dialog appears asking for his username/password/domain. Ray enters this information and hits OK. The AP is expecting EAP-TLS authorization, so it returns an error. Ray's device notices this error and switches the EAP type to TLS for this SSID without Ray being alerted to this, then the device tries to associate/connect again using TLS. The username/domain entered before are resubmitted to the AP. A certificate is autoselected for Ray and sent to the AP. Ray logs onto the network.

First Time Connect (802.1× Configured for EAP-TLS Network, User has Multiple Possible Certificates)

Ray takes his integrated wi-fi device into the range of his corporate wi-fi network (CORPSSID), which uses 802.1×. A bubble appears asking Ray if he wishes to connect to CORPSSID. Ray clicks connect. A dialog appears asking for his username/domain. Ray enters this information and hits OK. A dialog appears asking the user to choose a certificate (SeeFIG. 10for an example certificate screen). Ray picks the non-expired certificate issued by his company. Ray logs onto the network.

First Time Connect (802.1× Configured for EAP-TLS Network, User has No Certificates)

Ray takes his integrated wi-fi device into the range of his corporate wi-fi network (CORPSSID), which uses 802.1×. A bubble appears asking Ray if he wishes to connect to CORPSSID. Ray clicks connect. A dialog appears asking for his username/domain. Ray enters this information and hits OK. An error message appears telling Ray that he needs a certificate and he should contact his administrator. Alternatively, if the AP returned PEAP, the error message does not indicate that a certificate is needed by the user.

Subsequent Connections Anywhere

User with wi-fi walks into the range of a wi-fi network and is connected without the user of a user interface (UI).

According to another embodiment of the invention, PEAP is the dominant authentication method. PEAP doesn't require certificates. The present invention is extensible to other authentication methods.

According to one embodiment, the operating system exposes registry settings with flags that indicate whether a particular authentication method requires a call into the username/password/domain UI (for PEAP) or the username/domain U1(for TLS).

According to one embodiment, after one successful login, future logins do not use a UI. According to one embodiment, the username/domain may also be prefilled and be UI-less.

Process Flows

FIG. 4illustrates a process for logging into a network with PEAP, in accordance with aspects of the invention. After starting, the process flows to block405, where a new wireless network is detected. Moving to block410, the user clicks connect to begin connecting to the network. Flowing to decision block415, a determination is made as to whether the login information for the domain has been saved. When the information has not been saved, the process flows to block420where the user is prompted for the information required to logon to the network. According to one embodiment, this information includes a username, password, and domain. When the information has been saved, the process flows to block425where the username and domain are sent to the AP. The process then moves to decision block430where a determination is made as to whether the username/domain is accepted. When the username/domain is not accepted, the process flows to block435to re-request the information. When the information is accepted, the process flows to block440where the information is sent for PEAP authorization. Transitioning to decision block445a determination is made as to whether the credentials are accepted. When they are not accepted the process flows to block450where an error message is sent. When the credentials are accepted, the login is successful (block455), and the process returns to processing other actions.

FIG. 5illustrates a process of an attempted PEAP login on a TLS network (error case), in accordance with aspects of the invention. After starting, the process flows to block505, where a new wireless network is detected. Moving to block510, the user clicks connect to begin connecting to the network. Flowing to decision block515, a determination is made as to whether the login information for the domain has been saved. When the information has not been saved, the process flows to block520where the user is prompted for the information required to logon to the network. According to one embodiment, this information includes a username, password, and domain. When the information has been saved, the process flows to block525where the username and domain are sent to the AP. The process then moves to decision block530where a determination is made as to whether the username/domain is accepted. When the username/domain is not accepted, the process flows to block535to re-request the information. When unsuccessful gaining authorization, the AP automatically switches authentication procedures to TLS authorization without interaction from the user and the authorization process is restarted using TLS instead of PEAP (block540). The process then returns to processing other actions.

FIG. 6illustrates a process for TLS authentication and selecting certificates, in accordance with aspects of the invention. After starting, the process flows to block605, where a new wireless network is detected. Moving to block610, the user clicks connect to begin connecting to the network. Flowing to decision block615, a determination is made as to whether the login information has been saved. When the information has not been saved, the process flows to block620where the user is prompted for the information required to logon to the network. According to one embodiment, this information includes a username and domain. When the information has been saved, the process flows to block625where the username and domain are sent to the AP. The process then moves to decision block630where a determination is made as to whether the username/domain is accepted. When the username/domain is not accepted, the process flows to block635to re-request the information. Flowing to decision block640a determination is made as to whether the user has client certificates. When the user does not have client certificates the process flows to block645where an error message is sent and possibly assist the user in obtaining a certificate. When the user does have a certificate, the process flows to block650where a determination is made as to whether the user has more than one certificate for the username and domain supplied. When the user does not have more than one certificate, the process flows to block655where the certificate is automatically selected. When the user does have more than one certificate the process flows to block660the user selects a certificate from a choice of certificates. Moving to decision block665a determination is made as to whether the certificate is accepted. When the certificate is not accepted the process moves to block670where an error message is returned to the user and help may be provided to the user to help correct the problem with the certificate. When the certificate is accepted, the process flows to block675where the login is successful. The process then returns to processing other actions.

FIGS. 7-13illustrate exemplary screenshots, according to aspects of the invention.

FIG. 7illustrates an exemplary screenshot for a new network detected, in accordance with aspects of the invention. As illustrated, a bubble for a detected wi-fi network appears. According to this embodiment, the user chooses to connect to the Internet.

FIG. 8illustrates an exemplary screenshot logging on to a network server using PEAP, in accordance with aspects of the invention. As illustrated, the user is asked for the information used to logon to the network. According to one embodiment, the information includes the user name, password, and domain. After the user clicks OK, the device sends the username/domain information to the AP. The username/domain are saved if they are accepted; otherwise, this dialog is repeated with the previously typed username/domain. The AP then asks for PEAP authentication. If the username/password/domain are accepted, the user is done. The password is saved if the user checked the checkbox. According to one embodiment, ff the password is rejected, the AP terminates the association and an error message is displayed. If the AP asks for an alternate type of authentication, the logon process is restarted and this SSID is switched to use that new authorization type.

FIG. 9illustrates an exemplary screenshot logging on to a network server using TLS, in accordance with aspects of the invention. As illustrated If TLS, is used the username/domain are requested. If this is a first time logon and the user has not clicked settings to choose TLS, PEAP is the default and the user will get the PEAP experience, followed by an error since he cannot logon. After the user clicks OK, the device sends the username/domain information to the AP. The username/domain are saved if they are accepted; otherwise, this dialog is repeated with the previously typed username/domain. If the AP asks for an alternate type of authentication, the login process is automatically restarted and switch this SSID to use the new authorization type.

FIG. 10illustrates an exemplary screenshot when TLS does not pick the certificate automatically, in accordance with aspects of the invention. The username/domain generally allows the proper client certificate to be chosen automatically. If it works, there is no more UI. If no appropriate client certificates are available, an error message is displayed and an offer may be made to take the user to the certificate management UI.

According to one embodiment, the Pick a Certificate UI displayed inFIG. 10only shows appropriate client certificates and not all of the client certificates. According to one embodiment, tapping on a certificate chooses that certificate. Tap&Hold shows one menu item: properties. Selecting properties goes to the certificate properties page. If the chosen certificate is rejected, an error popup (“the certificate was not accepted”) is displayed.

FIG. 11illustrates exemplary properties of a certificate, in accordance with aspects of the invention. If the network is unprotected, the client have timeouts asking the AP for 802.1× support. This can take up to 9 seconds (3 retries of 3 seconds each). Once connected to the network unprotected, the user's setting is changed to connect to this SSID without 802.1× enabled. According to one embodiment of the invention, all of the appropriate certificates are not automatically cycled through due to the way APs work. After a certificate fails, the AP terminates the association. Instead, the system reassociates and tries again.

FIG. 12illustrates an exemplary progress UI, in accordance with aspects of the invention. According to one embodiment, progress is shown in two cases. Immediately after the user clicks connect on the bubble up to the point that a logon UI is shown (e.g. username/password, certificate picker). This helps to ensure that status is shown during potential delays (e.g. trying 802.1× on an unprotected network).

If the AP asks for a different type of authentication than the one currently be attempted, the progress bubble is shown as the system is waiting to reassociate (this can take up to 60 seconds). For example, in the case where PEAP authentication is first attempted, then TLS, the user clicks connect, the progress UI is shown. The username/password/domain is asked for, the AP asks for TLS, the process is restarted, the progress UI is shown again, then the user is logged onto the network.

Clicking the Settings link cancels the current connection and goes to the Wireless networking settings. Cancel cancels the wi-fi connection. Hide hides the bubble.

FIG. 13illustrates an exemplary configure network authentication dialog, in accordance with aspects of the invention. The authentication, data encryption, key settings, and access controls may be configured according to one embodiment of the invention.