Subject: [Emu] Idea: New X509 Extension for securing EAP-TLS

From: Jan-Frederik Rieckers <[email-masked]>
Date: Sat, 9 Nov 2019 18:33:18 +0100

Hi to all,

I have submitted a draft for a new X509v3 extension to improve security
in EAP environments by including information which is implicitly defined
by the communication context in the certificate .
This is done e.g. by including the Realm of the username in the
certificate, to give clients the opportunity to decide if the
certificate can be trusted apart from (user-set) configuration.

https://datatracker.ietf.org/doc/draft-rieckers-eapparameterextension/

This is a very early working state. I would be happy to get feedback if
this is useful and the draft goes into the right direction.

If people are interested I would prepare a short presentation about
deployment experiences in the eduroam at the University Bremen,
which have lead to this draft, together with the basic idea how to solve
these problems.

Probably this draft is not one which can or will be adopted by the EMU
working group, but I think this is the right group of people for a first
feedback.

Kind regards

Jan-Frederik Rieckers

---

From: Russ Housley <[email-masked]>
Date: Sat, 9 Nov 2019 13:00:03 -0500

With a very quick skim, it appears that you are trying to do the same thing as RFC 7585.

Russ

> On Nov 9, 2019, at 12:33 PM, Jan-Frederik Rieckers <[email-masked]> wrote:
> 
> Signed PGP part
> Hi to all,
>

---

From: Alan DeKok <[email-masked]>
Date: Sat, 9 Nov 2019 14:52:29 -0500

> With a very quick skim, it appears that you are trying to do the same thing as RFC 7585.

  I think there's overlap, but it's not quite the same thing.

  Both proposals add a "known realm" as an X.509 certificate property.  They differ in their usage, and in who is checking the fields.  I'll quickly recap:

  RFC 7585 allows for RADIUS clients to dynamically discover RADIUS servers via DNS.  As a sanity check, the discovered RADIUS server should induce the "known realm" in its server certificate.  The RADIUS client verifies that the "known realm" field matches the domain it was looking for.  Note that this verification is done by a RADIUS client, and is independent of the authentication mechanism carried inside of RADIUS.  (PAP, CHAP, EAP, etc.)

  In this proposal, the supplicant is the component which is checking the "known realm" field.  The supplicant verifies that the NAI it's sending matches the "known realm" sent by the server.

  It is common practice today for server certificates to include a contact email address in the common name field.  However, there's no requirement that this is done.  No one checks the domain of that email address against the NAI being used by the supplicant.

  I think that this proposal may be useful.  Given that the parties who check this field do so for different purposes, it may be useful to have two separate OIDs.

  On the other hand, RCC 7585 uses the OID for TLS connections which then carry RADIUS packets.  This draft would use an OID for EAP-TLS authentications, which are carried inside of RADIUS, and then inside of UDP / TCP / TLS / DTLS.  The uses-cases may be different enough to warrant re-use of the same OID.

  Alan DeKok.

---

From: Russ Housley <[email-masked]>
Date: Sun, 10 Nov 2019 11:16:13 -0500

>  On the other hand, RCC 7585 uses the OID for TLS connections which then carry RADIUS packets.  This draft would use an OID for EAP-TLS authentications, which are carried inside of RADIUS, and then…

Thanks for the overview.  It was very helpful.

RFC 7586 define the NAIRealm as an otherName in the SubjectAltName of a certificate.  It seems that the NAIRealm name form works equally well, regardless of the role that the certificate holder is performing in the protocol.

Russ

---

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

> Thanks for the overview.  It was very helpful.

  Glad to help.

> RFC 7586 define the NAIRealm as an otherName in the SubjectAltName of a certificate.  It seems that the NAIRealm name form works equally well, regardless of the role that the certificate holder is…

  I agree.

  TBH, I like this proposal for securing EAP-TLS.  It may take time to deploy, but adding more clarity to certificates is always useful.  I'd be in favour of WG adoption of a document based on this.

  FWIW, a configuration file that creates certificates with the NAIRealm is located here:

https://github.com/FreeRADIUS/freeradius-server/blob/master/raddb/certs/server.cnf

  Alan DeKok.

---

From: Jan-Frederik Rieckers <[email-masked]>
Date: Mon, 11 Nov 2019 10:42:05 +0100

Hi,
Thank you for your feedback.

I was unaware of RFC 7585. I had a brief look on it and it seems that
the certificate part could be used for the goal I try to achieve.

I'm not quite sure if the naiRealm should be used for validation on
supplicants for EAP-TLS. I would assume it would not be a security
issue, but I don't have enough experience to be sure about that.

The main reason why I submitted this draft is my experience from the
deployment of eduroam at University Bremen.
With expiry of the used root CA and the needed migration, we have forced
all our users to use one specific outer Identity, to be sure the users
configure their devices with the eduroam Configuration Assistant Tool
(CAT, cat.eduroam.org) instead of a manual configuration, because in our
experience manual configured devices almost always lacked configuration
for certificate checking.
But I just have experience in local deployment, the federation
connections are done at higher levels (country research networks), I
don't have an insight there.

Greetings,
Jan-Frederik Rieckers

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Mon, 11 Nov 2019 23:15:36 +0000

