On Fri, 18 Feb 2022 at 19:18, Joseph Salowey <j...@salowey.net> wrote:
This is a working group last call for TLS-based EAP types and TLS 1.3. The > document is available here: > https://datatracker.ietf.org/doc/draft-ietf-emu-tls-eap-types/ > > Please review the document and provide comments by March 4, 2022 > Would it be useful to clarify the use of protected success indication, TLS application data 0x00, with resumption. I'm mainly thinking of EAP-TTLS which can end resumption very quickly. For example, this EAP-TTLS resumption sequence diagram shows how resumption typically happens: https://datatracker.ietf.org/doc/html/rfc5281#section-15.3 This EAP-TTLS RFC also mentions that this could happen with client certificate authentication too: https://datatracker.ietf.org/doc/html/rfc5281#section-7.6 The 3rd paragraph in Section 2 in the draft mentions 0x00 octet once and then refers to Section 3. It also could refer to Section 4 where new text could say something like this: If the EAP peer nor EAP server does not initiate an "inner tunnel" method, the EAP server must send 0x00 inside the TLS tunnel. Section 4 in the draft already states that RFC 9190 (EAP-TLS 1.3) defines how resumption is done. Strengthening this by mentioning 0x00 octet would make it clear to the implementation developers that they always have to expect and require at minimum 0x00 octet over a TLSv1.3 tunnel when an EAP-based TLS method is about to skip tunnelled authentication. As an example, wpa_supplicant recognises this and logs 'EAP-TTLS: ACKing EAP-TLS Commitment Message' during EAP-TTLS resumption. Thanks, Heikki -- Heikki Vatiainen h...@radiatorsoftware.com
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
