Hi Alan, Jorge, Jim, Hannes, One octet of plaintext naturally results in a larger encrypted record (which serves as the notification). The current text only explains how to construct the encrypted record by setting the TLSPlaintext to one octet of zeros.
RFC 8446 in any case says the following in Section 5.1. Record Layer: "Application Data messages contain data that is opaque to TLS. Application Data messages are always protected." Perhaps the text can be made more explicit as follows: 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 an encyrpted Commitment Message. The Commitment Message is an encyrpted TLS record constructed with application data 0x00 (i.e. a TLS record with TLSPlaintext.type = application_data, TLSPlaintext.length = 1, and TLSPlaintext.fragment = 0x00). Note that the length of the plaintext is greater than the corresponding TLSPlaintext.length due to the inclusion of TLSInnerPlaintext.type and any padding supplied by the sender. EAP server implementations MUST set TLSPlaintext.fragment to 0x00, but EAP peer implementations MUST accept any application data as a Commitment Message from the EAP server to not send any more handshake messages. The Commitment Message may be sent in the same EAP-Request as the last handshake record or in a separate EAP-Request. Sending the Commitment Message in a separate EAP-Request adds an additional round-trip, but may be necessary in TLS implementations that only implement a subset of TLS 1.3. Is this amenable to all? --Mohit On 7/13/20 9:24 PM, Jorge Vergara wrote: Windows expects an encrypted octet. My brain had automatically translated the plaintext -> encrypted based on the timing of the commitment message - which was apparently an incorrect translation at the time. Interop has been tested with FreeRADIUS and hostapd. -----Original Message----- From: Emu <emu-boun...@ietf.org><mailto:emu-boun...@ietf.org> On Behalf Of Alan DeKok Sent: Monday, July 13, 2020 10:52 AM To: Mohit Sethi M <mohit.m.se...@ericsson.com><mailto:mohit.m.se...@ericsson.com> Cc: Roman Danyliw <r...@cert.org><mailto:r...@cert.org>; emu@ietf.org<mailto:emu@ietf.org> Subject: Re: [Emu] Finishing draft-ietf-emu-eap-tls13 - Commitment Message handling On Jul 13, 2020, at 1:44 PM, Mohit Sethi M <mohit.m.se...@ericsson.com><mailto:mohit.m.se...@ericsson.com> wrote: Dear all, draft-ietf-emu-eap-tls13 is currently in the state "AD Evaluation::AD Followup". Our AD (Roman) had done an excellent review (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Femu%2Fk6K98OhuOQmbzSAgGWCtSIVv3Qk%2F&data=02%7C01%7Cjovergar%40microsoft.com%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380970944&sdata=mfYGmzLt9zC%2BDBmqGzeFmx%2Bq8XdZG%2Bd0JefKvwSSQ%2Bw%3D&reserved=0), which I addressed in version 10 (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Femu%2FIopJTjefyVVKpObzyFc0CAJ-Pig%2F&data=02%7C01%7Cjovergar%40microsoft.com%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380970944&sdata=%2FWzCNaXEnxX9adDHjLHKHmH0aYyG3CV4cqpyRSP7yF4%3D&reserved=0). ... Hannes says that this is not ideal and cannot be achieved with mbed TLS 1.3 implementation. He made 3 alternative suggestions for achieving the functionality of the commitment message (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Femu%2FeM-14QdDQjg7DvhAVJMzpvPz5wg%2F&data=02%7C01%7Cjovergar%40microsoft.com%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380980941&sdata=umbXQTG0%2FLJN6IrXI%2BjgrQME6mE3UtmI7nOTAdghl7M%3D&reserved=0). I would like to close this issue and would like to receive feedback from others who have commented before or are working on implementations: Jim, Alan, Jouni; please let us know what do you think about the change? hostap sends an encrypted octet. See https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw1.fi%2Fcgit%2Fhostap%2Fcommit%2F%3Fid%3D36ec5881657157752dced741256441c230e42fe6&data=02%7C01%7Cjovergar%40microsoft.com%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380980941&sdata=R1R8rq0d0MyG36iSVeJwcP3UYRSb%2F4MafyW9Ir%2BNx2A%3D&reserved=0 EAP-TLS server: Add application data to indicate end of v1.3 handshake This adds an encrypted version of a one octet application data payload to the end of the handshake when TLS v1.3 is used to indicate explicit termination of the handshake (either after Finished message or after the optional NewSessionTicket message). The current draft-ietf-emu-eap-tls13-05 defines this to be a zero length payload, but since that is not allowed by OpenSSL, use a one octet payload instead for now with hopes of getting the draft specification updated instead of having to modify OpenSSL for this. Signed-off-by: Jouni Malinen <j...@w1.fi><mailto:j...@w1.fi> FreeRADIUS does the same, as of recent commits in the v3.0.x branch. We've successfully tested interoperability. So I think it's fine to send the one octet as *encrypted* data, and not *plaintext*. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org<mailto:Emu@ietf.org> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu&data=02%7C01%7Cjovergar%40microsoft.com%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380980941&sdata=1xjqVMXOl1D62KRGdzAggBjEIuBVMoIU6AisOnJEroo%3D&reserved=0 _______________________________________________ Emu mailing list Emu@ietf.org<mailto:Emu@ietf.org> https://www.ietf.org/mailman/listinfo/emu
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
