Hello all. 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. The code of the eappeap_success method in the peap.c file is the following: . . . tlv_packet[10] = EAP_TLV_SUCCESS; /* New code */ tlv_packet[11] = 0x80; /* mandatory AVP */ tlv_packet[12] = EAP_TLV_VENDOR_SPECIFIC; len_aux = 4 + mydata_len; tlv_len = htons(len_aux); ptr++; // [3] ptr++; // [4] ptr++; // [5] ptr++; // [6] ptr++; // [7] ptr++; // [8] ptr++; // [9] ptr++; // [10] ptr++; // [11] ptr++; // [12] ptr++; // [13] memcpy(ptr, &tlv_len, 2); tlv_packet[15] = 0; /* Vendor ID: Fixed to 0*/ tlv_packet[16] = 0; /* Vendor ID */ tlv_packet[17] = 0; /* Vendor ID */ tlv_packet[18] = 1; /* Vendor ID */ int i; for (i = 0; i < mydata_len; i++) {tlv_packet[19 + i] = mydata[i]; } /* End new code */ (tls_session->record_plus)(&tls_session->clean_in, tlv_packet, packet_len); . . . 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. Then the client replies with a PEAP message without data (0x020b00061900). 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. 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 ... Can anybody help me with this problem and tell me why the second fragment is not correct? Thanks in advance. -- ----------------------------- Manuel Sanchez Cuenca Departamento de Ingenieria de la Informacion y las Comunicaciones Facultad de Informatica. Universidad de Murcia Campus de Espinardo - 30080 Murcia (SPAIN) Tel.: +34-968-364644 Fax: +34-968-364151 email: msc@dif.um.es | manuelsc@um.es url: http://libra.inf.um.es/~lolo
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.
Finally I have solved the problem including this code in eaptls_ack_handler (eap_tls.c): case handshake: if (tls_session->info.handshake_type == finished) { DEBUG2(" rlm_eap_tls: ack handshake is finished"); if (tls_session->dirty_out.used == 0) return EAPTLS_SUCCESS; //return EAPTLS_SUCCESS; } DEBUG2(" rlm_eap_tls: ack handshake fragment handler"); /* Fragmentation handler, send next fragment */ return EAPTLS_REQUEST; In this way, if there is more data to send, a new fragment is sent. But... Alan DeKok escribió:
Yes. The TLS code inside of FreeRADIUS assumes that once the initial handshake is completed, that there is no more data to send.
Is this correct? I mean, why freeradius suppose that only in the initial handshake are necessary fragments, the specification of PEAP says somethig about it?
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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
-- ----------------------------- Manuel Sanchez Cuenca Departamento de Ingenieria de la Informacion y las Comunicaciones Facultad de Informatica. Universidad de Murcia Campus de Espinardo - 30080 Murcia (SPAIN) Tel.: +34-968-364644 Fax: +34-968-364151 email: msc@dif.um.es | manuelsc@um.es url: http://libra.inf.um.es/~lolo
Manuel Sánchez Cuenca wrote:
Finally I have solved the problem including this code in eaptls_ack_handler (eap_tls.c): ...
That looks reasonable.
Yes. The TLS code inside of FreeRADIUS assumes that once the initial handshake is completed, that there is no more data to send.
Is this correct?
Until now, yes.
I mean, why freeradius suppose that only in the initial handshake are necessary fragments, the specification of PEAP says somethig about it?
The specification of PEAP doesn't say much about that, so far as I recall. Alan DeKok.
Alan DeKok escribió:
Yes. The TLS code inside of FreeRADIUS assumes that once the initial handshake is completed, that there is no more data to send.
Is this correct?
Until now, yes.
But this assumption limits the protocol.
I mean, why freeradius suppose that only in the initial handshake are necessary fragments, the specification of PEAP says somethig about it?
The specification of PEAP doesn't say much about that, so far as I recall.
When the specification of PEAP talks about fragmentation, it says: "By including support for fragmentation and reassembly within PEAPv2, methods leveraging PEAPv2 do not need to support this on their own." And in the way fragmentation is implemented in freeradius, it is not allowed. I mean, if fragmentation is allowed only in the handshake, new protocols leveraging PEAP in freeradius need to implement fragmentation too.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
-- ----------------------------- Manuel Sanchez Cuenca Departamento de Ingenieria de la Informacion y las Comunicaciones Facultad de Informatica. Universidad de Murcia Campus de Espinardo - 30080 Murcia (SPAIN) Tel.: +34-968-364644 Fax: +34-968-364151 email: msc@dif.um.es | manuelsc@um.es url: http://libra.inf.um.es/~lolo
Manuel Sánchez Cuenca wrote:
But this assumption limits the protocol.
Again, it has worked until now. The limitation affects only changes that no one has made, and no one has deployed. So it's not really much of a limitation, is it? If you're adding new functionality then yes, this limitation has to be removed.
When the specification of PEAP talks about fragmentation, it says:
"By including support for fragmentation and reassembly within PEAPv2,
Ah. The server implements PEAPv0, not PEAPv2.
And in the way fragmentation is implemented in freeradius, it is not allowed. I mean, if fragmentation is allowed only in the handshake, new protocols leveraging PEAP in freeradius need to implement fragmentation too.
The current code also limits the implementation to PEAPv0. So? When you add the code that implements PEAPv2, you have to update a bunch of code. I fail to see why this is a surprise. Alan DeKok.
participants (2)
-
Alan DeKok -
Manuel Sánchez Cuenca