A Sketch of Trusted WiFi - Open, Authenticated, Encrypted

With the rise of Letsencrypt, the costs of TLS certificates has become essentially nothing. This opens up new possibilities for authenticated encryption for things other than https by leveraging the existing Internet Publick Key Infrastructure (PKI) and Domain Name System (DNS). Here I'll explain how we might use Letsencrypt to make WiFi safer.

When a WiFi network is setup for public use, there is trade off made between offering an unencrypted open access network vs an encrypted but password protected network. And neither of these options offers the ability for the client to authenticate that they have connected to the correct access point (AP).

We can leverage the Internet PKI to provide an open, authenticated, encrypted connection to the WiFi AP, just like we leverage PKI to get an open, authenticated, encrypted connection to https://wikipedia.com/

To clarify, we want 3 properties. Openness, meaning the client does not need to authenticate itself (e.g. it should not need to enter a password, or provide a client certificate). Authentication, meaning the AP's identity is verified. Encryption, meaning the connection between the client and AP is encrypted.

Protocol

The following protocol meets these requirements:

Alice, the WiFi provider, owns the domain name "alice.net". She creates a subdomain "wifi.alice.net" and obtains a signed TLS certificate from some certificate authority (CA) in the Internet PKI (Any CA can be used, not just Letsencrypt).

The AP then needs three things to be configured:

• the AP should have the SSID "wifi.alice.net".
• the AP should have the signed certificate for "wifi.alice.net", along with the corresponding private key.
• the AP should use EAP-TLS with no client certificate (called EAP-UNAUTH-TLS?)

Alice turns on the WiFi.

Bob connects to the WiFi network named "wifi.alice.net", this establishes a connection with EAP-TLS. Additionally he checks that the X.509 certificate he received is for the domain "wifi.alice.net", and that it has a valid signature from a trusted CA.
QED

How'd that work?

We get openness by ensuring that the variant of the EAP-TLS protocol does not require a client certificate.

We get encryption with EAP-TLS.

The authentications is a little more subtle. We get authentication by checking that the certificate the AP serves us is the same as the SSID. This passes the work of "Authentication" to the CA who issues the certificate. Implicit here is that Bob, not his WiFi client, chooses "wifi.alice.net" because he knows that Alice owns that domain. Maybe he knows this because he is at Alice's house, or he's at Alice's internet cafe, or Alice.com is a know ISP for public WiFi etc.

Moving Forward

The pieces to implement this mostly exist. Only minor modifications are required to AP's and Clients. The only novel idea is comparing the SSID with the domain of the certificate to get authentication.

To get a proof of concept working, there are a few things to consider:

• EAP-TLS with no client certificate is not well supported. There is interest and work in changing this. PoC's exist.
• I don't know if you can simply "install" a certificate originally intended for TLS in place of a certificate intended for WiFi. They are both X.509 certificates.
• Clients (wpa_supplicant) would need to be modified to compare the SSID with the domain in the certificate.

I'm working on it.