Hi,

We are running freeradius, version 1.1.7, on Fedora.  We are testing WPA2/EAP-TLS authentication, with large certificate chains (just under 64K in PEM format).  Some individual cert sizes in the chain approach 10K in DER format.  If the chain is small enough to fit in a single TLS message, authentication works fine.  But is the chain is greater than 16,384 bytes, eap-tls fails.  Looking at a packet trace, freeradius does not send a message above 16.438 bytes.  Instead of breaking it up into different records, it attempts to send it in one TLS record, with fragments that are too large. 

Wireshark trace of Radius traffic shows the following:

            TLS      Server Hello, Certificate, Certificate Request {Malformed Packet}

                        Frame: 1239, payload 16384-17407 (1024 bytes)

                                    [Fragment overlap:  True]

                                    {Fragment too long:  True] 

This frame pattern repeats with later fragments …

Per RFC’s 2716 and 5216, it seems freeradius should brake a single TLS message (larger than one 16,384 byte record can support) into multiple TLS records. 

We could not find anything on this problem in the FAQ or user lists.  Can someone tell us what we are doing wrong, or is this a bug which hasn’t been reports, since this large cert chain is rare?  We will update to the latest freeradius release.

Thanks,
Brian Smith

RFC’s  2716 and 5216 - EAP-TLS Authentication Protocol

Section 2.1.5.  Fragmentation

   A single TLS record may be up to 16384 octets in length, but a TLS

   message may span multiple TLS records, and a TLS certificate message

   may in principle be as long as 16 MB.  The group of EAP-TLS messages

   sent in a single round may thus be larger than the MTU size or the

   maximum Remote Authentication Dail-In User Service (RADIUS) packet

   size of 4096 octets.  As a result, an EAP-TLS implementation MUST

   provide its own support for fragmentation and reassembly.  However,

   in order to ensure interoperability with existing implementations,

   TLS handshake messages SHOULD NOT be fragmented into multiple TLS

   records if they fit within a single TLS record.

   In order to protect against reassembly lockup and denial-of-service

   attacks, it may be desirable for an implementation to set a maximum

   size for one such group of TLS messages.  Since a single certificate

   is rarely longer than a few thousand octets, and no other field is

   likely to be anywhere near as long, a reasonable choice of maximum

   acceptable message length might be 64 KB.