Hi Joe, > On 7 Oct 2019, at 02:42, Joseph Salowey <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 > 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
