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

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 12 Jun 2020 08:36:43 +0000

Hi all,

This has probably been discussed extensively in the EMU group. I am sorry to bring it up again but I believe this is a bad design decision. I raised it in my short review just sent to the list but I believe it is worthwhile to point it out separately.

draft-ietf-emu-eap-tls13 introduces a new message to EAP-TLS, namely the Commitment Message. This requires extra code in an implementation because the normal behavior would be to run a TLS stack and then send encrypted data.
EAP-TLS does, however, not send application data*. This message changes this. Not only does it not send encrypted application data it requires an implementation to transmit a plaintext application data record after the application traffic secret has been created and before that application traffic secret is used to protect post handshake messages. This will make it difficult to re-use an off-the-shelf TLS 1.3 stack.

There is very little motivation about this message other than

"

   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.

"

I might miss something important here but why cannot the EAP-Success or EAP-Failure serve that purpose?

Here are two examples to explain what I mean:

  1.  Failed exchange

    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

  1.  Successful Exchange with Post-Handshake NewSession Ticket

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

                                 <--------        Commitment Message)

    EAP-Response/

    EAP-Type=EAP-TLS             -------->

                                 <--------               EAP-Success

Ciao
Hannes

(*): FWIW Post handshake messages are protected with the application traffic secrets.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Mohit Sethi M <[email-masked]>
Date: Mon, 15 Jun 2020 13:51:55 +0000

Hi Hannes,

Unfortunately you are wrong here. The design decision was in fact taken to avoid changes to the underlying TLS implementation while also avoiding changes to RFC 3748. To summarize:

Jouni Malinen pointed out that mapping session resumption of TLS 1.3 to EAP-TLS is non-trivial. See his email here: https://mailarchive.ietf.org/arch/msg/emu/SBdblHmLQTbBwoZHK8Rih-g5ne8/. Essentially, TLS 1.3 allows a server to send a Post-Handshake message with a NewSessionTicket at any time. However, in EAP-TLS this is not possible. The TLS tunnel is torn down after authentication. John notes in his response to Jouni (https://mailarchive.ietf.org/arch/msg/emu/nNUw61cTvHgWj8F0sOVRoICUzlk/) "in TLS the connection is assumed to stay open for a long time after the client sends Finished, in EAP the connection is assumed to be closed shortly after."

