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

[Ryan Sleevi <[e-mail]>]

On Tue, Jan 7, 2020 at 12:51 PM Alan DeKok <[e-mail]>
wrote:

> On Jan 7, 2020, at 12:33 PM, Ryan Sleevi <[e-mail]> wrote:
> > > At the high-level, 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.
> >
> >   It's been accepted practice in all EAP implementations for ~15 years.
> Are there practical issues you're aware of?  Because I can't recall seeing
> any.
> >
> > I'm sure "practical" will be seen as subjective, but here's some
> examples:
> >
> > Operational:
> > - Customers of CAs having trouble when their CA has to perform timely
> revocation of their certificates
> > - Migration off SHA-1
> > - Migration off 1024-bit RSA
> > - CAs being shut down or exiting the business due to non-compliance with
> browser requirements
>
>   How is that specific to the use of TLS (id-kp-serverAuth) certificates?
> Any use of TLS certificates by EAP would be subject to the same issues.


Was there a typo here? I’m not sure how to parse or understand this?


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

If a site administrator has access to the public / private keys for a web
> server, it's possible to re-use those certs for EAP.  This re-use cannot be
> prevented.
> >
> > No. But it results in prompt revocation of that certificate if anyone
> demonstrates it being used like that
>
>   No, it doesn't.
>
>   *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.


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


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


>
> >   Everyone knows that it's wrong to use id-kp-serverAuth for EAP.   The
> way forward is to figure out how to fix it.
> >
> > Update software?
>
>   To do *what*?  A concrete proposal would help here.


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?


> > I'm glad there's agreement it's bad/wrong to use, but it seems the only
> path forward is going to be to breaking, not recommending for using public
> (TLS) CAs with id-kp-serverAuth.
>
>   Please call Microsoft and Apple, and tell them you're going to forbid
> their 15 year workflow for EAP.  Then, tell them that you *want* their
> systems to break, and that it's for security reasons.


They’re on the same page already. I won’t claim to speak for them, but the
same principles and concerns I’m raising are and have been shared by all
the major OS and browser vendors in some form. This is the path that is on
the way out, not the way forward.

  I suspect that request won't go over well.
>
>   We just cannot break existing systems without a clear and present
> security problem.  And none has been demonstrated here.


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.

Wanting to both have and eat cake is an unwinnable position.


> > Attempting to specify some interoperable behaviour in the interim,
> before things are broken, for how folks can keep using id-kp-serverAuth,
> seems to be the problem. Just accepting that things need to be broken seems
> like it easily allows moving into the discussion about NAIRealm and manual
> configuration.
>
>   I think it's OK to *document* existing behaviour.  Behaviour that has
> been demonstrated in to be interoperable with billions of devices.


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.


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

>