Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic

[Ryan Sleevi <[e-mail]>]

I think we’re in more agreement than disagreement here, but I think part of
your analysis missed the mark.

On Sun, Jan 19, 2020 at 10:07 AM Alan DeKok <[e-mail]>
wrote:

>   The question here is *what* root store?  It's easy for browsers to ship
> root stores.  The WWW root stores are well known.
>
>   What root store is already widely known, and trusted for EAP?


There isn’t one today, which is exactly why you have no need to use
anything existing.

You define your certificate profile.
You define your certificate policies - what information they validate and
how they validate.

The root store is the result of defining those two, and then allowing CAs
interested in that set to apply and be evaluated against that. There’s
nothing extant, as we’ve agreed multiple times, because everyone manually
configures.

There’s zero need to use any existing CAs. If the concern is “Our root
store is initially empty”, well then yes, it matches the status quo today:
there is no root store. Rome wasn’t built in a day, and figuring out who
should be in that store takes time. There’s no doubt a dozen CAs that would
happily issue, if they knew what the expected profile and policies were,
and would stand up dedicated roots.

Of course, the CAs are only going to do that if there are users: those who
will buy or rely on those certificates. So you need to convince supplicants
that a zero-touch world is worth it, AND that it can be as secure as manual
configuration.

Supplicant vendors - whether they are open-source or operating system - are
taking on the work to manage and police that root store. To ensure that the
CAs included follow the profiles, policies, and practices. So you have to
convince them that it’s worthwhile for their users.

If this sounds like a lot of work: Yes. It is. Yet organizations like the
WiFi Alliance or the Wireless Power Consortium or the USB-IF have all
managed to do so, to varying degrees of success.

  I think you're operating from a WWW perspective.  That use-case is very
> different from EAP.  In WWW, 99% of the TLS-enabled traffic is from the
> server to the client.  The client doesn't know what the information is, and
> doesn't really care.  Even secret information like passwords sent to a web
> server are generated by / on that web server.  So a client can verify (a)
> the password was created for a proven server using a trusted CA, and next
> time (b) prove it's the same server, so it's OK to send over the password.
>
>   EAP is completely different.  I have *my* password.  It's secret, and I
> made it.  I want to be sure that I give it *only* to the site which is
> authorized.  This means that I don't really care that a root CA is
> trusted.  That root CA might sign certificates for 1000 companies.  I want
> to have my password only to one company; the correct one.  I want the
> client supplicant to *not* hand my password to the other ones.  I have no
> DNS to leverage, either.
>
>   To put it another way, in WWW, the server has data that the client
> wants.  In EAP, the client has data (passwords) that the server wants.  The
> trust models are very different.


They are not at all different. In both cases, the client has a principal it
wants to validate: in RFC 6125, this is the reference name. This is the
name in your credential in the case of EAP, the name of the host in the URL
in WWW. The client wants to make sure it’s talking to the entity authorized
for that name.

You can manually preconfigured exactly that entity. In EAP, this is
incredibly easy to do when you’re provisioning the client credential to
also provision the peer identity. This is the existing flow.

The long-term goal seems to be to want to indirect that, so that explicitly
provisioning credentials is not necessary. In that model, you need a
third-party, the CA, to vet and validate the identity, so your EAP server
can attest it. Rather than having to rely on a preconfigured identity, you
want to make sure the reference name matches the names presented in the
certificate.

The trust model is _identical_ to WWW, as you describe it.

If the argument is that the only information that needs validation is a DNS
name, and that it’s profile is similar to, or could be identical to, TLS,
then you still have the burden of demonstrating the operational
considerations are the same before you make the case to reuse the existing.
For example, the payment terminal example I mentioned used the same
policies and profiles, but the operational consideration was these devices
are not field upgradable and only support certificates from a limited
number of CAs. The lack of updates and the lack of agility were an
insurmountable gulf of difference from the constraints of operating systems
(patches) and browsers (regular updates), and so these devices need
separate PKIs, which ANSI X-9 is happy to oblige:
https://x9.org/asc-x9-launches-new-security-study-groups-on-public-key-infrastructure-pki-and-transport-layer-security-tls/

If this future world is a world where the provisioning of certificates is
only done via ACME, and manual configuration is “unsupported” (even if
technically capable, it’s in the “may break you at any time if you decide
to do this” level of support), and your profiles are explicitly short-lives
to help ensure this, then yes, it’s reasonable to talk about overlap.


>   Shipping a trusted root CA on the supplicant OS is the *only* way to do
> this.


This is not true.

Shipping the trusted root CA list in the supplicant _software_ totally
works. Conflating the supplicant with the OS is continuing to muddy the
waters.

  Instead the supplicant is shipped with the OS. Therefore, any root CAs
> needed by the supplicant MUST be included with the OS.
>
>   It really is that simple.


This may seem like splitting hairs, but it’s a _profound_ distinction if
you’ve ever managed PKIs on operating systems, as this is not true.
Shipping a CA list in the supplicant shipped in the OS != shipping a CA
list in the OS. They are very different models of managing and configuring
that should not be conflated. Android has plenty of OS components that ship
their own root stores, separate from the root store it provides as part of
its public API contract. We only need the former, not the latter.

It sounds like this has circled back into “How do we get
Apple/Microsoft/Google/whomever to have their supplicants trust a set of
CAs by default”, and the steps outlined above continue to be it. For
Google/Android/ChromeOS, I’m not going to want to conflate the TLS PKI and
the EAP PKI if they have different operational considerations (e.g. the
ease of replacement of certs and the ability to respond to CA incidents),
different profile considerations (the information being attested), and
different policy considerations (how that information is validated). The
advocates of such a solution need to do the work in defining the profiles
and policies and presenting that as the use case for why.

To the OS vendor, managing these profiles and policies is a non-trivial
undertaking involving a host of folks: Legal (for contracts and CP/CPS
review), Engineering, Project/Program Management (it’s a lot of work to
review several thousand CAs a year, let alone the 60-70 organizations in
the root store), Release Management, etc. There has to be a value
proposition here, because the convenient part of the much maligned manual
configuration is that it outsourced all the risk the OS vendor might be
taking on, and instead allows it to be the customer’s problem. That may
seem unfair and non-ideal, but that’s where the risk/value calculus is
right now, and to get vendors to change, you need to present a compelling
value case that demonstrably minimizes risk. Trust is hard and expensive 🤷

  In conclusion, we need a new PKI, and the root CAs must be included with
> OS distributions.  But the OS vendors won't do that until we define the
> requirements, solution, and transition path.


The transition path has been repeatedly defined, so that’s 1/3 of the way
there 👍