On Mar 4, 2022, at 1:48 PM, Heikki Vatiainen <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/emu
