EAP-TLS with TLS 1.3
aland at deployingradius.com
Mon Mar 12 13:01:32 CET 2018
On Mar 12, 2018, at 10:40 AM, Stefan Winter <stefan.winter at restena.lu> wrote:
> I'm currently looking at
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.
> 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
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.
> 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.
More information about the Freeradius-Devel