Enterprise Wi-Fi: improving user device security

[Alan DeKok]

On Dec 31, 2019, at 9:19 AM, Stefan Winter <stefan.winter at restena.lu> wrote:
> I'm happy to be able to talk about an enhancement for Enterprise Wi-Fi
> made recently in the Wi-Fi Alliance, with "code" for 3.0.x that
> implements this. Please see my pull request at
> https://github.com/FreeRADIUS/freeradius-server/pull/3230

  Thanks.  We've merged the changes into v3 and the "master" branch.

> The problem that this is trying to solve is the following: as a RADIUS
> administrator, you can configure your EAP type for Enterprise Wi-Fi and
> have a server certificate from a specific CA. You tell your users that
> they should send their username/password ONLY to your server, which can
> be validated by looking at the CA chain and server name. You create
> configuration instructions, either in form of a PDF file or by using
> configuration generators such as on https://enterprise-wifi.net.

  The IETF EMU working group has been discussing this for a while.  There has been a depressing lack of consensus on this issue.  It's good to see some progress being made elsewhere.

> And then your users ignore all those instructions and simply type their
> username and password at the prompt, not validating any server identity,
> possibly sending it to a rogue attacker. Academic field studies suggest
> that some 50% of end users are that lazy, leading to an easy attack
> vector to grab credentials from Wi-Fi logins.

  Agreed.

> Bespoke additions by Wi-Fi Alliance allow you as the admin to limit how
> ignorant your users can be when connecting to your network. By including
> a certain policy OID field in your server certificate, you can apply
> validation policy directly at the supplicant level: if the user has not
> properly configured the network with CA/servername/cert fingerprint,
> then you can tell the supplicant to not even attempt the authentication,
> and tell the user to get a proper configuration first. Only if the
> configuration is sufficient to actually identify the server correctly
> will the authentication be attempted.

  Two questions:

* when will supplicant vendors implement this?
* When will certificate authorities be upgraded to sign CSRs with these OIDs?

  Right now, CAs will sign certs only with limited OIDs.  For example, they won't sign CSRs with the id-kp-eapOverLan OID defined in:

https://tools.ietf.org/html/rfc4334

  The CAs also won't sign CSRs with NAIrealm fields as defined in RFC 7585. :(

  It might be too late for this rev of the specs, but it would also be useful for the server certificates to contain an NAIrealm field.  That way supplicants can check that they are sending credentials for "user at example.com" to the server which has the certificate for "example.com".

> This comes in two flavours
> 
> a) "Trust Override Disabled - Strict": There are no exceptions. Have a
> proper configuration, or the supplicant won't try to authenticate you.
> 
> b) "Trust Override Disabled- Trust On First Use": If this is the very
> first time you connect to a network, and the configuration is
> insufficient, take the incoming server certificate, ask user to confirm
> that this is okay, and take that one as the one trusted certificate. If
> the certificate changes at any point in the future, the supplicant will
> not ask the user again; it will unconditionally stop the authentication
> attempt prior to sending username/password.

  A related question is how does the supplicant know to trust the server certificate?  Sure it's signed by a CA, but most supplicants don't trust any CAs by default.

  It would be good to get an exact work flow here.

> Thinking this through, here's a few considerations:
> 
> 1. What happens if your very first connection is directly to an
> attacker? The supplicant will not be told to be picky, will prompt for
> trust, and will send the username/password to the attacker. Since you
> have never ever contacted your proper authentication server, it can't
> tell your supplicant to be picky, so this is a hard problem that can't
> be solved. It can be compared to your first SSH connection attempt, and
> you immediately end up at an impostor, and trust its SSH key.

  Also, why trust the server certificate at all?  What role does the root CA (if any) play in this process?

> 2. With TOD-TOFU, the server certificate is pinned "forever". Now what
> happens if you feel the need to change the server cert? It is possible
> to delete the entire Wi-Fi config - this will also delete the stickiness
> to the old cert. While that's possible, it is best to do everything you
> can to let your server cert live very very long. E.g. have a CA cert
> with 30 years validity, and a server cert *with the same 30 years
> validity*. The TOD-TOFU configuration is then good for a very long time,
> and the only reasons to exchange the cert are an actual key compromise
> or crypto algorithms decaying over time. Using a root CA with the same
> lifetime has the additional plus that those clients who configured the
> (CA,name) tuple, instead of relying on the ad-hoc first use trust, will
> even accept the new server certificate without needing any change.

  There should really be a way for certs to be signed by multiple entities.  i.e. the new cert could be signed by the old one, as a signal that the new cert is (a) known, and (b) can replace the old one.

> The new policies are now part of raddb/certs/xpextensions and default to
> enabling "TOD-TOFU". This should be part of the next 3.0.x release. But
> of course it will only start having an effect once you have created a
> certificate with the respective scripts; and its effect will only be on
> "new" supplicants that have the latest Wi-Fi Alliance WPA3 Security Dec
> 2019 Release certification. There will be a slow phase-in of such
> supplicants over time. This has the advantage that turning it on *today*
> won't all of a sudden break all your deployed base. Which is good.

  Good to hear.  Thanks.

  Alan DeKok.