# Understanding Server Authentication in WPA3 Enterprise
## 2 Background: Server Authentication in WPA2 Enterprise
Similarly, consider a supplicant that does not satisfy either requirement (i) or (ii) --i.e., a supplicant that indeed checks the validity of received certificates but that does not know the name of the AS. In this case, the supplicant may start interact with ET as above, because the ET may legitimately own a certificate issued by a certification authority considered trusted by the supplement. Even in this case, phase 2 will fail but the ET may have collected credential material. In summary, applicants which are not configured to use the correct Authentication Server name for a given enterprise network and to verify that the claimed identity of an Authentication Server indeed matches that name could be tricked into executing the authentication protocol with any ET claiming to have the SSID of that network [8]. The impact of attacks of this kind depends on the specific supplicant and may range from the evil twin acting as a man-in-the-middle to the evil twin obtaining either the user password or a hash of the user password [10]. In practice, applicants that are not configured correctly are very common. Users often select the SSID of the enterprise network, insert their credentials, and then play with the network configuration until connecting, usually by selecting \"skip certificate validation\" or \"accept any certificate\". WPA2 Enterprise does not specify any means for _preventing_ this behavior. Organizations may adopt security policies that forbid insecure configurations or that mandate the usage on the enterprise network only by applicants that have been approved (and hopefully correctly configured) by the IT staff. However, WPA2 Enterprise does not provide any technical means for detecting connection attempts from supplicants that are not compliant with the security policy. Furthermore, organizations often suggest insecure configuration practices--i.e., of the form \"skip certificate validation\" or \"accept any certificate\" [11]--which means that either network administrators are not aware of the corresponding risks or choose to ignore those risks, perhaps because the need to support users in configuring their devices would take away precious (and usually scarce) resources that may be devoted to other activities relevant to the overall security of the organization. The net result is that WPA2 Enterprise is very often deployed by violating crucial security-relevant requirements, which creates significant security risks for users and for the organization as a whole. A detailed and comprehensive survey of the defensive mechanisms that have been proposed for mitigating ET-based attacks to WPA2 Enterprise environments can be found in [7]. Most of the proposed defenses can mitigate attack scenarios where the ET either coexists with a legitimate access point or replaces one of those--in other words, those mechanisms are suitable for defending against attacks that occur at locations _within_ the enterprise. According to this survey and to our knowledge, only three defense mechanisms capable of mitigating remote clone attacks--i.e., the attacks that may occur potentially anywhere and that are considered in the present work--have been proposed in the literature. Two of these mechanisms required significant changes to the authentication protocols used in WPA2 Enterprise and thus were not compatible with the existing infrastructure already deployed worldwide [19; 20]. A third proposal for defending against remote clone attacks that did not require any change to WPA2 protocols can be found in [10]. The cited work was based on a significant change in the interface presented by applicants to users; essentially, applicants should distinguish between WPA2 Personal networks (those where a single password is shared by all applicants and that are typically used in home environments) and WPA2 Enterprise networks, and users should identify networks in the latter category not only by their name (i.e., SSID) but also by the name of their Authentication Server.