Enterprise Wi-Fi: improving user device security
aland at deployingradius.com
Mon Jan 6 15:32:38 CET 2020
On Jan 6, 2020, at 2:51 AM, Stefan Winter <stefan.winter at restena.lu> 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?
More information about the Freeradius-Users