On Jan 6, 2020, at 2:51 AM, Stefan Winter <stefan.winter@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.