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

[Mohit Sethi M <[e-mail]>]

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:
>
> Hi Mohit,
>
> See below. Thanks for your super quick response.
>
> *From:* Mohit Sethi M <[e-mail]>
> *Sent:* Tuesday, June 16, 2020 12:25 PM
> *To:* Hannes Tschofenig <[e-mail]>; Mohit Sethi M 
> <[e-mail]>; [e-mail]
> *Subject:* Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13
>
> Hi Hannes,
>
> On 6/16/20 12:37 PM, Hannes Tschofenig wrote:
>
>     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.
>
> 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?
>
>      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?
>
> [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/
>
>     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,
>
>                                                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/
>
>     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-Success
>
>
>
>      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.
>
> [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
>
>     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 <[e-mail]>
>     <mailto:[e-mail]>
>     *Sent:* Monday, June 15, 2020 3:52 PM
>     *To:* Hannes Tschofenig <[e-mail]>
>     <mailto:[e-mail]>; [e-mail] <mailto:[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
>
>          2. 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  <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
>
>     [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.