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

[Alan DeKok <[e-mail]>]

On Jan 8, 2020, at 3:11 AM, Ryan Sleevi <[e-mail]> wrote:
> 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.

  We absolutely need a dedicated hierarchy.  A major reason why EAP uses id-kp-serverAuth is because no other hierarchy has been available.

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

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

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

  There's a big difference between "my bank has some IT issues", and "all of enterprise WiFi stops working, world-wide".  That's my concern.  And, why I think existing practices will continue into the foreseeable future.

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

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

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

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

  On initial reading, none of those attacks are relevant here.

  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.e. we're not re-using the same private key material across disparate encryption protocol.  Which is what those papers discuss.  We're using TLS as TLS, in the same way that other people use TLS.  It's 100% normal TLS, with 100% the same certificate.  The only thing that changes is the transport layer which encapsulates the TLS protocol.

  I fail to see how using an EAP header is insecure, whereas using a TCP header is fine.  The only attack I'm aware of is an administrative one.  A TLS web admin can use the web certificate to set up an unauthorized SSID.  And, an EAP admin can use the EAP certificate to set up an unauthorized web server.  That's really it.

> 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?  If so, why?

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

  Sure.

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

  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.

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

  "My bank has IT issues due to stupid tech stuff" is completely different from "Wi-Fi is broken world-wide".

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

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

  That attitude is approaching ad hominem invective, and it's entirely inappropriate.

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

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

  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.

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

  All of the transport-specific validation happens in the application.  Because only the application knows what transport is being used.  And only the application can tie the two together.

  This is how TLS applications have been written for a very long time.  So I'm not sure why you describe checking id-kp-serverAuth as "post-validation".  It's not.  It's just one step of many.  The TLS library does some checks, and the application does other checks.  And doing it this way isn't an "interesting strategy", it's the only possible way to do it.  it's been industry practice for decades,

  A think a good chunk of the disconnect here is simple unfamiliarity with the subject space.

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

  I agree.

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

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

  That's been my position from the beginning.

  Alan DeKok.