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

[John Mattsson]

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


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Mohit Sethi M]

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

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Mohit Sethi M]

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

*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 
Date: Thursday, 10 October 2019 at 09:14
To: Joseph Salowey 
Cc: John Mattsson 
,
 "draft-ietf-emu-eap-tl...@ietf.org" 
, 
EMU WG 
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: 
Resent to: John Mattsson 
, 

Resent date: Thu, 10 Oct 2019 00:14:49 -0700 (PDT)

Hi Joe,


On 7 Oct 2019, at 02:42, Joseph Salowey 
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.  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 
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 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>>, 
EMU WG mailto:emu@ietf.org>>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: mailto:alias-boun...@ietf.org>>
Resent to: John Mattsson 

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

[Owen Friel (ofriel)]

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


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


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


[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

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 
mailto:mohit.m.se...@ericsson.com>>
Date: Thursday, 10 October 2019 at 10:03
To: Eliot Lear mailto:l...@cisco.com>>, John Mattsson 
mailto:john.matts...@ericsson.com>>
Cc: 
"draft-ietf-emu-eap-tl...@ietf.org" 
mailto:draft-ietf-emu-eap-tl...@ietf.org>>, 
John Mattsson 
mailto:john.mattsson=40ericsson@dmarc.ietf.org>>,
 EMU WG mailto:emu@ietf.org>>
Subject: 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. 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



___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Eliot Lear]

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 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  
>> Date: Thursday, 10 October 2019 at 09:14
>> To: Joseph Salowey  
>> Cc: John Mattsson  
>> , 
>> "draft-ietf-emu-eap-tl...@ietf.org" 
>>  
>>  
>> , EMU WG  
>> 
>> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
>> Resent from:  
>> Resent to: John Mattsson  
>> ,  
>> 
>> Resent date: Thu, 10 Oct 2019 00:14:49 -0700 (PDT)
>> 
>> Hi Joe,
>> 
>> 
>> On 7 Oct 2019, at 02:42, Joseph Salowey > > 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 
>> > > 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 > >
>> Date: Wednesday, 18 September 2019 at 15:21
>> To: "draft-ietf-emu-eap-tl...@ietf.org 
>> " 
>> > >, EMU WG > >
>> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
>> Resent from: mailto:alias-boun...@ietf.org>>
>> Resent to: John Mattsson > >, > 

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

[John Mattsson]

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, 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 
Date: Thursday, 10 October 2019 at 10:03
To: Eliot Lear , John Mattsson 
Cc: "draft-ietf-emu-eap-tl...@ietf.org" , 
John Mattsson , EMU WG 

Subject: 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. 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 
mailto: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 mailto:l...@cisco.com>>
Date: Thursday, 10 October 2019 at 09:14
To: Joseph Salowey mailto:j...@salowey.net>>
Cc: John Mattsson 
mailto:john.mattsson=40ericsson@dmarc.ietf.org>>,
 "draft-ietf-emu-eap-tl...@ietf.org" 
mailto:draft-ietf-emu-eap-tl...@ietf.org>>, 
EMU WG mailto:emu@ietf.org>>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: mailto:alias-boun...@ietf.org>>
Resent to: John Mattsson 
mailto:john.matts...@ericsson.com>>, 
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 
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.  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 

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

[John Mattsson]

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 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 
Date: Thursday, 10 October 2019 at 09:55
To: John Mattsson , Eliot Lear , 
Joseph Salowey 
Cc: John Mattsson , 
"draft-ietf-emu-eap-tl...@ietf.org" , EMU WG 

Subject: 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 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,

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 
Date: Thursday, 10 October 2019 at 09:14
To: Joseph Salowey 
Cc: John Mattsson 
,
 "draft-ietf-emu-eap-tl...@ietf.org" 
, 
EMU WG 
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: 
Resent to: John Mattsson 
, 

Resent date: Thu, 10 Oct 2019 00:14:49 -0700 (PDT)

Hi Joe,



