Enterprise Wi-Fi: improving user device security

[Alan DeKok]

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?

  Alan DeKok.