Re: [WIRELESS-LAN] [EXTERNAL] Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?

[James Andrewartha]

On 20/8/20 1:01 am, Smith, Todd wrote:
> If I come onto your institution then I would have to accept your
> certificate chain to be granted access.  Why should I trust your chain
> over a major CA provider?  Obviously, you have the control and authority
> to insist on whatever access conditions that you find acceptable, but in
> my case I don’t and I use third-party certs since they are acceptable by
> practically every device.

The risk is not about the initial trust, the risk is that with a public
CA, an attacker can obtain a certificate signed by the same CA, and
spoof your SSID and obtain PEAP credentials with their validly-signed
RADIUS server. Since most clients won't be configured with the specific
RADIUS server names and will trust any server signed by the same CA,
they will connect to this spoofed SSID without prompting the user. And
then, given the way PEAP works, they'll have a password-equivalent
secret for the user.

If you have a private CA for your RADIUS servers, nobody else can obtain
a certificate signed by it (well unless they hack your servers).

This is a marginal but not insignificant risk to poorly configured
clients. I definitely agree that vendors (both client and wifi
infrastructure) should make EAP-TLS easier to deploy.

-- 
James Andrewartha
Network & Projects Engineer
Christ Church Grammar School
Claremont, Western Australia
Ph. (08) 9442 1757
Mob. 0424 160 877

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

RE: [WIRELESS-LAN] [EXTERNAL] Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?

[Tim Cappalli]

Well, the prompt is nearly identical identical for private vs public CAs on 
Apple and Windows devices, and at least in my experience, users don’t read it, 
they just either complain to the help desk (or on Twitter) or click it.

The core reason to use an internal PKI is so you can renew the server 
certificates without worrying about breaking changes for that impact users and 
require help desk calls and/or intervention.

If we want to get super technical, using a web server certificate from a public 
CA for EAP is technically not allowed.

The other thing to keep in mind is that you can use multiple EAP methods on the 
same SSID. You can use PEAP for your legacy organizationally owned devices, and 
even devices that are managed (ex: Windows devices with a machine credential) 
and use EAP-TLS or another option for unmanaged.

tim

From: Smith, Todd<mailto:todd.sm...@camc.org>
Sent: Wednesday, August 19, 2020 13:23
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] [EXTERNAL] Re: [WIRELESS-LAN] New certificate 
expiration for certificates affecting 802.1X?

Tim,

Thank you for your response.  The issue that I see is that where it is a 
supplicant or a manual install; I am still required to trust your chain instead 
of a major CA.  I use third-party certificates since I know that are supported 
and it is easier to trust an organization that has to be validated every couple 
of years then a random organization that may or may not protect its internal CA 
properly.  I do run internal CA and they are harder to protect then most people 
believe.

Much of the medical equipment that I work with can’t support EAP-TLS and 
getting 802.1x PEAP is sometimes a major challenge.  In 2020, the number of 
wireless devices that I see that are at least 3 generations old is still 
unacceptably high.

Todd Smith

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
Sent: Wednesday, August 19, 2020 1:12 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] [EXTERNAL] Re: [WIRELESS-LAN] New certificate 
expiration for certificates affecting 802.1X?

The core difference is a user or device password cannot be compromised when 
modern authentication is used. Password-based authentication has been in the 
process of being deprecated for years. Unfortunately networks are one of the 
last parties stuck on passwords.



  *   If I come onto your institution then I would have to accept your 
certificate chain to be granted access.  Why should I trust your chain over a 
major CA provider?

This should NEVER be happening. That’s the other major point. A properly 
configured supplicant will never prompt the user to accept a trust anchor, 
regardless of whether it’s a public CA or not.

Tim

From: Smith, Todd<mailto:todd.sm...@camc.org>
Sent: Wednesday, August 19, 2020 13:01
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] [EXTERNAL] Re: [WIRELESS-LAN] New certificate 
expiration for certificates affecting 802.1X?

This is all well and good and I accept that different institutions have 
different requirements.  How is EAP-TLS which requires a client certificate any 
better than EAP-PEAP which while using username/password is in a Microsoft 
setting not worse than setting at your wired machine to login?  Unless your 
organization requires client side certs on your wired machines; then I don’t 
see the difference?  Your point is well founded in that not required server 
certificate validation does open up to MITM attacks for PEAP but to summarily 
declare EAP-TLS superior because it uses client certificates seems to miss the 
point.

