Subject: [Emu] Best practices for supplicants and authenticators

From: Alan DeKok <[email-masked]>
Date: Mon, 18 Nov 2019 09:18:01 -0500

After the meeting earlier today, I made some notes on best practices for supplicants and authenticators.  I think it would be useful to have an official WG document which gives guidance.

Background:

a) the current practice in TLS-based EAP methods is to use certificates with "id-kp-serverAuth" OID set for Extended Key Usage.
b) many supplicants check for this OID, and refuse to perform authentication if it is missing
c) supplicants do not check DNS names or any other field in the certificates
d) as a result of this lack of verification, supplicants ship with all known CAs disabled for TLS-based EAP methods

  If the supplicants did ship with root CAs enabled, then because of the lack of validation in (c), the supplicants would hand over user credentials to any authenticator who has a properly signed certificate.  This is wrong, and is why all of the root CAs are disabled.

  It would be useful to simplify the user experience when working with EAP-TLS.  It would also be useful to reduce security issues.  This is where a new document is needed.  I believe that the standards exist to support these goals.  However, there's a lack of guidance around using these standard.  It would be good to document current practices, and then give guidance on how to upgrade to better practices.

  I'll start off describing the end goal, and then discuss how we can get there.

  The goal is to have certificates which contain the id-kp-eapOverLAN OID (RFC 4334), and either the NAIRealm OID (RFC 7585), or a similar one dedicated to TLS-based EAP authentication.  Supplicants can use these fields to verify that the certificate is both intended to be used for TLS-based EAP authentication, and that the certificate is for a given realm.

  The end user experience *should* be something like:

* connect to a system which uses 802.1X authentication (SSID, wired, etc)
* prompt the user for full credentials (user id + realm / password)
* validate that the server certificate has the id-kp-eapOverLAN OID set, AND that the NAIRealm OID matches the user's realm
* validate the certificate chain

  If those validation steps succeed, then the supplicant could send the users credentials over the EAP method.  I think that this extra validation means that supplicants can trust known root CAs by default.  Which makes the user experience much better.

  Since the certificates do not currently contain these fields, and supplicants don't check them, we need an upgrade path.

  The first step is to suggest that admins generate certificates with the above fields.  This likely means that certificate authorities will be asked to sign certs with the NAIRealm OID, which they might not do.  This limitation is less of a problem in a roaming federation like Eduroam, where they are their own CA.

  The next step is to suggest that supplicant vendors upgrade their systems to allow the id-kp-eapOverLAN OID, *or* the id-kp-serverAuth in server certificates.  That is a simple change, and shouldn't have any negative affects.

  Supplicants can also be upgraded to check the NAIRealm.  If the field does not match the users realm, then the certificate should be rejected.  If the field does match, then the supplicant should validate the certificate chain.  This validation should also include trusting known root CAs by default.

  We should also recommend that supplicant vendors check the id-mod-dns-srv-name-88 and id-mod-dns-srv-name-93 fields of server certificates.  If the domain names there do not match the realm given by the user, then the user should be warned, and the certificate rejected.

  If accepted, I think that such practices would tremendously simplify the use of TLS-based EAP methods for both users and administrators.

  Alan DeKok.

---

From: "Cappalli, Tim (Aruba)" <[email-masked]>
Date: Mon, 18 Nov 2019 15:22:58 +0000

So again, if NAIRealm is not bound to an organization’s public domain name, how does a public CA prove ownership of an NAIRealm? How is this different than ESSID?

I don’t see how this improves assurance of a server identity.

tim

From: Emu <[email-masked]>
Date: Monday, November 18, 2019 at 9:18 AM
To: EMU WG <[email-masked]>
Subject: [Emu] Best practices for supplicants and authenticators
  After the meeting earlier today, I made some notes on best practices for supplicants and authenticators.  I think it would be useful to have an official WG document which gives guidance.

Background:

  Alan DeKok.

_______________________________________________
Emu mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/emu

---

From: Jan-Frederik Rieckers <[email-masked]>
Date: Mon, 18 Nov 2019 16:29:53 +0100

