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

From: John Mattsson <[email-masked]>
Date: Tue, 8 Jun 2021 09:25:37 +0000

Hi Oleg,

"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."

Do you have any concrete suggestions for improvements of this section Oleg?
This second part of the paragraph seems to discuss what happens if the
advice in the first half is not followed. When I conect to Ericsson's
internal WiFi network, I would expect checks that I am taking to the EAP
server, not the printer. I would also expect checks that I talk with
Ericsson EAP server, and not Huawei's or Nokia's EAP server. Should
Network be replaced by a better term?

Some comments from me on Section 2.2

"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."

This requires some security consideration, I think....

"Iimplementations MAY rely on system-wide root CA
certificate bundles for authenticating the server certificate.
If server name matching is not used"

This seems to indicate that it is ok to not do any server authentication. The TLS CertificateVerify message does not give any authentication in itself, it only enables the application using TLS to do authentication.

Section 2.2. "Identity Verification" needs to match current deployments and uses of EAP-TLS. But if EAP-TLS does not even mandate server authentication, does it really make sense to mandate revocation?

Cheers,
John

From: Emu <[email-masked]> on behalf of Oleg Pekar <[email-masked]>
Date: Monday, 31 May 2021 at 17:46
To: Joseph Salowey <[email-masked]>
Cc: [email-masked] <[email-masked]>, EMU WG <[email-masked]>
Subject: Re: [Emu] EAP-TLS 1.3 Section 2.2 text
This version is fine. Just the term "EAP servers for the network" still looks confusing to me. Maybe we can use instead the more detailed explanation that you provided above.

On Tue, May 25, 2021 at 7:45 AM Joseph Salowey <[email-masked]<mailto:[email-masked]>> wrote:
I made some changes to the pull request to address some of the comments and make the text clearer:

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 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) 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.

   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 Thu, May 20, 2021 at 10:23 PM Joseph Salowey <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, May 19, 2021 at 5:58 AM Alan DeKok <[email-masked]<mailto:[email-masked]>> wrote:
On May 19, 2021, at 8:37 AM, Oleg Pekar <[email-masked]<mailto:[email-masked]>> wrote:
> After thinking a bit more about it - for the sake of the client implementation clarity, would it be better if we provide the strict algorithm for server identity check or maybe reference RFC 6125.

  Given the time frame and what we know, I think the existing text is OK.

[Joe] In addition the intent of the text is to make implementers aware of the issues and provide some guidance as to how to solve the problem.  I don't think we can dictate too much more at this point.   We can have follow-on work to have a strict algorithm is depolyers and implementers feel it is necessary.

  This is what wpa_supplicant does in it's implementation, and it seems to work fine.  Apple appears to do the same thing:

https://opensource.apple.com/source/eap8021x/eap8021x-264.30.3/EAP8021X.fproj/EAPTLSUtil.c.auto.html

  Look for "trusted_server_names", which leads to:

https://opensource.apple.com/source/eap8021x/eap8021x-156/EAP8021X.fproj/EAPTLSUtil.c

server_name_matches_server_names()

  Which checks if the name from the cert is an exact match for one of the "trusted_server_names", or contains "*." followed by a suffix which is one of the trusted server names.

  I think it's past the time where this document can ask supplicants to change their behavior.  We know what the supplicants do, it's not wrong, and it seems to work.  So let's document that, and move on.

  Alan DeKok.