On Jul 13, 2020, at 1:44 PM, Mohit Sethi M <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://mailarchive.ietf.org/arch/msg/emu/k6K98OhuOQmbzSAgGWCtSIVv3Qk/), > which I addressed in version 10 > (https://mailarchive.ietf.org/arch/msg/emu/IopJTjefyVVKpObzyFc0CAJ-Pig/). > ... > 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://mailarchive.ietf.org/arch/msg/emu/eM-14QdDQjg7DvhAVJMzpvPz5wg/). > > 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://w1.fi/cgit/hostap/commit/?id=36ec5881657157752dced741256441c230e42fe6 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> 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 https://www.ietf.org/mailman/listinfo/emu
