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

[Ryan Sleevi <[e-mail]>]

On Wed, Jan 8, 2020 at 8:14 AM Alan DeKok <[e-mail]> wrote:

>   Except, of course, CAs don't really have a process to issue certs with
> distinct EKUs.  So they're impossible to get in practice.
>

I'm not sure what your data to support this is, but this does not match the
commercial space. While I think we're in agreement you "shouldn't" be using
publicly trusted CAs, it's not at all true that they don't really have a
process. Perhaps this was more true a decade ago, but the work on Delegated
Credentials and Signed HTTP Exchanges - both which require custom
certificate profiles for issuance, and both which are relatively recent and
yet available from CAs.


>   If mis-use isn't defined, then it's reasonable to argue that following
> IETF standards isn't mis-use.
>

I'm not sure how you reached this conclusion. I gave you an example of
where misuse is defined to preclude such certificates, and that's but one
of many examples if you read commercial CA's CP/CPSes. The argument you
might be making is that "Well, they can change" - and sure, but that's just
continuing to move the goalposts, when the high level message is the same:
that overlaying with extant CAs, the original proposal, is a bad idea and
full of sharp edges.


> >   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.
>
>   I don't see how.  Validation of id-kp-serverAuth is the responsibility
> of the application, not the TLS library.  i.e. the TLS library exports APIs
> which (a) do TLS, and (b) allow the application to selectively validate
> certificates.
>
>   It is inappropriate for a TLS library to enforce one EKU on all users of
> TLS.  And how would the library do that?  It is entirely unaware of the
> transport protocol (TCP / HTTPS vs EAP).
>

I'm guessing you may be more familiar with the embedded libraries that roll
their own TLS stacks or build on OpenSSL?  This isn't how many of the
popular root stores and PKI libraries are implemented, which again goes
back to Owen's original question, for "public" certificates and extant root
stores - for example, the root stores and PKI/TLS libraries in a number of
popular operating systems, such as Windows, macOS/iOS, Android, and
ChromeOS.

These libraries have the client say "I want it for TLS", and the validation
library not only does validation for items like EKU, but that the
certificate complies with the root store policies for such certificates.
The root store policies may (as I mentioned previously) *also* have
dependencies on the particular TLS library being used; that is, they're not
designed to be used/operated outside of a given library.


>   The situation we have here is that we have a normal TLS "web server"
> certificate which is being used for TLS.  The transport protocol here is
> EAP, not TCP.  You seem to be claiming that there are security issues with
> this use-case.  I don't see how.
>

I'm afraid we're quickly diverging again, because I'm worried this claim
isn't being taken in the context it was made, so perhaps we should circle
back to this once we're on the same page on the fundamentals?


> > 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.
>
>   But using the *same* TLS version across different transport protocols is
> insecure?


I didn't say it was.


>   I agree CAs can shut down individual use-cases if they desire.  My
> push-back is against the idea of turning off enterprise WiFi whole-sale,
> world-wide.  That's just not going to happen, no matter what the policies
> of the CA.
>

Great. I don't think anyone has suggested turning off enterprise WiFi,
whole-scale, world-wide, or even anything remotely close to that, so I
think we're good?


>   It's simple English.  Stating that this *is* the status quo doesn't mean
> I think it's a good idea.  I've spent many messages agreeing it's bad, and
> working on a better solution.  It's not just possible to describe my
> position as a "full-throated support for the broken and dangerous status
> quo."
>

I think I've spent as many messages saying the same thing: let's work on a
better solution. I've tried to articulate one several times, which doesn't
involve "break WiFi world wide", so perhaps we can focus on that?


> > 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.
>
>   The disconnect is largely that I don't think we can simply shut-down
> Wi-Fi world-wide.  Plus, you think that me describing the current system
> means I'm supporting it.  That's just not true.
>

I certainly haven't suggested we shut-down Wi-Fi world-wide. I have argued
against specifying the extant behaviour, in as much as standards imply
support, even informational. Even as tombstones of ideas that didn't work,
they serve as attractive nuisances for implementors.


> > 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.
>
>   I have no idea what that means.  It reads like you're saying the use of
> id-kp-serverAuth isn't the existing practice.  Which it is.  So... why the
> disconnect?
>

Put simply: There's no "obtain a certificate from a public CA and it just
works", where that certificate contains id-kp-serverAuth. I don't and
haven't disagreed that people can and do use id-kp-serverAuth for private
CAs, and I also don't doubt people obtain server certs from public CAs and
then manually configure them, but there's no "it just works". If the goal
is to specify "it just works", there's no reason or need to be constrained
by id-kp-serverAuth.


>   My recommendation for ~15 years for EAP has been that people should use
> private CAs.  It avoids all of the issues we're discussing here.
>

We're in quite violent agreement :)


> >   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.
>
>   I think that's another disconnect.  TLS libraries don't perform HTTPS
> validation checks for all certificates.  They can't, because they have no
> idea what the underlying transport is.  All the TLS library knows is that
> it gets handed a TLS blob.  The library does its TLS magic, and hands
> decoded data to the application.
>

I think we have very different perspectives of the industry, and I suspect
this is unfamiliarity with our divergent areas. I get the impression you're
speaking more about embedded libraries and stuff like OpenSSL, and you're
true. That's not an accurate reflection of the stacks in a number of
operating systems - e.g. Windows, macOS/iOS, Linux Standard Base (via NSS),
Android, or ChromeOS. These libraries and APIs, used to underpin much of
the client TLS traffic (including browsers) are often abstracted APIs in
which the library handles the transport as well as the verification, and
they explicitly don't support disconnects.


> >   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.-
>
>   Many people use private CAs.  Many use public CAs.  *All* of them use
> id-kp-serverAuth.  Common EAP supplicants (MS / Apple / etc.) ship with
> known root CAs.  These root CAs are trusted by default for web browsing.
> None are trusted by default for EAP.
>

Right: we're in agreement, I believe? Getting "trusted by default for EAP"
means disconnecting from id-kp-serverAuth, as part of, well, introducing
the concept of "trusted by default for EAP".