Subject: [Emu] Finishing draft-ietf-emu-eap-tls13 - Commitment Message handling

From: Mohit Sethi M <[email-masked]>
Date: Mon, 13 Jul 2020 17:44:00 +0000

Dear all,

draft-ietf-emu-eap-tls13 is currently in the state "AD Evaluation::AD Followup". Our AD (Roman) had done an excellent review (https://mailarchive.ietf.org/arch/msg/emu/k6K98OhuOQmbzSAgGWCtSIVv3Qk/), which I addressed in version 10 (https://mailarchive.ietf.org/arch/msg/emu/IopJTjefyVVKpObzyFc0CAJ-Pig/).

The only outstanding issue is the handling of the commitment message. The current text in the draft says the following:

   When an EAP server has sent its last handshake message (Finished or a
   Post-Handshake), it commits to not sending any more handshake
   messages by sending a Commitment Message.  The Commitment Message is
   a TLS record with application data 0x00 (i.e. a TLS record with
   TLSPlaintext.type = application_data, TLSPlaintext.length = 1, and
   TLSPlaintext.fragment = 0x00).  Note that the length of the plaintext
   is greater than the corresponding TLSPlaintext.length due to the
   inclusion of TLSInnerPlaintext.type and any padding supplied by the
   sender.  EAP server implementations MUST set TLSPlaintext.fragment to
   0x00, but EAP peer implementations MUST accept any application data
   as a Commitment Message from the EAP server to not send any more
   handshake messages.  The Commitment Message may be sent in the same
   EAP-Request as the last handshake record or in a separate EAP-
   Request.  Sending the Commitment Message in a separate EAP-Request
   adds an additional round-trip, but may be necessary in TLS
   implementations that only implement a subset of TLS 1.3.

Hannes says that this is not ideal and cannot be achieved with mbed TLS 1.3 implementation. He made 3 alternative suggestions for achieving the functionality of the commitment message (https://mailarchive.ietf.org/arch/msg/emu/eM-14QdDQjg7DvhAVJMzpvPz5wg/).

I would like to close this issue and would like to receive feedback from others who have commented before or are working on implementations: Jim, Alan, Jouni; please let us know what do you think about the change?

--Mohit

---

From: Alan DeKok <[email-masked]>
Date: Mon, 13 Jul 2020 13:51:39 -0400

On Jul 13, 2020, at 1:44 PM, Mohit Sethi M <[email-masked]> wrote:
> ...

  hostap sends an encrypted octet.  See https://w1.fi/cgit/hostap/commit/?id=36ec5881657157752dced741256441c230e42fe6

EAP-TLS server: Add application data to indicate end of v1.3 handshake
This adds an encrypted version of a one octet application data payload
to the end of the handshake when TLS v1.3 is used to indicate explicit
termination of the handshake (either after Finished message or after the
optional NewSessionTicket message). The current
draft-ietf-emu-eap-tls13-05 defines this to be a zero length payload,
but since that is not allowed by OpenSSL, use a one octet payload
instead for now with hopes of getting the draft specification updated
instead of having to modify OpenSSL for this.

Signed-off-by: Jouni Malinen <[email-masked]>

  FreeRADIUS does the same, as of recent commits in the v3.0.x branch.  We've successfully tested interoperability.

  So I think it's fine to send the one octet as *encrypted* data, and not *plaintext*.

  Alan DeKok.

---

From: Jorge Vergara <[email-masked]>
Date: Mon, 13 Jul 2020 18:24:32 +0000

Windows expects an encrypted octet. My brain had automatically translated the plaintext -> encrypted based on the timing of the commitment message - which was apparently an incorrect translation at the time. Interop has been tested with FreeRADIUS and hostapd.

-----Original Message-----
From: Emu <[email-masked]> On Behalf Of Alan DeKok
Sent: Monday, July 13, 2020 10:52 AM
To: Mohit Sethi M <[email-masked]>
Cc: Roman Danyliw <[email-masked]>; [email-masked]
Subject: Re: [Emu] Finishing draft-ietf-emu-eap-tls13 - Commitment Message handling

On Jul 13, 2020, at 1:44 PM, Mohit Sethi M <[email-masked]> wrote:
> 
> Dear all,
> 
> draft-ietf-emu-eap-tls13 is currently in the state "AD Evaluation::AD Followup". Our AD (Roman) had done an excellent review (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Femu%2Fk6K98OhuOQmbzSAgGWCtSIVv3Qk%2F&amp;data=02%7C01%7Cjovergar%40microsoft.com%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380970944&amp;sdata=mfYGmzLt9zC%2BDBmqGzeFmx%2Bq8XdZG%2Bd0JefKvwSSQ%2Bw%3D&amp;reserved=0), which I addressed in version 10 (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Femu%2FIopJTjefyVVKpObzyFc0CAJ-Pig%2F&amp;data=02%7C01%7Cjovergar%40microsoft.com%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380970944&amp;sdata=%2FWzCNaXEnxX9adDHjLHKHmH0aYyG3CV4cqpyRSP7yF4%3D&amp;reserved=0). 
> ...
> Hannes says that this is not ideal and cannot be achieved with mbed TLS 1.3 implementation. He made 3 alternative suggestions for achieving the functionality of the commitment message (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Femu%2FeM-14QdDQjg7DvhAVJMzpvPz5wg%2F&amp;data=02%7C01%7Cjovergar%40microsoft.com%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380980941&amp;sdata=umbXQTG0%2FLJN6IrXI%2BjgrQME6mE3UtmI7nOTAdghl7M%3D&amp;reserved=0). 
> 

  hostap sends an encrypted octet.  See https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw1.fi%2Fcgit%2Fhostap%2Fcommit%2F%3Fid%3D36ec5881657157752dced741256441c230e42fe6&amp;data=02%7C01%7Cjovergar%40microsoft.com%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380980941&amp;sdata=R1R8rq0d0MyG36iSVeJwcP3UYRSb%2F4MafyW9Ir%2BNx2A%3D&amp;reserved=0

EAP-TLS server: Add application data to indicate end of v1.3 handshake This adds an encrypted version of a one octet application data payload to the end of the handshake when TLS v1.3 is used to indicate explicit termination of the handshake (either after Finished message or after the optional NewSessionTicket message). The current
draft-ietf-emu-eap-tls13-05 defines this to be a zero length payload, but since that is not allowed by OpenSSL, use a one octet payload instead for now with hopes of getting the draft specification updated instead of having to modify OpenSSL for this.

  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%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380980941&amp;sdata=1xjqVMXOl1D62KRGdzAggBjEIuBVMoIU6AisOnJEroo%3D&amp;reserved=0

---

From: Jim Schaad <[email-masked]>
Date: Mon, 13 Jul 2020 11:30:49 -0700

My expectation would be that the third option from Hannes is what should be done.  The commit message should be encrypted and not a plain text message.

Jim

From: Mohit Sethi M <[email-masked]> 
Sent: Monday, July 13, 2020 10:44 AM
To: [email-masked]
Cc: Jim Schaad <[email-masked]>; Alan DeKok <[email-masked]>; [email-masked]; Roman Danyliw <[email-masked]>; Hannes Tschofenig <[email-masked]>
Subject: Finishing draft-ietf-emu-eap-tls13 - Commitment Message handling

Dear all,

--Mohit

---

From: Mohit Sethi M <[email-masked]>
Date: Mon, 13 Jul 2020 18:49:54 +0000

Hi Alan, Jorge, Jim, Hannes,

One octet of plaintext naturally results in a larger encrypted record (which serves as the notification). The current text only explains how to construct the encrypted record by setting the TLSPlaintext to one octet of zeros.

RFC 8446 in any case says the following in Section 5.1.  Record Layer: "Application Data messages contain data that is opaque to TLS. Application Data messages are always protected."

Perhaps the text can be made more explicit as follows:

When an EAP server has sent its last handshake message (Finished or a Post-Handshake), it commits to not sending any more handshake messages by sending an encyrpted Commitment Message.  The Commitment Message is an encyrpted TLS record constructed with application data 0x00 (i.e. a TLS record with TLSPlaintext.type = application_data, TLSPlaintext.length = 1, and TLSPlaintext.fragment = 0x00).  Note that the length of the plaintext is greater than the corresponding TLSPlaintext.length due to the inclusion of TLSInnerPlaintext.type and any padding supplied by the sender.  EAP server implementations MUST set TLSPlaintext.fragment to 0x00, but EAP peer implementations MUST accept any application data as a Commitment Message from the EAP server to not send any more handshake messages.  The Commitment Message may be sent in the same EAP-Request as the last handshake record or in a separate EAP-Request.  Sending the Commitment Message in a separate EAP-Request adds an additional round-trip, but may be necessary in TLS implementations that only implement a subset of TLS 1.3.
Is this amenable to all?

--Mohit

On 7/13/20 9:24 PM, Jorge Vergara wrote:

-----Original Message-----
From: Emu <[email-masked]><mailto:[email-masked]> On Behalf Of Alan DeKok
Sent: Monday, July 13, 2020 10:52 AM
To: Mohit Sethi M <[email-masked]><mailto:[email-masked]>
Cc: Roman Danyliw <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Emu] Finishing draft-ietf-emu-eap-tls13 - Commitment Message handling

On Jul 13, 2020, at 1:44 PM, Mohit Sethi M <[email-masked]><mailto:[email-masked]> wrote:

Dear all,

Signed-off-by: Jouni Malinen <[email-masked]><mailto:[email-masked]>

  Alan DeKok.

_______________________________________________
Emu mailing list
[email-masked]<mailto:[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%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380980941&amp;sdata=1xjqVMXOl1D62KRGdzAggBjEIuBVMoIU6AisOnJEroo%3D&amp;reserved=0

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

---

From: Jim Schaad <[email-masked]>
Date: Tue, 14 Jul 2020 20:14:32 -0700

From: Emu <[email-masked]> On Behalf Of Mohit Sethi M
Sent: Monday, July 13, 2020 11:50 AM
To: Jorge Vergara <jovergar=[email-masked]>; Alan DeKok <[email-masked]>; Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: Re: [Emu] Finishing draft-ietf-emu-eap-tls13 - Commitment Message handling

When an EAP server has sent its last handshake message (Finished or a Post-Handshake), it commits to not sending any more handshake messages by sending an encyrpted Commitment Message.  The Commitment Message is an encyrpted TLS record constructed with application data 0x00 (i.e. a TLS record with TLSPlaintext.type = application_data, TLSPlaintext.length = 1, and TLSPlaintext.fragment = 0x00).  Note that the length of the plaintext is greater than the 

[JLS] I tend to find the above confusing.  Why not stop with saying the commit message is a single byte of 0 in the application data stream.  All of the rest I find to just be confusion.

corresponding TLSPlaintext.length due to the inclusion of TLSInnerPlaintext.type and any padding supplied by the sender.  EAP server implementations MUST set TLSPlaintext.fragment to 0x00, but EAP peer implementations MUST accept any application data as a Commitment Message from the EAP server to not send any more handshake messages.  The Commitment Message may be sent in the same EAP-Request as the last handshake record or in a separate EAP-Request.  Sending the Commitment Message in a separate EAP-Request adds an additional round-trip, but may be necessary in TLS implementations that only implement a subset of TLS 1.3.

Is this amenable to all? 

--Mohit

 
-----Original Message-----
From: Emu  <mailto:[email-masked]> <[email-masked]> On Behalf Of Alan DeKok
Sent: Monday, July 13, 2020 10:52 AM
To: Mohit Sethi M  <mailto:[email-masked]> <[email-masked]>
Cc: Roman Danyliw  <mailto:[email-masked]> <[email-masked]>; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Emu] Finishing draft-ietf-emu-eap-tls13 - Commitment Message handling
 
On Jul 13, 2020, at 1:44 PM, Mohit Sethi M  <mailto:[email-masked]> <[email-masked]> wrote:

Dear all,
 
draft-ietf-emu-eap-tls13 is currently in the state "AD Evaluation::AD Followup". Our AD (Roman) had done an excellent review (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Femu%2Fk6K98OhuOQmbzSAgGWCtSIVv3Qk%2F <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Femu%2Fk6K98OhuOQmbzSAgGWCtSIVv3Qk%2F&amp;data=02%7C01%7Cjovergar%40microsoft.com%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380970944&amp;sdata=mfYGmzLt9zC%2BDBmqGzeFmx%2Bq8XdZG%2Bd0JefKvwSSQ%2Bw%3D&amp;reserved=0> &amp;data=02%7C01%7Cjovergar%40microsoft.com%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380970944&amp;sdata=mfYGmzLt9zC%2BDBmqGzeFmx%2Bq8XdZG%2Bd0JefKvwSSQ%2Bw%3D&amp;reserved=0), which I addressed in version 10 (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Femu%2FIopJTjefyVVKpObzyFc0CAJ-Pig%2F <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Femu%2FIopJTjefyVVKpObzyFc0CAJ-Pig%2F&amp;data=02%7C01%7Cjovergar%40microsoft.com%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380970944&amp;sdata=%2FWzCNaXEnxX9adDHjLHKHmH0aYyG3CV4cqpyRSP7yF4%3D&amp;reserved=0> &amp;data=02%7C01%7Cjovergar%40microsoft.com%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380970944&amp;sdata=%2FWzCNaXEnxX9adDHjLHKHmH0aYyG3CV4cqpyRSP7yF4%3D&amp;reserved=0). 
...
Hannes says that this is not ideal and cannot be achieved with mbed TLS 1.3 implementation. He made 3 alternative suggestions for achieving the functionality of the commitment message (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Femu%2FeM-14QdDQjg7DvhAVJMzpvPz5wg%2F <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Femu%2FeM-14QdDQjg7DvhAVJMzpvPz5wg%2F&amp;data=02%7C01%7Cjovergar%40microsoft.com%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380980941&amp;sdata=umbXQTG0%2FLJN6IrXI%2BjgrQME6mE3UtmI7nOTAdghl7M%3D&amp;reserved=0> &amp;data=02%7C01%7Cjovergar%40microsoft.com%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380980941&amp;sdata=umbXQTG0%2FLJN6IrXI%2BjgrQME6mE3UtmI7nOTAdghl7M%3D&amp;reserved=0). 

  hostap sends an encrypted octet.  See https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw1.fi%2Fcgit%2Fhostap%2Fcommit%2F%3Fid%3D36ec5881657157752dced741256441c230e42fe6 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw1.fi%2Fcgit%2Fhostap%2Fcommit%2F%3Fid%3D36ec5881657157752dced741256441c230e42fe6&amp;data=02%7C01%7Cjovergar%40microsoft.com%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380980941&amp;sdata=R1R8rq0d0MyG36iSVeJwcP3UYRSb%2F4MafyW9Ir%2BNx2A%3D&amp;reserved=0> &amp;data=02%7C01%7Cjovergar%40microsoft.com%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380980941&amp;sdata=R1R8rq0d0MyG36iSVeJwcP3UYRSb%2F4MafyW9Ir%2BNx2A%3D&amp;reserved=0

Signed-off-by: Jouni Malinen  <mailto:[email-masked]> <[email-masked]>

 
  Alan DeKok.
 
_______________________________________________
Emu mailing list
[email-masked] <mailto:[email-masked]> 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu&amp;data=02%7C01%7Cjovergar%40microsoft.com%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380980941&amp;sdata=1xjqVMXOl1D62KRGdzAggBjEIuBVMoIU6AisOnJEroo%3D&amp;reserved=0> &amp;data=02%7C01%7Cjovergar%40microsoft.com%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380980941&amp;sdata=1xjqVMXOl1D62KRGdzAggBjEIuBVMoIU6AisOnJEroo%3D&amp;reserved=0
 
_______________________________________________
Emu mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/emu