Draft: draft-ietf-emu-eap-tls13

Commentary: 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 ] . = =[  (   ) 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 . If the EAP - TLS server authenticates successfully , the EAP - TLS peer MUST send an EAP - Response message with EAP - Type = EAP - TLS containing TLS records conforming to the version of TLS used . Just to walk through the various scenarios here ; if the last message of the TLS handshake for a given TLS version is sent by the TLS client , that will go in an EAP - Response , so the server is then able to send EAP - Success directly . On the other hand , if the last TLS handshake message is sent by the server , that will have to go in an EAP - TLS EAP - Request , and so the peer will have to send an empty EAP - TLS response in order for the server to be able to wend EAP - Success ? Do we need to have any text here to handle that empty EAP - TLS Eap - Request case ? = =[ COMMENT(Alvaro Retana ) Is the intention of the  to provide additional formal updates to rfc5216 ? That is what it looks like to me , but there 's no reference to it from the main text . Please either reference the Appendix when talking about some of the other updates ( if appropriate ) or specifically include the text somewhere more prominent . [ Roman ] As proposed above , please provide some forward reference . = =[  ( Éric Vyncke ) I find " This section updates Section 2.1.1 of [ RFC5216 ] . " a little ambiguous as it the ' updated section ' is not identified clearly . I.e. , as the sections in RFC 5216 are not too long , why not simply providing whole new sections ? [ Roman ] I 'd propose a simple fix by using ( approximate phrases such as ) either : This section updates Section xxx of [ RFC5216 ] by amending it with the following text . ( for the cases where the intent is to keep the existing text in rfc5216 but add this new text ) This section updates Section xxx of [ RFC5216 ] by replacing it with the following text . ( for the cases where the intent is to replace an entire section in rfc5216 ) = =[  ( Éric Vyncke ) None of us are native English speaker , but " e.g. " as " i.e. " are usually followed by a comma while " but " has usually no comma before ;-) [ Roman ] A simple s / e.g./e.g . ,/ and s / i.e./i.e . ,/ would catch this . Regards , Roman 
 = =[  ( Éric Vyncke ) None of us are native English speaker , but " e.g. " as " i.e. " are usually followed by a comma while " but " has usually no comma before ;-) [ Roman ] A simple s / e.g./e.g . ,/ and s / i.e./i.e . ,/ would catch this .  is correct that US english i.e. and e.g. is usually followed by a comma . I corrected this in I also run a word spell check on the document . Word does not suggest removing any comma after " but " but rather insert an additional comma after a but . I think this can be left to the RFC editor . The word spell check caught two other grammar errors ( s after plural , no s after singular ) RFC 8446 does not use capitalization on post - handshake as that is just a name for a set of messages . I corrected these things in 
 I Made a new PR 
 Made a commit with 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 ] . 
 Section 2.1.4 Changed the text to : The message flow ends with a protected success indication from the EAP - TLS server , follwed by an EAP - Response packet of EAP - Type = EAP - TLS and no data from the EAP - TLS peer , follwed by EAP - Success from the server . 
 I a forward reference to the appendix in the introduction 
 looks like you have got everything covered ? are there any comments from Roman which still need to be addressed ? should we submit a new version and ask for IETF last call ? 
 I have tried to do everything . Problem with the updates thing . The replace or amend strategy does not really work .... [ Roman ] I 'd propose a simple fix by using ( approximate phrases such as ) either : This section updates Section xxx of [ RFC5216 ] by amending it with the following text . ( for the cases where the intent is to keep the existing text in rfc5216 but add this new text ) This section updates Section xxx of [ RFC5216 ] by replacing it with the following text . ( for the cases where the intent is to replace an entire section in rfc5216 ) 
 We should likely not do to much changes . Maybe we can write something like Amends with the following text . TLS 1.2 specific details in RFC 5216 are replaced . Requirement in the new takes precedence over requirements in the old text . 
 This review was addressed in earlier submissions . closing
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.  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 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.  The two
paragraphs below replace 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):
When an EAP-TLS server has successfully processed the TLS client
Finished and sent its last handshake message (Finished or a Post-
Handshake), it sends an encrypted TLS record with application data
0x00.  The encrypted TLS record with application data 0x00 is a
protected success result indication, as defined in RFC3748.  After
sending a EAP-Request that contains the protected success result
indication, the EAP-TLS server must not send any more EAP-Request and
may only send an EAP-Success.  The EAP-TLS server MUST NOT send an
encrypted TLS record with application data 0x00 alert before it has
successfully processed the client finished and sent its last
handshake message.
Paragraph (version B):
When an EAP-TLS server has successfully processed the TLS client
Finished and sent its last handshake message (Finished or a post-
handshake message), it sends an encrypted TLS record with application
data 0x00.  The encrypted TLS record with application data 0x00 is a
protected success result indication, as defined in RFC3748.  After
sending an EAP-Request that contains the protected success result
indication, the EAP-TLS server must not send any more EAP-Request and
may only send an EAP-Success.  The EAP-TLS server MUST NOT send an
encrypted TLS record with application data 0x00 alert before it has
successfully processed the client finished and sent its last
handshake message.
Paragraph (version A):
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
EAP-TLS server need to be able to securely retrieve authorization
information such as certificate chains from the initial full
handshake.  This document use the term "cached data" to describe such
information.  Authorization during resumption MUST be based on such
cached data.  The EAP-TLS peer and EAP-TLS server MAY perform fresh
revocation checks on the cached certificate data.  Any security
policies for authorization MUST be followed also for resumption.  The
certificates may have been revoked since the initial full handshake
and the authorizations of the other party may have reduced.  If the
cached revocation data is not sufficiently current, the EAP-TLS peer
or EAP-TLS server MAY force a full TLS handshake.
Paragraph (version B):
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
EAP-TLS server need to be able to securely retrieve authorization
information such as certificate chains from the initial full
handshake.  This document uses the term "cached data" to describe
such information.  Authorization during resumption MUST be based on
such cached data.  The EAP-TLS peer and EAP-TLS server MAY perform
fresh revocation checks on the cached certificate data.  Any security
policies for authorization MUST be followed also for resumption.  The
certificates may have been revoked since the initial full handshake
and the authorizations of the other party may have reduced.  If the
cached revocation data is not sufficiently current, the EAP-TLS peer
or EAP-TLS server MAY force a full TLS handshake.