Large amounts of data in EAP-TTLS

[Alan DeKok]

Jouni Malinen wrote:
> 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..

  I agree.

> 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).

  I'll go try it again.  I've made some changes to the code in
FreeRADIUS recently, which may have affected this.

  All I know is that when I re-built eapol_test with a larger buffer,
and *didn't* modify FreeRADIUS, it suddenly started working.  I had been
testing by adding new AVP's to the tunneled data, and eapol_test
complained that the decrypted tunneled data was shorter than the AVP
"length"s would indicate.

> 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.

  OK.  The entries for FreeRADIUS might be updated.  1.0 is *years* old.
 I don't think there are many more EAP types supported, but there should
be fewer issues, I think.

> 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.

  That sounds right.  The phase2 fragmentation isn't handled at *all* in
FreeRADIUS.  It assumes that all of the data fits into one packet in
phase 2.

  Alan DeKok.