Re: [Emu] Issue 47 Certificate identity checks

[Joseph Salowey <[e-mail]>]

On Mon, Apr 12, 2021 at 5:48 AM Alan DeKok <[e-mail]>
wrote:

> 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.
>
>
[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.
>
>