Mohit Sethi M mohit.m.se...@ericsson.com wrote: I think these are mostly TLS questions that would not be specific for EAP-TLS-PSK
> For example: the current TLS 1.3 spec requires external PSKs to be > provisioned for a specific hash function. Yes, but if there is no specific hash function, SHA-256 is used as a default. >Then there is also the discussion on how does a server handle external PSK vs. >PSK for resumption? They will clearly be >in different parts of the stack: >external PSKs with the EAP server and resumptions PSKs with the TLS server >library. >Also, should a server issue resumption PSKs when the original authentication >is based on an external PSK. The only >benefit would be that it would make >tracking of peers/clients much harder. Yes, but I do not see how EAP would differ from any other TLS deployment with external PSK. >There is ongoing work in the TLS working group but the question is how long >should we wait: >https://tools.ietf.org/html/>draft-ietf-tls-external-psk-importer-01 I see no reason to wait for that draft. What draft-ietf-tls-external-psk-importer does is to allow a single external PSK to be used to negotiate both TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384. Most IoT would not want to negotiate AES-256 and SHA-384, and those who want (like e.g. US government devices using the CSNA suite) would probably not want to negotiate AES-128 and SHA-256. draft-ietf-tls-external-psk-importer fills a gap in the TLS 1.3 protocol, but is not a game changer in any way. John From: Mohit Sethi M <mohit.m.se...@ericsson.com> Date: Thursday, 10 October 2019 at 10:03 To: Eliot Lear <l...@cisco.com>, John Mattsson <john.matts...@ericsson.com> Cc: "draft-ietf-emu-eap-tl...@ietf.org" <draft-ietf-emu-eap-tl...@ietf.org>, John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org>, EMU WG <emu@ietf.org> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 I wouldn't say that TLS 1.3 is wrong but there is some stuff that could benefit from further clarification. For example: the current TLS 1.3 spec requires external PSKs to be provisioned for a specific hash function. Then there is also the discussion on how does a server handle external PSK vs. PSK for resumption? They will clearly be in different parts of the stack: external PSKs with the EAP server and resumptions PSKs with the TLS server library. Also, should a server issue resumption PSKs when the original authentication is based on an external PSK. The only benefit would be that it would make tracking of peers/clients much harder. There is ongoing work in the TLS working group but the question is how long should we wait: https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01 --Mohit On 10/10/19 10:51 AM, Eliot Lear wrote: 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<mailto: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. 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<mailto:Emu@ietf.org> https://www.ietf.org/mailman/listinfo/emu
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
