Subject: [Emu] Issue 47 Certificate identity checks

From: Joseph Salowey <[email-masked]>
Date: Sun, 11 Apr 2021 20:19:23 -0700

Please review the following proposal and discuss it on this thread.

RFC 5216 lacks guidance on how to validate the EAP server's certificate
especially with respect to identities.

RFC 5216 recommends validating the certificate path is valid and that the
extended key usage attributes are either not present, allow for any usage
or allow for TLS server usage.   This creates an issue that if the same
truest root is used for EAP TLS and for other TLS server usage that any TLS
server will be able to extend its privilege and behave as an EAP server.
The following recommendations are made for implementations and
deployments to avoid this problem.

1. EAP TLS Peer implementations SHOULD allow for configuration of names to
match against SANs of type DNS name that are authorized to act as EAP-TLS
servers.

2. CAs MAY issue certs to EAP Servers that specify the id-kp-eapOverLAN EKU
specified in RFC 3770.  EAP TLS peer implementations SHOULD allow for the
configuration to require the id-kp-eapOverLAN EKU for validation of EAP
server certificates.

3. If the above options are not available then separate trust roots need to
be used to issue certificates for EAP-TLS server and for TLS servers.  EAP
TLS peer implementations MUST allow for configuration of a unique trust
root to validate the server's certificate.

EAP-TLS peer implementations SHOULD provide ways to automate the
configuration of the information necessary for the validation of the
certificate.

Cheers,

Joe

---

From: Eliot Lear <[email-masked]>
Date: Mon, 12 Apr 2021 09:54:17 +0200

Hi Joe,

I’m okay with most of this text except for as follows:

> 2. CAs MAY issue certs to EAP Servers that specify the id-kp-eapOverLAN EKU specified in RFC 3770.

The above sentence is unnecessary.  Of COURSE CAs can issue certs with that EKU or any other.  What I think you mean is this:

CAs issuing certificates intended for use by EAP servers SHOULD specify the id-kp-eapOverLAN EKU specified in RFC 3770.

[I am even tempted to say MUST, but I don’t think we ca go that far.]

[…]

>  3. If the above options are not available then separate trust roots need to be used to issue certificates for EAP-TLS server and for TLS servers.

I don’t think this is sufficient.  Rather, I would discuss the logic behind it.  In particular, I would state quite clearly something along the following lines:

“EAP peers need to have some basis to decide which networks are authorized.  A key signal for this purpose is the validation of the server certificate.  To prevent use of the wrong server, the peer SHOULD have some means to select and update appropriate trust anchors.  How this happens is beyond the scope of this memo."

> EAP TLS peer implementations MUST allow for configuration of a unique trust root to validate the server's certificate.

This statement seems independent of the previous one, and may be overly broad.  Let me give you an example: a device may be designed only to operate as part of a federation.

Eliot

---

From: Alan DeKok <[email-masked]>
Date: Mon, 12 Apr 2021 08:48:03 -0400

On Apr 11, 2021, at 11:19 PM, Joseph Salowey <[email-masked]> wrote:
> RFC 5216 lacks guidance on how to validate the EAP server's certificate especially with respect to identities.

  Yes.  :)

> RFC 5216 recommends validating the certificate path is valid and that the extended key usage attributes are either not present, allow for any usage or allow for TLS server usage.   This creates an issue that if the same truest root is used for EAP TLS and for other TLS server usage that any TLS server will be able to extend its privilege and behave as an EAP server.   The following recommendations are made for implementations and deployments to avoid this problem.

  One of my colleagues, Arran Cudbard-Bell wrote a cute tool a few years ago.  It would pretend to be a WiFI hotspot.  Then when systems tried to do EAP, it would strip the realm from the EAP identity.  It would then, use HTTPS to connect to a web server for that realm, and download that HTTPS server cert.  That cert would then be cloned under a new "self signed" CA, and the cloned cert presented to the user.

  The only real difference between the "real" and "fake" certs was the root CA / trust anchor.

  So yes, this is a real issue.  Even in a trusted environment, a web server admin can set up a WiFi hotspot using the HTTPS server cert.  This seems wrong.

> 1. EAP TLS Peer implementations SHOULD allow for configuration of names to match against SANs of type DNS name that are authorized to act as EAP-TLS servers. 

  Given the above attacks, I'm not sure that this helps.

> 2. CAs MAY issue certs to EAP Servers that specify the id-kp-eapOverLAN EKU specified in RFC 3770.  EAP TLS peer implementations SHOULD allow for the configuration to require the id-kp-eapOverLAN EKU for validation of EAP server certificates.  

  That's good, but as discussed previously on this list, it's essentially impossible to get those certs from public CAs.  Claims of "just start your own public CA" notwithstanding, the only practical way to do it is with a private CA.

> 3. If the above options are not available then separate trust roots need to be used to issue certificates for EAP-TLS server and for TLS servers.  EAP TLS peer implementations MUST allow for configuration of a unique trust root to validate the server's certificate.  
> 
> EAP-TLS peer implementations SHOULD provide ways to automate the configuration of the information necessary for the validation of the certificate.  

  After looking into this in some depth, the only real thing you can depend on is the CA.  If the CA is trusted, nothing else matters.  If the CA is not trusted, then nothing else matters.

  i.e. for any kind of increased security you'd like to add to EAP-TLS, you can almost always find a scenario where that security forbids real-world use-cases we'd like to support.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 12 Apr 2021 08:52:32 -0400

> “EAP peers need to have some basis to decide which networks are authorized.  A key signal for this purpose is the validation of the server certificate.  To prevent use of the wrong server, the peer…

  Yes.

  Many existing systems won't allow users to select trust anchors.  Many existing systems won't even "pin" trust anchors.  If the root CA used by an EAP-TLS server changes, they might notify the user.  Or they might just send over the new credentials.  It's all really bad.

> This statement seems independent of the previous one, and may be overly broad.  Let me give you an example: a device may be designed only to operate as part of a federation.

  I would agure there that the federation should have it's own CA. 

  I'm not sure what it means to have a federation where someone else controls who is a member of the federation.

  Alan DeKok.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 12 Apr 2021 15:02:46 +0200

Hi Alan,

> On 12 Apr 2021, at 14:52, Alan DeKok <[email-masked]> wrote:
> 
>>> 

That’s what I’m thinking.  But I could imagine hardcoded devices that make use of it.  That’s all.

Eliot

---

From: Alan DeKok <[email-masked]>
Date: Mon, 12 Apr 2021 09:09:31 -0400

> 2. CAs MAY issue certs to EAP Servers that specify the id-kp-eapOverLAN EKU specified in RFC 3770.  EAP TLS peer implementations SHOULD allow for the configuration to require the id-kp-eapOverLAN E…

  Just one final note on id-kp-eapOverLAN.

  RFC 3770 describes that as being used for client certs.  If we allow it for server certs, then how can we tell them apart?

  i.e. a client could take it's cert, set itself up as a WiFi hotspot, and no *other* client could tell the difference between the "fake" server cert, and a real one.

  As a result, it looks like id-kp-eapOverLAN is not appropriate for server certs.

  Alan DeKok.

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 12 Apr 2021 09:22:27 -0700

On Mon, Apr 12, 2021 at 5:48 AM Alan DeKok <[email-masked]>
wrote:

> > RFC 5216 recommends validating the certificate path is valid and that
> the extended key usage attributes are either not present, allow for any
> usage or allow for TLS server usage.   This creates an issue that if the
> same truest root is used for EAP TLS and for other TLS server usage that
> any TLS server will be able to extend its privilege and behave as an EAP
> server.   The following recommendations are made for implementations and
>   One of my colleagues, Arran Cudbard-Bell wrote a cute tool a few years
> ago.  It would pretend to be a WiFI hotspot.  Then when systems tried to do
> EAP, it would strip the realm from the EAP identity.  It would then, use
> HTTPS to connect to a web server for that realm, and download that HTTPS
> server cert.  That cert would then be cloned under a new "self signed" CA,
> and the cloned cert presented to the user.
>
>   So yes, this is a real issue.  Even in a trusted environment, a web
> server admin can set up a WiFi hotspot using the HTTPS server cert.  This
> seems wrong.
>
> > 1. EAP TLS Peer implementations SHOULD allow for configuration of names
> to match against SANs of type DNS name that are authorized to act as
> EAP-TLS servers.
>
[Joe] You would need to use the name matching in conjunction with
validation to a trusted root.

> > 2. CAs MAY issue certs to EAP Servers that specify the id-kp-eapOverLAN
> EKU specified in RFC 3770.  EAP TLS peer implementations SHOULD allow for
> the configuration to require the id-kp-eapOverLAN EKU for validation of EAP
> server certificates.
>
>   That's good, but as discussed previously on this list, it's essentially
> impossible to get those certs from public CAs.  Claims of "just start your
> own public CA" notwithstanding, the only practical way to do it is with a
> private CA.
>
>
[Joe]  without some sort of name matching using certs from a public CA is
unwise.

> > 3. If the above options are not available then separate trust roots need
> to be used to issue certificates for EAP-TLS server and for TLS servers.
> EAP TLS peer implementations MUST allow for configuration of a unique trust
>   After looking into this in some depth, the only real thing you can
> depend on is the CA.  If the CA is trusted, nothing else matters.  If the
> CA is not trusted, then nothing else matters.
>
> [Joe] In this case we would have to rule out CAs that are not under the
organizations control (public CAs)

>   i.e. for any kind of increased security you'd like to add to EAP-TLS,
> you can almost always find a scenario where that security forbids
> real-world use-cases we'd like to support

  Alan DeKok.

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 12 Apr 2021 09:25:27 -0700

On Mon, Apr 12, 2021 at 6:02 AM Eliot Lear <[email-masked]> wrote:

> EAP TLS peer implementations MUST allow for configuration of a unique
> trust root to validate the server's certificate.
>
>
> This statement seems independent of the previous one, and may be overly
> broad.  Let me give you an example: a device may be designed only to
> operate as part of a federation.
>
>
[Joe] Relying on a burned in certificate this way seems like a really bad
idea.  What happens when that certificate expires?

---

From: Alan DeKok <[email-masked]>
Date: Mon, 12 Apr 2021 13:54:15 -0400

On Apr 12, 2021, at 12:22 PM, Joseph Salowey <[email-masked]> wrote:
> [Joe]  without some sort of name matching using certs from a public CA is unwise.  

  The only other alternative is to "pin" the server cert.  Many systems support this.  Perhaps mentioning Time of First Use (TOFU) would help here.

  i.e. if the peer pins both the CA and the server cert, then the contents of the server cert matter less.  All that matters is that the peer detects if/when the server cert changes.

  If we rely on names, then which one?  There are many fields in a certificate which could be used.

> [Joe] In this case we would have to rule out CAs that are not under the organizations control (public CAs)

  Only if the peer doesn't notice if the server cert changes.

  I think it's safe to recommend that clients pin both the server cert and the CA cert.  Anything else is "there be dragons".

  Alan DeKok.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 12 Apr 2021 20:07:37 +0200

> On 12 Apr 2021, at 19:54, Alan DeKok <[email-masked]> wrote:
> 
>  The only other alternative is to "pin" the server cert.  Many systems support this.  Perhaps mentioning [Trust On] First Use (TOFU) would help here.
> 

That won’t work for headless wireless.

Yes, we have kicked that hornet’s nest.  I hope everyone is wearing appropriate netting.

Eliot

---

From: Tim Cappalli <[email-masked]>
Date: Mon, 12 Apr 2021 18:15:50 +0000

Pinning the server certificate is unrealistic. A properly configured supplicant with a trusted private root and subject match is adequate and allows good security hygiene with server cert rotation.

