I agree with Jouni that this is not an editorial change. In practice, TLS-based EAP methods are often built on the same code base. That means that an EAP-TTLS implementation that also supports EAP-TLS will typically behave as specified in RFC 5281, disallowing use of the 'L' flag in fragments other than the first one.
As a result, setting the 'L' flag in fragments other than the first one is probably not something that should be encouraged. -----Original Message----- From: Sean Turner [mailto:[email protected]] Sent: Tuesday, November 16, 2010 9:24 AM To: Pae, Min Cc: Jouni Malinen; Dan Simon; Bernard Aboba; Ryan Hurst; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [Emu] [Editorial Errata Reported] RFC5216 (2510) Did this ever get resolved? spt On 9/7/10 5:45 PM, Pae, Min wrote: > I agree that the text I proposed does not take other TLS based methods into > account. The AAA vendor that we are working with does include the length in > fragments other than the first, but we are working with them to get this > addressed. > > I classified the errata as editorial because I didn't think the proposed text > redefines anything about the protocol. If your comment about restricting the > inclusion of the length field in fragments other than the first is included, > you are probably correct that this shouldn't be classified as editorial. > > On Sep 7, 2010, at 12:05 AM, Jouni Malinen<[email protected]> wrote: > >> On Fri, Sep 3, 2010 at 11:51 PM, RFC Errata System >> <[email protected]> wrote: >>> http://www.rfc-editor.org/errata_search.php?rfc=5216&eid=2510 >> >>> Section: 3.1 >> >> Please note that similar language exists in other places of the >> document, too (2.1.5 and 3.2) and the same comments should apply to >> them. >> >>> Original Text >>> ------------- >>> The L bit (length included) 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. >>> >>> Corrected Text >>> -------------- >>> The L bit (length included) 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. The L bit MAY be included >>> in all fragments of a fragmented TLS message, but if included the >>> TLS Length MUST represent the entire length of the TLS message. >> >> This would still leave some potential uses of the L bit undefined. >> These two sentences cover only fragmented TLS messages. What about TLS >> messages that are not fragmented? >> >> It should also be noted that the proposed text would make RFC 5216 >> (EAP-TLS) inconsistent with RFC 5281 (EAP-TTLS) as far as >> fragmentation is concerned. I do not think that that would be a good >> idea since it is possible to share same implementation for handling >> fragmentation/reassembly of various TLS-based EAP methods (EAP-TLS, >> EAP-TTLS, EAP-PEAP, EAP-FAST). >> >> RFC 5281 disallows use of the L bit in the fragments other than the >> first one. In addition, it does actually cover the not fragmented >> message case, too: >> >> If there are multiple fragments, the first fragment MUST have the L >> bit set and include the length of the entire raw message prior to >> fragmentation. Fragments other than the first MUST NOT have the L >> bit set. Unfragmented messages MAY have the L bit set and include >> the length of the message (though this information is redundant). >> >> My preference would be for RFC 5216 to follow this design, but I don't >> think I would be willing to call this change "editorial".. Are there >> any known EAP-TLS implementations that actually use the L bit in >> fragments other than the first one? Would that interoperate with other >> EAP-TLS implementations? >> >> - Jouni > _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
