On Mar 17, 2018, at 5:22 PM, Mohit Sethi <[email protected]> wrote: > 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.
That's good. > 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. Yes. > 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? Some. People tend to complain about problems. But they don't tend to share certificate chains. Typically the EAP fragment size is at least 1020, as that's the mandated minimum to support. It's often not a lot larger than that. There are many products which support large Ethernet frames, but somehow can't forward EAP packets which nearly fill those frames. Also, for certificate chains, the issue is less the number of certificates than what's in them. e.g. A certificate containing a name "Min Ye" will be smaller than one containing a name like "UMAMAHESWARI SUBBING" (both taken from the IETF attendee list for examples.) The same applies for the rest of the fields. Do the certs contain corporate addresses? Additional OIDs describing permitted uses? Lists of groups that the user is a member of? All of that information can bloat the certificate chain. Meaning that only a few *large* certificates could reach the ~50K limit. Instead of testing with a large number of small certificates, it would be be useful to test with *real-world* data. i.e. create certificates which contain all of the possible information (names, addresses, etc.) where all of that information is as large as possible. That gets you a rough upper limit on the size of the certificate. Even the sample certificates I use for FreeRADIUS testing easily reach 2.5Kb, with only small amounts of test information in them. Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
