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.