On Wed, Jan 8, 2020 at 10:38 AM Alan DeKok <al...@deployingradius.com> 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 <ryan-i...@sleevi.com> 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?
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
