Re: [Emu] Issue 47 Certificate identity checks

[Alan DeKok <[e-mail]>]

On Apr 11, 2021, at 11:19 PM, Joseph Salowey <[e-mail]> 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.