I do think this is where we can make TEAP’s sweet spot. But we should avoid differences in TLS implementations between TEAP and EAP-TLS. That just complicates libraries. And it’s for that same reason that I’m just a bit nervous about us constraining TLS 1.3. Put another way: before we do so we have to answer this question: what is so different about EAP than other TLS applications? If the answer is “nothing” for a particular case, then either we have it wrong or TLS 1.3 has it wrong, and we should sort that.
Eliot > On 10 Oct 2019, at 09:44, John Mattsson <john.matts...@ericsson.com> 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 >> <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 >>> <https://www.ietf.org/mailman/listinfo/emu> >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org <mailto:Emu@ietf.org> >> https://www.ietf.org/mailman/listinfo/emu
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
