Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

[Michael Richardson <[e-mail]>]

On 2019-11-14 7:59 p.m., Alan DeKok wrote:
> On Nov 13, 2019, at 6:23 PM, Michael Richardson <[e-mail]> wrote:
>> I think that the issue isn't, can we find or define a OID that has the
>> right semantics.
>> I think that the issue whether or not any public CAs are willing to
>> include that into a certificate.
>   That's less relevant than it may be.
>
>   The common practice for years has been to recommend self-signed or "internal" CAs.  The original reason was that supplicants didn't do certificate pinning.  So if they were configured to trust a root CA, they would send user credentials to *any* EAP authentication server which had a certificate signed by that CA.  With certificate pinning, they now warn if the server certificate changes.
>
>   The other reason is that supplicant configuration is still largely a manual process.  If admins need a complex process to configure the supplicant, then adding a self-signed CA to the mix has near-zero cost.  And supplicant vendors seem entirely disinterested in a standard way to configure them.

I understand.
If the authentication server is manually configured, then it matters not
in the last what OIDs might be in the certificate.

We believe that TEAP-BRSKI (or BRSKI-WIFI) will result in supplicants
being configured during an automated process.
This would involve getting the organizational root CA, and it could pin
the authentication server certificate, or
it could pin just a DN, TBD.  The OIDs might be be useful that point,
but I would generally find them not interesting.