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

[Eliot Lear <[e-mail]>]

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