This is also related to ongoing anima discussions about RFC 8366, and how it can bootstrap trust when the pinned domain cert is a public PKI CA, and not a private CA, and hence additional domain (or realm or FQDN) info is also needed in order for the peer to verify the identity of the server.

Its also relevant for ongoing Wi-Fi Alliance DPP discussions about bootstrapping a supplicant onto an 802.1X network - after a supplicant completes DPP and gets provisioned with a trust anchor - what if that trust anchor is a public PKI? It’s the same problem.

One deployment consideration is if an operator wants to use a public PKI (e.g. Lets Encrypt) for their AAA certs, then it could be years, if ever, before these extensions could be supported (as Alan alludes to), so it would also be good to define how this could work with standard RFC 6125 DNS-IDs / RFC 5280 dNSNames.

> -----Original Message-----
> From: Emu <[email-masked]> On Behalf Of Jan-Frederik Rieckers
> Sent: 11 November 2019 09:42
> To: Alan DeKok <[email-masked]>; Russ Housley
> <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
> 
> Hi,
> I was unaware of RFC 7585. I had a brief look on it and it seems that the
> certificate part could be used for the goal I try to achieve.
> 
> I'm not quite sure if the naiRealm should be used for validation on supplicants
> for EAP-TLS. I would assume it would not be a security issue, but I don't have
> enough experience to be sure about that.
> 
> With expiry of the used root CA and the needed migration, we have forced all
> our users to use one specific outer Identity, to be sure the users configure their
> devices with the eduroam Configuration Assistant Tool (CAT, cat.eduroam.org)
> instead of a manual configuration, because in our experience manual configured
> devices almost always lacked configuration for certificate checking.
> But I just have experience in local deployment, the federation connections are
> done at higher levels (country research networks), I don't have an insight there.
> 
> Greetings,
> Jan-Frederik Rieckers

---

From: Alan DeKok <[email-masked]>
Date: Mon, 11 Nov 2019 20:07:16 -0500

