On Feb 18, 2021, at 10:38 AM, Alan DeKok <[email protected]> wrote: > Implementations largely fixed that years ago via a few methods: > > * on initial connection to SSID, prompting the user to see if the certificate > is OK (historical, and less permitted these days) > > * pre-provisioning SSID / CA certificate / user credentials to each machine > > * certificate pinning so that the EAP server certificate is cached and > associated with an SSID / user credentials. i.e. not just the CA cert. This > caching prevents bad actors from getting their own certificate from the same > CA, and setting up their own "mirror" malicious SSID. > > The result is that this works for most situations, and is reasonably secure.
Some suggested text, perhaps for Section 5.3, Certificate Validation: There are some proposed additions to the certificate validation text in Section 5.3 of RFC 5216: Experience shows that configuring EAP peers can be difficult and error-prone, especially when that configuration is performed manually by end users. In order to avoid errors and insecure configurations, EAP-TLS peers SHOULD be provisioned via an automated process. This process should configure all settings necessary to perform EAP-TLS in a secure manner, in its expected use-case(s). These settings can include not only the certificate chain from certificate authority to client certificate, but also the expected EAP server certificate. These settings can also include information about the protocol layers above or below EAP (MAC addresses, IP addresses, port numbers, WiFi SSID, etc.). Where these settings cannot be provisioned in an automated manner, the EAP peer SHOULD cache them after first use. The peer SHOULD then present the EAP-TLS credentials only when all of the cached settings match the network being accessed. Where these settings do not match, the EAP peer MAY refuse to proceed with authentication. Where the EAP peer does proceed, it SHOULD inform the end user (where possible) as to the nature of the changes, and give the user the option of proceeding or refusing the authentication. The above recommendations have been in wide-spread use in EAP-TLS peer implementations for many years. Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
