# Understanding Server Authentication in WPA3 Enterprise
## 2 Background: Server Authentication in WPA2 Enterprise  
In this section, we provide the necessary background on WPA2 Enterprise and focus on the configurations most commonly used. A Wi-Fi device (a _supplicant_) may connect to an enterprise network only after executing an authentication protocol with the _Authentication Server_ (AS) for that network. For the purpose of our discussion, this protocol may be summarized as follows (we refer the reader to the abundant literature on the subject for full details--e.g., [9]):  
* Phase 1: the supplicant verifies the identity of the AS for the network it is attempting to connect to. * Phase 2: 1. The supplicant sends user credential material to the AS. * The AS demonstrates knowledge of the user credentials to the supplicant. In Phase 1, the AS provides a certificate binding its name to a public key and the two parties establish a cryptographically secure TLS tunnel based on that public key (much like what happens at a higher level of the network software stack, when a browser connects to a web server with the HTTPS protocol). Phase 2 is executed within the TLS tunnel created at step 1. Note that the certificate does _not_ bind a public key to the name of the wireless network (i.e., to its SSID), only to the name of the AS. For example, in our university, the name of the network is eduroam, while the name of the AS is raggio.units.it. The correct execution of step 1 thus requires certain configuration information that must be stored on the supplicant before connecting--i.e., a _network_profile._ The network profile must include the association between the SSID of the network and the name of AS, where the AS name is provided in the form of a certificate. WPA2 Enterprise left crucial security details regarding AS authentication unspecified. In particular, it was not specified how to make sure that: (i) the supplicant is indeed equipped with a network profile, (ii) the network profile is accurate, and (iii) the supplicant indeed uses the network profile as specified. WPA2 Enterprise merely assumed--i.e., took for granted--that these requirements are met by every supplicant at every organization. These details have far-reaching implications for the security of the network, its users, and the organization as a whole. To clarify, consider a fraudulent wi-fi access point broadcasting the name of an enterprise network--i.e., an evil twin (ET) [3, 4, 5, 6, 7]. ET-based attacks can be classified as proposed in [7]: _replacement_, where a legitimate access point is switched off and replaced by the ET at the same location; _coexistence_, where the ET coexists with a legitimate access point at the same location; _remote clone_, where the ET is at a location where there is no legitimate access point. In this work, we are mainly interested in remote clone scenarios, in particular at locations that have nothing to do with the enterprise. We consider attacks aimed at eliciting credential material from the supplicant for later offline credential guessing [16, 17, 18]. The typical scenario for these attacks consists of users which carry supplicants configured for connecting to the wireless enterprise network automatically (e.g., smartphones) and that move outside of the enterprise. Attacks of this kind require a supplicant that remains in close proximity with an ET for a very short time and may occur potentially anywhere, often without any involvement of the user at the supplicant. Consider a supplicant that happens to pass nearby an ET and whose configuration does not satisfy requirement (iii) above--e.g., a supplicant configured with such commonly available options as \"skip certificate validation\" or \"accept any certificate\". The supplicant will start interacting with ET, will complete Phase 1, and will begin the execution of Phase 2, often without any user action. Phase 2 will fail because the ET will not be able to prove knowledge of the user credentials, but the supplicant might disconnect when it is too late--i.e., after having already sent credential material to the ET.