> One deployment consideration is if an operator wants to use a public PKI (e.g. Lets Encrypt) for their AAA certs, then it could be years, if ever, before these extensions could be supported (as Ala…

  That sounds reasonable.

  Certificates for 802.1X authentication already use DNS names.  It's not wide-spread, but it's not rare.  There's no *meaning* to these names, as nothing checks them.

  It would be useful to suggest how a supplicant can use these fields to further verify a server certificate.  And for servers, what these fields should contain.

  Alan DeKok.

---

From: Jan-Frederik Rieckers <[email-masked]>
Date: Tue, 12 Nov 2019 08:53:46 +0100

> One deployment consideration is if an operator wants to use a public PKI (e.g. Lets Encrypt) for their AAA certs, then it could be years, if ever, before these extensions could be supported (as Ala…

I had a lot of thoughts about this topic.
I am experimenting with certificates in EAP-TLS contexts and experienced
the problems with getting a certificate with specific extension
properties from our public PKI. (In my case a test certificate with a
critical MustStaple extension)

The Problem with dNSNames is that they are also used in other contexts
(mainly HTTPS). There would be the possibility to define a specific
prefix to bind it to a Realm without having the certificate being valid
for the HTTPS host (e.g. eap-tls.uni-bremen.de for the realm
uni-bremen.de) but I don't see the advantage in that.
This will probably don't really lead to a change in the supplicants
implementations.

My deployment experience shows, that the certificate check is the main
security problem in WPA2-Enterprise networks. I have seen instructions
for installing WPA2-Enterprise networks where they have explicitly
suggested switching off the certificate check, probably because it was
too complicated for the users and would lead to people complaining at
the IT department about the complicated setup.

A setup of WPA2-Enterprise can be secure if all devices are part of a
centralized Device Management, but especially in eduroam this isn't
possible. We have a lot of people who don't really care about security.

  Jan-Frederik Rieckers

---

From: Michael Richardson <[email-masked]>
Date: Tue, 12 Nov 2019 17:19:39 +0800

> This is also related to ongoing anima discussions about RFC 8366, and how it can bootstrap trust when the pinned domain cert is a public PKI CA, and not a private CA, and hence additional domain (o…

While I'm familiar with this conversation, which I'm right now inspired
to call the the "Maria" problem
("How do solve a problem like Maria.  How do you a cloud certificate and
pin it down?")

I don't really understand what it has to do with the problem of an EAP
client, **which is not doing initial onboarding**, to validate a
certificate that it has received as part of EAP-TLS*.
> Its also relevant for ongoing Wi-Fi Alliance DPP discussions about bootstrapping a supplicant onto an 802.1X network - after a supplicant completes DPP and gets provisioned with a trust anchor - wh…

I agree that this is the Maria problem, because the client has to pin
*a* CA and a SubjectDN (specifically a dnsName SubjectAltName), and you
want to allow the server to change public CAs.

>> done at higher levels (country research networks), I don't have an insight there.

I skimmed your document before and I didn't understand it based upon my
quick read. Your text here helps me a bit.
In eduroam, the supplicant sees the TLSServerCertificate of the local
institution's Authentication Server, correct?
Is it not the case that for this to be validated that there needs to be
a path to the eduroam's root certificate,
which the client would have pinned?

You need to set the NAI correctly, because we have essentially an
SNI-like issue, in that the Authentication Server
needs to answer with it's eduroam certificate for eduroam clients, and
it might use a different certificate for other clients?

As I understand it, your ran into an issue because the root certificate
expired, and clients had pinned it, but they could find a new
certificate in DNS?

---

From: Michael Richardson <[email-masked]>
Date: Tue, 12 Nov 2019 17:28:46 +0800

> critical MustStaple extension)

You were trying to do a CSR with some extra attributes with a CA (using
ACME? Using LetsEncrypt?) and the CA ignored the things that it couldn't
verify?
> This will probably don't really lead to a change in the supplicants

I think you are saying that the problem with dNSNames is that web
servers use them/pay-attention to them, so CAs are careful what they put
in.  That's a reason to avoid that SAN in my opinion.  Toerless, in
draft-ietf-anima-autonomic-control-plane went the other direction, and
argued that only dNSNames have good interoperability, and so we have to
use only them.
> the IT department about the complicated setup.

So, as I understand it, the enrollment process for laptops/phones into
WPA-Enterprise does not include retrieving a set of anchors for that
connection.  Or that it is just too hard to do.   It works fine if the
devices are compelled by their corporate masters, but this fails for
BYOD, and it fails for cross-realm (which eduroam is).

---

From: Jan-Frederik Rieckers <[email-masked]>
Date: Tue, 12 Nov 2019 11:46:24 +0100

> ACME? Using LetsEncrypt?) and the CA ignored the things that it couldn't

No, it was a direct request to the CA of our research network. The
problem here was, that the CA itself would have had to clarify this with
their CA (Telekom Trust Center), because it would mean to set up a new
certificate profile. And that wasn't possible for this one usecase.

> BYOD, and it fails for cross-realm (which eduroam is).

It doesn't. In eduroam this has lead to cat.eduroam.org, where the
installers can be downloaded. As Carsten Borman and I already have
written in a submission for the IAB DEDR workshop[1], with the need of
this tool we also could have used client certificates instead of
username/password combinations.

For a long time it was easy to connect to eduroam without certificate
checking. Especially Android had a very insecure default setting and
most of our users just typed in their username and password and
connected to eduroam without any certificate check. And if the inner
authentication then defaults to PAP an attacker could get many
credentials just by setting up a rogue access point in a crowded place.
And many universities in Germany use PAP because they don't want a
NT-Hashed password in their database.

With the expiry of the old Root CA all clients had to change their
configuration, because (if set up correctly) the root ca was in fact pinned.
We used this rollover to force all our users to use a specific outer
identity, to encourage the use of the CAT.
Since the expiry we also deny all requests with any other outer identity
before the EAP-TLS handshake, to prevent certificate warnings on the
user devices.

Jan-Frederik

---
1: https://www.iab.org/wp-content/IAB-uploads/2019/05/p16-bormann-wifi.txt

---

From: Alan DeKok <[email-masked]>
Date: Tue, 12 Nov 2019 11:32:03 -0500

On Nov 12, 2019, at 2:53 AM, Jan-Frederik Rieckers <[email-masked]> wrote:
> (mainly HTTPS).

  They're also domain names, not realms.  A particular certificate may be valid for authenticating uses to the realm "example.org".  That same certificate may not be valid for the main web site for "example.org".

  This means that domain names are a hint, but not authoritative.  Only the NAIRealm field would be authoritative.  i.e. "this certificate really is for users authenticating to a realm".

> There would be the possibility to define a specific

  A common short-hand is for certificates to use the "radius" subdomain.  e.g. "radius.example.org".  While not perfect, it's something.

> the IT department about the complicated setup.

  Exactly.

> possible. We have a lot of people who don't really care about security.

 What's worse is that there's no cross-platform way to set up 802.1X.  It would be nice if a user could visit an HTTPS secured web site for example.com, and then download a supplicant configuration.  Stefan Winter has a draft:

https://tools.ietf.org/html/draft-winter-opsec-netconfig-metadata-00

  But it received little support from vendors.

  Security should be simple, and it should be the default.  Users don't care about security because it's hard, and because it too often prevents them from getting things done.  If security is useful, they will use it.

  Alan DeKok.

---

From: Russ Housley <[email-masked]>
Date: Tue, 12 Nov 2019 11:43:01 -0500

> possible. We have a lot of people who don't really care about security.

Can the extended key usage for EAP over a LAN ( id-kp-eapOverLAN ) solve this for you?  It is defined in RFC 4334.  A certificate for Web PKI should not include this extended key usage.

RFC 4334 also offers a certificate extension that lists the SSIDs that are associated with the server.

Russ

---

From: Alan DeKok <[email-masked]>
Date: Tue, 12 Nov 2019 15:07:41 -0500

> RFC 4334 also offers a certificate extension that lists the SSIDs that are associated with the server.

  That does sound relevant.  I wasn't even aware of that document.

  While RFC 4334 offers the id-kp-eapOverLAN OID, I'm not aware of anyone using it.  Even Microsoft supplicants still require the TLS web server auth OID (1.3.6.1.5.5.7.3.1).

  So yes, RFC 4334 is absolutely relevant here.

  Alan DeKok.

---

From: "Cappalli, Tim (Aruba)" <[email-masked]>
Date: Tue, 12 Nov 2019 20:13:24 +0000

How does a public CA prove ownership of an SSID?

From: Emu <[email-masked]>
Date: Tuesday, November 12, 2019 at 3:08 PM
To: Russ Housley <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

  Alan DeKok.

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

---

From: Alan DeKok <[email-masked]>
Date: Tue, 12 Nov 2019 18:40:38 -0500

> How does a public CA prove ownership of an SSID?

  Do public CAs *always* verify addresses and/or telephone numbers, which are normally included in certificates?

  Do public CAs verify that email addresses in the certificate work?

  Do public CAs verify that the OIDs in the certificate match the intended use-cases?

  Is there a global registry of SSIDs which the public CA could use to verify the SSID?

  To put it another way, I'm not sure why this question is being posed.

  Alan DeKok.

---

From: "Cappalli, Tim (Aruba)" <[email-masked]>
Date: Tue, 12 Nov 2019 23:59:17 +0000

Regardless of validation levels, it is not possible to own an ESSID. It is possible, however, to own a domain, email address, physical address, etc. That's the difference.

Putting an ESSID in a certificate is a slippery slope. I doubt any public CA or OS vendor would ever entertain this.

Tim

________________________________
From: Alan DeKok <[email-masked]>
Sent: Tuesday, November 12, 2019 18:40
To: Cappalli, Tim (Aruba)
Cc: Russ Housley; [email-masked]
Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 12 Nov 2019 19:59:42 -0500

> Regardless of validation levels, it is not possible to own an ESSID. It is possible, however, to own a domain, email address, physical address, etc. That's the difference. 

  I think that's largely begging the question.

  Your comment seems to be that it's OK for a certificate to include incorrect a physical address, because that address is "owned" by someone.  Even if the owner of that address knows nothing about the certificate request.

  I don't see how that's useful.

  Which is why I asked about validation.  If the CA doesn't validate addresses, why should it validate SSIDs?   Even worse, the CAs verify *control* of domain names.  They don't verify *ownership* of the domain name.  They're not quite the same thing.

  Is the person requesting the certificate the "owner" of the domain name?  If not, is the certificate request authorized by the owner?  None of this is checked by CAs right now.

> Putting an ESSID in a certificate is a slippery slope. I doubt any public CA or OS vendor would ever entertain this.

  Both are well known to do "surprising" things with certificates.  I'm not sure why they would care about additional fields in a certificate.

  My point is that we have loose rules around the subjects of "ownership" and "validation".  Simplistic statements are easy to make, but aren't particularly helpful.

  In my view, if something is useful, practical and can be shown to be not harmful, then I think it can be used.  Putting SSIDs into a certificate seems useful, and (at least) the PKIX WG seemed to have agreed.

  Further,  RFC 4334 in fact contains no text about "ownership" of the SSID.  i.e. inclusion of an SSID in a certificate is *not* a statement about "ownership" of that SSID.  So your comments seem to be against an issue that doesn't exist.

  Alan DeKok.

---

From: Jan-Frederik Rieckers <[email-masked]>
Date: Wed, 13 Nov 2019 15:32:05 +0100

There has been some discussion about this idea. I don't have any
experience in IETF work yet, so I don't know how this discussion can go on.
I would be happy to present my deployment experiences from eduroam and
the basic idea in Singapore. (Since I won't attend the meeting in
person, I would join from remote)
Is there room for that?

 Jan-Frederik Rieckers

---

From: Michael Richardson <[email-masked]>
Date: Thu, 14 Nov 2019 07:23:52 +0800

>   While RFC 4334 offers the id-kp-eapOverLAN OID, I'm not aware of anyone using it.  Even Microsoft supplicants still require the TLS web server auth OID (1.3.6.1.5.5.7.3.1).

I think that the issue isn't, can we find or define a OID that has the
right semantics.
I think that the issue whether or not any public CAs are willing to
include that into a certificate.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 14 Nov 2019 07:26:55 +0800

>   Do public CAs *always* verify addresses and/or telephone numbers, which are normally included in certificates?

They are?  I've rarely seen it.
I think that if it's in the certificate, then they have verified them.
I can remember in the bad old days providing CAs with notorized articles
of incorporation, etc.
I haven't done that this decade though, and I haven't seen that kind of
info.
CAs won't include anything they can't verify.

>   Do public CAs verify that email addresses in the certificate work?

yes, they do by sending a challenge to it.
>   Do public CAs verify that the OIDs in the certificate match the intended use-cases?

Most won't include OIDs.
>   Is there a global registry of SSIDs which the public CA could use to verify the SSID?

No, SSIDs are a local matter.
One could (and I do), use FQDNs as the SSID.

That's the only way I can see this working.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 14 Nov 2019 06:59:48 -0500

> include that into a certificate.

  That's less relevant than it may be.

  The common practice for years has been to recommend self-signed or "internal" CAs.  The original reason was that supplicants didn't do certificate pinning.  So if they were configured to trust a root CA, they would send user credentials to *any* EAP authentication server which had a certificate signed by that CA.  With certificate pinning, they now warn if the server certificate changes.

  The other reason is that supplicant configuration is still largely a manual process.  If admins need a complex process to configure the supplicant, then adding a self-signed CA to the mix has near-zero cost.  And supplicant vendors seem entirely disinterested in a standard way to configure them.

  The other benefit of self-signed CAs is that they're free.  No verification is required.  Since the admin controls both the CA and the end user machine, he's free to do whatever he wants, when he wants.

  As to why self-signed CAs are appealing, here's an example.   I've had "interesting" times trying to renew a simple certificate for HTTPS usage.  The CA was happy to take my money and "verify" ownership of a domain.  But they were entirely uninterested in sending me an actual certificate.  Their support system was similarly unhelpful.  In the end, I went with a simpler approach.  And I can't be the only person that this happened too.

  The gating issue for me is supplicants.  It's easy to update Open Source supplicants to check new OIDs.  The larger vendors might upgrade.  Eventually.  Maybe.

  On a technical front, a major issue is also *how* to upgrade.  What do supplicants do?  Allow both OIDs?  When do they start rejecting certificates with the "TLS web server" OIDs?

  Alan DeKok.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 14 Nov 2019 20:38:59 +0800

>   The other reason is that supplicant configuration is still largely a manual process.  If admins need a complex process to configure the supplicant, then adding a self-signed CA to the mix has nea…

I understand.
If the authentication server is manually configured, then it matters not
in the last what OIDs might be in the certificate.

We believe that TEAP-BRSKI (or BRSKI-WIFI) will result in supplicants
being configured during an automated process.
This would involve getting the organizational root CA, and it could pin
the authentication server certificate, or
it could pin just a DN, TBD.  The OIDs might be be useful that point,
but I would generally find them not interesting.

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Sat, 16 Nov 2019 12:59:37 +0000

-----Original Message-----
From: Emu <[email-masked]> On Behalf Of Michael Richardson
Sent: 12 November 2019 09:20
To: [email-masked]
Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

> This is also related to ongoing anima discussions about RFC 8366, and how it can bootstrap trust when the pinned domain cert is a public PKI CA, and not a private CA, and hence additional domain (o…

While I'm familiar with this conversation, which I'm right now inspired to call the the "Maria" problem ("How do solve a problem like Maria.  How do you a cloud certificate and pin it down?")

I don't really understand what it has to do with the problem of an EAP client, **which is not doing initial onboarding**, to validate a certificate that it has received as part of EAP-TLS*.

[ofriel] whether its first time bootstrap or subsequent EAP authentication, the EAP server is going to present the same identity cert to the client, and that could be signed by a public CA, and in both scenarios (bootstrap and reauthenticate) the client needs to know what identity to look for in the server cert.

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Sat, 16 Nov 2019 12:59:58 +0000

-----Original Message-----
From: Emu <[email-masked]> On Behalf Of Alan DeKok
Sent: 12 November 2019 16:32
To: Jan-Frederik Rieckers <[email-masked]>
Cc: [email-masked]
Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

<snip>

> There would be the possibility to define a specific prefix to bind it 
> to a Realm without having the certificate being valid for the HTTPS 
> host (e.g. eap-tls.uni-bremen.de for the realm

[ofriel] this seems like something reasonable, but that's more a general deployment recommendation: ensure that the identity/realm of EAP servers is different from the identity/domain of webservers within an org. Therefore in the absence of an NAIRealm or id-kp-eapOverLAN extension in a cert,  clients can still distinguish between the two. Users point their Browser clients point to 'example.org' and wi-fi supplications are configured to look for 'radius.exampe.org'.

The supplicant logic for verifying EAP server identity (assuming it already knows the root CA and a realm/domain string) could be check for NAIRealm first, then check for id-kp-eapOverLAN, then check for a dnsName.

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Sat, 16 Nov 2019 13:01:27 +0000

The CA/Browser forum has concrete guidelines on address, email, domain verification outlined here.

https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.6.pdf

All public CAs should follow these, or face blacklisting. CAs don’t want to risk being the next Symantec.

" 3.2.2.1. Identity
 If the Subject Identity Information is to include the name or address of an organization, the CA SHALL verify the identity and address of the organization and that the address is the Applicant’s address of existence or operation. The CA SHALL verify the identity and address of the Applicant using documentation provided by, or through communication with, at least one of the following:
1. A government agency in the jurisdiction of the Applicant’s legal creation, existence, or recognition;
2. A third party database that is periodically updated and considered a Reliable Data Source;
3. A site visit by the CA or a third party who is acting as an agent for the CA; or
4. An Attestation Letter.
The CA MAY use the same documentation or communication described in 1 through 4 above to verify both the Applicant’s identity and address.
Alternatively, the CA MAY verify the address of the Applicant (but not the identity of the Applicant) using a utility bill, bank statement, credit card statement, government-issued tax document, or other form of identification that the CA determines to be reliable. "

" 3.2.2.3. Verification of Country
If the subject:countryName field is present, then the CA SHALL verify the country associated with the Subject using one of the following: (a) the IP Address range assignment by country for either (i) the web site’s IP address, as indicated by the DNS record for the web site or (ii) the Applicant’s IP address; (b) the ccTLD of the requested Domain Name; (c) information provided by the Domain Name Registrar; or (d) a method identified in Section 3.2.2.1. The CA SHOULD implement a process to screen proxy servers in order to prevent reliance upon IP addresses assigned in countries other than where the Applicant is actually located. "

There is also a bunch of stuff in there about emails including:

" 3.2.2.4.4 Constructed Email to Domain Contact
Confirm the Applicant's control over the FQDN by (i) sending an email to one or more addresses created by using 'admin', 'administrator', 'webmaster', 'hostmaster', or 'postmaster' as the local part, followed by the at-sign ("@"), followed by an Authorization Domain Name, (ii) including a Random Value in the email, and (iii) receiving a confirming response utilizing the Random Value. "

-----Original Message-----
From: Emu <[email-masked]> On Behalf Of Michael Richardson
Sent: 13 November 2019 23:27
To: [email-masked]
Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

They are?  I've rarely seen it.
I think that if it's in the certificate, then they have verified them.
I can remember in the bad old days providing CAs with notorized articles of incorporation, etc.
I haven't done that this decade though, and I haven't seen that kind of info.
CAs won't include anything they can't verify.

Most won't include OIDs.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 16 Nov 2019 09:28:35 -0500

> The supplicant logic for verifying EAP server identity (assuming it already knows the root CA and a realm/domain string) could be check for NAIRealm first, then check for id-kp-eapOverLAN, then che…

  There is currently no document which offers guidance for implementors.  There's just common practice, and various standards.  Which are unfortunately different.  Even worse, it's not clear how these practices interact, or how we should migrate from existing practice to using the standards.

  I think it would be useful for this WG to have a document which gives these guidelines.

  Aln DeKok.

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Sat, 16 Nov 2019 14:47:57 +0000

-----Original Message-----
From: Alan DeKok <[email-masked]> 
Sent: 16 November 2019 14:29
To: Owen Friel (ofriel) <[email-masked]>
Cc: Jan-Frederik Rieckers <[email-masked]>; [email-masked]
Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

[ofriel] Happy to help put a strawman for that together, along with some recommendations for the other PSK ambiguity.

  Aln DeKok.

---

From: Dan Harkins <[email-masked]>
Date: Mon, 18 Nov 2019 15:22:21 -0800

Hi Alan,

>    Is there a global registry of SSIDs which the public CA could use to verify the SSID?

   I'm taking these as rhetorical questions with an implied "no". If that is
not the correct way of taking them then please let me know.

   So the issue is, if the CA does not check any of these things then 
you cannot
trust them in the certificate. The reason you trust the contents of a 
certificate
is because you trust the CA has done the appropriate due diligence to 
validate
the stuff it is certifying. If a CA doesn't do the due diligence on any 
of the
above stuff and still issues a certificate containing that stuff then I 
would
question the integrity of the CA and probably not trust other things it is
certifying. In other words, I'd probably remove that CA's cert from my TADB.

>    To put it another way, I'm not sure why this question is being posed.

   Here's one: Why would you trust an attribute that was not validated?

   Dan.

---

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

> not the correct way of taking them then please let me know.

  The implication is that many of them are "no".  Some are "yes".  Some *should* be "yes", and are in practice often "no".

>   So the issue is, if the CA does not check any of these things then you cannot
> trust them in the certificate.

  What happens if the CA checks some things, and not others?

> The reason you trust the contents of a certificate
> is because you trust the CA has done the appropriate due diligence to validate
> the stuff it is certifying. If a CA doesn't do the due diligence on any of the
> above stuff and still issues a certificate containing that stuff then I would

  That's up to you.  

>   Here's one: Why would you trust an attribute that was not validated?

  Define "validation" :)

  If the certificate contains an NAIRealm OID, then I know how the CA should validate it: check that the realm matches the domain.

  For SSIDs, since there's no registry, it's not possible to "validate" it against a registry.  So "validation" here means... what, exactly?

  My point for SSIDs is that validation means whatever we define it to mean.  So long as everyone agrees that the SSID field is a hint and is not validated by the CA, it's OK to use it.

  In addition, CAs currently validate *control* of a domain.  But they don't (and can't) really validate *ownership* as such.  i.e. if I own a company, I can tell an employee to ask a CA for certificates for that domain.  He may be making that request, even if he doesn't "own" the domain.  He can convince the CA that he controls the domain.  I'm not sure how the CA would check that the owner of the domain has properly delegated the certificate request to the employee.

  The same applies for telephone numbers.  Do CAs call the numbers?  Do they check that the person answering is the same person who made the request?  Maybe.

  These issues can't be answered with simple black & white statements.  If the data in a certificate is imperfect, it might still be useful.

  Alan DeKok.

---

From: Dan Harkins <[email-masked]>
Date: Mon, 18 Nov 2019 16:39:07 -0800

>    What happens if the CA checks some things, and not others?

   Then it means the CA is certifying things it shouldn't.

>> certifying. In other words, I'd probably remove that CA's cert from my TADB.

   Let me put it another way. There is no reason to trust a CA that does 
not perform
due diligence on the things it certifies. Convince me otherwise.

>>    Here's one: Why would you trust an attribute that was not validated?

   I'll pass on playing that game.

>    My point for SSIDs is that validation means whatever we define it to mean.  So long as everyone agrees that the SSID field is a hint and is not validated by the CA, it's OK to use it.

   Use it how? What value do you put in an attribute that hasn't been 
validated (and
don't ask me what that word means since you used it)?

>    In addition, CAs currently validate *control* of a domain.  But they don't (and can't) really validate *ownership* as such.  i.e. if I own a company, I can tell an employee to ask a CA for certi…

   Then what you can infer from a domain name in a certificate issued by 
such a CA
is that the holder of the corresponding private key controls that 
domain. Nothing
more, nothing less. But you can't infer anything from other attributes 
that have not
been validated (again, using a word you used yourself)

>    The same applies for telephone numbers.  Do CAs call the numbers?  Do they check that the person answering is the same person who made the request?  Maybe.

   You tell me if a CA "calls the numbers". If it doesn't then what can 
you infer
from a telephone number in a certificate it signs?

>    These issues can't be answered with simple black & white statements.  If the data in a certificate is imperfect, it might still be useful.

   OK, convince me of its utility.

   Dan.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Nov 2019 07:17:59 -0500

>   Then it means the CA is certifying things it shouldn't.

  Well, that's what happens with most CA's.

>   I'll pass on playing that game.

  We have a good "feel" for what validation means in casual conversation.  We're less clear what it means as a *process*.

  How does a CA validate a field?  The answer is too often "it validates the field", which seems a bit circular.

  My point is that validation isn't black and white.  There are various kinds of validation, each of which give you different kinds of information.  My goal is to understand what those are, and to find out how we can use that information.  Your position seems to be "it's either perfectly validated or perfectly useless".

>   Use it how? What value do you put in an attribute that hasn't been validated (and

  RFC 4334 describes this in some detail.  See section 3 for discussion on SSIDs.

>   Then what you can infer from a domain name in a certificate issued by such a CA
> is that the holder of the corresponding private key controls that domain. Nothing
> more, nothing less. But you can't infer anything from other attributes that have not

  Certificates contain serial numbers.  They haven't been validated by a CA.  The lack of validation therefore means that you can't infer anything from that field?

  I would argue that you *can* make inferences from that field.

>   You tell me if a CA "calls the numbers". If it doesn't then what can you infer

  This isn't difficult.  It means that the certificate owner has claimed he can be reached at that number.  And the CA has signed the statement, agreeing that it's a statement made by the certificate owner.

>   OK, convince me of its utility.

  See RFC 4334 and its discussion of SSIDs.

  Alan DeKok.

---

From: Dan Harkins <[email-masked]>
Date: Wed, 20 Nov 2019 02:23:42 -0800

> On Nov 18, 2019, at 7:39 PM, Dan Harkins <[email-masked]> wrote:
[snip]
>    I would argue that you *can* make inferences from that field.

   What do you mean that certificate serial numbers haven't been 
validated by the CA? They
originate from the CA. They are, by definition, a valid statement from 
the CA.

>    See RFC 4334 and its discussion of SSIDs.

   Is this _my_ certificate that has this attribute in it or is it in a 
certificate I receive?
If it's my certificate then what is the point of putting it in my 
certificate? I am asking for
ambiguous data to be certified and placed in my certificate for my own 
use? If this attribute
is in a certificate I receive then what does it mean to "select the 
correct certificate for
authentication in a particular WLAN"?Fit this check into the network 
connection process:

   1. service discovery
   2. 802.11 authentication
   3. 802.11 association
   4. EAP-ID req/resp
   5. EAP authentication

Which numbered step is this attribute used in and how?

   This attribute seems useless to me and its ambiguity and therefore 
unverifiability is a
large reason why.

   Dan.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 20 Nov 2019 07:11:15 -0500

On Nov 20, 2019, at 5:23 AM, Dan Harkins <[email-masked]> wrote:
>   Is this _my_ certificate that has this attribute in it or is it in a certificate I receive?

 The Introduction of RFC 4334 says:

   Automated selection of client certificates for use with PPP and IEEE
   802.1X is highly desirable.

  Which seems clear.

> If it's my certificate then what is the point of putting it in my certificate?

   See the text in the document, which explains this in detail.

> I am asking for
> ambiguous data to be certified and placed in my certificate for my own use? If this attribute
> is in a certificate I receive then what does it mean to "select the correct certificate for
> authentication in a particular WLAN"?

  The text explains this in detail.  I'll summarize.

  The use-case of the document is that an individual is issued a client certificate.  That certificate contains an OID about the expected use-case (EAPoL), and also a list of SSIDs used to perform EAP.  When a client system is confronted with a set of SSIDs, it can cross-correlate the SSIDs it sees with SSIDs in it's certificate store.  The client system can then select an appropriate authentication method (EAP versus WPA-PSK), and also a client certificate to use.  Since it's selected a client cert, it can also verify the certificate chain back to the root.

  I would *also* argue that this information can be placed in a server certificate, for situations when client certificates are not being used.  As discussed extensively previously on this list, a client can connect to an SSID, obtain the server cert, and then verify:

a) the server cert is intended for EAPoL (and is not just a cert taken from a web server)
b) the SSIDs in the cert match the SSID used to authenticate
c) the NAIRealm in the cert matches a user identifier stored in the client system

  In which case the client has *more* information than what is available to it today, and can thus make better decisions about whether or not to accept the cert.

