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

[Ryan Sleevi <[e-mail]>]

On Tue, Jan 7, 2020 at 9:00 PM Alan DeKok <[e-mail]> wrote:

> > The question posed in that original message is what to do with extant
> certificates and extant practices, such as going to CAs used for TLS and
> asking for an id-kp-serverAuth cert, or supplicants looking for
> id-kp-serverAuth, and whether to specify that. My answer to that is
> categorically "no, don't do that".
>
>   The use of id-kp-serverAuth is suggested in RFC 5216 Section 5.3:
>
>    In the case of the EAP-TLS peer, this involves ensuring that the
>    certificate presented by the EAP-TLS server was intended to be used
>    as a server certificate.  Implementations SHOULD use the Extended Key
>    Usage (see Section 4.2.1.13 of [RFC3280]) extension and ensure that
>    at least one of the following is true:
>
>    1) The certificate issuer included no Extended Key Usage identifiers
>       in the certificate.
>    2) The issuer included the anyExtendedKeyUsage identifier in the
>       certificate (see Section 4.2.1.13 of [RFC3280]).
>    3) The issuer included the id-kp-serverAuth identifier in the
>       certificate (see Section 4.2.1.13 [RFC3280]).
>
>   Realistically, we can't change these recommendations in an "update EAP
> for TLS 1.3" document.


For EAP-TLS, that is, where you have the full fidelity of TLS, these are
fine-ish requirements. They would be bad requirements outside the context
of TLS (e.g. signed assertions or other protocols).

However, if using the same set or CAs that popular OSes use for TLS, it
does mean that these CAs, and their customers, will still be subject to the
same agility requirements, and limited to the same profile as TLS. Because
of this, there’s ample reason to split further into the dedicated hierarchy
and dedicated EKU.

For example, no CA that is “publicly trusted” for TLS will be able to issue
a certificate with id-kp-serverAuth and also NAIRealm in the otherName,
because they are contractually limited (and in some cases, legally
restricted by their local operating jurisdiction) from including other
forms of subjectAltNames. The use of distinct EKUs, however, would allow
them to do so, because those restrictions and regulations are largely
specific to id-kp-serverAuth.

> This is not specific to EAP, but part of the general problem of
> repurposing different trust hierarchies and different implementations,
> without addressing or mitigating the ecosystem considerations.
>
>   There are many OIDs assigned to extended key purpose:
>
>
> https://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-1.3.6.1.5.5.7.2
>
>   On quick inspection, most of those don't define their own PKI
> hierarchy.  So it would seem that most have the same problem.


Yup. I mentioned in the prior mail, but perhaps it wasn’t clear, that many
of the PKI management concepts from ITU-T don’t work in practice.

That is, while RFC 5280 et al provide the technical flexibility for a wide
variety of PKI approaches, as demonstrated through RFC 4158, and RFC 3647
provides an approach for structuring the policy, the operational concerns
that arise mean that the technological flexibility isn’t usable or useful
in practice. RFC 5280 envisaged that two different applications that had
two different policies (for example, a hypothetical Google Root store vs a
hypothetical Microsoft Root store) would, on a policy level, ensure that
every CA’s 3647-policy was compatible with and audited against their
requirements, and on a technical level, ensure that every certificate they
ingested was mapped to a (Google || Microsoft) specific set of policies
contained in the user-initial-policy-set inputs of 6.1.1 of 5280, with the
Root store applying policyMappings against those trust anchors.

However, that is not and has never been the case, as applications and
verifications don’t use the user-initial-policy-set. The consequence of
this is that, from an administrative perspective, the policy OID is
virtually entirely ignored, and more or less from the first deployment of
v3 certificates, policy has been associated and imposed at the EKU level
instead. That is, if a given EKU is present, then the issuing CA is
contractually and administratively subject to the Root Store’s policies and
expectations, because client software and libraries does not and roughly
had never used the user-initial-policy-set.

In more recent times, the differences in profiles and expectations for
those EKUs (such as timestampping vs email vs TLS), and the challenges in
managing hierarchies that issue multiple different EKUs and ensuring the
hierarchy is adequately compliant with all the expectations, even when
segmented by intermediate and EKU, has seen a shift into separating out the
hierarchies such that a given hierarchy (root and all intermediates) ONLY
issue certain types of certificates. This makes the CP/CPS manageable for
the root store to consume, and manageable for the process of assessing and
auditing.

I apologize for the length of this, but it’s meant to underscore that the
flexibility afforded by 5280/3647 is not usable in practice, not as
idealized in the early 90s when the PKI Gold Rush was going on and folks
like the ABA were figuring out how to audit/assess (c.f. the PKI Assessment
Guidelines that would coevolve into/influence ISO 21188 and later
WebTrust). The hyperfederated models in 4158 work on a technical level, but
not on a practical level, certainly not on an Internet level, and
simplicity is preferred and encouraged.