If I come onto your institution then I would have to accept your certificate 
chain to be granted access.  Why should I trust your chain over a major CA 
provider?  Obviously, you have the control and authority to insist on whatever 
access conditions that you find acceptable, but in my case I don’t and I use 
third-party certs since they are acceptable by practically every device.

To change the question slightly, What are organizations using for large private 
PKI?  Microsoft CA?  OpenSSL?  What are organizations  doing to onboard 
non-owned devices to accept this foreign cert chain?

Thank you in advance for a responses to a difficult and troubling subject
Todd Smith


**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at 
https://www.educause.edu/community<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunity=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C3c25ae2d96c342746f4808d84464a091%7C72f988bf8

RE: [WIRELESS-LAN] [EXTERNAL] Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?

[Smith, Todd]

Tim,

Thank you for your response.  The issue that I see is that where it is a 
supplicant or a manual install; I am still required to trust your chain instead 
of a major CA.  I use third-party certificates since I know that are supported 
and it is easier to trust an organization that has to be validated every couple 
of years then a random organization that may or may not protect its internal CA 
properly.  I do run internal CA and they are harder to protect then most people 
believe.

Much of the medical equipment that I work with can't support EAP-TLS and 
getting 802.1x PEAP is sometimes a major challenge.  In 2020, the number of 
wireless devices that I see that are at least 3 generations old is still 
unacceptably high.

Todd Smith

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
Sent: Wednesday, August 19, 2020 1:12 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] [EXTERNAL] Re: [WIRELESS-LAN] New certificate 
expiration for certificates affecting 802.1X?

The core difference is a user or device password cannot be compromised when 
modern authentication is used. Password-based authentication has been in the 
process of being deprecated for years. Unfortunately networks are one of the 
last parties stuck on passwords.


?  If I come onto your institution then I would have to accept your certificate 
chain to be granted access.  Why should I trust your chain over a major CA 
provider?

This should NEVER be happening. That's the other major point. A properly 
configured supplicant will never prompt the user to accept a trust anchor, 
regardless of whether it's a public CA or not.

Tim

From: Smith, Todd<mailto:todd.sm...@camc.org>
Sent: Wednesday, August 19, 2020 13:01
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] [EXTERNAL] Re: [WIRELESS-LAN] New certificate 
expiration for certificates affecting 802.1X?

This is all well and good and I accept that different institutions have 
different requirements.  How is EAP-TLS which requires a client certificate any 
better than EAP-PEAP which while using username/password is in a Microsoft 
setting not worse than setting at your wired machine to login?  Unless your 
organization requires client side certs on your wired machines; then I don't 
see the difference?  Your point is well founded in that not required server 
certificate validation does open up to MITM attacks for PEAP but to summarily 
declare EAP-TLS superior because it uses client certificates seems to miss the 
point.

If I come onto your institution then I would have to accept your certificate 
chain to be granted access.  Why should I trust your chain over a major CA 
provider?  Obviously, you have the control and authority to insist on whatever 
access conditions that you find acceptable, but in my case I don't and I use 
third-party certs since they are acceptable by practically every device.

To change the question slightly, What are organizations using for large private 
PKI?  Microsoft CA?  OpenSSL?  What are organizations  doing to onboard 
non-owned devices to accept this foreign cert chain?

Thank you in advance for a responses to a difficult and troubling subject
Todd Smith


**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

RE: [WIRELESS-LAN] [EXTERNAL] Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?

[Tim Cappalli]

The core difference is a user or device password cannot be compromised when 
modern authentication is used. Password-based authentication has been in the 
process of being deprecated for years. Unfortunately networks are one of the 
last parties stuck on passwords.



  *   If I come onto your institution then I would have to accept your 
certificate chain to be granted access.  Why should I trust your chain over a 
major CA provider?

This should NEVER be happening. That’s the other major point. A properly 
configured supplicant will never prompt the user to accept a trust anchor, 
regardless of whether it’s a public CA or not.

Tim

From: Smith, Todd<mailto:todd.sm...@camc.org>
Sent: Wednesday, August 19, 2020 13:01
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] [EXTERNAL] Re: [WIRELESS-LAN] New certificate 
expiration for certificates affecting 802.1X?

This is all well and good and I accept that different institutions have 
different requirements.  How is EAP-TLS which requires a client certificate any 
better than EAP-PEAP which while using username/password is in a Microsoft 
setting not worse than setting at your wired machine to login?  Unless your 
organization requires client side certs on your wired machines; then I don’t 
see the difference?  Your point is well founded in that not required server 
certificate validation does open up to MITM attacks for PEAP but to summarily 
declare EAP-TLS superior because it uses client certificates seems to miss the 
point.