On 7 Oct 2019, at 02:42, Joseph Salowey 
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.  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 
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 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>>, 
EMU WG mailto:emu@ietf.org>>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: mailto:alias-boun...@ietf.org>>
Resent to: John Mattsson 
mailto:john.matts...@ericsson.com>>, 
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 

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

[Mohit Sethi M]

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 
mailto: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 mailto:l...@cisco.com>>
Date: Thursday, 10 October 2019 at 09:14
To: Joseph Salowey mailto:j...@salowey.net>>
Cc: John Mattsson 
mailto:john.mattsson=40ericsson@dmarc.ietf.org>>,
 "draft-ietf-emu-eap-tl...@ietf.org" 
mailto:draft-ietf-emu-eap-tl...@ietf.org>>, 
EMU WG mailto:emu@ietf.org>>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: mailto:alias-boun...@ietf.org>>
Resent to: John Mattsson 
mailto:john.matts...@ericsson.com>>, 
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 
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.  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 
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 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>>, 
EMU WG mailto:emu@ietf.org>>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: mailto:alias-boun...@ietf.org>>
Resent to: John Mattsson 
mailto:john.matts...@ericsson.com>>, 
mailto:mo...@piuha.net>>
Resent date: Wednesday, 

Re: [Emu] TEAP errata 5770

[Eliot Lear]

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 arbitrary number of 
> methods that may or may not make an EMSK available would be fairly complex.
> 
> I think the most straight forward solution is to either always assume that 
> for an EMSK generating method the EMSK is either always available or always 
> unavailable.  It seems that it is safer to always assume that the EMSK is 
> unavailable and will therefore never be used.  I think this has the following 
> implications:
> 
> -  The S-IMCK is always generated from the inner method MSK or the all-zero 
> value if the method does not generate key material.
> -  The EMSK compound MAC is not used
> -  Implementations must have a policy that accepts MSK MACs
> 
> It would appear that from a cryptographic analysis point of view the MSK and 
> EMSK are equivalent since these keys will only be used in these TEAP 
> calculations and not for other purposes..  There are documented drawbacks of 
> using the MSK described in RFC7029 
> (https://tools.ietf.org/html/rfc7029#page-12 
> ).   If the properties of the 
> EMSK binding are needed in the use cases currently under consideration then I 
> think we could redefine the way the EMSK MAC to be computed from the EMSK of 
> the inner method changing the above to
> 
> -  The S-IMCK is always generated from the inner method MSK or the all-zero 
> value if the method does not generate key material.
> - Compute EMSK MAC from the inner-method EMSK instead of the S-IMCK
>  Compound-MAC = MAC( EMSK[J], BUFFER )
> -  Implementations have a policy that prevents EMSK downgrade to MSK
> 
> Hopefully there is a more elegant solution. Any ideas?
> 
> Joe
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu



signature.asc
Description: Message signed with OpenPGP
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Mohit Sethi M]

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,

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 
Date: Thursday, 10 October 2019 at 09:14
To: Joseph Salowey 
Cc: John Mattsson 
,
 "draft-ietf-emu-eap-tl...@ietf.org" 
, 
EMU WG 
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: 
Resent to: John Mattsson 
, 

Resent date: Thu, 10 Oct 2019 00:14:49 -0700 (PDT)

Hi Joe,


On 7 Oct 2019, at 02:42, Joseph Salowey 
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.  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 
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 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>>, 
EMU WG mailto:emu@ietf.org>>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: mailto:alias-boun...@ietf.org>>
Resent to: John Mattsson 
mailto:john.matts...@ericsson.com>>, 
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
https://www.ietf.org/mailman/listinfo/emu

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

[Eliot Lear]

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  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 mailto:l...@cisco.com>>
> Date: Thursday, 10 October 2019 at 09:14
> To: Joseph Salowey mailto:j...@salowey.net>>
> Cc: John Mattsson  >, 
> "draft-ietf-emu-eap-tl...@ietf.org 
> " 
>  >, EMU WG  >
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> Resent from: mailto:alias-boun...@ietf.org>>
> Resent to: John Mattsson  >,  >
> Resent date: Thu, 10 Oct 2019 00:14:49 -0700 (PDT)
> 
> Hi Joe,
> 
> 
>> On 7 Oct 2019, at 02:42, Joseph Salowey > > 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 
>> > > 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 >> >
>>> Date: Wednesday, 18 September 2019 at 15:21
>>> To: "draft-ietf-emu-eap-tl...@ietf.org 
>>> " 
>>> >> >, EMU WG >> >
>>> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
>>> Resent from: mailto:alias-boun...@ietf.org>>
>>> Resent to: John Mattsson >> >, >> >
>>> 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 
>>> 

