> -----Original Message----- > From: Emu <emu-boun...@ietf.org> On Behalf Of Joseph Salowey > Sent: 31 October 2019 04:45 > To: Alan DeKok <al...@deployingradius.com> > Cc: draft-ietf-emu-eap-tl...@ietf.org; John Mattsson > <john.mattsson=40ericsson....@dmarc.ietf.org>; Michael Richardson > <m...@sandelman.ca>; EMU WG <emu@ietf.org> > Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 > > > > On Wed, Oct 30, 2019 at 4:12 AM Alan DeKok > <mailto:al...@deployingradius.com> wrote: > On Oct 30, 2019, at 5:02 AM, Eliot Lear <mailto:l...@cisco.com> wrote: > > A fair argument, if it can be made, and I am not convinced it has been fully > expressed, is the idea that there is no context by which one can separate fast > restart and initial authentication. This is Alan’s concern. I’m not saying > it’s > without merit, but what I cannot yet see is whether it is an implementation > or a > protocol matter. > > I believe it's a protocol matter. In TLS 1.3, PSK handshakes are the same > as > resumption handshakes. > > It's not clear to me how this issue was addressed when using TLS 1.3 with > HTTPS. But I do believe it's an issue there, too. > > [Joe] Can you elaborate on what the issue is? I think most TLS deployments > operate in either a certificate based mode or a PSK mode, but not both at the > same time.
[ofriel] TLS1.3 explicitly does not allow both PSK and certs simultaneously. draft-ietf-tls-tls13-cert-with-extern-psk does, but that’s Experimental. I don't think TLS with extern PSK is really intended for Web/Browser HTTPS connections. Its more for devices/things which are preprovisioned with the extern PSK. In TLS1.3, by design the protocol does not differentiate between resumption and external PSKs, and says nothing about PSK ID format, as commented here https://mailarchive.ietf.org/arch/msg/tls/Q5K8HSPPgLRojQwXbV4ZTIxBIH0 , https://mailarchive.ietf.org/arch/msg/tls/X_z8pc3oS2Au7KajjMhlWhP1UPc And its application specific how the two are differentiated, the spec says nothing about it: https://mailarchive.ietf.org/arch/msg/tls/btLnZERYv8GJJ2PFUksjNsDyv8o I still don't get why EAP-TLS1.3 should place restrictions on use of TLS1.3. Surely it should be an EAP server implementation decision on whether to support that feature or not, but we should not preclude a specific EAP server implementation from supporting extern PSK by disallowing it in the spec. If a particular EAP server does not want to support extern PSK - that’s fine. > > As an additional note, I believe it's also important that > draft-dekok-emu-tls- > eap-types be published at the same time as the EAP-TLS document. The only > unknown there is FAST and TEAP. I'm happy to remove them from the > document. > > But at this point it's not even a WG document. There's not even consensus > that > the document necessary, which surprises me rather a lot. Because password- > based EAP methods are *much* more wide-spread than EAP-TLS. > > If the IETF publishes EAP-TLS without simultaneously rev'ing TTLS and PEAP, > it > will not only look bad, it will *be* bad. And the industry press will > (rightfully) > lambast the standards process. > > [Joe] We need people to contribute to the document. If we are going to > publish > a document through the working group it needs to at least to include TEAP. I > know there are folks on this list who are implementing. They need to step up > and help with this document and the TEAP errata. > > Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
