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

[Alan DeKok <[e-mail]>]

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.

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

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

  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.

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

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

  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.

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

  In the absence of a solution, it's best to document existing practice.

  Alan DeKok.