> For example, the use of such certificates outside of TLS can and will
> lead to them being revoked, because one of the requirements for such
> certificates is that they be used in TLS, otherwise they're revoked.
>
>   Based on personal knowledge, such revocation will take down a number of
> banks world-wide.  And many other enterprises.  Which to me, means it's not
> going to happen.


Folks used to say the same about certain prominent root CAs: that they were
“too big to fail”. The reality is that while I suspect you’re right that
the CA is strongly incentivized not to follow their own stated policies
when those policies would cause harm, in many cases, they are contractually
or legally bound to do so; e.g. they’re required to follow their policies
by the root stores they are included in, and if they fail to do so, they
are removed from those root stores. As removal from the root stores means
things go from “one customer impacted” to “all customers impacted”, or
impact the viability of the business model of the CA, the root CA is
strongly incentivized to follow their policies over special favors for that
customer.

There are countless examples of this in the TLS PKI, because allowing CAs
to selectively ignore stated policies to appease certain customers is, at
its core, indistinguishable from malice or compromise from the point of
view or those who trust that CA. Major companies have had their
certificates revoked even when it left software or services non-functional.
If there is any theme from the TLS PKI for the past 5 years, it’s been “I’m
sorry, that’s unfortunate, but for the greater good you MUST be broken
because you’re certificate does not conform.”


>   And how the heck is the CA going to find out?  They don't have armies of
> people trolling SSIDs for "mis-use" of certificates.


Perhaps it wasn’t clear why I linked to that Atlassian issue in The
Register, but the point in doing so was to highlight that _anyone_ can
report to the CA when a customer is doing something problematic. For the
set of “publicly trusted” CAs, the policies they are governed by require
them to make available problem reporting mechanisms, to respond to those
within 24 hours, and if a violation, to revoke within 24 hours to five days.

This is also why I kept emphasizing the timebomb nature of it: your Wifi
may totally work, until all of a sudden someone decides to report it to the
CA, which obligates the CA to revoke.

  Any user of such a certificate could point to RFC 5216, and rightly claim
> that this use-case is explicitly allowed.
>
>   Further, RFC 2549 defines id-kp-serverAuth as being for "TLS Web server
> authentication".  But it doesn't mandate that certificates get revoked if
> they're used for another purpose.
>
>   TBH, I'd like to see a pointer to an official CA policy saying that such
> revocation is required.


As part of (Day Job), I review the policies of every CA our software
decides to trust, in detail. I also manage what our expectations are for
the CAs we trust.

A common set of expectations is the CA/Browser Forum’s Baseline
Requirements. Section 4.9.1.1 enshrines a number of common expectations of
revocation, although both root stores and CAs are free to add more. For
example, Microsoft’s policies and contracts, at https://aka.ms/rootcert,
require prompt revocation if Microsoft’s directs this, under some
circumstances.

Section 4.9.1.1 of the BRs requires revocation for “misuse”. Misuse is
intentionally (by the root programs, at least; some CAs marketing
departments would prefer otherwise) not defined by the BRs; that’s
something the CA defines, but is required to define. In RFC 3647, this is
often tied to Section 4.4.5, which maps to Section 1.4 of the CA’s CP/CPS,
although in practice CAs split this definition up all over their CP/CPS.

An example of a recent CP/CPS review, where I flagged concerns over how a
CA expressed in their CP/CPS what acceptable uses were in Section 1.4, is
https://bugzilla.mozilla.org/show_bug.cgi?id=1403453#c13 . Here, the CA
arguably prohibited the use of their certificates in TLS servers
altogether, which is pretty shocking, and why I flagged it. In practice,
the CP/CPSes I review place restrictions that limit a certificate to TLS,
and prohibit the use of the private key to sign other things. In general,
that’s a good definition of “misuse”, but it does mean that using such
certificates in other contexts (e.g. to sign documents) will cause 1.4 to
be violated, which means anyone in the world will be able to request that
certificate be revoked, at any time, and the CA have contractual
obligations to do so if they wish to remain trusted.

> Also, the changes to how PKI libraries validate TLS certificates, and the
> expectations for the issuance and management of such certificates, are at
> odds with the goals and objectives of interoperability being discussed.
>
>   I'm not sure why.
>
>   Having spent too much time banging my head against the OpenSSL API, I
> have some depressing familiarity with it.  Their certificate validation API
> doesn't care about extended key usage.  Those checks have to be added by
> the application.
>
>   So... if we upgrade EAP implementations to use id-kp-eapOverLAN, then
> only the EAP applications have to be updated.  The common PKI libraries
> don't change.


I agree that this goes away if you use an explicit EKU; the problem I was
describing exists only if the profile tries to require id-kp-serverAuth.

> Reusing private key material across protocols and use cases does cause
> issues,
>
>   Such as?


