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

[Mohit Sethi M <[e-mail]>]

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 draft-ietf-emu-eap-tls13<https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-07> draft if that is what the general consensus is.

--Mohit

On 10/10/19 12:24 PM, Eliot Lear wrote:
Hi Mohit,

On 10 Oct 2019, at 09:55, Mohit Sethi M <[e-mail]<mailto:[e-mail]>> 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.

*Architecturally* I am angling toward code impact.  Is there a fundamental issue with TLS-PSK or is it just EAP-TLS-PSK?  This is a matter of how one would want to address the problem in OpenSSL/GNUTLS/TinySSL/WolfSSL and what the calling interfaces should be.

I want to stress again: whether it’s PSK or public key is conceptually not that different here.  There is some potential theft protection in public key mechanisms, but only if a real TEE is used.  We’re not seeing that as much as we would like yet, but it may make sense to aim in that direction.

Thus one potential outcome of this discussion is: PSK is just bad, and never use it, regardless of EAP or other.  Another potential outcome is the opposite.  And then there are some states in between.

Eliot

--Mohit

On 10/10/19 10:44 AM, John Mattsson 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 <[e-mail]><mailto:[e-mail]>
Date: Thursday, 10 October 2019 at 09:14
To: Joseph Salowey <[e-mail]><mailto:[e-mail]>
Cc: John Mattsson <john.mattsson=[e-mail]><mailto:john.mattsson=[e-mail]>, "[e-mail]"<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>, EMU WG <[e-mail]><mailto:[e-mail]>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: <[e-mail]><mailto:[e-mail]>
Resent to: John Mattsson <[e-mail]><mailto:[e-mail]>, <[e-mail]><mailto:[e-mail]>
Resent date: Thu, 10 Oct 2019 00:14:49 -0700 (PDT)

Hi Joe,


On 7 Oct 2019, at 02:42, Joseph Salowey <[e-mail]<mailto:[e-mail]>> 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=[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, 18 September 2019 at 15:21
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, EMU WG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: <[e-mail]<mailto:[e-mail]>>
Resent to: John Mattsson <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>
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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/emu






_______________________________________________
Emu mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/emu