# Understanding Server Authentication in WPA3 Enterprise
## 5 Discussion  
Much of the improved security of WPA3 Enterprise over WPA2 is due to the impossibility of configuring a supplicant with \"skip certificate validation\" or \"accept any certificate\". In WPA2 Enterprise, the possession of a valid certificate may be sufficient to induce an incorrectly configured supplicant to enter Phase 2 automatically and without any user involvement, while this will no longer be possible with WPA3 Enterprise. The opportunities for tricking a supplicant into leaking  
Figure 3: Supplicant evolution in a network with a TOD-STRICT policy. credential material to a fraudulent AS are thus greatly reduced by this relatively simple constraint on the allowed configurations. It is important to point out that, actually, the WPA3 specification does not forbid those insecure configuration options clearly and explicitly. The specification requires that the identity of the server be verified in Phase 1 and that, if the verification fails, there must be a means for the user to possibly accept trust in the received certificate. On the other hand, the specification does not impose any temporal or causal relationships between a failed server identity verification and the decision of the user. In other words, a supplicant with a configuration option \"accept any certificate\" could collect the user intent once and for all, which would satisfy the literal meaning of the specification. The overall spirit of the specification, however, is such that the user intent should be collected explicitly whenever the server identity verification fails. In this work, we assume that the certification procedure for WPA3 supplicants, not publicly available at the time of this writing, will indeed guarantee that this is the case. Otherwise, much of the security improvements provided by WPA3 Enterprise could vanish. WPA3 Enterprise provides several significantly different options and leaves important security-related decisions to network administrators (e.g., which TOD policy to apply, if any) and to users (e.g., whether to accept a certificate from the network and which ones). Leaving important security-sensitive decisions to people could lead, in practice, to decisions that are either short-sighted or not sufficiently informed, which may frequently result in a trade-off that is excessively biased toward lower costs, better functionality, and lower security. Indeed, it is fair to claim that the vast majority of security incidents today involve erroneous security-related choices made by users. A crucial issue in this respect is that applicants may still be allowed to connect without installing a network profile from a trusted out-of-band channel, and that in these cases it is up to the user to decide whether the information coming from the network is to be trusted. This is the root of the potential problems in server authentication. While WPA3 Enterprise has greatly reduced the attack opportunities in this respect, the root of the problem remains. The WPA3 Enterprise specification includes a set of recommended warning messages to be presented to users. These messages are clear and informative, at least from the point of view of a technically savvy reader. On the other hand, it is difficult to assess whether they will be adequate for non-technically savvy users and, most importantly, what the behavior of those users when they need to connect will be. We are not aware of any specific study in this area, but studies on the behavior of users when faced with security-related browser warnings could provide interesting insights. In particular, it was recently ascertained that fostering adequate comprehension of warnings related to server identity over TLS is still a significant challenge, despite the many years of design iterations in this area [24]. Consider a user of an organization that has chosen to not enforce any TOD policy. Suppose the supplicant has not installed any network profile, as often occurs today.