Enterprise Wi-Fi: improving user device security

[Stefan Winter]

Hello,


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


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.


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.


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.


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.


b) is actually extremely similar to SSH and its reaction to your first
connection to a new host. That first time asks you a question of trust,
and any subsequent change of server-side identity will raise all alarm
bells.


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.

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.


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.


Greetings,


Stefan


-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20191231/3423f013/attachment.sig>