Large amounts of data in EAP-TTLS
j at w1.fi
Mon Nov 19 22:25:00 EST 2007
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
More information about the HostAP