Subject: Re: [Emu] Late WGLC Comment on draft-ietf-emu-eap-tls13

From: John Mattsson <[email-masked]>
Date: Mon, 9 Mar 2020 09:59:40 +0000

Hi Russ,

Sorry for the late reply. I actually brought up your draft [ID-ietf-tls-tls13-cert-with-extern-psk] during my EMU presentation at IETF 106 as something that should probably be in EAP-TLS. Bernard Aboba then expressed a very strong opinion that [ID-ietf-tls-tls13-cert-with-extern-psk] should absolutely not be included in the EAP-TLS Type-Code 0x0D. After this the WG decided as a way forward to specify EAP-TLS with PSK authentication in a new draft.

Given these strong opinions from Bernard Aboba, and the wish to publish draft-ietf-emu-eap-tls13 soon. I think the best way forward would be specify the use of [ID-ietf-tls-tls13-cert-with-extern-psk] in the same new draft as EAP-TLS with PSK authentication. Does that sound like an acceptable way forward?

Cheers,
John

-----Original Message-----
From: Russ Housley <[email-masked]>
Date: Monday, 13 January 2020 at 18:29
To: John Mattsson <[email-masked]>
Cc: EMU WG <[email-masked]>
Subject: Late WGLC Comment on draft-ietf-emu-eap-tls13

    John:
    
    Section 2.1.1 says:
    
       Pre-Shared Key (PSK) authentication SHALL NOT be used except
       for resumption.
    
    I would rather this say:
    
       Pre-Shared Key (PSK) authentication SHALL NOT be used except
       for resumption or in conjunction with the "tls_cert_with_extern_psk"
       extension [ID-ietf-tls-tls13-cert-with-extern-psk].
    
    Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 10 Mar 2020 12:30:07 -0400

I do not understand the reason for Bernard's objection.  I looked at the minutes, and I do not find any rationale there.  Can you help?

Russ

> On Mar 9, 2020, at 5:59 AM, John Mattsson <[email-masked]> wrote:
> 
> Hi Russ,
>

---

From: Mohit Sethi M <[email-masked]>
Date: Tue, 10 Mar 2020 16:43:28 +0000

Hi Russ,

You can listen here: https://youtu.be/YJLG4JUftqI?t=1144

We plan to support it in EAP-TLS-PSK instead: 
https://tools.ietf.org/html/draft-mattsson-emu-eap-tls-psk-00. We have 
already added a reference to draft-ietf-tls-tls13-cert-with-extern-psk 
and plan to use it. I think using an external PSK any ways requires 
ironing out some issues like what is the relationship between NAI and 
the PSK identity? And do we allow user-configured PSK identities/PSKs etc.?

Would it be reasonable if we specify the usage of 
draft-ietf-tls-tls13-cert-with-extern-psk in EAP-TLS-PSK instead?

--Mohit

On 3/10/20 6:30 PM, Russ Housley wrote:
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: Russ Housley <[email-masked]>
Date: Tue, 10 Mar 2020 13:47:45 -0400

Thanks for the pointer.

I am fine with the proposed way forward.

Russ

> On Mar 10, 2020, at 12:43 PM, Mohit Sethi M <[email-masked]> wrote:
> 
> Hi Russ,
>

---

From: John Mattsson <[email-masked]>
Date: Wed, 11 Mar 2020 08:01:17 +0000

Hi,

 >> I do not understand the reason for Bernard's objection.  I looked at the minutes, and I do not find any rationale there.  Can you help?

If I remember correctly, Bernard stated that the indroduction of PSK could weaken the implementation and violate the security proofs of EAP-TLS. I don't really agree with Bernard, but I am fine with resticting the type code 0x0D to certificates only. I am not sure any proofs with TLS 1.1 would apply to TLS 1.3 anyway as TLS 1.3 is basically a new protocol, reusing encoding and IANA registers from the old version. 

Given that the EAP-TLS Type-Code 0x0D is decicated to Certificates, I am not sure the approach to dedicate a new type code for PSK authentication is the correct choice.

psk_ke
psk_dhe_ke
tls_cert_with_extern_psk+psk_dhe_ke

are just three of many authentication methods that may not fit in type code 0x0D. Earlier versions of TLS have supported many more authentication methods 

KRB5
anon
SRP
ECCPWD

And just looking at the TLS WG documents, there are several future authentication methods for TLS 1.3 likely in the future.

https://datatracker.ietf.org/doc/draft-wang-tls-raw-public-key-with-ibc/
https://datatracker.ietf.org/doc/draft-tschofenig-tls-cwt/
https://datatracker.ietf.org/doc/draft-vanrein-tls-kdh/

I do not think the EAP group should forbid any TLS 1.3 authentication method unless there is valid reasons to do so. Instead of the current suggestion:

0x0D     EAP-TLS (cert and nothing else)
0xTBD    EAP-TLS-PSK (psk and psk+something else)

I think a better way to structure things would be:

0x0D     EAP-TLS (cert and nothing else)
0xTBD    EAP-TLS-FULL (everything that TLS 1.3 supports)

I sympatise with earlier comments in the group that EAP should mostly be a transport for TLS and that the decisions of which authentication methods to support should be taken by the TLS WG.

