Re: [Emu] Working Group Last Call for TLS-based EAP types and TLS 1.3
On Mar 4, 2022, at 1:48 PM, Heikki Vatiainen wrote: > 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 I would argue that EAP-TTLS with only a client certificate doesn't make sense. I'm not sure why it's in RFC 5281. If you want to only use a client certificate, you should just use EAP-TLS. I suggest for this document that we just forbid the case of using only a client certificate with TTLS. > 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. Thanks. I'll add some text here. > 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. Agreed. I'll add some text. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Working Group Last Call for TLS-based EAP types and TLS 1.3
On Fri, 18 Feb 2022 at 19:18, Joseph Salowey 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
