Mohit Sethi M mohit.m.se...@ericsson.com wrote: > @Elliot: I understand your discomfort with constraining TLS 1.3. But there is > clearl precedent. The original EAP-TLS specification in RFC 5216 > (https://tools.ietf.org/html/rfc5216) has no mention of PSKs.
That was quite different. When EAP-TLS (RFC 2716) was first published, there was no PSK mode in TLS at all. When RFC 5216 was published, TLS-PSK was a quite recent and not so well-supported extension. Also TLS 1.2 (RFC 5246) has no mention of PSKs. TLS 1.3 embraces PSK because the demand from IoT and makes it part of the main specification. From: Mohit Sethi M <mohit.m.se...@ericsson.com> Date: Thursday, 10 October 2019 at 09:55 To: John Mattsson <john.matts...@ericsson.com>, Eliot Lear <l...@cisco.com>, Joseph Salowey <j...@salowey.net> Cc: John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org>, "draft-ietf-emu-eap-tl...@ietf.org" <draft-ietf-emu-eap-tl...@ietf.org>, EMU WG <emu@ietf.org> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 Hi, Speaking purely as an individual contributor. I agree that this is a use-case we should address. I am open to discussions whether it should be done in this draft or separately and whether we should have a separate method type or use the same. @Elliot: I understand your discomfort with constraining TLS 1.3. But there is clearl precedent. The original EAP-TLS specification in RFC 5216 (https://tools.ietf.org/html/rfc5216) has no mention of PSKs. --Mohit On 10/10/19 10:44 AM, John Mattsson wrote: Hi Eliot, I agree that the question boils down to IoT. There are currently a lot of IoT systems using PSK, and many of them will likely want to stay on PSK, rather than migrating to RPK. Using a protocol with PFS is nowadays recommended practice. EAP-PSK does not provide PFS, and EAP-PWD is not suitable for IoT. I strongly think we need an EAP method with PSK + PFS for IoT, and the easiest way to achieve that seems to be EAP-TLS-PSK. Cheers, John From: Eliot Lear <l...@cisco.com><mailto:l...@cisco.com> Date: Thursday, 10 October 2019 at 09:14 To: Joseph Salowey <j...@salowey.net><mailto:j...@salowey.net> Cc: John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org><mailto:john.mattsson=40ericsson....@dmarc.ietf.org>, "draft-ietf-emu-eap-tl...@ietf.org"<mailto:draft-ietf-emu-eap-tl...@ietf.org> <draft-ietf-emu-eap-tl...@ietf.org><mailto:draft-ietf-emu-eap-tl...@ietf.org>, EMU WG <emu@ietf.org><mailto:emu@ietf.org> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 Resent from: <alias-boun...@ietf.org><mailto:alias-boun...@ietf.org> Resent to: John Mattsson <john.matts...@ericsson.com><mailto:john.matts...@ericsson.com>, <mo...@piuha.net><mailto:mo...@piuha.net> Resent date: Thu, 10 Oct 2019 00:14:49 -0700 (PDT) Hi Joe, On 7 Oct 2019, at 02:42, Joseph Salowey <j...@salowey.net<mailto:j...@salowey.net>> wrote: There is a TLS working group draft on importing external PSKs for use with TLS - https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01. This draft can mitigate some of the issues with using external PSKs. My suggesting is to leave the draft as is and deal with external PSKs as an update to EAP-TLS 1.3 or as a separate method. Before we nail this down, it seems like we need to have a discussion about how best to onboard wired IoT devices in particular from an on-prem view. The issue here is that EAP-TLS-PSK is useful for that purpose, as we discussed. Now there is nothing particularly special about PSK and we could run with a naked public key pair as well in 1.3, but we have to choose something. The fundamental question is what does a manufacturer stamp into the device and what is placed on a label. We have a running example of DPP doing this for wireless with public key code, but that doesn’t get us to proper onboarding for wired – the signaling just isn’t there. Also, maybe it’s me, but I remain uncomfortable about this group constraining TLS 1.3. Eliot Is the current published version up to date with the rest of the comments? Thanks, Joe On Fri, Sep 20, 2019 at 3:42 AM John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org<mailto:40ericsson....@dmarc.ietf.org>> wrote: Hi Alan, I added references to RFC 8446 Section 8.1, and 8.2, and 4.2.11. Agree that they are good to point out. I am not sure about the other suggestions, I am hesitant to discuss anything detailed about TLS 1.3 that does not have a specific connection to EAP-TLS or are useful for users of EAP-TLS. My feeling is that adding some extension, but not other would be even more confusing. The diagrams are there to show the message flows, which have a strong connection to the EAP state machine. For other details I think implementors have to read RFC 8466. /John -----Original Message----- From: Alan DeKok <al...@deployingradius.com<mailto:al...@deployingradius.com>> Date: Wednesday, 18 September 2019 at 15:21 To: "draft-ietf-emu-eap-tl...@ietf.org<mailto:draft-ietf-emu-eap-tl...@ietf.org>" <draft-ietf-emu-eap-tl...@ietf.org<mailto:draft-ietf-emu-eap-tl...@ietf.org>>, EMU WG <emu@ietf.org<mailto:emu@ietf.org>> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 Resent from: <alias-boun...@ietf.org<mailto:alias-boun...@ietf.org>> Resent to: John Mattsson <john.matts...@ericsson.com<mailto:john.matts...@ericsson.com>>, <mo...@piuha.net<mailto:mo...@piuha.net>> Resent date: Wednesday, 18 September 2019 at 15:21 Just re-reading the text on PSK, I noticed a few things. The text in Section 2.1.2 talks about PSK, the session ticket, and a "key_share" extension. The accompanying diagram doesn't include any of those. I suggest updating the diagram to include them. As a related note, if the PSK *is* in the resumption cache, but the key is wrong, the cache entry should not be discarded. Otherwise an attacker can disable caching for *all* users. This issue could be clearer in this document. Perhaps it would be useful to add a short note in Section 5 about security of resumption. It should reference RFC 8446 Section 8.1, and 8.2, which discuss this issue. Also, Section 4.2.11 of that document has an "Implementor's note:" which is important. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org<mailto:Emu@ietf.org> https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org<mailto:Emu@ietf.org> https://www.ietf.org/mailman/listinfo/emu
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
