A Flexible Authorization Mechanism for Enterprise Networks Using Smart-Phone Devices

The authentication and authorization process is a critical factor in Wi-Fi enterprise networks, being the mechanism used to give access to the network resources. The general Wi-Fi enterprise network security frameworks have a static structure, being based on user-name/password credentials and without offering a flexible granular access. Nowadays, smart-phones devices are becoming ubiquitous and these can be used as security elements due to their hardware/software capabilities. Smart-phones have the capability to execute complex cryptographic operations and have the hardware peripherals, which allow authenticating the user. In this paper, we propose a smart-phone centric authentication and authorization solution which employs a bootstrap security protocols to provision temporary credentials for a WPA2 Enterprise protected Wi-Fi network.


I. INTRODUCTION
The security mechanisms are a critical factor for a Wi-Fi enterprise network because the resource owner must give access only to authenticated and authorized users. Along with the increased popularity of smart-phone devices, there are new requirements for this type of networks: flexibility, granular access, revocation and ease of use. Thus for environments like university campuses or companies which offer a Wi-Fi resource to visitors or temporary collaborators, a flexible security network access is mandatory, in order to address a custom application use-case. Currently the Wi-Fi security solutions have a static structure, most of them employing a WPA2 Enterprise mechanism with the 802.1X protocol authenticating and authorizing the users which are provided user-name/password credentials. WPA2 Enterprise solutions use a back-end RADIUS server to store the user credentials and other attributes, the authentication response being relayed to the Network Access Server (NAS), which allows the supplicant to access the network resources. This type of architecture is suitable for an environment where the supplicants have a welldefined set of access attributes and follow a strict security policy. When authorizing temporary users, the NAS must be integrated with a remote security domain. This security domain handles the user attributes and the authorization process is executed in a federated manner. Also in this type of scenario, the user's smart-phone is used as supplicant device, thus the security system must provide both user to device authentication and device to service authentication, while provisioning the smart-phone with temporary access credentials, which must be delivered to the NAS.
In this paper, we propose a smart-phone centric security solution, which completes the WPA2 Enterprise scheme by executing a bootstrap authentication protocol, which allows the smart-phone application to be provisioned with temporary Wi-Fi credentials. We address the scenario of a university campus or a company client network, where the visitors use the smartphone as security element to access a Wi-Fi protected resource: an e-learning or a confidential business website. For this scheme, we use FIDO as authentication protocol, which runs on the smart-phone, and we propose a security stack, which comprises several server-side modules. The rest of the paper is organized as follows. In section 2 we present the related work. Section 3 presents the general system architecture and describes each module of the proposed security stack. In section 4 we present details regarding the system implementation: the NAS and the Android security application. Finally, section 5 outlines our conclusions.

II. RELATED WORK
The smart-phone can be used as security element because it has connectivity capabilities and it is equipped with hardware modules that permit the user identification (e.g. fingerprint reader, facial recognition using the camera). The idea of using a smart-phone as authentication element is currently explored by both academia and commercial products.
In [1], Shafique et al. describe a series of attacks and vulnerabilities of smart-phone authentication mechanisms and present a comparative analysis of various authentication techniques.
Agrawal and Patidar explore in [2] multiple smart-phone security techniques addressing the user-to-device authentication using biometrics behavioral analysis. Regarding the importance of eliminating the passwords in the authentication process, Lindemann presents in [3] the advantages of FIDO, a challenge-response protocol which employs cryptographic keys.
In [4], Everts et al. also explore the idea of using a smartphone to authenticate to web-services by means of cryptographic keys, thus replacing the passwords. The security features of Android enabled smart-phones and their capability of executing cryptographic operations in a Trusted Execution Environment (TEE) are analyzed by Cooijmans et al in [5].
In [6], Broeder et al. present the advantages, in terms of security and operational costs, when a federated identity management system is employed by multiple organizations. The importance of using authentication mechanisms (for accessing both web and physical resources) which take into consideration the usability factor is stressed by Carullo et al. in [7]. Multiple aspects regarding the Guest Wi-Fi security, are described by Yap et al. in [8], presenting the problem of nonuniform authentication methods for this type of networks.

