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

[Alan DeKok <[e-mail]>]

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

  I'm not sure how that happened, but whatever.

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

  I mean both.

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

  I don't see how it's relevant, because EAP just isn't implemented like that.  I've asked for explanations, and gotten unsatisfactory answers.

  I also don't see why you would construe my comments as "rejecting" those messages.  I've taken great pains to explain my position clearly, and in detail.

  I'm starting to wonder if this conversation can go anywhere.   Why are you putting negative motives on my behaviour?

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

  It's a *procedural* issue, and a *policy* issue, IMHO.  There is no additional *security* issue.  Even your examples below aren't EAP specific.  They apply to any uses of 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

   The same attack applies to any application using TLS, including HTTP.  And most people are aware enough to *not* use the same certificate for multiple systems.  Which means that this attack is (a) not specific to EAP, and (b) only applicable in misconfigured systems.

  It helps to describe *precisely* what you're talking about.  I've been asking for many messages now exactly what you mean.  Until now, I've been getting the run-around.  That's unproductive.

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

  <sigh>  Please pay attention.

  That is the way things work NOW.  There should be no confusion about what OBJECTIVES I'm working towards, because I stated them clearly in the message you're replying to.

  Such replies are unproductive.

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

  And TBH, me asking for specific details, and getting answers which are only tangentially related to the question.

  Alan DeKok.