Original text:
version used).  While this document updates EAP-TLS RFC5216, it remains backwards compatible with it and existing implementations of EAP-TLS.  This document only describes differences compared to <del> RFC5216.  All message flow are specific to TLS 1.3 and do not apply to TLS 1.2. </del>  In addition to the improved security and privacy offered by TLS 1.3, there are other significant benefits of using EAP-TLS with TLS 1.3. empty EAP-Response to the EAP-Request containing the TLS close_notify alert, the EAP-TLS server sends EAP-Success. <del> In the case where EAP-TLS with mutual authentication is successful (and neither HelloRetryRequest nor Post-Handshake messages are sent) the conversation will appear as shown in figbase1. </del>  2.1.2. tickets needed for future connections is defined in I-D.ietf-tls- ticketrequests. <del> In the case where EAP-TLS with mutual authentication and ticket establishment with two tickets is successful, the conversation will appear as shown in figbase2. </del>  2.1.3. is therefore in general unsuitable for deriving a NAI to use in the Identity Response. <del> A subsequent successful resumption handshake where both sides authenticate via a PSK provisioned via an earlier NewSessionTicket and where the server provisions a single new ticket is shown in figresumption. A subsequent successful resumption handshake where both sides authenticate via a PSK provisioned via an earlier NewSessionTicket and where the server does not provision any new tickets is shown in figresumption2. </del>  As specified in Section 2.2 of RFC8446, the EAP-TLS peer SHOULD supply a "key_share" extension when attempting resumption, which "user_cancelled", both of which indicate that the connection is not going to continue normally, see RFC8446. <del> In the case where the EAP-TLS server rejects the ClientHello with a fatal error, the conversation will appear as shown in figterm1.  The EAP-TLS server can also partly reject the ClientHello with a HelloRetryRequest, see helloretry. </del>  <del> In the case where EAP-TLS server authentication is unsuccessful, the conversation will appear as shown in figterm2. </del>  <del> In the case where the EAP-TLS server authenticates to the EAP-TLS peer successfully, but the EAP-TLS peer fails to authenticate to the EAP-TLS server, the conversation will appear as shown in figterm3. </del>  2.1.5. This is a new section when compared to RFC5216. <del> In the case where EAP-TLS is used without peer authentication (e.g., emergency services, as described in RFC7406) the conversation will appear as shown in figbase3. </del>  2.1.6. "supported_groups" extension.  In this case the client should send a new ClientHello with a "key_share" that the EAP-TLS server supports. <del> The case of a successful EAP-TLS mutual authentication after the EAP- TLS server has sent a HelloRetryRequest message is shown in fighelloretryrequest.  Note the extra round-trip as a result of the </del>  HelloRetryRequest. 2.1.7.

Reviewer comments:
Some of the text describing the figures indicated that TLS 1.3 only has one possible message flow. This pull request change the text to make it is clear that the message flows are examples. Based on discussion on the List initiated by Alan.

Revised text:
version used).  While this document updates EAP-TLS RFC5216, it remains backwards compatible with it and existing implementations of EAP-TLS.  This document only describes differences compared to  <ins> RFC5216.  All message flow are example message flows specific to TLS 1.3 and do not apply to TLS 1.2. </ins> In addition to the improved security and privacy offered by TLS 1.3, there are other significant benefits of using EAP-TLS with TLS 1.3. empty EAP-Response to the EAP-Request containing the TLS close_notify alert, the EAP-TLS server sends EAP-Success.  <ins> figbase1 shows an example message flow for a succesfull EAP-TLS full handshake with mutual authentication (and neither HelloRetryRequest nor Post-Handshake messages are sent). </ins> 2.1.2. tickets needed for future connections is defined in I-D.ietf-tls- ticketrequests.  <ins> figbase2 shows an example message flow for a succesfull EAP-TLS full handshake with mutual authentication and ticket establishment of a single ticket. </ins> 2.1.3. is therefore in general unsuitable for deriving a NAI to use in the Identity Response.  <ins> figresumption shows an example message flow for a subsequent succesfull EAP-TLS resumption handshake where both sides authenticate via a PSK provisioned via an earlier NewSessionTicket and where the server provisions a single new ticket. </ins> As specified in Section 2.2 of RFC8446, the EAP-TLS peer SHOULD supply a "key_share" extension when attempting resumption, which "user_cancelled", both of which indicate that the connection is not going to continue normally, see RFC8446.  <ins> figterm1 shows an example message flow where the EAP-TLS server rejects the ClientHello with a Error alert.  The EAP-TLS server can also partly reject the ClientHello with a HelloRetryRequest, see helloretry. </ins>  <ins> figterm2 shows an example message flow where EAP-TLS server authentication is unsuccessful and the EAP-TLS peer sends a TLS Error alert. </ins>  <ins> figterm3 shows an example message flow where the EAP-TLS server authenticates to the EAP-TLS peer successfully, but the EAP-TLS peer fails to authenticate to the EAP-TLS server and sends a TLS Error alert. </ins> 2.1.5. This is a new section when compared to RFC5216.  <ins> figbase3 shows an example message flow for a succesfull EAP-TLS full handshake without peer authentication (e.g., emergency services, as described in RFC7406). </ins> 2.1.6. "supported_groups" extension.  In this case the client should send a new ClientHello with a "key_share" that the EAP-TLS server supports.  <ins> fighelloretryrequest shows an example message flow for a succesfull EAP-TLS full handshake with mutual authentication and HelloRetryRequest.  Note the extra round-trip as a result of the </ins> HelloRetryRequest. 2.1.7.