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

[Ryan Sleevi <[e-mail]>]

On Tue, Jan 7, 2020 at 11:44 AM Alan DeKok <[e-mail]>
wrote:

> On Jan 7, 2020, at 9:54 AM, 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

Security:
- Cross-protocol considerations due to key reuse seems like a meaningful
security issue that's being dismissed.


>   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, the same as no one can prevent you
from embedding a private key in software, but doing so gets it swiftly
revoked. [1]

[1] https://www.theregister.co.uk/2019/12/05/atlassian_zero_day_bug/


>   I'm not sure what your point is here.  I agree this usage is wrong, but
> the goal is to *fix* it.  The goal isn't to "bless" the existing usage.
>
>   The goal is to figure out what *should* supplicants do.
>

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.


>   EAP supplicant implementations largely do this already.  So there's no
> "proposal" of a new root store.  There's a statement that there *is* a
> different root store.
>

That doesn't match Owen's original message, so while I'm glad there's an
acknowledgement here of differences, that doesn't seem to match the
discussion to date.


>   i.e. implementations default to not trusting CAs for EAP.  The trust has
> to be explicitly enabled by an admin, or by the user.  This means that
> there's a store of CAs *only* for EAP.
>
>   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? 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.

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