Enterprise Wi-Fi: improving user device security

classic Classic list List threaded Threaded
4 messages Options
| Threaded
Open this post in threaded view
|

Enterprise Wi-Fi: improving user device security

Stefan Winter-4
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



-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

signature.asc (849 bytes) Download Attachment
| Threaded
Open this post in threaded view
|

Re: Enterprise Wi-Fi: improving user device security

Alan DeKok-2
On Dec 31, 2019, at 9:19 AM, Stefan Winter <[hidden email]> 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 "[hidden email]" 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.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Enterprise Wi-Fi: improving user device security

Stefan Winter-4
Hello,


>> 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?

While the public availability of the final spec makes it rather apparent
that the *ability* to support this is as from now - read the spec and
write the code - , the timing for making this *required* is not public yet.


> * 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 "[hidden email]" to the server which has the certificate for "example.com".


I'll be buying popcorn and watch things evolve. Basically, this is an
entirely new type of certificate, i.e. a new "business unit". Here, CAs
don't sell webserver certs, they sell Wi-Fi EAP server certs. They are
also free of CA/B forum requirements here bevause it is not a browser
thing. I.e. validity beyond the two-year limit is possible here. Also,
since concepts like LetsEncrypt don't (currently) work well over the EAP
channel, they can try to make actual money with this.

It remains to be seen if and how quickly commercial CAs pick this up.
Until then, having one's own private CA for EAP purposes has just earned
a unique selling point not currently available with commercial CAs.


There is actually a big operational difference between the policy values
and the NAIRealm value: TOD Policies are fixed values. They don't need
vetting on the CA side. You express your wish to have this policy in
effect, they deliver a certificate which puts this policy into effect.

OTOH, with NAIRealm, you claim "I run a legitimate EAP server for the
NAI realm example.com". How does the CA vet this claim of yours? The EAP
channel is not publicly observable unless you are connecting to a
network secured with it. They'd need to set up an AP, connect to your
Wi-Fi infrastructure, attempt to authenticate, and then see where they
end up. An additional challenge-response system is then needed to bind
the person applying for the cert in their web interface to the
certificate/information in the EAP channel. All of these steps don't
exist today and are somewhat hard to solve. Not impossible, just hard.

The policies come without these additional complexities, so are a more
low-hanging fruit. Not that I don't want to reach the high-hanging ones,
too, but I'm happy that we now have ripe low-hanging fruit to start with.


>> 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.

The work flow is pretty much identical to SSH server keys: If you've
never connected to a server, and haven't bothered to configure the
expected server identity upfront, there is no way to know you are
connecting to the right guy. This one first time, you take a leap of
faith and accept whatever comes. From that moment on, in the future you
either get the same key (good) or you observe that the key changed
(refuse to connect; the only way of overriding is to delete your (SSH /
Wi-Fi) configuration and restart from scratch.


Just as with SSH, the expectation is that you establish that first
connection in a well-defined setting (in the case of Wi-Fi: such as at
your helpdesk, inside the office building etc.) so that you learn the
correct ID. A rogue attacker later on the street that tries to grab your
password by having replicated your office SSID will be automatically
blocked from doing so, because your supplicant has previously learned
that TOD-TOFU is in place, and has previously learned the expected
certificate, and observes a different incoming certificate.


>> 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?

As discussed above: it's a leap of faith during the very first
connection to the network. No CA plays a part in this process: it's not
preconfigured (otherwise the TOFU step wouldn't be needed anyway), and
the EAP conversation typically only sends server cert plus possibly
intermediates. If no root CA is being sent, it can't be marked as
trusted. So with TOFU, the exact server certificate is being trusted on
first use (interactively by the user); from then on, the server cert is
stored in the local supplicant config and is the reference for all
subsequent connections to the same network.


>> 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.

I wish. X.509v3 does not have a way to do this. Between CAs,
cross-certification and re-using a private key to generate a different
cert are tricks being used, but they have their own failure modes. There
does not seem to be any practical way today to handle trust root
rollover :-(


Greetings,


Stefan Winter


>> 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.
>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
--
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



-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

signature.asc (849 bytes) Download Attachment
| Threaded
Open this post in threaded view
|

Re: Enterprise Wi-Fi: improving user device security

Alan DeKok-2
On Jan 6, 2020, at 2:51 AM, Stefan Winter <[hidden email]> wrote:
> There is actually a big operational difference between the policy values
> and the NAIRealm value: TOD Policies are fixed values. They don't need
> vetting on the CA side. You express your wish to have this policy in
> effect, they deliver a certificate which puts this policy into effect.

  See discussion on the EMU list.  There was great shock and horror about putting *any* policies into certificates.

> OTOH, with NAIRealm, you claim "I run a legitimate EAP server for the
> NAI realm example.com". How does the CA vet this claim of yours?

  The same way it validates contact names, telephone numbers, or even domain names.

  I've had CAs verify that I control a domain.  I can't recall them ever verifying the domains listed in the CSR.  How would they do that?  When a certificate is issued, there's no requirement that "www.example.com" even exist in DNS.  The certificate is *allowed* to be used for "www.example.com".  But that permission doesn't turn into a *requirement* on anyone or anything.

> The EAP
> channel is not publicly observable unless you are connecting to a
> network secured with it. They'd need to set up an AP, connect to your
> Wi-Fi infrastructure, attempt to authenticate, and then see where they
> end up.

  If a certificate lists 5 host names, the registrar verifies that the CSR owns the domain (e.g. example.com).  There is very little verification of the individual host names.

>>  Also, why trust the server certificate at all?  What role does the root CA (if any) play in this process?
>
> As discussed above: it's a leap of faith during the very first
> connection to the network. No CA plays a part in this process: it's not
> preconfigured (otherwise the TOFU step wouldn't be needed anyway), and
> the EAP conversation typically only sends server cert plus possibly
> intermediates. If no root CA is being sent, it can't be marked as
> trusted. So with TOFU, the exact server certificate is being trusted on
> first use (interactively by the user); from then on, the server cert is
> stored in the local supplicant config and is the reference for all
> subsequent connections to the same network.

  That's a little weird.  I'll have to think about that some more.

  The supplicant trusts a certificate it knows nothing about, which isn't vouched for by anyone?

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html