Draft: draft-ietf-emu-eap-tls13

Commentary: Update to identity validation section . 
 This seems ready to merge .
Paragraph (version A):
The EAP peer identity provided in the EAP-Response/Identity is not
authenticated by EAP-TLS.  Unauthenticated information SHALL NOT be
used for accounting purposes or to give authorization.  The
authenticator and the EAP-TLS server MAY examine the identity
presented in EAP-Response/Identity for purposes such as routing and
EAP method selection.  EAP-TLS servers MAY reject conversations if
the identity does not match their policy.  Note that this also
applies to resumption, see Sections resumption, secauth, and secres.
Paragraph (version B):
The EAP peer identity provided in the EAP-Response/Identity is not
authenticated by EAP-TLS.  Unauthenticated information MUST NOT be
used for accounting purposes or to give authorization.  The
authenticator and the EAP-TLS server MAY examine the identity
presented in EAP-Response/Identity for purposes such as routing and
EAP method selection.  EAP-TLS servers MAY reject conversations if
the identity does not match their policy.  Note that this also
applies to resumption, see Sections resumption, secauth, and secres.
Paragraph (version A):
The EAP server identity in the TLS server certificate is typically a
fully qualified domain name (FQDN).  EAP peer implementations SHOULD
allow users to configuring a unique trust root (CA certificate) and a
server name to authenticate the server certificate and match the
subjectAlternativeName (SAN) extension in the server certificate with
the configured server name.  In the absence of a user-configured root
CA certificate, implementations MAY rely on system-wide root CA
certificate bundles for authenticating the server certificate.  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
CA bundle, then effectively any server can obtain a certificate which
will be trusted for EAP authentication by the Peer.
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 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.
Paragraph (version A):
The process of configuring a root CA certificate and a server name is
non-trivial and therefore automated methods of provisioning are
RECOMMENDED.  For example, the eduroam federation RFC7593 provides a
Configuration Assistant Tool (CAT) to automate the configuration
process.  In the absence of a trusted root CA certificate (user
configured or system-wide), EAP peers MAY implement a trust on first
use (TOFU) mechanism where the peer trusts and stores the server
certificate during the first connection attempt.  The EAP peer
ensures that the server presents the same stored certificate on
subsequent interactions.  Use of TOFU mechanism does not allow for
the server certificate to change without out-of-band validation of
the certificate and is therefore not suitable for many deployments.
Paragraph (version B):
The process of configuring a root CA certificate and a server name is
non-trivial and therefore automated methods of provisioning are
RECOMMENDED.  For example, the eduroam federation RFC7593 provides a
Configuration Assistant Tool (CAT) to automate the configuration
process.  In the absence of a trusted root CA certificate (user
configured or system-wide), EAP peers MAY implement a trust on first
use (TOFU) mechanism where the peer trusts and stores the server
certificate during the first connection attempt.  The EAP peer
ensures that the server presents the same stored certificate on
subsequent interactions.  Use of a TOFU mechanism does not allow for
the server certificate to change without out-of-band validation of
the certificate and is therefore not suitable for many deployments
including ones where multiple EAP servers are deployed for high
availability.