PEAP fragmentation

[Alan DeKok]

Manuel Sánchez Cuenca wrote:
> I'm modifying the PEAP module included in freeradius 1.1.4 to send in
> the last message of the protected channel some information to the
> client. Specifically, I'm including a new TLV in the eappeap_success
> message.

  Ok...

> The code of the eappeap_success method in the peap.c file is the following:
...
>        ptr++; // [3]
...
>        ptr++; // [13]

  Why not just "ptr += 10"?

>        tlv_packet[18] = 1;     /* Vendor ID */
> 
>        int i;

  That's not C.

>        for (i = 0; i < mydata_len; i++) {tlv_packet[19 + i] = mydata[i];  }

  Why not use "memcpy"?

> When the data to be sent (mydata) is small, the protocol works ok, but
> when the the amount of data is big, there are some problems. In this
> situation, the server sends the first fragment with the bits L and M
> sets to 1.

  As it should, I think.

> Then the client replies with a PEAP message without data
> (0x020b00061900).

  That's a TLS ACK message.

> Now, the server sends something that doesn't seem the
> right data, because in one test, the total size of the fragments was
> 1029, the first fragment size was 1024, and the second one (with must be
> 5) was 37.

  The fragment that the server sends?

> When the fragment ACK is received, he log of freeradius shows:
> 
>       ...
>       rlm_eap_tls: Received EAP-TLS ACK message
>          rlm_eap_tls: ack handshake fragment handler
>          rlm_eap_tls: ack handshake is finished
>          eaptls_verify returned 3
>          eaptls_verify returned 3
>          rlm_eap_peap: EAPTLS_SUCCESS

  Yes.  The TLS code inside of FreeRADIUS assumes that once the initial
handshake is completed, that there is no more data to send.

> Can anybody help me with this problem and tell me why the second
> fragment is not correct?

  See the code that prints out "ack handshake is finished".  It's
terminating the EAP session earlier than you expect.  You'll need to
modify the code to have it send more data.

  Alan DeKok.