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

From: John Mattsson <[email-masked]>
Date: Tue, 1 Sep 2020 08:10:00 +0000

Hi,

Note that close_notify (no more data) is not an exact replacement for the Commitment Message (no more handshake data). A change from 0x00 to close_notify invalidates Figure 6: EAP-TLS unsuccessful client authentication in the document.

    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,
                                 <--------        Commitment Message)
    EAP-Response/
    EAP-Type=EAP-TLS
   (TLS Certificate,
    TLS CertificateVerify,
    TLS Finished)                -------->
                                                         EAP-Request/
                                                    EAP-Type=EAP-TLS
                                 <--------          (TLS Fatal Alert)
    EAP-Response/
    EAP-Type=EAP-TLS             -------->
                                 <--------               EAP-Failure

           Figure 6: EAP-TLS unsuccessful client authentication

If the Commitment Message is changed to close_notify, the TLS Fatal Alert would have to be changed to an EAP-Failure instead. The difference is that The TLS Fatal Alert can contain information such as 

   bad_certificate,  unsupported_certificate,  certificate_revoked,  certificate_expired, certificate_unknown,  illegal_parameter, unknown_ca, access_denied, etc. while EAP-Failure must not contain any additional data.

I don't have any strong preferences but if we change to close_notify, then Figure 6 needs to be updated.

Cheers,
John

-----Original Message-----
From: Emu <[email-masked]> on behalf of Mohit Sethi M <mohit.m.sethi=[email-masked]>
Date: Wednesday, 5 August 2020 at 11:31
To: Alan DeKok <[email-masked]>, Jorge Vergara <[email-masked]>
Cc: Mohit Sethi M <[email-masked]>, Benjamin Kaduk <[email-masked]>, EMU WG <[email-masked]>
Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3

    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://protect2.fireeye.com/v1/url?k=6a599c40-34f9328d-6a59dcdb-866132fe445e-b8526f21b1021465&q=1&e=bf6ddc28-bb64-4bb0-bea7-defe210b15fd&u=https%3A%2F%2Fgithub.com%2Femu-wg%2Fdraft-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:
    > On Aug 3, 2020, at 2:23 PM, Jorge Vergara <[email-masked]> wrote:
    >> 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.
    >
    > _______________________________________________
    > Emu mailing list
    > [email-masked]
    > https://www.ietf.org/mailman/listinfo/emu
    _______________________________________________
    Emu mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/emu

---

From: John Mattsson <[email-masked]>
Date: Tue, 1 Sep 2020 12:24:41 +0000

Hi,

Reading up on the mail discussion more (I have been on parental leave), I don't see any real motivation for this late technical change suggestion...

Hannes wrote that the draft-ietf-emu-eap-tls13 does not work with Mbed because it introduces a new message and requires unencrypted data. One of Hannes suggestions for change was that:

"Use the Commitment Message as an application layer payload (encrypted as it should be)."

This suggestion is exactly my understanding of how draft-ietf-emu-eap-tls13-10 works. At least it is exactly what I intended when I wrote the sections in question. I don't see why anybody would get the impressions that the application data would be unencrypted, all application data in TLS 1.3 is encrypted.

To summarize, I don't see that there is a real motivation for late technical change. That Hannes misunderstood the draft seems like a reason to add some clarification text. 

If we change the specification to use close_notify:

- we need to also update Figure 6 

- do we still want to have the flexibilty that "The close_notify alert may be sent in the same EAP-Request as the last handshake record or in a separate EAP-Request."? The flexibility was added to be compatible with OpenSSL that where not compatible with RFC8446. But keeping the flexibility with close_notify allows the server to chose between an extra round-trip and the ability to send a TLS Fatal Alert as a result of unsuccessful client authentication.

Cheers,
John

-----Original Message-----
From: Emu <[email-masked]> on behalf of John Mattsson <john.mattsson=[email-masked]>
Date: Tuesday, 1 September 2020 at 10:10
To: Mohit Sethi M <mohit.m.sethi=[email-masked]>, Alan DeKok <[email-masked]>, Jorge Vergara <[email-masked]>
Cc: Mohit Sethi M <[email-masked]>, Benjamin Kaduk <[email-masked]>, EMU WG <[email-masked]>
Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3

    Hi,

        EAP Peer                                              EAP Server

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

                                                             EAP-Request/
                                                        EAP-Type=EAP-TLS
                                     <--------                (TLS Start)
        EAP-Response/
        EAP-Type=EAP-TLS

    Cheers,
    John

    -----Original Message-----
    From: Emu <[email-masked]> on behalf of Mohit Sethi M <mohit.m.sethi=[email-masked]>
    Date: Wednesday, 5 August 2020 at 11:31
    To: Alan DeKok <[email-masked]>, Jorge Vergara <[email-masked]>
    Cc: Mohit Sethi M <[email-masked]>, Benjamin Kaduk <[email-masked]>, EMU WG <[email-masked]>
    Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3

        --Mohit

---

From: Alan DeKok <[email-masked]>
Date: Tue, 1 Sep 2020 08:50:56 -0400

