Subject: Re: [Emu] Potential re-establishment of the EMU working group

From: Mohit Sethi <[email-masked]>
Date: Sat, 17 Mar 2018 17:22:44 +0000

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 <[email-masked]> 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.
>

---

From: Alan DeKok <[email-masked]>
Date: Mon, 19 Mar 2018 10:50:55 +0000

On Mar 17, 2018, at 5:22 PM, Mohit Sethi <[email-masked]> 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.