If I come onto your institution then I would have to accept your certificate 
chain to be granted access.  Why should I trust your chain over a major CA 
provider?  Obviously, you have the control and authority to insist on whatever 
access conditions that you find acceptable, but in my case I don’t and I use 
third-party certs since they are acceptable by practically every device.

To change the question slightly, What are organizations using for large private 
PKI?  Microsoft CA?  OpenSSL?  What are organizations  doing to onboard 
non-owned devices to accept this foreign cert chain?

Thank you in advance for a responses to a difficult and troubling subject
Todd Smith

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>]
 On Behalf Of Tim Cappalli
Sent: Wednesday, August 19, 2020 11:27 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates 
affecting 802.1X?

Correct, some versions of operating systems do not support a self-signed EAP 
server certificates.

It is also just a bad idea as you can’t renew it without re-onboarding devices. 
If you use at least 1 issuer, you can cycle the certificate without updating 
clients.

PEAP (and EAP-TTLS) should never be used on unmanaged devices unless a security 
assessment has been done and its been determined that credential exposure is an 
acceptable risk to the organization.

I feel like this conversation surfaces multiple times per year. So here’s the 
summary:

If able, EAP-TLS should be used for all user-centric device network access. 
This then implies an organizationally controlled PKI is used to issue the EAP 
server certificate.
If EAP-TLS is not feasible and a legacy, known vulnerable EAP method like PEAP 
is going to be used, it is highly recommended that a supplicant provisioning 
wizard be used. This would also use an organizationally controlled PKI for the 
EAP server certificate. Your information security team should determine whether 
credential exposure is an acceptable risk for the organization.
If EAP-TTLS/PAP or EAP-TTLS/MSCHAPv2 are used, a supplicant provisioning wizard 
is required for Apple operating systems. This would also use an 
organizationally controlled PKI for the EAP server certificate. Your 
information security team should determine whether credential exposure is an 
acceptable risk for the organization.
If you decide to use an EAP server certificate from a public CA, expect 
problems every year.

General summary
 Always use a PKI in your control for the EAP server identity so you’re 
able to renew the server certificate without any risk of a chain change or 
enforcement of restrictions intended for browsers

If you must use legacy password-based authentication, use a supplicant 
provisioning wizard (butrealize this does not remove all risk as you 
can’t force users to use it)

 If users configure their own supplicant for password-based 
authentication or blindly accept a certificate prompt, you should assume that 
their credentials have been comprised


Also one quick update regarding Android: Android 11 will not restrict EAP 
server certificates to Chrome’s 1 year lifetime.

tim

From: Dennis Xu<mailto:d...@uoguelph.ca>
Sent: Wednesday, Augus

RE: [EXTERNAL] Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?

[Smith, Todd]

This is all well and good and I accept that different institutions have 
different requirements.  How is EAP-TLS which requires a client certificate any 
better than EAP-PEAP which while using username/password is in a Microsoft 
setting not worse than setting at your wired machine to login?  Unless your 
organization requires client side certs on your wired machines; then I don’t 
see the difference?  Your point is well founded in that not required server 
certificate validation does open up to MITM attacks for PEAP but to summarily 
declare EAP-TLS superior because it uses client certificates seems to miss the 
point.

If I come onto your institution then I would have to accept your certificate 
chain to be granted access.  Why should I trust your chain over a major CA 
provider?  Obviously, you have the control and authority to insist on whatever 
access conditions that you find acceptable, but in my case I don’t and I use 
third-party certs since they are acceptable by practically every device.

To change the question slightly, What are organizations using for large private 
PKI?  Microsoft CA?  OpenSSL?  What are organizations  doing to onboard 
non-owned devices to accept this foreign cert chain?

Thank you in advance for a responses to a difficult and troubling subject
Todd Smith

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU]
 On Behalf Of Tim Cappalli
Sent: Wednesday, August 19, 2020 11:27 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates 
affecting 802.1X?

Correct, some versions of operating systems do not support a self-signed EAP 
server certificates.

It is also just a bad idea as you can’t renew it without re-onboarding devices. 
If you use at least 1 issuer, you can cycle the certificate without updating 
clients.

PEAP (and EAP-TTLS) should never be used on unmanaged devices unless a security 
assessment has been done and its been determined that credential exposure is an 
acceptable risk to the organization.

I feel like this conversation surfaces multiple times per year. So here’s the 
summary:

