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

[Alan DeKok <[e-mail]>]

  To clarify. we agree on the following:

* id-kp-serverAuth is wrong to use for EAP
* we should use something else, whatever that is

  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.

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.

>   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".  All of the text I see on revocation is about malware, leak of private keys, etc.

> 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.

> [re: security issues with using TLS web server certs with EAP ]
> 
> 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 was reacting to the following statement:

> 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:

> 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.

  So I don't know how I'm misunderstanding you.  You claimed the use-case was insecure, and it would cause interoperability issues. 

  Maybe you're referring to other use-cases.  But if so, you're not making that clear.  I've been talking about EAP and WiFi.  Other use-cases aren't applicable here.

> 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.

> 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.

> 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. 

  Which is what I've been saying for a long time.  My goal to move to something else is to get it to the point where it just works.

> 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.

  i.e. when you say "the library handles the transport as well as the verification", this is manifestly not true for EAP.  That's my point.  I'm trying to discuss EAP use-cases.

  Linux uses wpa_supplicant (or iwd), which *do* work the way I described.  The Apple supplicant code is also online, and last I checked, also works this way.  I don't know how the MS code works, but I highly doubt that their crypto library implements EAP.  I suspect that they also have an EAP implementation which calls a TLS library to do the TLS work.

  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.

> 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".

  Yes.

  Alan DeKok.