Original text:
2.5. <del> This is a new section when compared to RFC5216. </del>  TLS 1.3 RFC8446 introduces Post-Handshake messages.  These Post- Handshake messages use the handshake content type and can be sent <del> after the main handshake.  One such Post-Handshake message is NewSessionTicket.  The NewSessionTicket can be used for resumption. After sending TLS Finished, the EAP-TLS server may send any number of Post-Handshake messages in separate EAP-Requests.  To decrease the </del>  uncertainty for the EAP-TLS peer, the following procedure MUST be followed: <del> When an EAP-TLS 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 close_notify alert.  After sending the alert, the EAP-TLS server may only send an EAP-Success or an EAP- Failure.  Using the TLS close_notify however results in an extra EAP- Request and EAP-Response exchange between the peer and the server. </del>  3.

Reviewer comments:
Based on a number of comments from Bernard. This EAP state machine is related to Ben's DISCUSS and the EMU consensus call on alternate status indications and use of close_notify. The update tries to inplement the suggestions from Bernard. The informal RFC 4137 is references but not normatively. Requirement in RFC 3478 to differentiate protected and unprotected result indicators is followed. This pull request is related to the pull requests "Packet Modification Attacks" and "MUST Error alert"
In the dicussion on the commitment message there has been quite a lot of talk about the need for an authenticated signal at the end of the handshake. This has not been discussed before. The -13 commitment message could not be used for that and close notify cannot be used for that. The NewSessionTicket could be used for this. This is a message that acknoledge that the server has accepted the client authentication. it is also a message that can only be sent be the server and not by an on-path attacker. Note that the NewSessionTicket is not cryptographically bound to the Clients second flight, but this is probably not needed. Jorge Vergara wrote that an authenticated signal is probably not needed. "1. I don't see a strict requirement for an authenticated signal at the end of the handshake." This issue is likely related to the newly opened issue of the EAP state machine.
Most of the current discussion in the group is about result indications and not signaling the end of the handshake. I doesn't seem that we need to signal the end of the handshake. The peer should always know how long a flight of messages is even if they are fragmented.
Agree, the protected result indications make any "end of handshake"-indication superfluous.
I think we can close this issue out once we have merged the application data as success indicator.
This will be resolved by merging PR , PR and PR

Revised text:
2.5.  <ins> This is a new section when compared to RFC5216 and only applies to TLS 1.3 (or higher).  RFC4137 offers a proposed state machine for EAP. </ins> TLS 1.3 RFC8446 introduces Post-Handshake messages.  These Post- Handshake messages use the handshake content type and can be sent  <ins> after the main handshake.  Examples of Post-Handshake messages are NewSessionTicket, which is used for resumption and KeyUpdate, which is not useful and not expected in EAP-TLS.  After sending TLS Finished, the EAP-TLS server may send any number of Post-Handshake messages in separate EAP-Requests. To provide a protected success result indication and to decrease the </ins> uncertainty for the EAP-TLS peer, the following procedure MUST be followed:  <ins> When an EAP-TLS server has successfully processed the TLS client Finished and sent its last handshake message (Finished or a Post- Handshake), it commits to not sending any more handshake messages by sending a TLS close_notify alert.  The TLS close_notify alert is a protected success result indication, as defined in RFC3748. Implementations follwing RFC4137 sets the alternate indication of success variable altAccept after sending or receiving close_notify. After sending the TLS close_notify alert, the EAP-TLS server may only send an EAP-Success.  The EAP-TLS server MUST NOT send an TLS close_notify alert before it has successfully processed the client finished and sent its last handshake message. TLS Error alerts SHOULD be considered a failure result indication, as defined in RFC3748.  Implementations follwing RFC4137 sets the alternate indication of failure variable altReject after sending or receiving an Error alert.  After sending or receiving a TLS Error alert, the EAP-TLS server may only send an EAP-Failure.  Protected TLS Error alerts are protected failure result indications, unprotected TLS Error alerts are not. The keying material can be derived after the TLS server Finished has been sent or received.  Implementations following RFC4137 can then set the eapKeyData and aaaEapKeyData variables. The keying material can be made available to lower layers and the authenticator after the authenticated success result indication has been sent or received.  Implementations following RFC4137 can set the eapKeyAvailable and aaaEapKeyAvailable variables. </ins> 3.