III. SYSTEM ARCHITECTURE
The core element of our system architecture is the authentication and authorization stack comprised of the following: FIDO UAF & OpenID Connect as services and as client code libraries residing on the user device application. The proposed security system architecture is based on the work done in [10] [11].
FIDO UAF [9] is employed for the user to device and device to service authentication part of the security system, and OpenID Connect as authentication federation and authorization mechanism for organization services. FIDO UAF on the user device takes advantage of new Android features such as the Keystore that allows storing cryptographic material (asymmetric private keys in our case) on the Trusted Execution Environment of the device that is authenticated using biometric identification mechanisms such as fingerprint, or face recognition.
As for the federated authentication part, FIDO UAF and OpenID Connect can easily be extended to communicate with each other. This extension allows the user to register his biometric attributes instead of cumbersome and complex passwords that in many cases are reused, or forgotten. User biometrics are used to access his cryptographic credentials and never leave his device through the whole authentication and authorization process.
Generating RADIUS credentials for the Auth Wi-Fi SSID can easily be achieved by extending the FIDO UAF Server to generate and save such credentials inside the RADIUS database after a successful authentication process for a particular user.
As observed from the proposed system architecture diagram, there are four steps required in order to authenticate and authorize service access to the user:  3. Besides generating RADIUS credentials, the FIDO UAF Server also generates an authentication id, which is transferred to the user device and is sent to the OIDC Provider in order to verify authentication status. This authentication id is designed as a short lived token which is consumed (invalidated) at every successful validation response by the FIDO UAF Server, or after a designated time frame; 4. After the user selects an organization service, the OIDC authorization process starts and the Identity Provider verifies with the FIDO UAF Server if the user is authenticated and if his attributes meets the authorization policy.
IV. SYSTEM IMPLEMENTATION Regarding the system implementation, for the Android security application we used a smart-phone equipped with a fingerprint reader, which authenticates the user in the FIDO protocol context. For the Wi-Fi router we used a dual-band Linksys WRT 1900 ACS device on which we installed an OpenWRT operating system, this being the NAS for our system. The NAS advertises two Wi-Fi SSID: WiFi-Open -the no password network which allows the user to authenticate and obtain the temporary credentials for the WiFi-Auth -the WPA2 Enterprise network which exposes the protected resource (in our case this being the Internet connection). Along with the Wi-Fi networks, the employed NAS also has an Ethernet switching module, used to connect the Wi-Fi networks to the server, which runs our authentication stack, and to the Internet gateway. The NAS has four networks, logically separated by VLANs, as follows: • WiFi-Open (VLAN O) -hosts the unauthenticated users, and the server, which offers the authentication services.
• WiFi-Auth (VLAN A) -hosts the authenticated users, which can access the protected resources.
• Management (VLAN M) -it is special network which allows managing the NAS via a SSH connection.
• Internet (VLAN I) -it is the network which offers access to the protected resource. The NAS has a route, which allows the packets originating from the WiFi-Auth network to be routed to the Internet network (NAT).
The system configuration on the NAS side is presented in Figure 2. As it can be observed, the NAS Ethernet switching module shares the same VLAN broadcast domain with the Wi-Fi networks, by using Linux bridges (brctl). The NAS CPU port, which is connected to the Ethernet switching module, operates only with VLAN tagged packets in order to forward the packets to the corresponding Linux VLAN interface. For our implementation, we used only one NAS Ethernet port configured as trunk, the actual connection to the authentication server, management module and Internet gateway being handled by another switch.
For the advertised Wi-Fi networks, the NAS plays the role of DHCP server, default gateway and DNS server (using OpenWRT dnsmasq), the latter being used to solve to internal domain names employed in the FIDO protocol. The WiFi-Auth network has configured as authentication method WPA2 Enterprise, along with a RADIUS back-end server and a shared secret (used by the RADIUS protocol to permit the authentication between the NAS and the RADIUS authentication server). For the RADIUS authentication server we used the FreeRADIUS solution for which we configured an SQL back-end credentials server (MariaDB hosted on the same machine as the RADIUS server) which holds the temporary user credentials. Thus, after the user is authentication on the FIDO server side, the randomly generated user credentials are injected into the SQL back-end. More specifically, we used the FreeRADIUS radcheck SQL table to insert the randomly generated credentials as follows: the UserName and Value fields contain the random material generated by the FIDO server. Taking into consideration this mechanism, the RADIUS server is not aware of the FIDO based authentication stack, executing the authentication session by querying normal username/password credentials. This authentication flow is depicted in Figure 3. The random credentials are short-lived tokens, being erased from the RADIUS database after a few seconds the authentication process is finalized. Thus, the FIDO server controls the time frame in which the authenticated user can use the obtained credentials, mitigating a credential re-use attack at a later time, when the user might be revoked from the system. This mechanism also blocks the attackers that may capture the authentication token from accessing the protected network.
On the smart-phone side, after the FIDO authentication ends, the application receives the random credentials that have to be used for the authentication to the protected network via WPA2 Enterprise. In order to design a user-friendly security system, the smart-phone application makes the switch to protected Wi-Fi network automatically, using the provisioned temporary credentials as user-name and password.
To implement this feature we used the Android SDK WifiManager and WifiConfiguration classes to add a new network configuration. In the new Android network configuration, we added the following: the protected network SSID, the key management method is set to IEEE8021X and WPA_EAP, the EAP method is set to PEAP and the random credentials are set as identity and password. Because the 802.1X PEAP method is used, an issue, which must be taken into consideration the RADIUS certificate, trust. This certificate must be verified against a trusted chain or by using a certificate pinning method in order to prevent the smart-phone supplicant to execute the authentication protocol with a rogue RADIUS server, which may capture the random credentials. In our implementation, we installed the RADIUS certificate trusted chain using the previously mentioned Android classes, but in other implementations this certificate could be simply trusted by the Android system or provided by the FIDO server along with the random credentials.

