Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3

From: Alan DeKok <[email-masked]>
Date: Sat, 1 Aug 2020 09:52:47 -0400

On Jul 31, 2020, at 12:30 PM, Jim Schaad <[email-masked]> wrote:
> 
> Ok – so this issue was raised at IETF 102.  (presentation https://www.ietf.org/proceedings/102/slides/slides-102-emu-eap-tls-with-tls-13-00)
>  
> Just reading the slides is not telling me what was the problem.  I think I am going to need to hear the audio of the presentation.  I have an extremely vague memory that there was an OpenSSL problem involved here but I would not swear to that.  You might be a better description either from John Mattsson or Jouni.

  IIRC it's that OpenSSL doesn't have an API to send a zero bytes of application data.  I think other TLS implementations have similar limitations.

  Regardless of what solution is implemented, the requirement is to have a positive acknowledgement that TLS setup is finished.  This step seems to be missing by default in TLS 1.3.

  I suspect that most uses of TLS will *always* send application data.  Which makes EAP-TLS an outlier.  Hence the need for hacks like "send application data as one octet of zero".

  Alan DeKok.

---

From: Jim Schaad <[email-masked]>
Date: Sat, 1 Aug 2020 08:23:01 -0700

-----Original Message-----
From: Alan DeKok <[email-masked]> 
Sent: Saturday, August 1, 2020 6:53 AM
To: Jim Schaad <[email-masked]>
Cc: Mohit Sethi M <[email-masked]>; EMU WG <[email-masked]>; Benjamin Kaduk <[email-masked]>
Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3

[JLS]  Cobwebs are slowly being shaken out of my brain.  
*  I made an incorrect statement yesterday because I got EAP-TEAP and EAP-TLS confused.  Not surprising because I only ever spent any time on EAP-TEAP .  In EAP-TLS, once the handshake has been completed the tunnel does not need to be kept open.  This is the opposite of the case for EAP-TEAP where the tunnel is used for application EAP data.

* Based on that I agree with EKR that the close notification could be used instead of sending the one byte of application data.   Sending the close notification means that the server will no longer be sending any data and thus would not send any new session tickets.

EAP Peer                                              EAP Server

                                                         EAP-Request/
                                 <--------                  Identity
    EAP-Response/
    Identity (Privacy-Friendly)  -------->
                                                         EAP-Request/
                                                    EAP-Type=EAP-TLS
                                 <--------                (TLS Start)
    EAP-Response/
    EAP-Type=EAP-TLS
   (TLS ClientHello)             -------->
                                                         EAP-Request/
                                                    EAP-Type=EAP-TLS
                                                    (TLS ServerHello,
                                             TLS EncryptedExtensions,
                                              TLS CertificateRequest,
                                                     TLS Certificate,
                                               TLS CertificateVerify,
                                 <--------              TLS Finished)
    EAP-Response/
    EAP-Type=EAP-TLS
   (TLS Certificate,
    TLS CertificateVerify,
    TLS Finished)                -------->
                                                         EAP-Request/
                                                    EAP-Type=EAP-TLS
                                 <--------        (close_notify)
    EAP-Response/
    EAP-Type=EAP-TLS             -------->
                                 <--------               EAP-Success

Jim

  Alan DeKok.

---

From: Jorge Vergara <[email-masked]>
Date: Mon, 3 Aug 2020 18:23:45 +0000

ACK that EAP-TLS does not need to keep the connection open.

Question: should some consideration be given to consistency with other EAP methods that do need to keep the connection open? i.e. PEAP/EAP-TTLS/TEAP

Jorge

-----Original Message-----
From: Emu <[email-masked]> On Behalf Of Jim Schaad
Sent: Saturday, August 1, 2020 8:23 AM
To: 'Alan DeKok' <[email-masked]>
Cc: 'Mohit Sethi M' <[email-masked]>; 'EMU WG' <[email-masked]>; 'Benjamin Kaduk' <[email-masked]>
Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3

-----Original Message-----
From: Alan DeKok <[email-masked]> 
Sent: Saturday, August 1, 2020 6:53 AM
To: Jim Schaad <[email-masked]>
Cc: Mohit Sethi M <[email-masked]>; EMU WG <[email-masked]>; Benjamin Kaduk <[email-masked]>
Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3

On Jul 31, 2020, at 12:30 PM, Jim Schaad <[email-masked]> wrote:
> 
> Ok – so this issue was raised at IETF 102.  (presentation https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fproceedings%2F102%2Fslides%2Fslides-102-emu-eap-tls-with-tls-13-00&amp;data=02%7C01%7Cjovergar%40microsoft.com%7C79f98e3e6f7f49971c4608d8362ed351%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637318922028443984&amp;sdata=nExLYi6p0JNNeZ8TZsfXkRIm53%2BHuUidEhU2GrrioA4%3D&amp;reserved=0)
>  

EAP Peer                                              EAP Server

                                                         EAP-Request/
                                 <--------                  Identity
    EAP-Response/

Jim

  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%7C79f98e3e6f7f49971c4608d8362ed351%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637318922028448974&amp;sdata=c40nE5bUpT69CYY9qDNx7dRyVWzFRqgoKcUvgV0p9yE%3D&amp;reserved=0

---

From: Alan DeKok <[email-masked]>
Date: Tue, 4 Aug 2020 13:15:36 -0400

> ACK that EAP-TLS does not need to keep the connection open.

  I agree.  I'm happy to change the implementations to send "close notify".

> Question: should some consideration be given to consistency with other EAP methods that do need to keep the connection open? i.e. PEAP/EAP-TTLS/TEAP

  When those methods send application data, they don't need to do anything else.

  When those methods use fast reconnect, they don't send application data.  So the other EAP methods should also send "close notify" in that case.

  Alan DeKok.

---

From: Jim Schaad <[email-masked]>
Date: Tue, 4 Aug 2020 10:34:07 -0700

I think it might be a good idea to specify that the close_notify is always
sent when the TLS channel is closed.  I was thinking that if we really
wanted a content on the EAP Response, then it be reasonable to have the
client respond with a close_notify as well.

-----Original Message-----
From: Alan DeKok <[email-masked]> 
Sent: Tuesday, August 4, 2020 10:16 AM
To: Jorge Vergara <[email-masked]>
Cc: Jim Schaad <[email-masked]>; Mohit Sethi M
<[email-masked]>; EMU WG <[email-masked]>; Benjamin Kaduk
<[email-masked]>
Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3

> Question: should some consideration be given to consistency with other EAP
methods that do need to keep the connection open? i.e. PEAP/EAP-TTLS/TEAP

  When those methods send application data, they don't need to do anything
else.

  When those methods use fast reconnect, they don't send application data.
So the other EAP methods should also send "close notify" in that case.

  Alan DeKok.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 4 Aug 2020 14:17:55 -0700

Hi Mohit,

Sorry for the slow response.

On Fri, Jul 31, 2020 at 02:08:44PM +0000, Mohit Sethi M wrote:
> Dear all,
> 
> Thanks all for the discussion on the commitment message.
> 
> draft-ietf-emu-eap-tls13-10 (https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-10) in figure 2 shows the ticket establishment and commitment message:
[snip]
> 
> and the relevant text on commitment message:
> 
> 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

[reordering]
> 
> I couldn't parse the comments about the "KeyUpdate" message. Perhaps having the discussion over email will help me understand the issue.
> 

I was referring to the specific promise to not send any more *handshake*
messages here -- the only currently defined handshake messages that the EAP
server could be sending are NewSessionTicket and KeyUpdate.  (Okay, or
EKTKey from draft-ietf-per-srtp-ekt-diet, but EAP is not using that at
all.)  I was not sure if the need was to avoid sending KeyUpdate vs.
NewSessionTicket, and why the application layer needed to be concerned with
it at all -- to some extent both can be handled internally by the TLS
implementation.  The application probably wants to get involved if it wants
to resume using a session ticket, but it's permitted to just drop the
tickets on the floor and never use them.

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

This construction feels weird to me because it's using application data to
try to make a promise about the TLS layer, which is a fragile construction
and could break if there are changes to the TLS implementation without
corresponding changes to the application code.  In general, the application
will not even know when/whether the TLS implementation is going to send
more messages (though it would be fairly surprising for the TLS
implementation to spontaneously send stuff in the absence of other
application messages).
Using close_notify as we seem to be agreeing upon feels better since it's
the TLS-layer mechanism for doing so and the TLS implementation is expected
to do the right thing in terms of not sending more messages, once it's sent
or received.

-Ben

---

From: Mohit Sethi M <[email-masked]>
Date: Wed, 5 Aug 2020 09:31:28 +0000

I seem to agree with the consensus around the usage of close_notify 
instead of a byte of 0x00. In fact, I can't even remember the reason for 
that choice anymore.

The draft is now updated in github to specify the usage of close_notify:
https://github.com/emu-wg/draft-ietf-emu-eap-tls13

Here is the diff for your convenience:

https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-emu-eap-tls13.txt&url2=https://emu-wg.github.io/draft-ietf-emu-eap-tls13/draft-ietf-emu-eap-tls13.txt

This edit probably still requires some sanity checking. I will wait 
until we have confirmation from the different implementations before 
cleaning up and publishing a new version.

--Mohit

On 8/4/20 8:15 PM, Alan DeKok wrote:
> https://www.ietf.org/mailman/listinfo/emu