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

From: Joseph Salowey <[email-masked]>
Date: Sun, 9 May 2021 18:16:55 -0700

Alan's review made the following comments:

>  Section 2.2 has substantial new text which was not previously discussed
on the WG mailing list.

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

> Comment: How does this text related to RFC 5216 Section 5.2 ?  There
seems to be substantial overlap.

> What does this text add to / change from RFC 5216 Section 5.2 ?

[Joe] It was brought up in discussions that RFC 5216 does not sufficiently
describe how to validate the identity in the certificate.

>  Requiring a supplicant to be configured with a peer name is a new
requirement from RFC 5216, and isn't called out as such.

[Joe]  This can be called out in this section

>  What happens in a high availability (HA) environment?  Are all of the
EAP servers required to have the same FQDN?

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

>  While this text is intended to increase security, there are
implementation and operational considerations which need addressing.

>   In the absence of a user-configured root
>  CA certificate,

> Comment: I'm not sure what that means.  It seems to assume certain things
without explaining them.

[Joe] This text doesn't seem to add much.  I'd suggest removing that
sentence.

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

>  i.e. when there's an HA configuration.

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

---

From: Alan DeKok <[email-masked]>
Date: Mon, 10 May 2021 08:11:15 -0400

On May 9, 2021, at 9:16 PM, Joseph Salowey <[email-masked]> 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.

---

From: Joseph Salowey <[email-masked]>
Date: Sat, 15 May 2021 17:21:58 -0700

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 <[email-masked]>
wrote:

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

---

From: Alan DeKok <[email-masked]>
Date: Mon, 17 May 2021 08:44:10 -0400

On May 15, 2021, at 8:21 PM, Joseph Salowey <[email-masked]> wrote:
> I proposed a PR#72 based on this suggestion. The resulting text for the section is below.  Please review to see if it is OK.

  It looks good, subject to minor comments.

>    authenticated by EAP-TLS.  Unauthenticated information SHALL NOT be

  This is just a personal preference, but "MUST NOT" is clearer to me than SHALL NOT.  It's also more used, IIRC.

>    server name to authenticate the server certificate and match the

  The later text discusses multiple names, so perhaps instead

	... and one or more server names ...

  Alan DeKok.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 17 May 2021 14:46:36 +0200

Let this be the biggest argument on this list ;-)

> On 17 May 2021, at 14:44, Alan DeKok <[email-masked]> wrote:
> 
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 17 May 2021 12:06:07 -0400

Nit: RFC 5280 (see Section 4.2.1.6) talks about the subject alternative name extension, which as an ASN.1 definition for SubjectAltName.  So, please do not refer to subjectAlternativeName.

Russ

> 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
> 
> On Mon, May 10, 2021 at 5:11 AM Alan DeKok <[email-masked] <mailto:[email-masked]>> wrote:
> On May 9, 2021, at 9:16 PM, Joseph Salowey <[email-masked] <mailto:[email-masked]>> wrote:
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: Oleg Pekar <[email-masked]>
Date: Mon, 17 May 2021 23:58:53 +0300

To section: 2.2.  Identity Verification

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

-- comment:
What is meant by "EAP server for the network"?

2)
EAP peer implementations SHOULD allow users to configuring a unique trust
root (CA certificate)

-- comment:
Should say "a unique trusted root" in conformance with the other occurrence.

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

-- comment:
Could you please clarify the idea of adding the same name to SAN of
multiple certificates, since some EAP-TLS server certificates are just
generic certificates and their SAN DNS and IP fields may contain the unique
value per server instance.

Regards,
Oleg

On Mon, May 17, 2021 at 7:06 PM Russ Housley <[email-masked]> wrote:

> Nit: RFC 5280 (see Section 4.2.1.6) talks about the subject alternative
> name extension, which as an ASN.1 definition for SubjectAltName.  So,
> please do not refer to subjectAlternativeName.
>
> Russ
>
>
> <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
>

---

From: Oleg Pekar <[email-masked]>
Date: Wed, 19 May 2021 15:37:39 +0300

+Peter

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.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 19 May 2021 08:58:29 -0400

On May 19, 2021, at 8:37 AM, Oleg Pekar <[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.

  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.

---

From: Joseph Salowey <[email-masked]>
Date: Thu, 20 May 2021 22:23:11 -0700

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

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 24 May 2021 21:45:30 -0700

I made some changes to the pull request to address some of the comments and
make the text clearer:

   authenticated by EAP-TLS.  Unauthenticated information MUST NOT be

   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.

On Thu, May 20, 2021 at 10:23 PM Joseph Salowey <[email-masked]> wrote:

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

---

From: Alan DeKok <[email-masked]>
Date: Tue, 25 May 2021 08:20:01 -0400

I think that's good.

> On May 25, 2021, at 12:45 AM, Joseph Salowey <[email-masked]> wrote:
> 
> I made some changes to the pull request to address some of the comments and make the text clearer:
> 
> On Wed, May 19, 2021 at 5:58 AM Alan DeKok <[email-masked]> wrote:
> [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.  
>

---

From: Heikki Vatiainen <[email-masked]>
Date: Tue, 25 May 2021 17:45:37 +0300

> and make the text clearer:

One note about the TOFU mechanism: What we've seen is that certificate
renewal also triggers server certificate re-trust query/prompt/other
action. That is, even if the issuing CA, public key and subject/SAN names
remain the same, the certificate is deemed as changed by the EAP peer. In
other words, if only validity dates have changed in the certified
information, users a prompted again.

Should TOFU defined more closely in a future document, it could be
beneficial to give guidance which changes are accepted without validation.
One option is to not allow any changes, but allowing some renewals to be
accepted transparently could be useful. This is espcially seen with public
root CAs where certificate validity periods are getting shorter.

I'm not suggesting changes to the text below. The above is just a
consideration for any possible future documents that relate to TOFU.

-- 
Heikki Vatiainen
[email-masked]

---

From: Oleg Pekar <[email-masked]>
Date: Mon, 31 May 2021 18:46:13 +0300

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]> wrote:

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