Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05

[John Mattsson <[e-mail]>]

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 <[e-mail]>
Date: Wednesday, 24 July 2019 at 20:49
To: Alan DeKok <[e-mail]>, Jouni Malinen <[e-mail]>, Jim Schaad <[e-mail]>
Cc: EMU WG <[e-mail]>
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)