Re: [Emu] TEAP errata 5770

[Joseph Salowey]

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 the most straight forward solution is to either always assume that
> for an EMSK generating method the EMSK is either always available or always
> unavailable.  It seems that it is safer to always assume that the EMSK is
> unavailable and will therefore never be used.  I think this has the
> following implications:
>
> -  The S-IMCK is always generated from the inner method MSK or the
> all-zero value if the method does not generate key material.
> -  The EMSK compound MAC is not used
> -  Implementations must have a policy that accepts MSK MACs
>
> It would appear that from a cryptographic analysis point of view the MSK
> and EMSK are equivalent since these keys will only be used in these
> TEAP calculations and not for other purposes.  There are documented
> drawbacks of using the MSK described in RFC7029 (
> https://tools.ietf.org/html/rfc7029#page-12).   If the properties of the
> EMSK binding are needed in the use cases currently under consideration then
> I think we could redefine the way the EMSK MAC to be computed from the EMSK
> of the inner method changing the above to
>
> -  The S-IMCK is always generated from the inner method MSK or the
> all-zero value if the method does not generate key material.
> - Compute EMSK MAC from the inner-method EMSK instead of the S-IMCK
>  Compound-MAC = MAC( EMSK[J], BUFFER )
> -  Implementations have a policy that prevents EMSK downgrade to MSK
>
> Hopefully there is a more elegant solution. Any ideas?
>
>
[Joe] It might be better to do the following:

Singe S-IMCK chain, but when an EMSK method is used there are two pre
S-IMCK keys generated, one for the EMSK and one for the MSK.  These are
used to calculate two CMKs for Compound MACs for EMSK and MSK
respectively.  If the server responds with an EMSK MAC then the pre S-IMCK
generated from the EMSK is used as the S-IMCK for future calculations if
not then the one from the MSK is used.

Modification to section 5.2 Intermediate Compound Key Derivations:

When an EMSK generating method is used, then two compound MAC keys are
generated, one based on the IMSK with the EMSK from the current method and
on from the MSK from the current method as follows:

 S-IMCK[j-1] = compound session key from previous method:

 IMSK-EMSK[J] = First 32 octets of TLS-PRF(EMSK,
"teapbind...@ietf.org" | "\0" | 64)

 IMSK-MSK = MSK


 IMCK-EMSK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
IMSK-EMSK[j], 60)
   S-IMCK-EMSK[j] = first 40 octets of IMCK-EMSK[j]
   CMK-EMSK[j] = last 20 octets of IMCK-EMSK[j]


 IMCK-MSK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
IMSK-MSK[j], 60)
   S-IMCK-MSK[j] = first 40 octets of IMCK-EMSK[j]
   CMK-MSK[j] = last 20 octets of IMCK-EMSK[j]


  CMK-MSK[J] is used to calculate the MSK compound MAC

  CMK-EMSK[J] is used to calculate the EMSK compound MAC

If the EMSK MAC is returned form the server then the

 S-IMCK[j] = S-IMCK-EMSK[j]

else
  S-IMCK[j] = S-IMCK-MSK[j]

Modifications to  5.3.  Computing the Compound MAC

The Compound MAC EMSK computation is as follows:

  CMK-EMSK = CMK-EMSK[j]
  Compound-MAC-EMSK = MAC( CMK-EMSK, BUFFER )


The Compound MAC MSK computation is as follows:

  CMK-MSK = CMK-MSK[j]
  Compound-MAC-MSK = MAC( CMK-MSK, BUFFER )


I think this is more in line with what was originally intended and better
than what I originally wrote in the previous message.


> Joe
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu