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

[Jorge Vergara <[e-mail]>]

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 <[e-mail]> On Behalf Of Alan DeKok
Sent: Monday, July 13, 2020 10:52 AM
To: Mohit Sethi M <[e-mail]>
Cc: Roman Danyliw <[e-mail]>; [e-mail]
Subject: Re: [Emu] Finishing draft-ietf-emu-eap-tls13 - Commitment Message handling

On Jul 13, 2020, at 1:44 PM, Mohit Sethi M <[e-mail]> 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&amp;data=02%7C01%7Cjovergar%40microsoft.com%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380970944&amp;sdata=mfYGmzLt9zC%2BDBmqGzeFmx%2Bq8XdZG%2Bd0JefKvwSSQ%2Bw%3D&amp;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&amp;data=02%7C01%7Cjovergar%40microsoft.com%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380970944&amp;sdata=%2FWzCNaXEnxX9adDHjLHKHmH0aYyG3CV4cqpyRSP7yF4%3D&amp;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&amp;data=02%7C01%7Cjovergar%40microsoft.com%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380980941&amp;sdata=umbXQTG0%2FLJN6IrXI%2BjgrQME6mE3UtmI7nOTAdghl7M%3D&amp;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&amp;data=02%7C01%7Cjovergar%40microsoft.com%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380980941&amp;sdata=R1R8rq0d0MyG36iSVeJwcP3UYRSb%2F4MafyW9Ir%2BNx2A%3D&amp;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 <[e-mail]>

  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
[e-mail]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu&amp;data=02%7C01%7Cjovergar%40microsoft.com%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380980941&amp;sdata=1xjqVMXOl1D62KRGdzAggBjEIuBVMoIU6AisOnJEroo%3D&amp;reserved=0