Welcome and thanks for your comments Oleg!
slon v sobstvennom palto <[email protected]>; 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
[email protected]
https://www.ietf.org/mailman/listinfo/emu
