Universidade de Aveiro Departamento de Eletrónica,Telecomunicações e Informática 2019
José Pedro
Estima Santos
Portais WIFI Seguros no Ambiente WIFI4EU
Secure WIFI Portals in WIFI4EU Environment
Universidade de Aveiro Departamento de Eletrónica,Telecomunicações e Informática 2019
José Pedro
Estima Santos
Portais WIFI Seguros no Ambiente WIFI4EU
Secure WIFI Portals in WIFI4EU Environment
Dissertação apresentada à Universidade de Aveiro para cumprimento dos requisitos necessários à obtenção do grau de Mestre em Engenharia Infor-mática, realizada sob a orientação científica do Doutor João Paulo Silva Bar-raca, Professor auxiliar do Departamento de Eletrónica, Telecomunicações e Informática da Universidade de Aveiro, e do Doutor André Ventura da Cruz Marnoto Zúquete, Professor auxiliar do Departamento de Eletrónica, Teleco-municações e Informática da Universidade de Aveiro.
Agradecimento ao IT
o júri / the jury
presidente / president Professor Doutor Diogo Nuno Pereira Gomes Professor Auxiliar, Universidade de Aveiro
vogais / examiners committee Professor Doutor Carlos Nuno da Cruz Ribeiro Professor Associado, Universidade de Lisboa - Instituto Superior Técnico
Professor Doutor André Ventura da Cruz Marnoto Zúquete Professor Auxiliar, Universidade de Aveiro
agradecimentos /
acknowledgements Visto que não tenho muito jeito para escrever estas coisas, vou fazê-lo deuma forma muito simples. O meu maior agradecimento aos meus pais por me terem educado, apoiado e suportado, de forma incondicional, ao longo deste percurso. Deixo também um agradecimento a toda a minha família que me acompanha desde miúdo, em especial à minha madrinha por me tranquilizar quando necessário. Deixo também o meu profundo agradecimento ao Professor João Paulo Barraca, orientador desta tese, e ao Professor André Zúquete, co-orientador desta tese, por toda a ajuda, disponibilidade, partilha de conhecimento e valiosas orientações que me deram, nada disto seria possível sem eles. Por fim, um obrigado a todos os meus amigos que sempre estiveram, e estarão, presentes durante este percurso a que chamamos vida. Acredito vivamente que tudo o que fazemos na vida têm muito mais valor se aqueles que nos são próximos estiverem lá para ver.
Palavras Chave 802.1X, segurança, redes informáticas, EAP, TLS, captive portals, hotspots.
Resumo Visto que as redes hotspot estão cada vez mais presentes e são bastante uti-lizadas, a quantidade de informação sensível que é transmitida neste tipo de redes e o facto dos utilizadores poderem não ser de confiança, faz com que seja necessária a existência de mecanismos de segurança que consigam ga-rantir, pelo menos, a confidencialidade e integridade dos dados transmitidos, bem como a autenticação deste tipo de redes, por forma a evitar eventuais redes malignas. Grande parte dos hotspots públicos funcionam com base em captive portals sendo necessária uma "autenticação", que nem sempre pode ser considerada como segura (através de um portal web) contudo estes po-dem ser explorados por forma a ser utilizados, em conjunto com outras tecno-logias, para providenciar soluções mais seguras. Este trabalho estuda o que é a arquitetura 802.1X e a forma como é utilizada, estuda também como fun-cionam os captive portals e as diferentes formas através das quais hotspots públicos fornecem Internet aos seus utilizadores. O objetivo deste trabalho é desenvolver uma aplicação que permitirá aos seus utlizadores registaram-se num sistema, fornecer-lhes credenciais assimétricas, de uma forma simplifi-cada, e configurar uma ligação Wi-Fi a uma rede segura. O registo neste sistema e o download da aplicação serão feitos através de um captive por-tal. Os utilizadores poderão então autenticar-se na rede Wi-Fi segura que foi configurada nos seus dispositivos, esta rede utiliza uma extensão do proto-colo EAP, nomeadamente o TLS, para autenticar os seus utilizadores tendo em conta as credenciais assimétricas que lhes foram fornecidas. Esta rede além de permitir fazer autenticação, autorização e a contabilização dos seus utilizadores, também permitirá que os utilizadores que se registem num de-terminado captive portal possam utilizar esta rede em qualquer sítio onde é fornecida.
Keywords 802.1X, security, networks, EAP, TLS, captive portals, hotspots.
Abstract As hotspot networks are increasingly present and used, the amount of sen-sitive information that is transmitted in this type of network and the fact that users might not be trustworthy leads to the need for existence of security mechanisms that can guarantee, at least, confidentiality and integrity of the users’ transmitted data, as well as the authentication of these networks in or-der to avoid malicious ones. The majority of public hotspots work based on captive portals and require "authentication", which is not always a secure one (through a captive portal) however, captive portals can be explored in order to be used in conjunction with different technology to provide more secure so-lutions. This works studies the 802.1X architecture and the way it is used, it also studies captive portals and the different ways that public hotspots provide Internet to its users. The goal of this work is to develop an application that will allow users to register themselves in a system, seamlessly provide them with asymmetric credentials and configure a Wi-Fi connection to a secure network. The registration in this system and the download of the application are done through a captive portal. The users can then authenticate in the secure Wi-Fi network that was configured in their devices, this network is an extension of the EAP method, namely TLS, to authenticate the users according to the cre-dentials that were given to them. This network also allows for authentication, authorization and accounting of its users, it will also allow users that registered in a given captive portal to use the network in any place where it is provided.
Contents
Contents i
List of Figures v
List of Tables vii
Glossary ix
1 Introduction 1
1.1 Motivation . . . 1
1.2 Objectives . . . 2
1.3 Thesis Structure . . . 3
2 State of the Art 5 2.1 IEEE 802.11i . . . 5
2.2 IEEE 802.1X . . . 5
2.2.1 802.1X Entities . . . 6
2.2.2 802.1X Port Entities . . . 6
2.2.3 802.1X Authentication Process . . . 6
2.2.4 Simplification for SOHO environments . . . 8
2.2.5 Sessions Keys . . . 8
2.3 RADIUS . . . 9
2.3.1 Indirection levels . . . 9
2.3.2 New protection mechanisms . . . 10
2.4 Extensible Authentication Protocol . . . 11
2.5 EAP Packets . . . 11
2.6 EAP Methods . . . 11
2.6.1 EAP-TLS . . . 11
2.6.2 EAP-TTLS . . . 12
2.6.4 EAP-PSK . . . 13
2.6.5 EAP-SIM, EAP-AKA and EAP-AKA’ . . . 13
2.6.6 EAP-PWD . . . 14
2.6.7 Comparison and viability of different EAP methods . . . 15
2.7 Captive Portals . . . 17
2.7.1 Implementations . . . 18
2.7.2 Security Limitations . . . 18
2.8 Wi-Fi Business models . . . 19
2.9 Hotspot 2.0 . . . 20
2.9.1 Architectures . . . 20
2.9.2 Improving Wi-Fi hotspots trustworthiness . . . 23
2.10 Eduroam . . . 24
2.11 LTE Networks and Wi-Fi Integration in Operator Networks . . . 25
2.11.1 Problems with current deployments . . . 27
2.12 NFV and SDN . . . 28
3 Solution 31 3.1 Requirements . . . 31
3.2 Architecture . . . 32
3.2.1 Certificate-based authentication vs Password-based authentication . . . 33
3.2.2 Overview . . . 34 3.2.3 Networks . . . 35 3.2.4 Necessary Keys . . . 36 3.2.5 Mobile Application . . . 36 3.2.6 Laptop application . . . 38 3.2.7 Authentication Server . . . 38 3.2.8 Accounting . . . 39
3.2.9 Authentication of roaming users . . . 39
3.2.10 Preventing exposure of the users’ location in the roaming process . . . 41
3.3 First Method - Locally Signing User Certificates . . . 42
3.3.1 Considerations . . . 45
3.4 Second Method - Request Credentials from the AS . . . 45
3.4.1 Considerations . . . 47
3.4.2 Preventing exposure of the users’ location . . . 47
3.5 Scenarios . . . 49
3.5.1 Play store support vs. no support . . . 49
3.5.2 User with account vs User without account . . . 49
3.5.4 Reauthentication and Sessions . . . 50
3.5.5 Lost of credentials . . . 51
3.5.6 Third parties registration mechanisms . . . 51
3.5.7 Chave Móvel Digital (CMD) . . . 51
3.5.8 Legal rights . . . 52 4 Implementation 53 4.1 Application . . . 53 4.1.1 Android Application . . . 53 4.1.2 Linux Application . . . 61 4.2 Authentication Servers . . . 62
4.2.1 Home Authentication Server . . . 63
4.2.2 Local Authentication Server . . . 68
4.2.3 DHCP Relay . . . 71 4.2.4 Network configuration . . . 71 4.2.5 Problems . . . 73 5 Results 75 5.1 Captive Portal . . . 75 5.2 Android application . . . 80 5.3 Linux Application . . . 81 5.4 EAP TLS Authentication . . . 83 5.4.1 Successful authentication . . . 83 5.4.2 Failed authentication . . . 86 5.5 Reauthentication . . . 88 5.6 DHCP . . . 90 5.7 Roaming Authentication . . . 91
5.7.1 Communication between the user’s device and the local AS . . . 91
5.7.2 Communication between the local AS and the user’s home AS . . . 92
5.8 Requesting credentials from the AS . . . 95
5.8.1 Requesting credentials from the user’s home AS . . . 96
5.8.2 Requesting credentials from the home AS through the local AS . . . 98
5.9 DNS . . . 104
6 Conclusion 105
List of Figures
2.1 802.1X architecture. . . 6
2.2 802.11 / EAPoW authentication process. . . 7
2.3 Example of RADIUS architecture. . . 9
2.4 HS 2.0 architecture: SIM device. . . 21
2.5 HS 2.0 architecture: non-SIM device. . . 21
2.6 Internet Service Provider with Subscription Servers. . . 22
2.7 Features according to [22]. . . 24
2.8 LTE Network Architecture. . . 26
3.1 Architecture overview. . . 34
3.2 Registration process. . . 37
3.3 Roaming authentication process. . . 40
3.4 RadSec process. . . 41
3.5 Using Tor together with RadSec for improving users’ privacy. . . 42
3.6 Authentication using credentials locally signed by the application. . . 43
3.7 Authentication using credentials signed by the AS. . . 46
3.8 Service that requests credentials on users behalf. . . 48
4.1 Mobile registration process. . . 54
4.2 Example of a certificate issued by the application. . . 56
4.3 Flowchart of the service that changes the user’s credentials. . . 58
4.4 Obtaining credentials from the AS. . . 59
4.5 Example of a certificate issued by the home AS. . . 60
4.6 Information contained in a QR Code. . . 60
4.7 Import credentials to a Linux device. . . 61
4.8 Home AS issuing certificates for the users. . . 64
4.9 Validation of the users’ credentials. . . 66
4.10 Local AS proxying certificate request to the user’s home AS. . . 70
4.12 Network setup. . . 72
5.1 Redirecting a user to the captive portal’s web page. . . 75
5.2 Captive Portal’s Web page. . . 76
5.3 AS sending Signal message 1. . . 77
5.4 AS sending Signal message 2. . . 78
5.5 Android receiving Signal message. . . 79
5.6 Android application for a non-registered person. . . 80
5.7 Android application interface upon a registration. . . 80
5.8 Linux application interface. . . 81
5.9 Linux network configuration. . . 82
5.10 EAP authentication TLS. . . 83
5.11 EAP authentication RADIUS 1. . . 84
5.12 EAP authentication RADIUS 2. . . 85
5.13 EAP Failure 1. . . 86
5.14 EAP Failure 2. . . 87
5.15 Reauthentication 1. . . 88
5.16 Reauthentication 2. . . 89
5.17 DHCP logs. . . 90
5.18 Roaming RADIUS authentication 1. . . 91
5.19 Roaming RADIUS authentication 2. . . 91
5.20 RadSec proxy request from the local AS to the home AS. . . 92
5.21 Validation of RadSec credentials of the local and home AS. . . 93
5.22 RadSec authentication completed and initial data exchange. . . 94
5.23 Final data exchange to authenticate the user. . . 95
5.24 Client connecting to the home AS to request a new certificate. . . 96
5.25 Home AS sending certificate back to the client. . . 97
5.26 Client connecting to the local AS to request a new certificate. . . 98
5.27 Local AS receiving the information and establishing a connection with Tor. . . 99
5.28 Request being forwarded to the user’s home AS from a Tor exit node. . . 100
5.29 TLS connection established between the Tor exit node and the user’s home AS. . . 101
5.30 Data exchange between the local AS and the Tor entry node. . . 102
5.31 Certificate issued by the user’s home AS being sent to him from the local AS. . . 103
List of Tables
Glossary
3GPP 3rd Generation Partnership Project AAA Authentication, Authorization and
Acounting
AES Advanced Encryption Standard AES Advanced Encryption Standard AK Authentication Key
ANQP Access Network Query Protocol APK Android Application Package AP Access Points
AS Authentication Server CA Certification Authority CMD Chave Móvel Digital
DHCP Dynamic Host Configuration Protocol DNS Domain Name System
EAPoL EAP over LAN
EAP Extensible Authentication Protocol EC Elliptic Curve
EMSK Extended Master Session Key EPC Evolved Packet Core
ePDG evolved Packet Data Gateway GDPR General Data Protection Regulation GPRS General Packet Radio Services GSM Global System for Mobile GTK Group Temporal Key HLR Home Location Register HS 2.0 Hot Spot 2.0
HSS Home Subscriber Server
HTTPS Hyper Text Transfer Protocol Secure HTTP HyperText Transfer Protocol HTTP HyperText Transfer Protocol
ICMP The Internet Control Message Protocol IEEE Institute of Electrical and Electronics
Engineers
IPSec Internet Protocol Security IP Internet Protocol
ISP Internet Service Providers JSON JavaScript Object Notation KCK Key Confirmation Key KDK Key Derivation Key KEK Key Encryption Key LAN Local Area Network LTE Long-Term Evolution MAC Media Access Control MAP Mobile Application Part MiTM Man-in-the-Middle
MK Master Key
MME Mobility Management Entity MSK Master Session Key
NAI Network Access Identifier NAPTR Name Authority Pointer NAS Network Authentication Server NAT Network Address Translation NFC Near-Field Communication NFV Network Functions’ Virtualization nmcli Network Manager Command Line
Interface
OAEP Optimal Asymmetric Encryption Padding
OI Organizational Identifiers OSA Open System Authentication OSU Online Sing Up
OS Operative System
PCRF Policy and Charging Rules Function PDN-GW Packet Data Network gateway PFS Perfect Forward Secrecy PKI Public Key Infrastructure PKI Public Key Infrastructure PMIPv6 Proxy Mobile IPv6 PMK Pairwise Master Key PPP Point-to-Point
PPS MO PerProviderSubscription Management Object
PTK Pairwise Transient Key QoE Quality of Experience QR Code Quick Response Code
RADIUS Remote Authentication Dial-In User Service
RAN Radio Access Network RFC Request for Comments RSA Rivest–Shamir–Adleman RSN Robust Security Network S-GW Serving Gateway
SAML Security Assertion Markup Language SDN Software-defined Networking
SIM Subscriber Identification Module SMS Short Message Service
SOHO Small Office Home Office SRV Service Record
SSID Service Set Identifier
SSL Secure Sockets Layer
TCP Transmission Control Protocol TKIP Temporal Key Integrity Protocol
TK Temporal Key
TLS Transport Layer Security UDP User Datagram Protocol UDP User Datagram Protocol
UMTS Universal Mobile Telecommunications Service
URL Uniform Resource Locator
USIM Universal Subscriber Identity Module VLAN Virtual LAN
VM Virtual Machine
VNF Virtual Network Functions WFA Wi-Fi Alliance
WLAN Wireless Local Area Network WPA2 Wi-Fi Protected Access II
CHAPTER
1
Introduction
This chapter’s purpose is to give an introduction to the thesis, describing the problem and the objectives of this work, as well as the structure of the document.
1.1 Motivation
The growth of the Internet made it one of the main forms of entertainment used by people. This growth also made possible the existence of certain services, such as online banking, shopping, social media, amongst others. This caused many businesses to provide free Internet access, by using public hotspots, to supply an extra service to their customers and attract new ones, this phenomena lead to an increase of public hotspots and consequently an increase in the number of potentially dangerous networks in it.
Currently, free Internet access is provided mostly by public hotspots which are networks of easy access, which makes them very useful. Public hotspot networks usually work with captive portals to allow users to connect to a network. Captive portal solutions usually require the user to agree with some sort of terms and conditions to be allowed to use the network. Despite being a very popular solution worldwide, it lacks security measures to protect its users and their data. Some of the most serious problems related with public hotspots are:
1. Clients’ traffic is not encrypted; thus, it can be captured in clear text by eavesdroppers. 2. Transmitted information has no integrity control; thus, it can be modified by attackers. 3. Users and devices can be deceived by rogue access points.
Therefore, in spite of being a very popular access control mechanism, it has a serious shortage in security measures, since all of the network’s traffic can be inspected, intercepted and even modified. Entities providing free Wi-Fi should use solutions respecting at least the confidentiality and integrity of users’ data but ideally the following key aspects of security:
1. Confidentiality, ensuring that the information is not available to unauthorized entities; 2. Integrity, ensuring the non-modification of information without authorization;
4. Authentication, ensuring the legitimacy of a user;
This thesis intends to develop a solution, based on the captive portals’ paradigm, to allow users to have an easy and seamless access to free and secure Wi-Fi networks which are capable of protecting its users’ data and incorporate the previously mentioned key aspects of security.
1.2 Objectives
The WIFI4EU’s1 initiative has the objective of providing a Wi-Fi network in multiple places around Europe. The network must be free, must have coverage in points of interest, must be based on the captive portals’ paradigm by using public hotspots and must allow the possibility of identifying its users if needed.
WIFI4EU’s initiative was divided into two main phases. The first phase is related with having only local authentication, meaning that users need to register on the captive portal in each visited place providing the WIFI4EU service. The system must provide Authentication, Authorization and Acounting (AAA) of its users and the AAA is responsibility of each beneficiary according to European and national laws. By beneficiary it is understood the city halls that are chosen by WIFI4EU to receive 15000 euros vouchers to provide the WIFI4EU service.
WIFI4EU has a second phase that aims at the development of a solution that can evolve into a federated architecture. In this thesis we developed a solution for the second phase. Thus, our objectives were to develop a system that can be used by anyone to access free and secure network, with the possibility to authenticate local and foreign users. In more detail, the objectives of this thesis were the following:
1. Study the 802.1X architecture, the EAP meta protocol and how this protocol works, the methods that are available and assess the viability of these methods for our scenario. 2. Study how captive portals work, how are they implemented and their vulnerabilities. 3. Study how RADIUS works, how is it implemented and how remote authentication is
performed.
4. Study current Wi-Fi business models and how Internet access is provided to end users. 5. Study how Hotspot 2.0 works and its different architectures.
6. Study how can Wi-Fi hotspots’ security be improved without modifying the clients’ supplicant or the AP.
7. Study similar systems to provide uniform network access in different countries through the same network, such as Eduroam.
8. Study LTE networks and how is Wi-Fi integrated in operator networks. 9. Study NFV and SDN.
10. Propose an architecture. 11. Implement a solution.
1
1.3 Thesis Structure
In order to reflect the work that was done, the remainder of this document is structured in the following way.
Chapter 2 contains the state of the art regarding the fundamental technologies that are, or can be, explored in secure, wireless access networks.
In chapter 3 are first presented the requirements imposed by the WIFI4EU’s initiative regarding the implementation of the system and our view on which requirements are actually important when it comes to developing a secure and convenient solution.
In chapter 4 we describe how the proposed architecture was implemented.
In chapter 5 we provide the results that we obtained from a set of tests of the system. Finally, chapter 6 presents a conclusion about the discussed problem, the solution’s description and advantages and future work perspectives.
CHAPTER
2
State of the Art
In this chapter it will be described the state of the art related with 802.11i, 802.1X, RADIUS, EAP, Captive Portals, Wi-Fi Hotspot business models, Hotspot 2.0, Eduroam, LTE Networks and Wi-Fi integration, Network Functions’ Virtualization and Software-Defined Networks. The chapter intends to give an overview of a set of technologies that can be used to provide a
secure wireless network, despite the ones that we will use in our architecture.
2.1 IEEE 802.11i
Institute of Electrical and Electronics Engineers (IEEE) 802.11i1, or Wi-Fi Protected Access II (WPA2), is a standard which defines one security model for 802.11 networks. 802.11i uses the Robust Security Network (RSN) concept, a RSN network must support an authentication between the interlocutors based on 802.1X [13], a distribution of session keys, also based on 802.1X, a management of session keys and frame protection mechanisms based on Advanced Encryption Standard (AES) or Temporal Key Integrity Protocol (TKIP) [28].
2.2 IEEE 802.1X
IEEE 802.1X [13] is a standard for port-based network access control, it provides an authenti-cation mechanism for devices to authenticate themselves in Local Area Network (LAN) and Wireless Local Area Network (WLAN), this authentication is based on Extensible Authentica-tion Protocol (EAP), which is an encapsulaAuthentica-tion protocol used only for the Access Points (AP) to know that the supplicants’ traffic is destined to the Authentication Server (AS). This standard allows for mutual authentication between the network and its clients, and it also allows for the generation and distribution of session keys for link-layer traffic protection. The distribution of these keys is very important to ensure that there is confidentiality and integrity in the connection between the client and the network.
Figure 2.1: 802.1X architecture.
Figure 2.1 shows the different entities of the 802.1X architecture. During an 802.1X authentication, after the client and the AS prove their authenticity to each other it is arranged for the distribution of a Master Session Key (MSK), which it will be used to further calculate the necessary sessions keys needed between the Supplicant and the AS, the session keys will then be used to encrypt the remainder of the communication, thus ensuring the confidentiality of the exchanged data, this will further be explained in subsection 2.2.5. IEEE 802.1X was first developed for cable networks and eventually was extended to wireless networks.
2.2.1 802.1X Entities
The 802.1X architecture involves the following three entities:
• The Supplicant, which is the device that wishes to attach to the LAN or WLAN. • The Authenticator, which is a network device, such as an AP, that controls the access
of supplicants to the network.
• The Authentication Server (AS), which is the backend server in charge of the mutual au-thentication process between the supplicant and the network (e.g Remote Auau-thentication Dial-In User Service (RADIUS) [21]).
2.2.2 802.1X Port Entities
In 802.1X it is defined that for every authentication session there are two logical port entities on the Authenticator that control the access of the supplicant to the network: the controlled port and the uncontrolled port. The authorized state allows network traffic to ingress to or egress from the controlled port; the unauthorized state prevents network traffic to ingress to or egress from the controlled port. The uncontrolled port is simply used to exchange EAP over LAN (EAPoL) frames between the supplicant and the AS.
The controlled port is initially on an unauthorized state and after a successful authentication process its state is changed into authorized and the supplicant is then allowed to communicate normally with the network.
2.2.3 802.1X Authentication Process
In 802.1X, the EAP encapsulation between the Supplicant and the Authenticator is done over LAN, EAPoL, and the EAP encapsulation between the Authenticator and the AS is done over RADIUS.
Figure 2.2: 802.11 / EAPoW authentication process.
The 802.1X authentication is done in three major stages as shown in Figure 2.2.
1. The Supplicant connects to the AP with the usual 802.11 process of network discovery, Open System Authentication (OSA) and association between itself and the AP. OSA is a simple two step process, the client sends an authentication management frame containing its identity and the AP sends back a frame informing if it recognizes the identity of the client. By the end of this stage the controlled port’s state is unauthorized. 2. At this stage, the Supplicant sends a EAPoL Start message and EAP messages are
exchanged. These messages include the Supplicant’s identity as well as pairs of EAP Request-Response and RADIUS Request-Challenge until the EAP method is completed either with success or with failure. Usually at this stage it takes place the mutual authentication and the distribution of session keys between the Supplicant and the AS. This dialog takes place through the uncontrolled port. By the end of this stage, the status of the controlled port is still unauthorized.
3. At last, it takes place the mutual authentication and the distribution of sessions keys between the Supplicant and the Authenticator. It is then performed a four-way handshake which involves the exchange of four messages. By the end of this exchange, if all the
steps where successful, the status of the control port will be authorized and the client will have network access.
2.2.4 Simplification for SOHO environments
The previously described 802.1X architecture requires an AS, which makes it very complex to Small Office Home Office (SOHO) environments. Taking this into consideration, it is possible to use only part of the system, excluding the AS.
This solution is commonly known as WPA-PSK or WPA2-PSK and it uses a shared secret, Pre-Shared Key (PSK), between each Supplicant and the Authenticator. This key can be the same to all network users that are Supplicants.
It is clearly understood that this authentication system with a single PSK per network should only be used when the universe of users of a network is small and trustworthy. This is the case of a family, small group of friends or a small company, which are all perfect examples of the typical environments that prefer the SOHO approach [28].
The SOHO architecture is similar to the one present in Figure 2.1 without the AS.
2.2.5 Sessions Keys
802.1X produces different sessions keys, which are used for different purposes. The first key to be calculated is the MSK, it is calculated by the Supplicant and by the AS after a successful EAP authentication [28].
The second key to be calculated is the Pairwise Master Key (PMK), which has 256 bits. This key is calculated by the Supplicant and the Authenticator from either the MSK, in the EAP case, or with the PSK, in case of SOHO environments. The PMK is used to ensure a correct message exchange between the Supplicant and the Authenticator, by the end of said exchange both parties possess a new shared session key, Pairwise Transient Key (PTK) and a key for secure communication between Supplicant groups, Group Temporal Key (GTK) [28].
During the four-way handshake both parties randomly generate and exchange two nonces, a nonce is an arbitrary number that can be used just once in a cryptographic communication. Based on those nonces, their Media Access Control (MAC) addresses and PMK, it is produced PTK, this key can be subdivided into three keys [28]:
• Key Confirmation Key (KCK), which has 128 bits and it is used to authenticate all of the messages of the four-way handshake, except the first one.
• Key Encryption Key (KEK), which has 128 bits and it is used to encrypt useful data transmitted in EAPoL Key messages. Namely, used to encrypt group keys.
• Temporal Key (TK), which is the session key used by the Supplicant and the Authenti-cator, after the four-way handshake, to ensure that their communication is only between themselves and it does not involve third parties. This protection can be done with either TKIP or AES.
There is another key Extended Master Session Key (EMSK), however it does not have a clearly defined purpose yet [28].
2.3 RADIUS
RADIUS [21] is one example of an AAA service. RADIUS is used to control the access of users and devices to a network through a Network Authentication Server (NAS). A RADIUS server and a NAS are used to perform the authentication of users and devices. RADIUS provides three types of services :
• Authentication of users or devices before being granted network access.
• Authorization of users or devices to the usage of certain services, such as the network. • Accounting for the usage of those services.
Figure 2.3: Example of RADIUS architecture.
In RADIUS terminology, the NAS is the Authenticator. This architecture is fairly similar to the IEEE 802.1X, but the Authenticator is referred to as NAS, as it is shown in Figure 2.3. In the RADIUS protocol, there is no distinction between Authentication and Authorization. What exists are requests to access resources which are authorized, or not, according to the user’s identity, or other circumstances, such as the time when the request was made. Because of this access requests involves the authentication of the requesting user or machine [28].
The communication between a client and a RADIUS server is accomplished with questions and answers, using the User Datagram Protocol (UDP). The questions have a request and a set of attributes that help a RADIUS server to make a decision. The answers have the decision that was made and a set of attributes. For instance, if the client is a NAS, those attributes may be used to guide the way it must interact with the authenticated users [28].
2.3.1 Indirection levels
RADIUS supports multiple indirection levels, and has two concepts used for authentication purposes: realms and proxies. The username is split in two components: the name of the user and the realm of the user, separated by a character defined in RADIUS configuration, usually
@. For instance, the name john.doe@ua.pt means the john.doe user in the ua.pt realm.
When a username with a realm is presented to a RADIUS server, it can redirect the request to the appropriate realm’s RADIUS server. This way, the first RADIUS server acts as a proxy between the user and their realm.
A request redirected by RADIUS server contains a special attribute, Proxy-State. It is replicated as many times as it roams along RADIUS servers. This means that a request redirected through a chain of servers, will have as many Proxy-State attributes as redirections, which allows for the response to be sent to the NAS where the request was initially done, after the authentication process is completed [28].
Another way to redirect users to their appropriate realm’s RADIUS server is by using RadSec, which was defined in Request for Comments (RFC) 6614 [27], and translates to
RADIUS over Transport Layer Security (TLS). In a RadSec scenario, a client is a RADIUS server proxying a request, and a server is the one answering to the request. Both parties use an asymmetric keypair and a X.509 certificate to authenticate themselves. RadSec improves security, because all of the communications use TLS, ensuring that all the information exchanged between RADIUS servers is protected from eavesdroppers.
RadSec uses Transmission Control Protocol (TCP) which provides a reliable transport, while the normal RADIUS proxy use UDP, facilitates the detection when a RADIUS server is down or unreachable, and it allows requests to be made directly to the users’ home AS. In traditional RADIUS, requests are proxied between all of the hierarchy servers until they reach the intended one. However, with RadSec, it is possible to use Domain Name System (DNS) queries, to obtain a user’s home AS from their realm, and proceed with the authentication without additional packet redirections.
To proxy an authentication to a specific realm a Name Authority Pointer (NAPTR) query is used, which will point to the service target that handles the realms’ requests. Then, a Service Record (SRV) query is used to obtain the Internet Protocol (IP) address to where the request must be proxied to. This allows RADIUS servers to have a dynamic proxy configuration, which depends on the users realm, it is also the reason as to why certificates are needed, in normal RADIUS proxies a server only needs to know and trust the one immediately above and below him in the hierarchy, whilst in RadSec there is no hierarchy and the certificates provide similar functionality.
2.3.2 New protection mechanisms
When RADIUS protocol was designed, it was not anticipated the existence of critical data exchanges, besides passwords. Thus, its protection mechanisms are essentially the authenti-cation of RADIUS responses, which does not allow a NAS to be deceived by fake messages sent by attackers, and the encryption of the User-Password attribute. As the RADIUS server started to be used to support even more indirect authentications, there was the need for new security requirements that were not considered in the protocol at the time. The solution for that was the creation of new attributes that could provide the required functionalities without breaking the ones already present.
One of the biggest changes of the RADIUS protocol evolution consists in the exploration of RADIUS in EAP authentication. The EAP messages are independent from the RADIUS and are transmitted in RADIUS messages encapsulated in a new attribute, EAP-Message. Also, every messages sent between a NAS and a RADIUS server that contain an EAP message must have one extra authenticator, which is encapsulated in another new attribute,
Message-Authenticator. For requests to the server, the value of this attribute must be the result of the
HMAC-MD5 algorithm to the complete RADIUS message and to the secret key that is shared between the NAS and the RADIUS server. For server responses, it should be performed a similar calculation, but using the authenticator sent by the client, and not the authenticator of the response calculated by the RADIUS server, which must be calculated in the end taking into account the value of the attribute Message-Authenticator from the response [28].
2.4 Extensible Authentication Protocol
The EAP [1] is a meta protocol designed to encapsulate other authentication protocols; it is used in wireless networks (e.g 802.1X [13]) and Point-to-Point (PPP) [24] connections. This protocol does not implement any security mechanisms by itself, consequently the authentication method encapsulated by EAP must implement its own security.
The RFC 4017 [25] defines the following set of requirements for EAP protocols in Wi-Fi networks:
• Provide mutual authentication, resilient to Man-in-the-Middle (MiTM) and dictionary attacks.
• Guarantee the generation and distribution of a MSK to both parties (Supplicant and AS), this key must have at least 128 random and secret bits.
• Protect the identity of the Supplicant from eavesdroppers.
In 802.1X, the EAP is fundamental to release the AP, which plays the role of the Authenticator, from the task of managing particular aspects of authentication models. This way, the entire authentication process is centralized in a AS, which makes it possible to change the authentication mechanisms without changing the AP software [28].
2.5 EAP Packets
Regarding EAP packets, there are 4 possible codes and thus 4 possible messages. The codes are the following:
• Code 1 is an EAP Request. It is sent by the AS to the Supplicant. This packet is sent with the same identifier until a valid EAP response or a failure is received.
• Code 2 is an EAP Response. This packet is sent by the Supplicant to the AS in reply to an EAP request. These packets match the identifier from the request which it replies to. • Code 3 is an EAP Success. This packet is sent by the AS to the Supplicant in order to
notify that authentication has been completed.
• Code 4 is an EAP Failure, this packet is sent by the AS to the Supplicant in order to notify that authentication was not successful.
2.6 EAP Methods
The most commonly used EAP methods are EAP-TLS [23], EAP-TTLS [7], EAP-PEAP [20], EAP-PSK [5], EAP-SIM [10], EAP-AKA [2], EAP-AKA’ [3] and EAP-PWD [9]. These methods differ in multiple aspects such as usability, security, flexibility, system compatibility and others.
2.6.1 EAP-TLS
In this authentication protocol it is executed an authenticated negotiation of the TLS keys. When it finishes, both parties will have a shared secret which is the MSK. Both parties use an asymmetric key pair and a X.509 certificate to authenticate themselves.
Since a TLS session can exist for an arbitrary period of time and has a numerical identifier known by both parties, when negotiating a new secure session, TLS allows it to be done in two distinct ways: using the information previously known, or creating a totally new secure session. The first option has the advantage of allowing a more efficient negotiation, because it uses something already known by both parties.
The Supplicant’s identity is directly extracted from their public key certificate, therefore it is not possible to protect it during the execution of this protocol. This creates privacy and anonymity problems from possible network eavesdroppers. However, there is a strategy to deal with this privacy issue, which consists in repeating the protocol. On a first step, the supplicant provides an empty certificate list in the Certificate Verify message, and an AS configured for privacy accepts the response and continues with the setup of the secure session. Then, on a second step, the AS forces the supplicant to run another TLS session setup, over the one previously created, but now with a proper certificate list in the certificate verify message [18]. In this strategy it is assumed that both parties agreed on a cipher suite to ensure confidentiality on the initial step.
Another problem with this protocol is related with the usage of key pairs and certificates in order to authenticate the Supplicant, as this is a rather complex and unfriendly process it may not have a hearty reception by users [28].
Regarding EAP-TLS, the main advantage is the mutual authentication by using certificates. Since certificates can be revoked access of any user can be controlled by revoking their certificate. It also foresees privacy protection of the users’ identity. The main disadvantage is the need for the configuration of the users certificates.
2.6.2 EAP-TTLS
EAP-TTLS works in two stages. In the first stage, it is created a secure TLS channel between both parties, Supplicant and AS, to protect the remainder of the protocol, then, the Supplicant is authenticated using one of the possible authentication protocols, EAP. By the end of the authentication process, both parties will have a shared secret key, which is the MSK. In the first stage the AS authenticates as in EAP-TLS, with an asymmetric key pair and an X.509 public key certificate. This authentication prevents the Supplicant from being deceived by an attacker executing a MiTM, since the Supplicant will be able to authenticate the AS with its certificate, which is exchanged during this protocol.
In the second stage, the Supplicant authenticates itself using a username and password, which can be done using protocols that exchange cleartext information, because the authentica-tion is done inside the secure channel created in stage one. This protocol is more user-friendly than the previous one, because the users can authenticate themselves using a more familiar method, such as username and password [28].
The main advantages of this method are mutual authentication, allowing the users to authenticate themselves with one of multiple authentication methods, and it protects their identity from eavesdroppers, since the information is exchanged inside a secure channel, which provides security, even though the protocol used to exchange this information may be insecure
(e.g. PAP [16]).
2.6.3 EAP-PEAP
EAP-PEAP works in one or two stages. In the first stage, it is created a secure TLS channel between both parties, Supplicant and AS, to protect a potential second stage. In the second stage, the Supplicant is authenticated by EAP. As in the two previous methods, in the first stage the AS authenticates itself with an asymmetric key pair and a X.509 certificate from their public key. Once again, this authentication prevents the Supplicant from being deceived by a malicious individual performing a MiTM attack. The second stage is only executed if during the first stage the AS was not able to authenticate the supplicant. This way, if during the first stage the Supplicant authenticates as in EAP-TLS, the second stage will not be executed [28].
The main advantages of this method are mutual authentication as well as the protection of the Supplicant’s identity during stage 2, thus, allowing the Supplicant to authenticate with any authentication protocol in a secure channel. This protocol is more flexible than EAP-TLS and EAP-TTLS. However, the problems presented in EAP-TLS will still exist if the authentication is done in the first stage [28].
2.6.4 EAP-PSK
EAP-PSK in an authentication protocol in which there is only one authentication key pre-shared (PSK) with every user on the network; this key is pre-shared between the Supplicants and the AS.
This protocol is based on the Authenticated Key Exchange protocol [4]. The Supplicant and the AS trade random values, one random value from the Supplicant and one from the AS, and prove their authenticity by adding one message authentication code, which is calculated with an Authentication Key (AK) that is derived from the PSK, to the messages. If the proof is valid, both the client and the AS calculate the MSK and the EMSK from the random value generated by the Supplicant and from another key derived from the PSK called Key Derivation Key (KDK).
This protocol does not provide Perfect Forward Secrecy (PFS). A key possesses PFS if its security does not depend on the obscurity of the secrets of long duration used in its negotiation, by other words, if a session key is negotiated using one or more KEK, and if the knowledge of those KEK is sufficient for the discovery of the session key, then the security of the key does not depend only from its secrecy but also from the secrecy of the KEK [28]. It also allows dictionary attacks to the PSK. The discovery of this key is enough for an attacker to decrypt past interactions from the same Supplicant, as long as they were derived from the same PSK. It also does not provide the protection of the users’ identity.
2.6.5 EAP-SIM, EAP-AKA and EAP-AKA’
EAP-SIM is an adaptation of the authentication used in the Global System for Mobile (GSM). The Supplicant uses one smart card with a Subscriber Identification Module (SIM) to generate
keys as answers to challenges, either created by the AS and sent by the Authenticator or created by itself [28].
EAP-SIM’s main advantages are mutual authentication, the Supplicant authenticates with SIM from the GSM, it also optionally supports privacy protection of the users’ identity. The main disadvantages are network impersonation if some GSM triplets are known and some vulnerabilities regarding some A3/A8 algorithms that have been compromised [10]. A3 is an algorithm used for authentication, while A8 is used for the generation of a cipher key [8].
EAP-AKA is similar to EAP-SIM but uses the Universal Subscriber Identity Module (USIM) used in the Universal Mobile Telecommunications Service (UMTS). The key, Kc, obtained through one GSM authentication, is used to encrypt directly the exchanged frames. Two Kc keys are used in order to generate a Master Key (MK), this MK is then used, with a pseudo random sequence generation function, in order to generate the MSK [28].
EAP-AKA’, also known as EAP-AKA prime, is a small revision of the EAP-AKA protocol, the difference is a new key derivation function, that binds the keys derived within the method to the name of the access network, and is used for non-3rd Generation Partnership Project (3GPP) access to a 3GPP core network, like Wi-Fi.
EAP-AKA’s main advantages are mutual authentication, optional privacy protection of the users’ identity, supplicant authentication with USIM and a secure PPP authentication model. The disadvantage is that the RADIUS AS needs access to Home Location Register (HLR). HLR is a database that contains various information about all of the mobile subscribers of a mobile network such as the mobile numbers, services, whether the numbers have been ported to another network and similar information2.
EAP-AKA and EAP-AKA prime’s main advantages and disadvantages are essential the same, however, EAP-AKA prime is a bit more secure since it uses SHA-2 instead of SHA-1, which ensures that the security of the protocol is, at least, as good as EAP-AKA, if not better.
2.6.6 EAP-PWD
EAP-PWD is a protocol that addresses the problem of password-based authenticated key exchange, it makes possible for the derivation of an authenticated and cryptographically strong shared secret, from a possibly weak password.
The security of EAP-PWD3 relies on the production of quality secret random numbers by both parties, Supplicant and AS. If this is not obliged, it may result in a compromise of the shared secret from the exchange, allowing for the possibility of a dictionary attack.
There are three message exchanges in the EAP-PWD protocol, an identity exchange, a commit exchange and a confirm exchange. The Supplicant and AS use the identity exchange to discover each others identities and to agree on a ciphersuite to use in the remainder of the exchanges. The AS uses a request identity message to inform the Supplicant of any password preprocessing that may be required. In the commit exchange both parties exchange information to generate a shared key, and to also bind each other to a particular guess of
2
https://www.infobip.com/en/glossary/hlr-home-location-register 3
the password. In the confirm exchange both parties prove the knowledge of the password by generation and verifying verification data.
EAP-PWD’s main advantages are mutual authentication, forward secrecy, which means that compromised passwords will not reveal the shared secret keys from earlier executions of the protocol. It is resilient to active and passive attacks. The disadvantages are that the ciphersuite offer made by the server is not protected from tampering by an active attacker, none of the messages sent in this protocol are encrypted, some messages are not integrity protected and the identity exchange is not protected. An attacker will see the AS identity in the identity request message and see the Supplicant’s identity in the following response.
2.6.7 Comparison and viability of different EAP methods
Considering the nature of the problem that this thesis attempts to solve, some of the methods previously described can not be considered for a possible solution. There are a lot more EAP methods, but we focused on those that are used more often and that exist both in Android, iOS and laptops.
As we want to develop a solution that is convenient as well as provide a good level of security and still offer some privacy to its users, we present below a summary table that not only reflects the advantages and disadvantages of each method, but also provides reasons as to why some methods can not be considered.
EAP method Advantages Disadvantages EAP-TLS Mutual authentication with
certificates; Blocks users through certificate revocation; Allows for the protection of the client’s identity;
Certificate configuration is re-quired;
EAL-TTLS Mutual authentication; Al-lows the client to authenticate themself with any authentica-tion method; Client’s identity is protected;
EAP-PEAP Mutual authentication; Client’s identity protected in stage 2; Allows the client to authenticate themself with any authentication in a secure channel;
EAP-PSK Easy to implement; Does not provide PFS; Al-lows dictionary attacks; Key is shared between all users; Lack of identity protection;
EAP-SIM Mutual authentication; Client authenticates with SIM from GSM; Allows client’s identity to be protected;
Network impersonation if some GSM triplets are known; Some A3/A8 algorithms have vulnerabilities;
EAP-AKA Mutual authentication; Client authenticates with USIM; Secure PPP authentication model; Allows client’s identity to be protected;
RADIUS needs access to HLR;
EAP-AKA’ Mutual authentication; Client authenticates with USIM; Secure PPP authentication model; Allows for non-3GPP access to a 3GPP core net-work; Allows client’s identity to be protected;
RADIUS needs access to HLR;
EAP-PWD Mutual authentication; For-ward secrecy; Resistant to ac-tive and passive attacks;
The ciphersuite offer by the server is not protected from tampering by an active at-tacker; None of the messages sent in this protocol are en-crypted; Does not protect the identity of Supplicant nor the AS;
Table 2.1: EAP methods comparison.
the ability to identify its users since all of the users are authenticated with the same PSK. It also does not provide PFS, which is fundamental, because it does not allow the decryption of recorded past sessions if long-term secret keys or passwords are compromised. It allows dictionary attacks to the PSK. With the discovery of this key, one can decrypt and analyze all past interactions from a client, as long as they were derived from the same PSK because there is no PFS.
EAP-SIM implies the need for the device to have a SIM card, which also does not make for a convenient solution, as it must be able to authenticate all kinds of devices. This is the same reason as to why EAP-AKA and EAP-AKA’ must not be considered as well, the devices would be required to have USIM cards.
EAP-PWD does not provide identity protection of its users and this reason alone is enough to not consider it.
The remaining methods, EAP-TLS, EAP-TTLS and EAP-PEAP provide security, have the ability to protect the users’ identity and to identify them if necessary. All of them can be considered for the solution.
2.7 Captive Portals
In order to understand what a captive portal is we must also understand what hotspots are: devices usually placed in public locations in order to provide Internet access by Internet Service Providers (ISP). Current 802.11 based hotpots use one of two security solutions; either no security at all, so that any user can connect directly to the Internet, or using a captive portal [6]. A captive portal usually presents itself as a welcome or login page, it is a router or a gateway host that does not allow traffic to pass before the user performs the proper authentication [12]. This is also called a walled garden state, where the user has access to part of the network in order to authenticate themself but, while they do not, there is nothing they can do regarding online activity, since all traffic requested by the user will be either blocked or redirected to the captive portal’s web page.
Captive portals are usually presented in one of three ways, even though they may be configured in multiple ways. One way is by displaying some sort of terms and conditions web page for the user to comply with, in order to be granted full access to the network. Another way is to display a login page for the user to authenticate in order to be granted access. The last way is to display a web page that provides a payment plan for the user to buy in order to have access to the network during a limited period of time.
ChilliSpot4is an open source captive portal used to authenticate users of a wireless network. It supports web-based login, which is the de facto standard for public hotspots. AAA is handled by a RADIUS server. Some alternatives to ChilliSpot are Sputnik5 and WiFiDog6.
Usually, a captive portal operates in the following stages [12]:
4 http://www.chillispot.org/ 5 http://www.sputnik.com/ 6 http://dev.wifidog.org/
1. Let the supplicant receive an IP address from the Dynamic Host Configuration Protocol (DHCP) server via Wi-Fi link;
2. Block all traffic, except for the captive portal server;
3. Redirect any web traffic from the supplicant to the captive portal;
4. Return a web page displaying terms of use, billing information or a login screen; 5. Once the user has accepted the terms, logged in or bought a subscription, grant him
full network access.
2.7.1 Implementations
The captive portals’ paradigm implies the existence of a system capable of redirecting all the supplicant’s traffic to the captive portal. This system can either reside inside the AP itself or on a dedicated server. The captive portal can also communicate with a server (e.g. RADIUS) to store user and session information. There are numerous ways of implementing this system, using HyperText Transfer Protocol (HTTP) redirects, The Internet Control Message Protocol (ICMP) redirects or DNS redirects.
In this scenario the HTTP redirect is a response sent by the AP to a HTTP GET request from the supplicant. If the supplicant is not authenticated in the network, every request the supplicant performs in order to access a web page will be answered with the captive portal’s Uniform Resource Locator (URL) until the authentication is done. RFC 6585 [19] provides a new HTTP status code (511) created to avoid confusions with other status codes that were being used to redirect HTTP clients to captive portals.
ICMP redirects are messages sent to the hosts that notify them about an alternative route and also updates their routing information in order to follow the previously announced route. This also allows for the supplicant’s traffic to be redirected to the captive portal while they are not authenticated.
DNS redirect, defined in RFC 7710 [15], states that when a supplicant requests a web page, the captive portal’s system will ensure that either only the DNS server provided by DHCP can be queried by unauthenticated supplicants, or all the DNS requests will be forwarded to a determined DNS server. This DNS server will always return the IP address of the captive portal’s web page as a result for any DNS lookup.
2.7.2 Security Limitations
With the existence of multiple ways for implementing a captive portal, there are also different limitations that concern each one’s security. Some Portals can have confidentiality issues by not encrypting or protecting usernames and passwords, while others only protect this sensitive information during authentication phases and after that fail to use an appropriate protocol to protect the remainder of the communication and all the information is transmitted in the clear. Often the lack of protection of the users’ data is done without their knowledge, as many people have no idea if their data are being protected nor what the possible consequences are. The maintenance of the authenticated session is also a major problem, since after the authentication is done, some captive portal implementations allow the traffic to pass through the gateway with an IP and MAC address based authorization system. This can be exploited
by a malicious user because once an IP and MAC address are authenticated and discovered by an attacker, they can spoof those addresses in order to have network access.
2.8 Wi-Fi Business models
Some companies, such as MEO and NOS, provide hotspots in domestic AP’s. The hotspots provided by these ISPs have authentication and a user is able to access the network with a username and password as long as they are clients of that service provider. This can be done with the usage of an application instead of the standard captive portal web page. Another type of business model is simply creating a system where the user connects to the network and it is presented with a billing page in order to have access to the network in a limited period of time.
One business model that is used with the purpose of getting more users into an establish-ment, such as restaurants, is to deploy multiple hotspots scattered across a city. When a user connects to it, they are presented with the restaurants web page, where usually it is exposed the restaurant’s menu for advertising purposes. The client is then able to access the network with their mobile phone number where they will receive the code that grants him access to the network.
FON7 and Boingo8 are examples of companies that have multiple hotspots scattered across the world and provide their users with coverage in various countries. They usually allow other companies to partner with them. For instance, NOS has an agreement with FON and basically FON provides the hotspots and NOS’s clients are able to connect to the network using NOS’s credentials in a FON’s hotspot9.
It is important to understand that a cellular network and a Wi-Fi network both require authentication but for very different reasons. A cellular network is provided and maintained by an operator which takes care of all the network related issues, such as keeping up with the supply and demand of broadband network access, providing connectivity in different countries and above all having a good quality of service. The main purpose for the existence of authentication in a mobile network is billing, because operators need to know how much traffic a given person is using, in order to charge them appropriately. A Wi-Fi system is usually not really managed by anyone in the sense of having someone constantly checking network’s traffic, analyzing it and understanding possible weak aspects of the network. It is commonly a hotspot provided by someone that is a client of a ISP network and wishes to provide Internet access to other people. Of course we can not always tell who the administrator of an hotspot is and what their intentions might be. Some people provide free Wi-Fi access because they have a venue and they feel like their clients would value in a significant way that perk or even to bring more people into the venue; some people provide the same perk but their Wi-Fi network is protected by a password that must be asked for or given when something is bought and some people sell their Wi-Fi to others. The majority of these business models do not
7https://fon.com/ 8
http://www.boingo.com/
provide strong authentication mechanisms and their hotspots can be turned into rogue access points by malicious users which can later take advantage of it for the wrong reasons.
Taking into account the problem presented in this thesis none of the previous systems is a possible solution for it. Having no authentication whatsoever and just a terms and conditions web page is not viable since anyone can perform a MiTM and see the network traffic of all its users. The billing plan is not acceptable because the goal of this solution is to have a free of charge system. The system regarding the clients of a determined system provider, even though it has authentication, would require everyone to have the same ISP or a system where clients from one ISP could be authenticated by another ISP which is something that does not seem likely in a near future. One possible solution would be to use a mobile phone number to receive a code that would be used to authenticate the user into a network. This would require everyone that wishes to connect to the network to have a mobile phone within reach, in order to authenticate in devices such as laptops, tablets and smartphones.
2.9 Hotspot 2.0
Hot Spot 2.0 (HS 2.0), also called Wi-Fi Certified Passpoint, is a new standard for public access Wi-Fi that enables seamless roaming among Wi-Fi networks, and between Wi-Fi and cellular networks. This standard is based on 802.11u and eases cellular-like roaming, increased bandwidth, and service on demand for wireless-equipped devices in general. With this, whenever a subscriber’s 802.11u-capable device is in range of at least one Wi-Fi network, the device automatically selects a network and connects to it. Network discovery, registration, provisioning, and access processes are automated, so that the user does not have to go through them manually in order to connect and stay connected to the network10.
2.9.1 Architectures
HS 2.011 has three architectures for the deployment of hotspots, being them when using cellular network credentials, when using non-cellular network credentials or when the device does not possess a credential that can be used to access the Wi-Fi network.
10https://whatis.techtarget.com/definition/Hot-Spot-20-HS-20 11
Figure 2.4: HS 2.0 architecture: SIM device.
The network discovery and authentication process for the deployment of HS 2.0 using cellular network credentials for authentication shown in Figure 2.4 includes the following steps:
1. The user’s device detects HS 2.0 indication in AP beacon frame.
2. The user’s device queries Access Network Query Protocol (ANQP) server for 3GPP cellular network information and roaming consortium Organizational Identifiers (OI). 3. The user’s device matches the information and OI received against its list of credentials
and preferred networks.
4. The user’s device automatically associates with Passpoint AP.
5. The user’s device performs IEEE 802.1X authentication to the home RADIUS AS using EAP-SIM, EAP-AKA or EAP-AKA’.
6. Home AS communicates with HLR using the Mobile Application Part (MAP). MAP is a protocol that allow GSM and General Packet Radio Services (GPRS) networks to communicate with each other in order to provide services to users.
Figure 2.5: HS 2.0 architecture: non-SIM device.
The network discovery and authentication process for the deployment of HS 2.0 using non-cellular network credentials for authentication shown in Figure 2.5 includes the following steps:
1. The user’s device detects HS 2.0 indication in AP beacon frame.
2. The user’s device queries ANQP server for Network Access Identifier (NAI) realms and roaming consortium OI.
3. The user’s device matches the realms and OI received against its list of credentials and preferred networks.
4. The user’s device automatically associates with Passpoint AP.
5. The user’s device performs IEEE 802.1X authentication to the home RADIUS AS using EAP-TLS or EAP-TTLS with MS-CHAPv2.
Figure 2.6: Internet Service Provider with Subscription Servers.
The network discovery and credential/policy provisioning when network credentials are needed by the mobile device shown in Figure 2.6 includes the following steps:
1. The user’s device detects HS 2.0 indication in AP beacon frame.
2. The user’s device queries ANQP server for NAI realms and roaming consortium OI. 3. The user’s device attempts to match the realms and OI received against its list of
credentials and preferred networks, however there are no realms or OI which match any of the devices credentials.
4. The user’s device queries ANQP server for network authentication type to determine if Online Sing Up (OSU) is supported; if so, the device queries ANQP server for OSU providers list.
5. The user’s device parses the OSU providers list and displays the friendly name or icon of the available ISP.
6. Upon the user selecting a ISP, the mobile device associates to the OSU Service Set Identifier (SSID) and connects to that ISP’s OSU server. Then the user signs up for a subscription and the mobile device is provisioned with the PerProviderSubscription Management Object (PPS MO). If the ISP provisions a username and password creden-tial, it’s contained within the PPS MO. If the ISP provisions a client certificate, the ISP’s Certification Authority (CA) creates the certificate and provisions it to the device; in this case, the PPS MO contains a reference to the client certificate. The PPS MO
also contains the device setting for use with the provisioned credential and optional network selection policy which governs how the credential can be used.
7. The user’s device automatically disassociates with OSU SSID and associates to the Passpoint SSID.
This way, HS 2.0 is a very good solution, as it allows seamless network access and roaming with different authentication protocols given the different type of devices. In SIM-based devices, the device’s credentials are verified against the home operator’s HLR; in non-SIM based devices, the device’s credentials are verified against the home operator’s RADIUS server. It is also possible to promptly provide credentials to a user allowing him to subscribe and connect to the network from a ISP, when the network credentials are needed by the mobile device. This subscription does not necessarily mean that the user must pay for the network. In a free system like the one attempted to be developed the subscription would simply be a network registration allowing for the usage of the network.
2.9.2 Improving Wi-Fi hotspots trustworthiness
In [22] it was shown that Hotspot 2.0 can be compromised and, therefore, controlled by an untrustworthy entity to carry out different types of attacks if the users’ data is not protected. Which creates the need for having another layer of trust, besides the authentication layer, to decide which hotspots to choose among the ones available to people. In [22] it are also described some of the problems with legacy Wi-Fi hotspots, such as legitimate hotspot spoofing, session hijacking, eavesdropping and unencrypted Wi-Fi. Hotspot 2.0 network discovery is based on ANQP, which is a query-response protocol that defines services provided by an AP. ANQP communicates metadata useful for AP selection. Their proposal can be seamlessly implemented in hotspots compatible with Hotspot 2.0 by simply using the extra remaining metadata fields available, in order to exchange signed computational trust information. Their solution puts forward a plan to extend computational trust by calculating three types of trust:
1. Trust values in Wi-Fi service providers, which would help selecting the most trustworthy service providers and encourage overall better Wi-Fi service quality, because Wi-Fi providers would try to remain trustworthy in order to keep more users;
2. Trust values in Wi-Fi service providers’ hotspots with the usage of location coordinates in addition to the certified service provider identity;
3. Trust values in user clients, who may be identified with EAP-SIM and trust values may concern their trustworthiness in rating service providers or not carrying out illegal activities.
Figure 2.7: Features according to [22].
Figure 2.7 was obtained from [22] and clearly states the features of Wi-Trust comparing with Hotspot 2.0 and legacy Wi-Fi.
2.10 Eduroam
Eduroam [26] is an international free roaming service for the research and higher education community. It provides to members of different research and higher education an easy and secure network access when visiting an institution that it is not their own. The authentication is always performed by their home institution. However, the authorization to access the network is handled by the visited institution. Eduroam uses the IEEE 802.1X standard as authentication and a hierarchical RADIUS system.
Regarding trust management [26] within RADIUS hierarchy, it is implicitly build into the AAA infrastructure, since every RADIUS server must know all of its peers in advance. This trust is installed via shared RADIUS secrets configured for each pair of servers, and this shared secret is then used by RADIUS to authenticate a peer. In Eduroam’s architecture, a peer is always one level above the other. An institutional level RADIUS server (e.g Aveiro’s University server) communicates only with a federation server (e.g. Portugal’s federation server), which can then communicate with the international confederation server above or one institutional below. In order to introduce a new roaming realm, the administrator of the higher level server must negotiate the shared secret with the administrator of the newly created realm.
Eduroam is a network that has many resemblances to a possible solution for the problem that this thesis attempts to solve. It is a secure system that allows authentication by any
