ACK that EAP-TLS does not need to keep the connection open. Question: should some consideration be given to consistency with other EAP methods that do need to keep the connection open? i.e. PEAP/EAP-TTLS/TEAP
Jorge -----Original Message----- From: Emu <emu-boun...@ietf.org> On Behalf Of Jim Schaad Sent: Saturday, August 1, 2020 8:23 AM To: 'Alan DeKok' <al...@deployingradius.com> Cc: 'Mohit Sethi M' <mohit.m.se...@ericsson.com>; 'EMU WG' <emu@ietf.org>; 'Benjamin Kaduk' <ka...@mit.edu> Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3 -----Original Message----- From: Alan DeKok <al...@deployingradius.com> Sent: Saturday, August 1, 2020 6:53 AM To: Jim Schaad <i...@augustcellars.com> Cc: Mohit Sethi M <mohit.m.se...@ericsson.com>; EMU WG <emu@ietf.org>; Benjamin Kaduk <ka...@mit.edu> Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3 On Jul 31, 2020, at 12:30 PM, Jim Schaad <i...@augustcellars.com> wrote: > > Ok – so this issue was raised at IETF 102. (presentation > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fproceedings%2F102%2Fslides%2Fslides-102-emu-eap-tls-with-tls-13-00&data=02%7C01%7Cjovergar%40microsoft.com%7C79f98e3e6f7f49971c4608d8362ed351%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637318922028443984&sdata=nExLYi6p0JNNeZ8TZsfXkRIm53%2BHuUidEhU2GrrioA4%3D&reserved=0) > > Just reading the slides is not telling me what was the problem. I think I am > going to need to hear the audio of the presentation. I have an extremely > vague memory that there was an OpenSSL problem involved here but I would not > swear to that. You might be a better description either from John Mattsson > or Jouni. IIRC it's that OpenSSL doesn't have an API to send a zero bytes of application data. I think other TLS implementations have similar limitations. Regardless of what solution is implemented, the requirement is to have a positive acknowledgement that TLS setup is finished. This step seems to be missing by default in TLS 1.3. I suspect that most uses of TLS will *always* send application data. Which makes EAP-TLS an outlier. Hence the need for hacks like "send application data as one octet of zero". [JLS] Cobwebs are slowly being shaken out of my brain. * I made an incorrect statement yesterday because I got EAP-TEAP and EAP-TLS confused. Not surprising because I only ever spent any time on EAP-TEAP . In EAP-TLS, once the handshake has been completed the tunnel does not need to be kept open. This is the opposite of the case for EAP-TEAP where the tunnel is used for application EAP data. * Based on that I agree with EKR that the close notification could be used instead of sending the one byte of application data. Sending the close notification means that the server will no longer be sending any data and thus would not send any new session tickets. 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 <-------- (close_notify) EAP-Response/ EAP-Type=EAP-TLS --------> <-------- EAP-Success Jim Alan DeKok. _______________________________________________ Emu mailing list 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%7C79f98e3e6f7f49971c4608d8362ed351%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637318922028448974&sdata=c40nE5bUpT69CYY9qDNx7dRyVWzFRqgoKcUvgV0p9yE%3D&reserved=0 _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu