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

[Hannes Tschofenig <[e-mail]>]

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 <[e-mail]>
Sent: Monday, June 15, 2020 3:52 PM
To: Hannes Tschofenig <[e-mail]>; [e-mail]
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:

   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,

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.


_______________________________________________

Emu mailing list

[e-mail]<mailto:[e-mail]>

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.