>   This attribute seems useless to me and its ambiguity and therefore unverifiability is a
> large reason why.

  I would suggest not using it for your own purposes then.  I would also suggest allowing *others* to use it, if they find it useful.

  Alan DeKok.

---

From: Dan Harkins <[email-masked]>
Date: Wed, 20 Nov 2019 06:58:23 -0800

>    The use-case of the document is that an individual is issued a client certificate.  That certificate contains an OID about the expected use-case (EAPoL), and also a list of SSIDs used to perform…

   So you asked for imprecise, ambiguous, and unverified information to 
be put
in your own certificate for you to use later. Just because something is 
in an
RFC doesn't make it right. And appeal to RFC is another form of appeal to
authority fallacy.

   Oh, and what's the point of verifying the chain of your own 
certificate prior
to connecting to a network? Do you do OCSP responses to see if your 
certificate
has been revoked?

>    I would *also* argue that this information can be placed in a server certificate, for situations when client certificates are not being used.  As discussed extensively previously on this list, a…

   Yea, and that's why I gave you the list of actions a client takes and 
asked
you to point out where in the list this happens. You deleted the list.

>    In which case the client has *more* information than what is available to it today, and can thus make better decisions about whether or not to accept the cert.

   If the information is ambiguous and unverified why would you use it 
in a decision
to accept a certificate or not?

>    I would suggest not using it for your own purposes then.  I would also suggest allowing *others* to use it, if they find it useful.

   I'm not proposing to prevent you from doing anything. I'm asking 
what's the point
and why. You didn't really provide one. And good luck getting a public 
CA to put
ambiguous and unverifiable information in a certificate for you.

   Dan.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 20 Nov 2019 11:07:19 -0500

On Nov 20, 2019, at 9:58 AM, Dan Harkins <[email-masked]> wrote:
>   So you asked for imprecise, ambiguous, and unverified information to be put
> in your own certificate for you to use later. Just because something is in an

  You asked how it worked.  I pointed you to the RFC.  You now claim I *can't* refer to the RFC, because it's an appeal to authority.

  To recap: appeals to authority are logical fallacies where someone says "I'm right because of this authority".  I'm not saying that.  I'm saying that some people find it *useful*.  I'm pointing to the RFC as evidence that people find it useful.  I'm pointing to the RFC as an explanation of how it works.

  I think some of this back and forth could have been avoided with a careful reading of the RFC.

>   Oh, and what's the point of verifying the chain of your own certificate prior
> to connecting to a network? Do you do OCSP responses to see if your certificate
> has been revoked?

  I had hoped my explanation was unclear.  I guess not.

 The point was that when a client connects, it can check the *server* certificate chain back to the *same* CA which was used to issue the client cert.

  I've never seen a client check it's own certificate chain during authentication.  Such a use-case would be ludicrous, which makes me wonder why you think that's what I was proposing.

