On Mon, Apr 12, 2021 at 5:48 AM Alan DeKok <[email protected]> wrote:
> 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. > > [Joe] You would need to use the name matching in conjunction with validation to a trusted root. > > 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. > > [Joe] without some sort of name matching using certs from a public CA is unwise. > > 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. > > [Joe] In this case we would have to rule out CAs that are not under the organizations control (public CAs) > 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
