From: Emu <emu-boun...@ietf.org> On Behalf Of John Mattsson Sent: 10 October 2019 09:30 To: Mohit Sethi M <mohit.m.se...@ericsson.com>; Eliot Lear <l...@cisco.com> Cc: 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
Mohit Sethi M mohit.m.se...@ericsson.com<mailto: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. [ofriel] I wouldn’t say that the only benefit is to make tracking of peers/clients harder. A server could use PSK for initial auth, and then issue local credentials for the thing within the EAP tunnel. The thing can now be let on the network immediately, and on subsequent reboots/reauths/reconnects can use its locally issued credential. In either scenario (initial bootstrap or subsequent reauth using the local credential), the server may issue resumption PSKs. Yes, but I do not see how EAP would differ from any other TLS deployment with external PSK. [ofriel] Agree. I do not see why EAP should place artificial constraints on TLS. I cannot see a good reason why an EAP-TLS implementation couldn’t be coded to have the same flexibility as any other TLS1.3 server. A particular EAP implementation could of course choose not to support authentication PSKs, but it seems a mistake to prohibit this in the specification. >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<https://tools.ietf.org/html/%3edraft-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<mailto:mohit.m.se...@ericsson.com>> Date: Thursday, 10 October 2019 at 10:03 To: Eliot Lear <l...@cisco.com<mailto:l...@cisco.com>>, John Mattsson <john.matts...@ericsson.com<mailto:john.matts...@ericsson.com>> Cc: "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>>, John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org<mailto:john.mattsson=40ericsson....@dmarc.ietf.org>>, EMU WG <emu@ietf.org<mailto: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
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
