EAP-TLS with TLS 1.3

[Alan DeKok]

On Mar 12, 2018, at 10:40 AM, Stefan Winter <stefan.winter at restena.lu> wrote:
> I'm currently looking at
> https://www.ietf.org/id/draft-mattsson-eap-tls13-02.txt.

  I'll be at the IETF next Monday, trying to convince them to Do the Right Thing.

> It states that:
> 
>   While Elliptic Curve Cryptography (ECC) was optional for earlier
>   version of TLS, TLS 1.3 mandates support of ECC (see Section 9 of
>   [I-D.ietf-tls-tls13]).  To avoid fragmentation, the use of ECC in
>   certificates, signature algorithms, and groups are RECOMMENDED when
>   using EAP-TLS with TLS 1.3 or higher.
> 
> That sounds like useful advice.

  Yes.

> I'm wondering though what to do if you have a diverse variety of client
> devices doing EAP; some of which only do TLS 1.2 while others do TLS 1.3.

  "When in danger or in doubt, run in circles, scream and shout." :)

> The EAP server can only present one certificate to its incoming peer
> connections.

  It should be able to pick the "right" certificate.

> If it has a ECDSA certificate, there's a chance for an interop problem
> with TLS 1.2 clients not supporting the needed cipher suites.
> 
> If it has a RSA certificate, it misses out on the small-cert benefits.

  Yes.

> I wonder if it's possible to have both certificates available to the
> server, with a late selection: depending on which TLS version has been
> negotiated, present one cert or the other.
> 
> Is that kind of stuff doable?

  Ask OpenSSL. :(

  We can do almost anything on our end.  Getting the OpenSSL magic correct may be a bit harder.  The OpenSSL documentation is a weird combination of exhaustive, and completely unhelpful.

  If anyone can take a look at how Apache does it, that would help.  Simply knowing which OpenSSL calls to do, and in what order, will solve 99% of the problem.

  Alan DeKok.