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

From: Joseph Salowey <[email-masked]>
Date: Sun, 6 Oct 2019 17:42:18 -0700

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.

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=
[email-masked]> 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 <[email-masked]>
> Date: Wednesday, 18 September 2019 at 15:21
> To: "[email-masked]" <[email-masked]>,
> EMU WG <[email-masked]>
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> Resent from: <[email-masked]>
> Resent to: John Mattsson <[email-masked]>, <[email-masked]>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 10 Oct 2019 09:14:30 +0200

Hi Joe,

> On 7 Oct 2019, at 02:42, Joseph Salowey <[email-masked]> 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

> On Fri, Sep 20, 2019 at 3:42 AM John Mattsson <john.mattsson=[email-masked] <mailto:[email-masked]>> 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
> 
> From: Alan DeKok <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, EMU WG <[email-masked] <mailto:[email-masked]>>
> Resent from: <[email-masked] <mailto:[email-masked]>>
> Resent to: John Mattsson <[email-masked] <mailto:[email-masked]>>, <[email-masked] <mailto:[email-masked]>>
>       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.
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/emu <https://www.ietf.org/mailman/listinfo/emu>

---

From: John Mattsson <[email-masked]>
Date: Thu, 10 Oct 2019 07:44:54 +0000

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

Hi Joe,

On 7 Oct 2019, at 02:42, Joseph Salowey <[email-masked]<mailto:[email-masked]>> 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.

Eliot

Thanks,

Joe

On Fri, Sep 20, 2019 at 3:42 AM John Mattsson <john.mattsson=[email-masked]<mailto:[email-masked]>> wrote:
Hi Alan,

/John

