Large amounts of data in EAP-TTLS

[Alan DeKok]

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

  Good point.

> Are you sure this was caused by compression? 

  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.

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

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

  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.

  Alan DeKok.