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

[Alan DeKok <[e-mail]>]

On Jan 7, 2020, at 2:19 PM, Ryan Sleevi <[e-mail]> wrote:
> Was there a typo here? I’m not sure how to parse or understand this?

  I read your previous messages as claiming there were issues *specific* to EAP using id-kp-serverAuth.  When I asked for specifics, the response was to describe general issues with certificate management.

  My conclusion, then, is that there are no issues specific to EAP using id-kp-serverAuth. 

> > Security:
> > - Cross-protocol considerations due to key reuse seems like a meaningful security issue that's being dismissed.
> 
>   Who is dismissing it?
> 
> >   Any security issues are limited. 
> 
> ^ this seems dismissive

  Nonsense.  I'm asking you to prove your position that there are issues.  I've given detailed explanations of security issues, including pros and cons.  There is no possible way you can see such discussion as me being "dismissive" of the issues.

>   *Everyone* has been doing this with EAP for a very long time.  i.e. getting a certificate using id-kp-serverAuth from a root CA, and then using that certificate for EAP.  I have never heard of such a certificate being revoked.
> 
> The same was said for people embedding private keys in their software.

  I have no idea what that means, or why it's relevant.

  People have advocated all kinds of stupid things over the years.  None of that is relevant.  The concern here is that you're claiming there are major issues with EAP using id-kp-serverAuth, and that those issues *will* be seen.  My counter-position is that it's been 15 years, and no such issues have been seen.

  So please state *what* issues exist.  *Why* they are issues.  *What* effects those issues will have.  Failing that, please stop claiming that there are issues.

> > There's no short-term or medium-term solution that can rely on 'accepting' or 'specifying' the use of id-kp-serverAuth, which was the original proposal as a "recommend". Any of those uses are inherently broken and unsafe and just time bombs waiting to go off.
> 
>   It's been 15+ years.  There has been no such issue.
> 
> This is empirically false. The use of certain CA’s certificates in wireless deployments has absolutely been a barrier to compliance and improvements.

  How?  How are those barriers *specific* to EAP, and are not generic to any certificate upgrade / change?

  You haven't said.

>   I think it's acceptable to recommend people continue existing practice, where such practice has been shown to be (a) workable, and (b) has no known issues.
> 
> I’ve demonstrated both a and b are false, perhaps not to your satisfaction, but it remains true.

  No, you haven't demonstrated that.  And not even "to my satisfaction".  You've made claims with essentially zero evidence.

  And let's be clear here.  Your claim above is that the existing EAP practices are *not* workable.  That claim is disproven by the working of all WiFi equipment.

  Since I'm not satisfied or maybe not understanding your point, please explain *how* the current EAP practices *do not work*, in the face of billions of devices that manifestly do work.  Please make the explanation simple, and specific to EAP.

> The same message you’re replying to contains one, which you dismiss as unworkable. It’s unclear why, or if the only solution is enshrine the status quo?

  Where did I dismiss any solution as unworkable?

> Apologies for the confusion here, but there seems to be a lot of unresolvable contradictions here. We must do something different, but we can’t change. We know the current solution is bad, but there’s nothing wrong with it. We need something better, but we can’t break anything.

  My position is in no way contradictory.  I will re-iterate as it seems to be misunderstood:

* the existing practices work (you claim they do not)
* the existing practices appear to be mostly secure (you claim they are not)
* the existing practices are imperfect (using TLS web server OIDs for EAP is bad, and allows for a security issue)
* we should come up with a better solution
* that better solution CANNOT be implemented by breaking existing systems
* we need a migration path from "now" to "the better solution".
* there has been discussion about what a better solution would look like
* discussion has indicated that others oppose parts of the proposed solution.

> I strongly disagree here. Documenting bad behaviour in SDOs serves to try and legitimize it. The only benefit is to allow existing implementations to align and new implementations to be interoperable, except the behavior being specified is bad, and will break, and will cause pain. Even on the Informational track, that would be actively harmful to the ecosystem.

  How?

> > I know that's easy to say when it's individual vendors who have to deal with the fallout and that's why I suggested there's a spectrum of responses for how that's phased out. But explicitly moving towards that goal, and not trying to live in the interim with id-kp-serverAuth, seems the best path forward.
> 
>   I welcome concrete proposals to move forward.  The discussion here seems to recommend against using id-kp-eapOverLAN and NAIRealm.  Which means we *don't* have a way forward.
> 
> Why not?

  We don't have a way forward until WG consensus is reached.  Which is why we're having this discussion.

  Honestly, I'm confused at the discussion here.  You're not showing any *concrete* security issues above what I've already discussed.  You're not proposing anything better.  You're claiming that EAP doesn't work today.  You want to fix things by breaking everything.

  That's... not something I understand.

  Alan DeKok.