https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-felsch.pdf
https://www.usenix.org/sites/default/files/conference/protected-files/security16_slides_aviram.pdf
https://www.nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2015/08/21/Tls13QuicAttacks.pdf

I’m sure everyone’s got a favorite citation, but the TLS WG spent so long
on formal security proofs in part because of the number of issues that
resulted from the negotiation and key reuse across TLS versions, which are
functionally “different” protocols.

> just like reusing root certificates across trust purposes does cause
> issues. So using the TLS PKI is and always will be fraught with peril, and
> the maintainers of those TLS PKIs will disregard "your" concerns (the
> equipment, software, and users), because "your" use case is explicitly not
> supported and not supportable.
>
>   I disagree rather fundamentally.  For one, it's not "my" use-case.  It's
> the use-case of literally billions of devices, and of the largest companies
> on the planet.
>
>   You're suggesting here that the root CAs will tell those people to "get
> stuffed" with no repercussions.  I don't see that happening.  Ever.


You’re right that we disagree. However, it’s important to note: I didn’t
say no repercussion.

In these situations, the CA is between a rock and a hard place: they can
follow their stated policies and contractual obligations, which generally
means breaking their customer because either the CA or the customer did
something wrong, or they can violate their stated policies and obligations
and risk distrust by the vendors that trust them. This is the inherent
challenge in any third-party operates CA: you can’t delegate trust.

A good example of this is the use of underscores in domain names in
certificates. Underscores are not part of the preferred name syntax, and
thus are not conformant with RFC5280 for inclusion within a subjectAltName,
even if they’re valid DNS labels (since DNS is 8-bits of goodness). Since
resolving libraries were generally more than “just” DNS and didn’t enforce
the preferred name syntax on inputs, the use of underscores in DNS
hostnames slowly crept in to the ecosystem, with major operating systems
like Windows allowing them and resolving such names.

TLS CAs are obligated to follow 5280, and there were a few CAs that ignored
this requirement of 5280, and issued such invalid and unauthorized
certificates. Browsers declared that they must revoke these non-conforming
certificates. Yet this broke high-profile customers like Verizon, CIBC, CVS
  Pharmacy, Discover, Citi, Intuit, and Ericsson. That’s a veritable who’s
who of healthcare, banking, and telecom - and yet they were still broken
none the less, because the harm to them was outweighed by the harm caused
by selective and arbitrary compliance and enforcement. Were they happy with
their CA (and with root stores)? Oh no. Some of them definitely changed
their CA after that, and many harsh and heated threats were sent to root
store vendors. But, it happened. Those certificates were revoked.

The solution for problems like this is to make sure you don’t overlap with
the requirements of other consumers, and why using the separate EKU, which
is the most common way to free yourself of those requirements, is the best
bet.

That said, it may not totally free you. For example, Cisco could
contractually require every CA that Cisco trusts follows Cisco’s policies,
and so if Cisco forbid something your implementation wanted to do or use,
y’all would not be able to use the same set of CAs. That’s the
interoperability challenge I was referencing, and how to resolve that is
arguably beyond the ken of the IETF.

   If the root CAs try something so stupid, it will be international news,
> and they will get told in no uncertain terms to stop it.  And they will.


Hah, you and I live in very different worlds than how CAs are managed.

I didn’t see much international news when the SHA-1 deprecation in the TLS
PKI reportedly threatened to leave entire countries unable to process
payments, did you? Even stuff like
https://blog.mozilla.org/security/2016/02/24/payment-processors-still-using-weak-crypto/
got very little attention. Certainly, I think there’s still only a handful
of people who could name which CA surreptitiously backdated SHA-1
certificates for which payment processor company, in violation of their
policies and requirements, seemingly in order to attract business from them
(as the payment processor used a different CA, and that existing CA
followed the rules).

> These concerns aren't unique to EAP, by any means. But they're reasons
> why using id-kp-serverAuth is going down a route of trouble, and just
> because it's been done by some vendors doesn't mean it's good.
>
>   Not "some vendors".   All vendors.  BILLIONS of devices.  TRILLION
> DOLLAR companies.
>
>   In a fight between you and them, I'll bet on them.  I understand where
> you're coming from, but describing this practice as "done by some vendors"
> is drastically minimizing the situation.


I’m not sure how this isn’t a full-throated support for the broken and
dangerous status quo. There’s a way forward here, and change is possible. I
fully acknowledge that customer satisfaction often triumphs over technical
considerations, and customers are most satisfied when they have the least
work to do. However, it is possible to change things, even in ways that may
break backwards compatibility, and folks do it all the time.

The context in this is largely around making it zero-config, which is
entirely laudable goal, but inherently Something New and thus the absolute
best opportunity to break things.