On 18.11.19 16:22, Cappalli, Tim (Aruba) wrote:
> So again, if NAIRealm is not bound to an organization’s public domain
> name, how does a public CA prove ownership of an NAIRealm? How is this
> different than ESSID?

It must not be a public domain name, but it can be.

Speaking of eduroam this is usually the case, and is also used for
roaming. (See RFC7585, the NAPTR DNS record)
And if it is, it can be validated by a CA.

  Janfred

---

From: Alan DeKok <[email-masked]>
Date: Mon, 18 Nov 2019 10:34:29 -0500

> On Nov 18, 2019, at 10:22 AM, Cappalli, Tim (Aruba) <[email-masked]> wrote:
> 
> So again, if NAIRealm is not bound to an organization’s public domain name,

  I never suggested that or implied it.  I'm not sure why it's relevant.

> how does a public CA prove ownership of an NAIRealm? How is this different than ESSID?

  I had hoped that my point was clear.

  The requirement would be for the NAIReam to be in the same domain as rest of the certificate.  Anything else makes zero sense.

  i.e. if the certificate is from "example.org", then the NAIRealm should be "example.org", or any other name within that domain.  Such as "radius.example.org"

> I don’t see how this improves assurance of a server identity.

  No one proposed the position you're opposing, so the conclusion above is irrelevant.

  On the other hand, if the requirement is that the NAIRealm be the domain name, then it makes perfect sense, and it's useful.

  We can't use existing fields to derive the NAIRealm.  The common name is typically an email address and *not* a domain name.   The various DNS fields are DNS host names (FQDNs), and not domain names.  We can *suggest* that supplicants can check these fields.  But it involves parsing them, and deriving *implicit* meaning from them.

  In contrast, an NAIRealm field is *explicit* meaning, that doesn't require additional derivation.

  I think that explicit statements of intent are useful.  I don't see why there's any controversy about this.

  Alan DeKok.

---

From: "Cappalli, Tim (Aruba)" <[email-masked]>
Date: Mon, 18 Nov 2019 15:37:05 +0000

If the goal is not to improve identity assurance of an EAP server then what is this best practice change actually for?

From: Alan DeKok <[email-masked]>
Date: Monday, November 18, 2019 at 10:34 AM
To: Cappalli, Tim (Aruba) <[email-masked]>
Cc: EMU WG <[email-masked]>
Subject: Re: [Emu] Best practices for supplicants and authenticators

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 18 Nov 2019 10:43:29 -0500

> If the goal is not to improve identity assurance of an EAP server then what is this best practice change actually for?

  I have been *explicit* in my statements that my goal *is* to improve validation of the EAP server identity.  I have no idea how anyone could interpret those statements as meaning the opposite of their clear intent.

  So I have no idea what you're getting at.  Please explain yourself using something *other* than a leading question which gets everything wrong.

  i.e. state a position and defend it.  Attacking a straw man version of someone else's position is unhelpful.

  Alan DeKok.

---

From: "Cappalli, Tim (Aruba)" <[email-masked]>
Date: Mon, 18 Nov 2019 15:47:05 +0000

Alan – Adding yet another OID and/or EKU to a certificate does not change the fact that no authority can attest to that information. A public CA cannot validate a ownership of an NAIRealm. So while a supplicant could be configured to validate that the server’s NAIRealm matches the local configuration, that doesn’t change the requirement to manually configure the supplicant. So what are we actually trying to improve here?

Date: Monday, November 18, 2019 at 10:43 AM

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 18 Nov 2019 10:57:19 -0500

> On Nov 18, 2019, at 10:47 AM, Cappalli, Tim (Aruba) <[email-masked]> wrote:
> 
> Alan – Adding yet another OID and/or EKU to a certificate does not change the fact that no authority can attest to that information. A public CA cannot validate a ownership of an NAIRealm. 

  That's not true.

  Public CAs validate ownership of domain names. The NAIRealm is a domain name.  And, the NAIRealm is the *same* as the domain name in the certificate.  Which the CA validated.

  Unless you have a counter-argument, that discussion should be closed.

> So while a supplicant could be configured to validate that the server’s NAIRealm matches the local configuration, that doesn’t change the requirement to manually configure the supplicant.

  I explained how it could simplify the supplicants configuration.

