Hi Alan and Bernard,
Darshak, Aleksi and I are currently running some experiments at the IETF
hackathon to re-produce the problem of EAP-TLS authentication with large
certificates and long chains.
We have been generating root CA certificates, intermediate CA
certificates, and end-entity certificates (with RSA 4096-bit keys). We
are using a standard D-Link DWL6600AP1 access point.
In the morning, the client and server were always able to authentication
each other successfully. We added about 7 intermediate CAs in-between
the client end-entity certificate and the root-CA certificate. However,
the client and server were still able to complete the EAP authentication
successfully.
We then started reducing the EAP fragment_size in wpa_supplicant from
the default of 1396 bytes to about 200 bytes. And as you had mentioned
on the list, the AP drops the session after about 39/40 message
exchanges and sends a new EAP-Identity request.
From back of the envelope calculations, for such failure to happen with
the default EAP fragment_size of 1396 bytes, the certificate chain on
the client has to be about 55000 bytes. We wonder if this is true and if
this is encountered in deployments often? Are we missing something? Do
you have some numbers on the size of the certificate chain and the EAP
fragment_size from your deployment experience?
--Mohit
On 02/05/2018 12:41 PM, Alan DeKok wrote:
On Feb 5, 2018, at 4:03 AM, Mohit Sethi <mohit.m.se...@ericsson.com> wrote:
Thanks for raising this issue. I am trying to understand the problem of large
certificates and longer certificate chains a bit better.
From your deployment experience, is the problem equally bad for authentication
in both directions (i.e. both client and server certificates are large with
long certificate chains)?
More so for clients.
And is the problem only the number of EAP messages/packets, or also the
duration of a single authentication run (i.e. AP implementations drop EAP
session if not completed within x seconds/minutes)?
Mainly the number of EAP messages. The duration is less of an issue,
because it almost always happens within a second.
Alan DeKok.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
