Change:
The PR only fixed some of Alan's comments. I updated the PR to address all Alan's comments that was copied in the issue
From Alan's review: >
Also >
Looks good to merge

Discussion:
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. <del> Privacy, which in EAP-TLS means that the peer username is not disclosed, is mandatory and achieved without any additional round- trips.  Revocation checking is mandatory and simplified with OCSP stapling, and TLS 1.3 introduces more possibilities to reduce fragmentation when compared to earlier versions of TLS. </del> <ins> Privacy, which in EAP-TLS means that no information about the underlying peer identity is disclosed, is mandatory and achieved without any additional round-trips.  Revocation checking is mandatory and simplified with OCSP stapling, and TLS 1.3 introduces more possibilities to reduce fragmentation when compared to earlier versions of TLS. </ins> This document follows the terminology from I-D.ietf-tls-rfc8446bis where the master secret is renamed to the main secret and the

TLS 1.3 changes both the message flow and the handshake messages compared to earlier versions of TLS.  Therefore, much of Section 2.1 <del> of RFC5216 does not apply for TLS 1.3. </del> <ins> of RFC5216 does not apply for TLS 1.3.  EAP-TLS 1.3 remains backwards compatible with EAP-TLS 1.2 RFC5216 . TLS version negotiation is handled by the TLS layer, and thus outside of the scope of EAP-TLS. Therefore so long as the underlying TLS implementation correctly implements TLS version negotiation, EAP-TLS will automatically leverage that capability. </ins> After receiving an EAP-Request packet with EAP-Type=EAP-TLS as described in RFC5216 the conversation will continue with the TLS

the client has received a NewSessionTicket message from the EAP-TLS server, the client can use the PSK identity associated with the ticket to negotiate the use of the associated PSK.  If the EAP-TLS <del> server accepts it, then the security context of the new connection is tied to the original connection and the key derived from the initial handshake is used to bootstrap the cryptographic state instead of a full handshake.  It is up to the EAP-TLS peer to use resumption, but it is RECOMMENDED that the EAP-TLS peer use resumption if it has a valid ticket that has not been used before.  It is left to the EAP- TLS server whether to accept resumption, but it is RECOMMENDED that the EAP-TLS server accept resumption if the ticket which was issued is still valid.  However, the EAP-TLS server MAY choose to require a full handshake.  As in a full handshake, sending a NewSessionTicket during resumption is optional.  As described in Appendix C.4 of RFC8446, reuse of a ticket allows passive observers to correlate different connections.  EAP-TLS peers and EAP-TLS servers SHOULD follow the client tracking preventions in Appendix C.4 of RFC8446. </del> <ins> server accepts it, then the resumed session has been deemed to be authenticated, and securely tied to the associated with the prior authentication or resumption.  It is up to the EAP-TLS peer to use resumption, but it is RECOMMENDED that the EAP-TLS peer use resumption if it has a valid ticket that has not been used before. It is left to the EAP-TLS server whether to accept resumption, but it is RECOMMENDED that the EAP-TLS server accept resumption if the ticket which was issued is still valid.  However, the EAP-TLS server MAY choose to require a full handshake.  In the case a full handshake is required, the negotiation proceeds as if the session was a new authentication, and resumption had never been requested.  The requirements of Sections section_auth and ticket then apply in their entirety.  As described in Appendix C.4 of RFC8446, reuse of a ticket allows passive observers to correlate different connections.  EAP-TLS peers and EAP-TLS servers SHOULD follow the client tracking preventions in Appendix C.4 of RFC8446. </ins> It is RECOMMENDED to use a Network Access Identifiers (NAIs) with the same realm during resumption and the original full handshake.  This

above keying material. By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation <del> without having to extract the Main Secret, ClientHello.random, and ServerHello.random in a non-standard way. </del> <ins> which provides a public API for the exporter.  Note that EAP-TLS with TLS 1.2 RFC5216 can be used with the TLS exporter since the public exporter was defined in RFC5705. </ins> 2.4.

There are a number of security issues related to resumption that are not described in RFC5216.  The problems, guidelines, and requirements <del> in this section therefore applies to all version of TLS. </del> <ins> in this section therefore applies to EAP-TLS when it is used with any version of TLS. </ins> When resumption occurs, it is based on cached information at the TLS layer.  To perform resumption in a secure way, the EAP-TLS peer and