Code change:
maintain backwards compatibility.  However, this document does provide additional guidance on authentication, authorization, and resumption for EAP-TLS regardless of the underlying TLS version used. <del> This document only describes differences compared to RFC5216.  All message flow are example message flows specific to TLS 1.3 and do not apply to TLS 1.2.  Since EAP-TLS couples the TLS handshake state machine with the EAP state machine it is possible that new versions of TLS will cause incompatibilities that introduce failures or security issues if they are not carefully integrated into the EAP-TLS protocol.  Therefore, implementations MUST limit the maximum TLS version they use to 1.3, unless later versions are explicitly enabled by the administrator. </del> <ins> This document only describes differences compared to RFC5216.  When EAP-TLS is used with TLS 1.3, some references are updated as specified in updateref.  All message flow are example message flows specific to TLS 1.3 and do not apply to TLS 1.2.  Since EAP-TLS couples the TLS handshake state machine with the EAP state machine it is possible that new versions of TLS will cause incompatibilities that introduce failures or security issues if they are not carefully integrated into the EAP-TLS protocol.  Therefore, implementations MUST limit the maximum TLS version they use to 1.3, unless later versions are explicitly enabled by the administrator. </ins> This document specifies EAP-TLS 1.3 and does not specify how other TLS-based EAP methods use TLS 1.3.  The specification for how other

Related discussion:
text: Hi! I performed a second AD review on draft-ietf-emu-eap-tls13. This time on -18. Thank you to the authors, the responsible co-chair, and the WG for all of the work to redesign the -13 protocol in response to the initial IESG review in December 2020. My review feedback consists of my own minimal additional comments and highlights of where previously stated IESG ballot items do not appear to be responded to or addressed. All items appear to be minor. ** Section 2.4. Previously, this text referenced TLS 1.3 or higher necessitating more ambiguous reference to version numbers. However, now the text only notes TLS 1.3. OLD When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP- TLS servers MUST comply with the compliance requirements (mandatory- to-implement cipher suites, signature algorithms, key exchange algorithms, extensions, etc.) for the TLS version used. For TLS 1.3 the compliance requirements are defined in Section 9 of [RFC8446]. NEW When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP-TLS servers MUST comply with the compliance requirements (mandatory- to-implement cipher suites, signature algorithms, key exchange algorithms, extensions, etc.) defined in Section 9 of [RFC8446]. ==[ COMMENT (Ben Kaduk) Section 2.1.4 The two paragraphs below replaces the corresponding paragraphs in Section 2.1.3 of [RFC5216] when EAP-TLS is used with TLS 1.3 or higher. The other paragraphs in Section 2.1.3 of [RFC5216] still apply with the exception that SessionID is deprecated. If the EAP-TLS peer authenticates successfully, the EAP-TLS server MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing TLS records conforming to the version of TLS used. The message flow ends with the EAP-TLS server sending an EAP-Success message.