Draft: draft-ietf-emu-eap-tls13

Commentary: Based on a number of comments from  . This EAP state machine is related to  's DISCUSS and the EMU consensus call on alternate status indications and use of close_notify . The update tries to inplement the suggestions from  . The informal RFC 4137 is references but not normatively . Requirement in RFC 3478 to differentiate protected and unprotected result indicators is followed . This pull request is related to the pull requests " Packet Modification Attacks " and " MUST Error alert " 
 In the dicussion on the commitment message there has been quite a lot of talk about the need for an authenticated signal at the end of the handshake . This has not been discussed before . The -13 commitment message could not be used for that and close notify can not be used for that . The NewSessionTicket could be used for this . This is a message that acknoledge that the server has accepted the client authentication . it is also a message that can only be sent be the server and not by an on - path attacker . Note that the NewSessionTicket is not cryptographically bound to the Clients second flight , but this is probably not needed .   wrote that an authenticated signal is probably not needed . " 1 . I do n't see a strict requirement for an authenticated signal at the end of the handshake . " This issue is likely related to the newly opened issue of the EAP state machine . 
 Most of the current discussion in the group is about result indications and not signaling the end of the handshake . I does n't seem that we need to signal the end of the handshake . The peer should always know how long a flight of messages is even if they are fragmented . 
  , the protected result indications make any " end of handshake"-indication superfluous . 
 I think we can close this issue out once we have merged the application data as success indicator . 
 This will be resolved by merging PR , PR and PR
Paragraph (version A):
This is a new section when compared to RFC5216.
Paragraph (version A):
When an EAP-TLS server has sent its last handshake message (Finished
or a Post-Handshake), it commits to not sending any more handshake
messages by sending a TLS close_notify alert.  After sending the
alert, the EAP-TLS server may only send an EAP-Success or an EAP-
Failure.  Using the TLS close_notify however results in an extra EAP-
Request and EAP-Response exchange between the peer and the server.
Paragraph (version B):
This is a new section when compared to RFC5216 and only applies to
TLS 1.3 (or higher).  RFC4137 offers a proposed state machine for
EAP.
Paragraph (version B):
TLS 1.3 RFC8446 introduces Post-Handshake messages.  These Post-
Handshake messages use the handshake content type and can be sent
after the main handshake.  Examples of Post-Handshake messages are
NewSessionTicket, which is used for resumption and KeyUpdate, which
is not useful and not expected in EAP-TLS.  After sending TLS
Finished, the EAP-TLS server may send any number of Post-Handshake
messages in separate EAP-Requests.
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), it commits to not sending any more handshake messages by
sending a TLS close_notify alert.  The TLS close_notify alert is a
protected success result indication, as defined in RFC3748.
Implementations follwing RFC4137 sets the alternate indication of
success variable altAccept after sending or receiving close_notify.
After sending the TLS close_notify alert, the EAP-TLS server may only
send an EAP-Success.  The EAP-TLS server MUST NOT send an TLS
close_notify alert before it has successfully processed the client
finished and sent its last handshake message.
Paragraph (version B):
TLS Error alerts SHOULD be considered a failure result indication, as
defined in RFC3748.  Implementations follwing RFC4137 sets the
alternate indication of failure variable altReject after sending or
receiving an Error alert.  After sending or receiving a TLS Error
alert, the EAP-TLS server may only send an EAP-Failure.  Protected
TLS Error alerts are protected failure result indications,
unprotected TLS Error alerts are not.
Paragraph (version B):
The keying material can be derived after the TLS server Finished has
been sent or received.  Implementations following RFC4137 can then
set the eapKeyData and aaaEapKeyData variables.
Paragraph (version B):
The keying material can be made available to lower layers and the
authenticator after the authenticated success result indication has
been sent or received.  Implementations following RFC4137 can set the
eapKeyAvailable and aaaEapKeyAvailable variables.