FreeRADIUS EAP-TLS issues

[Jouni Malinen]

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