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

[Ryan Sleevi <[e-mail]>]

Or... just stop using those certs/roots already? We’ve already identified
that there is absolutely zero reason to do so in the extant status quo,
because it still requires manual configuration. You get no benefits and
clearly downsides, so just... don’t do that? Any complaints about how that
existing PKI is managed is just a complaint that it doesn’t fit your
purposes and doesn’t do what you want, which is fine: that’s the entire
point.

If you don’t like CAs being required to do what they say, and be held
accountable to stated policies, then sure, let them issue whatever they
want and decide unilaterally what the risks are. Of course, then you’ll end
up with situations like CAs issuing certificates with duplicate serial
numbers, with one of the duplicates being a CA certificate used for active
MITM of user connections, and the issuing CA complaining that revoking
would be disruptive for those other holders with the same serial number.
Which is a real thing that happened, and indistinguishable from a policy
perspective to Alan’s example. Or you can deal with the commiserate legal
risks involved in selectively enforcing when you agree or disagree with the
CA’s risk assessment and what is “reasonable”, with the CA who issues
certificates used for MITM lamenting it’s “unfair” and “inconsistent” that
they aren’t allowed to declare there is no risk for those certificates,
while other CAs get to declare there’s no risk for EAP-TLS, despite their
policies stating they don’t allow it.

If you don’t want to deal with those problems, which are messy and complex,
then yes, manually configure your certs, and don’t manually configure ones
that expose you to all of this. Problem solved, and no need for Dickens.

I can appreciate that, if you’re not involved with managing a PKI or trust
store, it would seem undesirable to actually enforce standards and
contracts and policies as they were written, especially when inconvenient.
Yet documents like RFC 3647 exist precisely because the world is not a
technocratic utopia, trust is a hard problem, and it exists in a world
where there are messy and complex legal problems. If you want to use want
to use PKI, and you want to do more than just require explicit manual
configuration, then you have to deal with all of that and more. You can
pretend it doesn’t exist, but you can’t escape that reality. DigiNotar is
an example, but one of dozens at this point. Manual configuration lets you
localize that to things you control, and so that’s an eminently reasonable
status quo.

On Sat, Jan 18, 2020 at 12:34 AM Owen Friel (ofriel) <[e-mail]>
wrote:

> If the PKI community as a whole (vendors, standards bodies, consortia,
> CAs) has managed to engineer a situation where, according to the strict
> letter of the law, CAs would have no choice but to revoke operators
> identity certificates for many of their services if Alan was actually mean
> and wrote his script, which would cause widespread outages, then, quoting
> Charles Dickens, "the law is a ass", and I'm with Alan and Richard and the
> law (the CP/CPS) should probably change.
>
> > -----Original Message-----
> > From: Spasm <[e-mail]> On Behalf Of Alan DeKok
> > Sent: 17 January 2020 19:39
> > To: Ryan Sleevi <[e-mail]>
> > Cc: [e-mail]; Michael Richardson <[e-mail]>; Joseph
> > Salowey <[e-mail]>; Benjamin Kaduk <[e-mail]>; EMU WG
> > <[e-mail]>
> > Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert
> validation
> > logic
> >
> >
> > On Jan 17, 2020, at 12:33 PM, Ryan Sleevi <[e-mail]> wrote:
> > >  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.
> >
> >    I'm not sure how a RADIUS server will disable WiFi.  They are
> entirely separate
> > systems.
> >
> > > 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?
> >
> >   The RADIUS server has a domain name, which is commonly used in the
> > certificate.
> >
> >   If that is insufficient for the CAs purposes, then we should also
> acknowledge
> > that the revocation requirement likely also applies to SMTP, XMPP, DNS
> over
> > TLS, and IMAP.  i.e. *all* non-WWW protocols which use TLS.
> >
> >  We should not single-out EAP / RADIUS as mis-using the certificates in
> this
> > manner.  The mis-use of these certificates in other protocols is orders
> of
> > magnitude larger than the EAP / RADIUS problem.
> >
> > > 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
> >
> >   EAP supplicants follow RFC 5216 Section 5.3.
> >
> > > 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",
> >
> >   True.
> >
> > > as well as "Some of the answers in #1 are problematic and you should
> try and
> > discourage them"
> >
> >   There were *allegations* of problems.
> >
> > > 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.
> >
> >   If I was mean, I would write scripts to troll the net for mis-use of
> certificates in
> > SMTP, XMPP, IMAP, VPNs, etc.  Then, make the script auto-submit notices
> to the
> > relevant CAs.  That process is simple to do, and by the above rules,
> would
> > require the CAs to revoke the relevant certs.
> >
> >   i.e. certs which affect a high percentage of daily internet traffic.
> >
> >   If that scenario were to play out, I suspect that CAs would very
> quickly stop
> > revoking the relevant certs.  A straight-forward approach to enforcing
> the rules
> > would be over-ruled by simple practicalities:  Turning off big chunks of
> the
> > Internet is a non-starter.
> >
> >   As Michael Richardson pointed out, then solution here is likely to fix
> the rules,
> > not the protocols.
> >
> > > 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.
> >
> >   And therefore we need a different root store for *each* of EAP, RADIUS,
> > SMTP, XMPP, IMAP, DNS over TLS, VPNs, etc.  Note that we need *different*
> > stores for EAP and RADIUS, because RADIUS server are reachable on port
> 2083
> > as RADIUS over TLS, *and* they implement TLS over EAP, which in turn
> carried
> > over RADIUS.  Different use-cases, different root stores.
> >
> >   There may be significant push-back against that many root stores.
> >
> > > 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
> >
> >   That's good, but insufficient.  There is a lot more verification that
> EAP
> > supplicants need to do before automatically trusting a root CA.
> >
> >   I suspect that most CAs already know that their customers mis-use
> certs for
> > non-WWW purposes.  EAP / RADIUS is just a minor (almost insignificant)
> part of
> > this problem.  I also suspect most CAs operate based on the hope that no
> one
> > notices, and then requires them to revoke many, many, certificates.
> >
> >   Alan DeKok.
> >
> > _______________________________________________
> > Spasm mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/spasm
>