Re: [Emu] TEAP errata 5770

On Tue, Oct 8, 2019 at 10:46 PM Joseph Salowey wrote: > Based on Jouni's analysis the derivation of the S-IMCKs is not well > specified. To me it looks like the solution to handle an arbitrary number > of methods that may or may not make an EMSK available would be fairly > complex. > > I think

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

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,

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

From: Emu On Behalf Of John Mattsson Sent: 10 October 2019 09:30 To: Mohit Sethi M ; Eliot Lear Cc: draft-ietf-emu-eap-tl...@ietf.org; John Mattsson ; EMU WG Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 Mohit Sethi M

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

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

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

Re: [Emu] TEAP errata 5770

Just one comment: TEAP does not require an inner method, and indeed for IoT it is not necessary. Eliot > On 9 Oct 2019, at 07:46, Joseph Salowey wrote: > > Based on Jouni's analysis the derivation of the S-IMCKs is not well > specified. To me it looks like the solution to handle an

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.

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

Hi Mohit, > On 10 Oct 2019, at 09:55, Mohit Sethi M 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

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

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

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

Hi Elliot, PSK and certificates have different security properties. That being said, both are needed. As I stated earlier: a modern EAP method with PSK is needed and TLS-PSK is the right choice. I am happy to have it in the current

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

Yes, but I do not see how EAP would differ from any other TLS deployment with external PSK. Can you give an example of an existing TLS 1.3 deployment that offers both resumption PSKs and external PSKs? EAP-TLS would not be different from other TLS deployments with external PSKs. However, so

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

Mohit Sethi M mailto:mohit.m.se...@ericsson.com wrote: > Can you give an example of an existing TLS 1.3 deployment that offers both > resumption PSKs and external PSKs? Don’t know if it is deployed anywhere, but OpenSSL supports resumption of PSK sessions. There was a bug that stopped it from