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.


> On 10 Oct 2019, at 09:44, John Mattsson <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 
>> <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 
>>> <https://www.ietf.org/mailman/listinfo/emu>
>> _______________________________________________
>> Emu mailing list
>> Emu@ietf.org <mailto:Emu@ietf.org>
>> https://www.ietf.org/mailman/listinfo/emu

Attachment: signature.asc
Description: Message signed with OpenPGP

Emu mailing list

Reply via email to