> So what are we actually trying to improve here?

  See my previous messages for explanations.

  Alan DeKok.

---

From: "Cappalli, Tim (Aruba)" <[email-masked]>
Date: Mon, 18 Nov 2019 16:01:34 +0000

So you’re saying an NAIRealm must be a publicly registered domain name? I agree, but just want to be crystal clear.

tim

Date: Monday, November 18, 2019 at 10:57 AM

  That's not true.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 18 Nov 2019 11:04:36 -0500

> So you’re saying an NAIRealm must be a publicly registered domain name? I agree, but just want to be crystal clear.

  Yes.  See RFC 7542.  It defines the NAI in some detail.

  Alan DeKok.

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Wed, 20 Nov 2019 03:40:25 +0000

Assuming that NAIRealm is a registered domain as per RFC 7542, and thus public CAs can verify ownership, the goal / where we want to get to is:

- CA may be a public CA and thus public CAs can be enabled by default in supplicant config
- supplicant checks NAI Realm in the EAP identity cert matches that of the user's realm
- supplicant verifies id-kp-eapOverLAN is set

And also assuming that public CAs will not issue certs with an NAIRealm or id-kp-eapOverLAN bit. (This is certainly true for Let's Encrypt. See below for details.) And it could be years before public CAs do.

Does that mean there is an intermediate rollout phase where the supplicant checks that the realm the user enters matches a dNSName in the EAP cert?

The rollout / upgrade issue with this is of course if we give guidance that supplicants
(i) check that entered realm matches NAIRealm; and id-kp-eapOverLAN is set
If that fails then (ii) check that dNSName matches entered realm

at what point in time would supplicant behaviour ever change to remove the fallback to option (ii) and checking dNSName only?

As a data point on RFC 4985 and id-mod-dns-srv-name-93 (or RFC 6125 SRV-IDs): Public CAs generally don't issue these either, so the same issue with supplicants checking for NAIRealm or id-kp-eapOverLAN exists with id-mod-dns-srv-name-93 w.r.t. Public CAs.

Owen

P.S.: Let's Encrypt implementation is at: https://github.com/letsencrypt/boulder

You can see the only allowed KeyUsage and ExtKeyUsage bits here:

https://github.com/letsencrypt/boulder/blob/master/cmd/gen-ca/main.go#L318

https://github.com/letsencrypt/boulder/blob/master/cmd/cert-checker/main.go#L303

-----Original Message-----
From: Emu <[email-masked]> On Behalf Of Alan DeKok
Sent: 18 November 2019 14:18
To: EMU WG <[email-masked]>
Subject: [Emu] Best practices for supplicants and authenticators

Background:

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 20 Nov 2019 09:16:24 -0500

> - CA may be a public CA and thus public CAs can be enabled by default in supplicant config

  I would add: only if the new checks pass.

> - supplicant verifies id-kp-eapOverLAN is set

  In addition to id-kp-serverAuth.  We still need a way to distinguish server certificates from client certificates.

> And also assuming that public CAs will not issue certs with an NAIRealm or id-kp-eapOverLAN bit. (This is certainly true for Let's Encrypt. See below for details.) And it could be years before publ…

  I agree.

> Does that mean there is an intermediate rollout phase where the supplicant checks that the realm the user enters matches a dNSName in the EAP cert?

  It's worth checking that anyways.  It can be done quickly by supplicants, and doesn't require changes to any CAs.

> If that fails then (ii) check that dNSName matches entered realm

  Yes.

> at what point in time would supplicant behaviour ever change to remove the fallback to option (ii) and checking dNSName only?

  I'm not sure.

> As a data point on RFC 4985 and id-mod-dns-srv-name-93 (or RFC 6125 SRV-IDs): Public CAs generally don't issue these either, so the same issue with supplicants checking for NAIRealm or id-kp-eapOve…

   I agree.

  TBH, even if these practices are only implemented in a roaming consortium, they will still be useful.  A roaming consortium can create their own CA with their own rules.

  i.e. even if just Eduroam adopts this practice, then it can be used by millions, if not tens of millions of people.  And making EAP easier to use is always of enormous utility.

  Alan DeKok.