Cheers,
John

-----Original Message-----
From: Russ Housley <[email-masked]>
Date: Tuesday, 10 March 2020 at 18:48
To: Mohit Sethi M <[email-masked]>
Cc: John Mattsson <[email-masked]>, EMU WG <[email-masked]>
Subject: Re: [Emu] Late WGLC Comment on draft-ietf-emu-eap-tls13

    Thanks for the pointer.

    Russ

---

From: Mohit Sethi M <[email-masked]>
Date: Wed, 11 Mar 2020 08:48:29 +0000

Hi John,

I understand your concern of EAP restricting TLS authentication methods. 
However, it is not unusual for other groups to define profiles of a 
protocol they rely on.

If someone's IoT device wants only EAP-TLS-PSK and nothing else, then I 
believe we should enable that. I agree with you that a separate document 
and type code for each TLS authentication method is not ideal either. We 
could do something like EAP-TLS-FULL as you suggest (as long as 
developers can pick and choose only relevant TLS authentication method). 
Also, we are not yet running out of the type code (and expanded type 
code) space for now. If others are interested in defining some 
EAP-TLS-foo method later on, they have the liberty to do that.

--Mohit

---

From: Alan DeKok <[email-masked]>
Date: Wed, 11 Mar 2020 07:25:54 -0400

> If I remember correctly, Bernard stated that the indroduction of PSK could weaken the implementation and violate the security proofs of EAP-TLS. I don't really agree with Bernard, but I am fine wit…

  For what it's worth, RFC 5216 doesn't make any statement about PSK.  So on a first reading, there are currently no restrictions on using PSK with EAP-TLS, and TLS <= 1.2.

  There are multiple client / server implementations which support PSK for EAP-TLS.

  That being said, I'm OK with having one EAP type code for EAP-TLS (certs), and another for EAP-TLS (everything else)

  I would avoid having multiple EAP types.  That would bloat implementations.  It's better to just let implementors / admins configure TLS parameters for one EAP type, instead of multiple  EAP types.

  Alan DeKok.

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Wed, 11 Mar 2020 13:03:24 +0000

Alan,
How should we interpret this in RFC 5216 https://tools.ietf.org/html/rfc5216#section-2.1.1:

   If the EAP server is not resuming a previously established session,
   then it MUST include a TLS server_certificate handshake message, and
   a server_hello_done handshake message MUST be the last handshake
   message encapsulated in this EAP-Request packet.

   The certificate message contains a public key certificate chain for
   either a key exchange public key (such as an RSA or Diffie-Hellman
   key exchange public key) or a signature public key (such as an RSA or
   Digital Signature Standard (DSS) signature public key).

Does this statement pretty much precludes the certificateless TLS 1.2 ciphersuites, i.e. the extern PSK ones from right?

Owen

-----Original Message-----
From: Emu <[email-masked]> On Behalf Of Alan DeKok
Sent: 11 March 2020 19:26
To: John Mattsson <john.mattsson=[email-masked]>
Cc: Mohit Sethi M <[email-masked]>; EMU WG <[email-masked]>
Subject: Re: [Emu] Late WGLC Comment on draft-ietf-emu-eap-tls13

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 11 Mar 2020 09:05:12 -0400

> How should we interpret this in RFC 5216 https://tools.ietf.org/html/rfc5216#section-2.1.1:
 ...
> Does this statement pretty much precludes the certificateless TLS 1.2 ciphersuites, i.e. the extern PSK ones from right?

  Ah, yes.  I had looked for references to PSK, and didn't see them.  I didn't look for text saying "only certificates."

  Alan DeKok.

---

From: John Mattsson <[email-masked]>
Date: Wed, 11 Mar 2020 13:38:48 +0000

>I would avoid having multiple EAP types.  That would bloat implementations.  It's better to just let implementors / admins configure TLS parameters for one EAP type, instead of multiple  EAP types.

What does "avoid having multiple EAP types" refer to?

Does this mean you would like to avoid "EAP-TLS (certs), and another for EAP-TLS (everything else)", even If you can accept it

Or are you saying that you want to avoid EAP-TLS (cert), EAP-TLS (psk), EAP-TLS (pwd), etc....

John

-----Original Message-----
From: Alan DeKok <[email-masked]>
Date: Wednesday, 11 March 2020 at 12:26
To: John Mattsson <[email-masked]>
Cc: Russ Housley <[email-masked]>, Mohit Sethi M <[email-masked]>, EMU WG <[email-masked]>
Subject: Re: [Emu] Late WGLC Comment on draft-ietf-emu-eap-tls13

    

    
      Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 11 Mar 2020 10:02:11 -0400

> Does this mean you would like to avoid "EAP-TLS (certs), and another for EAP-TLS (everything else)", even If you can accept it

  That's fine.

> Or are you saying that you want to avoid EAP-TLS (cert), EAP-TLS (psk), EAP-TLS (pwd), etc....

  Having EAP-TLS-(TLS variant) is probably wrong.  Just use EAP-TLS (full).  That lets us configure TLS parameters in TLS, and not in EAP.

  Alan DeKok.