If able, EAP-TLS should be used for all user-centric device network access. 
This then implies an organizationally controlled PKI is used to issue the EAP 
server certificate.
If EAP-TLS is not feasible and a legacy, known vulnerable EAP method like PEAP 
is going to be used, it is highly recommended that a supplicant provisioning 
wizard be used. This would also use an organizationally controlled PKI for the 
EAP server certificate. Your information security team should determine whether 
credential exposure is an acceptable risk for the organization.
If EAP-TTLS/PAP or EAP-TTLS/MSCHAPv2 are used, a supplicant provisioning wizard 
is required for Apple operating systems. This would also use an 
organizationally controlled PKI for the EAP server certificate. Your 
information security team should determine whether credential exposure is an 
acceptable risk for the organization.
If you decide to use an EAP server certificate from a public CA, expect 
problems every year.

General summary
 Always use a PKI in your control for the EAP server identity so you’re 
able to renew the server certificate without any risk of a chain change or 
enforcement of restrictions intended for browsers

If you must use legacy password-based authentication, use a supplicant 
provisioning wizard (butrealize this does not remove all risk as you 
can’t force users to use it)

 If users configure their own supplicant for password-based 
authentication or blindly accept a certificate prompt, you should assume that 
their credentials have been comprised


Also one quick update regarding Android: Android 11 will not restrict EAP 
server certificates to Chrome’s 1 year lifetime.

tim

From: Dennis Xu
Sent: Wednesday, August 19, 2020 12:12
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates 
affecting 802.1X?

Hi Tim,

Can you please further elaborate the issues with self-signed certs vs private 
CA signed certs besides the manageability stuffs?

I understand some OSes cannot connect if using self-signed cert for PEAP 
authentication, unless using on-boarding solutions to configure them to trust 
the cert. I am not sure if the private CA signed cert makes any difference on 
this.

Below is from the FreeRADIUS EAP configuration file:
#  Trusted Root CA list
#
#  ALL of the CA's in this list will be trusted
#  to issue client certificates for authentication.
#
#  In general, you should use self-signed
#  certificates for 802.1x (EAP) authentication.
   

Re: [External] Re: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?

[Hunter Fuller]

Every day I am more and more thankful that we migrated off of InCommon for
dot1X. We slid right under the door for all this Apple stuff. Life has
never been better on our private CA.

On Wed, Aug 19, 2020 at 08:42 Andrew Gallo <
01d1fb3cd70a-dmarc-requ...@listserv.educause.edu> wrote:

> Thanks Tim-
>
> Good point on the non-public CA.
>
> For the record, here's Apple's announcement:
> https://support.apple.com/en-us/HT211025
>
> I'm also going to ask over on the InCommon cert-users list.
>
> Thanks
>
>
>
>
> On 8/19/2020 9:33 AM, Tim Cappalli wrote:
> > Google’s announcement was for Chrome so it is not clear whether there
> will be a change in Android.
> >
> > Apple’s announcement is system-wide on macOS and iOS.
> >
> > But keep in mind it does not apply to non-public CAs, which are the only
> trust chains that should be used for EAP.
> >
> > tim
> >
> > 
> > From: The EDUCAUSE Wireless Issues Community Group Listserv on behalf of
> Andrew Gallo
> > Sent: Wednesday, August 19, 2020 09:28
> > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> > Subject: [WIRELESS-LAN] New certificate expiration for certificates
> affecting 802.1X?
> >
> > Does anyone know if the new, shorter certificate expiration for TLS that
> > Apple announced (and Google is following) will affect 802.1X
> authentication?
> >
> > Thanks
> > --
> > 
> > Andrew Gallo
> > The George Washington University
> >
> >
> > **
> > Replies to EDUCAUSE Community Group emails are sent to the entire
> community list. If you want to reply only to the person who sent the
> message, copy and paste their email address and forward the email reply.
> Additional participation and subscription information can be found at
> https://www.educause.edu/community
> >
> > **
> > Replies to EDUCAUSE Community Group emails are sent to the entire
> community list. If you want to reply only to the person who sent the
> message, copy and paste their email address and forward the email reply.
> Additional participation and subscription information can be found at
> https://www.educause.edu/community
> >
>
> --
> 
> Andrew Gallo
> The George Washington University
>
> **
> Replies to EDUCAUSE Community Group emails are sent to the entire
> community list. If you want to reply only to the person who sent the
> message, copy and paste their email address and forward the email reply.
> Additional participation and subscription information can be found at
> https://www.educause.edu/community
>
-- 

--
Hunter Fuller (they)
Router Jockey
VBH Annex B-5
+1 256 824 5331

Office of Information Technology
The University of Alabama in Huntsville
Network Engineering

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community