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

[Ryan Sleevi <[e-mail]>]

On Wed, Jan 15, 2020 at 11:07 PM Benjamin Kaduk <[e-mail]> wrote:

> A couple things that stand out to me from having basically read the whole
> thread in one go (this is not intended to be an exhaustive list of open
> questions):
>
> It was implied but not fully clear to me, that Ryan thinks that someone so
> inclined could, right now, go around trying to connect to wifi using EAP
> authentication, grab a packet capture of the remote server using its
> id-kp-serverAuth certificate for authenticating the TLS-over-EAP
> connection, and report that certificate to its issuing CA as "misuse"
> requiring prompt revocation, at least for several major CAs.  It's quite
> probably that I missed them as they went by, but specific links to specific
> CA policy documents that would classify such certificate usage as "misuse"
> (requiring revocation) would help clarify things, at least for me.
>

While I think people are missing the forest for the tree, here's an example
CP/CPS from a CA:
https://www.certsign.ro/media/document/ZytpRDNNUTFHR01Ra2MxVUx4REdQZz09/original/CPS%20OV%20SSL_v%201.10_April%202019.pdf


1.4.2 Prohibited certificate uses
> Any usage of a certificate other than the usage explicitly allowed in the
> CPS, is prohibited.
> 1.4.1 Appropriate certificate uses
> Certificates may be used in applications that satisfy at least the
> following conditions:
> • Manage properly the public and private keys,
> • Certificates and associated public keys are used in compliance with
> their declared
> purpose, confirmed by CERTSIGN,
> • Have built-in mechanisms of certificate status verification,
> certification path creation
> and validation control (signature availability, expiration date etc.),
> • Provides relevant information regarding certificates and their status
> for users.


It's already been flagged, for the CA to fix in their next CP/CPS update (
https://bugzilla.mozilla.org/show_bug.cgi?id=1403453 ), that they're
conflating requirements on Relying Party applications (i.e. those that
verify certificates) and Subscriber applications (i.e. those that serve
certificates). Does your RADIUS endpoint support and use OCSP stapling and
disable WiFi if the certificate is expired? No? Then it's a potential
violation of this CP/CPS.

Now, folks might be unhappy with that, thinking certSIGN isn't a "major"
CA. Here's DigiCert's CPS -
https://www.digicert.com/wp-content/uploads/2019/11/DigiCert_CPS_v420.pdf .
4.9.1 states that:

> DigiCert may revoke a certificate within 24 hours and will revoke a
> Certificate within 5 days if one or more of the following occurs:

...
> 3. The Subscriber or the cross-certified CA breached a material obligation
> under the CP, this CPS, or the relevant agreement;


DigiCert's Subscriber Agreement (the relevant agreement) is at
https://www.digicert.com/legal-repository/Subscriber-Agreement.pdf and, in
Section 2.2, makes reference to their Certificate Terms Of Use -
https://www.digicert.com/legal-repository/Certificate-Terms-of-Use.pdf

This Terms of Use has gems like (in Section 12)

>  Customer will use passwords that
> are randomly generated with at least 16 characters containing uppercase
> letters, lowercase letters, numbers, and symbols
> to transport Private Keys. Customer will only allow Customer’s employees,
> agents, and contractors to access or use Private
> Keys if the employee, agent, or contractor has undergone a background
> check by Customer (to the extent allowed by law)
> and has training or experience in PKI and other information security
> fields.


And in Section 16:

>   Customer will only use a TLS/SSL Certificate on the servers accessible
> at the domain names listed in the issued Certificate


Remind me how an EAP-TLS/RADIUS server is accessible at that domain name?
And if someone points their domain name to my server, would that require
revocation?

Or in Section 17:

> DigiCert may revoke a Certificate without notice for the reasons stated in
> the CPS, including if DigiCert reasonably believes
> that:
>
...

f. the Certificate was used without authorization, outside of its intended
> purpose or used to sign Suspect Code;
>

id-kp-serverAuth sure does seem to mean "WWW server", since RFC 5280 states:

>    id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
>    -- TLS WWW server authentication


This may seem pedantic and overbroad (OK, it definitely is), but that's the
entire meta-point here.

There's two parts of discussion from the thread:
1) What do extant clients do, today, in the verification of certificates
used in EAP-TLS
2) What should future clients do, 'tomorrow', to make this easier to use
and secure, ideally by default.

Much of the answer was around #2, which is "Don't try to glom on to
something existing, you need to build your own thing", as well as "Some of
the answers in #1 are problematic and you should try and discourage them"

