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

[Michael Richardson <[e-mail]>]

On 2019-11-12 3:53 p.m., Jan-Frederik Rieckers wrote:
> On 12.11.19 00:15, Owen Friel (ofriel) wrote:
>> One deployment consideration is if an operator wants to use a public PKI (e.g. Lets Encrypt) for their AAA certs, then it could be years, if ever, before these extensions could be supported (as Alan alludes to), so it would also be good to define how this could work with standard RFC 6125 DNS-IDs / RFC 5280 dNSNames.
> I had a lot of thoughts about this topic.
> I am experimenting with certificates in EAP-TLS contexts and experienced
> the problems with getting a certificate with specific extension
> properties from our public PKI. (In my case a test certificate with a
> critical MustStaple extension)

You were trying to do a CSR with some extra attributes with a CA (using
ACME? Using LetsEncrypt?) and the CA ignored the things that it couldn't
verify?
> The Problem with dNSNames is that they are also used in other contexts
> (mainly HTTPS). There would be the possibility to define a specific
> prefix to bind it to a Realm without having the certificate being valid
> for the HTTPS host (e.g. eap-tls.uni-bremen.de for the realm
> uni-bremen.de) but I don't see the advantage in that.
> This will probably don't really lead to a change in the supplicants
> implementations.

I think you are saying that the problem with dNSNames is that web
servers use them/pay-attention to them, so CAs are careful what they put
in.  That's a reason to avoid that SAN in my opinion.  Toerless, in
draft-ietf-anima-autonomic-control-plane went the other direction, and
argued that only dNSNames have good interoperability, and so we have to
use only them.
> My deployment experience shows, that the certificate check is the main
> security problem in WPA2-Enterprise networks. I have seen instructions
> for installing WPA2-Enterprise networks where they have explicitly
> suggested switching off the certificate check, probably because it was
> too complicated for the users and would lead to people complaining at
> the IT department about the complicated setup.

So, as I understand it, the enrollment process for laptops/phones into
WPA-Enterprise does not include retrieving a set of anchors for that
connection.  Or that it is just too hard to do.   It works fine if the
devices are compelled by their corporate masters, but this fails for
BYOD, and it fails for cross-realm (which eduroam is).