>   Yea, and that's why I gave you the list of actions a client takes and asked

  Yes.  Because I gave an explanation of how it works.  I want to be sure that the explanation is understood before going into further details.

  If my explanation makes no sense, then there's no point in me discussing technical details.

>   If the information is ambiguous and unverified why would you use it in a decision

  Well we're going in circles.  I've given explanations.  You reject them whole-sale, and keep asking me for more explanations.

>   I'm not proposing to prevent you from doing anything. I'm asking what's the point
> and why. You didn't really provide one. And good luck getting a public CA to put

  I've already addressed these points.  Please see my previous messages.

  I think this horse has been beaten to death.  I don't see any point in continuing it, unless there is progress.

  Alan DeKok.

---

From: Dan Harkins <[email-masked]>
Date: Thu, 21 Nov 2019 16:39:49 -0800

[snip]
>    I've never seen a client check it's own certificate chain during authentication.  Such a use-case would be ludicrous, which makes me wonder why you think that's what I was proposing.

   Above you refer to a client checking its own certificate in order to 
find an appropriate
one to use for an SSID. And now this is the use case you claim is 
ludicrous. EXACTLY!

   Asking a CA to certify something that is ambiguous and unverifiable 
in order to use it
yourself is ludicrous.

>    If my explanation makes no sense, then there's no point in me discussing technical details.

   It doesn't make sense because it's too late. You can't use 
unverifiable information in a
certificate you have not yet obtained in order to make a network 
connection decision. So
this unverifiable and ambiguous nonsense you want to put in a 
certificate is for a client
certificate and that use case is, as you note, ludicrous.

>    I think this horse has been beaten to death.  I don't see any point in continuing it, unless there is progress.

   I think we have made progress and closure. The use case for 
unverifiable and ambiguous
nonsense in a certificate is ludicrous.

   Dan.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 22 Nov 2019 08:23:38 -0500

On Nov 21, 2019, at 7:39 PM, Dan Harkins <[email-masked]> wrote:
>   I think we have made progress and closure.

  No.

  The word "unverifiable" is not a magic wan that you can use to win any argument.

  Your description of what I'm proposing does not match what I'm actually proposing.

  Alan DeKok.