Hi Alan,
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)? 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)?
--Mohit
On 12/21/2017 04:01 PM, Alan DeKok wrote:
On Dec 21, 2017, at 8:40 AM, Jari Arkko <jari.ar...@piuha.net> wrote:
I’ve been thinking of what to do with the EAP work that got discussed both in
the SAAG meeting last time (my drafts), as well on the list. The latter was
more on the EAP-TLS side, and it seems that the discussion has converged to a
reasonable direction recently.
Wondering how we could get the work moving forward. The first thought that came
to my mind was to start a small working group. Thoughts? A very drafty idea of
what it would do is below. Comments appreciated.
The Session ID also needs to be defined for SIM and AKA, as per Jouni's
comments. That doesn't fit in with AKA' changes.
It may also be worth re-examining EAP-TLS. Modern certificates are getting
large, and people are using longer certificate chains. The result can be that
initial EAP-TLS authentication takes many packets. This has issues not just
for latency, but also access point implementations. Most implementations will
drop an EAP session if it hasn't finished after 40-50 packets.
I've seen people run into this issue with large certificates and long
certificate chains. It would be good to find a way to allow this use-case.
Alan DeKok.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