V. CONCLUSIONS
Flexible authentication and authorization mechanisms are critical for the enterprise networks, which offer services to guest users which may have a temporary access. The security scheme proposed in this paper leverages the security capabilities of Android smart-phones in order to design a userfriendly authentication mechanism the need to provision temporary users with user-name/password credentials or even digital certificates. One of the main advantages of our work is the fact that this system can serve as a basis for a roaming user authentication scenario. Thus, two organizations, which establish a trust relation (mutual authentication), can interconnect a local Wi-Fi enterprise structure with the FIDO based security stack deployed remotely, obtaining a federated authentication scheme. Another characteristic that must be taken into consideration in this security scenario, is the user anonymity, which may be achieved if the Organization Identity Service and the Wi-Fi enterprise structure are located in separated trust domains. Regarding the user security, the FIDO protocol permits generating a pair of asymmetric cryptographic keys especially for a certain resource (in our case the protected Wi-Fi network), thus the user does not employ other cryptographic material associated with another resource. In addition, the FIDO cryptographic keys are removed and deregistered from the server side after the Wi-Fi usage is ceased. Taking into consideration the modular structure of our security scheme, which may enable federated authentication schemes, rapid used revocation can be obtained even though the user tries to access the resources located at another organization premises. Moreover, the proposed security scheme is feasible in terms of operational expenses because it can be integrated with an already existing Wi-Fi enterprise security structure. Regarding the future work, we plan to adapt the proposed security system to a smart-home scenario, where the user can authorize the IoT device to connect to the Home Area Network (Wi-Fi 802.1X protected).
For this scenario, we also plan to address the non-802.1X capable IoT devices by using a MAC authentication bypass mechanism.