> A transition plan is always challenging, and the IETF is generally a poor
> venue for figuring out those logistics, because they're often rarely
> technical. For example, RFC 7585 exists: implementations "just" need to
> adopt it. Or, if the desire is to have an RFC describe what the end state
> should be, it should focus on that: describing the end-state. I don't think
> it should specify the intermediate states, because those are going to vary
> on a host of concerns, and worse, encourage folks to stop at the
> intermediate state as being 'good enough'. One such example of an
> intermediate state is using id-kp-serverAuth certificates, or trying to
> make a public/private CA demarcation. Those are bad steps to take.
>
>    Again, this isn't an "intermediate state".  This is decades-long
> existing practice, and existing standards.


>   I think part of the disconnect here is that you're not clear on just how
> entrenched this use-case is.  You keep saying "some vendors" or describe it
> as an "intermediate state".  It's simply not true, and that false
> description is leading you to false conclusions.


I agree that we have a disconnect, but the context here is from Owen’s
original message, and I get the feeling you have a different design or
conclusion that you’ve not expressed but are operating on, or that I’ve
fundamentally misunderstood.

That original discussion was in the context of public CAs. In the world of
locally-configured or private CAs, I don’t have as strong opinions.
However, if the objective is to get to an end state where EAP is “secure by
default” and any EAP operator can “just” get a certificate, then any
discussion about id-kp-serverAuth isn’t the extant status quo.

Further, the nice thing about private or locally configured certificates is
they provide a very easy transition plan, because you know “someone”
generated the certificate and can generate the “right” thing when it’s
required by a client. The nice thing about EKUs being a SEQUENCE is with
everything we’ve been discussing, it’s possible to support both Old and New
for private use simultaneously, while the zero-touch world can *only* use
New.

> I'm not as optimistic as you are for suggesting 'all' EAP
> clients/supplicants are behaving and enforcing those extended key usages,
> so that doesn't seem too unreasonable. For example, wpa_supplicant doesn't
> seem to do so, in the versions used by ChromeOS, Android, or the current
> tip of tree (using either the internal or the OpenSSL implementation), and
> that seems like it probably covers quite a few devices/clients.
>
>   Apple, Microsoft, and 3GPP all require the use of id-kp-serverAuth.
> wpa_supplicant checks for it, too.  See src/tls/tlsv1_client_read.c.  The
> requirements of RFC 5216 Section 5.3 are followed.


Thanks for the pointer! Applying it post-validation is definitely an
interesting strategy, given the operational considerations and issues like
https://trailofbits.files.wordpress.com/2012/06/flame-md5.pdf that can
allow for EKUs to bleed across hierarchies. I had mistakenly looked on the
validation side, since that’s where the identity validation occurs.

However, that’s still not intrinsically at odds with the original message
to Owen, or with the design principles I’ve been trying to capture in these
replies, which is that if the desire to is to have zero-touch auth, you
need to do one of the following:
1) Define a new, non-overlapping trust store (whether for id-kp-serverAuth
or for id-kp-eapOverLan) with its own profile and policies or
2) Accept that any use of a shared or overlapping trust store will be
subject to the agility requirements of the existing trust stores (read:
OSes and browsers)

#2 is almost always going to work out badly for users and deployments,
which is why I’m so strongly discouraging it, even if it’s technically
viable, and so it’s best to accept the cost of #1 upfront rather than defer
it.

  So id-kp-serverAuth is *entrenched*.  It's not used sometimes by some
> vendors.  It's baked into existing standards and implementations.  Everyone
> uses it all of the time.  Everywhere.  Always.


And going back to the original message: is everyone always using public
CAs? I got the impression that our experiences are similar: which is that
it requires manual and explicit configuration, and there’s no “out of the
box” trust store here, and that the use of public CAs is not a concept that
can MSP, because inherently, these are all manually configured.-

I believe a good incentive to deploy the new behaviour has been discussed
> here: ease of configuration of the end-user devices.
>
>   Other SDOs like the Wi-Fi alliance are moving ahead with their own
> requirements on certificates.  CAs will support those requirements for the
> simple reason that it makes them money.


Sure, but Wi-Fi Alliance is also doing the thing I’ve been encouraging:
defining their own trust store. A CA trusted for TLS today cannot comply
with root program requirements and issue Passpoint certificates. The
profiles are incompatible, which is fine, as long as you don’t have trust
overlap. And that’s true everywhere but Windows right now, or at least when
I last did the CP/CPS reviews three months ago.

My issue with Owen’s original proposal, and hopefully it remains clear
here: overlapping the PKIs should be a non-goal. Distinguishing them at the
EKU is fine; distinguishing them at the EKU so extant CAs can issue from
extant trust hierarchies is problematic and should be a non-goal. At the
same time, changing the EKU in order to change the profile, and having
supplicants strictly enforce that profile, _is_ a good idea, in as much as
it allows you to explicitly transition to a sensible and defined profile
and make a clean break.