In the hopes it makes it more accessible, imagine a situation where both
Ben and I need gears (widgets, sprockets, take your pick).
Ben needs gears that are 4cm in diameter and capable of being used in
temperatures from 0-20 degrees Celsius.
I need gears that are 4cm in diameter and capable of being used in
temperatures from 0-30 degrees Celsius.
We both get our gears from a single supplier: Cogswell's Cogs

Ben has a bunch of spare gears around for my equipment, and realizes he can
just use my gears in his equipment, and everything just works. Our
requirements are seen as compatible. That's convenient! However, when Ben
approaches Cogswell's Cogs, to sign a supply agreement, it's important that
the contract doesn't say "Ben will get 100 of whatever gears Ryan gets".
Instead, Ben should say "Ben will get 100 gears that are 4cm in diameter
and capable of being used in temperatures from 0-20 degrees Celsius": what
Ben actually requires.

That's because I may (read: will) change my gears to be 5cm in the future,
and be used in temperatures from 15-45 degrees Celsius, and those won't
work anymore for Ben. However, if Ben's contract says "I'll have what
Ryan's having", then that's what he's going to get, and sad times will be
had. I certainly won't have much sympathy for Ben, when Ben comes asking
that I change my equipment back to how it used to be, because Ben's needs
are different than my needs, and it's entirely Ben's fault for not
specifying his contract based on what he required, rather than what I was
getting.

Similarly, it'd be a bad idea to give instructions to say "Ryan's gears
work with Ben's equipment", especially when my specs can and will change.
They can even end up completely incompatible. For example, Ben might
require durable, long-lived gears, because Ben's equipment goes into hard
to reach places that are difficult to service, and thus that they may be
made of metal. My gears might be made of metal now, but that's expensive
for the machining and milling, and I may be planning to switch to plastic,
as part of ensuring they're mass-market affordable and easily replaceable.

To connect it back to the discussion: The discussion about revocation, and
what a CA's CP/CPS says is or isn't allowed for a usage, matters, because
browsers require CAs promptly revoke those certificates in 24 hours/5 days
for situations when they specify bad requirements. Can problematic CAs fix
their CP/CPS to allow this? Yes. But you've still got a host of other
expectations/requirements that can and will diverge, over time.

In the specific context of thinking about "#2" - what a touch-free future
looks like - having it use the same root store as Web browsers is the
anti-pattern, because the requirements are different. It's like Ben saying
"I want Ryan's gears", rather than thinking about "I need gears that are
4cm in diameter, capable of being used in temperatures from 0-20 degrees
Celsius, and durable enough to be used in hard to reach places" - and
finding someone who can and will manufacture those for you. You might end
up using Cogwell's Cogs, just like I do, and it might be that, for a time,
our gears are produced on the same production line - but your requirements
and my requirements aren't intertwined.


> Is there anything better for implementations to actually do (as distinct
> from what we write down as recommendations) than to start setting up a
> parallel (purpose-specific) PKI now and trusting that in parallel with what
> they're currently doing, with the hope of being able to have a flag day
> many years down the line when the new PKI becomes the only thing that's
> trusted?
>

There's no doubt the status quo is "Everything is manually configured" and
"It's inconsistent what is validated". The goal is to get to #2, "It just
works"

- Define your requirements (the certificate profile)
- Define your policies (what do you expect CAs to verify, and how do they
verify)
- Provide a way to distinguish "new certificates" from "The old and manual
cruft" - for example, an explicit EKU
- Pick your poison.... er, CAs... for the new root store (e.g. as WiFi
Alliance has done, or Wireless Power Consortium has done, or plenty of
vendors have done)
- Have CAs issue certificates with both EKUs (old and new) in the leaf.
It's a SEQUENCE for a reason.
- Have supplicants configured that
   - If new EKU is present, look in built-in store
   - If old EKU is present, require manual configuration

This gets you half-way to #2: things can just work if you pick one of the
new-CAs with new-EKUs, and otherwise require manual configuration for
old-EKUs

At that point, supplicant vendors can slowly phase out support for 'old EKU'
- If the certificate is manually generated by the wifi server, it is 'easy'
to just generate certificates with the new EKU (potentially with *both* new
and old EKUs)
- If the certificate is coming from a "Web PKI" CA, it intentionally
'breaks' / makes this case difficult.

Similarly, RADIUS/EAP-TLS servers can require, when certificates are being
installed, that the 'new' EKU be present (potentially alongside the 'old'
EKU), and that the certificate conforms with the 'new' profile.

At some point, down the line, you can explicitly prohibit the new root
store from issuing with id-kp-serverAuth. Supplicants will all be looking
for/requiring the new EKU. Your RADIUS/EAP-TLS servers will all be
requiring the new EKU to be configured. But when, where, and how you cross
that rubicon is up to y'all, and that's the only flag day involved: when to
turn off the old.