On Wed, Nov 21, 2007 at 11:07:16AM +0100, Alan DeKok wrote:
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 still do. How large certificates are you using? I'm hitting the fragment limit in phase 2 and the bug is triggered when sending the second fragment of the message that includes server certificate.
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.
I don't think this is the same issue.
The phase 2 data doesn't get fragmented in FreeRADIUS. The code doesn't handle that at all. It just gets truncated.
Not fragmenting phase 2 data sounds fine, but truncating it does not.. I would have expected this to be handled by fragmenting the long phase 2 data in phase 1.
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.
How did you configure wpa_supplicant? The network block should have something like this: identity="jkm" ca_cert="FreeRADIUS/ca.pem" ca_cert2="FreeRADIUS/ca.pem" client_cert2="FreeRADIUS/user.pem" private_key2="FreeRADIUS/user.pem" private_key2_passwd="whatever" phase2="auth=TLS"
I don't know much about EAP-TLS inside of PEAP... maybe there isn't supposed to be a client certificate?
The EAP-TLS inside the PEAP tunnel should look just like EAP-TLS without PEAP. I started looking into more details and it looks like the bug is in how FreeRADIUS handles fragmentation for the encrypted phase 2 data. The issue I'm seeing is triggered by eappeap_authenticate() processing status==EAPTLS_SUCCESS by adding an EAP packet into tls_session->clean_in while there is pending data (the second fragment) of the tunneled EAP-TLS message. This will make clean_in->used > 0 check in tls_handshake_send() trigger and this new EAP message from eappeap_authenticate() is written into TLS data (SSL_write()) and dirty_out is now corrupted by using the encrypted, incorrect EAP packet (BIO_read in tls_handshake_send() overrides the pending second fragment). I did not understand what the EAPTLS_SUCCESS processing in eappeap_authenticate() was supposed to do, but in practice, the current implementation is corrupting any PEAP phase 2 data that needs to be fragmented. I would assume that eappeap_authenticate() would need to be modified not to add this new EAP packet if there is pending data to be sent out, but I don't know how exactly this should be done. Anyway, I tested a quick hack that prevented clean_in from being modified here and that allowed the fragmented message to go through successfully (i.e., unmodified eapol_test received the frame and was able to decrypt it). This hack was not enough to handle further processing, so someone will need to figure out how to fix this properly. -- Jouni Malinen PGP id EFC895FA