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

[Ryan Sleevi <[e-mail]>]

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

>   The rest of the disagreement is (from what I see), bringing up
> situations or use-cases which are unrelated to EAP, and therefore confusing
> the issue.
>

They're related to the proposal that started this thread, which I'm trying
to focus the discussion on, and which may be why we keep finding
misalignment.


> On Jan 8, 2020, at 9:29 AM, Ryan Sleevi <[e-mail]> wrote:
> > 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.
>
>   I've looked, and haven't been able to find a process where I can get a
> cert with id-kp-eapOverLan set.
>

Thanks. It seems like you meant process as "They won't sell it to me", and
I meant process as "They can't sell it to me / Don't know how to sell it to
me".


> >   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,
>
>   Hmm... that wasn't clear at all.  I can't find any policies which say
> "certificates will be revoked if they're used for purposes other than TLS
> web server".


The CA must revoke if the certificate is misused; that's required by
contract.
The CA defines what misuse means.
A number of CAs define misuse as "used for purposes other than TLS web
server"
Ergo, obtaining and using certificates with EAP means these certificates
are at risk of revocation.


> > I'm guessing you may be more familiar with the embedded libraries that
> roll their own TLS stacks or build on OpenSSL?
>
>   I'm familiar with application use-cases.  Most EAP applications use
> OpenSSL.  As do RADIUS applications, web servers, DNS servers, etc.  They
> all operate the same way,
>
>   Other systems implement things differently, of course.  OS vendors are
> locking down their cert stores to more stringently control access.  This
> includes limiting the API used by applications.  What other PKI systems do
> is irrelevant, because they don't implement the application protocols.
>

It's extremely relevant to the original proposal, at
https://mailarchive.ietf.org/arch/msg/spasm/S4tO5yE_HP9CC6qd8WudY9Ln3oM,
and to the subsequent follow-ups (e.g.
https://mailarchive.ietf.org/arch/msg/spasm/E9CpTnuCNqV9d-2hnB0c3fJ4NtQ )

If you reject messages like that, then it's understandable you might
disagree on the relevance.
If you support the goal (of no-touch access), then it's still relevant in
as much as there's plenty of academic literature on how you design those
APIs (e.g.
https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html ),
but that's more of an implementation discussion.


> > I will say that using TLS (id-kp-serverAuth) certificates, from the
> intersection of CAs that are commonly trusted by operating systems and
> browsers, is bad. It will create security issues, will create
> interoperability issues, and will not help users.
>
>   I asked *what* security issues there were, and what interoperability
> issues existed when these certificates were used for EAP.  I stated that
> 15+ years of experience showed no issues.  Your response was:
>
> > This is empirically false. The use of certain CA’s certificates in
> wireless deployments has absolutely been a barrier to compliance and
> improvements.
>
>   I asked again for evidence, and got told:
>

I didn't see interpret your reply as you've summarized, but your follow-up
indicates that you disagree that it's a "security" issue if, for example, a
CA decides to not revoke certain certificates or to keep issuing certain
certificates, because that's seemingly seen as an interoperability issue.
Again, this is in the context of using the same set of CAs for EAP and for
TLS web server - I'm not speaking about other contexts here. In these
contexts, the security issue is for the TLS clients trusting certificates
from CAs that violate the policies. For example, continuing to issue SHA-1
certificates to support devices/clients that only trust SHA-1 certificates,
from the same hierarchy used for TLS. The interoperability issues are
indistinguishable from security issues in situations like this.


> > Reusing private key material across protocols and use cases does cause
> issues,
>
>    With pointers to papers that shows private key usage across disparate
> encryption methods.  These papers are entirely irrelevant to the use-case
> discussed here, i.e. these certs being used for EAP-TLS.
>

It looks like I should have spelled out a situation clearer:
- Consider that TLS 1.2 had interoperability issues with wpa_supplicant
versions and certain Cisco devices, due to confusion about the PRF
algorithm used
  - This led Apple, Google, and Microsoft to not enable TLS 1.2 for their
supplicants for quite some time, due to the ineroperability issues
  - These concerns were not applicable to the use of TLS web server
authentication, and such clients were able (and long had enabled) TLS 1.2
support
  - As a consequence, if the EAP-TLS and TLS web server shared the same
certificate, you can exercise some of those cross-protocol attacks
  - This similarly applies to TLS 1.2 (EAP) vs TLS 1.3 (web) deployments

This is an example of how certs being used for EAP-TLS, indistinguishable
from the Web hierarchy, leads to security issues. We may disagree on
categorization (e.g. "It's a deployment issue with a site, not an inherent
security issue"), but my objective is to try to prevent situations where
deployment issues result in security issues. Hence the recommendation to
make it *impossible* to reuse the same certificate across these different
consumers and use cases.


> > 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?
>
>   Suggesting that CAs will revoke all certificates mis-using
> id-kp-serverAuth *is* implying that enterprise WiFi will be disabled
> world-wide.  I explained in detail why I believe this correlation to be
> true.
>

Thanks. I think this conclusion is based on a misunderstanding. I have not
suggested CAs are going to know which certificates are used for EAP-TLS and
proactively revoke those. As you've correctly noted, and I've agreed, they
can't know. What I have suggested is that anyone, at any time, may be able
to notify the CA of potential misuse (according to the CA's definition),
thus requiring revocation. This creates an operational burden for those
deployments, and creates an incentive for the CA to ignore their stated
policies, which creates security issues for TLS clients (any CA ignoring
their policies is, fundamentally, indistinguishable from a security issue).

The way to mitigate that risk - of required revocation - involves clients
and servers make sure the certificates they accept are not subjected to
that.


> > Put simply: There's no "obtain a certificate from a public CA and it
> just works", where that certificate contains id-kp-serverAuth.
>
>   The only required step is for supplicants to explicitly enable that CA
> to be used for EAP.  As I said earlier, the root CAs are all enabled for
> the web, and none are enabled by default for EAP.
>

Yes, but I don't think that fits with the objectives of the original
message,
https://mailarchive.ietf.org/arch/msg/spasm/S4tO5yE_HP9CC6qd8WudY9Ln3oM and
the followups, such as
https://mailarchive.ietf.org/arch/msg/spasm/E9CpTnuCNqV9d-2hnB0c3fJ4NtQ

My observations have been that the means of achieving that goal are
problematic; that is, we _don't_ want to enable the extant root CAs for EAP
by default, with the described mechanism. My comments MUST be taken in
consideration as describing what that future world should look like and how
to get there.

  So I don't really care how OS vendors implement certificate checking for
> HTTPS.  It doesn't apply to EAP.  Bringing up irrelevant issues is just
> confusing and unhelpful.


Perhaps you missed replies like
https://mailarchive.ietf.org/arch/msg/spasm/E9CpTnuCNqV9d-2hnB0c3fJ4NtQ that
brought that up?

It sounds like much of our disagreement has just been on lacking the
context from the overall thread and discussion (with others), and thus
arriving at different conclusions based on that lack of context?