Hi John, >Should draft-ietf-emu-eap-tls13-04 just copy the sentence from RFC 5281 or do the group want something different?
I remember that some EAP-TLS/PEAP clients rejected not fragmented messages without L bit set, probably due to their wrong interpretation of EAP-TLS RFC. Would it worth to say something like "Implementation SHOULD accept unfragmented messages with and without L bit set" in addition to copying the sentence above from RFC 5281? Cheers, Oleg On Sun, Mar 10, 2019 at 2:39 PM John Mattsson <john.matts...@ericsson.com> wrote: > Welcome and thanks for your comments Oleg! > > slon v sobstvennom palto <slonvpa...@gmail.com>; wrote: > > >Per my experience the existing fragmentation method described in EAP-TLS > >RFC 5216 serves good for all fragmentation needs. The method is reused by > >PEAP, EAP-FAST, TEAP and EAP-TTLS. There's an ambiguity in EAP-TLS RFC > that > >doesn't specify whether a not-fragmented message should have the L bit and > >the 4 octets length field so different peers treat it differently. > However, > >for example, EAP-TTLS RFC closed it tightly saying that even a > >single-fragment message should have it nevertheless on its redundancy. > > I cannot find anything in EAP-TTLS (RFC 5281) saying that the L bit should > be set. As you have noticed, EAP-TLS (RFC 5216) does not say anything about > the L bit in unfragmented messages and my understanding is that the > ambiguity is if unfragmented messages can (not should) have the L bit set.. > As far as I can see, EAP-TTLS (RFC 5281) states that unfragmented messages > MAY set the L bit. > > RFC 5281 Section 9.2.2: > > “Unfragmented messages MAY have the L bit set and include the > length of the message (though this information is redundant).” > > I looked through the other TLS-based EAP methods (both RFCs and drafts) > and none of them seems to say anything new about the L bit. > draft-ietf-emu-eap-tls13 should clarify any ambiguity. > > Should draft-ietf-emu-eap-tls13-04 just copy the sentence from RFC 5281 or > do the group want something different? > > Cheers, > John > >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu