Subject: [Emu] RFC5216 - L-Flag in the fragment packets (fwd)

From: Bernard Aboba <[email-masked]>
Date: Tue, 5 May 2009 04:10:59 -0700

________________________________________
 From: Murat Sezgin [[email-masked]]
 Sent: Tuesday, May 05, 2009 3:27 AM
 To: Dan Simon; Bernard Aboba; Ryan Hurst
 Subject: RFC5216 - L-Flag in the fragment packets
 
 Hi Mr.Simon,  Mr.Aboba and Mr.Hurst
 
 In the “2.1.5 Fragmentation” section of the RFC5216, it is written that “The L flag is set to indicate the presence of the four-octet TLS Message Length field, and MUST be set for the first fragment of a fragmented TLS message or set of messages”. Here, it is not clear that the other fragments must or must not include this L-flag set. On the other hand, the RFC5281-- EAP-TTLS, indicates that “Fragments other than the first MUST NOT have the L bit set”.  Is there a L-flag inconsistency between the EAP-TLS and EAP-TTLS fragments. Do you think you need to explicitly put the same statement in the RFC5216?
 
 In the FreeRadius implementation, there is an option called “include_length” in the tls module configuration section of eap.conf file, its default value is set to “yes”, and with this configuration the server sends the L-flag in each fragment, this is not consistent with the TTLS RFC. FreeRadius’s TTLS implementation also uses this option in its TLS handshake phase.

 Regards,
 Murat Sezgin
 Software Engineer
 www.ubicom.com

---

From: Jouni Malinen <[email-masked]>
Date: Tue, 5 May 2009 15:25:32 +0300

>  In the “2.1.5 Fragmentation” section of the RFC5216, it is written that “The L flag is set to indicate the presence of the four-octet TLS Message Length field, and MUST be set for the first fragme…

The situation with the L-Flag in EAP methods that use TLS (TLS, PEAP,
TTLS, FAST) is actually even more confusing than this particular detail
might suggest. For example, PEAPv0 seems to require that the TLS Message
Length is included even in unfragmented frames in Phase 1 (however, it
is not allowed to be included in Phase 2!) or at least a deployed and
commonly used server requires such behavior to interoperate properly for
certain cases.

Taken into account that many implementations share code between
EAP-TLS/PEAP/TTLS/FAST, it would be great if these methods were to use
the same rules for fragmentation. Alas, I do not think that this would
be feasible due to conflicting requirements in the specifications and/or
deployed implementations.. Anyway, it would be great if all new RFCs
touching this area have clear statements describing the exact and
consistent (at least within the EAP method) use of the TLS Message
Length field for all frames, so that we could hopefully avoid getting
even more variance on how this needs to be processed in the future.

>  In the FreeRadius implementation, there is an option called “include_length” in the tls module configuration section of eap.conf file, its default value is set to “yes”, and with this configuratio…

So far, I've never needed to include the TLS Message Length in any other
frame than the first fragmented. However, I have had to implement
workarounds to allow the non-fragmented frames to get special handling
in some cases, i.e., to get the TLS Message Length added into them (both
for all frames and also with the difference in Phase 1 vs. Phase 2 as
described above). Obviously, this is not really a desired situation
since it takes considerable amount of time to come up with all the
needed workarounds to interoperate with existing implementations.

-- 
Jouni Malinen                                            PGP id EFC895FA

---

From: Alan DeKok <[email-masked]>
Date: Thu, 07 May 2009 10:48:11 +0200

Bernard Aboba wrote:
>  In the FreeRadius implementation, there is an option called
> “include_length” in the tls module configuration section of eap.conf
> file, its default value is set to “yes”, and with this configuration the
> server sends the L-flag in each fragment, this is not consistent with
> the TTLS RFC. FreeRadius’s TTLS implementation also uses this option in
> its TLS handshake phase.

  All I can say is that it's inter-operable with everything out there.

  In any case, future releases will have this behavior configurable.

  Alan DeKok.