Draft: draft-ietf-emu-eap-tls13

Commentary: Text updates based on  's suggestion and some editorial suggestions
Paragraph (version A):
For TLS 1.3, resumption is described in Section 2.2 of RFC8446.  If
the client has received a NewSessionTicket message from the EAP-TLS
server, the client can use the PSK identity associated with the
ticket to negotiate the use of the associated PSK.  If the EAP-TLS
server accepts it, then the resumed session has been deemed to be
authenticated, and securely tied to the associated with the prior
authentication or resumption.  It is up to the EAP-TLS peer to use
resumption, but it is RECOMMENDED that the EAP-TLS peer use
resumption if it has a valid ticket that has not been used before.
It is left to the EAP-TLS server whether to accept resumption, but it
is RECOMMENDED that the EAP-TLS server accept resumption if the
ticket which was issued is still valid.  However, the EAP-TLS server
MAY choose to require a full handshake.  In the case a full handshake
is required, the negotiation proceeds as if the session was a new
authentication, and resumption had never been requested.  The
requirements of Sections section_auth and ticket then apply in their
entirety.  As described in Appendix C.4 of RFC8446, reuse of a ticket
allows passive observers to correlate different connections.  EAP-TLS
peers and EAP-TLS servers SHOULD follow the client tracking
preventions in Appendix C.4 of RFC8446.
Paragraph (version B):
For TLS 1.3, resumption is described in Section 2.2 of RFC8446.  If
the client has received a NewSessionTicket message from the EAP-TLS
server, the client can use the PSK identity associated with the
ticket to negotiate the use of the associated PSK.  If the EAP-TLS
server accepts it, then the resumed session has been deemed to be
authenticated, and securely associated with the prior authentication
or resumption.  It is up to the EAP-TLS peer to use resumption, but
it is RECOMMENDED that the EAP-TLS peer use resumption if it has a
valid ticket that has not been used before.  It is left to the EAP-
TLS server whether to accept resumption, but it is RECOMMENDED that
the EAP-TLS server accept resumption if the ticket which was issued
is still valid.  However, the EAP-TLS server MAY choose to require a
full handshake.  In the case a full handshake is required, the
negotiation proceeds as if the session was a new authentication, and
resumption had never been requested.  The requirements of Sections
section_auth and ticket then apply in their entirety.  As described
in Appendix C.4 of RFC8446, reuse of a ticket allows passive
observers to correlate different connections.  EAP-TLS peers and EAP-
TLS servers SHOULD follow the client tracking preventions in
Appendix C.4 of RFC8446.
Paragraph (version A):
The EAP server identity in the TLS server certificate is typically a
fully qualified domain name (FQDN) in the SubjectAltName (SAN)
extension.  Since EAP-TLS deployments may use more than one EAP
server, each with a different certificate, EAP peer implementations
SHOULD allow for the configuration of a unique trusted root (CA
certificate) to authenticate the server certificate and one or more
server names to match against the SubjectAltName (SAN) extension in
the server certificate.  To simplify name matching, an EAP-TLS
deployment can assign a name to represent an authorized EAP server
and EAP Server certificates can include this name in the list of SANs
for each certificate that represents an EAP-TLS server.  If server
name matching is not used, then peers may end up trusting servers for
EAP authentication that are not intended to be EAP servers for the
network.  If name matching is not used with a public root CA, then
effectively any server can obtain a certificate which will be trusted
for EAP authentication by the Peer.  While this requirement to verify
domain names is new, and was not mentioned in RFC5216, it has been
widely implemented in EAP-TLS peers.  As such, it is believed that
this section contains minimal new interoperability or implementation
requirements on EAP-TLS peers and can be applied to earlier versions
of TLS.
Paragraph (version B):
The EAP server identity in the TLS server certificate is typically a
fully qualified domain name (FQDN) in the SubjectAltName (SAN)
extension.  Since EAP-TLS deployments may use more than one EAP
server, each with a different certificate, EAP peer implementations
SHOULD allow for the configuration of one or more trusted root
certificates (CA certificate) to authenticate the server certificate
and one or more server names to match against the SubjectAltName
(SAN) extension in the server certificate.  If any of the configured
names match any of the names in the SAN extension then the name check
passes.  To simplify name matching, an EAP-TLS deployment can assign
a name to represent an authorized EAP server and EAP Server
certificates can include this name in the list of SANs for each
certificate that represents an EAP-TLS server.  If server name
matching is not used, then it degrades the confidence that the EAP
server with which it is interacting is authoritative for the given
network.  If name matching is not used with a public root CA, then
effectively any server can obtain a certificate which will be trusted
for EAP authentication by the Peer.  While this requirement to verify
domain names is new, and was not mentioned in RFC5216, it has been
widely implemented in EAP-TLS peers.  As such, it is believed that
this section contains minimal new interoperability or implementation
requirements on EAP-TLS peers and can be applied to earlier versions
of TLS.