Draft: draft-ietf-emu-eap-tls13

Commentary: Explain that the next version of TLS may not be compatible with this document . Remove " or higher " in several sections . This addresses issue 
 does this commit address Issue ? 
 As an implementor , I 'm not sure what it means to " automatically support " or " not automatically support " something . It 's not clear to me what I do with that recommendation . I think it 's best to make an explicit statement that That statement gives clear direction on exactly what to do . i.e. there are APIs to " limit the maximum TLS version " . So I know what that phrase means . There are no APIs to " not automatically support " something . So I do n't know what that phrase means , or what I should do in order to satisfy its ' requirements . The rest of the changes are fine . 
 Thanks , I updated the text . 
 From  's review : Suggestion : remove all " or higher " text . Add in text which says that by default , EAP - TLS 1.3 implementations MUST limit the maximum TLS version to 1.3 , unless later versions are explicitly enabled by the administrator . 
 It would help implementors to understand why this restriction is there . i.e. instead of just saying " use TLS 1.3 " , it would be good to note something like :
Paragraph (version B):
This document defines how to use EAP-TLS with TLS 1.3 and does not
change how EAP-TLS is used with older versions of TLS.  It does
however provide additional guidance on authorization and resumption
for EAP-TLS in general (regardless of the underlying TLS 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 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 imtegrated 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.
Paragraph (version A):
After receiving an EAP-Request packet with EAP-Type=EAP-TLS as
described in RFC5216 the conversation will continue with the TLS
handshake protocol encapsulated in the data fields of EAP-Response
and EAP-Request packets.  When EAP-TLS is used with TLS version 1.3
or higher, the formatting and processing of the TLS handshake SHALL
be done as specified in that version of TLS.  This document only
lists additional and different requirements, restrictions, and
processing compared to RFC8446 and RFC5216.
Paragraph (version B):
After receiving an EAP-Request packet with EAP-Type=EAP-TLS as
described in RFC5216 the conversation will continue with the TLS
handshake protocol encapsulated in the data fields of EAP-Response
and EAP-Request packets.  When EAP-TLS is used with TLS version 1.3,
the formatting and processing of the TLS handshake SHALL be done as
specified in that version of TLS.  This document only lists
additional and different requirements, restrictions, and processing
compared to RFC8446 and RFC5216.
Paragraph (version A):
TLS 1.3 replaces the session resumption mechanisms in earlier
versions of TLS with a new PSK exchange.  When EAP-TLS is used with
TLS version 1.3 or higher, EAP-TLS SHALL use a resumption mechanism
compatible with that version of TLS.
Paragraph (version B):
TLS 1.3 replaces the session resumption mechanisms in earlier
versions of TLS with a new PSK exchange.  When EAP-TLS is used with
TLS version 1.3, EAP-TLS SHALL use a resumption mechanism compatible
with that version of TLS.
Paragraph (version A):
TLS 1.3 changes both the message flow and the handshake messages
compared to earlier versions of TLS.  Therefore, some normative text
in Section 2.1.3 of RFC5216 does not apply for TLS 1.3 or higher.
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.
Paragraph (version B):
TLS 1.3 changes both the message flow and the handshake messages
compared to earlier versions of TLS.  Therefore, some normative text
in Section 2.1.3 of RFC5216 does not apply for TLS 1.3 or higher.
The two paragraphs below replaces the corresponding paragraphs in
Section 2.1.3 of RFC5216 when EAP-TLS is used with TLS 1.3.  The
other paragraphs in Section 2.1.3 of RFC5216 still apply with the
exception that SessionID is deprecated.
Paragraph (version A):
EAP-TLS peer and server implementations supporting TLS 1.3 or higher
MUST support anonymous NAIs (Network Access Identifiers) (Section 2.4
in RFC7542) and a client supporting TLS 1.3 MUST NOT send its
username in cleartext in the Identity Response.  Following RFC7542,
it is RECOMMENDED to omit the username (i.e., the NAI is @realm), but
other constructions such as a fixed username (e.g. anonymous@realm)
or an encrypted username (e.g.,
xCZINCPTK5+7y81CrSYbPg+RKPE3OTrYLn4AQc4AC2U=@realm) are allowed.
Note that the NAI MUST be a UTF-8 string as defined by the grammar in
Section 2.2 of RFC7542.
Paragraph (version B):
EAP-TLS peer and server implementations supporting TLS 1.3 MUST
support anonymous NAIs (Network Access Identifiers) (Section 2.4 in
RFC7542) and a client supporting TLS 1.3 MUST NOT send its username
in cleartext in the Identity Response.  Following RFC7542, it is
RECOMMENDED to omit the username (i.e., the NAI is @realm), but other
constructions such as a fixed username (e.g. anonymous@realm) or an
encrypted username (e.g.,
xCZINCPTK5+7y81CrSYbPg+RKPE3OTrYLn4AQc4AC2U=@realm) are allowed.
Note that the NAI MUST be a UTF-8 string as defined by the grammar in
Section 2.2 of RFC7542.
Paragraph (version A):
As the certificate messages in TLS 1.3 are encrypted, there is no
need to send an empty certificate_list and perform a second handshake
for privacy (as needed by EAP-TLS with earlier versions of TLS).
When EAP-TLS is used with TLS version 1.3 or higher the EAP-TLS peer
and EAP-TLS server SHALL follow the processing specified by the used
version of TLS.  For TLS 1.3 this means that the EAP-TLS peer only
sends an empty certificate_list if it does not have an appropriate
certificate to send, and the EAP-TLS server MAY treat an empty
certificate_list as a terminal condition.
Paragraph (version B):
As the certificate messages in TLS 1.3 are encrypted, there is no
need to send an empty certificate_list and perform a second handshake
for privacy (as needed by EAP-TLS with earlier versions of TLS).
When EAP-TLS is used with TLS version 1.3 the EAP-TLS peer and EAP-
TLS server SHALL follow the processing specified by the used version
of TLS.  For TLS 1.3 this means that the EAP-TLS peer only sends an
empty certificate_list if it does not have an appropriate certificate
to send, and the EAP-TLS server MAY treat an empty certificate_list
as a terminal condition.
Paragraph (version A):
When EAP-TLS is used with TLS version 1.3 or higher the Key_Material,
IV, and Method-Id SHALL be derived from the exporter_secret using the
TLS exporter interface RFC5705 (for TLS 1.3 this is defined in
Section 7.5 of RFC8446).
Paragraph (version B):
When EAP-TLS is used with TLS version 1.3 the Key_Material, IV, and
Method-Id SHALL be derived from the exporter_secret using the TLS
exporter interface RFC5705 (for TLS 1.3 this is defined in
Section 7.5 of RFC8446).