Draft: draft-ietf-emu-eap-tls13

Commentary: Some of the text describing the figures indicated that TLS 1.3 only has one possible message flow . This pull request change the text to make it is clear that the message flows are examples . Based on discussion on the List initiated by  .
Paragraph (version A):
This document defines how to use EAP-TLS with TLS 1.3 (or higher) 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 specific to TLS 1.3 and do not apply
to TLS 1.2.
Paragraph (version A):
In the case where EAP-TLS with mutual authentication is successful
(and neither HelloRetryRequest nor Post-Handshake messages are sent)
the conversation will appear as shown in figbase1.
Paragraph (version B):
figbase1 shows an example message flow for a succesfull EAP-TLS full
handshake with mutual authentication (and neither HelloRetryRequest
nor Post-Handshake messages are sent).
Paragraph (version A):
In the case where EAP-TLS with mutual authentication and ticket
establishment with two tickets is successful, the conversation will
appear as shown in figbase2.
Paragraph (version B):
figbase2 shows an example message flow for a succesfull EAP-TLS full
handshake with mutual authentication and ticket establishment of a
single ticket.
Paragraph (version A):
A subsequent successful resumption handshake where both sides
authenticate via a PSK provisioned via an earlier NewSessionTicket
and where the server provisions a single new ticket is shown in
figresumption.
Paragraph (version A):
A subsequent successful resumption handshake where both sides
authenticate via a PSK provisioned via an earlier NewSessionTicket
and where the server does not provision any new tickets is shown in
figresumption2.
Paragraph (version B):
figresumption shows an example message flow for a subsequent
succesfull EAP-TLS resumption handshake where both sides authenticate
via a PSK provisioned via an earlier NewSessionTicket and where the
server provisions a single new ticket.
Paragraph (version A):
In the case where the EAP-TLS server rejects the ClientHello with a
fatal error, the conversation will appear as shown in figterm1.  The
EAP-TLS server can also partly reject the ClientHello with a
HelloRetryRequest, see helloretry.
Paragraph (version A):
In the case where EAP-TLS server authentication is unsuccessful, the
conversation will appear as shown in figterm2.
Paragraph (version A):
In the case where the EAP-TLS server authenticates to the EAP-TLS
peer successfully, but the EAP-TLS peer fails to authenticate to the
EAP-TLS server, the conversation will appear as shown in figterm3.
Paragraph (version A):
In the case where EAP-TLS is used without peer authentication (e.g.,
emergency services, as described in RFC7406) the conversation will
appear as shown in figbase3.
Paragraph (version B):
figterm1 shows an example message flow where the EAP-TLS server
rejects the ClientHello with a Error alert.  The EAP-TLS server can
also partly reject the ClientHello with a HelloRetryRequest, see
helloretry.
Paragraph (version B):
figterm2 shows an example message flow where EAP-TLS server
authentication is unsuccessful and the EAP-TLS peer sends a TLS Error
alert.
Paragraph (version B):
figterm3 shows an example message flow where the EAP-TLS server
authenticates to the EAP-TLS peer successfully, but the EAP-TLS peer
fails to authenticate to the EAP-TLS server and sends a TLS Error
alert.
Paragraph (version B):
figbase3 shows an example message flow for a succesfull EAP-TLS full
handshake without peer authentication (e.g., emergency services, as
described in RFC7406).
Paragraph (version A):
The case of a successful EAP-TLS mutual authentication after the EAP-
TLS server has sent a HelloRetryRequest message is shown in
fighelloretryrequest.  Note the extra round-trip as a result of the
HelloRetryRequest.
Paragraph (version B):
fighelloretryrequest shows an example message flow for a succesfull
EAP-TLS full handshake with mutual authentication and
HelloRetryRequest.  Note the extra round-trip as a result of the
HelloRetryRequest.