-----Original Message-----
From: Alan DeKok <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 18 September 2019 at 15:21
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, EMU WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: <[email-masked]<mailto:[email-masked]>>
Resent to: John Mattsson <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Resent date: Wednesday, 18 September 2019 at 15:21

      Alan DeKok.

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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 10 Oct 2019 09:51:21 +0200

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 <[email-masked]> wrote:
> 
> Hi Eliot,
> 
> From: Eliot Lear <[email-masked] <mailto:[email-masked]>>
> To: Joseph Salowey <[email-masked] <mailto:[email-masked]>>
> Cc: John Mattsson <john.mattsson=[email-masked] <mailto:john.mattsson=[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, EMU WG <[email-masked] <mailto:[email-masked]>>
>> On 7 Oct 2019, at 02:42, Joseph Salowey <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Mohit Sethi M <[email-masked]>
Date: Thu, 10 Oct 2019 07:55:07 +0000

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 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.

--Mohit

On 10/10/19 10:44 AM, John Mattsson wrote:
Hi Eliot,

Cheers,
John

From: Eliot Lear <[email-masked]><mailto:[email-masked]>
Date: Thursday, 10 October 2019 at 09:14
To: Joseph Salowey <[email-masked]><mailto:[email-masked]>
Cc: John Mattsson <john.mattsson=[email-masked]><mailto:john.mattsson=[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, EMU WG <[email-masked]><mailto:[email-masked]>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: <[email-masked]><mailto:[email-masked]>
Resent to: John Mattsson <[email-masked]><mailto:[email-masked]>, <[email-masked]><mailto:[email-masked]>
Resent date: Thu, 10 Oct 2019 00:14:49 -0700 (PDT)

Hi Joe,

Eliot

Thanks,

Joe

/John

-----Original Message-----
From: Alan DeKok <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 18 September 2019 at 15:21
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, EMU WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: <[email-masked]<mailto:[email-masked]>>
Resent to: John Mattsson <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Resent date: Wednesday, 18 September 2019 at 15:21

      Alan DeKok.

---

From: Mohit Sethi M <[email-masked]>
Date: Thu, 10 Oct 2019 08:03:31 +0000

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

On 10 Oct 2019, at 09:44, John Mattsson <[email-masked]<mailto:[email-masked]>> wrote:

Hi Eliot,

Cheers,
John

From: Eliot Lear <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 10 October 2019 at 09:14
To: Joseph Salowey <[email-masked]<mailto:[email-masked]>>
Cc: John Mattsson <john.mattsson=[email-masked]<mailto:john.mattsson=[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, EMU WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: <[email-masked]<mailto:[email-masked]>>
Resent to: John Mattsson <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Resent date: Thu, 10 Oct 2019 00:14:49 -0700 (PDT)

Hi Joe,

Eliot

Thanks,

Joe

/John

-----Original Message-----
From: Alan DeKok <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 18 September 2019 at 15:21
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, EMU WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: <[email-masked]<mailto:[email-masked]>>
Resent to: John Mattsson <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Resent date: Wednesday, 18 September 2019 at 15:21

      Alan DeKok.

---

From: John Mattsson <[email-masked]>
Date: Thu, 10 Oct 2019 08:07:34 +0000

> @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 o…

That was quite different. When EAP-TLS (RFC 2716) was first published, there was no PSK mode in TLS at all. When RFC 5216 was published, TLS-PSK was a quite recent and not so well-supported extension. Also TLS 1.2 (RFC 5246) has no mention of PSKs. TLS 1.3 embraces PSK because the demand from IoT and makes it part of the main specification.

From: Mohit Sethi M <[email-masked]>
Date: Thursday, 10 October 2019 at 09:55
To: John Mattsson <[email-masked]>, Eliot Lear <[email-masked]>, Joseph Salowey <[email-masked]>
Cc: John Mattsson <john.mattsson=[email-masked]>, "[email-masked]" <[email-masked]>, EMU WG <[email-masked]>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

Hi,

--Mohit

Cheers,
John

Hi Joe,

Eliot

Thanks,

Joe

/John

-----Original Message-----
From: Alan DeKok <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 18 September 2019 at 15:21
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, EMU WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: <[email-masked]<mailto:[email-masked]>>
Resent to: John Mattsson <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Resent date: Wednesday, 18 September 2019 at 15:21

      Alan DeKok.

---

From: John Mattsson <[email-masked]>
Date: Thu, 10 Oct 2019 08:30:09 +0000

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.

Yes, but I do not see how EAP would differ from any other TLS deployment with external PSK.

>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

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 <[email-masked]>
Date: Thursday, 10 October 2019 at 10:03
To: Eliot Lear <[email-masked]>, John Mattsson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, John Mattsson <john.mattsson=[email-masked]>, EMU WG <[email-masked]>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

--Mohit

Eliot

Hi Eliot,

Cheers,
John

Hi Joe,

Eliot

Thanks,

Joe

/John

-----Original Message-----
From: Alan DeKok <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 18 September 2019 at 15:21
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, EMU WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: <[email-masked]<mailto:[email-masked]>>
Resent to: John Mattsson <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Resent date: Wednesday, 18 September 2019 at 15:21

      Alan DeKok.

Emu mailing list

---

From: Eliot Lear <[email-masked]>
Date: Thu, 10 Oct 2019 11:24:39 +0200

Hi Mohit,

> On 10 Oct 2019, at 09:55, Mohit Sethi M <[email-masked]> 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 <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
>> From: Eliot Lear <[email-masked]> <mailto:[email-masked]>
>> To: Joseph Salowey <[email-masked]> <mailto:[email-masked]>
>> Cc: John Mattsson <john.mattsson=[email-masked]> <mailto:john.mattsson=[email-masked]>, "[email-masked]" <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>, EMU WG <[email-masked]> <mailto:[email-masked]>
>> Resent from: <[email-masked]> <mailto:[email-masked]>
>> Resent to: John Mattsson <[email-masked]> <mailto:[email-masked]>, <[email-masked]> <mailto:[email-masked]>

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Thu, 10 Oct 2019 09:25:11 +0000

From: Emu <[email-masked]> On Behalf Of John Mattsson
Sent: 10 October 2019 09:30
To: Mohit Sethi M <[email-masked]>; Eliot Lear <[email-masked]>
Cc: [email-masked]; John Mattsson <john.mattsson=[email-masked]>; EMU WG <[email-masked]>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

Mohit Sethi M [email-masked]<mailto:[email-masked]> wrote:

>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.

[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>

John

From: Mohit Sethi M <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 10 October 2019 at 10:03
To: Eliot Lear <[email-masked]<mailto:[email-masked]>>, John Mattsson <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, John Mattsson <john.mattsson=[email-masked]<mailto:john.mattsson=[email-masked]>>, EMU WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

--Mohit

Eliot

---

From: Mohit Sethi M <[email-masked]>
Date: Thu, 10 Oct 2019 10:38:17 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

Eliot

--Mohit

Cheers,
John

Hi Joe,

Eliot

Thanks,

Joe

/John

-----Original Message-----
From: Alan DeKok <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 18 September 2019 at 15:21
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, EMU WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: <[email-masked]<mailto:[email-masked]>>
Resent to: John Mattsson <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Resent date: Wednesday, 18 September 2019 at 15:21

      Alan DeKok.

---

From: Mohit Sethi M <[email-masked]>
Date: Thu, 10 Oct 2019 10:55:51 +0000

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 far EAP-TLS has only been used with certificates. If we are adding support for external PSKs, we should make sure that implementations know how to handle them.

--Mohit

---

From: John Mattsson <[email-masked]>
Date: Thu, 10 Oct 2019 16:18:47 +0000

> 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 working that was patched 12 months ago. 
https://github.com/openssl/openssl/issues/7433

---

From: Mohit Sethi M <[email-masked]>
Date: Fri, 11 Oct 2019 07:14:32 +0000

I am aware that Openssl has support for external PSK. The Selfie attack 
was demonstrated using this Openssl implementation: 
https://eprint.iacr.org/2019/347

However, the github issue you posted is still helpful. If I understand 
the resolution of this issue: Openssl will first check for a valid 
external PSK before checking for resumption PSKs.

I think we can include EAP-TLS-PSK without major changes to the current 
document. I only want to ensure that EAP-TLS-PSK does not leave any 
implementation ambiguities.

--Mohit

---

From: Michael Richardson <[email-masked]>
Date: Fri, 11 Oct 2019 13:04:21 +0200

Eliot Lear <[email-masked]> wrote:
    > 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.

okay, so why do you prefer PSK?

    > 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.

I don't understand this.
Are you saying that because it's wired, people do not expect to scan
anything?

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Eliot Lear <[email-masked]>
Date: Fri, 11 Oct 2019 13:25:26 +0200

> On 11 Oct 2019, at 13:04, Michael Richardson <[email-masked]> wrote:
> 
> 

I do not.  But we need to have *a* flow for on prem onboarding.  TLS-PSK is one approach, but there are others.  I just want a discussion before we nail this down, as I wrote.

> Are you saying that because it's wired, people do not expect to scan

No quite the opposite- I’m saying that there is at least one way to do this with Wifi, but no way to do this for wired right now, an we need one.

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Fri, 11 Oct 2019 16:09:48 +0200

Eliot Lear <[email-masked]> wrote:
    >>> about PSK and we could run with a naked public key pair as well in
    >>> 1.3, but we have to choose something.
    >> 

    > I do not.  But we need to have *a* flow for on prem onboarding.
    > TLS-PSK is one approach, but there are others.  I just want a
    > discussion before we nail this down, as I wrote.

    >> 
    >>> 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.
    >> 
    >> I don't understand this.  Are you saying that because it's wired,
    >> people do not expect to scan anything?

    > No quite the opposite- I’m saying that there is at least one way to do
    > this with Wifi, but no way to do this for wired right now, an we need
    > one.

So, can wired just be a degenerate version of wifi, where there can be only
one "ESSID", and there are no beacons to consider?

---

From: Eliot Lear <[email-masked]>
Date: Fri, 11 Oct 2019 16:34:43 +0200

> On 11 Oct 2019, at 16:09, Michael Richardson <[email-masked]> wrote:
> 

On the whole that has been my thought.  But it is a matter of which mechanism to degenerate to.  Is it TLS-PSK?  eDPP++?  TLS with naked public keys++?  And again, this is the on-prem case.  For cloud, we are well along.

Eliot

---

From: Joseph Salowey <[email-masked]>
Date: Tue, 29 Oct 2019 22:22:46 -0700

On Fri, Oct 11, 2019 at 7:34 AM Eliot Lear <[email-masked]> wrote:

> On the whole that has been my thought.  But it is a matter of which
> mechanism to degenerate to.  Is it TLS-PSK?  eDPP++?  TLS with naked public
> keys++?  And again, this is the on-prem case.  For cloud, we are well along.
>

[Joe] We are currently in a holding pattern with EAP-TLS.  It does not seem
right to delay it for functionality that we are not sure we have a use case
for.  If a use case develops then we can publish an update to EAP-TLS 1.3.
Do we have a use case for EAP-TLS-PSK that is blocked in the current
situation?

---

From: Eliot Lear <[email-masked]>
Date: Wed, 30 Oct 2019 10:02:23 +0100

> On 30 Oct 2019, at 06:22, Joseph Salowey <[email-masked]> wrote:
> 
> 
> 
> On Fri, Oct 11, 2019 at 7:34 AM Eliot Lear <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> > On 11 Oct 2019, at 16:09, Michael Richardson <[email-masked] <mailto:[email-masked]>> wrote:
> >
> [Joe] We are currently in a holding pattern with EAP-TLS.  It does not seem right to delay it for functionality that we are not sure we have a use case for.  If a use case develops then we can publish an update to EAP-TLS 1.3.  Do we have a use case for EAP-TLS-PSK that is blocked in the current situation?
> 

I would suggest that we do have a well-identified use case, although it has some issues, and that is IoT onboarding for on-prem equipment, as Owen described.  I do not know if we will end up executing on that use case, but it is a use case.  On the whole, the argument has to go the other way: why should we cripple a particular TLS method without strong justification?  The more we specialize the longer it takes to deliver new services, and the harder they are to support.

A fair argument, if it can be made, and I am not convinced it has been fully expressed, is the idea that there is no context by which one can separate fast restart and initial authentication.  This is Alan’s concern.  I’m not saying it’s without merit, but what I cannot yet see is whether it is an implementation or a protocol matter.

Eliot

---

From: Alan DeKok <[email-masked]>
Date: Wed, 30 Oct 2019 07:11:58 -0400

> A fair argument, if it can be made, and I am not convinced it has been fully expressed, is the idea that there is no context by which one can separate fast restart and initial authentication.  This…

  I believe it's a protocol matter.  In TLS 1.3, PSK handshakes are the same as resumption handshakes.

  It's not clear to me how this issue was addressed when using TLS 1.3 with HTTPS.  But I do believe it's an issue there, too.

  As an additional note, I believe it's also important that draft-dekok-emu-tls-eap-types be published at the same time as the EAP-TLS document.  The only unknown there is FAST and TEAP.  I'm happy to remove them from the document.

  But at this point it's not even a WG document.  There's not even consensus that the document necessary, which surprises me rather a lot.  Because password-based EAP methods are *much* more wide-spread than EAP-TLS.

  If the IETF publishes EAP-TLS without simultaneously rev'ing TTLS and PEAP, it will not only look bad, it will *be* bad.  And the industry press will (rightfully) lambast the standards process.

  Alan DeKok.

---

From: Jorge Vergara <[email-masked]>
Date: Thu, 31 Oct 2019 01:11:06 +0000

Hello - I am the primary maintainer of Microsoft's EAP implementation. I am sorry for joining late to this conversation, but hope our input is welcome.

On the topic of draft-dekok-emu-tls-eap-types:

I agree that it is necessary to standardize other TLS based EAP methods at the same time as EAP-TLS. The alternatives if this doesn't happen were discussed here previously at https://mailarchive.ietf.org/arch/msg/emu/J9Afcza1gOBQ_jww8E0yxSKPYeo - namely, either implementations will forge ahead with non-standard updates anyways, or they will be forced to wait to update EAP-TLS until the other methods are updated.

We are taking the second approach - we do not plan to update our EAP-TLS implementation until it is clear what the updates to other EAP methods will look like. We do not want to see non-standard vendor implementations to become difficult to implement de-facto standards. We would also like to see TEAP covered in this update.

A brief review on the material contained in the draft-dekok-emu-tls-eap-types:

I believe the 0x00 "Commitment message" not to send anymore TLS handshake data should be mentioned in this document, since it was established during https://mailarchive.ietf.org/arch/msg/emu/0MeocWZQLCv1pST5_2jW_ABlpMo that even tunnel based methods will need this.

The key derivation proposed for TEAP/FAST uses the definition from FAST, which is not identical to the TEAP derivation. Namely, FAST used MSK[j] in the derivation, but TEAP uses IMSK[j], which may be equivalent in some cases, but may not in others where the inner method exports an EMSK. I understand there may be a TEAP errata related to this and I may not be fully up to date on the errata discussion, so perhaps this is already taken into consideration.

Jorge Vergara

-----Original Message-----
From: Emu <[email-masked]> On Behalf Of Alan DeKok
Sent: Wednesday, October 30, 2019 4:12 AM
To: Eliot Lear <[email-masked]>
Cc: [email-masked]; John Mattsson <john.mattsson=[email-masked]>; Michael Richardson <[email-masked]>; EMU WG <[email-masked]>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

  Alan DeKok.

_______________________________________________
Emu mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu&amp;data=02%7C01%7Cjovergar%40microsoft.com%7C68e3a65a1c3441c857cb08d75d2a038b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637080308161040037&amp;sdata=zrPr0rRh1bkV8rrF23SaAJYz6aFfuO3lTX9e6U1fOXw%3D&amp;reserved=0

---

From: Joseph Salowey <[email-masked]>
Date: Wed, 30 Oct 2019 21:39:39 -0700

Hi Jorge,

Thanks for joining the conversation.

On Wed, Oct 30, 2019 at 6:11 PM Jorge Vergara <jovergar=
[email-masked]> wrote:

> Hello - I am the primary maintainer of Microsoft's EAP implementation. I
> am sorry for joining late to this conversation, but hope our input is
> welcome.
>
> I agree that it is necessary to standardize other TLS based EAP methods at
> the same time as EAP-TLS. The alternatives if this doesn't happen were
> discussed here previously at
> https://mailarchive.ietf.org/arch/msg/emu/J9Afcza1gOBQ_jww8E0yxSKPYeo -
> namely, either implementations will forge ahead with non-standard updates
> anyways, or they will be forced to wait to update EAP-TLS until the other
> methods are updated.
>
> We are taking the second approach - we do not plan to update our EAP-TLS
> implementation until it is clear what the updates to other EAP methods will
> look like. We do not want to see non-standard vendor implementations to
> become difficult to implement de-facto standards. We would also like to see
> TEAP covered in this update.
>
> I believe the 0x00 "Commitment message" not to send anymore TLS handshake
> data should be mentioned in this document, since it was established during
> https://mailarchive.ietf.org/arch/msg/emu/0MeocWZQLCv1pST5_2jW_ABlpMo
> that even tunnel based methods will need this.
>
> The key derivation proposed for TEAP/FAST uses the definition from FAST,
> which is not identical to the TEAP derivation. Namely, FAST used MSK[j] in
> the derivation, but TEAP uses IMSK[j], which may be equivalent in some
> cases, but may not in others where the inner method exports an EMSK. I
> understand there may be a TEAP errata related to this and I may not be
> fully up to date on the errata discussion, so perhaps this is already taken
> into consideration.
>
>
[Joe] I know that Alan has been asking for help with this draft especially
with TEAP and EAP-FAST.  I hope that you and others can work with him to
get the draft in a shape that we can progress through the working group.  I
agree that this is an important thing to do.

The EAP-TLS 1.3 draft is fairly far along and I do not think we have
consensus to add TEAP into the document at this point, but I think we can
make faster progress on the TLS types document if we have people interested
in working on it.

> Cc: [email-masked]; John Mattsson <john.mattsson=
> [email-masked]>; Michael Richardson <[email-masked]>;
> EMU WG <[email-masked]>
> > A fair argument, if it can be made, and I am not convinced it has been
> fully expressed, is the idea that there is no context by which one can
> separate fast restart and initial authentication.  This is Alan’s concern.
> I’m not saying it’s without merit, but what I cannot yet see is whether it
> is an implementation or a protocol matter.
>
>   It's not clear to me how this issue was addressed when using TLS 1.3
> with HTTPS.  But I do believe it's an issue there, too.
>
>   As an additional note, I believe it's also important that
> draft-dekok-emu-tls-eap-types be published at the same time as the EAP-TLS
> document.  The only unknown there is FAST and TEAP.  I'm happy to remove
> them from the document.
>
>   But at this point it's not even a WG document.  There's not even
> consensus that the document necessary, which surprises me rather a lot.
> Because password-based EAP methods are *much* more wide-spread than EAP-TLS.
>
>   If the IETF publishes EAP-TLS without simultaneously rev'ing TTLS and
> PEAP, it will not only look bad, it will *be* bad.  And the industry press
> will (rightfully) lambast the standards process.
>
>   Alan DeKok.
>

---

From: Joseph Salowey <[email-masked]>
Date: Wed, 30 Oct 2019 21:44:48 -0700

> with HTTPS.  But I do believe it's an issue there, too.
[Joe] Can you elaborate on what the issue is?  I think most TLS deployments
operate in either a certificate based mode or a PSK mode, but not both at
the same time.

> will (rightfully) lambast the standards process.
[Joe] We need people to contribute to the document.  If we are going to
publish a document through the working group it needs to at least to
include TEAP.   I know there are folks on this list who are implementing.
They need to step up and help with this document and the TEAP errata.