An earlier cleaner way of sending NewSessionTicket required an extra round trip and left the peer uncertain about the next message (https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-00#section-2.1.1). Jouni highlighted this uncertainty for a peer: " the peer has no idea whether the NewSessionTicket is delivered after ClientFinished. In other words, the next message in the sequence could be either continuation of EAP-TLS method or EAP-Success". You ask "why cannot the EAP-Success or EAP-Failure serve that purpose?". See RFC 3748 (https://tools.ietf.org/html/rfc3748) which says the following:

   Implementation Note: Because the Success and Failure packets are not
   acknowledged, they are not retransmitted by the authenticator, and
   may be potentially lost.  A peer MUST allow for this circumstance as
   described in this note.

and

 On the peer, after success result indications have been exchanged by
   both sides, a Failure packet MUST be silently discarded.  The peer
   MAY, in the event that an EAP Success is not received, conclude that
   the EAP Success packet was lost and that authentication concluded
   successfully.

Thus, EAP-Success cannot be used as a reliable notification mechanism. Till version 05 of the document, we used an empty application data record as a notification of the last handshake message. The text said:

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 appending an empty application data record (i.e. a TLS
   record with TLSPlaintext.type = application_data and
   TLSPlaintext.length = 0) to the last handshake record.  After sending
   an empty application data record, the EAP server may only send an
   EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert
   Message.

However, Jouni in a later response (https://mailarchive.ietf.org/arch/msg/emu/WA8OREhTsF8JEPvaixGoCwmd1qY/) noted that such behavior is non-trivial to achieve with OpenSSL. He notes " OpenSSL is not willing to send such an empty TLSPlaintext structure. SSL_write() has following to say : 'You should not call SSL_write() with num=0, it will return an error. SSL_write_ex() can be called with num=0, but will not send application data to the peer.'"

Therefore, the text was later updated to:

 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.

There is still a challenge in scenarios where a server chooses not to issue any NewSessionTicket. In this email: https://mailarchive.ietf.org/arch/msg/emu/PgGjhmafbbSJCcQctDsFw7AvNmU/ Jouni notes this problem:

I did see some issues when OpenSSL 1.1.1 when disabling sending of
session tickets, though. The current draft indicates that the empty
Application Data payload would be send out in the same EAP packet with
the server's Finished message, i.e., before the server having
authenticated the peer. And this would be done without the peer having
used TLS early data (which is explicitly disallowed in the draft). That
combination did not work with my experiments since OpenSSL was rejecting
the SSL_write() operation after the server having written own Finished
message, but before having received the Finished message from the peer.
The OpenSSL documentation seemed to imply that SSL_write_early_data()
could be used by the server _if_ the client first sent early data.. At
least in my tests, OpenSSL rejected that call without early data from
the client.

This is why the current text also says the following:

 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.  In the case
   where the server sends the Commitment Message in a separate EAP-
   Request, the conversation will appear as shown in Figure 9.  After
   sending the Commitment Message, the EAP server may only send an EAP-
   Success, an EAP-Failure, or an EAP-Request with a TLS Alert Message.

Thus, the current design decision has been guided by parallel implementation experience and it is the best solution we could come up with (given all the practical limitations).

--Mohit

On 6/12/20 11:36 AM, Hannes Tschofenig wrote:
Hi all,

“

“

  1.  Failed exchange

    EAP Peer                                              EAP Server

                                                         EAP-Request/

                                 <--------                  Identity

    EAP-Response/

                                                         EAP-Request/

                                                    EAP-Type=EAP-TLS

                                 <--------                (TLS Start)

    EAP-Response/

    EAP-Type=EAP-TLS

                                                         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

    EAP-Response/

                                 <--------               EAP-Failure

    EAP Peer                                              EAP Server

                                                         EAP-Request/

                                 <--------                  Identity

    EAP-Response/

                                                         EAP-Request/

                                                    EAP-Type=EAP-TLS

                                 <--------                (TLS Start)

    EAP-Response/

    EAP-Type=EAP-TLS

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

    EAP-Response/

                                 <--------               EAP-Success

Ciao
Hannes

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 15 Jun 2020 14:41:54 +0000

Hi Mohit,

Thanks for the super-detailed response.

Give me till tomorrow to parse your response. Glad to hear that you talked about this topic already.

Ciao
Hannes

From: Mohit Sethi M <[email-masked]>
Sent: Monday, June 15, 2020 3:52 PM
To: Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13

Hi Hannes,

   described in this note.
and

   successfully.

   Message.

the client.

--Mohit

"

"

  1.  Failed exchange

    EAP Peer                                              EAP Server

                                                         EAP-Request/

                                 <--------                  Identity

    EAP-Response/

                                                         EAP-Request/

                                                    EAP-Type=EAP-TLS

                                 <--------                (TLS Start)

    EAP-Response/

    EAP-Type=EAP-TLS

                                                         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

    EAP-Response/

                                 <--------               EAP-Failure

    EAP Peer                                              EAP Server

                                                         EAP-Request/

                                 <--------                  Identity

    EAP-Response/

                                                         EAP-Request/

                                                    EAP-Type=EAP-TLS

                                 <--------                (TLS Start)

    EAP-Response/

    EAP-Type=EAP-TLS

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

    EAP-Response/

                                 <--------               EAP-Success

Ciao
Hannes

Emu mailing list

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 16 Jun 2020 09:37:58 +0000

Hi Mohit,

I had a chance to read through the emails you provided. A good discussion.

I can offer three solutions:

  1.  Use EAP-Success / EAP-Failure as an indication for the completion of the exchange, even if it is not a reliable notification mechanism. If the EAP peer does not receive the NewSessionTicket message then it does not matter because it is optional to use anyway. It will be a failure case anyway if the EAP-Success / EAP-Failure got lost. They EAP peer may not even know whether the exchange was successful despite correctly processing TLS handshake messages.

  1.  Demand that the NewSessionTicket is sent immediately after the Finished, very much like you currently demand that the Commitment Message is attached to the last message.

  1.  Use the Commitment Message as an application layer payload (encrypted as it should be). (Note that this has nothing to do with early data.) If the OpenSSL spec does not support an application layer message from the server right after the finish then it is not compliant to the TLS 1.3 RFC.

The current solution in the draft, for example, does not work with Mbed TLS because you cannot tell the stack to suddenly bypass the encryption layer (after successfully establishing it) to send a plaintext message.

Ciao
Hannes

Hi Hannes,

   described in this note.
and

   successfully.

   Message.

the client.

--Mohit

"

"

  1.  Failed exchange

    EAP Peer                                              EAP Server

                                                         EAP-Request/

                                 <--------                  Identity

    EAP-Response/

                                                         EAP-Request/

                                                    EAP-Type=EAP-TLS

                                 <--------                (TLS Start)

    EAP-Response/

    EAP-Type=EAP-TLS

                                                         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

    EAP-Response/

                                 <--------               EAP-Failure

    EAP Peer                                              EAP Server

                                                         EAP-Request/

                                 <--------                  Identity

    EAP-Response/

                                                         EAP-Request/

                                                    EAP-Type=EAP-TLS

                                 <--------                (TLS Start)

    EAP-Response/

    EAP-Type=EAP-TLS

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

    EAP-Response/

                                 <--------               EAP-Success

Ciao
Hannes

Emu mailing list

---

From: Mohit Sethi M <[email-masked]>
Date: Tue, 16 Jun 2020 10:25:14 +0000

Hi Hannes,

On 6/16/20 12:37 PM, Hannes Tschofenig wrote:
>  1. Use EAP-Success / EAP-Failure as an indication for the completion
>     of the exchange, even if it is not a reliable notification
>     mechanism. If the EAP peer does not receive the NewSessionTicket
>     message then it does not matter because it is optional to use
>     anyway. It will be a failure case anyway if the EAP-Success /
>     EAP-Failure got lost. They EAP peer may not even know whether the
>     exchange was successful despite correctly processing TLS handshake
>     messages.
>
I am uncomfortable doing this without updating RFC 3748. Not only will 
we be violating RFC 3748, we would still have the problem of peer 
uncertainty about the next message. It could be a NewSessionTicket or 
EAP-Success/Failure.
>
>  2. Demand that the NewSessionTicket is sent immediately after the
>     Finished, very much like you currently demand that the Commitment
>     Message is attached to the last message.
>
I assume that you imply immediately after the server has sent its TLS 
Finished (and not after the server has received the TLS Finished from 
the peer)? Are you also implying that a NewSessionTicket should always 
be sent out, regardless of whether a server wants or supports 
resumption? What if the server is issuing several tickets?
>
>  3. Use the Commitment Message as an application layer payload
>     (encrypted as it should be). (Note that this has nothing to do
>     with early data.) If the OpenSSL spec does not support an
>     application layer message from the server right after the finish
>     then it is not compliant to the TLS 1.3 RFC.
>
How would that work? How can server send encrypted application layer 
payload without having received the TLS Finished from the peer.

While I am open to discussing better alternatives, I think from an 
implementation perspective, it makes sense to have a definite 
notification mechanism for the server to notify the peer that no more 
post-handshake messages are to be expected.

--Mohit

> The current solution in the draft, for example, does not work with 
> Mbed TLS because you cannot tell the stack to suddenly bypass the 
> encryption layer (after successfully establishing it) to send a 
> plaintext message.
>
> Ciao
>
> Hannes
>
> *From:* Mohit Sethi M <[email-masked]>
> *Sent:* Monday, June 15, 2020 3:52 PM
> *To:* Hannes Tschofenig <[email-masked]>; [email-masked]
> *Subject:* Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13
>
> Hi Hannes,
>
> Unfortunately you are wrong here. The design decision was in fact 
> taken to avoid changes to the underlying TLS implementation while also 
> avoiding changes to RFC 3748. To summarize:
>
> Jouni Malinen pointed out that mapping session resumption of TLS 1.3 
> to EAP-TLS is non-trivial. See his email here: 
> https://mailarchive.ietf.org/arch/msg/emu/SBdblHmLQTbBwoZHK8Rih-g5ne8/. 
> Essentially, TLS 1.3 allows a server to send a Post-Handshake message 
> with a NewSessionTicket at any time. However, in EAP-TLS this is not 
> possible. The TLS tunnel is torn down after authentication. John notes 
> in his response to Jouni 
> (https://mailarchive.ietf.org/arch/msg/emu/nNUw61cTvHgWj8F0sOVRoICUzlk/) 
> "in TLS the connection is assumed to stay open for a long time after 
> the client sends Finished, in EAP the connection is assumed to be 
> closed shortly after."
>
> An earlier cleaner way of sending NewSessionTicket required an extra 
> round trip and left the peer uncertain about the next message 
> (https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-00#section-2.1.1). 
> Jouni highlighted this uncertainty for a peer: " the peer has no idea 
> whether the NewSessionTicket is delivered after ClientFinished. In 
> other words, the next message in the sequence could be either 
> continuation of EAP-TLS method or EAP-Success". You ask "why cannot 
> the EAP-Success or EAP-Failure serve that purpose?". See RFC 3748 
> (https://tools.ietf.org/html/rfc3748) which says the following:
>
> Thus, EAP-Success cannot be used as a reliable notification mechanism. 
> Till version 05 of the document, we used an empty application data 
> record as a notification of the last handshake message. The text said:
>
>         messages by appending an empty application data record (i..e. a TLS
>
> However, Jouni in a later response 
> (https://mailarchive.ietf.org/arch/msg/emu/WA8OREhTsF8JEPvaixGoCwmd1qY/) 
> noted that such behavior is non-trivial to achieve with OpenSSL. He 
> notes " OpenSSL is not willing to send such an empty TLSPlaintext 
> structure. SSL_write() has following to say : 'You should not call 
> SSL_write() with num=0, it will return an error. SSL_write_ex() can be 
> called with num=0, but will not send application data to the peer.'"
>
> There is still a challenge in scenarios where a server chooses not to 
> issue any NewSessionTicket. In this email: 
> https://mailarchive.ietf.org/arch/msg/emu/PgGjhmafbbSJCcQctDsFw7AvNmU/ 
> Jouni notes this problem:
>
>     message, but before having received the Finished message from the peer..
>
> Thus, the current design decision has been guided by parallel 
> implementation experience and it is the best solution we could come up 
> with (given all the practical limitations).
>
> --Mohit
>
>     This has probably been discussed extensively in the EMU group. I
>     am sorry to bring it up again but I believe this is a bad design
>     decision. I raised it in my short review just sent to the list but
>     I believe it is worthwhile to point it out separately.
>
>     draft-ietf-emu-eap-tls13 introduces a new message to EAP-TLS,
>     namely the Commitment Message. This requires extra code in an
>     implementation because the normal behavior would be to run a TLS
>     stack and then send encrypted data.
>
>     EAP-TLS does, however, not send application data*. This message
>     changes this. Not only does it not send encrypted application data
>     it requires an implementation to transmit a plaintext application
>     data record after the application traffic secret has been created
>     and before that application traffic secret is used to protect post
>     handshake messages. This will make it difficult to re-use an
>     off-the-shelf TLS 1.3 stack.
>
>     I might miss something important here but why cannot the
>     EAP-Success or EAP-Failure serve that purpose?
>
>      2. Successful Exchange with Post-Handshake NewSession Ticket
>
>         EAP Peer                                              EAP Server
>
>                                                              EAP-Request/
>
>                                      <--------                  Identity
>
>         EAP-Response/
>
>     IMPORTANT NOTICE: The contents of this email and any attachments
>     are confidential and may also be privileged. If you are not the
>     intended recipient, please notify the sender immediately and do
>     not disclose the contents to any other person, use it for any
>     purpose, or store or copy the information in any medium. Thank you.
>
>     [email-masked]  <mailto:[email-masked]>
>
>     https://www.ietf..org/mailman/listinfo/emu  <https://www.ietf.org/mailman/listinfo/emu>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose 
> the contents to any other person, use it for any purpose, or store or 
> copy the information in any medium. Thank you.
>
> [email-masked]

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 16 Jun 2020 10:43:40 +0000

Hi Mohit,

See below. Thanks for your super quick response.

From: Mohit Sethi M <[email-masked]>
Sent: Tuesday, June 16, 2020 12:25 PM
To: Hannes Tschofenig <[email-masked]>; Mohit Sethi M <[email-masked]>; [email-masked]
Subject: Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13

Hi Hannes,

  1.  Use EAP-Success / EAP-Failure as an indication for the completion of the exchange, even if it is not a reliable notification mechanism. If the EAP peer does not receive the NewSessionTicket message then it does not matter because it is optional to use anyway. It will be a failure case anyway if the EAP-Success / EAP-Failure got lost. They EAP peer may not even know whether the exchange was successful despite correctly processing TLS handshake messages.
I am uncomfortable doing this without updating RFC 3748. Not only will we be violating RFC 3748, we would still have the problem of peer uncertainty about the next message. It could be a NewSessionTicket or EAP-Success/Failure.

[Hannes] What is done in EAP today?

I assume that you imply immediately after the server has sent its TLS Finished (and not after the server has received the TLS Finished from the peer)? Are you also implying that a NewSessionTicket should always be sent out, regardless of whether a server wants or supports resumption? What if the server is issuing several tickets?

[Hannes] I would leave it as an option to send a NewSessionTicket but it is sent then it has to be in the last message. Here is the exchange:

Case 1: NewSessionTicket Message Sent

    EAP Peer                                              EAP Server

                                                         EAP-Request/
                                 <--------                  Identity
    EAP-Response/
                                 <--------              TLS Finished,
                                               TLS NewSessionTicket)
    EAP-Response/
    EAP-Type=EAP-TLS
   (TLS Certificate,
    TLS CertificateVerify,
    TLS Finished)                -------->
                                 <--------               EAP-Success

Case 2: No ticket sent

    EAP Peer                                              EAP Server

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

How would that work? How can server send encrypted application layer payload without having received the TLS Finished from the peer.

[Hannes] Here is a copy-and-paste from the TLS spec:

       Client                                           Server

Key  ^ ClientHello
Exch | + key_share*
     | + signature_algorithms*
     | + psk_key_exchange_modes*
     v + pre_shared_key*       -------->
                                                  ServerHello  ^ Key
                                                 + key_share*  | Exch
                                            + pre_shared_key*  v
                                        {EncryptedExtensions}  ^  Server
                                        {CertificateRequest*}  v  Params
                                               {Certificate*}  ^
                                         {CertificateVerify*}  | Auth
                                                   {Finished}  v
                               <--------  [Application Data*]
     ^ {Certificate*}
Auth | {CertificateVerify*}
     v {Finished}              -------->
       [Application Data]      <------->  [Application Data]

The TLS 1.3 spec says:
   Note that while the
   server may send Application Data prior to receiving the client's
   Authentication messages, any data sent at that point is, of course,
   being sent to an unauthenticated peer.

The question is whether the aspect of sending data to an unauthenticated peer matters in this case? I would argue that it does not matter because the currently defined Commitment message is unencrypted.

While I am open to discussing better alternatives, I think from an implementation perspective, it makes sense to have a definite notification mechanism for the server to notify the peer that no more post-handshake messages are to be expected.

[Hannes] I am trying to find out how to implement this functionality into our stack and it looks painful (developer-visible API changes). Of course, it is difficult to accommodate for not yet invented post-handshake authentication messages. We don't even know whether they will be compatible with the network access authentication use case.

Ciao

Hannes

PS: I believe it would be good to highlight this specific aspect in the introduction of the document. For me it appeared that the specification is largely a copy-and-paste job but this clearly is something worth highlighting to the reader/implementer.

--Mohit

Ciao
Hannes

From: Mohit Sethi M <[email-masked]><mailto:[email-masked]>
Sent: Monday, June 15, 2020 3:52 PM
To: Hannes Tschofenig <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13

Hi Hannes,

   described in this note.
and

   successfully.

   Message.

the client.

--Mohit

"

"

  1.  Failed exchange

    EAP Peer                                              EAP Server

                                                         EAP-Request/

                                 <--------                  Identity

    EAP-Response/

                                                         EAP-Request/

                                                    EAP-Type=EAP-TLS

                                 <--------                (TLS Start)

    EAP-Response/

    EAP-Type=EAP-TLS

                                                         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

    EAP-Response/

                                 <--------               EAP-Failure

    EAP Peer                                              EAP Server

                                                         EAP-Request/

                                 <--------                  Identity

    EAP-Response/

                                                         EAP-Request/

                                                    EAP-Type=EAP-TLS

                                 <--------                (TLS Start)

    EAP-Response/

    EAP-Type=EAP-TLS

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

    EAP-Response/

                                 <--------               EAP-Success

Ciao
Hannes

Emu mailing list

https://www.ietf..org/mailman/listinfo/emu<https://www.ietf.org/mailman/listinfo/emu>
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Emu mailing list

---

From: Mohit Sethi M <[email-masked]>
Date: Tue, 16 Jun 2020 10:57:50 +0000

Hi Hannes,

Thanks for you super quick response too.

Based on your feedback, I am leaning towards :

> Use the Commitment Message as an application layer payload (encrypted 
> as it should be). (Note that this has nothing to do with early data.) 
> If the OpenSSL spec does not support an application layer message from 
> the server right after the finish then it is not compliant to the TLS 
> 1.3 RFC. 

It would also result in the smallest change to the current 
specification. Only the description of how the commitment message is 
constructed needs to be changed. I agree that sending a notification to 
an unauthenticated peer in this case is fine.

I wonder how others feel about this change.

--Mohit

On 6/16/20 1:43 PM, Hannes Tschofenig wrote:
> *Sent:* Tuesday, June 16, 2020 12:25 PM
> *To:* Hannes Tschofenig <[email-masked]>; Mohit Sethi M 
> <[email-masked]>; [email-masked]
>      1. Use EAP-Success / EAP-Failure as an indication for the
>         completion of the exchange, even if it is not a reliable
>         notification mechanism. If the EAP peer does not receive the
>         NewSessionTicket message then it does not matter because it is
>         optional to use anyway. It will be a failure case anyway if
>         the EAP-Success / EAP-Failure got lost. They EAP peer may not
>         even know whether the exchange was successful despite
>         correctly processing TLS handshake messages.
>
>         Finished, very much like you currently demand that the
>         Commitment Message is attached to the last message.
>
> [Hannes] I would leave it as an option to send a NewSessionTicket but 
> it is sent then it has to be in the last message. Here is the exchange:
>
>         application layer message from the server right after the
>         finish then it is not compliant to the TLS 1.3 RFC.
>
> The question is whether the aspect of sending data to an 
> unauthenticated peer matters in this case? I would argue that it does 
> not matter because the currently defined Commitment message is 
> unencrypted.
>
> [Hannes] I am trying to find out how to implement this functionality 
> into our stack and it looks painful (developer-visible API changes). 
> Of course, it is difficult to accommodate for not yet invented 
> post-handshake authentication messages. We don’t even know whether 
> they will be compatible with the network access authentication use case.
>
> Ciao
>
> Hannes
>
> PS: I believe it would be good to highlight this specific aspect in 
> the introduction of the document. For me it appeared that the 
> specification is largely a copy-and-paste job but this clearly is 
> something worth highlighting to the reader/implementer.
>
> --Mohit
>
>     <mailto:[email-masked]>
>     *To:* Hannes Tschofenig <[email-masked]>
>     <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>     taken to avoid changes to the underlying TLS implementation while
>     also avoiding changes to RFC 3748. To summarize:
>
>     Jouni Malinen pointed out that mapping session resumption of TLS
>     1.3 to EAP-TLS is non-trivial. See his email here:
>     Essentially, TLS 1.3 allows a server to send a Post-Handshake
>     message with a NewSessionTicket at any time. However, in EAP-TLS
>     this is not possible. The TLS tunnel is torn down after
>     authentication. John notes in his response to Jouni
>     "in TLS the connection is assumed to stay open for a long time
>     after the client sends Finished, in EAP the connection is assumed
>     to be closed shortly after."
>
>     An earlier cleaner way of sending NewSessionTicket required an
>     extra round trip and left the peer uncertain about the next
>     message
>     Jouni highlighted this uncertainty for a peer: " the peer has no
>     idea whether the NewSessionTicket is delivered after
>     ClientFinished. In other words, the next message in the sequence
>     could be either continuation of EAP-TLS method or EAP-Success".
>     You ask "why cannot the EAP-Success or EAP-Failure serve that
>     purpose?". See RFC 3748 (https://tools.ietf.org/html/rfc3748)
>     which says the following:
>
>     Thus, EAP-Success cannot be used as a reliable notification
>     mechanism. Till version 05 of the document, we used an empty
>     application data record as a notification of the last handshake
>     message. The text said:
>
>     noted that such behavior is non-trivial to achieve with OpenSSL.
>     He notes " OpenSSL is not willing to send such an empty
>     TLSPlaintext structure. SSL_write() has following to say : 'You
>     should not call SSL_write() with num=0, it will return an error.
>     SSL_write_ex() can be called with num=0, but will not send
>     application data to the peer.'"
>
>     There is still a challenge in scenarios where a server chooses not
>     to issue any NewSessionTicket. In this email:
>     implementation experience and it is the best solution we could
>     come up with (given all the practical limitations).
>
>     --Mohit
>
>         This has probably been discussed extensively in the EMU group.
>         I am sorry to bring it up again but I believe this is a bad
>         design decision. I raised it in my short review just sent to
>         the list but I believe it is worthwhile to point it out
>         separately.
>
>         implementation because the normal behavior would be to run a
>         TLS stack and then send encrypted data.
>
>         EAP-TLS does, however, not send application data*. This
>         message changes this. Not only does it not send encrypted
>         application data it requires an implementation to transmit a
>         plaintext application data record after the application
>         traffic secret has been created and before that application
>         traffic secret is used to protect post handshake messages.
>         This will make it difficult to re-use an off-the-shelf TLS 1.3
>         stack.
>
>             EAP Peer                                              EAP
>         Server
>                                          <--------                 
>         Identity
>                                          <--------                (TLS
>         Start)
>                                                             (TLS
>         ServerHello,
>                                                      TLS
>         EncryptedExtensions,
>                                                       TLS
>         CertificateRequest,
>                                                              TLS
>         Certificate,
>                                                        TLS
>         CertificateVerify,
>                                                                 TLS
>         Finished,
>             EAP Peer                                              EAP
>         Server
>                                          <--------                 
>         Identity
>                                          <--------                (TLS
>         Start)
>                                                             (TLS
>         ServerHello,
>                                                      TLS
>         EncryptedExtensions,
>                                                       TLS
>         CertificateRequest,
>                                                              TLS
>         Certificate,
>                                                        TLS
>         CertificateVerify,
>                                          <--------              TLS
>         Finished)
>                                                        (TLS
>         NewSessionTicket,
>         IMPORTANT NOTICE: The contents of this email and any
>         attachments are confidential and may also be privileged. If
>         you are not the intended recipient, please notify the sender
>         immediately and do not disclose the contents to any other
>         person, use it for any purpose, or store or copy the
>         information in any medium. Thank you.
>
>