Large amounts of data in EAP-TTLS

[Jouni Malinen]

On Tue, Nov 20, 2007 at 03:57:52AM +0100, Alan DeKok wrote:

>   If compression is enabled in the TLS session, then the decrypted data
> could be much larger than the encrypted portion.  Of course, my tests
> ran into this, because I was sending large amounts of identical data as
> padding, just to test the system.

EAP-TTLS extends EAP-TLS and consequently, I would assume it has to
follow the restrictions placed on EAP-TLS. RFC 2716 Ch. 3.7 prohibit use
of compression ("As a result, during the EAP-TLS conversation the EAP
endpoints MUST NOT request or negotiate compression."). Based on this, I
would assume that this particular problem should not show up when used
with compliant implementations.

The odd part here is that as far as I can tell, eapol_test should not
have tried to negotiate compression or well, at least it does not in my
tests. ClientHello goes out with just one supported Compression Method
(0 = null).

>   Is there a correct way to fix this?  Setting the phase2 buffer size
> large works, but isn't optimal.  An alternative would be to keep reading
> the SSL context until there's no more data, but that would require
> addition code to handle subsequent memory allocation.

Are you sure this was caused by compression? This could be something
else like problems in handling (EAP) fragmentation of the phase 2 data.
How large amount of data are you sending in the tunnel? Which version of
wpa_supplicant/eapol_test were you using in the tests?

-- 
Jouni Malinen                                            PGP id EFC895FA