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

[Jan-Frederik Rieckers <[e-mail]>]

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)

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.

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.

A setup of WPA2-Enterprise can be secure if all devices are part of a
centralized Device Management, but especially in eduroam this isn't
possible. We have a lot of people who don't really care about security.

  Jan-Frederik Rieckers