Re: [Emu] EAP-TLS 1.3 Section 2.2 text

[Joseph Salowey <[e-mail]>]

I proposed a PR#72
<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/72> based on this
suggestion. The resulting text for the section is below.  Please review to
see if it is OK.

Thanks,

Joe

2.2.  Identity Verification

   This section updates Section 2.2 of [RFC5216].

   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 2.1.3, 5.6, and 5.7.

   The EAP server identity in the TLS server certificate is typically a
   fully qualified domain name (FQDN).  EAP peer implementations SHOULD
   allow users to configure 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.  EAP-TLS deployments will often use more
   than one EAP server.  In this case each EAP server may have a
   different certificate.  To facilitate SAN matching, EAP Server
   certificates can include the same name in the list of SANs for each
   certificate that represents the EAP-TLS servers.  EAP-TLS peers
   SHOULD allow for the configuration of multiple EAP server names since
   deployments may choose to use multiple EAP servers each with their
   own 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 root CA, then effectively any server can obtain a
   certificate which will be trusted for EAP authentication by the Peer.


   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.


On Mon, May 10, 2021 at 5:11 AM Alan DeKok <[e-mail]>
wrote:

> On May 9, 2021, at 9:16 PM, Joseph Salowey <[e-mail]> wrote:
> > [Joe]  This is a good question.  There are multiple ways this could be
> addressed.  All servers should have one of their list of SANs that matches
> the name used for EAP servers.  Another option is for supplicants to allow
> for the configuration of multiple certificates or allow for a wild card
> match.
>
>   FWIW, wpa_supplicant has a list of allowed host names for SAN.  I don't
> think it allows wildcards.
>
> >   How about this text addition:
> >
> > "EAP-TLS deployments will often use more than one EAP server.  In this
> case each EAP server may have a different certificate.  To facilitate the
> SAN matching, EAP Server certificates can include the same name in the list
> of SANs for each certificate that represents the EAP-TLS servers.  EAP-TLS
> peers SHOULD allow for the configuration of multiple EAP server names since
> deployments may choose to use multiple EAP servers each with their own
> certificate."
>
>   That's good.
>
> > [Joe] Is your comment about HA and the TOFU mechanism?  I'm not really
> sure how the TOFU mechanism is supposed to work and be secure.  Perhaps we
> should remove the TOFU mechanism text or state that it does not work well
> in all HA configurations (where different servers use different
> certificates)
>
>   Perhaps just state that it does not work well in HA configurations.
>
>   I don't think TOFU can be secure here.
>
>   Alan DeKok.
>
>