Large amounts of data in EAP-TTLS

[Jouni Malinen]

On Tue, Nov 20, 2007 at 09:04:12AM +0100, Alan DeKok wrote:

>   At least partly by compression.  I'm seeing ~300 bytes of data go into
> SSL on the FreeRADIUS side, and ~150 come out.  So that appears to be
> compressed.  I haven't looked at the details of SSL negotiation, but I
> would suspect compression.
> 
>   FreeRADIUS doesn't do anything specific to disable compression negotation.

I tested the current CVS HEAD with wpa_supplicant (0.6.x devel) and
compression was not enabled. wpa_supplicant/eapol_test does not
advertise support for compression and there shouldn't really be anything
that the server can do at this point to enable it..

Getting from 300 bytes to 150 bytes in encryption phase sounds
suspicious.. I tested this by modifying FreeRADIUS to add zeros into the
end of the MS-CHAP2-Success in EAP-TTLS/MSCHAPv2. I was able to get 200
extra zeros through without problems (i.e., the MS-CHAP2-Success was 243
bytes long). This resulted in 293 bytes of encrypted phase 2 data being
decrypted into 256 bytes in eapol_test (i.e., nothing like 150->300).
Same with 300 extra zeros (389 encrypted bytes decrypted into 356
bytes).

>   wpa_supplicant 0.5.8.  The phase2 data is small, only a few hundred bytes.

I verified that I get the same results from wpa_supplicant 0.5.x branch.
I'm not sure what exactly you are seeing, but it looks like I cannot
reproduce this.. At least the simplest case of just increasing the
length of a single AVP (MS-CHAP2-Success) from 43 to 243 (and likewise,
to 343) with repetitive data (all zeros) worked fine in my tests.

>   I've also been trying TTLS/PEAP with tunneled EAP-TLS.  That sends a
> larger amount of data inside the TLS tunnel.  After some minor hacks on
> FreeRADIUS to enabled TLS inside of the TLS tunnel, the negotiation
> proceeds.  However, it fails on phase 2.
> 
>   Do you have test scenarios for TTLS/PEAP with tunneled EAP-TLS?  I'm
> about to commit some changes to FreeRADIUS CVS head that removes the
> limitation on those methods.  They won't work, but they won't complain
> about it, either.

Yes, I've tested EAP-TTLS/EAP-TLS and EAP-PEAP/EAP-TLS successfully with
multiple RADIUS servers. Couple of interop tests failed with
Meetinghouse Aegis and another RADIUS server, if I remember correctly,
and the issue was in server not handling some of the phase 2
fragmentation correctly. eap_testing.txt has more details on the tested
combinations.

I ran a quick test between eapol_test and FreeRADIUS and it looks like
EAP-PEAP Phase 1 goes through fine and eapol_test is able to send the
ClientHello for Phase 2 through fine. FreeRADIUS sends this to OpenSSL
and got back ServerHello + Certificate + ServerKeyExchange +
CertificateRequest. FreeRADIUS sends these to eapol_key and the data
itself seems to go through, but OpenSSL fails to decrypt it when
fragment_size=1024 is used. When I reduced fragment_size to 500,
eapol_test was reporting an error in TLS processing due to there being
more data than TLS message length was indicating.. I did not look into
details on what FreeRADIUS was doing, but I would assume something goes
wrong in phase 2 data fragmenting/encryption.

-- 
Jouni Malinen                                            PGP id EFC895FA