FreeRADIUS EAP-TLS issues

[Alan DeKok]

Jouni Malinen wrote:
> Something odd is happening with the EAP-PEAP fragmentation.. If I set
> fragment_size=1300 in FreeRADIUS configuration, the first Phase 2
> message from FreeRADIUS has TLS Message Length of 1333. The first
> fragment includes 1300 bytes, so I would expect to see the remaining 33
> bytes on the next fragment. However, that fragment is 37 bytes, i.e.,
> extra 4 bytes.

  Hmm... I don't see that with the CVS head.

  I've just committed a fix where it would allow 10 bytes more than
"fragment_size" in an EAP packet.  The fragment size was being used to
fragment EAP-TLS *data*, and wasn't accounting for the header.

> If I change fragment_size to 1200, the TLS Message Length become 1237.
> This does not sound correct, since the total data length should be more
> or less the same here regardless of the fragment size (well, up to a
> certain limit since making this very small could add more fragmentation
> overhead to phase 2). However, with this fragment_size, the second
> message is 37 bytes and that matches with the TLS Message Length. The
> reassembled data is not a valid SSL record, though..

  I don't see 33 extra bytes.  I *did* see 10, but a recent commit fixes
that.

> It looks like there are at least two issues. The TLS Message Length is
> set to about fragment_size regardless of the real phase 2 length, i.e.,
> the phase 2 gets truncated, not fragmented in full. In addition, the
> phase 1 fragmentation seems to end up reporting incorrect total length
> for the fragments (i.e., TLS Message Length can be smaller than the sum
> of the lengths of all fragments).

  I've also tried setting "fragment_size" to 1300, 1200, and 600, and
testing with EAP-TTLS (pap), and PEAP (EAP-MSCHAPv2).  In those tests,
it now sets the maximum EAP packet size to the fragment size.  The TLS
message length stays the same for all fragment sizes.

  The phase 2 data doesn't get fragmented in FreeRADIUS.  The code
doesn't handle that at all.  It just gets truncated.

  When trying PEAP with tunneled EAP-TLS, (and some additional patches),
  it gets to the point where the server is looking for a client
certificate, and doesn't get one.  In response to the server ACK,
wpa_supplicant just sends another ACK... and the cycle repeats until it
gives up.

  I don't know much about EAP-TLS inside of PEAP... maybe there isn't
supposed to be a client certificate?

  Alan DeKok.