I made a few smaller changes, added a figure, and committed to GitHub. A diff can be found here:
http://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-emu-eap-tls13-05.txt&url2=https://raw.githubusercontent.com/emu-wg/draft-ietf-emu-eap-tls13/master/draft-ietf-emu-eap-tls13.txt The GitHub commit can be found here: https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/b6529d49b129a0796715ab320df18003ceb4a964#diff-f0254f10e4339e650834528e3c398a26 Question: How will the use of Application data with TLSPlaintext.fragment = 0x00 work with EAP-TTLS, PEAP, and TEAP when they start using TLS 1.3? I assume they will need to send the same 0x00 to commit to not sending any more handshake messages as well as using application data for other purposes. I do not know exactly how the TLSPlaintext fragments look like in EAP-TTLS, PEAP, and TEAP. The TLSPlaintext fragment for commit need to be chosen so that the string does not collide with any other strings used. Cheers, John -----Original Message----- From: John Mattsson <john.matts...@ericsson.com> Date: Wednesday, 24 July 2019 at 20:49 To: Alan DeKok <al...@deployingradius.com>, Jouni Malinen <j...@w1.fi>, Jim Schaad <i...@augustcellars.com> Cc: EMU WG <emu@ietf.org> Subject: Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05 Hi, Based on the discussion on the list and at the meeting today I suggest the following changes to Section 2.1, 2.5, and figures. When we agree I will make a commit to GitHub and submit a new version of the draft. With the solution suggested by Jim, there should be no need to force NewSessionTicket. Do we need a figure to illustrate the "or in a separate EAP-Request" part of " The TLS record with application data may be sent in the same EAP-Request as the last handshake record or in a separate EAP-Request." Cheers, John Section 2.1: --------------------------- OLD The EAP server commits to not send any more handshake messages by sending an empty TLS record, see Section 2.5. NEW The EAP server commits to not send any more handshake messages by sending a TLS record with the application data 0x00, see Section 2.5. Section 2.5 EAP State Machines --------------------------- OLD 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. NEW 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 TLS record with application data 0x00 (i.e. a TLS record with TLSPlaintext.type = application_data, TLSPlaintext.length = 1, and TLSPlaintext.fragment = 0x00). EAP server implementations MUST set TLSPlaintext.fragment to 0x00, but EAP peer implementations MUST accept any application data as a commit from the EAP server to not send any more handshake messages. The TLS record with application data may be sent in the same EAP-Request as the last handshake record or in a separate EAP-Request. After sending the application data record, the EAP server may only send an EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert Message. Figures: --------------------------- OLD <-------- TLS empty record) NEW <-------- TLS Application Data) _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu