> From: Murat Sezgin [msez...@ubicom.com] > 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?
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 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. 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 _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