> Reading up on the mail discussion more (I have been on parental leave), I don't see any real motivation for this late technical change suggestion...

  My $0.02 is that it's philosophical.  EAP-TLS does authentication using TLS.  Adding an extra zero byte seems weird.  It's a hack to get around limitations of protocol and/or implementations.

> - do we still want to have the flexibilty that "The close_notify alert may be sent in the same EAP-Request as the last handshake record or in a separate EAP-Request."? The flexibility was added to…

  In my experience, the TLS Fatal Alert is incredibly useful.  It would be very, very, bad to remove that from the spec.  Doing so would mean that failed authentications get an error of "failed", instead of something descriptive.  And IMHO there's a special place for people who use content-free error messages.

  So my priorities are:

* EAP failure MUST (where possible) get an informative TLS Fatal Alert back to the peer
* it would be nice to remove the "send 1 byte of 0x00" hack, as it's philosophically weird

  I think it would be acceptable to send 1 byte of 0x00 when an EAP failure occurred.  We know that the user won't be authenticated, so we don't care about extra data stuffed into the TLS session.

  Alan DeKok.

---

From: John Mattsson <[email-masked]>
Date: Tue, 1 Sep 2020 14:23:53 +0000

Hi,

If the ability to send a descriptive TLS Fatal Alert back to the peer is a requirement, changing to close_notify seems like a bad idea. My understanding is that is would add an extra roundtrip without any clear benefits compared to sending an encrypted 0x00 application data.

    EAP Peer                                              EAP Server

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

                  Figure 1: EAP-TLS mutual authentication

vs.

    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
                                 <--------          TLS close_notify)
    EAP-Response/
    EAP-Type=EAP-TLS             -------->
                                 <--------               EAP-Success

                  Figure 1: EAP-TLS mutual authentication

Cheers,
John

-----Original Message-----
From: Alan DeKok <[email-masked]>
Date: Tuesday, 1 September 2020 at 14:51
To: John Mattsson <[email-masked]>
Cc: John Mattsson <john.mattsson=[email-masked]>, Mohit Sethi M <mohit.m.sethi=[email-masked]>, Jorge Vergara <[email-masked]>, Mohit Sethi M <[email-masked]>, Benjamin Kaduk <[email-masked]>, EMU WG <[email-masked]>
Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3

      So my priorities are:

      Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 2 Sep 2020 13:33:11 -0400

On Sep 1, 2020, at 10:23 AM, John Mattsson <[email-masked]> wrote:
> 
> If the ability to send a descriptive TLS Fatal Alert back to the peer is a requirement, changing to close_notify seems like a bad idea.

  It's fine for EAP Success.  But having two different code paths is a little surprising.

> My understanding is that is would add an extra roundtrip without any clear benefits compared to sending an encrypted 0x00 application data.

  That's a reason to stick with sending 0x00, then.

  Alan DeKok.

---

From: Jorge Vergara <[email-masked]>
Date: Thu, 17 Sep 2020 16:44:33 +0000

Does anyone else have any other thoughts on this? I'm not a TLS expert but similarly value the TLS Fatal Alerts over using close_notify. If we will be losing alerts then I would favor switching back to 0x00.

Jorge Vergara

-----Original Message-----
From: Alan DeKok <[email-masked]> 
Sent: Wednesday, September 2, 2020 10:33 AM
To: John Mattsson <[email-masked]>
Cc: John Mattsson <john.mattsson=[email-masked]>; Mohit Sethi M <mohit.m.sethi=[email-masked]>; Jorge Vergara <[email-masked]>; Mohit Sethi M <[email-masked]>; Benjamin Kaduk <[email-masked]>; EMU WG <[email-masked]>
Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 22 Sep 2020 09:17:43 -0400

> Does anyone else have any other thoughts on this? I'm not a TLS expert but similarly value the TLS Fatal Alerts over using close_notify. If we will be losing alerts then I would favor switching bac…

  In the absence of further discussion, I would suggest staying with 0x00.

  I'll go poke some code. :)

  Alan DeKok.

---

From: John Mattsson <[email-masked]>
Date: Tue, 22 Sep 2020 14:35:33 +0000

If we are going back to an encrypted application message with 0x00, how do we update the draft to make it clear that the commitment message is encrypted? Several people understood that 0x00 was supposed to not be encrypted. Is something incorrect in draft-ietf-emu-eap-tls13-10, or it there just a need to add a note like:

"Note that in TLS 1.3, all application data including the Commitment Message is protected through authenticated encryption."?

John

-----Original Message-----
From: Alan DeKok <[email-masked]>
Date: Tuesday, 22 September 2020 at 15:17
To: Jorge Vergara <[email-masked]>
Cc: John Mattsson <[email-masked]>, Mohit Sethi M <[email-masked]>, Benjamin Kaduk <[email-masked]>, EMU WG <[email-masked]>
Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 22 Sep 2020 11:22:45 -0400

> "Note that in TLS 1.3, all application data including the Commitment Message is protected through authenticated encryption."?

  That seems fine to me.  Section 2.5 already states that 0x00 is the plaintext, and that plaintext length != encrypted length.

  Alan DeKok.