Draft: draft-ietf-emu-eap-tls13

Commentary: During dicsussion on close_notify , there was a good dicusssion on the list on why resumption is needed . Some short clarifications on how TLS 1.3 works . E.g. that PSK is not included in the ticket .
Paragraph (version A):
To enable resumption when using EAP-TLS with TLS 1.3, the EAP-TLS
server MUST send one or more NewSessionTicket messages (each
containing a PSK, a PSK identity, a ticket lifetime, and other
parameters) in the initial authentication.  Note that TLS 1.3 RFC8446
limits the ticket lifetime to a maximum of 604800 seconds (7 days)
and EAP-TLS servers MUST respect this upper limit when issuing
tickets.  The NewSessionTicket is sent after the EAP-TLS server has
received the client Finished message in the initial authentication.
The PSK associated with the ticket depends on the client Finished and
cannot be pre-computed in handshakes with client authentication.  The
NesSessionTicket MUST NOT be sent before the client's certificate has
been validated.  The NewSessionTicket message MUST NOT include an
"early_data" extension.  If the "early_data" extension is received
then it MUST be ignored.  Servers should take into account that fewer
newSessionTickets will likely be needed in EAP-TLS than in the usual
HTTPS connection scenario.  In most cases a single newSessionTicket
will be sufficient.  A mechanism by which clients can specify the
desired number of tickets needed for future connections is defined in
I-D.ietf-tls-ticketrequests.
Paragraph (version B):
To enable resumption when using EAP-TLS with TLS 1.3, the EAP-TLS
server MUST send one or more Post-Handshake NewSessionTicket messages
(each associated with a PSK, a PSK identity, a ticket lifetime, and
other parameters) in the initial authentication.  Note that TLS 1.3
RFC8446 limits the ticket lifetime to a maximum of 604800 seconds (7
days) and EAP-TLS servers MUST respect this upper limit when issuing
tickets.  The NewSessionTicket is sent after the EAP-TLS server has
received the client Finished message in the initial authentication.
The NewSessionTicket can be sent in the same flight as the TLS server
Finished or later.  The PSK associated with the ticket depends on the
client Finished and cannot be pre-computed in handshakes with client
authentication.  The NewSessionTicket message MUST NOT include an
"early_data" extension.  If the "early_data" extension is received
then it MUST be ignored.  Servers should take into account that fewer
newSessionTickets will likely be needed in EAP-TLS than in the usual
HTTPS connection scenario.  In most cases a single newSessionTicket
will be sufficient.  A mechanism by which clients can specify the
desired number of tickets needed for future connections is defined in
I-D.ietf-tls-ticketrequests.
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, 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.  EAP-TLS is typically used with client
authentication and typically fragments the TLS flights into a large
number of EAP requests and EAP responses.  Resumption significantly
reduces the number of round-trips and enables the EAP-TLS server to
omit database lookups needed during a full handshake with client
authentication.