I believe the id-kp-eapOverLAN EKU should be a MUST. Public CAs should not be issuing server certificates for EAP in the first place. I feel like this debate comes up every few years. Any public CA-signed TLS web server certificate that is used for EAP can be requested to be revoked for misuse.

If an organization cannot ensure proper configuration of a supplicant, they should not be using EAP.

tim
________________________________
From: Emu <[email-masked]> on behalf of Eliot Lear <lear=[email-masked]>
Sent: Monday, April 12, 2021 14:07
To: Alan DeKok <[email-masked]>
Cc: EMU WG <[email-masked]>
Subject: Re: [Emu] Issue 47 Certificate identity checks

Eliot

---

From: Alan DeKok <[email-masked]>
Date: Mon, 12 Apr 2021 14:50:59 -0400

> Pinning the server certificate is unrealistic. A properly configured supplicant with a trusted private root and subject match is adequate and allows good security hygiene with server cert rotation.

  While I agree, many customers don't.  The only way to convince them otherwise is to present a "fait accompli" that all of the vendors now forbid this behaviour.

> I believe the id-kp-eapOverLAN EKU should be a MUST.

  I think we can't use it.  It's defined for client certs.  We don't want client certs to pretend to be server certs.  Using id-kp-eapOverLAN for both will allow this.

> Public CAs should not be issuing server certificates for EAP in the first place. I feel like this debate comes up every few years. Any public CA-signed TLS web server certificate that is used for EAP can be requested to be revoked for misuse.

  Replace EAP with EAP, SMTPS, XMPP, etc.

  i.e. any protocol using TLS.

  There was a long thread about this on EMU a year ago.  Maybe it is the case that certificate authorities MUST revoke such mis-used certs.  If so, I could write a script which would scan the net, find such certs, and report them.  I suspect that it could take down 10% to 25% of TLS-enabled services.

  Is this a good idea?  Probably not.

  Is it possible?  According to multiple people, yes.

  What should we do about it?  I don't know.

  But my $0.02 is that if it is true, then we should admit that the real-world use-cases for certs don't match how certificate authorities work.  We should then likely change the definition of "id-kp-serverAuth" to mean "any TLS-enabled service", instead of "TLS WWW servers".

> If an organization cannot ensure proper configuration of a supplicant, they should not be using EAP.

  Or, they should rely on experts to ensure that systems can't be configured incorrectly.  This is where the IETF has spent two decades not addressing these use-cases.

  Given the time frame for the EAP-TLS document, I suspect it's best to just say "here be dragons", and leave it at that.  Any attempt to define new behavior may be time consuming.

  Alan DeKok.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 12 Apr 2021 21:30:05 +0200

> On 12 Apr 2021, at 18:25, Joseph Salowey <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> 
> [Joe] Relying on a burned in certificate this way seems like a really bad idea.  What happens when that certificate expires?
> 

Separate the cert from the cert selection.  Don’t burn the cert in, but imagine a device that communicates out of the box with a federation service.  This is already done at higher layers.

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Tue, 13 Apr 2021 20:17:18 -0400

Alan DeKok <[email-masked]> wrote:
    > ago.  It would pretend to be a WiFI hotspot.  Then when systems tried
    > to do EAP, it would strip the realm from the EAP identity.  It would
    > then, use HTTPS to connect to a web server for that realm, and download
    > that HTTPS server cert.  That cert would then be cloned under a new
    > "self signed" CA, and the cloned cert presented to the user.

Why did you need the HTTPS server cert?
Did you need the OIDs, and stuff out of it?  Why wasn't the realm name enough
to make the imposter cert from the non-authorized CA?

I'm just trying to understand how the HTTPS cert is involved here.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Alan DeKok <[email-masked]>
Date: Wed, 14 Apr 2021 07:23:29 -0400

> I'm just trying to understand how the HTTPS cert is involved here.

  The HTTPS cert contains a wealth of information which makes it look "real" to the average person.  All of that information can be cloned into the imposter cert.  So the only differences between the imposter cert and real one are (a) signing CA, and (b) key data that most people don't understand.

  What any mere mortal looking at the imposter cert will see "Yup, it has the right addresses, phone numbers, names, etc.".  For all intents and purposes, it appears to be real.

  This imposter process worked better years ago when supplicants would show the entire cert to the user.  Now, many don't even do that.  Some just show a fingerprint in a pop-up dialog, and ask the user "is this OK?".

  How that's useful to anyone is beyond me.

  Alan DeKok.

---

From: Tim Cappalli <[email-masked]>
Date: Wed, 14 Apr 2021 14:56:47 +0000

Honestly, no information in an EAP server certificate is good enough for a user to make a "walk up" informed decision. If the supplicant is not properly pre-configured, all bets are off. TOFU is not acceptable.

At least requiring an EAP-specific EKU or OID would require operating systems to separate out the EAP trust store.

TLS Web Server Certificate should not be acceptable for EAP.

tim
________________________________
From: Emu <[email-masked]> on behalf of Alan DeKok <[email-masked]>
Sent: Wednesday, April 14, 2021 07:23
To: Michael Richardson <[email-masked]>
Cc: EMU WG <[email-masked]>
Subject: Re: [Emu] Issue 47 Certificate identity checks

  Alan DeKok.

_______________________________________________
Emu mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu&amp;data=04%7C01%7Ctim.cappalli%40microsoft.com%7C03fdb74ac18749ebdc6608d8ff37c2da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637539962261663872%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=boROVAFgSky1v93Iu1jzrthBVbvAhNgKa5TVZ9h0zQA%3D&amp;reserved=0

---

From: Alan DeKok <[email-masked]>
Date: Wed, 14 Apr 2021 13:21:09 -0400

On Apr 14, 2021, at 10:56 AM, Tim Cappalli <[email-masked]> wrote:
> 
> Honestly, no information in an EAP server certificate is good enough for a user to make a "walk up" informed decision.

  I'm curious how this is different from say, HTTPS.  The use-cases seem pretty similar.

> At least requiring an EAP-specific EKU or OID would require operating systems to separate out the EAP trust store.

  I agree 100% there.

> TLS Web Server Certificate should not be acceptable for EAP.

  Well, yes.  The question is how do we get there from here.

  Alan DeKok.

---

From: Tim Cappalli <[email-masked]>
Date: Wed, 14 Apr 2021 17:29:01 +0000

The equivalent to HTTPS with EAP would be if the ESSID was a subject name in the certificate and ESSIDs could be registered and validated. That doesn't exist today and wouldn't ever really work (or scale). The closest thing to it is server certificates for Passpoint OSU, which have their own issues and aren't feasible for most deployments.

Given the significant changes required in both EAP clients and EAP servers for TLS 1.3, I think the time is appropriate for making the server certificate requirements more strict. This is likely the last chance for a long time.

tim
________________________________
From: Alan DeKok <[email-masked]>
Sent: Wednesday, April 14, 2021 13:21
To: Tim Cappalli <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Emu] Issue 47 Certificate identity checks

  I agree 100% there.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 14 Apr 2021 15:28:22 -0400

> The equivalent to HTTPS with EAP would be if the ESSID was a subject name in the certificate and ESSIDs could be registered and validated. That doesn't exist today and wouldn't ever really work (or…

  Configuring known ESSIDs is good, but I'm not sure how they're relevant for security.

  At a high level, if the certificates are OK, then TLS protects you from whatever is going on in the underlying transport layer.

  Having "known SSIDs" only matters for subsequent traffic flow, I think.  At that point, channel bindings (RFC 6677) become more useful.

> Given the significant changes required in both EAP clients and EAP servers for TLS 1.3, I think the time is appropriate for making the server certificate requirements more strict. This is likely th…

  I strongly suspect that there's no consensus here, and this really isn't the document to do it in.  The issues are much larger than for just EAP-TLS.

  Alan DeKok.