On Apr 11, 2021, at 11:19 PM, Joseph Salowey <[email protected]> wrote: > RFC 5216 lacks guidance on how to validate the EAP server's certificate > especially with respect to identities.
Yes. :) > RFC 5216 recommends validating the certificate path is valid and that the > extended key usage attributes are either not present, allow for any usage or > allow for TLS server usage. This creates an issue that if the same truest > root is used for EAP TLS and for other TLS server usage that any TLS server > will be able to extend its privilege and behave as an EAP server. The > following recommendations are made for implementations and deployments to > avoid this problem. One of my colleagues, Arran Cudbard-Bell wrote a cute tool a few years ago. It would pretend to be a WiFI hotspot. Then when systems tried to do EAP, it would strip the realm from the EAP identity. It would then, use HTTPS to connect to a web server for that realm, and download that HTTPS server cert. That cert would then be cloned under a new "self signed" CA, and the cloned cert presented to the user. The only real difference between the "real" and "fake" certs was the root CA / trust anchor. So yes, this is a real issue. Even in a trusted environment, a web server admin can set up a WiFi hotspot using the HTTPS server cert. This seems wrong. > 1. EAP TLS Peer implementations SHOULD allow for configuration of names to > match against SANs of type DNS name that are authorized to act as EAP-TLS > servers. Given the above attacks, I'm not sure that this helps. > 2. CAs MAY issue certs to EAP Servers that specify the id-kp-eapOverLAN EKU > specified in RFC 3770. EAP TLS peer implementations SHOULD allow for the > configuration to require the id-kp-eapOverLAN EKU for validation of EAP > server certificates. That's good, but as discussed previously on this list, it's essentially impossible to get those certs from public CAs. Claims of "just start your own public CA" notwithstanding, the only practical way to do it is with a private CA. > 3. If the above options are not available then separate trust roots need to > be used to issue certificates for EAP-TLS server and for TLS servers. EAP > TLS peer implementations MUST allow for configuration of a unique trust root > to validate the server's certificate. > > EAP-TLS peer implementations SHOULD provide ways to automate the > configuration of the information necessary for the validation of the > certificate. After looking into this in some depth, the only real thing you can depend on is the CA. If the CA is trusted, nothing else matters. If the CA is not trusted, then nothing else matters. i.e. for any kind of increased security you'd like to add to EAP-TLS, you can almost always find a scenario where that security forbids real-world use-cases we'd like to support. Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
