Re: [WIRELESS-LAN] Cisco EAP-TLS fragmentation with active/active firewalls

[Tim Cappalli]

TCP vs UDP

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Turpin, Max 

Date: Monday, September 13, 2021 at 18:28
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] Cisco EAP-TLS fragmentation with active/active 
firewalls
Why will RadSec fix the issue?

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Tim Cappalli 

Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Monday, September 13, 2021 at 12:27 PM
To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" 
Subject: Re: [WIRELESS-LAN] Cisco EAP-TLS fragmentation with active/active 
firewalls

Switch to RadSec between your controllers and RADIUS server. Should eliminate 
the issue if you don't have any other config options.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Lee Weers 
Date: Monday, September 13, 2021 at 18:25
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] Cisco EAP-TLS fragmentation with active/active 
firewalls
Look at the load balancing on the firewalls. Depending on how it is setup, 
there is a way that all the traffic is sent to one firewall vs the other per 
session.  I know this can be done at the interface level. I don’t remember what 
they called it off the top of my head.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Turpin, Max
Sent: Monday, September 13, 2021 11:09 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] Cisco EAP-TLS fragmentation with active/active firewalls

Hey everyone,

Hoping everyone is having a peaceful start of the semester. Reaching out 
because we’re dealing with a doozy of a problem and hoping someone else may 
have dealt with this and can help.

We are running several pairs of Cisco 5520 controllers running 8.5.171 code. We 
have recently done a complete rebuild of our Clearpass environment split across 
two data centers and those are running 6.9.6. What we have found is that when 
sending traffic to this new cluster, some packets are greater than 1500 bytes 
and are getting fragmented in the environment. That would be all well and fine 
except our perimeter firewalls are active/active so in some cases, fragment 1 
goes to FW-A and fragment 2 goes to FW-B. Palo alto will drop fragments if does 
not have all parts. So these fragments are getting dropped and thus the EAP 
exchange is timing out.


  1.  As far as I’ve gotten from Cisco, 5520 controllers do not support jumbo 
frames
  2.  There is no support from Cisco on specifying an EAP-TLS fragment size 
(unlike Aruba)
  3.  I cannot move all the controllers inside the data centers as there are 
some remote controllers as part of this environment.

The only solution I can think of right now is to point the traffic to one 
firewall with policy routes with SLA tracking but that’s an administratively 
burdensome solution and frankly, kind of kludgy.

Have any of you dealt with this sort of issue? Any thoughts on this would be 
appreciated.

Thanks,
Max

**
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%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.educause.edu-252Fcommunity-26data-3D04-257C01-257Ctim.cappalli-2540MICROSOFT.COM-257C95baac46bfbe4fbd445d08d976d314e2-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637671471268908152-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C3000-26sdata-3DUbn20rOFYRyYWaWLz8hlhWzAbeWGRj9rX9ZExWR2Mf4-253D-26reserved-3D0%26d%3DDwMF-g%26c%3DG2MiLlal7SXE3PeSnG8W6_JBU6FcdVjSsBSbw6gcR0U%26r%3DzobI7d8a-PnWsDxhdheA-Pkovo0vk-DVRBlpbuIQ8mE%26m%3Dz8STE2vHGTWY4lHzB1ludq3RWLUA9RQhWhFAff82Da8%26s%3DbYknutz_e69ijK-QpUcThQtaKDKHbWizz6N0kk5pPbk%26e%3D=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C29ed4aabe2034528178c08d976d37baf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637671472976689869%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=ksWHz35njdlH95RSvcETegEcn7tDwy3nsF5n2dOcl9k%3D=0>

**
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%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.educause.edu-252Fcommunity

Re: Cisco EAP-TLS fragmentation with active/active firewalls

[Tim Cappalli]

Switch to RadSec between your controllers and RADIUS server. Should eliminate 
the issue if you don't have any other config options.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Lee Weers 
Date: Monday, September 13, 2021 at 18:25
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] Cisco EAP-TLS fragmentation with active/active 
firewalls
Look at the load balancing on the firewalls. Depending on how it is setup, 
there is a way that all the traffic is sent to one firewall vs the other per 
session.  I know this can be done at the interface level. I don’t remember what 
they called it off the top of my head.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Turpin, Max
Sent: Monday, September 13, 2021 11:09 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] Cisco EAP-TLS fragmentation with active/active firewalls

Hey everyone,

Hoping everyone is having a peaceful start of the semester. Reaching out 
because we’re dealing with a doozy of a problem and hoping someone else may 
have dealt with this and can help.

We are running several pairs of Cisco 5520 controllers running 8.5.171 code. We 
have recently done a complete rebuild of our Clearpass environment split across 
two data centers and those are running 6.9.6. What we have found is that when 
sending traffic to this new cluster, some packets are greater than 1500 bytes 
and are getting fragmented in the environment. That would be all well and fine 
except our perimeter firewalls are active/active so in some cases, fragment 1 
goes to FW-A and fragment 2 goes to FW-B. Palo alto will drop fragments if does 
not have all parts. So these fragments are getting dropped and thus the EAP 
exchange is timing out.


  1.  As far as I’ve gotten from Cisco, 5520 controllers do not support jumbo 
frames
  2.  There is no support from Cisco on specifying an EAP-TLS fragment size 
(unlike Aruba)
  3.  I cannot move all the controllers inside the data centers as there are 
some remote controllers as part of this environment.

The only solution I can think of right now is to point the traffic to one 
firewall with policy routes with SLA tracking but that’s an administratively 
burdensome solution and frankly, kind of kludgy.

Have any of you dealt with this sort of issue? Any thoughts on this would be 
appreciated.

Thanks,
Max

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

**
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] ISE-NPS-Azure MFA

[Tim Cappalli]

I'd recommend you use SAML with your VPN solution directly to AAD and not go 
through ISE.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of James Andrewartha 

Sent: Thursday, August 26, 2021 10:50
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] ISE-NPS-Azure MFA


Microsoft note this behaviour and have some sort of workaround in their NPS MFA 
extension: 
https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-nps-extension#radius-protocol-behavior-and-the-nps-extension



Really though, doing MFA for RADIUS is a square peg in a round hole, use MFA to 
provision a client cert and do EAP-TLS instead.



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Manon Lessard 

Reply to: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Thursday, 26 August 2021 at 10:20 pm
To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" 
Subject: [WIRELESS-LAN] ISE-NPS-Azure MFA



A question not directly related to Wi-Fi, but related to ISE which seems to be 
something some of you use.



We are currently authenticating a VPN test group via ISE through NPS servers 
(defined as a token server).

The goal is to do MFA with Azure through the Authenticator app on people’s 
phones.

Everything works, but Authenticator pops up for confirmation, sometimes 2 to 3 
times, even if one has accepted the first confirmation…



I would like to have feedback from people who used something like that and have 
solved the multiple Authenticator prompts.



Thank you



Manon Lessard
Chargée de programmation et d’analyse

CCNP, CWNE #275, AWA 10, ESCE Design

Direction des technologies de l'information

Pavillon Louis-Jacques-Casault
1055, avenue du Séminaire
Bureau 0403
Université Laval, Québec (Québec)

G1V 0A6, Canada

418 656-2131, poste 412853
Télécopieur : 418 656-7305

manon.less...@dti.ulaval.ca
www.dti.ulaval.ca

Avis relatif à la confidentialité | Notice of 
Confidentiality



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

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

Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root

[Tim Cappalli]

Jonathan,

As I mentioned in my first reply, just use the certificate that is still valid 
on all nodes in your CPPM cluster for EAP. This will allow existing clients to 
still authenticate.

When that cert expires, you'll need to look at re-onboarding clients and at 
that point and I'd recommend moving to a PKI you control (even just a basic 
offline root using openssl). I'd recommend at least spinning up the root now 
and including it in the CAT tool config so new clients that connect will be 
ready for that change.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Jonathan Miller 

Date: Tuesday, August 10, 2021 at 10:59
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root
You don't often get email from jmill...@fandm.edu. Learn why this is 
important<http://aka.ms/LearnAboutSenderIdentification>
Thank you all for the informative replies.  As is probably obvious, when we 
initially rolled this out, we were completely unaware of the best practices, 
and are currently working to correct that and get our infrastructure where it 
should be.

We do not have an in-house PKI expert, but we are not completely unfamiliar 
with OpenSSL.  We do not currently have any internal CA as we've just used 
InCommon for all of our certificate needs.

If we want to do this right, my understanding is that the process is to:
1.  Create a Root CA with a long-lived certificate
2.  Create a certificate for our ClearPass servers, signed by that Root CA, 
making sure to include the attributes listed here:  
https://wiki.geant.org/display/H2eduroam/EAP+Server+Certificate+considerations<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.geant.org%2Fdisplay%2FH2eduroam%2FEAP%2BServer%2BCertificate%2Bconsiderations=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7Cd945b2f5981e4a8d218a08d95c0f368c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637642043443375888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=jh%2FetlyWIgHaSPABgLA68kwjOHmQBuGeZd0fFXetj%2F8%3D=0>
3.  Apply the certificate to ClearPass and distribute our new Root CA via CAT 
or other means

Would we be crazy to try to accomplish this inside of the 2 weeks that we have 
before students start to return to campus?  Any advice is appreciated, just 
trying to steer this boat away from the iceberg.

Thanks,

Jonathan Miller
Senior Network Analyst
Franklin and Marshall College


On Mon, Aug 9, 2021 at 12:12 PM Jeffrey D. Sessler 
mailto:j...@scrippscollege.edu>> wrote:
CA’s have done nothing is fifteen plus years, so from a risk management 
perspective, the chance of them changing course now is rather low. As to future 
RFCs, even if that happened tomorrow, it could be a decade or more before there 
was broad support, and more importantly, we could think about enforcement.

Jeff


From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Monday, August 09, 2021 8:05 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root

CA policies really have nothing to do with implementations of other protocols. 
There have been many discussions about this on this list and others, and a 
future RFC will likely include further clarity. However, as I've said in the 
past, RFCs do not dictate CA/B policies.

If we're going to continue this discussion, we should fork a new thread as it 
has nothing to do with the original question.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Jeffrey D. Sessler 
mailto:j...@scrippscollege.edu>>
Sent: Monday, August 9, 2021 10:53
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root


Per the RFC, the certificate-using application _MAY_ require the EAP extended 
key usage extension to be present. It is not a must or shall, so I’m not 
exactly sure the problem here. Vendors have chosen against requirement.



The certificate-using application appears to be satisfied by the server 
authentication EKU, which is appropriate, and I don’t see why the public CA 
would consider it a misuse and invalidate it.



As others have indicated, this is the de facto, and right or wrong, it’s not 
going to change and not worth getting stirred up about.



jeff



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Doug Wussler 
<029e57f9967b-dmarc-requ...@listserv.educause.edu<mailto:029e57f9967b-dmarc-requ...@listserv.educause.edu>>
Date: M

Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root

[Tim Cappalli]

CA policies really have nothing to do with implementations of other protocols. 
There have been many discussions about this on this list and others, and a 
future RFC will likely include further clarity. However, as I've said in the 
past, RFCs do not dictate CA/B policies.

If we're going to continue this discussion, we should fork a new thread as it 
has nothing to do with the original question.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Jeffrey D. Sessler 

Sent: Monday, August 9, 2021 10:53
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root


Per the RFC, the certificate-using application _MAY_ require the EAP extended 
key usage extension to be present. It is not a must or shall, so I’m not 
exactly sure the problem here. Vendors have chosen against requirement.



The certificate-using application appears to be satisfied by the server 
authentication EKU, which is appropriate, and I don’t see why the public CA 
would consider it a misuse and invalidate it.



As others have indicated, this is the de facto, and right or wrong, it’s not 
going to change and not worth getting stirred up about.



jeff



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Doug Wussler 
<029e57f9967b-dmarc-requ...@listserv.educause.edu>
Date: Monday, August 9, 2021 at 7:33 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root

Well, here is Microsoft's take on it...



https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/certificate-requirements-eap-tls-peap<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Ftroubleshoot%2Fwindows-server%2Fnetworking%2Fcertificate-requirements-eap-tls-peap=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C59c7f01ea8414b2479a408d95b457fa6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637641176365059401%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=%2BCWA6jkNM8DQmgmh8st8qz%2FKWxnsJU4%2B153FNcHcGog%3D=0>



[Image removed by 
sender.]<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Ftroubleshoot%2Fwindows-server%2Fnetworking%2Fcertificate-requirements-eap-tls-peap=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C59c7f01ea8414b2479a408d95b457fa6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637641176365069364%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=dpIf8NlChzBa%2F2GRw1x07spULXVqRrd%2Bin%2Blva%2FsJ3Y%3D=0>

Certificate requirements when you use EAP-TLS - Windows Server | Microsoft 
Docs<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Ftroubleshoot%2Fwindows-server%2Fnetworking%2Fcertificate-requirements-eap-tls-peap=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C59c7f01ea8414b2479a408d95b457fa6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637641176365069364%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=dpIf8NlChzBa%2F2GRw1x07spULXVqRrd%2Bin%2Blva%2FsJ3Y%3D=0>

Certificate requirements when you use EAP-TLS or PEAP with EAP-TLS. 09/08/2020; 
4 minutes to read; D; h; s; In this article. When you use Extensible 
Authentication Protocol-Transport Layer Security (EAP-TLS) or Protected 
Extensible Authentication Protocol (PEAP) with EAP-TLS, your client and server 
certificates must meet certain requirements.

docs.microsoft.com







From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu>
Sent: Monday, August 9, 2021 10:31 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root



I started working on something but decided it is not something I really have 
the cycles to maintain over time. (And I've found over the years that most 
people don't follow best practices anyway.)



tim



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Doug Wussler 
<029e57f9967b-dmarc-requ...@listserv.educause.edu>
Sent: Monday, August 9, 2021 10:30
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root



You don't often get email from 
029e57f9967b-dmarc-requ...@listserv.educause.edu. Learn why this is 
important<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F%2Faka.ms%2FLearnAboutSenderIdentification__%3B!!PhOWcWs!m_2CNd9NWCog0ZndhN4d4DBE2qugsIALRsIsBuLXHNQRxmnbzP9IM1KCwNjcaMgkk80%24=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C59c7f01ea8414b2479a408d95b457fa6%7C72f988bf86f141af91ab2d7cd011db47

Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root

[Tim Cappalli]

I started working on something but decided it is not something I really have 
the cycles to maintain over time. (And I've found over the years that most 
people don't follow best practices anyway.)

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Doug Wussler 
<029e57f9967b-dmarc-requ...@listserv.educause.edu>
Sent: Monday, August 9, 2021 10:30
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root

You don't often get email from 
029e57f9967b-dmarc-requ...@listserv.educause.edu. Learn why this is 
important<http://aka.ms/LearnAboutSenderIdentification>
Tim -

Didn't you write up an explanation for all these issues?  You were going to be 
able to point to that page since these issues resurface so often.

Doug


From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu>
Sent: Monday, August 9, 2021 8:42 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root

A public CA issues certificates for web server authentication (amongst others 
like code signing and S/MIME).

An EAP server is not a web server and has a designated usage assigned (which 
public CAs will not issue). EAP also does not follow traditional PKIX 
validation models due to the way the protocol operates.

Any public CA web server certificate used for EAP could be revoked for misuse 
at any time.

Tim



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Elton, Norman N 

Sent: Monday, August 9, 2021 8:36:08 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root

You don't often get email from wne...@wm.edu. Learn why this is 
important<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F%2Faka.ms%2FLearnAboutSenderIdentification__%3B!!PhOWcWs!noHRJ9yNg6gY_CYUmBa634tRxygv7eC6u8UIfKWwEztfKUZ8TF_IMixoYTawqpIJda0%24=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C468fff2bcd664807999208d95b4232fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637641162173292636%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=keJRtmc2KlEldjrgNyJBHH8oGIG2PO0uhgQ%2BHdAcdkA%3D=0>

>> Technically, you're not even supposed to use the certificates issued from a 
>> public CA for EAP as it's a violation of multiple policies.



I’m curious what those are. I thought it was fairly standard practice to use 
publicly-signed certificates on the server side, with privately-signed 
certificates on the clients.



Thanks!



Norman



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu>
Date: Monday, August 9, 2021 at 8:31 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root

EAP server certs from a PKI you (or a partner like SecureW2) control are the 
best practice.



Technically, you're not even supposed to use the certificates issued from a 
public CA for EAP as it's a violation of multiple policies.



Tim







From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Elton, Norman N 

Sent: Monday, August 9, 2021 8:18:37 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root



You don't often get email from wne...@wm.edu. Learn why this is 
important<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F%2Faka.ms%2FLearnAboutSenderIdentification__%3B!!PhOWcWs!noHRJ9yNg6gY_CYUmBa634tRxygv7eC6u8UIfKWwEztfKUZ8TF_IMixoYTawqpIJda0%24=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C468fff2bcd664807999208d95b4232fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637641162173302592%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=UWcLijHqgDvoe6dbXsP1hPINtL1jyIP%2BQupYw%2FPoVK8%3D=0>

To piggyback on Jonathan’s question … he mentions moving the server-side 
certificates to a private CA. Is this common? We’re using SecureW2 to configure 
an EAP-TLS deployment, so it should be trivial to configure the client to trust 
our private CA.



We currently configure clients to trust server certificates coming from 
InCommon. I’ve had a long-simmering concern that if, for whatever reason, we 
can’t use InCommon one day … that means we have to reconfigure all our 
cliients. One solution, of course, is to trust multiple root public CAs. I 
suppose an alternative is to move to a private CA on the server-side.



Thanks!



Norman





Norman Elton

Director

W IT Infrastructure

wne...@wm.edu&

Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root

[Tim Cappalli]

This is largely a workaround/hack due to the continued deployment of EAP server 
certificates issued from public CAs in the wild.

Issuing certificates from your own PKI with the web server auth EKU is 
perfectly acceptable and should also include the EAP EKU.

Unfortunately there can't really be a flag day for something like this due to 
industry fragmentation.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Jeffrey D. Sessler 

Sent: Monday, August 9, 2021 10:24
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root


I’m curious about this and would like to know more. Many operating systems 
require the Server Auth (1.3.6.1.5.5.7.3.1) EKU, and MS calls this out as a 
requirement for EAP. Last I looked, public CA’s include this when minting a so 
called web server cert.



Jeff





From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu>
Date: Monday, August 9, 2021 at 5:42 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root

A public CA issues certificates for web server authentication (amongst others 
like code signing and S/MIME).



An EAP server is not a web server and has a designated usage assigned (which 
public CAs will not issue). EAP also does not follow traditional PKIX 
validation models due to the way the protocol operates.



Any public CA web server certificate used for EAP could be revoked for misuse 
at any time.



Tim







From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Elton, Norman N 

Sent: Monday, August 9, 2021 8:36:08 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root



You don't often get email from wne...@wm.edu. Learn why this is 
important<http://aka.ms/LearnAboutSenderIdentification>

>> Technically, you're not even supposed to use the certificates issued from a 
>> public CA for EAP as it's a violation of multiple policies.



I’m curious what those are. I thought it was fairly standard practice to use 
publicly-signed certificates on the server side, with privately-signed 
certificates on the clients.



Thanks!



Norman



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu>
Date: Monday, August 9, 2021 at 8:31 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root

EAP server certs from a PKI you (or a partner like SecureW2) control are the 
best practice.



Technically, you're not even supposed to use the certificates issued from a 
public CA for EAP as it's a violation of multiple policies.



Tim







From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Elton, Norman N 

Sent: Monday, August 9, 2021 8:18:37 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root



You don't often get email from wne...@wm.edu. Learn why this is 
important<http://aka.ms/LearnAboutSenderIdentification>

To piggyback on Jonathan’s question … he mentions moving the server-side 
certificates to a private CA. Is this common? We’re using SecureW2 to configure 
an EAP-TLS deployment, so it should be trivial to configure the client to trust 
our private CA.



We currently configure clients to trust server certificates coming from 
InCommon. I’ve had a long-simmering concern that if, for whatever reason, we 
can’t use InCommon one day … that means we have to reconfigure all our 
cliients. One solution, of course, is to trust multiple root public CAs. I 
suppose an alternative is to move to a private CA on the server-side.



Thanks!



Norman





Norman Elton

Director

W IT Infrastructure

wne...@wm.edu<mailto:wne...@wm.edu> / 757-221-7790







From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu>
Date: Monday, August 9, 2021 at 8:03 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root

You should never use different EAP server certificates across a RADIUS cluster. 
Use the same cert across all nodes (in this case take the other cert with the 
longest expiry and upload it to all the nodes in the CPPM cluster)







From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Jonathan Miller 

Sent: Monday, August 9, 2021 7:32:19 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root



You don't often get email from jmill

Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root

[Tim Cappalli]

Lets not go down this rabbit hole again.

I was directly answering the question. If you choose to use certificates that 
violate CA policies and risk revocation, and ask users to configure their own 
supplicants, putting their credentials at high risk, that is your decision.

Tim



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of James Andrewartha 

Sent: Monday, August 9, 2021 8:52:03 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root

Which is great and I agree with but Android went and made it really hard to 
onboard a private CA and so now people are going back to public certs for EAP 
to lower their support burden.



Sent from my Galaxy



 Original message 
From: Tim Cappalli <0194c9ecac40-dmarc-requ...@listserv.educause.edu>
Date: 9/8/21 20:42 (GMT+08:00)
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root

A public CA issues certificates for web server authentication (amongst others 
like code signing and S/MIME).

An EAP server is not a web server and has a designated usage assigned (which 
public CAs will not issue). EAP also does not follow traditional PKIX 
validation models due to the way the protocol operates.

Any public CA web server certificate used for EAP could be revoked for misuse 
at any time.

Tim



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Elton, Norman N 

Sent: Monday, August 9, 2021 8:36:08 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root

You don't often get email from wne...@wm.edu. Learn why this is 
important<http://aka.ms/LearnAboutSenderIdentification>

>> Technically, you're not even supposed to use the certificates issued from a 
>> public CA for EAP as it's a violation of multiple policies.



I’m curious what those are. I thought it was fairly standard practice to use 
publicly-signed certificates on the server side, with privately-signed 
certificates on the clients.



Thanks!



Norman



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu>
Date: Monday, August 9, 2021 at 8:31 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root

EAP server certs from a PKI you (or a partner like SecureW2) control are the 
best practice.



Technically, you're not even supposed to use the certificates issued from a 
public CA for EAP as it's a violation of multiple policies.



Tim







From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Elton, Norman N 

Sent: Monday, August 9, 2021 8:18:37 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root



You don't often get email from wne...@wm.edu. Learn why this is 
important<http://aka.ms/LearnAboutSenderIdentification>

To piggyback on Jonathan’s question … he mentions moving the server-side 
certificates to a private CA. Is this common? We’re using SecureW2 to configure 
an EAP-TLS deployment, so it should be trivial to configure the client to trust 
our private CA.



We currently configure clients to trust server certificates coming from 
InCommon. I’ve had a long-simmering concern that if, for whatever reason, we 
can’t use InCommon one day … that means we have to reconfigure all our 
cliients. One solution, of course, is to trust multiple root public CAs. I 
suppose an alternative is to move to a private CA on the server-side.



Thanks!



Norman





Norman Elton

Director

W IT Infrastructure

wne...@wm.edu<mailto:wne...@wm.edu> / 757-221-7790







From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu>
Date: Monday, August 9, 2021 at 8:03 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root

You should never use different EAP server certificates across a RADIUS cluster. 
Use the same cert across all nodes (in this case take the other cert with the 
longest expiry and upload it to all the nodes in the CPPM cluster)







From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Jonathan Miller 

Sent: Monday, August 9, 2021 7:32:19 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root



You don't often get email from jmill...@fandm.edu. Learn why this is 
important<http://aka.ms/LearnAboutSenderIdentification>

We are currently using publicly signed certificates for our eduroam access on a 
cluster of 2 ClearP

Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root

[Tim Cappalli]

A public CA issues certificates for web server authentication (amongst others 
like code signing and S/MIME).

An EAP server is not a web server and has a designated usage assigned (which 
public CAs will not issue). EAP also does not follow traditional PKIX 
validation models due to the way the protocol operates.

Any public CA web server certificate used for EAP could be revoked for misuse 
at any time.

Tim



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Elton, Norman N 

Sent: Monday, August 9, 2021 8:36:08 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root

You don't often get email from wne...@wm.edu. Learn why this is 
important<http://aka.ms/LearnAboutSenderIdentification>

>> Technically, you're not even supposed to use the certificates issued from a 
>> public CA for EAP as it's a violation of multiple policies.



I’m curious what those are. I thought it was fairly standard practice to use 
publicly-signed certificates on the server side, with privately-signed 
certificates on the clients.



Thanks!



Norman



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu>
Date: Monday, August 9, 2021 at 8:31 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root

EAP server certs from a PKI you (or a partner like SecureW2) control are the 
best practice.



Technically, you're not even supposed to use the certificates issued from a 
public CA for EAP as it's a violation of multiple policies.



Tim







From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Elton, Norman N 

Sent: Monday, August 9, 2021 8:18:37 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root



You don't often get email from wne...@wm.edu. Learn why this is 
important<http://aka.ms/LearnAboutSenderIdentification>

To piggyback on Jonathan’s question … he mentions moving the server-side 
certificates to a private CA. Is this common? We’re using SecureW2 to configure 
an EAP-TLS deployment, so it should be trivial to configure the client to trust 
our private CA.



We currently configure clients to trust server certificates coming from 
InCommon. I’ve had a long-simmering concern that if, for whatever reason, we 
can’t use InCommon one day … that means we have to reconfigure all our 
cliients. One solution, of course, is to trust multiple root public CAs. I 
suppose an alternative is to move to a private CA on the server-side.



Thanks!



Norman





Norman Elton

Director

W IT Infrastructure

wne...@wm.edu<mailto:wne...@wm.edu> / 757-221-7790







From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu>
Date: Monday, August 9, 2021 at 8:03 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root

You should never use different EAP server certificates across a RADIUS cluster. 
Use the same cert across all nodes (in this case take the other cert with the 
longest expiry and upload it to all the nodes in the CPPM cluster)







From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Jonathan Miller 

Sent: Monday, August 9, 2021 7:32:19 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root



You don't often get email from jmill...@fandm.edu. Learn why this is 
important<http://aka.ms/LearnAboutSenderIdentification>

We are currently using publicly signed certificates for our eduroam access on a 
cluster of 2 ClearPass servers.



We are in a situation where one of our certs will be expiring in October of 
this year, while the other is good until June of next year.



The certificate are issued through InCommon, and when I renewed our expiring 
certificate, I noticed that it is showing that is has a root of Sectigo, where 
it was previously Comodo.  The certificate that is not expiring has a root CA 
of Comodo.



This leads me to the following questions:

1.  Is it advisable to run certificates with different Root CAs on different 
members of our ClearPass cluster?  Would we expect to see client issues?

2.  If it's not a problem to do this, can I simply add the Root CA for Sectigo 
to our eduroam CAT configuration, or is there only one Root CA allowed?



Any other advice is appreciated.  I understand that most institutions are 
moving to privately issued certificates in order to get control of these 
certificate chain issues, but we haven't quite gotten there yet.  Our plan to 
properly onboard clients is to use an SSID with a c

Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root

[Tim Cappalli]

EAP server certs from a PKI you (or a partner like SecureW2) control are the 
best practice.

Technically, you're not even supposed to use the certificates issued from a 
public CA for EAP as it's a violation of multiple policies.

Tim



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Elton, Norman N 

Sent: Monday, August 9, 2021 8:18:37 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root

You don't often get email from wne...@wm.edu. Learn why this is 
important<http://aka.ms/LearnAboutSenderIdentification>

To piggyback on Jonathan’s question … he mentions moving the server-side 
certificates to a private CA. Is this common? We’re using SecureW2 to configure 
an EAP-TLS deployment, so it should be trivial to configure the client to trust 
our private CA.



We currently configure clients to trust server certificates coming from 
InCommon. I’ve had a long-simmering concern that if, for whatever reason, we 
can’t use InCommon one day … that means we have to reconfigure all our 
cliients. One solution, of course, is to trust multiple root public CAs. I 
suppose an alternative is to move to a private CA on the server-side.



Thanks!



Norman





Norman Elton

Director

W IT Infrastructure

wne...@wm.edu<mailto:wne...@wm.edu> / 757-221-7790







From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu>
Date: Monday, August 9, 2021 at 8:03 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root

You should never use different EAP server certificates across a RADIUS cluster. 
Use the same cert across all nodes (in this case take the other cert with the 
longest expiry and upload it to all the nodes in the CPPM cluster)







From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Jonathan Miller 

Sent: Monday, August 9, 2021 7:32:19 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root



You don't often get email from jmill...@fandm.edu. Learn why this is 
important<http://aka.ms/LearnAboutSenderIdentification>

We are currently using publicly signed certificates for our eduroam access on a 
cluster of 2 ClearPass servers.



We are in a situation where one of our certs will be expiring in October of 
this year, while the other is good until June of next year.



The certificate are issued through InCommon, and when I renewed our expiring 
certificate, I noticed that it is showing that is has a root of Sectigo, where 
it was previously Comodo.  The certificate that is not expiring has a root CA 
of Comodo.



This leads me to the following questions:

1.  Is it advisable to run certificates with different Root CAs on different 
members of our ClearPass cluster?  Would we expect to see client issues?

2.  If it's not a problem to do this, can I simply add the Root CA for Sectigo 
to our eduroam CAT configuration, or is there only one Root CA allowed?



Any other advice is appreciated.  I understand that most institutions are 
moving to privately issued certificates in order to get control of these 
certificate chain issues, but we haven't quite gotten there yet.  Our plan to 
properly onboard clients is to use an SSID with a captive portal to direct them 
to the eduroam CAT download.



Thanks,

Jonathan Miller

Senior Network Analyst

Franklin and Marshall College

**
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=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C78bfb0cfe8144d3728f408d95b2fd24d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637641083242437605%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=DzBifpIe8ILZYvzbMR96aftTLyUacSZJiG%2F%2FI4iczro%3D=0>

**
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=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C78bfb0cfe8144d3728f408d95b2fd24d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637641083242447562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1

Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root

[Tim Cappalli]

You should never use different EAP server certificates across a RADIUS cluster. 
Use the same cert across all nodes (in this case take the other cert with the 
longest expiry and upload it to all the nodes in the CPPM cluster)



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Jonathan Miller 

Sent: Monday, August 9, 2021 7:32:19 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root

You don't often get email from jmill...@fandm.edu. Learn why this is 
important
We are currently using publicly signed certificates for our eduroam access on a 
cluster of 2 ClearPass servers.

We are in a situation where one of our certs will be expiring in October of 
this year, while the other is good until June of next year.

The certificate are issued through InCommon, and when I renewed our expiring 
certificate, I noticed that it is showing that is has a root of Sectigo, where 
it was previously Comodo.  The certificate that is not expiring has a root CA 
of Comodo.

This leads me to the following questions:
1.  Is it advisable to run certificates with different Root CAs on different 
members of our ClearPass cluster?  Would we expect to see client issues?
2.  If it's not a problem to do this, can I simply add the Root CA for Sectigo 
to our eduroam CAT configuration, or is there only one Root CA allowed?

Any other advice is appreciated.  I understand that most institutions are 
moving to privately issued certificates in order to get control of these 
certificate chain issues, but we haven't quite gotten there yet.  Our plan to 
properly onboard clients is to use an SSID with a captive portal to direct them 
to the eduroam CAT download.

Thanks,

Jonathan Miller
Senior Network Analyst
Franklin and Marshall College

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

Re: PEAP Username format in Domain Joined machines

[Tim Cappalli]

If you're planning on keeping legacy auth, you can modify the supplicant config 
in your GPO/MDM policy to prompt the user the first time. They can then enter 
their fully qualified username and password when prompted.

Legacy protocols should never be used without a GPO or MDM enforced supplicant.



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Pratik Mehta 

Sent: Tuesday, July 27, 2021 12:10:58 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] PEAP Username format in Domain Joined machines


Yes, we are using eduroam. For the Radius server we use Aruba ClearPass.



Additional Context: The reason for this ask is to support our faculty/staff 
that visits other “eduroam” participating universities. We are also using the 
authentication option of “User auth or computer auth” so when the user is 
logged out of the machine, the device remains connected to the wireless network 
via computer authentication. We understand that we can manually modify the 
profile to unselect “Automatically use my windows logon and password” in the 
wireless profile and manually configure the user name in the format of 
USERNAME@FQDN when prompted. However, the issue is we do not have all the 
faculty/admin staff with admin rights to machine.



Thank you Tim and Lynn.



Regards,

Pratik Mehta



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Heavrin, Lynn
Sent: Tuesday, July 27, 2021 12:01 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] PEAP Username format in Domain Joined machines



I didn’t see anywhere he mentioned this was for eduroam, but after a google 
search it seems Princeton uses it for their primary SSID, so yes that is a good 
point.  That’s one big factor in why we’re moving to EAP-TLS and forcing the 
format instead of trying to accommodate whatever the user decides to type in.



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu<mailto:0194c9ecac40-dmarc-requ...@listserv.educause.edu>>
Date: Tuesday, July 27, 2021 at 10:47 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] PEAP Username format in Domain Joined machines

I would not recommend that as the device will not be routable on eduroam 
outside your campus.



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Heavrin, Lynn mailto:lheav...@wustl.edu>>
Date: Tuesday, July 27, 2021 at 11:41
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] PEAP Username format in Domain Joined machines

Depending on your RADIUS server you could rewrite the identity to whatever you 
want.  Some are more granular than others with what all you can do.



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu<mailto:0194c9ecac40-dmarc-requ...@listserv.educause.edu>>
Date: Tuesday, July 27, 2021 at 10:17 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] PEAP Username format in Domain Joined machines

No, it cannot.



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Pratik Mehta mailto:pra...@princeton.edu>>
Date: Tuesday, July 27, 2021 at 11:14
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: [WIRELESS-LAN] PEAP Username format in Domain Joined machines

Hello Everyone,



On a Windows 10 device, and when using “Automatically use my windows logon and 
password” for MSCHAPv2 properties of PEAP authentication, the default username 
format that Windows uses in NETBIOS_DOMAIN_NAME\USERNAME.  Does anyone know if 
the default format can be to changed to USERNAME@FQDN (UPN format)?  This is 
obviously for a domain joined machine.



Thank you for your insights and assistance.



Regards,

Pratik Mehta



**
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=04%7C

Re: PEAP Username format in Domain Joined machines

[Tim Cappalli]

I would not recommend that as the device will not be routable on eduroam 
outside your campus.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Heavrin, Lynn 

Date: Tuesday, July 27, 2021 at 11:41
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] PEAP Username format in Domain Joined machines
Depending on your RADIUS server you could rewrite the identity to whatever you 
want.  Some are more granular than others with what all you can do.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu>
Date: Tuesday, July 27, 2021 at 10:17 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] PEAP Username format in Domain Joined machines
No, it cannot.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Pratik Mehta 

Date: Tuesday, July 27, 2021 at 11:14
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: [WIRELESS-LAN] PEAP Username format in Domain Joined machines
Hello Everyone,

On a Windows 10 device, and when using “Automatically use my windows logon and 
password” for MSCHAPv2 properties of PEAP authentication, the default username 
format that Windows uses in NETBIOS_DOMAIN_NAME\USERNAME.  Does anyone know if 
the default format can be to changed to USERNAME@FQDN (UPN format)?  This is 
obviously for a domain joined machine.

Thank you for your insights and assistance.

Regards,
Pratik Mehta


**
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=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C4072b031cb7c4c371e1508d95114e6c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637629972668917488%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=P8cJtMXFKzjDtllv%2FU93k4f4%2BtoHUi%2BbaKvXue%2Faml4%3D=0>

**
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=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C4072b031cb7c4c371e1508d95114e6c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637629972668927452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=D0Y5kzmNhNLJ7cBk3rkMHElNZqi3F9aHlbNJFOt59Ro%3D=0>



The materials in this message are private and may contain Protected Healthcare 
Information or other information of a sensitive nature. If you are not the 
intended recipient, be advised that any unauthorized use, disclosure, copying 
or the taking of any action in reliance on the contents of this information is 
strictly prohibited. If you have received this email in error, please 
immediately notify the sender via telephone or return mail.

**
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=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C4072b031cb7c4c371e1508d95114e6c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637629972668937397%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=q4Ay9s5CQ8L9E3qs4cUlDDYqF9b1eAnosakUwikwvKg%3D=0>

**
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: PEAP Username format in Domain Joined machines

[Tim Cappalli]

No, it cannot.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Pratik Mehta 

Date: Tuesday, July 27, 2021 at 11:14
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: [WIRELESS-LAN] PEAP Username format in Domain Joined machines
Hello Everyone,

On a Windows 10 device, and when using “Automatically use my windows logon and 
password” for MSCHAPv2 properties of PEAP authentication, the default username 
format that Windows uses in NETBIOS_DOMAIN_NAME\USERNAME.  Does anyone know if 
the default format can be to changed to USERNAME@FQDN (UPN format)?  This is 
obviously for a domain joined machine.

Thank you for your insights and assistance.

Regards,
Pratik Mehta


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

Re: Aruba and SAML SSO

[Tim Cappalli]

CPPM will parse out the SAML assertion attributes as long as you add them to 
the SSO dictionary in CPPM. You can then use them in role mapping or 
enforcement in an application authorization service.



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Martin MacLeod-Brown 

Sent: Monday, July 26, 2021 10:13:15 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: [WIRELESS-LAN] Aruba and SAML SSO


Hi Everyone



Just reaching out here to see if anyone has managed this using Aruba 
technologies?



We have a B2B client who enrols onto one of our Open Courses, using an email 
address of their choice.

We capture that email address in AAD and they will be sent an invite to join 
the relevant Teams/O365 resources that apply to them and to reset their initial 
password.

When these clients arrive at campus they connect to our guest Wi-Fi where they 
self register via our Captive Portal

Is there a way that they can use their B2B details that they signed up with 
originally to log into the guest Wi-Fi?



I know last time I looked at this, I could get Clearpass and AAD talking 
however the authentication token that AAD was sending back after a successful 
login was just some simple hashed text and I couldn’t work out how to intercept 
that or craft a service/role around it.



Has anyone done something like this?



Martin





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

Re: [WIRELESS-LAN] MPSK SSID Names

[Tim Cappalli]

Easiest way to prevent user-centric devices from actively using your headless 
device network is to block your identity provider from the headless roles so 
users can't sign in to resources.


From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Curtis, Bruce 
<01dd2279a597-dmarc-requ...@listserv.educause.edu>
Sent: Wednesday, June 9, 2021 10:23:22 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] MPSK SSID Names



> On Jun 9, 2021, at 8:59 AM, Michael Dickson  wrote:
>
> I'm curious if anyone is doing anything to prevent/discourage 802.1x capable 
> devices (laptops, tablets, smartphones) from connecting to the IoT network. 
> We would prefer these things stay on eduroam and currently use device 
> fingerprinting to deny access to our "devices/IoT" (MAB) network.

No.  Several IoT devices require that the phone/tablet/computer be on the SSID 
that the IoT device will be configured to use.  (The configuration App looks at 
what SSID the phone/tablet/computer is on and tells the IoT device to join the 
same SSID)

We require the MAC address of all of the devices that join the IoT SSID be 
registered so students have to register the MAC address of the 
phone/tablet/computer before connecting to the IoT SSID.

>
> Mike
> Michael Dickson
> Network Engineer
> Information Technology
> University of Massachusetts Amherst
> 413-545-9639
>
> michael.dick...@umass.edu
>
> PGP: 0x16777D39
>
>
>
> On 6/9/21 8:35 AM, Shoebottom, Bryan wrote:
>> I took over from our previous wireless admin a few years ago and went 
>> through an extensive project to consolidate and clean up our SSIDs.  Every 
>> use case seemed to have their own SSID multiplied by each site – it was a 
>> confusing mess for everyone.  After lots of research and consultation with 
>> our clients, and a mindset of keeping things simple yet accommodating 
>> policy/requirements, it came down to the following configuration:
>>
>>
>>
>> FanshaweCollege802.1x   staff/students via 
>> domain accounts, IoT/non-domain (e.g. shared iPads) items via ISE accounts
>>
>> FanshaweGuestMac auth click-through portal 
>> allows 24hrs access, then the portal comes up again
>>
>> eduroam 802.1x   staff/students 
>> via domain accounts, remote eduroam accounts
>>
>>
>>
>> FanshaweDevicesiPSK   IoT devices that don’t 
>> support 802.1x
>>
>>
>>
>>
>>
>> The top 2 SSIDs are broadcast at all our sites.  Eduroam is broadcast at all 
>> our educational based sites.  We tried to have eduroam and FanshaweCollege 
>> combined, but senior management didn’t want to lose the branded SSID.  As 
>> for the FanshaweDevices, to keep airspace clean, we only broadcast this 
>> where we need it.  We are a Cisco shop and almost exclusively on the WLC9800 
>> now.  We make use of the AP Join profiles and an AP naming standard to 
>> accomplish this.  By changing a character in the AP name, I can have it 
>> pickup different policies for RF, SSID, etc.  Currently we have the iPSK 
>> network only broadcast in 2 locations to support athletic equipment and 
>> Nintendo switches.  The iPSK auth method allows us have a single SSID, yet 
>> provide back-end control depending on the device that is connecting, or 
>> better, the PSK they use.  Our Residence networking is provided by a 3rd 
>> party.
>>
>>
>>
>> So far this has worked really well, and I received compliments the September 
>> following the changes as helpdesk lineups/queues were significantly shorter. 
>>  All SSIDs run on both 5 and 2.4GHz, so if we do decide to split up SSIDs 
>> based on frequency, I could see some changes here, otherwise it’s ticking 
>> all our boxes.
>>
>>
>>
>>
>>
>> --
>>
>> Regards,
>>
>>
>>
>> Bryan Shoebottom
>>
>> Network & Systems Specialist
>>
>>
>>
>> Network Services & Computer Operations
>>
>> 1001 Fanshawe College Blvd. London, ON N5Y 5R6
>>
>> T 519.452.4430 x4904 | F 519.453.3231
>>
>> bshoebot...@fanshawec.ca
>>
>>
>>
>> 
>>
>>
>> From: Patrick McEvilly 
>> Sent: June 8, 2021 4:37 PM
>> Subject: Re: MPSK SSID Names
>>
>>
>>
>> Hi Brian
>>
>>
>>
>> We are struggling with a name that would work for this.  We have “Harvard 
>> Secure” as our 802.1x SSID, “Harvard University” as our legacy MAC 
>> registered SSID and eduroam.  We want to use the MPSK SSID to solve for all 
>> things – IoT, gaming consoles, Alexa, Smart*, AV gear, for both BYOD and for 
>> infrastructure devices.  We are also interested in hearing what others have 
>> named their SSIDs or suggestions that would represent the general-purpose 
>> use of such an SSID.
>>
>>
>>
>> Patrick
>>
>>
>>
>> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>>  on behalf of Brian Helman 
>> 
>> Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 
>> 
>> Date: Tuesday, June 8, 2021 at 3:04 PM
>> To: 

Re: Forcing Client Cert Selection in Windows for EAP-TLS

[Tim Cappalli]

No, there's really no way to do this with your configuration. Mixing GPO/MDM + 
a supplicant utility like SecureW2 is not recommended. It becomes a giant 
unpredictable tug of war.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Heavrin, Lynn 

Sent: Friday, May 14, 2021 10:07
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: [WIRELESS-LAN] Forcing Client Cert Selection in Windows for EAP-TLS


Has anyone used EAP-TLS where a Windows device has multiple client certs loaded 
in the personal store?  Is there a way to force it via GPO to choose one cert 
over the other to use for authentication?  The user certs from ADCS don’t 
always contain a private key in the personal store except on the first device a 
user logs into, so we moved to SecureW2 to guarantee it would work.  In Cisco 
ISE I trust both ADCS and SecureW2 CAs.  What is happening and what I’m trying 
to achieve is:



  1.  if a computer happens to have an ADCS User cert private key, it uses that 
one first and I want to try to force it to use the SecureW2 cert via GPO or 
some setting
  2.  For machine auth, I want it to always use the ADCS cert since there’s no 
private key issue.  There is no SecureW2 machine cert.  Due to this I don’t 
think I can just say “only use certs from this Issuer CA” because I need both, 
unless I can do that for user and machine separately.



Thanks,



Lynn Heavrin

Network Engineer III | Network Engineering

Washington University in St. Louis





The materials in this message are private and may contain Protected Healthcare 
Information or other information of a sensitive nature. If you are not the 
intended recipient, be advised that any unauthorized use, disclosure, copying 
or the taking of any action in reliance on the contents of this information is 
strictly prohibited. If you have received this email in error, please 
immediately notify the sender via telephone or return mail.

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

Re: [WIRELESS-LAN] WPA3/OWE as campus solution?

[Tim Cappalli]

Don't remember saying anything about employees being forced to do anything...

We're so far off topic at this point. I'm done.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Jeffrey D. Sessler 

Sent: Thursday, April 22, 2021 1:05:35 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] WPA3/OWE as campus solution?


Tim,



I would take a look at case law, where it was determined that an employer can 
not expect an employee to use their own device without compensation.  This has 
resulted in two scenarios now.  The first being that the employer provides the 
employee with a stipend to compensate them for use of their personal device.  
The second being that employers now provide the necessary devices (tools) to 
the employee in order to carry out their duties.



For example, with COVID, many employers are providing temporary stipends to 
employees to cover Internet consumption and personal cell use.



In no way shape or fashion can an employer compel the user to install or enroll 
their personal device into their employer’s end-point management.  The employer 
could say it’s an optional condition of the employee’s desire, in a voluntary 
decision, to use that device for company business. Can’t be forced.



Jeff



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Tim Cappalli
Sent: Thursday, April 22, 2021 9:14 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] WPA3/OWE as campus solution?



Well, I can tell you that is just not the reality. Sorry!





From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Jeffrey D. Sessler 
mailto:j...@scrippscollege.edu>>
Sent: Thursday, April 22, 2021 12:04
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] WPA3/OWE as campus solution?



On 2021-04-21 21:30:53+, Tim Cappalli wrote:
>  I'd also like to address the comment about post-college experience.
>
>  Most organizations these students are going to work at are going to
> require MDM or MAM on their personal devices. So I fundamentally
> disagree with the comment that they won't deal with "enrollment" post
> campus life.

On the above specifically.  In every business scenario I've encountered, and 
it's at EDU level now too, unless you are going to compensate the user for 
access/control of their device, the business has no right to require MDM.  This 
is in the same territory as requiring an employee to check business email from 
a personal device - it must be only as an employee opt-in convenience, and not 
a substitute for the business providing that person the tools they need to do 
their job.

That's a long trip version of saying that a business is going to hand their 
employee a pre-enrolled/managed company-owned device(s) where it is the 
business' responsibility to handle whatever onboarding they've established for 
their company assets.  The individual will never encounter this activity (nor 
should they) with a personal device they own.

Jeff

-Original Message-
From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Jonathan Waldrep
Sent: Wednesday, April 21, 2021 7:27 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] WPA3/OWE as campus solution?

On 2021-04-21 21:24:25+, Tim Cappalli wrote:
>  Why not take baby steps? One example: So many organizations talk
> about user experience challenges of onboarding (and trust me, I hear
> you) but then issue 1 year certs and force the user through it every
> year.
>
>  Switch to a 5 year cert (or device specific cred) and use
> authorization rules to temporarily (or permanently) revoke access.
 100%. Preach. We are kicking off a project to move from PEAP/MSCHAPv2 to 
EAP-TLS, primarily for usability reasons. There are plenty of other reasons why 
it is a good change (that I as an admin am personally excited about), but they 
are not what is pushing things forward that hardest. Right now, because 
MSCHAPv2 is hot garbage, users have a password used only for network access. We 
want to get rid of that.
Partly because _passwords_ are hot garbage.

 The intent is to move to per-device certs that will expire after the device is 
dead from oxidation. The cert/key establishes _authentication_ (who is this?). 
This is only breaks if the key is compromised or the device changes hands. 
Everything else is an issue of _authorization_ (is this allowed?). We're 
considering blurring that line a bit and pretending it is all authorization, 
but now I'm just rambling.

 I don't think I've said anything until this point that Tim wo

Re: [WIRELESS-LAN] WPA3/OWE as campus solution?

[Tim Cappalli]

Well, I can tell you that is just not the reality. Sorry!


From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Jeffrey D. Sessler 

Sent: Thursday, April 22, 2021 12:04
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] WPA3/OWE as campus solution?

On 2021-04-21 21:30:53+, Tim Cappalli wrote:
>  I'd also like to address the comment about post-college experience.
>
>  Most organizations these students are going to work at are going to
> require MDM or MAM on their personal devices. So I fundamentally
> disagree with the comment that they won't deal with "enrollment" post
> campus life.

On the above specifically.  In every business scenario I've encountered, and 
it's at EDU level now too, unless you are going to compensate the user for 
access/control of their device, the business has no right to require MDM.  This 
is in the same territory as requiring an employee to check business email from 
a personal device - it must be only as an employee opt-in convenience, and not 
a substitute for the business providing that person the tools they need to do 
their job.

That's a long trip version of saying that a business is going to hand their 
employee a pre-enrolled/managed company-owned device(s) where it is the 
business' responsibility to handle whatever onboarding they've established for 
their company assets.  The individual will never encounter this activity (nor 
should they) with a personal device they own.

Jeff

-Original Message-
From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Jonathan Waldrep
Sent: Wednesday, April 21, 2021 7:27 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] WPA3/OWE as campus solution?

On 2021-04-21 21:24:25+, Tim Cappalli wrote:
>  Why not take baby steps? One example: So many organizations talk
> about user experience challenges of onboarding (and trust me, I hear
> you) but then issue 1 year certs and force the user through it every
> year.
>
>  Switch to a 5 year cert (or device specific cred) and use
> authorization rules to temporarily (or permanently) revoke access.
 100%. Preach. We are kicking off a project to move from PEAP/MSCHAPv2 to 
EAP-TLS, primarily for usability reasons. There are plenty of other reasons why 
it is a good change (that I as an admin am personally excited about), but they 
are not what is pushing things forward that hardest. Right now, because 
MSCHAPv2 is hot garbage, users have a password used only for network access. We 
want to get rid of that.
Partly because _passwords_ are hot garbage.

 The intent is to move to per-device certs that will expire after the device is 
dead from oxidation. The cert/key establishes _authentication_ (who is this?). 
This is only breaks if the key is compromised or the device changes hands. 
Everything else is an issue of _authorization_ (is this allowed?). We're 
considering blurring that line a bit and pretending it is all authorization, 
but now I'm just rambling.

 I don't think I've said anything until this point that Tim would disagree 
with. It's here mostly for the broader discussion of the thread.

> You don't have to burn the whole forest down.
 I'm not planning on it. We'll still have a .1X network (eduroam). I just won't 
care if someone decides to not use it.

 What I do want to burn down are the dead trees - the captive portal and 
_mandated_ authentication. And that's not going to happen for a while.
EAP-TLS isn't a strict prereq, but it is more urgent, and we don't have the 
manpower to do both at the same time.

>  I'm sure your security folks would rather have a guaranteed encrypted
> network with user identity, a 5 year cert and full control, than an
> open network with no reliable user identity or enforcement mechanism.
 I've talked to them. They don't care. That's the simplicity zero-trust brings 
to the table. The _legal_ team on the other hand... that's a conversation that 
still needs to happen.

 I've used the term "zero-trust" some already, and I'm about to a lot more, so 
let's get past the buzz-word and define it. By "zero-trust", I am making the 
explicit choice to _NOT_:
  - care who you are
  - make any assumption about the security posture of the device
  - make any assumption about the network between us (encrypted, MitM,
etc)
 I _might_ care if your identity is knowable. Subtle but important distinction 
here: I _might_ care if the question, "Who are you?" has a meaningful answer, 
for the sake of accountability. I do _not_ care what that answer is.
 Also, some of these questions obviously need answering somewhere around layer 
7. But, layers 1-3 are not designed to answer those questions and are really 
bad at trying. Zero-trust is specifically layers 1-3.

 On enforcement, lets take a trip into the nuances of our implementation of 
zero-trust

Re: [WIRELESS-LAN] WPA3/OWE as campus solution?

[Tim Cappalli]

I'd also like to address the comment about post-college experience.

Most organizations these students are going to work at are going to require MDM 
or MAM on their personal devices. So I fundamentally disagree with the comment 
that they won't deal with "enrollment" post campus life.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu>
Sent: Wednesday, April 21, 2021 5:24:25 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] WPA3/OWE as campus solution?

Why not take baby steps? One example: So many organizations talk about user 
experience challenges of onboarding (and trust me, I hear you) but then issue 1 
year certs and force the user through it every year.

Switch to a 5 year cert (or device specific cred) and use authorization rules 
to temporarily (or permanently) revoke access.

You don't have to burn the whole forest down.

I'm sure your security folks would rather have a guaranteed encrypted network 
with user identity, a 5 year cert and full control, than an open network with 
no reliable user identity or enforcement mechanism.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Jonathan Waldrep 

Sent: Wednesday, April 21, 2021 5:15:09 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] WPA3/OWE as campus solution?

I keep trying to reply to this thread with my thoughts and some idea of where 
we are trying to move on this topic, but inevitably, it ends up rambly and 
unfinished. Let's see if I can actually keep it short and relevant. If so, 
there is lots left unsaid; please feel free to ask for details.

We don't have a non-BYOD side of the network. There are some traditional 
institution-managed devices, but they are the exception, and they don't have a 
special network. Painting with a broad brush lacking some nuance, all of our 
user facing networks are zero trust. Turns out, this simplifies a great many 
things.

That said, I would love to move to a model where we have eduroam, and a wide 
open network (preferably with OWE, but that is orthogonal). No captive portal. 
No PSK. Both of those methods are problematic. Why? And what about device 
discovery (Chromecasts, airplay, etc)? How do we know who the device belongs 
to? How do you keep the devices secure without encryption? How do you keep the 
network secure without authentication? Why have eduroam at all? Great 
questions, that I'm going to skip right over (see preface).

In general, shifting our mindset about network authentication from something 
that is required for the administrators' sake to something that the user can 
opt into because it gives _the user_ tangible value opens up a lot of 
opportunity.

The biggest challenges to overcome here are _not_ technical. They are business 
and legal issues. On that note, I have yet to see a time where a technical 
solution to a non-technical problem doesn't end up hurting the user.

--
Jonathan Waldrep
Network Engineer
Network Infrastructure and Services
Virginia Tech


On Wed, Apr 21, 2021 at 3:22 PM Jennifer Minella 
mailto:j...@cadinc.com>> wrote:

Ooh Lee what a great thread! I didn’t have a chance yesterday but catching up 
now.



Here’s what I throw in the mix for consideration… (no recommendations just free 
flow thoughts)

Sorry this is long; WPA3 gets me really excited 



  1.  OWE/Open Enhanced (not technically part of WPA3 but #semantics) ONLY 
provides OTA encryption; it does nothing for authenticating the user to the 
network NOR the network to the user.
  2.  …that means you could use a guest portal experience, with or without user 
ID, and add encryption vs historically having to use a Pre-Shared Key or 802.1X 
for key exchanges and encryption.
  3.  If you care about who the user is, you can still use a portal with 
self-registration and whatever duration you feel is appropriate. Depending on 
how much you care, a self-registration portal may (or may not) be sufficient.
  4.  If you care about protecting the user/device against a MiTM or evil twin 
attack, then you probably prefer a mechanism that allows some type of 
authentication, which is typically mutual authentication (e.g. 1X).
  5.  Under WPA3, security is increased across the board and will be ongoing 
(not fixed). Including replacing Pre-Shared Key (PSK) with SAE- which 
looks/feels JUST like PSK to admins/users but further protects assets by using 
unique key derivations for each endpoint. So… if someone has the passcode they 
can get on, but they can’t decrypt any other traffic even if the endpoint(s) 
are using the same key. The list of enhancements goes on and on.
  6.  Does your organization require traceability of users for any internal or 
external policies or compliance? This could be for security reasons, compliance 
with IP and digital rights, or other n

Re: [WIRELESS-LAN] WPA3/OWE as campus solution?

[Tim Cappalli]

Why not take baby steps? One example: So many organizations talk about user 
experience challenges of onboarding (and trust me, I hear you) but then issue 1 
year certs and force the user through it every year.

Switch to a 5 year cert (or device specific cred) and use authorization rules 
to temporarily (or permanently) revoke access.

You don't have to burn the whole forest down.

I'm sure your security folks would rather have a guaranteed encrypted network 
with user identity, a 5 year cert and full control, than an open network with 
no reliable user identity or enforcement mechanism.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Jonathan Waldrep 

Sent: Wednesday, April 21, 2021 5:15:09 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] WPA3/OWE as campus solution?

I keep trying to reply to this thread with my thoughts and some idea of where 
we are trying to move on this topic, but inevitably, it ends up rambly and 
unfinished. Let's see if I can actually keep it short and relevant. If so, 
there is lots left unsaid; please feel free to ask for details.

We don't have a non-BYOD side of the network. There are some traditional 
institution-managed devices, but they are the exception, and they don't have a 
special network. Painting with a broad brush lacking some nuance, all of our 
user facing networks are zero trust. Turns out, this simplifies a great many 
things.

That said, I would love to move to a model where we have eduroam, and a wide 
open network (preferably with OWE, but that is orthogonal). No captive portal. 
No PSK. Both of those methods are problematic. Why? And what about device 
discovery (Chromecasts, airplay, etc)? How do we know who the device belongs 
to? How do you keep the devices secure without encryption? How do you keep the 
network secure without authentication? Why have eduroam at all? Great 
questions, that I'm going to skip right over (see preface).

In general, shifting our mindset about network authentication from something 
that is required for the administrators' sake to something that the user can 
opt into because it gives _the user_ tangible value opens up a lot of 
opportunity.

The biggest challenges to overcome here are _not_ technical. They are business 
and legal issues. On that note, I have yet to see a time where a technical 
solution to a non-technical problem doesn't end up hurting the user.

--
Jonathan Waldrep
Network Engineer
Network Infrastructure and Services
Virginia Tech


On Wed, Apr 21, 2021 at 3:22 PM Jennifer Minella 
mailto:j...@cadinc.com>> wrote:

Ooh Lee what a great thread! I didn’t have a chance yesterday but catching up 
now.



Here’s what I throw in the mix for consideration… (no recommendations just free 
flow thoughts)

Sorry this is long; WPA3 gets me really excited 



  1.  OWE/Open Enhanced (not technically part of WPA3 but #semantics) ONLY 
provides OTA encryption; it does nothing for authenticating the user to the 
network NOR the network to the user.
  2.  …that means you could use a guest portal experience, with or without user 
ID, and add encryption vs historically having to use a Pre-Shared Key or 802.1X 
for key exchanges and encryption.
  3.  If you care about who the user is, you can still use a portal with 
self-registration and whatever duration you feel is appropriate. Depending on 
how much you care, a self-registration portal may (or may not) be sufficient.
  4.  If you care about protecting the user/device against a MiTM or evil twin 
attack, then you probably prefer a mechanism that allows some type of 
authentication, which is typically mutual authentication (e.g. 1X).
  5.  Under WPA3, security is increased across the board and will be ongoing 
(not fixed). Including replacing Pre-Shared Key (PSK) with SAE- which 
looks/feels JUST like PSK to admins/users but further protects assets by using 
unique key derivations for each endpoint. So… if someone has the passcode they 
can get on, but they can’t decrypt any other traffic even if the endpoint(s) 
are using the same key. The list of enhancements goes on and on.
  6.  Does your organization require traceability of users for any internal or 
external policies or compliance? This could be for security reasons, compliance 
with IP and digital rights, or other needs. One Uni org I’ve worked with 
successfully stopped a student from a suicide attempt when the student posted 
online- they physically located the person and saved them from what they were 
about to do… There are a lot of things to consider and every org is different.
  7.  Whether or not portal acceptable use and/or user ID/registration is 
needed is a hotly-debated topic and has a lot of “it depends”. I recently asked 
several CISOs, lawyers, auditors, and cyber security friends at the FBI.
 *   The CISOs feel it’s “window dressing” except that per …
 *   …Lawyers, there may be some legal protection if a user 

Re: WPA3/OWE as campus solution?

[Tim Cappalli]

How would you limit local services like printing, screen mirroring, media 
casting, etc?

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Lee H Badman 
<00db5b77bd95-dmarc-requ...@listserv.educause.edu>
Sent: Friday, April 16, 2021 10:17
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] WPA3/OWE as campus solution?


Exactly- hance the notion of simplifying… relying on application security, 2FA 
etc for actual security while making simply connecting much, much easier.



Lee Badman | Network Architect (CWNE#200)

Information Technology Services
(NDD Group)
206 Machinery Hall
120 Smith Drive
Syracuse, New York 13244

t 315.443.3003   e lhbad...@syr.edu<mailto:lhbad...@syr.edu> w its.syr.edu

Campus Wireless Policy: 
https://answers.syr.edu/display/network/Wireless+Network+and+Systems<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fanswers.syr.edu%2Fdisplay%2Fnetwork%2FWireless%2BNetwork%2Band%2BSystems=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C27dfc8f182a44aed4cd308d900e27165%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637541794836879442%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=l7sSKIp95iXMYD5uRV%2F%2FbVgSsEaikmLNW%2FhYq1D0u0M%3D=0>

SYRACUSE UNIVERSITY
syr.edu



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Tim Cappalli
Sent: Friday, April 16, 2021 10:16 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] WPA3/OWE as campus solution?



Just keep in mind that OWE does not have an identity layer.



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Lee H Badman 
<00db5b77bd95-dmarc-requ...@listserv.educause.edu<mailto:00db5b77bd95-dmarc-requ...@listserv.educause.edu>>
Sent: Friday, April 16, 2021 10:08
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: [WIRELESS-LAN] WPA3/OWE as campus solution?



One more for you all- anyone contemplating ditching 802.1X for the BYOD side of 
your WLAN (not managed laptops and “business” clients) and simplifying with 
OWE/WPA3? Like… the open network that’s actually moderately secure leveraging 
the latest security options?



Thanks,



Lee Badman | Network Architect (CWNE#200)

Information Technology Services
(NDD Group)
206 Machinery Hall
120 Smith Drive
Syracuse, New York 13244

t 315.443.3003   e lhbad...@syr.edu<mailto:lhbad...@syr.edu> w its.syr.edu

Campus Wireless Policy: 
https://answers.syr.edu/display/network/Wireless+Network+and+Systems<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fanswers.syr.edu%2Fdisplay%2Fnetwork%2FWireless%2BNetwork%2Band%2BSystems=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C27dfc8f182a44aed4cd308d900e27165%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637541794836889399%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=8NCkz0FedufnGUcZpDDnCmeI4Gx4Exz%2ByaIUHso5OJc%3D=0>

SYRACUSE UNIVERSITY
syr.edu



**
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=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C27dfc8f182a44aed4cd308d900e27165%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637541794836889399%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=AAVmLXrmI9B4sTKHA1yhsOSbNDYDYUz2GHUw71tade8%3D=0>

**
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=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C27dfc8f182a44aed4cd308d900e27165%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637541794836899358%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=LphZNCklAUFdRTZegyIdubuk1%2FVGBGgRvpZ1jsRAvpA%3D=0>

**
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/c

Re: WPA3/OWE as campus solution?

[Tim Cappalli]

Just keep in mind that OWE does not have an identity layer.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Lee H Badman 
<00db5b77bd95-dmarc-requ...@listserv.educause.edu>
Sent: Friday, April 16, 2021 10:08
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: [WIRELESS-LAN] WPA3/OWE as campus solution?


One more for you all- anyone contemplating ditching 802.1X for the BYOD side of 
your WLAN (not managed laptops and “business” clients) and simplifying with 
OWE/WPA3? Like… the open network that’s actually moderately secure leveraging 
the latest security options?



Thanks,



Lee Badman | Network Architect (CWNE#200)

Information Technology Services
(NDD Group)
206 Machinery Hall
120 Smith Drive
Syracuse, New York 13244

t 315.443.3003   e lhbad...@syr.edu w its.syr.edu

Campus Wireless Policy: 
https://answers.syr.edu/display/network/Wireless+Network+and+Systems

SYRACUSE UNIVERSITY
syr.edu



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

Re: [WIRELESS-LAN] Microsoft Windows 10 CRL Check on 802.1x Authentication

[Tim Cappalli]

RE OCSP: AFAIK, only Android 11+ supports OCSP stapling for EAP.

RE OP: Pratik, I reached out to the Windows team and they are diagnosing the 
issue to try to pinpoint when this occurs.

tim



From: The EDUCAUSE Wireless Issues Community Group Listserv on behalf of 
Jonathan Waldrep
Sent: Wednesday, April 14, 2021 10:33
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Microsoft Windows 10 CRL Check on 802.1x 
Authentication

On 2021-04-13 21:20:32+, Pratik Mehta wrote:
> [...]
> The problem is that Windows attempts to perform a CRL check on the
> RADIUS server certificate during the TLS handshake and before 802.1x
> authentication is complete. This causes the EAP session to timeout and
> wireless connectivity to take a long time to be established (more than
> 25 seconds). It does not make sense for the supplicant to perform a
> CRL check before wireless connectivity
> is established.
> [...]

 I can't speak to the specifics of the situation, but in general, the
solution is to use OCSP stapling instead of a CRL check.

 The gist of OCSP stapling is the server contacts the CA/OCSP server to
get a token that asserts the cert has not been revoked, and sends that
with the cert to the client. This allows the client to verify the
server's cert hasn't been revoked without having to connect another
network resource. I've probably got the details there wrong, but that is
the _idea_ of what is happening.

 Implementing OCSP stapling on your authentication servers may bypass
the bug.

 Full disclosure: we haven't gotten around to implementing this
ourselves yet, so there may well be dragons ahead that I am completely
unaware of.

--
Jonathan Waldrep
Network Engineer
Network Infrastructure and Services
Virginia Tech

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

Re: [WIRELESS-LAN] [EXT] Re: [WIRELESS-LAN] Android 11 Manual Profile Configuration Variable

[Tim Cappalli]

I didn’t forget  Been a busy few weeks. Will hopefully have something early 
next week.

tim

From: Tim Cappalli 
Date: Thursday, February 11, 2021 at 10:47
To: The EDUCAUSE Wireless Issues Community Group Listserv 

Subject: Re: [WIRELESS-LAN] [EXT] Re: [WIRELESS-LAN] Android 11 Manual Profile 
Configuration Variable
Yes, the CN must always be a SAN entry.

If folks think it would be useful, I can put together a blog post on this over 
the weekend that puts all of the information in one spot.

If you think this would be useful, go here and submit  “Yes”: 
https://forms.office.com/r/QFNX1q-8f1

(trying to avoid tons of reply alls)

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of McClintic, Thomas 

Date: Thursday, February 11, 2021 at 10:42
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] [EXT] Re: [WIRELESS-LAN] Android 11 Manual Profile 
Configuration Variable
Am I understanding correctly that if the CN also exists as a SAN then it is 
accepted?

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Tim Cappalli
Sent: Thursday, February 11, 2021 9:20 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] [EXT] Re: [WIRELESS-LAN] Android 11 Manual Profile 
Configuration Variable


 EXTERNAL EMAIL 
Yes, the EAP server certificate subject should be the same eTLD as the 
credential realm.

Said differently, if EAP identity is 
`t...@capptoso.com<mailto:t...@capptoso.com>`, the server certificate should be 
`.capptoso.com`.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Jethro R Binks 
mailto:jethro.bi...@strath.ac.uk>>
Date: Thursday, February 11, 2021 at 10:15
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] [EXT] Re: [WIRELESS-LAN] Android 11 Manual Profile 
Configuration Variable
Can I drill into this a bit please just be clear on my understanding?

On Thu, 11 Feb 2021, Sweetser, Frank E. wrote:

> "The STA is configured with EAP credentials that explicitly specify a CA
> root certificate that matches the root certificate in the received
> Server Certificate message and, if the EAP credentials also include a
> domain name (FQDN or suffix-only), it matches the domain name
> (SubjectAltName dNSName if present, otherwise SubjectName CN) of the
> certificate [2] in the received Server Certificate message."
>
> In particular, note the bit about SAN if present, otherwise CN.  A
> strict reading of this (which Android appears to follow) means that
> unlike the web browser behavior we're all used to, if there is a dNSName
> in the SAN list, then the CN will not be evaluated in matching the
> client configured domain.  This means that if you have:
>
>
>   *   A client configured domain of myorg.edu
>   *   A server CN of radius.myorg.edu
>   *   A server SAN of radius.myotherorg.edu

Particularly, "EAP credential domain name", as contrasted with the
"Domain" setting in the client discussed earlier.

My understanding is that the "Domain" setting in the client is telling the
client "the radius server must present a certificate with this
subjectAltName/CN".  Equivalent to the Validate server connection /
Connect to these servers settings seen elsewhere?

But "EAP credential domain name" to me means the credentials one provides
to authenticate as, so usern...@myorg.edu<mailto:usern...@myorg.edu> say.

Is this saying that the server cert subjectAltName/CN must be "myorg.edu"?
That's not what the common case is now I would say; most radius server
certs would likely carry a name "aaa.myorg.org", "radius.myorg.org" or
somesuch.

Do I misunderstand "EAP credentials also include a domain name (FQDN or
suffix-only)" ??

Reading the document a bit more, "EAP credentials" seems to be a broader
phrase equated to "network profile" (see 5.3.1), so perhaps means "the
bundle of settings including login credentials and Domain of radius server
for validation", so "EAP credential domain name" is referring to the
Domain (for cert validation) ie "radius.myorg.org", not any domain part of
the login credentials ie "myorg.org"?  Is that a correct reading?

Jethro.

.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
Jethro R Binks, Network Manager,
Information Services Directorate, University Of Strathclyde, Glasgow, UK

The University of Strathclyde is a charitable body, registered in
Scotland, number SC015263.

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

Re: [WIRELESS-LAN] [EXT] Re: [WIRELESS-LAN] Android 11 Manual Profile Configuration Variable

[Tim Cappalli]

There is some ambiguity on this topic (EAP identity realm matching to EAP 
server identity) and I’m trying to get some clarity so for the time being, 
ignore my comment about requiring the same domain in the cert (it is definitely 
a best practice but it may not be required).

I will include this as part of the blog.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Jethro R Binks 

Date: Thursday, February 11, 2021 at 13:17
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] [EXT] Re: [WIRELESS-LAN] Android 11 Manual Profile 
Configuration Variable
On Thu, 11 Feb 2021, Tim Cappalli wrote:

> Yes, the EAP server certificate subject should be the same eTLD as the
> credential realm.

I should have used the word realm for clarity sorry, I couldn't quite
bring it to mind!

> Said differently, if EAP identity is
> `t...@capptoso.com<mailto:t...@capptoso.com>`, the server certificate
> should be `.capptoso.com`.

Right, so not absolutely identically, but the same parent domain?

Hmm.  As an organisation, I might issue credentials to some...@myorg.org,
someone...@subdomin.myorg.org, and some...@anotherrelatedorg.org, but all
be authenticated by radius.myorg.org.  How does that square?  In that
circumstance I have to add more subjectAltNames in my certificate?  And
know in advance what they are, or keep re-issuing the cert as I add more?
This seems ... undesirable.

As long as the radius server issues the certificate that the client is
programme to expect, I'm not sure why there should be a mandate for a
match with the EAP realm.

Jethro.


>
> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>  on behalf of Jethro R Binks 
> 
> Date: Thursday, February 11, 2021 at 10:15
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
> Subject: Re: [WIRELESS-LAN] [EXT] Re: [WIRELESS-LAN] Android 11 Manual 
> Profile Configuration Variable
> Can I drill into this a bit please just be clear on my understanding?
>
> On Thu, 11 Feb 2021, Sweetser, Frank E. wrote:
>
> > "The STA is configured with EAP credentials that explicitly specify a CA
> > root certificate that matches the root certificate in the received
> > Server Certificate message and, if the EAP credentials also include a
> > domain name (FQDN or suffix-only), it matches the domain name
> > (SubjectAltName dNSName if present, otherwise SubjectName CN) of the
> > certificate [2] in the received Server Certificate message."
> >
> > In particular, note the bit about SAN if present, otherwise CN.  A
> > strict reading of this (which Android appears to follow) means that
> > unlike the web browser behavior we're all used to, if there is a dNSName
> > in the SAN list, then the CN will not be evaluated in matching the
> > client configured domain.  This means that if you have:
> >
> >
> >   *   A client configured domain of myorg.edu
> >   *   A server CN of radius.myorg.edu
> >   *   A server SAN of radius.myotherorg.edu
>
> Particularly, "EAP credential domain name", as contrasted with the
> "Domain" setting in the client discussed earlier.
>
> My understanding is that the "Domain" setting in the client is telling the
> client "the radius server must present a certificate with this
> subjectAltName/CN".  Equivalent to the Validate server connection /
> Connect to these servers settings seen elsewhere?
>
> But "EAP credential domain name" to me means the credentials one provides
> to authenticate as, so usern...@myorg.edu say.
>
> Is this saying that the server cert subjectAltName/CN must be "myorg.edu"?
> That's not what the common case is now I would say; most radius server
> certs would likely carry a name "aaa.myorg.org", "radius.myorg.org" or
> somesuch.
>
> Do I misunderstand "EAP credentials also include a domain name (FQDN or
> suffix-only)" ??
>
> Reading the document a bit more, "EAP credentials" seems to be a broader
> phrase equated to "network profile" (see 5.3.1), so perhaps means "the
> bundle of settings including login credentials and Domain of radius server
> for validation", so "EAP credential domain name" is referring to the
> Domain (for cert validation) ie "radius.myorg.org", not any domain part of
> the login credentials ie "myorg.org"?  Is that a correct reading?
>
> Jethro.
>
> .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
> Jethro R Binks, Network Manager,
> Information Services Directorate, University Of Strathclyde, Glasgow, UK
>
> The University of Strathclyde is a charitable body, registered in
> Scotland, number SC015263.
>
> **

Re: [WIRELESS-LAN] [EXT] Re: [WIRELESS-LAN] Android 11 Manual Profile Configuration Variable

[Tim Cappalli]

No. EAP server trust is between the client and home infrastructure.


From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Matthew Craig 

Date: Thursday, February 11, 2021 at 14:01
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] [EXT] Re: [WIRELESS-LAN] Android 11 Manual Profile 
Configuration Variable
Does all this have any consequences for “traveling” eduroam clients?


Elaboration:

Location: home at 
myorg.edu<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmyorg.edu%2F=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7Cbc753c2b5c2e49a20e2a08d8cebf4c5a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637486668945396583%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=ycvBnndtOUqpb17Ze4XCmt92wyv%2FU2YkNcZlIGM%2Bcy0%3D=0>
ssid: eduroam
username: profess...@myorg.edu<mailto:profess...@myorg.edu>
Professor X’s supplicant config: Domain = 
myorg.edu<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmyorg.edu%2F=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7Cbc753c2b5c2e49a20e2a08d8cebf4c5a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637486668945406573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=qn%2F0nuT2wr01A8NLMmB6YImxLiSi0BUdzv3j3SqOPjY%3D=0>
my radius server: 
radius.myorg.edu<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fradius.myorg.edu%2F=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7Cbc753c2b5c2e49a20e2a08d8cebf4c5a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637486668945416573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=pERIS2NqJW91ULkFoDtJyqjMi5LzcjO9mOyp9%2BPh6O0%3D=0>




Professor X travels to 
otherorg.edu<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fotherorg.edu%2F=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7Cbc753c2b5c2e49a20e2a08d8cebf4c5a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637486668945416573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=xZ4kaMvGq5fbamnZZCA1sY2Il9LMyriVQiM%2F5wV3rfI%3D=0>:

Location: traveling at 
otherorg.edu<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fotherorg.edu%2F=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7Cbc753c2b5c2e49a20e2a08d8cebf4c5a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637486668945426564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=nt9fVLbQDNeA1g6qYInoUgSWbPFiYgQTf8NLN9Iw7tc%3D=0>
ssid: eduroam
username: profess...@myorg.edu<mailto:profess...@myorg.edu>
Professor X’s supplicant config: Domain = 
myorg.edu<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmyorg.edu%2F=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7Cbc753c2b5c2e49a20e2a08d8cebf4c5a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637486668945426564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=1k9fH4i%2F66EN2ZcC0dFO91N%2Fpw7K2C2RV2uGrJpLu5I%3D=0>
otherorg radius server: 
aaa.otherorg.edu<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Faaa.otherorg.edu%2F=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7Cbc753c2b5c2e49a20e2a08d8cebf4c5a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637486668945436557%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=GBn2o2J5E9HrbMB0IxUdnUhZxB746TAGtQteG9pp78E%3D=0>



Does this not break?

What do?



-
Matt Craig
Network Engineer
Information and Communication Technologies
New Mexico State University








On Feb 11, 2021, at 8:19 AM, Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu<mailto:0194c9ecac40-dmarc-requ...@listserv.educause.edu>>
 wrote:

WARNING: This email originated external to the NMSU email system. Do not click 
on links or open attachments unless you are sure the content is safe.
Yes, the EAP server certificate subject should be the same eTLD as the 
credential realm.

Said differently, if EAP identity is 
`t...@capptoso.com<mailto:t...@capptoso.com>`, the server certificate should be 
`.capptoso.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcapptoso.com%2F=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7Cbc753c2b5c2e49a20e2a08d8cebf4c5a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637486668945436557%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=03kpdg2WtdCWUKvK6ltv5NcbXoEpq6O%2BOmS8ktlE4JQ%3D=0>`.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Jethro R Binks 
mailto:jethro.bi...@strath.ac.uk>>
Date: Thursday, February 11, 2021 at 10:15
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] [EXT] R

Re: [WIRELESS-LAN] [EXT] Re: [WIRELESS-LAN] Android 11 Manual Profile Configuration Variable

[Tim Cappalli]

Yes, the CN must always be a SAN entry.

If folks think it would be useful, I can put together a blog post on this over 
the weekend that puts all of the information in one spot.

If you think this would be useful, go here and submit  “Yes”: 
https://forms.office.com/r/QFNX1q-8f1

(trying to avoid tons of reply alls)

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of McClintic, Thomas 

Date: Thursday, February 11, 2021 at 10:42
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] [EXT] Re: [WIRELESS-LAN] Android 11 Manual Profile 
Configuration Variable
Am I understanding correctly that if the CN also exists as a SAN then it is 
accepted?

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Tim Cappalli
Sent: Thursday, February 11, 2021 9:20 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] [EXT] Re: [WIRELESS-LAN] Android 11 Manual Profile 
Configuration Variable


 EXTERNAL EMAIL 
Yes, the EAP server certificate subject should be the same eTLD as the 
credential realm.

Said differently, if EAP identity is 
`t...@capptoso.com<mailto:t...@capptoso.com>`, the server certificate should be 
`.capptoso.com`.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Jethro R Binks 
mailto:jethro.bi...@strath.ac.uk>>
Date: Thursday, February 11, 2021 at 10:15
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] [EXT] Re: [WIRELESS-LAN] Android 11 Manual Profile 
Configuration Variable
Can I drill into this a bit please just be clear on my understanding?

On Thu, 11 Feb 2021, Sweetser, Frank E. wrote:

> "The STA is configured with EAP credentials that explicitly specify a CA
> root certificate that matches the root certificate in the received
> Server Certificate message and, if the EAP credentials also include a
> domain name (FQDN or suffix-only), it matches the domain name
> (SubjectAltName dNSName if present, otherwise SubjectName CN) of the
> certificate [2] in the received Server Certificate message."
>
> In particular, note the bit about SAN if present, otherwise CN.  A
> strict reading of this (which Android appears to follow) means that
> unlike the web browser behavior we're all used to, if there is a dNSName
> in the SAN list, then the CN will not be evaluated in matching the
> client configured domain.  This means that if you have:
>
>
>   *   A client configured domain of myorg.edu
>   *   A server CN of radius.myorg.edu
>   *   A server SAN of radius.myotherorg.edu

Particularly, "EAP credential domain name", as contrasted with the
"Domain" setting in the client discussed earlier.

My understanding is that the "Domain" setting in the client is telling the
client "the radius server must present a certificate with this
subjectAltName/CN".  Equivalent to the Validate server connection /
Connect to these servers settings seen elsewhere?

But "EAP credential domain name" to me means the credentials one provides
to authenticate as, so usern...@myorg.edu<mailto:usern...@myorg.edu> say.

Is this saying that the server cert subjectAltName/CN must be "myorg.edu"?
That's not what the common case is now I would say; most radius server
certs would likely carry a name "aaa.myorg.org", "radius.myorg.org" or
somesuch.

Do I misunderstand "EAP credentials also include a domain name (FQDN or
suffix-only)" ??

Reading the document a bit more, "EAP credentials" seems to be a broader
phrase equated to "network profile" (see 5.3.1), so perhaps means "the
bundle of settings including login credentials and Domain of radius server
for validation", so "EAP credential domain name" is referring to the
Domain (for cert validation) ie "radius.myorg.org", not any domain part of
the login credentials ie "myorg.org"?  Is that a correct reading?

Jethro.

.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
Jethro R Binks, Network Manager,
Information Services Directorate, University Of Strathclyde, Glasgow, UK

The University of Strathclyde is a charitable body, registered in
Scotland, number SC015263.

**
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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunitydata=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C3597488f334c4c6fed8f08d8ce9fd805%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6

Re: [WIRELESS-LAN] [EXT] Re: [WIRELESS-LAN] Android 11 Manual Profile Configuration Variable

[Tim Cappalli]

Yes, the EAP server certificate subject should be the same eTLD as the 
credential realm.

Said differently, if EAP identity is 
`t...@capptoso.com`, the server certificate should be 
`.capptoso.com`.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Jethro R Binks 

Date: Thursday, February 11, 2021 at 10:15
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] [EXT] Re: [WIRELESS-LAN] Android 11 Manual Profile 
Configuration Variable
Can I drill into this a bit please just be clear on my understanding?

On Thu, 11 Feb 2021, Sweetser, Frank E. wrote:

> "The STA is configured with EAP credentials that explicitly specify a CA
> root certificate that matches the root certificate in the received
> Server Certificate message and, if the EAP credentials also include a
> domain name (FQDN or suffix-only), it matches the domain name
> (SubjectAltName dNSName if present, otherwise SubjectName CN) of the
> certificate [2] in the received Server Certificate message."
>
> In particular, note the bit about SAN if present, otherwise CN.  A
> strict reading of this (which Android appears to follow) means that
> unlike the web browser behavior we're all used to, if there is a dNSName
> in the SAN list, then the CN will not be evaluated in matching the
> client configured domain.  This means that if you have:
>
>
>   *   A client configured domain of myorg.edu
>   *   A server CN of radius.myorg.edu
>   *   A server SAN of radius.myotherorg.edu

Particularly, "EAP credential domain name", as contrasted with the
"Domain" setting in the client discussed earlier.

My understanding is that the "Domain" setting in the client is telling the
client "the radius server must present a certificate with this
subjectAltName/CN".  Equivalent to the Validate server connection /
Connect to these servers settings seen elsewhere?

But "EAP credential domain name" to me means the credentials one provides
to authenticate as, so usern...@myorg.edu say.

Is this saying that the server cert subjectAltName/CN must be "myorg.edu"?
That's not what the common case is now I would say; most radius server
certs would likely carry a name "aaa.myorg.org", "radius.myorg.org" or
somesuch.

Do I misunderstand "EAP credentials also include a domain name (FQDN or
suffix-only)" ??

Reading the document a bit more, "EAP credentials" seems to be a broader
phrase equated to "network profile" (see 5.3.1), so perhaps means "the
bundle of settings including login credentials and Domain of radius server
for validation", so "EAP credential domain name" is referring to the
Domain (for cert validation) ie "radius.myorg.org", not any domain part of
the login credentials ie "myorg.org"?  Is that a correct reading?

Jethro.

.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
Jethro R Binks, Network Manager,
Information Services Directorate, University Of Strathclyde, Glasgow, UK

The University of Strathclyde is a charitable body, registered in
Scotland, number SC015263.

**
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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunitydata=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C3597488f334c4c6fed8f08d8ce9fd805%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637486533221740806%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=7fwWkkx3Vp7v%2F1soXjoGx5NF1m0%2FRyr%2B7Jndtzfc7sg%3Dreserved=0

**
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] [EXT] Re: [WIRELESS-LAN] Android 11 Manual Profile Configuration Variable

[Tim Cappalli]

“means that unlike the web browser behavior we’re all used to, if there is a 
dNSName in the SAN list, then the CN will not be evaluated in matching the 
client configured domain”

This is how browsers work as well. The TLS spec for X.509 validation requires 
that you ignore the CN when SANs are present.

This should never be a problem for EAP as your EAP server certificate should 
only ever have one subject.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Sweetser, Frank E. 

Date: Thursday, February 11, 2021 at 08:36
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] [EXT] Re: [WIRELESS-LAN] Android 11 Manual Profile 
Configuration Variable
I just wanted to chime in with one more catch that we hit on Android.  The WPA3 
spec contains this language on comparing the client configured domain against 
the name of the server certificate:

“The STA is configured with EAP credentials that explicitly specify a CA root 
certificate that matches the root certificate in the received Server 
Certificate message and, if the EAP credentials also include a domain name 
(FQDN or suffix-only), it matches the domain name (SubjectAltName dNSName if 
present, otherwise SubjectName CN) of the certificate [2] in the received 
Server Certificate message.”

(From 
https://www.wi-fi.org/download.php?file=/sites/default/files/private/WPA3_Specification_v3.0.pdf<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.wi-fi.org%2Fdownload.php%3Ffile%3D%2Fsites%2Fdefault%2Ffiles%2Fprivate%2FWPA3_Specification_v3.0.pdf=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C6b0c7d1526f54fb0710a08d8ce91e5ed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637486473921524732%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=dvAXQcUZTgzthCCeslfxvbyiaKQcFnPq6dC0F24RZsY%3D=0>
 section 5.1, condition 2)

In particular, note the bit about SAN if present, otherwise CN.  A strict 
reading of this (which Android appears to follow) means that unlike the web 
browser behavior we’re all used to, if there is a dNSName in the SAN list, then 
the CN will not be evaluated in matching the client configured domain.  This 
means that if you have:


  *   A client configured domain of myorg.edu
  *   A server CN of radius.myorg.edu
  *   A server SAN of radius.myotherorg.edu

Then the client will reject the server certificate because the client domain 
does not match the SAN.  Resulting behavior includes going into a rapid retry 
loop, various error codes returned to the RADIUS server, and in some cases, 
going so far as to silently delete the certificate from the credential store.

So far we’ve only seen this on Pixels (including Pixel 2), but as it’s in the 
WPA3 spec I would assume we’ll see  similar behavior come to more operating 
systems, though hopefully with better error logging…

Frank Sweetser
Director of Network Operations
Worcester Polytechnic Institute
"For every problem, there is a solution that is simple, elegant, and wrong." - 
HL Mencken

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Floyd, Brad
Sent: Wednesday, February 10, 2021 5:15 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [EXT] Re: [WIRELESS-LAN] Android 11 Manual Profile Configuration 
Variable

Thanks Tim.
Brad

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Wednesday, February 10, 2021 4:07 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Android 11 Manual Profile Configuration Variable

Yes, the same as all the other platforms.

If the CN of your EAP server certificate is “networklogin.awesomeu.edu” then 
that should be what is configured in the supplicant.

SAN DNS entries could also be used but there should be no need given an EAP 
server certificate does not need multiple names for the most common use cases.

tim

From: Floyd, Brad<mailto:bfl...@mail.smu.edu>
Sent: Wednesday, February 10, 2021 17:03
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Android 11 Manual Profile Configuration Variable

Tim,

So the subject of the EAP server certificate is equal to the FQDN of my RADIUS 
server certificate or of a SAN entry within the server certificate?

Here is a screenshot from Eric’s Glinsky’s previous e-mail where I saw the 
domain variable. I don’t have an Android 11 device handy to test with.

[cid:image001.png@01D6FFC6.4E70EF80]

Thanks,
Brad

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Wednesday, February 10, 2021 3:22 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Android 11 Manual Profile Configuration Variable

Which

RE: Android 11 Manual Profile Configuration Variable

[Tim Cappalli]

Yes, the same as all the other platforms.

If the CN of your EAP server certificate is “networklogin.awesomeu.edu” then 
that should be what is configured in the supplicant. 

SAN DNS entries could also be used but there should be no need given an EAP 
server certificate does not need multiple names for the most common use cases.

tim

From: Floyd, Brad
Sent: Wednesday, February 10, 2021 17:03
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Android 11 Manual Profile Configuration Variable

Tim,

So the subject of the EAP server certificate is equal to the FQDN of my RADIUS 
server certificate or of a SAN entry within the server certificate?

Here is a screenshot from Eric’s Glinsky’s previous e-mail where I saw the 
domain variable. I don’t have an Android 11 device handy to test with.



Thanks,
Brad

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Tim Cappalli
Sent: Wednesday, February 10, 2021 3:22 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Android 11 Manual Profile Configuration Variable

Which profile are you referring to? Android does not have a generic profile 
construct.

Domain refers to the subject of the EAP server certificate (e.g. 
networklogin.mydomain.com) and yes subject matching is required for a proper 
supplicant configuration.

tim



From: Floyd, Brad
Sent: Wednesday, February 10, 2021 16:17
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] Android 11 Manual Profile Configuration Variable

>From the ongoing discussion about Android 11 (Google Pixel) configuration, I 
>see a variable named “Domain” in the profile configuration. I have not seen 
>this variable with previous versions of Android 802.1X profiles. Does this 
>field need to be filled in with this new version? If so, should it be 
>something like: “myuniversity.edu”? if not, what?
Thanks,
Brad

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


smime.p7s
Description: S/MIME cryptographic signature

RE: Android 11 Manual Profile Configuration Variable

[Tim Cappalli]

Which profile are you referring to? Android does not have a generic profile 
construct.

Domain refers to the subject of the EAP server certificate (e.g. 
networklogin.mydomain.com) and yes subject matching is required for a proper 
supplicant configuration.

tim



From: Floyd, Brad
Sent: Wednesday, February 10, 2021 16:17
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] Android 11 Manual Profile Configuration Variable

>From the ongoing discussion about Android 11 (Google Pixel) configuration, I 
>see a variable named “Domain” in the profile configuration. I have not seen 
>this variable with previous versions of Android 802.1X profiles. Does this 
>field need to be filled in with this new version? If so, should it be 
>something like: “myuniversity.edu”? if not, what?
Thanks,
Brad

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


smime.p7s
Description: S/MIME cryptographic signature

RE: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021

[Tim Cappalli]

That’s what I suspected. That is NOT for EAP server trust. It is for 
certificate status. Not the same thing.

If you look at the CA Certificate dropdown (not the Online Certificate Status 
dropdown), you should not see a Do Not Validate option.

tim

From: Walter Reynolds
Sent: Wednesday, February 10, 2021 10:45
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021

Here are the screenshots.







-
Walter Reynolds
Network Architect
Information and Technology Services
University of Michigan
(734) 615-9438


On Wed, Feb 10, 2021 at 6:49 AM Mathieu Sturm  wrote:
I’ve ordered a Pixel 5 and will do some testing as well. 
I’ve been testing with a virtual android 11 on android studio. This virtual 
android 11 also had the option to select “don’t validate” option.
 
I will share my findings once testing has been done.
 
 
Mathieu Sturm
Hoofdmedewerker Netwerkbeheer



Directie Financiën, Infrastructuur en IT
Afdeling Netwerkbeheer
Campus Schoonmeerssen - Gebouw B  Lokaal B0.75
Valentin Vaerwyckweg 1 - 9000 Gent
+32 9 243 35 23
www.hogent.be
 
 
 
Van: The EDUCAUSE Wireless Issues Community Group Listserv 
 Namens Dom Colangelo
Verzonden: dinsdag 9 februari 2021 18:26
Aan: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Onderwerp: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021
 
In my testing I found that networks saved prior to the patch retained the 
‘Don’t validate’ option. Forgetting and re-configuring the network eliminated 
the option.
 
Dom Colangelo
Systems Engineer
Omada Technologies
Cell: (617)-446-3945
dcolang...@omadatechnologies.com
 
From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Tim Cappalli
Sent: Tuesday, February 9, 2021 12:15
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021
 
Screenshot?
 
From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Walter Reynolds 

Date: Tuesday, February 9, 2021 at 12:03
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021


I have a Pixel 3 that I did a factory restet on.  Next I did all the updates 
needed and it is running Android 11.  The build number is RQ1A.210205.004 which 
includes the latest security patch for the phone.
 
When I go to configure a WPA2 Enterprise network I still have the "Don't 
validate" option.  
 
What am I missing here?
 

Walter Reynolds
Network Architect
Information and Technology Services
University of Michigan
(734) 615-9438
 
 
On Sun, Feb 7, 2021 at 3:29 AM Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu> wrote:
I would not expect Pixel 2 and earlier to receive this update as they are end 
of support.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Richie Penuela 

Sent: Friday, February 5, 2021 09:37
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021 
 
Mathieu,
 
Currently this is affecting Google Pixel 3 and up that have installed the 
Android 11 security patch in December. We have Google Pixel 2A w/ Android 11 
but the last security patch was provided prior to the one in December and we 
are still to select “Do not validate” option. In conversation with some of our 
integrators they believe that other Android platforms will follow suit. 
 
-Respectfully,
 

Sr. Wireless Engineer
UCF IT | Telecommunications
University of Central Florida
407.823.4906
richie.penu...@ucf.edu
 
Please note: Florida has a very broad open records law (F.S. 119). Emails may 
be subject to public disclosure
 
 
From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Mathieu Sturm 

Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Friday, February 5, 2021 at 9:32 AM
To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" 
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021
 
Hello all,
 
I’ve been testing with 2 devices (Samsung s10 upgraded to android 11 and 
Samsung s20 also upgraded to android 11).
It seems that I’m still able to select “Do not validate” on these devices. 
 
Is this because these devices were upgraded to android 11 and that the newer 
devices which were released with android 11 don’t allow the “Do not validate”?
Or are the pixel phones the only ones?
 
Regards,
 
Mathieu
 
Van: The EDUCAUSE Wireless Issues Community Group Listserv 
 Namens Hurt,Trenton W.
Verzonden: maandag 1 februari 2021 22:47
Aan: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Onderwerp: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021
 
FYI
 
I just received the following from securew2 about some additional security 
changes coming to android 11.  
 
 
 
This action will need to take place before the upcoming Android application 
update that is planned for February 15th, 2021.
 
As you may already be aware, Google mandates server

RE: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021

[Tim Cappalli]

My thoughts exactly. Sure, I’m curious about the behavior being reported, but 
it really doesn’t matter.


From: Jonathan Waldrep
Sent: Wednesday, February 10, 2021 10:36
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021

 I get the impression people haven't seen this:
https://www.youtube.com/watch?v=gkPvZDcrLFk

 Note this was presented in *2012*. As Tim has said many, many times,
you really should be validating the server, even if you have the option
to not. Thus, whether or not that option is available is kinda
irrelevant.

On 2021-02-10 11:36:36+, Mathieu Sturm wrote:
> I've ordered a Pixel 5 and will do some testing as well.
> I've been testing with a virtual android 11 on android studio. This virtual 
> android 11 also had the option to select "don't validate" option.
> 
> I will share my findings once testing has been done.
> 
> 
> Mathieu Sturm
> Hoofdmedewerker Netwerkbeheer
> 
> [https://www.hogent.be/www/assets/Image/logo2018.png]
> 
> Directie Financiën, Infrastructuur en IT
> Afdeling Netwerkbeheer
> Campus Schoonmeerssen - Gebouw B  Lokaal B0.75
> Valentin Vaerwyckweg 1 - 9000 Gent
> +32 9 243 35 23
> www.hogent.be<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.hogent.be%2F=02%7C01%7Cmathieu.sturm%40hogent.be%7C86879fbc6e8c49ab13ff08d67ac4edef%7C5cf7310e091a4bc5acd726c721d4cccd%7C1%7C0%7C636831383554731873=8NfYjNEE4XDViDT6wMtCYFa0cY8g5CXqS9kf7VtYBcU%3D=0>
> 
> 
> 
> Van: The EDUCAUSE Wireless Issues Community Group Listserv 
>  Namens Dom Colangelo
> Verzonden: dinsdag 9 februari 2021 18:26
> Aan: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Onderwerp: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021
> 
> In my testing I found that networks saved prior to the patch retained the 
> 'Don't validate' option. Forgetting and re-configuring the network eliminated 
> the option.
> 
> [cid:image005.png@01D6FFA9.5BA6C3E0]Dom Colangelo
> Systems Engineer
> Omada Technologies
> Cell: (617)-446-3945
> dcolang...@omadatechnologies.com<mailto:dcolang...@omadatechnologies.com>
> 
> From: The EDUCAUSE Wireless Issues Community Group Listserv 
> mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
>  On Behalf Of Tim Cappalli
> Sent: Tuesday, February 9, 2021 12:15
> To: 
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021
> 
> Screenshot?
> 
> From: The EDUCAUSE Wireless Issues Community Group Listserv 
> mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
>  on behalf of Walter Reynolds mailto:wa...@umich.edu>>
> Date: Tuesday, February 9, 2021 at 12:03
> To: 
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
> mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
> Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021
> 
> I have a Pixel 3 that I did a factory restet on.  Next I did all the updates 
> needed and it is running Android 11.  The build number is RQ1A.210205.004 
> which includes the latest security patch for the phone.
> 
> When I go to configure a WPA2 Enterprise network I still have the "Don't 
> validate" option.
> 
> What am I missing here?
> 
> 
> Walter Reynolds
> Network Architect
> Information and Technology Services
> University of Michigan
> (734) 615-9438
> 
> 
> On Sun, Feb 7, 2021 at 3:29 AM Tim Cappalli 
> <0194c9ecac40-dmarc-requ...@listserv.educause.edu<mailto:0194c9ecac40-dmarc-requ...@listserv.educause.edu>>
>  wrote:
> I would not expect Pixel 2 and earlier to receive this update as they are end 
> of support.
> 
> From: The EDUCAUSE Wireless Issues Community Group Listserv 
> mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
>  on behalf of Richie Penuela 
> mailto:richie.penu...@ucf.edu>>
> Sent: Friday, February 5, 2021 09:37
> To: 
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
> mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
> Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021
> 
> 
> Mathieu,
> 
> 
> 
> Currently this is affecting Google Pixel 3 and up that have installed the 
> Android 11 security patch in December. We have Google Pixel 2A w/ Android 11 
> but the last security patch was provided prior to the one in December and we 
> are still to select "Do not validate" option. In conversation with some of 
> our integrators they believe that other Android platforms will follow suit.
> 
> 
> 
> -Respectfully,
> 
> 
> 
> [sign

Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021

[Tim Cappalli]

Screenshot?

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Walter Reynolds 

Date: Tuesday, February 9, 2021 at 12:03
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021

I have a Pixel 3 that I did a factory restet on.  Next I did all the updates 
needed and it is running Android 11.  The build number is RQ1A.210205.004 which 
includes the latest security patch for the phone.

When I go to configure a WPA2 Enterprise network I still have the "Don't 
validate" option.

What am I missing here?


Walter Reynolds
Network Architect
Information and Technology Services
University of Michigan
(734) 615-9438


On Sun, Feb 7, 2021 at 3:29 AM Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu<mailto:0194c9ecac40-dmarc-requ...@listserv.educause.edu>>
 wrote:
I would not expect Pixel 2 and earlier to receive this update as they are end 
of support.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Richie Penuela 
mailto:richie.penu...@ucf.edu>>
Sent: Friday, February 5, 2021 09:37
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021


Mathieu,



Currently this is affecting Google Pixel 3 and up that have installed the 
Android 11 security patch in December. We have Google Pixel 2A w/ Android 11 
but the last security patch was provided prior to the one in December and we 
are still to select “Do not validate” option. In conversation with some of our 
integrators they believe that other Android platforms will follow suit.



-Respectfully,



[signature_2043038681]

Sr. Wireless Engineer

UCF IT | Telecommunications

University of Central Florida

407.823.4906

richie.penu...@ucf.edu<mailto:richie.penu...@ucf.edu>



Please note: Florida has a very broad open records law (F.S. 119). Emails may 
be subject to public disclosure





From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Mathieu Sturm 
mailto:mathieu.st...@hogent.be>>
Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, February 5, 2021 at 9:32 AM
To: 
"WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>" 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021



Hello all,



I’ve been testing with 2 devices (Samsung s10 upgraded to android 11 and 
Samsung s20 also upgraded to android 11).

It seems that I’m still able to select “Do not validate” on these devices.



Is this because these devices were upgraded to android 11 and that the newer 
devices which were released with android 11 don’t allow the “Do not validate”?

Or are the pixel phones the only ones?



Regards,



Mathieu



Van: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
Namens Hurt,Trenton W.
Verzonden: maandag 1 februari 2021 22:47
Aan: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Onderwerp: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021



FYI



I just received the following from securew2 about some additional security 
changes coming to android 11.







This action will need to take place before the upcoming Android application 
update that is planned for February 15th, 2021.



As you may already be aware, Google mandates server validation to be properly 
configured for WiFi from Android version 11. This means that any 802.1X WiFi 
configuration without the following two settings will fail to connect.



1.  Server Validation

2.  Connect to these server names



For more information about these configurations, please read below.



What is Server Validation in a Network Profile?

This configuration item is for clients to validate a RADIUS server certificate 
chain during an EAP authentication. Clients would forward its requests only 
when the received server certificate is signed by the CA that is configured on 
the SecureW2 Network Profile.  It may be required to upload only the Root CA of 
the RADIUS server certificate, however, in some cases, the full chain may need 
to be provided.



What is the Connect to these server names field?

This field is used to specify the name of your RADIUS server certificate using 
its Common Name. If there is only one RADIUS server in your setup, you can 
quickly find this name from the certificate. If there are more than one RADIUS 
servers, or if the RADIUS server Common Name has more than two subdomains, we 
advise to use a wildcard 

Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021

[Tim Cappalli]

I would not expect Pixel 2 and earlier to receive this update as they are end 
of support.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Richie Penuela 

Sent: Friday, February 5, 2021 09:37
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021


Mathieu,



Currently this is affecting Google Pixel 3 and up that have installed the 
Android 11 security patch in December. We have Google Pixel 2A w/ Android 11 
but the last security patch was provided prior to the one in December and we 
are still to select “Do not validate” option. In conversation with some of our 
integrators they believe that other Android platforms will follow suit.



-Respectfully,



[signature_2043038681]

Sr. Wireless Engineer

UCF IT | Telecommunications

University of Central Florida

407.823.4906

richie.penu...@ucf.edu



Please note: Florida has a very broad open records law (F.S. 119). Emails may 
be subject to public disclosure





From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Mathieu Sturm 

Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Friday, February 5, 2021 at 9:32 AM
To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" 
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021



Hello all,



I’ve been testing with 2 devices (Samsung s10 upgraded to android 11 and 
Samsung s20 also upgraded to android 11).

It seems that I’m still able to select “Do not validate” on these devices.



Is this because these devices were upgraded to android 11 and that the newer 
devices which were released with android 11 don’t allow the “Do not validate”?

Or are the pixel phones the only ones?



Regards,



Mathieu



Van: The EDUCAUSE Wireless Issues Community Group Listserv 
 Namens Hurt,Trenton W.
Verzonden: maandag 1 februari 2021 22:47
Aan: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Onderwerp: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021



FYI



I just received the following from securew2 about some additional security 
changes coming to android 11.







This action will need to take place before the upcoming Android application 
update that is planned for February 15th, 2021.



As you may already be aware, Google mandates server validation to be properly 
configured for WiFi from Android version 11. This means that any 802.1X WiFi 
configuration without the following two settings will fail to connect.



1.  Server Validation

2.  Connect to these server names



For more information about these configurations, please read below.



What is Server Validation in a Network Profile?

This configuration item is for clients to validate a RADIUS server certificate 
chain during an EAP authentication. Clients would forward its requests only 
when the received server certificate is signed by the CA that is configured on 
the SecureW2 Network Profile.  It may be required to upload only the Root CA of 
the RADIUS server certificate, however, in some cases, the full chain may need 
to be provided.



What is the Connect to these server names field?

This field is used to specify the name of your RADIUS server certificate using 
its Common Name. If there is only one RADIUS server in your setup, you can 
quickly find this name from the certificate. If there are more than one RADIUS 
servers, or if the RADIUS server Common Name has more than two subdomains, we 
advise to use a wildcard name.



For example:

If the RADIUS server certificate’s Common Name = radius.domain.com Connect to 
these server names should be radius.domain.com



If the RADIUS server certificate’s Common Name = 
radius.lab.department.domain.com Connect to these server names should be 
*.department.domain.com or *.domain.com









Thanks

Trent



Trenton Hurt, CWNE #172,ACMP,ACCP,CCNP(W),CCNA(W),CCNA(V),CCNA(R/S)

Network Analyst

University of Louisville

Phone (502) 852-1513



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

Re: android 11 upcoming changes Feb 15th 2021

[Tim Cappalli]

Samsung has likely not yet picked up the change. Google Pixels are currently 
the only devices confirmed to have received the update.

The change will eventually hit all devices.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Mathieu Sturm 

Sent: Friday, February 5, 2021 09:32
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021


Hello all,



I’ve been testing with 2 devices (Samsung s10 upgraded to android 11 and 
Samsung s20 also upgraded to android 11).

It seems that I’m still able to select “Do not validate” on these devices.



Is this because these devices were upgraded to android 11 and that the newer 
devices which were released with android 11 don’t allow the “Do not validate”?

Or are the pixel phones the only ones?



Regards,



Mathieu



Van: The EDUCAUSE Wireless Issues Community Group Listserv 
 Namens Hurt,Trenton W.
Verzonden: maandag 1 februari 2021 22:47
Aan: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Onderwerp: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021



FYI



I just received the following from securew2 about some additional security 
changes coming to android 11.







This action will need to take place before the upcoming Android application 
update that is planned for February 15th, 2021.



As you may already be aware, Google mandates server validation to be properly 
configured for WiFi from Android version 11. This means that any 802.1X WiFi 
configuration without the following two settings will fail to connect.



1.  Server Validation

2.  Connect to these server names



For more information about these configurations, please read below.



What is Server Validation in a Network Profile?

This configuration item is for clients to validate a RADIUS server certificate 
chain during an EAP authentication. Clients would forward its requests only 
when the received server certificate is signed by the CA that is configured on 
the SecureW2 Network Profile.  It may be required to upload only the Root CA of 
the RADIUS server certificate, however, in some cases, the full chain may need 
to be provided.



What is the Connect to these server names field?

This field is used to specify the name of your RADIUS server certificate using 
its Common Name. If there is only one RADIUS server in your setup, you can 
quickly find this name from the certificate. If there are more than one RADIUS 
servers, or if the RADIUS server Common Name has more than two subdomains, we 
advise to use a wildcard name.



For example:

If the RADIUS server certificate’s Common Name = radius.domain.com Connect to 
these server names should be radius.domain.com



If the RADIUS server certificate’s Common Name = 
radius.lab.department.domain.com Connect to these server names should be 
*.department.domain.com or *.domain.com









Thanks

Trent



Trenton Hurt, CWNE #172,ACMP,ACCP,CCNP(W),CCNA(W),CCNA(V),CCNA(R/S)

Network Analyst

University of Louisville

Phone (502) 852-1513



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

**
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: android 11 upcoming changes Feb 15th 2021

[Tim Cappalli]

100% agree and I've been preaching that for years, but there are many folks who 
have shared opinions that user experience is more important than credential 
security.

And a slightly tangential but still very related topic: what are you going to 
do when users no longer have passwords? It's coming sooner than you may think. 
Kill two birds with one stone and ditch passwords while improving user 
experience for network access as soon as possible.

We should probably fork this topic to a new thread or even maybe have an ad hoc 
virtual meeting on this topic! Every single (quarterly) thread about EAP server 
certificates and supplicant config ends with us drifting off course.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Enfield, Chuck 

Sent: Wednesday, February 3, 2021 16:56
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021


I know I’m singing to the choir when responding to you two, but it’s worth 
reminding readers that the main risk here isn’t to the network.  It’s to the 
user’s account credentials.  I’m pretty sure we think that’s important in 
higher ed too.



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Tim Cappalli
Sent: Wednesday, February 3, 2021 4:31 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021



For higher ed, you're absolutely right. For all other enterprise use cases, 
credential security is super important.



Unfortunately a network supplicant is not aware of the deployment type and 
can't adapt.



tim



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Jennifer Minella 

Sent: Wednesday, February 3, 2021 16:26
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021



There’s a fine, grey line between optimal security and usability ??



___

Jennifer Minella, CISSP, HP MASE

VP of Engineering & Security

Carolina Advanced Digital, Inc.

www.cadinc.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cadinc.com%2F=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7Ce1e200a7f6454ba8019a08d8c88e9664%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637479862044506917%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=2B%2FVwTZYxxAEX8XpzF246DB%2FN3L7VSxIvGcAZZv6XIY%3D=0>

j...@cadinc.com<mailto:j...@cadinc.com>

919.460.1313 Main Office

919.539.2726 Mobile/text

[CAD LOGO EMAIL SIG]



From: Tim Cappalli 
Sent: Monday, February 1, 2021 5:53 PM
Subject: Re: android 11 upcoming changes Feb 15th 2021



Jennifer, this has been extensively discussed on this list for the past few 
months which I why I said that nothing has changed since those conversations. 
This current thread makes it seem like more changes are coming in Android on 
February 15th which is NOT the case. There have been no changes since the 
December update and I'm not aware of any other changes in the Android 11 code 
train.



RE: Apple already does this: Android is the only operating system that requires 
a properly configured supplicant. Apple's TOFU model does not result in a 
proper configuration.



RE: wildcard, from the bottom of the message:



For example:

If the RADIUS server certificate’s Common Name = radius.domain.com Connect to 
these server names should be radius.domain.com



If the RADIUS server certificate’s Common Name = 
radius.lab.department.domain.com Connect to these server names should be 
*.department.domain.com or *.domain.com



They're recommending wildcard subject name matching if the environment uses a 
non-standard configuration. This is poor guidance and will result in credential 
compromise via MitM.



tim



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Jennifer Minella mailto:j...@cadinc.com>>
Sent: Monday, February 1, 2021 17:25
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021



I may disagree with some of the other feedback here…  I think this is a big 
deal.



It sounds like Google will be enforcing proper server validation for 
802.1X-secured networks, based on what Trent sent originally. I believe Apple 
already has been enforcing this for a bit.



If my guess is correct (I’ll try to find a link) then what it means is – after 
this update, you can’t tell the endpoint to ignore or bypass the server 
certificate for 802.1X (any EAP method).



The impact of this is…

  *   If you’re organization has any endpoints that have been configured to use 
a secured network but are ignoring the server’s certificate

Re: android 11 upcoming changes Feb 15th 2021

[Tim Cappalli]

For higher ed, you're absolutely right. For all other enterprise use cases, 
credential security is super important.

Unfortunately a network supplicant is not aware of the deployment type and 
can't adapt.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Jennifer Minella 

Sent: Wednesday, February 3, 2021 16:26
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021


There’s a fine, grey line between optimal security and usability 



___

Jennifer Minella, CISSP, HP MASE

VP of Engineering & Security

Carolina Advanced Digital, Inc.

www.cadinc.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cadinc.com%2F=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C3e27e80119884e09cdc608d8c88aaaca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637479845206817736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=JorC3cCWXiPbiFMzHXbR78kCAU0w4BrNqlhZMp2voZM%3D=0>

j...@cadinc.com<mailto:j...@cadinc.com>

919.460.1313 Main Office

919.539.2726 Mobile/text

[CAD LOGO EMAIL SIG]



From: Tim Cappalli 
Sent: Monday, February 1, 2021 5:53 PM
Subject: Re: android 11 upcoming changes Feb 15th 2021



Jennifer, this has been extensively discussed on this list for the past few 
months which I why I said that nothing has changed since those conversations. 
This current thread makes it seem like more changes are coming in Android on 
February 15th which is NOT the case. There have been no changes since the 
December update and I'm not aware of any other changes in the Android 11 code 
train.



RE: Apple already does this: Android is the only operating system that requires 
a properly configured supplicant. Apple's TOFU model does not result in a 
proper configuration.



RE: wildcard, from the bottom of the message:



For example:

If the RADIUS server certificate’s Common Name = radius.domain.com Connect to 
these server names should be radius.domain.com



If the RADIUS server certificate’s Common Name = 
radius.lab.department.domain.com Connect to these server names should be 
*.department.domain.com or *.domain.com



They're recommending wildcard subject name matching if the environment uses a 
non-standard configuration. This is poor guidance and will result in credential 
compromise via MitM.



tim



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Jennifer Minella mailto:j...@cadinc.com>>
Sent: Monday, February 1, 2021 17:25
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021



I may disagree with some of the other feedback here…  I think this is a big 
deal.



It sounds like Google will be enforcing proper server validation for 
802.1X-secured networks, based on what Trent sent originally. I believe Apple 
already has been enforcing this for a bit.



If my guess is correct (I’ll try to find a link) then what it means is – after 
this update, you can’t tell the endpoint to ignore or bypass the server 
certificate for 802.1X (any EAP method).



The impact of this is…

  *   If you’re organization has any endpoints that have been configured to use 
a secured network but are ignoring the server’s certificate – then that will 
STOP working suddenly at the update.
  *   This setting (ignore/don’t validate server cert) is not ideal but it’s 
prevalent especially for things like BYOD or HED device onboarding, testing, 
etc. It should be fixed but this is one of those things that could have a huge 
widespread impact if the endpoints/networks aren’t configured properly now.
  *   Typically proper settings for secured 1X networks are pushed through GPO, 
MDM, or an onboarding process through vendor tools (can be a server-based tool 
or a client-based config assist tool). If that wasn’t done then the endpoints 
may not have the server certificate installed and trusted, and if that’s the 
case they will just cease to work after the device upgrade.



Tim it’s not referencing a wildcard cert; they’re still using the specific FQDN 
for the COMMON NAME. The article references the connect to domains as a 
different field which is not the certificate CN.. ?



Yeah, here are some links…

·A reddit article I hope is accurate b/c I only skimmed it

https://www.reddit.com/r/networking/comments/j7ero1/psa_android_11s_december_security_update_will/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.reddit.com%2Fr%2Fnetworking%2Fcomments%2Fj7ero1%2Fpsa_android_11s_december_security_update_will%2F=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C3e27e80119884e09cdc608d8c88aaaca%7C72f988bf86f141af91ab2d7cd011

Re: [WIRELESS-LAN] [External] Re: [WIRELESS-LAN] [External] Re: [WIRELESS-LAN] [External] Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021

[Tim Cappalli]

Yeah, I think you're asking for a profile-like configuration mechanism on 
Android which is different than invocation of provisioning. I agree and hope 
there will be some traction in this area in the future.

For the time being though, you could still have a generic QR code that takes 
users to a landing page where you can use UA detection to invoke the correct 
flow, be it a profile download or just instructions.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Hunter Fuller 
<0211f6bc0913-dmarc-requ...@listserv.educause.edu>
Sent: Tuesday, February 2, 2021 13:53
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] [External] Re: [WIRELESS-LAN] [External] Re: 
[WIRELESS-LAN] [External] Re: [WIRELESS-LAN] android 11 upcoming changes Feb 
15th 2021

That's fair, and it's why I included the bit about requiring existing 
connectivity. I think in my mind, if there was a certificate involved, it would 
be downloaded from the Internet once the QR code was scanned. This is similar 
to what you can do with .mobileconfig files on iOS. You do have to find a way 
to get the .mobileconfig file into Safari on the device, but once you do that, 
the configuration process is quite streamlined. An Android equivalent would be 
amazing.

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


On Tue, Feb 2, 2021 at 12:48 PM Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu<mailto:0194c9ecac40-dmarc-requ...@listserv.educause.edu>>
 wrote:
I can scan a QR code with embedded credentials over your shoulder

(I think the newest Galaxy has 100x zoom?)



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Hunter Fuller 
<0211f6bc0913-dmarc-requ...@listserv.educause.edu<mailto:0211f6bc0913-dmarc-requ...@listserv.educause.edu>>
Sent: Tuesday, February 2, 2021 13:45
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] [External] Re: [WIRELESS-LAN] [External] Re: 
[WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021

I don't follow how sending someone configuration via a QR code on our website, 
would have a different trust profile from showing instructions on that same 
website, or sending them to eduroam CAT from that website.

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


On Tue, Feb 2, 2021 at 12:43 PM Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu<mailto:0194c9ecac40-dmarc-requ...@listserv.educause.edu>>
 wrote:
While UX is great with QR codes, security and trust is challenging.

You'll start to see more QR-based provisioning with IoT as part of Wi-Fi Easy 
Connect but those have other security layers baked on top.





From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Hunter Fuller 
<0211f6bc0913-dmarc-requ...@listserv.educause.edu<mailto:0211f6bc0913-dmarc-requ...@listserv.educause.edu>>
Sent: Tuesday, February 2, 2021 13:41
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] [External] Re: [WIRELESS-LAN] android 11 upcoming 
changes Feb 15th 2021

I wish there was a QR schema. Even if it only worked on devices with another 
connection available (LTE, etc.) to download the config. Sigh.

The closest we have right now is scanning a QR code leading to a .mobileconfig 
file on iOS.

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


On Tue, Feb 2, 2021 at 12:29 PM Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu<mailto:0194c9ecac40-dmarc-requ...@listserv.educause.edu>>
 wrote:
Well, again, you should be properly configuring the supplicant regardless, so 
the instructions would apply to any version of Android

RE: QR, no, enterprise authentication is not supported. A supplicant 
configuration tool should always be used. The supplicant was not designed to be 
manually configured by end users (on any OS).



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Michael Holden 
mailto:mhol...@datanetworksolutions.com>>
Sent: Tuesday, February 2, 2021 13:16
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LA

Re: [WIRELESS-LAN] [External] Re: [WIRELESS-LAN] [External] Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021

[Tim Cappalli]

I can scan a QR code with embedded credentials over your shoulder

(I think the newest Galaxy has 100x zoom?)



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Hunter Fuller 
<0211f6bc0913-dmarc-requ...@listserv.educause.edu>
Sent: Tuesday, February 2, 2021 13:45
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] [External] Re: [WIRELESS-LAN] [External] Re: 
[WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021

I don't follow how sending someone configuration via a QR code on our website, 
would have a different trust profile from showing instructions on that same 
website, or sending them to eduroam CAT from that website.

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


On Tue, Feb 2, 2021 at 12:43 PM Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu<mailto:0194c9ecac40-dmarc-requ...@listserv.educause.edu>>
 wrote:
While UX is great with QR codes, security and trust is challenging.

You'll start to see more QR-based provisioning with IoT as part of Wi-Fi Easy 
Connect but those have other security layers baked on top.





From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Hunter Fuller 
<0211f6bc0913-dmarc-requ...@listserv.educause.edu<mailto:0211f6bc0913-dmarc-requ...@listserv.educause.edu>>
Sent: Tuesday, February 2, 2021 13:41
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] [External] Re: [WIRELESS-LAN] android 11 upcoming 
changes Feb 15th 2021

I wish there was a QR schema. Even if it only worked on devices with another 
connection available (LTE, etc.) to download the config. Sigh.

The closest we have right now is scanning a QR code leading to a .mobileconfig 
file on iOS.

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


On Tue, Feb 2, 2021 at 12:29 PM Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu<mailto:0194c9ecac40-dmarc-requ...@listserv.educause.edu>>
 wrote:
Well, again, you should be properly configuring the supplicant regardless, so 
the instructions would apply to any version of Android

RE: QR, no, enterprise authentication is not supported. A supplicant 
configuration tool should always be used. The supplicant was not designed to be 
manually configured by end users (on any OS).



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Michael Holden 
mailto:mhol...@datanetworksolutions.com>>
Sent: Tuesday, February 2, 2021 13:16
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021

We've seen much the same.
A Pixel 2XL and a Pixel3XL fully updated, the 2XL had the Don't Validate 
option, but the Pixel3XL did not.

We added the CA cert to a subpage on the guest captive portal for ease of 
access to the Wireless device, and provided some instructions for the devices.
The workflow to manually add the Wireless Trust was a bit flaky too with Modify 
Settings not really working.

The instruction set that appeared to work as of the current (January 2021) 
Android software release on the Pixel 3XL not tested on Pixel 4/4a/5:


  1.  Download the CA cert from the ClearPass Guest Captive Portal Page
  2.  Go to Settings
  3.  Network & Internet
  4.  Wi-Fi
  5.  Wi-Fi preferences
  6.  Advanced
  7.  Install Certificate
  8.  Choose the Certificate downloaded in the first step
  9.  Name the Certificate
  10. Connect to the Secure SSID
 *   Change the Certificate from System Certs to the Certificate name 
entered in the previous step
 *   Domain to 
 *   Identity as the username
 *   Password as the user’s password
 *   Connect
  11. Confirm Wireless is connected to the WPA2-Enterprise SSID
 *   You may have to forget and add network as the Modify Setting on the 
SSID does not appear to work properly as of January, 2021 Android Software 
release


There is a QR code that can be created for PSK networks, has anyone seen if 
this is possible for WPA2/3-Enterprise?



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu<mailto:0194c9ecac40-dmarc-requ...@listserv.educause.edu>>
Sent: Tuesday

Re: [WIRELESS-LAN] [External] Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021

[Tim Cappalli]

While UX is great with QR codes, security and trust is challenging.

You'll start to see more QR-based provisioning with IoT as part of Wi-Fi Easy 
Connect but those have other security layers baked on top.





From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Hunter Fuller 
<0211f6bc0913-dmarc-requ...@listserv.educause.edu>
Sent: Tuesday, February 2, 2021 13:41
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] [External] Re: [WIRELESS-LAN] android 11 upcoming 
changes Feb 15th 2021

I wish there was a QR schema. Even if it only worked on devices with another 
connection available (LTE, etc.) to download the config. Sigh.

The closest we have right now is scanning a QR code leading to a .mobileconfig 
file on iOS.

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


On Tue, Feb 2, 2021 at 12:29 PM Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu<mailto:0194c9ecac40-dmarc-requ...@listserv.educause.edu>>
 wrote:
Well, again, you should be properly configuring the supplicant regardless, so 
the instructions would apply to any version of Android

RE: QR, no, enterprise authentication is not supported. A supplicant 
configuration tool should always be used. The supplicant was not designed to be 
manually configured by end users (on any OS).



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Michael Holden 
mailto:mhol...@datanetworksolutions.com>>
Sent: Tuesday, February 2, 2021 13:16
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021

We've seen much the same.
A Pixel 2XL and a Pixel3XL fully updated, the 2XL had the Don't Validate 
option, but the Pixel3XL did not.

We added the CA cert to a subpage on the guest captive portal for ease of 
access to the Wireless device, and provided some instructions for the devices.
The workflow to manually add the Wireless Trust was a bit flaky too with Modify 
Settings not really working.

The instruction set that appeared to work as of the current (January 2021) 
Android software release on the Pixel 3XL not tested on Pixel 4/4a/5:


  1.  Download the CA cert from the ClearPass Guest Captive Portal Page
  2.  Go to Settings
  3.  Network & Internet
  4.  Wi-Fi
  5.  Wi-Fi preferences
  6.  Advanced
  7.  Install Certificate
  8.  Choose the Certificate downloaded in the first step
  9.  Name the Certificate
  10. Connect to the Secure SSID
 *   Change the Certificate from System Certs to the Certificate name 
entered in the previous step
 *   Domain to 
 *   Identity as the username
 *   Password as the user’s password
 *   Connect
  11. Confirm Wireless is connected to the WPA2-Enterprise SSID
 *   You may have to forget and add network as the Modify Setting on the 
SSID does not appear to work properly as of January, 2021 Android Software 
release


There is a QR code that can be created for PSK networks, has anyone seen if 
this is possible for WPA2/3-Enterprise?



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu<mailto:0194c9ecac40-dmarc-requ...@listserv.educause.edu>>
Sent: Tuesday, February 2, 2021 12:54
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021

Screenshot please.




From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Walter Reynolds mailto:wa...@umich.edu>>
Sent: Tuesday, February 2, 2021 12:46
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021

Can someone explain something to me?

I have a Pixel 3 that I did a factory rest on.  Next I did all the updates 
needed and it is running Android 11.  The build number is RQ1A.210205.004 which 
includes the latest security patch for the phone.

When I go to configure a WPA2 Enterprise network I still have the "Don't 
validate" option.

What am I missing here?


Walter Reynolds
Network Architect
Information and Technology Services
University of Michigan
(734) 615-9438


On Tue, Feb 2, 2021 at 8:51 AM Hurt,Trenton W. 
ma

Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021

[Tim Cappalli]

Well, again, you should be properly configuring the supplicant regardless, so 
the instructions would apply to any version of Android

RE: QR, no, enterprise authentication is not supported. A supplicant 
configuration tool should always be used. The supplicant was not designed to be 
manually configured by end users (on any OS).



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Michael Holden 

Sent: Tuesday, February 2, 2021 13:16
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021

We've seen much the same.
A Pixel 2XL and a Pixel3XL fully updated, the 2XL had the Don't Validate 
option, but the Pixel3XL did not.

We added the CA cert to a subpage on the guest captive portal for ease of 
access to the Wireless device, and provided some instructions for the devices.
The workflow to manually add the Wireless Trust was a bit flaky too with Modify 
Settings not really working.

The instruction set that appeared to work as of the current (January 2021) 
Android software release on the Pixel 3XL not tested on Pixel 4/4a/5:


  1.  Download the CA cert from the ClearPass Guest Captive Portal Page
  2.  Go to Settings
  3.  Network & Internet
  4.  Wi-Fi
  5.  Wi-Fi preferences
  6.  Advanced
  7.  Install Certificate
  8.  Choose the Certificate downloaded in the first step
  9.  Name the Certificate
  10. Connect to the Secure SSID
 *   Change the Certificate from System Certs to the Certificate name 
entered in the previous step
 *   Domain to 
 *   Identity as the username
 *   Password as the user’s password
 *   Connect
  11. Confirm Wireless is connected to the WPA2-Enterprise SSID
 *   You may have to forget and add network as the Modify Setting on the 
SSID does not appear to work properly as of January, 2021 Android Software 
release


There is a QR code that can be created for PSK networks, has anyone seen if 
this is possible for WPA2/3-Enterprise?



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu>
Sent: Tuesday, February 2, 2021 12:54
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021

Screenshot please.




From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Walter Reynolds 

Sent: Tuesday, February 2, 2021 12:46
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021

Can someone explain something to me?

I have a Pixel 3 that I did a factory rest on.  Next I did all the updates 
needed and it is running Android 11.  The build number is RQ1A.210205.004 which 
includes the latest security patch for the phone.

When I go to configure a WPA2 Enterprise network I still have the "Don't 
validate" option.

What am I missing here?


Walter Reynolds
Network Architect
Information and Technology Services
University of Michigan
(734) 615-9438


On Tue, Feb 2, 2021 at 8:51 AM Hurt,Trenton W. 
mailto:trent.h...@louisville.edu>> wrote:
LOL if it’s working now on those android 11 devices as is then I guess it is.  
And if it’s not well then Feb 15th I guess will be fun

Trent Hurt

University of Louisville


From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu<mailto:0194c9ecac40-dmarc-requ...@listserv.educause.edu>>
Sent: Monday, February 1, 2021 6:06:41 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021


CAUTION: This email originated from outside of our organization. Do not click 
links, open attachments, or respond unless you recognize the sender's email 
address and know the contents are safe.

If the supplicant is properly configured, then yes.


From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Hurt,Trenton W. 
mailto:trent.h...@louisville.edu>>
Sent: Monday, February 1, 2021 18:03
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021

Tim

I know you can’t comment specifically on my setup or environment but if I have 
android 11 pixel 4 and others that have the December update already and the do 
not validate is not an option for those devices but they can use our onboard 
eap tls workflow and the devices aut

Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021

[Tim Cappalli]

Screenshot please.




From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Walter Reynolds 

Sent: Tuesday, February 2, 2021 12:46
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021

Can someone explain something to me?

I have a Pixel 3 that I did a factory rest on.  Next I did all the updates 
needed and it is running Android 11.  The build number is RQ1A.210205.004 which 
includes the latest security patch for the phone.

When I go to configure a WPA2 Enterprise network I still have the "Don't 
validate" option.

What am I missing here?


Walter Reynolds
Network Architect
Information and Technology Services
University of Michigan
(734) 615-9438


On Tue, Feb 2, 2021 at 8:51 AM Hurt,Trenton W. 
mailto:trent.h...@louisville.edu>> wrote:
LOL if it’s working now on those android 11 devices as is then I guess it is.  
And if it’s not well then Feb 15th I guess will be fun

Trent Hurt

University of Louisville


From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu<mailto:0194c9ecac40-dmarc-requ...@listserv.educause.edu>>
Sent: Monday, February 1, 2021 6:06:41 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021


CAUTION: This email originated from outside of our organization. Do not click 
links, open attachments, or respond unless you recognize the sender's email 
address and know the contents are safe.

If the supplicant is properly configured, then yes.


From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Hurt,Trenton W. 
mailto:trent.h...@louisville.edu>>
Sent: Monday, February 1, 2021 18:03
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021

Tim

I know you can’t comment specifically on my setup or environment but if I have 
android 11 pixel 4 and others that have the December update already and the do 
not validate is not an option for those devices but they can use our onboard 
eap tls workflow and the devices auth via that method.  Do you think that my 
setup (regardless if it’s not the most secure way or whatever) will still work 
after this feb 15 date?

Trent Hurt

University of Louisville


From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Trenton Hurt mailto:trenth...@gmail.com>>
Sent: Monday, February 1, 2021 5:55:20 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021


CAUTION: This email originated from outside of our organization. Do not click 
links, open attachments, or respond unless you recognize the sender's email 
address and know the contents are safe.

Android 11 (pixels 4 and other google handsets) have been doing the do not 
validate since early dec and for us it meant eap peap unmanaged over the air ( 
yes I know Tim this is not secure method but just how it is or was anyway).  
Now those users don’t have eap peap option and we have been moving them to our 
eap tls onboarding and this has been working for those android 11 users.  I 
just wasn’t sure if these were additional security measures that I needed to 
look out for or make some changes to my onboard profile stuff to make sure 
these android 11 still work after February 15

On Mon, Feb 1, 2021 at 5:28 PM Jennifer Minella 
mailto:j...@cadinc.com>> wrote:

I may disagree with some of the other feedback here…  I think this is a big 
deal.



It sounds like Google will be enforcing proper server validation for 
802.1X-secured networks, based on what Trent sent originally. I believe Apple 
already has been enforcing this for a bit.



If my guess is correct (I’ll try to find a link) then what it means is – after 
this update, you can’t tell the endpoint to ignore or bypass the server 
certificate for 802.1X (any EAP method).



The impact of this is…

  *   If you’re organization has any endpoints that have been configured to use 
a secured network but are ignoring the server’s certificate – then that will 
STOP working suddenly at the update.
  *   This setting (ignore/don’t validate server cert) is not ideal but it’s 
prevalent especially for things like BYOD or HED device onboarding, testing

Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021

[Tim Cappalli]

%7C0%7C637478174567583319%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=DmGZn22y375PDx%2FmlGOhoHnssJVfrrMqsLrl6tBIvOc%3D=0>

  *





___

Jennifer Minella, CISSP, HP MASE

VP of Engineering & Security

Carolina Advanced Digital, Inc.

www.cadinc.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cadinc.com%2F=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C22a612d19cdc4eef95f308d8c705a9ee%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637478174567583319%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=if94eAXScV57nhVeGwhBiNfMDl2CaOFFQYf19jNrKJ0%3D=0>

j...@cadinc.com<mailto:j...@cadinc.com>

919.460.1313 Main Office

919.539.2726 Mobile/text

[CAD LOGO EMAIL SIG]



From: Hurt,Trenton W. 
mailto:trent.h...@louisville.edu>>
Sent: Monday, February 1, 2021 4:54 PM
Subject: Re: android 11 upcoming changes Feb 15th 2021



Ok thanks as always for clarification as ive been seeing android 11 on campus 
and they work with our current eap tls onboard workflow.  I wasn’t sure if 
something else was coming on feb 15th that would cause some issue with this 
setup



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Monday, February 1, 2021 4:51 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021



CAUTION: This email originated from outside of our organization. Do not click 
links, open attachments, or respond unless you recognize the sender's email 
address and know the contents are safe.

This is a bit misleading IMO. There are no further changes in Android 11 after 
the December update.



Seems like this is specific to Secure W2's product.



As a general best practice, you should be using a single EAP server 
certificate, signed using a PKI in your control, across your all your RADIUS 
servers.



It is very poor practice to use a wildcard for EAP subject name matching. I'm 
very disappointed to see vendors making that recommendation.



tim



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Hurt,Trenton W. 
mailto:trent.h...@louisville.edu>>
Sent: Monday, February 1, 2021 16:46
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021



FYI



I just received the following from securew2 about some additional security 
changes coming to android 11.







This action will need to take place before the upcoming Android application 
update that is planned for February 15th, 2021.



As you may already be aware, Google mandates server validation to be properly 
configured for WiFi from Android version 11. This means that any 802.1X WiFi 
configuration without the following two settings will fail to connect.



1.  Server Validation

2.  Connect to these server names



For more information about these configurations, please read below.



What is Server Validation in a Network Profile?

This configuration item is for clients to validate a RADIUS server certificate 
chain during an EAP authentication. Clients would forward its requests only 
when the received server certificate is signed by the CA that is configured on 
the SecureW2 Network Profile.  It may be required to upload only the Root CA of 
the RADIUS server certificate, however, in some cases, the full chain may need 
to be provided.



What is the Connect to these server names field?

This field is used to specify the name of your RADIUS server certificate using 
its Common Name. If there is only one RADIUS server in your setup, you can 
quickly find this name from the certificate. If there are more than one RADIUS 
servers, or if the RADIUS server Common Name has more than two subdomains, we 
advise to use a wildcard name.



For example:

If the RADIUS server certificate’s Common Name = 
radius.domain.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fradius.domain.com%2F=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C22a612d19cdc4eef95f308d8c705a9ee%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637478174567593312%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=uxb2Rzakd9Ky%2Bj3CLRO1GI63T6wgz9186NJUGHq5h00%3D=0>
 Connect to these server names should be 
radius.domain.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fradius.domain.com%2F=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C22a612d19cdc4eef95f308d8c705a9ee%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637478174567603307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=ZGc54FBDpRoWEkPROFcQMJODzActh5

Re: android 11 upcoming changes Feb 15th 2021

[Tim Cappalli]

iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=sBYtxyiUCoCO8Di9psggBDTJ5PBsjyPSLOi10AaLZKk%3D=0>

j...@cadinc.com<mailto:j...@cadinc.com>

919.460.1313 Main Office

919.539.2726 Mobile/text

[CAD LOGO EMAIL SIG]



From: Hurt,Trenton W. 
Sent: Monday, February 1, 2021 4:54 PM
Subject: Re: android 11 upcoming changes Feb 15th 2021



Ok thanks as always for clarification as ive been seeing android 11 on campus 
and they work with our current eap tls onboard workflow.  I wasn’t sure if 
something else was coming on feb 15th that would cause some issue with this 
setup



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Monday, February 1, 2021 4:51 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021



CAUTION: This email originated from outside of our organization. Do not click 
links, open attachments, or respond unless you recognize the sender's email 
address and know the contents are safe.

This is a bit misleading IMO. There are no further changes in Android 11 after 
the December update.



Seems like this is specific to Secure W2's product.



As a general best practice, you should be using a single EAP server 
certificate, signed using a PKI in your control, across your all your RADIUS 
servers.



It is very poor practice to use a wildcard for EAP subject name matching. I'm 
very disappointed to see vendors making that recommendation.



tim



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Hurt,Trenton W. 
mailto:trent.h...@louisville.edu>>
Sent: Monday, February 1, 2021 16:46
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021



FYI



I just received the following from securew2 about some additional security 
changes coming to android 11.







This action will need to take place before the upcoming Android application 
update that is planned for February 15th, 2021.



As you may already be aware, Google mandates server validation to be properly 
configured for WiFi from Android version 11. This means that any 802.1X WiFi 
configuration without the following two settings will fail to connect.



1.  Server Validation

2.  Connect to these server names



For more information about these configurations, please read below.



What is Server Validation in a Network Profile?

This configuration item is for clients to validate a RADIUS server certificate 
chain during an EAP authentication. Clients would forward its requests only 
when the received server certificate is signed by the CA that is configured on 
the SecureW2 Network Profile.  It may be required to upload only the Root CA of 
the RADIUS server certificate, however, in some cases, the full chain may need 
to be provided.



What is the Connect to these server names field?

This field is used to specify the name of your RADIUS server certificate using 
its Common Name. If there is only one RADIUS server in your setup, you can 
quickly find this name from the certificate. If there are more than one RADIUS 
servers, or if the RADIUS server Common Name has more than two subdomains, we 
advise to use a wildcard name.



For example:

If the RADIUS server certificate’s Common Name = radius.domain.com Connect to 
these server names should be radius.domain.com



If the RADIUS server certificate’s Common Name = 
radius.lab.department.domain.com Connect to these server names should be 
*.department.domain.com or *.domain.com









Thanks

Trent



Trenton Hurt, CWNE #172,ACMP,ACCP,CCNP(W),CCNA(W),CCNA(V),CCNA(R/S)

Network Analyst

University of Louisville

Phone (502) 852-1513



**
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=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C626023000f32465c5d5108d8c7005106%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637478151479149539%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=BmyVzeC2GajK4B%2BIOzxV0e%2BRLcmmC7ieKuegttzttGw%3D=0>

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

Re: android 11 upcoming changes Feb 15th 2021

[Tim Cappalli]

This is a bit misleading IMO. There are no further changes in Android 11 after 
the December update.

Seems like this is specific to Secure W2's product.

As a general best practice, you should be using a single EAP server 
certificate, signed using a PKI in your control, across your all your RADIUS 
servers.

It is very poor practice to use a wildcard for EAP subject name matching. I'm 
very disappointed to see vendors making that recommendation.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Hurt,Trenton W. 

Sent: Monday, February 1, 2021 16:46
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: [WIRELESS-LAN] android 11 upcoming changes Feb 15th 2021


FYI



I just received the following from securew2 about some additional security 
changes coming to android 11.







This action will need to take place before the upcoming Android application 
update that is planned for February 15th, 2021.



As you may already be aware, Google mandates server validation to be properly 
configured for WiFi from Android version 11. This means that any 802.1X WiFi 
configuration without the following two settings will fail to connect.



1.  Server Validation

2.  Connect to these server names



For more information about these configurations, please read below.



What is Server Validation in a Network Profile?

This configuration item is for clients to validate a RADIUS server certificate 
chain during an EAP authentication. Clients would forward its requests only 
when the received server certificate is signed by the CA that is configured on 
the SecureW2 Network Profile.  It may be required to upload only the Root CA of 
the RADIUS server certificate, however, in some cases, the full chain may need 
to be provided.



What is the Connect to these server names field?

This field is used to specify the name of your RADIUS server certificate using 
its Common Name. If there is only one RADIUS server in your setup, you can 
quickly find this name from the certificate. If there are more than one RADIUS 
servers, or if the RADIUS server Common Name has more than two subdomains, we 
advise to use a wildcard name.



For example:

If the RADIUS server certificate’s Common Name = radius.domain.com Connect to 
these server names should be radius.domain.com



If the RADIUS server certificate’s Common Name = 
radius.lab.department.domain.com Connect to these server names should be 
*.department.domain.com or *.domain.com









Thanks

Trent



Trenton Hurt, CWNE #172,ACMP,ACCP,CCNP(W),CCNA(W),CCNA(V),CCNA(R/S)

Network Analyst

University of Louisville

Phone (502) 852-1513



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

Re: [EXTERNAL] Re: [WIRELESS-LAN] Android 11 and Cert Verification

[Tim Cappalli]

ect to a 
limited number of hosts with rarely changing fingerprints.



I find it curious that this change is only on Pixel devices, is that because no 
others have Android 11 or because only Google is implementing it?



--

James Andrewartha

Network & Projects Engineer

Christ Church Grammar School

Claremont, Western Australia

Ph. (08) 9442 1757

Mob. 0424 160 877



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Saturday, 16 January 2021 11:33 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification



EAP-TLS is modern, strong authentication. And enrollment can even use 
passwordless.

Imagine of browsers operated on the TOFU model?

*tim



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of James Andrewartha 
mailto:jandrewar...@ccgs.wa.edu.au>>
Sent: Saturday, January 16, 2021 10:31:27 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification



I disagree, but OWE or SAE with a captive portal then? At least I can use 
modern authentication methods like hardware keys and TOTP with a browser.



--

James Andrewartha

Network & Projects Engineer

Christ Church Grammar School

Claremont, Western Australia

Ph. (08) 9442 1757

Mob. 0424 160 877



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Saturday, 16 January 2021 11:24 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification



Because trust on first use is almost as bad as not trusting at all.

Properly deploy 802.1X or don't use it. Sorry to be harsh but this same 
conversation multiple times per year, every year is tiring.

Tom



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of James Andrewartha 
mailto:jandrewar...@ccgs.wa.edu.au>>
Sent: Saturday, January 16, 2021 10:11:00 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification



Why couldn’t Google add trust-on-first-use to Android like Apple has with iOS 
and macOS, and Microsoft has in Windows?



--

James Andrewartha

Network & Projects Engineer

Christ Church Grammar School

Claremont, Western Australia

Ph. (08) 9442 1757

Mob. 0424 160 877



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Saturday, 16 January 2021 6:28 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification



> “many colleges provided instructions as such.”



This is one of the many reasons the change was made. Not just colleges, 
enterprises as well.



These instructions are worse than instructing users to do to this:



chrome.exe --ignore-certificate-errors



tim



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Angelo Santabarbara 
mailto:asantabarb...@siena.edu>>
Date: Friday, January 15, 2021 at 17:25
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification

Correct Tim. I failed to clarify that you can no longer setup eduroam profiles 
manually without a certificate.  Previously this worked and many colleges 
provided instructions as such. With the most recent update this is no longer 
possible so we had to resort to using the eduroam CAT tool to provide a simple 
method of joining eduroam.

—Angelo D. Santabarbara, MBA
Director Networks & Systems | Siena College
O 518-782-6996
E asantabarb...@siena.edu<mailto:asantabarb...@siena.edu>
W siena.edu

**
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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunitydata=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7Cd7b8a5c46dec41792dab08d8b9a46c44%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637463463147866490%7CUnknow

Re: [EXTERNAL] Re: [WIRELESS-LAN] Android 11 and Cert Verification

[Tim Cappalli]

The RADIUS component is not the issue here and even if it was, there are many 
free solutions on the market.

(not that I’ve ever recommend NPS, but you can absolutely run NPS in a VM in 
Azure… or AWS or GCP)

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of James Andrewartha 

Date: Saturday, January 16, 2021 at 21:31
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] [EXTERNAL] Re: [WIRELESS-LAN] Android 11 and Cert 
Verification
I’m arguing on behalf of the many poorly-resourced environments where NPS has a 
marginal cost of zero, and that enabling TOFU would be a simple thing to 
improve their security. Most of these places don’t have the budget or expertise 
for something like CPPM (I have it and even I’m intimidated by it). Microsoft 
isn’t helping because there’s no cloud RADIUS (NPS is explicitly not supported 
in Azure). It’s the responsibility of vendors to provide accessible tools for 
security.

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

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Turpin, Max
Sent: Sunday, 17 January 2021 7:49 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] [EXTERNAL] Re: [WIRELESS-LAN] Android 11 and Cert 
Verification

You do have to maintain a pki or have someone else do it but CRLs are hardly 
necessary if you do identity checking as part of your radius service. If you 
want to do posture checking you will need to use some sort of agent (as far as 
I know) so that could certainly be part of your on boarding solution.

The fact that the majority of environments fail to deploy 802.1x correctly 
doesn’t take away the responsibility of institutions to fix it and provide a 
secure solution to users even if it means educating the administration and 
users on what must be done now to access the network. And as we almost all 
know, the problem is not a technical one now, but one of communication.

Max



On Jan 16, 2021, at 10:56 AM, James Andrewartha 
mailto:jandrewar...@ccgs.wa.edu.au>> wrote:

Certificate enrolment sucks for BYOD though, there’s no ongoing posture 
checking, and you have to maintain a CA and CRL.

SSH uses TOFU and is more comparable to RADIUS in that you only connect to a 
limited number of hosts with rarely changing fingerprints.

I find it curious that this change is only on Pixel devices, is that because no 
others have Android 11 or because only Google is implementing it?

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

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Saturday, 16 January 2021 11:33 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification

EAP-TLS is modern, strong authentication. And enrollment can even use 
passwordless.
Imagine of browsers operated on the TOFU model?
*tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of James Andrewartha 
mailto:jandrewar...@ccgs.wa.edu.au>>
Sent: Saturday, January 16, 2021 10:31:27 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification


I disagree, but OWE or SAE with a captive portal then? At least I can use 
modern authentication methods like hardware keys and TOTP with a browser.



--

James Andrewartha

Network & Projects Engineer

Christ Church Grammar School

Claremont, Western Australia

Ph. (08) 9442 1757

Mob. 0424 160 877



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Saturday, 16 January 2021 11:24 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification



Because trust on first use is almost as bad as not trusting at all.

Properly deploy 802.1X or don't use it. Sorry to be harsh but this same 
conversation multiple times per year, every year is tiring.

Tom



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of James Andrewartha 
mailto:jandrewar...@ccgs.wa.edu.au>>
Sent: Saturday, January 16, 2021 10:11:00 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification



Why couldn’t 

Re: [WIRELESS-LAN] Android 11 and Cert Verification

[Tim Cappalli]

And I should add, you do not have to use client certificates to address the 
core challenge of properly configuring supplicants in a wizard-like fashion 
while protecting user credentials in federated environments.

A per-device username and password can be used in combination with 
profile-based provisioning (available in some way, shape or form on each 
platform).

This is actually what many non-cellular SPs use for Passpoint.

Example:

Username: 1264CCBB-0D2E-44C5-B045-6D191EA65A4D
Password: y7A96MhKjf05R5nueRtk1QZ9TEqhlhY6zL
Anonymous Identity: anonym...@mydomain.edu<mailto:anonym...@mydomain.edu>

(This is actually how I deploy my personal network using some custom logic in 
CPPM  )

While it’s not as strong as a certificate and is not a device bound credential, 
it is better than using a user’s credentials (even when the supplicant is 
managed) and can be embedded into a profile in a web-based enrollment flow.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu>
Date: Saturday, January 16, 2021 at 11:12
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification

  *   Certificate enrolment sucks for BYOD though, there’s no ongoing posture 
checking, and you have to maintain a CA and CRL.


There are many aaS offerings and even the on-premises solutions do most of the 
CA management automagically. It is rare that you need to fully manage a PKI for 
unmanaged device access.


  *   SSH uses TOFU and is more comparable to RADIUS in that you only connect 
to a limited number of hosts with rarely changing fingerprints.


Sure, but the fingerprint for an SSH server can be explicitly compared since it 
is equivalent to a self-signed trust model.

There are also ways of binding an SSH server fingerprint to a domain name that 
is queried and evaluated on connection. That doesn’t exist with EAP.


  *   I find it curious that this change is only on Pixel devices, is that 
because no others have Android 11 or because only Google is implementing it?

The change was made in the core Android code. Pixels usually roll out new code 
first. As other OEMs integrate the code, it will show up.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of James Andrewartha 

Date: Saturday, January 16, 2021 at 10:56
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification
Certificate enrolment sucks for BYOD though, there’s no ongoing posture 
checking, and you have to maintain a CA and CRL.

SSH uses TOFU and is more comparable to RADIUS in that you only connect to a 
limited number of hosts with rarely changing fingerprints.

I find it curious that this change is only on Pixel devices, is that because no 
others have Android 11 or because only Google is implementing it?

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

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Tim Cappalli
Sent: Saturday, 16 January 2021 11:33 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification

EAP-TLS is modern, strong authentication. And enrollment can even use 
passwordless.
Imagine of browsers operated on the TOFU model?
*tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of James Andrewartha 
mailto:jandrewar...@ccgs.wa.edu.au>>
Sent: Saturday, January 16, 2021 10:31:27 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification


I disagree, but OWE or SAE with a captive portal then? At least I can use 
modern authentication methods like hardware keys and TOTP with a browser.



--

James Andrewartha

Network & Projects Engineer

Christ Church Grammar School

Claremont, Western Australia

Ph. (08) 9442 1757

Mob. 0424 160 877



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Saturday, 16 January 2021 11:24 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification



Because trust on first use is almost as bad as not trusting at all.

Properly deploy 802.1X or don't use it. Sorry to be harsh but this same 
conversation multiple times per year, every year is tiring.

Tom



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of James Andrewartha 
mailto:jandrewar...@ccgs.wa.edu.au>>
Sent: Saturday, 

Re: [WIRELESS-LAN] Android 11 and Cert Verification

[Tim Cappalli]

  *   Certificate enrolment sucks for BYOD though, there’s no ongoing posture 
checking, and you have to maintain a CA and CRL.


There are many aaS offerings and even the on-premises solutions do most of the 
CA management automagically. It is rare that you need to fully manage a PKI for 
unmanaged device access.


  *   SSH uses TOFU and is more comparable to RADIUS in that you only connect 
to a limited number of hosts with rarely changing fingerprints.


Sure, but the fingerprint for an SSH server can be explicitly compared since it 
is equivalent to a self-signed trust model.

There are also ways of binding an SSH server fingerprint to a domain name that 
is queried and evaluated on connection. That doesn’t exist with EAP.


  *   I find it curious that this change is only on Pixel devices, is that 
because no others have Android 11 or because only Google is implementing it?

The change was made in the core Android code. Pixels usually roll out new code 
first. As other OEMs integrate the code, it will show up.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of James Andrewartha 

Date: Saturday, January 16, 2021 at 10:56
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification
Certificate enrolment sucks for BYOD though, there’s no ongoing posture 
checking, and you have to maintain a CA and CRL.

SSH uses TOFU and is more comparable to RADIUS in that you only connect to a 
limited number of hosts with rarely changing fingerprints.

I find it curious that this change is only on Pixel devices, is that because no 
others have Android 11 or because only Google is implementing it?

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

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Tim Cappalli
Sent: Saturday, 16 January 2021 11:33 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification

EAP-TLS is modern, strong authentication. And enrollment can even use 
passwordless.
Imagine of browsers operated on the TOFU model?
*tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of James Andrewartha 
mailto:jandrewar...@ccgs.wa.edu.au>>
Sent: Saturday, January 16, 2021 10:31:27 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification


I disagree, but OWE or SAE with a captive portal then? At least I can use 
modern authentication methods like hardware keys and TOTP with a browser.



--

James Andrewartha

Network & Projects Engineer

Christ Church Grammar School

Claremont, Western Australia

Ph. (08) 9442 1757

Mob. 0424 160 877



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Saturday, 16 January 2021 11:24 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification



Because trust on first use is almost as bad as not trusting at all.

Properly deploy 802.1X or don't use it. Sorry to be harsh but this same 
conversation multiple times per year, every year is tiring.

Tom



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of James Andrewartha 
mailto:jandrewar...@ccgs.wa.edu.au>>
Sent: Saturday, January 16, 2021 10:11:00 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification



Why couldn’t Google add trust-on-first-use to Android like Apple has with iOS 
and macOS, and Microsoft has in Windows?



--

James Andrewartha

Network & Projects Engineer

Christ Church Grammar School

Claremont, Western Australia

Ph. (08) 9442 1757

Mob. 0424 160 877



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Saturday, 16 January 2021 6:28 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification



> “many colleges provided instructions as such.”



This is one of the many reasons the change was made. Not just colleges, 
enterprises as well.



These instructions are worse than instructing users to do to this:



chrome.exe --ignore-certificate-errors



tim



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of 

Re: [WIRELESS-LAN] Android 11 and Cert Verification

[Tim Cappalli]

EAP-TLS is modern, strong authentication. And enrollment can even use 
passwordless.

Imagine of browsers operated on the TOFU model?

*tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of James Andrewartha 

Sent: Saturday, January 16, 2021 10:31:27 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification


I disagree, but OWE or SAE with a captive portal then? At least I can use 
modern authentication methods like hardware keys and TOTP with a browser.



--

James Andrewartha

Network & Projects Engineer

Christ Church Grammar School

Claremont, Western Australia

Ph. (08) 9442 1757

Mob. 0424 160 877



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Tim Cappalli
Sent: Saturday, 16 January 2021 11:24 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification



Because trust on first use is almost as bad as not trusting at all.

Properly deploy 802.1X or don't use it. Sorry to be harsh but this same 
conversation multiple times per year, every year is tiring.

Tom



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of James Andrewartha 
mailto:jandrewar...@ccgs.wa.edu.au>>
Sent: Saturday, January 16, 2021 10:11:00 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification



Why couldn’t Google add trust-on-first-use to Android like Apple has with iOS 
and macOS, and Microsoft has in Windows?



--

James Andrewartha

Network & Projects Engineer

Christ Church Grammar School

Claremont, Western Australia

Ph. (08) 9442 1757

Mob. 0424 160 877



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Saturday, 16 January 2021 6:28 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification



> “many colleges provided instructions as such.”



This is one of the many reasons the change was made. Not just colleges, 
enterprises as well.



These instructions are worse than instructing users to do to this:



chrome.exe --ignore-certificate-errors



tim



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Angelo Santabarbara 
mailto:asantabarb...@siena.edu>>
Date: Friday, January 15, 2021 at 17:25
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification

Correct Tim. I failed to clarify that you can no longer setup eduroam profiles 
manually without a certificate.  Previously this worked and many colleges 
provided instructions as such. With the most recent update this is no longer 
possible so we had to resort to using the eduroam CAT tool to provide a simple 
method of joining eduroam.

—Angelo D. Santabarbara, MBA
Director Networks & Systems | Siena College
O 518-782-6996
E asantabarb...@siena.edu<mailto:asantabarb...@siena.edu>
W siena.edu

**
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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunitydata=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7Cd7b8a5c46dec41792dab08d8b9a46c44%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637463463147866490%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=BWCJlgK%2FAoLgUdILx%2Bqx7IL4GE4MU8jWaaYF0wrs0%2F8%3Dreserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunity=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7Cbca42b32c52d4179d81608d8ba33cfcf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637464079131475340%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=FGMYdsJkr4nBPulho2WRJvNBsyc2DndGV3EFJMSPRYY%3D=0>

**
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=04%7C01%7Ctim.cappalli%40M

Re: [WIRELESS-LAN] Android 11 and Cert Verification

[Tim Cappalli]

Because trust on first use is almost as bad as not trusting at all.

Properly deploy 802.1X or don't use it. Sorry to be harsh but this same 
conversation multiple times per year, every year is tiring.

Tom

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of James Andrewartha 

Sent: Saturday, January 16, 2021 10:11:00 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification


Why couldn’t Google add trust-on-first-use to Android like Apple has with iOS 
and macOS, and Microsoft has in Windows?



--

James Andrewartha

Network & Projects Engineer

Christ Church Grammar School

Claremont, Western Australia

Ph. (08) 9442 1757

Mob. 0424 160 877



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Tim Cappalli
Sent: Saturday, 16 January 2021 6:28 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification



> “many colleges provided instructions as such.”



This is one of the many reasons the change was made. Not just colleges, 
enterprises as well.



These instructions are worse than instructing users to do to this:



chrome.exe --ignore-certificate-errors



tim



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Angelo Santabarbara 
mailto:asantabarb...@siena.edu>>
Date: Friday, January 15, 2021 at 17:25
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification

Correct Tim. I failed to clarify that you can no longer setup eduroam profiles 
manually without a certificate.  Previously this worked and many colleges 
provided instructions as such. With the most recent update this is no longer 
possible so we had to resort to using the eduroam CAT tool to provide a simple 
method of joining eduroam.

—Angelo D. Santabarbara, MBA
Director Networks & Systems | Siena College
O 518-782-6996
E asantabarb...@siena.edu<mailto:asantabarb...@siena.edu>
W siena.edu

**
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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunitydata=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7Cd7b8a5c46dec41792dab08d8b9a46c44%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637463463147866490%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=BWCJlgK%2FAoLgUdILx%2Bqx7IL4GE4MU8jWaaYF0wrs0%2F8%3Dreserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunity=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C1123b0e513934e1deae808d8ba30fec7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637464067019202860%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=Q4pgh1NCwwyZueoFjyD63kU9jYSagQUAxovStYMqTic%3D=0>

**
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=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C1123b0e513934e1deae808d8ba30fec7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637464067019202860%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=Q4pgh1NCwwyZueoFjyD63kU9jYSagQUAxovStYMqTic%3D=0>

**
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=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C1123b0e513934e1deae808d8ba30fec7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637464067019212856%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=PqNSEdKuyqN4fIaEAk0ryUmxq%2F7yCLVTInpX35PIC9A%3D=0>

**
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] Android 11 and Cert Verification

[Tim Cappalli]

> “many colleges provided instructions as such.”

This is one of the many reasons the change was made. Not just colleges, 
enterprises as well.

These instructions are worse than instructing users to do to this:

chrome.exe --ignore-certificate-errors

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Angelo Santabarbara 

Date: Friday, January 15, 2021 at 17:25
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification
Correct Tim. I failed to clarify that you can no longer setup eduroam profiles 
manually without a certificate.  Previously this worked and many colleges 
provided instructions as such. With the most recent update this is no longer 
possible so we had to resort to using the eduroam CAT tool to provide a simple 
method of joining eduroam.

—Angelo D. Santabarbara, MBA
Director Networks & Systems | Siena College
O 518-782-6996
E asantabarb...@siena.edu
W siena.edu

**
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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunitydata=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7Cd7b8a5c46dec41792dab08d8b9a46c44%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637463463147866490%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=BWCJlgK%2FAoLgUdILx%2Bqx7IL4GE4MU8jWaaYF0wrs0%2F8%3Dreserved=0

**
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] Android 11 and Cert Verification

[Tim Cappalli]

Please see my previous response. No part of that statement is accurate.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Floyd, Brad 

Date: Thursday, January 14, 2021 at 18:00
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification
Angelo,
What do you mean “Android phones don’t allow manual setup”? Are you saying you 
can no longer manually create a wireless connection config on the device?
Thanks,
Brad

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Angelo Santabarbara
Sent: Thursday, January 14, 2021 4:58 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification


[EXTERNAL SENDER]
We are instructing our users to use the eduroam CAT tool 
(https://cat.eduroam.org/)
 that we configured to deploy a certificate. Best we could do now that Android 
phones don't allow manual setup. —Angelo D. Santabarbara, MBA Director Networks 
& Systems | Siena College O 518-782-6996 E 
asantabarb...@siena.edu  W siena.edu

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

**
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] Cisco ISE radius proxy service for eduroam?

[Tim Cappalli]

Why not just terminate EAP in ISE instead of proxying?  From: The EDUCAUSE Wireless Issues Community Group Listserv  on behalf of Drew Ratliff Date: Tuesday, December 8, 2020 at 10:30To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] Cisco ISE radius proxy service for eduroam?Hello all! Here at UNCA we just received and starting using Cisco ISE for our tacacs and radius services.  However, we started running into issues using ISE as a radius proxy service for Eduroam. Currently, our certificates are managed through another service, XpressConnect, used for onboarding and certificate management. When attempting to use the radius proxy service to push authentication requests to XpressConnect we are encountering problems similar to a known bug with ISE 2.7 (Bug info here: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvu67106/). We have explored a workaround using the radius token service but this limits the use of eduroam to only UNCA domain as the token decrypts and uses certificates to trust the authentication request. Cisco has told us that a patch for this bug should be released around mid January, so we are standing by for that.  But I was wondering what other universities using ISE were doing for eduroam, and specifically using it as a radius proxy service.  Is there a work around that we haven't explored yet?  Or are they running a version of ISE where this bug is not an issue? Really any information or experience would be helpful... thanks everyone! Drew -- Drew RatliffNetwork AdministratorUNC Asheville ITS828-251-6624**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



smime.p7s
Description: S/MIME cryptographic signature

Re: Eero Wired OUI if anyone can help

[Tim Cappalli]

My Eero uses 3c:5c:f1 on the wired ports which is in the list below.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Friday, October 16, 2020 at 17:09
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] Eero Wired OUI if anyone can help
Thanks much- I did find about half of these, but am thinking the wired side may 
be a non Eero chipset. But I will peck at the expanded list you turned up.

Thanks!

Lee Badman | Network Architect (CWNE#200)
Information Technology Services
(NDD Group)
206 Machinery Hall
120 Smith Drive
Syracuse, New York 13244
t 315.443.3003   e lhbad...@syr.edu w its.syr.edu
Campus Wireless Policy: 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fanswers.syr.edu%2Fdisplay%2Fnetwork%2FWireless%2BNetwork%2Band%2BSystemsdata=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C9d150a481b2b42b366c108d87217b480%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637384793422498114%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Mpbdf57oZQLBPkixxytFo9tkrAIhwcfRfp%2BKIuF4Shg%3Dreserved=0
SYRACUSE UNIVERSITY
syr.edu

-Original Message-
From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Smith, Jacob E
Sent: Friday, October 16, 2020 4:55 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Eero Wired OUI if anyone can help

Hi Lee,

I don't have any experience with anything eero related, but it looks like there 
are 36 OUI registered to eero, Inc., just in case this is in anyway helpful:

$ curl -s 
"https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fstandards-oui.ieee.org%2Foui%2Foui.txtdata=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C9d150a481b2b42b366c108d87217b480%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637384793422498114%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=8oJw4s%2FjqtyjXDoa0bA5Fguu5NxMtM3ODi7DNupoMKU%3Dreserved=0;
 | grep -i eero -A3
60-5F-8D   (hex)eero inc.
605F8D (base 16)eero inc.
500 Howard Street, Suite 900
SAN FRANCISCO  CA  94105
US
--
80-DA-13   (hex)eero inc.
80DA13 (base 16)eero inc.
660 3rd Street
San Francisco  CA  94107
US
--
6C-AE-F6   (hex)eero inc.
6CAEF6 (base 16)eero inc.
660 3rd Street
San Francisco  CA  94107
US
--
98-ED-7E   (hex)eero inc.
98ED7E (base 16)eero inc.
660 3rd Street
San Francisco  CA  94107
US
--
F8-BB-BF   (hex)eero inc.
F8BBBF (base 16)eero inc.
500 Howard St Suite 900
San Francisco  CA  94105
US
--
4C-01-43   (hex)eero inc.
4C0143 (base 16)eero inc.
660 3rd Street
San Francisco  CA  94107
US
--
00-AB-48   (hex)eero inc.
00AB48 (base 16)eero inc.
660 3rd Street
San Francisco  CA  94107
US
--
74-B6-B6   (hex)eero inc.
74B6B6 (base 16)eero inc.
660 3rd Street
San Francisco  CA  94107
US
--
30-57-8E   (hex)eero inc.
30578E (base 16)eero inc.
660 3rd Street
San Francisco  CA  94107
US
--
80-B9-7A   (hex)eero inc.
80B97A (base 16)eero inc.
660 3rd Street
San Francisco  CA  94107
US
--
18-90-88   (hex)eero inc.
189088 (base 16)eero inc.
660 3rd Street
San Francisco  CA  94107
US
--
14-22-DB   (hex)eero inc.
1422DB (base 16)eero inc.
230 9th St.
San Francisco  CA  94103
US
--
48-DD-0C   (hex)eero inc.
48DD0C (base 16)eero inc.
660 3rd Street
San Francisco  CA  94107
US
--
3C-5C-F1   (hex)

Re: multi user windows/osx eap tls onboarding

[Tim Cappalli]

For Windows 10, you can use TEAP with chained machine + user certs (or a mix of 
cert and legacy cred).

For macOS, I’d recommend just using a machine identity, unless you absolutely 
need user identity for policy.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Wednesday, October 14, 2020 at 15:15
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: [WIRELESS-LAN] multi user windows/osx eap tls onboarding
For folks who onboard using eap tls.  What workflow or solution do you use for 
multiuser windows/osx devices?   We are using securew2 and this onboard process 
creates cert for that user who onboards the device.  Then when another user 
logs on they can’t connect to wireless because the cert isn’t for that user 
currently logged on.I can do machine auth via adcs and gpo that out for 
those but not sure how or what to do with osx multi user

Thanks
Trent



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

Re: [WIRELESS-LAN] Android 11 and Cert Verification

[Tim Cappalli]

Just want to make sure it’s clear that configuring a trusted CA for EAP server 
identity and properly configuring the supplicant is not the same as enrolling a 
device with a client certificate.

Regarding simplicity at the expense of security: I’d ask why you don’t tell 
students, faculty and staff to disable all certificate validation in their 
browser so that you don’t have to purchase public CA-issued server certificates 
for your web servers, because it is easy (and free)? 

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Tuesday, October 13, 2020 at 14:27
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification
Tim, et al,

So the issue with advance certificate onboarding is that it requires a process 
in advance that most students would have issues with. Issuing certs in advance 
is more of a process for company-owned devices.  It doesn’t work well with BYOD 
clients that have dynamic VLAN placement based on returned filter-IDs from a 
RADIUS/NPS server.

Most vendors walk you through a quick and dirty setup of NPS for 802.1x auth 
and VLAN placement, and therefore, they are interested in simple auth at the 
expense of security.  However, with Android 11 (and possibly a bit further 
back), that bypass of “don’t validate”, etc, isn’t an option.

To have a proper cert setup get pushed out to the client, there needs to be a 
more complex setup on the backend than is originally thought.

My server and AD team is actively working on this.  This article is a good 
place to start, and it has links to other portions of the setup.  I hope this 
helps.  I’ll try to let everyone know how it works out when we are done.

https://docs.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-manage-cert-requirements<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows-server%2Fnetworking%2Ftechnologies%2Fnps%2Fnps-manage-cert-requirements=04%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C8893b44473f649d94eb608d86fa576df%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637382104479605004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=%2Fbjj%2FDz%2BdScw%2FzC%2FE3xfmihCpDvUkZ8RvCO1eSrXO%2FI%3D=0>


__
__


Fishel Erps,
Sr. Network & Infrastructure Engineer
School of Visual Arts

136 W 21st St., 8th Floor

New York, NY, 10011

LL: 212-592-2416
E:  fe...@sva.edu<mailto:fe...@sva.edu>
___

Please excuse any typographical
errors as this e-mail has been sent
from my mobile device
___




On Oct 13, 2020, at 14:00, Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu<mailto:0194c9ecac40-dmarc-requ...@listserv.educause.edu>>
 wrote:

Just do a quick Google search and you’ll see how many situations instruct users 
to not validate the server identity (across many operating systems).

It is (and has always been) the #1 problem with legacy credentials/auth methods 
with tunneled EAP.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Tuesday, October 13, 2020 at 13:59
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification
I too am also interested.

Michael Catania
Sr. Network Analyst
Information Technology Services
Loyola University Chicago
P: 773.508.3712| E: mcata...@luc.edu<mailto:mcata...@luc.edu>

From: Gray, Sean<mailto:sean.gr...@uleth.ca>
Sent: Tuesday, October 13, 2020 12:57 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification

Hi Philippe,

Thanks for sharing.

I’m interested to know if there are any higher Ed institutes out there that 
don’t onboard clients and push the necessary certs out? How will you be 
handling this change?

Thanks

Sean

Sean Gray | B.Sc (Hons)
Voice, Collaboration & Wireless Network Analyst
ITS, University of Lethbridge

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Philippe Hanset
Sent: October 13, 2020 11:23 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [WIRELESS-LAN] Android 11 and Cert Verification

Caution: This email was sent from someone outside of the University of 
Lethbridge. Do not click on links or open attachments unless you know they are 
safe. Suspicious emails should be forwarded to 
phish...@uleth.ca<mailto:phish...@uleth.ca>.

It might have been mentioned on this list before.
With this one, repetition might not be a bad idea…

[PSA] Android 11's December security update wi

Re: [WIRELESS-LAN] Android 11 and Cert Verification

[Tim Cappalli]

*organizations, not situations.

From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Tuesday, October 13, 2020 at 14:00
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification
Just do a quick Google search and you’ll see how many situations instruct users 
to not validate the server identity (across many operating systems).

It is (and has always been) the #1 problem with legacy credentials/auth methods 
with tunneled EAP.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Tuesday, October 13, 2020 at 13:59
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification
I too am also interested.

Michael Catania
Sr. Network Analyst
Information Technology Services
Loyola University Chicago
P: 773.508.3712| E: mcata...@luc.edu

From: Gray, Sean
Sent: Tuesday, October 13, 2020 12:57 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification

Hi Philippe,

Thanks for sharing.

I’m interested to know if there are any higher Ed institutes out there that 
don’t onboard clients and push the necessary certs out? How will you be 
handling this change?

Thanks

Sean

Sean Gray | B.Sc (Hons)
Voice, Collaboration & Wireless Network Analyst
ITS, University of Lethbridge

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Philippe Hanset
Sent: October 13, 2020 11:23 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] Android 11 and Cert Verification

Caution: This email was sent from someone outside of the University of 
Lethbridge. Do not click on links or open attachments unless you know they are 
safe. Suspicious emails should be forwarded to 
phish...@uleth.ca.

It might have been mentioned on this list before.
With this one, repetition might not be a bad idea…

[PSA] Android 11's December security update will remove the ability to disable 
EAP server cert validation

https://www.reddit.com/r/networking/comments/j7ero1/psa_android_11s_december_security_update_will/


Best,

Philippe

Philippe Hanset, CEO
www.anyroam.net
Operator of eduroam-US






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


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

Re: [WIRELESS-LAN] Android 11 and Cert Verification

[Tim Cappalli]

Just do a quick Google search and you’ll see how many situations instruct users 
to not validate the server identity (across many operating systems).

It is (and has always been) the #1 problem with legacy credentials/auth methods 
with tunneled EAP.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Tuesday, October 13, 2020 at 13:59
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification
I too am also interested.

Michael Catania
Sr. Network Analyst
Information Technology Services
Loyola University Chicago
P: 773.508.3712| E: mcata...@luc.edu

From: Gray, Sean
Sent: Tuesday, October 13, 2020 12:57 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Android 11 and Cert Verification

Hi Philippe,

Thanks for sharing.

I’m interested to know if there are any higher Ed institutes out there that 
don’t onboard clients and push the necessary certs out? How will you be 
handling this change?

Thanks

Sean

Sean Gray | B.Sc (Hons)
Voice, Collaboration & Wireless Network Analyst
ITS, University of Lethbridge

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Philippe Hanset
Sent: October 13, 2020 11:23 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] Android 11 and Cert Verification

Caution: This email was sent from someone outside of the University of 
Lethbridge. Do not click on links or open attachments unless you know they are 
safe. Suspicious emails should be forwarded to 
phish...@uleth.ca.

It might have been mentioned on this list before.
With this one, repetition might not be a bad idea…

[PSA] Android 11's December security update will remove the ability to disable 
EAP server cert validation

https://www.reddit.com/r/networking/comments/j7ero1/psa_android_11s_december_security_update_will/


Best,

Philippe

Philippe Hanset, CEO
www.anyroam.net
Operator of eduroam-US





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


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

Re: Wireless Device Policy Questions

[Tim Cappalli]

Every device registered in CPPM has a username bound to the device account. 
That username can be checked against an external authorization source whenever 
the device connects.

CPPM has had headless device registration since day 1 of the product.




From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Jennifer Minella 

Sent: Friday, September 25, 2020 17:42
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] Wireless Device Policy Questions


I’ve seen a range from “no lifeguard on duty” aka “good luck” with a basic 
low-security Internet-only network to managing specific device registrations 
tied to the user; typically the personal device registrations are going to be 
MAC -based, and I’ve seen several unis with home-grown MAC registration systems 
tied to user accounts and of course as Tim and Mike mentioned, ClearPass also 
does this. There are some caveats (or specific requirements) with ClearPass 
though, if you want it (the MAC-registered device) tied to the user’s account 
then you need to be using a user-based authentication at the SSID profile 
level; meaning, last I saw in POCs, there wasn’t a way to have a 
self-registration portal within CPPM that allowed a user to enter those 
credentials on something like the portal, then tie a MAC-registration to it. 
Other products like FortiNAC do meet that specific use case, as possibly other 
products as well.



Most schools we’ve worked with do have some type of limit for devices that can 
be registered but those do all have some type of self-service portal so the 
students can add/remove their devices. The allowed number of devices ranges.



___

Jennifer Minella, CISSP, HP MASE

VP of Engineering & Security

Carolina Advanced Digital, Inc.

www.cadinc.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cadinc.com%2F=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C1bd96ed1b58041a0fac508d8619bd89a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63739295584367=d%2FZFguoxMqYoyJ9iIhJartuVEbF6UHNID0hL1%2Bj44K4%3D=0>

j...@cadinc.com<mailto:j...@cadinc.com>

919.460.1313 Main Office

919.539.2726 Mobile/text

[CAD LOGO EMAIL SIG]



From: Michael Dickson 
Sent: Friday, September 25, 2020 10:29 AM
Subject: Re: Wireless Device Policy Questions



We use Clearpass for user MAC reg portal and for device fingerprinting. We have 
a special bit set in LDAP (AD) that we check for when a device seeks to auth 
onto a wireless network. If we need to prevent all user devices from getting 
connected we disable the bit. A relatively short reauth interval will prevent 
reauths.

Mike


Michael Dickson

Network Engineer

Information Technology

University of Massachusetts Amherst

413-545-9639

michael.dick...@umass.edu<mailto:michael.dick...@umass.edu>

PGP: 0x16777D39

On 9/25/20 10:25 AM, Tim Cappalli wrote:

If you're using Aruba ClearPass, you can add an account check during 
authorization.







From: The EDUCAUSE Wireless Issues Community Group Listserv 
<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
on behalf of Tristan Gulyas 
<004c763654fc-dmarc-requ...@listserv.educause.edu><mailto:004c763654fc-dmarc-requ...@listserv.educause.edu>
Sent: Thursday, September 24, 2020 20:34
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Wireless Device Policy Questions



Hi,



We're considering this approach, however we need a way to die this in with AD 
account status/expiry which needs to be near-instant, i.e. if an AD 
account/identity for a user is disabled, we need to immediately deregister or 
suspend ALL devices they have registered to their identity, otherwise things 
get ugly from an infosec perspective.



I'm assuming freeradius+web-based front end for registration? How do you 
perform the device fingerprinting? That's a very cool solution!



Cheers,

Tristan

--

TRISTAN GULYAS

Senior Network Engineer



Technology Services, eSolutions

Monash University

738 Blackburn Road

Clayton 3168

Australia



E: tristan.gul...@monash.edu<mailto:tristan.gul...@monash.edu>

monash.edu<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmonash.edu%2F=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C1bd96ed1b58041a0fac508d8619bd89a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63739295584367=CGHVNqxz3fYuAis2ZwJTNNzboGDyFeLc8OkQ6hoWIkU%3D=0>



On 25 Sep 2020, at 3:11 am, Michael Dickson 
mailto:mdick...@nic.umass.edu>> wrote:



We created a PSK SSID with MAC auth registration for devices. We limit device 
types to essentially the "consumer grade entertainment devices" genre. We use 
device fingerprinting to accomplish this. We started from a "deny all then 
allow" paradigm. Only game consoles during pilot. Then added video streaming 
dev

Re: [WIRELESS-LAN] Wireless Device Policy Questions

[Tim Cappalli]

If you're using Aruba ClearPass, you can add an account check during 
authorization.



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Tristan Gulyas 
<004c763654fc-dmarc-requ...@listserv.educause.edu>
Sent: Thursday, September 24, 2020 20:34
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] Wireless Device Policy Questions


Hi,

We're considering this approach, however we need a way to die this in with AD 
account status/expiry which needs to be near-instant, i.e. if an AD 
account/identity for a user is disabled, we need to immediately deregister or 
suspend ALL devices they have registered to their identity, otherwise things 
get ugly from an infosec perspective.

I'm assuming freeradius+web-based front end for registration? How do you 
perform the device fingerprinting? That's a very cool solution!

Cheers,
Tristan

--

TRISTAN GULYAS
Senior Network Engineer

Technology Services, eSolutions
Monash University
738 Blackburn Road
Clayton 3168
Australia

E: tristan.gul...@monash.edu
monash.edu

On 25 Sep 2020, at 3:11 am, Michael Dickson 
mailto:mdick...@nic.umass.edu>> wrote:

We created a PSK SSID with MAC auth registration for devices. We limit device 
types to essentially the "consumer grade entertainment devices" genre. We use 
device fingerprinting to accomplish this. We started from a "deny all then 
allow" paradigm. Only game consoles during pilot. Then added video streaming 
devices then AppleTV, Echo, SmartTVs, etc. Easier to add device types then take 
away. 802.1x capable devices get denied. We also limit number of devices a user 
can register. All helps to mitigate the flood of industrial IT devices coming 
in from campus wide vendors, some of which may fall into the life-safety genre. 
Vendors get stuck and end up asking how they can add "a lot" of sensors (e.g. 
HVAC) to our wireless. We have a discussion, give it a thumbs up or down, and 
create rules/policies/networks as needed. Good but not perfect. But starting 
off closed then letting out the line has helped. Having a PSK network also 
solves the issue of devices that can't connect to open SSIDs. And if we end up 
just allowing all on the devices network at least we have a sponsor to tie the 
devices back to.

Mike Dickson

Michael Dickson
Network Engineer
Information Technology
University of Massachusetts Amherst
413-545-9639
michael.dick...@umass.edu
PGP: 0x16777D39

On 9/24/20 11:33 AM, Lee H Badman wrote:

We created an open SSID for the dorms that has Internet access only. It helps 
with maybe ¾ of the consumer devices, but there are still some home gadgets 
that need more- Chromecast is one example. Some speakers as well. Then there 
are devices that will ONLY join PSK networks (like TP-Link power strip) so the 
open won’t work there. I have seen one Nanoleaf light controller that will not 
work in 2.4 if it sees 5 GHz, and it only works in 2.4 despite the ability to 
sense 5. The unholy and expensive things needed to make these high end 
enterprise systems work like home Wi-Fi is really fairly astounding.



If you go this route, expect to occasionally buy and try consumer gear to 
verify what works and what doesn’t, and to play whack a mole with students 
wireless hotspots when whatever you attempt doesn’t immediately work.



Or… let them use their own hotspots and be done with it. (If only…)



Lee Badman







Lee Badman | Network Architect (CWNE#200)

Information Technology Services
(NDD Group)
206 Machinery Hall
120 Smith Drive
Syracuse, New York 13244

t 315.443.3003   e lhbad...@syr.edu w 
its.syr.edu

Campus Wireless Policy: 
https://answers.syr.edu/display/network/Wireless+Network+and+Systems

SYRACUSE UNIVERSITY
syr.edu



From: 

Re: [WIRELESS-LAN] Android 11 and WPA-Enterprise

[Tim Cappalli]

You should avoid using a public CA issued web server certificates for an EAP 
server identity wherever possible.

But to directly answer your question, yes, you'd select Use System Certificates 
and set the subject name.


From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Tariq Adnan 
<01e6b38f57b3-dmarc-requ...@listserv.educause.edu>
Sent: Tuesday, September 22, 2020, 22:04
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Android 11 and WPA-Enterprise

Hi Tim,

How about choosing “use system certificate”, provided the CA cert is a valid 
public cert (QuoVadis CA) and in default certificate store of Android?

Thanks,



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Fishel Erps
Sent: Wednesday, 23 September 2020 5:17 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Android 11 and WPA-Enterprise

Tim,

Thank you.  This was extremely helpful.


__
__


Fishel Erps,
Sr. Network & Infrastructure Engineer
School of Visual Arts

136 W 21st St., 8th Floor

New York, NY, 10011

LL: 212-592-2416
E:  fe...@sva.edu<mailto:fe...@sva.edu>
___

Please excuse any typographical
errors as this e-mail has been sent
from my mobile device
___




On Sep 22, 2020, at 15:13, Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu<mailto:0194c9ecac40-dmarc-requ...@listserv.educause.edu>>
 wrote:

Fishel - as an aside, if the configuration guidance to users has been to ignore 
the EAP server identity or configure their devices to not validate it and the 
credential used for Wi-Fi is their primary password, I highly recommend you 
issue an organization-wide password reset as all of those credentials may have 
been compromised.



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Felix Windt 
mailto:felix.wi...@dartmouth.edu>>
Sent: Tuesday, September 22, 2020 15:10
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] Android 11 and WPA-Enterprise


https://www.eduroam.org/configuration-assistant-tool-cat/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-au.mimecast.com%2Fs%2FH83ZCk81N9t2QxV6f2CKrv%3Fdomain%3Deduroam.org%2F=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7Ce931942d792949012b0508d85f64f7ac%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637364234554596634=pdW1tfy9ba96gP3PYEFJVCBsTneUnVhbNvx0DmbaVcs%3D=0>



thx,

felix



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Patrick Mauretti 
mailto:pmaure...@massasoit.mass.edu>>
Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Tuesday, September 22, 2020 at 3:02 PM
To: 
"WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>" 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] Android 11 and WPA-Enterprise



Okay I’ll bite.  What’s the CAT tool you mentioned?  Link?



-Patrick





From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Floyd, Brad
Sent: Tuesday, September 22, 2020 3:00 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Android 11 and WPA-Enterprise



CAUTION: This email originated from outside of Massasoit. Do not click links or 
open attachments unless you recognize the sender and know the content is safe.



Fishel,

We have run into this on some versions of Android OS and the solution that 
works for us is to import our CA’s root certificate into the device. Once we 
import the root certificate and select it during the profile setup, the 
connection is established.

Thanks,

Brad



From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Fishel Erps
Sent: Tuesday, September 22, 2020 12:10 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Android 11 and WPA-Enterprise



Tim,



We use:



EAP Method = PEAP

Phase 2 = MSCHAPv2

CA Certificate = Unspecified

Identity = [username]

Password = [password]



The credentials trigger the return of a filter-ID from the RADIUS server to the 
controller, which the controller then uses to put the user into a VLAN.



Some android devices that are running version 11 no-longer have an option of 
“unspecified” under CA Certificate, and none of the other choices seem to work.







___

Re: [WIRELESS-LAN] Android 11 and WPA-Enterprise

[Tim Cappalli]

Fishel - as an aside, if the configuration guidance to users has been to ignore 
the EAP server identity or configure their devices to not validate it and the 
credential used for Wi-Fi is their primary password, I highly recommend you 
issue an organization-wide password reset as all of those credentials may have 
been compromised.



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Felix Windt 

Sent: Tuesday, September 22, 2020 15:10
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] Android 11 and WPA-Enterprise


https://www.eduroam.org/configuration-assistant-tool-cat/



thx,

felix



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Patrick Mauretti 

Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Tuesday, September 22, 2020 at 3:02 PM
To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" 
Subject: Re: [WIRELESS-LAN] Android 11 and WPA-Enterprise



Okay I’ll bite.  What’s the CAT tool you mentioned?  Link?



-Patrick





From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Floyd, Brad
Sent: Tuesday, September 22, 2020 3:00 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Android 11 and WPA-Enterprise



CAUTION: This email originated from outside of Massasoit. Do not click links or 
open attachments unless you recognize the sender and know the content is safe.



Fishel,

We have run into this on some versions of Android OS and the solution that 
works for us is to import our CA’s root certificate into the device. Once we 
import the root certificate and select it during the profile setup, the 
connection is established.

Thanks,

Brad



From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Fishel Erps
Sent: Tuesday, September 22, 2020 12:10 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Android 11 and WPA-Enterprise



Tim,



We use:



EAP Method = PEAP

Phase 2 = MSCHAPv2

CA Certificate = Unspecified

Identity = [username]

Password = [password]



The credentials trigger the return of a filter-ID from the RADIUS server to the 
controller, which the controller then uses to put the user into a VLAN.



Some android devices that are running version 11 no-longer have an option of 
“unspecified” under CA Certificate, and none of the other choices seem to work.







__
__



Fishel Erps,

Sr. Network & Infrastructure Engineer

School of Visual Arts

136 W 21st St., 8th Floor

New York, NY, 10011

LL: 212-592-2416

E:  fe...@sva.edu<mailto:fe...@sva.edu>
___

Please excuse any typographical

errors as this e-mail has been sent

from my mobile device

___





On Sep 22, 2020, at 12:04, Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu<mailto:0194c9ecac40-dmarc-requ...@listserv.educause.edu>>
 wrote:

Can you please provide some basic details?

  *   What exactly is "broken"?
  *   Which EAP method?
  *   Which credential type?
  *   How is/was the supplicant provisioned?
  *   Are only new devices affected or just upgraded devices?



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Fishel Erps 
<0030ecf871d2-dmarc-requ...@listserv.educause.edu<mailto:0030ecf871d2-dmarc-requ...@listserv.educause.edu>>
Sent: Tuesday, September 22, 2020 12:02
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: [WIRELESS-LAN] Android 11 and WPA-Enterprise



Hi,



v11 seems to have broken credential authentication for RADIUS and 
WPA2-Enterprise/802.1x.



Has anyone found a workaround?





__
__



Fishel Erps,

Sr. Network & Infrastructure Engineer

School of Visual Arts

136 W 21st St., 8th Floor

New York, NY, 10011

LL: 212-592-2416

C:  347-539-6380

E:  fe...@sva.edu<mailto:fe...@sva.edu>
___

Please excuse any typographical

errors as this e-mail has been sent

from my mobile device

___



**
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%7Cd8595

Re: [WIRELESS-LAN] [External] Re: [WIRELESS-LAN] Android 11 and WPA-Enterprise

[Tim Cappalli]

You can only install a CA from inside the Settings now to prevent users from 
unintentionally installing a malicious root.

Assuming you don't have a commercial supplicant provisioning platform, why not 
just use the CAT tool?

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Hunter Fuller 
Sent: Tuesday, September 22, 2020 14:15
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] [External] Re: [WIRELESS-LAN] Android 11 and 
WPA-Enterprise

Try these instructions. We had one Android 11 user report that they
work. You will obviously need a copy of your institution's
certificate.

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fuah.teamdynamix.com%2FTDClient%2F2075%2FPortal%2FKB%2FArticleDet%3FID%3D84342data=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C7a6227f7cbbf452acf5208d85f238224%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637363953684306020sdata=2NjMMbhReWpbYGQk3pN6xNF%2BsxHpUnDSm1RTm5reIxQ%3Dreserved=0

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

On Tue, Sep 22, 2020 at 12:10 PM Fishel Erps
<0030ecf871d2-dmarc-requ...@listserv.educause.edu> wrote:
>
> Tim,
>
> We use:
>
> EAP Method = PEAP
> Phase 2 = MSCHAPv2
> CA Certificate = Unspecified
> Identity = [username]
> Password = [password]
>
> The credentials trigger the return of a filter-ID from the RADIUS server to 
> the controller, which the controller then uses to put the user into a VLAN.
>
> Some android devices that are running version 11 no-longer have an option of 
> “unspecified” under CA Certificate, and none of the other choices seem to 
> work.
>
>
>
>
> __
> __
>
> Fishel Erps,
> Sr. Network & Infrastructure Engineer
> School of Visual Arts
> 136 W 21st St., 8th Floor
> New York, NY, 10011
> LL: 212-592-2416
> E:  fe...@sva.edu
> ___
>
> Please excuse any typographical
> errors as this e-mail has been sent
> from my mobile device
> ___
>
>
> On Sep 22, 2020, at 12:04, Tim Cappalli 
> <0194c9ecac40-dmarc-requ...@listserv.educause.edu> wrote:
>
> 
> Can you please provide some basic details?
>
> What exactly is "broken"?
> Which EAP method?
> Which credential type?
> How is/was the supplicant provisioned?
> Are only new devices affected or just upgraded devices?
>
> 
> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>  on behalf of Fishel Erps 
> <0030ecf871d2-dmarc-requ...@listserv.educause.edu>
> Sent: Tuesday, September 22, 2020 12:02
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
> Subject: [WIRELESS-LAN] Android 11 and WPA-Enterprise
>
> Hi,
>
> v11 seems to have broken credential authentication for RADIUS and 
> WPA2-Enterprise/802.1x.
>
> Has anyone found a workaround?
>
>
>
> __
> __
>
> Fishel Erps,
> Sr. Network & Infrastructure Engineer
> School of Visual Arts
> 136 W 21st St., 8th Floor
> New York, NY, 10011
> LL: 212-592-2416
> C:  347-539-6380
> E:  fe...@sva.edu
> ___
>
> Please excuse any typographical
> errors as this e-mail has been sent
> from my mobile device
> ___
>
> **
> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunitydata=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C7a6227f7cbbf452acf5208d85f238224%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637363953684306020sdata=5R4mqpUD8YmQ%2BkaPMmmAwsxkYJ4EmCxmQG8%2B6EkBjIQ%3Dreserved=0
>
> **
> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunitydata=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C7a6227f7cbbf452acf5208d85f238224%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637363953684306020sdata=5R4mqpUD8YmQ%2BkaPMmmAwsxkYJ4EmCxmQG8%2B6EkBjIQ%3Dreserved=0
>
> **
> Replies 

Re: [WIRELESS-LAN] Android 11 and WPA-Enterprise

[Tim Cappalli]

Not validating the EAP server identity is not really a valid configuration. You 
need to properly configure the supplicant with a trust anchor and subject name.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Fishel Erps 
<0030ecf871d2-dmarc-requ...@listserv.educause.edu>
Sent: Tuesday, September 22, 2020 1:10:19 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] Android 11 and WPA-Enterprise

Tim,

We use:

EAP Method = PEAP
Phase 2 = MSCHAPv2
CA Certificate = Unspecified
Identity = [username]
Password = [password]

The credentials trigger the return of a filter-ID from the RADIUS server to the 
controller, which the controller then uses to put the user into a VLAN.

Some android devices that are running version 11 no-longer have an option of 
“unspecified” under CA Certificate, and none of the other choices seem to work.




__
__

Fishel Erps,
Sr. Network & Infrastructure Engineer
School of Visual Arts
136 W 21st St., 8th Floor
New York, NY, 10011
LL: 212-592-2416
E:  fe...@sva.edu<mailto:fe...@sva.edu>
___

Please excuse any typographical
errors as this e-mail has been sent
from my mobile device
___


On Sep 22, 2020, at 12:04, Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu<mailto:0194c9ecac40-dmarc-requ...@listserv.educause.edu>>
 wrote:


Can you please provide some basic details?

  *   What exactly is "broken"?
  *   Which EAP method?
  *   Which credential type?
  *   How is/was the supplicant provisioned?
  *   Are only new devices affected or just upgraded devices?


From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Fishel Erps 
<0030ecf871d2-dmarc-requ...@listserv.educause.edu<mailto:0030ecf871d2-dmarc-requ...@listserv.educause.edu>>
Sent: Tuesday, September 22, 2020 12:02
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: [WIRELESS-LAN] Android 11 and WPA-Enterprise

Hi,

v11 seems to have broken credential authentication for RADIUS and 
WPA2-Enterprise/802.1x.

Has anyone found a workaround?



__
__

Fishel Erps,
Sr. Network & Infrastructure Engineer
School of Visual Arts
136 W 21st St., 8th Floor
New York, NY, 10011
LL: 212-592-2416
C:  347-539-6380
E:  fe...@sva.edu<mailto:fe...@sva.edu>
___

Please excuse any typographical
errors as this e-mail has been sent
from my mobile device
___


**
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%7Cc1cc8384d36d4ea7a02608d85f1a63c9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637363914240525482=XrUKKt1wvdKB9xFzuUH6vexOPHjdWN0kEs2hP%2BGG9ik%3D=0>

**
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%7Cc1cc8384d36d4ea7a02608d85f1a63c9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637363914240535477=qUgKhY%2Bdb2sSPQAn1Qx%2BywuNQaBh7uWHyXXM8qfmeGM%3D=0>

**
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%7Cc1cc8384d36d4ea7a02608d85f1a63c9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637363914240535477=qUgKhY%2Bdb2sSPQAn1Qx%2BywuNQaBh7uWHyXXM8qfmeGM%3D=0>

**
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] Android 11 and WPA-Enterprise

[Tim Cappalli]

Can you please provide some basic details?

  *   What exactly is "broken"?
  *   Which EAP method?
  *   Which credential type?
  *   How is/was the supplicant provisioned?
  *   Are only new devices affected or just upgraded devices?


From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Fishel Erps 
<0030ecf871d2-dmarc-requ...@listserv.educause.edu>
Sent: Tuesday, September 22, 2020 12:02
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: [WIRELESS-LAN] Android 11 and WPA-Enterprise

Hi,

v11 seems to have broken credential authentication for RADIUS and 
WPA2-Enterprise/802.1x.

Has anyone found a workaround?



__
__

Fishel Erps,
Sr. Network & Infrastructure Engineer
School of Visual Arts
136 W 21st St., 8th Floor
New York, NY, 10011
LL: 212-592-2416
C:  347-539-6380
E:  fe...@sva.edu
___

Please excuse any typographical
errors as this e-mail has been sent
from my mobile device
___


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

RE: [WIRELESS-LAN] iOS 14 Causing ARP Spoofing Events on Aruba Controllers

[Tim Cappalli]

Asking users to disable a feature that preserves their privacy for what is 
really a one time event (after iOS upgrade) on your network seems very drastic 
and has a longer term impact.



From: Cody Ensanian
Sent: Monday, September 21, 2020 15:59
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] iOS 14 Causing ARP Spoofing Events on Aruba 
Controllers

Started running into the IOS14 issue the day it released. As soon as an apple 
device upgraded to IOS14 they got ARP-spoof blacklisted on our Aruba 
controllers.

Which makes sense to me: pre-upgrade its the devices real mac address/IP which 
is known by the controller… post-upgrade the “private address” toggle is turned 
on by default, so IOS generates a random mac address for any wireless network 
profile on the device. Now, the phone tries sending traffic with new-mac/IP 
combo and of course the controller now thinks its ARP spoofing.

Rather than turn off ARP-spoof detection on our controllers, we are telling our 
users that for OUR networks, they have to disable the “private address” 
feature. They can leave it enabled for other networks, but not ours.

During beta testing Apple said the “private address” was going to randomize 
daily. This has since been tested/proven to not be the case. It is randomized 
PER NETWORK (SSID), but will not change if you forget the network and come 
back. If you forget and come back, it will generate the same random mac for 
that network should you leave the toggle on (they must either hash it with the 
SSID, or the device keeps an internal table of all generated random macs and 
the network/SSID its meant for)

Cody
University of Colorado Colorado Springs


From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Michael Hulko
Sent: Monday, September 21, 2020 1:38 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] iOS 14 Causing ARP Spoofing Events on Aruba 
Controllers

Keep the list posted as I am sure this is having an effect on others…. Oddly 
though, we are not seeing this in our Campus 8.6x environment.  Our “Arp 
Spoofing” issue is with our Housing 6.5x environment.  As I stated earlier, we 
have a number of other fires going..   Since moving to 8.6x in April on the 
recommendation of our SE….


  1.  8.6x GUI issues with blacklisting…  the GUI reports more than what is 
actually happening on the controllers
  2.  IAP to controller tunnel challenges with clustered environment (8.6x) …  
(actually, TAC did come back after 2 weeks troubleshooting and confirmed that 
IAP to controller tunnels will not work when controllers are clustered)
  3.  AP200 series APs on the 8.6x environment started randomly rebooting with 
“out of memory” errors
  4.  7240XM controllers in the 8.6x environment having process crashes and 
restarts plus warnings of CPU utilization peaking over 90%
  5.  ‘Arp Spoofing’
  6.  We are also detecting AP300 series reboots, but have not made any attempt 
to monitor or track these instances at this time.



Not to mention the myriad of user complaints that we generally field



Start of another school year



M

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@listserv.educause.edu>> 
on behalf of Nick Rauer 
mailto:rauer_nicho...@wheatoncollege.edu>>
Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@listserv.educause.edu>>
Date: Monday, September 21, 2020 at 2:12 PM
To: 
"WIRELESS-LAN@listserv.educause.edu" 
mailto:WIRELESS-LAN@listserv.educause.edu>>
Subject: Re: [WIRELESS-LAN] iOS 14 Causing ARP Spoofing Events on Aruba 
Controllers

We just wrapped up a week's worth of troubleshooting with Aruba TAC and a group 
of Aruba developers to troubleshoot a similar issue. They ultimately 
recommended we disable blacklisting clients for “Arp Spoof”. They did not 
correlate the issue related to the iOS update, though. I still have the case 
open, and will pass along the message. We are also seeing users complaining of 
their Windows 10 devices intermittently not connecting to an SSID after waking 
from sleep mode. We are still investigating that issue.

We have an MM/MC dual 7220 Cluster running 8.5.0.9 / AP300,AP500 series 
Deployed.

Thanks,
Nick Rauer
Manager of Networking and Telecommunications
Wheaton College – Massachusetts


From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Michael Hulko
Sent: Monday, September 21, 2020 1:10 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] iOS 14 Causing ARP Spoofing Events on Aruba 
Controllers

Yup.. we had to disable the “Arp Spoof” settings in the IDS profiles.  We have 
other irons in the fire so we are not able to do much to investigate this issue 
at this time.

M

From: The EDUCAUSE Wireless 

Re: [WIRELESS-LAN] MAC authentication bypass on Freeradius

[Tim Cappalli]

Yes, EAP-TLS, EAP-TTLS and PEAPv0/EAP-MSCHAPv2 are the common three EAP methods 
deployed, with TEAP becoming more popular.

Great care should be taken when using a legacy method like PEAPv0 with user 
credentials. Ensure the device is under management and the user cannot modify 
the supplicant configuration (same with EAP-TTLS/PAP or EAP-TTLS/MSCHAPv2).

Ideally these devices should just use what the rest of your students, faculty 
and staff are using.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Nadim El-Khoury 

Sent: Friday, August 28, 2020 10:35
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] MAC authentication bypass on Freeradius

Hi Tim,

Thank you for the information and advice.
Maybe use EAP-TLS or PEAP with EAP-TLS as the inner authentication method.
Do you think that would work?
Has anyone done that with Freeradius and eduroam?

Best,

Nadim

On Fri, Aug 28, 2020 at 9:57 AM Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu<mailto:0194c9ecac40-dmarc-requ...@listserv.educause.edu>>
 wrote:
eduroam is an 802.1X network. You need to use an EAP-based authentication 
method. MAC address can only be used as authorization context (but really 
shouldn't be).

Tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Nadim El-Khoury 
mailto:nel-kho...@springfield.edu>>
Sent: Friday, August 28, 2020 9:52:08 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC authentication bypass on Freeradius

Hi Norman,

Let me better explain what we trying to do.
We used to have an open hidden SSID using a WEP key to connect loaner laptops 
(Windows, Macs), iPads, and Chromebooks.
We upgraded our wireless network to MIST and we decided to only advertise 
eduroam.
We want to connect the above devices to eduroam using Mac address 
authentication, and it is not working.

Best,

Nadim

On Thu, Aug 27, 2020 at 9:38 PM Norman Elton 
mailto:normel...@gmail.com>> wrote:
Do you mean authenticate non-802.1x clients based on MAC address? Yes.
It works fine. We have an Open Access SSID, with "MAC address
authentication by RADIUS lookup". We provide our RADIUS server IP &
secret. Our FreeRADIUS server takes the request and responds with an
Accept/Reject, and the following attributes:

Tunnel-Type = "GRE"
Tunnel-Medium-Type = "IP"
Tunnel-Private-Group-ID = 

I don't remember any specific challenges, but if you can post what's
not working, I'm happy to help. And/or jump on a call and compare
experience with Mist.

Norman

On Thu, Aug 27, 2020 at 4:14 PM Nadim El-Khoury
mailto:nel-kho...@springfield.edu>> wrote:
>
> Hi Everyone,
>
> Has anyone been able to get MAC authentication bypass to work properly with 
> FreeRadius and MIST Wireless?
>
> Best,
>
> Nadim
>
> **
> 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%7Cf91dcafd78c2405c684708d84b5fb775%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637342221762326655=mq1H8E2Amsn5z9dMJ73oF%2BOf7vkhElvkqWRwnEhW7YM%3D=0>

**
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%7Cf91dcafd78c2405c684708d84b5fb775%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637342221762336640=3DtoqRGRwWWQ6Thqj%2BCWgF28C7rw7zuR7Vu35fLYeXI%3D=0>

**
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%7Cf91dcafd78c2405c684708d84b5fb775%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637342221762336640=3DtoqRGRwWWQ6Thqj%2BCWgF28C7rw7zuR7Vu35fLYeXI%3D=0

Re: [WIRELESS-LAN] MAC authentication bypass on Freeradius

[Tim Cappalli]

eduroam is an 802.1X network. You need to use an EAP-based authentication 
method. MAC address can only be used as authorization context (but really 
shouldn't be).

Tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Nadim El-Khoury 

Sent: Friday, August 28, 2020 9:52:08 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] MAC authentication bypass on Freeradius

Hi Norman,

Let me better explain what we trying to do.
We used to have an open hidden SSID using a WEP key to connect loaner laptops 
(Windows, Macs), iPads, and Chromebooks.
We upgraded our wireless network to MIST and we decided to only advertise 
eduroam.
We want to connect the above devices to eduroam using Mac address 
authentication, and it is not working.

Best,

Nadim

On Thu, Aug 27, 2020 at 9:38 PM Norman Elton 
mailto:normel...@gmail.com>> wrote:
Do you mean authenticate non-802.1x clients based on MAC address? Yes.
It works fine. We have an Open Access SSID, with "MAC address
authentication by RADIUS lookup". We provide our RADIUS server IP &
secret. Our FreeRADIUS server takes the request and responds with an
Accept/Reject, and the following attributes:

Tunnel-Type = "GRE"
Tunnel-Medium-Type = "IP"
Tunnel-Private-Group-ID = 

I don't remember any specific challenges, but if you can post what's
not working, I'm happy to help. And/or jump on a call and compare
experience with Mist.

Norman

On Thu, Aug 27, 2020 at 4:14 PM Nadim El-Khoury
mailto:nel-kho...@springfield.edu>> wrote:
>
> Hi Everyone,
>
> Has anyone been able to get MAC authentication bypass to work properly with 
> FreeRadius and MIST Wireless?
>
> Best,
>
> Nadim
>
> **
> 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

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

RE: Aruba Captive Portals and Login Pages

[Tim Cappalli]

The MAC address is appended to the redirect URL (login-page) as the query 
parameter “mac” on all Aruba platforms automatically.

tim

From: Higgins, Benjamin J
Sent: Tuesday, August 25, 2020 14:30
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] Aruba Captive Portals and Login Pages

Words from the trenches:

Anyone here know if you can pass the MAC Address to ClearPass when using a 
“login-page” in an “aaa authentication captive-portal”?  If so, how would you 
do it.

Appreciated!

--ben

--
Benjamin J. Higgins (‘97)   |  bjhigg...@wpi.edu
Manager of Network Operations   |  Office 508.831.4860
Worcester Polytechnic Institute |  Cell   508.713.1739


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

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

[Tim Cappalli]

I was saying there are very few organizations that truly have every resource, 
where the primary password is used, enabled for MFA.


From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Scott Bertilson 
<01d368c4bbc6-dmarc-requ...@listserv.educause.edu>
Sent: Wednesday, August 19, 2020 4:45:27 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates 
affecting 802.1X?

Tim commented:
...I highly doubt a majority of organizations have every single non-Wi-Fi 
resource protected with strong MFA at this point in time.

In our case, we use PEAP and use the same PW for WiFi as for everything else, 
but most of everything else (and growing) requires MFA.  I hope that's what he 
meant or else I'm missing something about how you make MFA work for WiFi in any 
large installation.

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

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

[Tim Cappalli]

I’ll respond, but we’re drifting really far from the original tactical 
conversation/ask. This is a great conversation, but I think maybe a separate 
thread to discuss the points you brought up might be better as many are either 
forward looking (do we need identity for Wi-Fi) or comparing attack vectors.


RE: compromised databases, yeah sure, but that assumes those credentials are 
there and still active. If I sit near University A and get 100 credentials, 
there’s a lot more guarantee I’m going to be able to do something malicious 
with very little work.

RE: MFA, sure that’s a huge part of the conversation, but I highly doubt a 
majority of organizations have every single non-Wi-Fi resource protected with 
strong MFA at this point in time.

tim


From: Jeffrey D. Sessler<mailto:j...@scrippscollege.edu>
Sent: Wednesday, August 19, 2020 14:28
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates 
affecting 802.1X?

Tim,

Isn’t it easier for a bad actor to pull user/passwords from the various online 
compromised credential databases, then collect them from WiFi scanning?  It 
would be interesting to correlate wifi harvested credentials with the various 
compromised credential databases, looking for matches. One could then evaluate 
the effectiveness of the scanning over the alternative and less risky use of 
the database.

It’s the economics of thievery, and I’m not convinced someone would go to the 
trouble of WiFi scanning given the alternative.

And for those using password-based auth (primary credentials), then the easy 
defense is MFA, where the bad actor would be limited to only WiFi access.  For 
those that treat WiFi as a hostile network and not as a permission to access 
resouces, at best this person gets free WiFi access.

Jeff


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

The underlying protocols used with PEAP are legacy. Usage in the wild does not 
dictate whether a protocol is legacy or not.

My one specific comment is to this:


  *   As a bad actor, why would I spend time trying to compromise a WiFi 
network, when it’s far easier to send your organization phishing emails?

It is incredibly easy. During non-COVID times, I can sit in downtown Boston and 
harvest hundreds of user credentials in an hour with software that can be 
configured in 10 minutes. This kind of passive “attack” is far worse than a 
phishing attempt.


In closing (unless there are other direct technical questions), if you’re going 
to use password-based authentication, please do not use the user’s primary 
credential. Generate a network-specific credential that the user can use for 
Wi-Fi. If we can make this the baseline, many concerns would go away.

tim


From: Jeffrey D. Sessler<mailto:j...@scrippscollege.edu>
Sent: Wednesday, August 19, 2020 13:38
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates 
affecting 802.1X?

For a student population that will only be with the institution for 4 years, 
and then spend the next 60 years using WiFi options with lower barriers and 
potentially a little more risk, are EDU’s getting it wrong? Are we too focused 
on something with low risk while ignoring other higher risk issues? At the 
point one needs complicated provisioning tools, your userbase sees only 
barriers, and then wonders why the other 99% of places they frequent don’t 
require such inconveniences.

The key is a _realistic_ risk assessment. There are plenty of examples outside 
of technology e.g. the lock on your doors, where it’s a given there are no 
silver bullets and we choose based on risk vs cost.  Do you spend thousands of 
dollars to put Bowley locks on your doors, or accept that in most situations, 
the $20 kwickset locks are good enough?  As a bad actor, why would I spend time 
trying to compromise a WiFi network, when it’s far easier to send your 
organization phishing emails? Phishing can be done remotely and exploit the 
greatest weakest (humans).  A successful phish/compromise and I’m well past the 
front door, the expensive locks, and enjoying a beer from your refrigerator.

According to by eduroam guest reports, PEAP still dominates everything else at 
89.7% vs 8.3% for EAP-TLS and 1.97% for EAP-TTLS. I don’t know that I’d call 
that legacy, and while it does have weakness, how would one compare it to an 
institution that may not have the best security controls around their 
provisioning tools? A compromise of one’s provisioning tool, say because of 
admins using weak passwords and/or no MFA, may present a higher security risk 
than the use of PEAP.

Jeff


Fro

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

[Tim Cappalli]

The underlying protocols used with PEAP are legacy. Usage in the wild does not 
dictate whether a protocol is legacy or not.

My one specific comment is to this:


  *   As a bad actor, why would I spend time trying to compromise a WiFi 
network, when it’s far easier to send your organization phishing emails?

It is incredibly easy. During non-COVID times, I can sit in downtown Boston and 
harvest hundreds of user credentials in an hour with software that can be 
configured in 10 minutes. This kind of passive “attack” is far worse than a 
phishing attempt.


In closing (unless there are other direct technical questions), if you’re going 
to use password-based authentication, please do not use the user’s primary 
credential. Generate a network-specific credential that the user can use for 
Wi-Fi. If we can make this the baseline, many concerns would go away.

tim


From: Jeffrey D. Sessler<mailto:j...@scrippscollege.edu>
Sent: Wednesday, August 19, 2020 13:38
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates 
affecting 802.1X?

For a student population that will only be with the institution for 4 years, 
and then spend the next 60 years using WiFi options with lower barriers and 
potentially a little more risk, are EDU’s getting it wrong? Are we too focused 
on something with low risk while ignoring other higher risk issues? At the 
point one needs complicated provisioning tools, your userbase sees only 
barriers, and then wonders why the other 99% of places they frequent don’t 
require such inconveniences.

The key is a _realistic_ risk assessment. There are plenty of examples outside 
of technology e.g. the lock on your doors, where it’s a given there are no 
silver bullets and we choose based on risk vs cost.  Do you spend thousands of 
dollars to put Bowley locks on your doors, or accept that in most situations, 
the $20 kwickset locks are good enough?  As a bad actor, why would I spend time 
trying to compromise a WiFi network, when it’s far easier to send your 
organization phishing emails? Phishing can be done remotely and exploit the 
greatest weakest (humans).  A successful phish/compromise and I’m well past the 
front door, the expensive locks, and enjoying a beer from your refrigerator.

According to by eduroam guest reports, PEAP still dominates everything else at 
89.7% vs 8.3% for EAP-TLS and 1.97% for EAP-TTLS. I don’t know that I’d call 
that legacy, and while it does have weakness, how would one compare it to an 
institution that may not have the best security controls around their 
provisioning tools? A compromise of one’s provisioning tool, say because of 
admins using weak passwords and/or no MFA, may present a higher security risk 
than the use of PEAP.

Jeff


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

My old colleagues likely won’t be happy with me saying this, but given the 
industry changes, I think you should collectively pressure NAC vendors to make 
device provisioning part of the core product without the need for additional 
licensing (at least for EDU).




From: Tim Tyler<mailto:ty...@beloit.edu>
Sent: Wednesday, August 19, 2020 12:39
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates 
affecting 802.1X?

Yes, I always find this conversation to be interesting.  There are many 
institutions that can’t afford an on-boarding solution.   Hence, the certs 
usually get ignored since most configurations are manual or semi-automatic.  
And my thought is that mac address registration would eliminate the 
vulnerability of user’s credentials via network authentication.  So this is 
something I keep thinking might be better than 802.1x if certs are going to get 
ignored anyways.
  But the recent conversation on mac addresses potentially becoming dynamic 
will make me strongly hesitate on this thought.
Tim


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 securi

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?

[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: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X?

[Tim Cappalli]

My old colleagues likely won’t be happy with me saying this, but given the 
industry changes, I think you should collectively pressure NAC vendors to make 
device provisioning part of the core product without the need for additional 
licensing (at least for EDU).




From: Tim Tyler<mailto:ty...@beloit.edu>
Sent: Wednesday, August 19, 2020 12:39
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates 
affecting 802.1X?

Yes, I always find this conversation to be interesting.  There are many 
institutions that can’t afford an on-boarding solution.   Hence, the certs 
usually get ignored since most configurations are manual or semi-automatic.  
And my thought is that mac address registration would eliminate the 
vulnerability of user’s credentials via network authentication.  So this is 
something I keep thinking might be better than 802.1x if certs are going to get 
ignored anyways.
  But the recent conversation on mac addresses potentially becoming dynamic 
will make me strongly hesitate on this thought.
Tim


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, August 19, 2020 12:12
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto: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.
#  In that case, this CA file should contain
#  *one* CA certificate.

Thanks,
Dennis

From: The EDUCAUSE Wire

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

[Tim Cappalli]

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, August 19, 2020 12:12
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto: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.
#  In that case, this CA file should contain
#  *one* CA certificate.

Thanks,
Dennis

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

CAUTION: This email originated from outside of the University of Guelph. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe. If in doubt, forward suspicious emails to 
ith...@uoguelph.ca<mailto:ith...@uoguelph.ca>

Good clarification, thanks.  In previous discussions, our identity group 
mentioned using PKI that they use for other systems.

Note to self, be careful what you ask for.




Mike Atkins
Network Engineer
Office of Information Technology
University of Notre Dame

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:34 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?

Got it.

Just to clarify, a self-signed EAP server certificate should never be used. A 
server certificate issued by a PKI under your control is the best deployment 
practice (which is not the same as a self-signed certificate).

tim

From: Mike Atkins<mailto:matk...@nd.edu>
Sent: Wednesday, August 19, 2020 11:31
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.E

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

[Tim Cappalli]

Got it.

Just to clarify, a self-signed EAP server certificate should never be used. A 
server certificate issued by a PKI under your control is the best deployment 
practice (which is not the same as a self-signed certificate).

tim

From: Mike Atkins<mailto:matk...@nd.edu>
Sent: Wednesday, August 19, 2020 11:31
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates 
affecting 802.1X?

Tim,
We use the public certificates for users that do not use our onboarding 
utility.  We use a public root certificate that is in pretty much all operating 
systems.  Fortunately or unfortuanately, some operating systems still want to 
walk the entire chain so we onboard with the root and intermediate.

Our information security group had concerns about users just accepting security 
prompts for certificates.  Using a self-signed cert that expires far into the 
future sounds better each day.





Mike Atkins
Network Engineer
Office of Information Technology
University of Notre Dame

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Wednesday, August 19, 2020 10:38 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?

If you’re already onboarding your users, why do you continue to use a public 
cert?

A public EAP server cert should only be used when a “walk-up” enter your 
username/password experience is desired (of course that’s after your 
organization has decided that credential exposure is not a concern).

Tim

From: Mike Atkins<mailto:matk...@nd.edu>
Sent: Wednesday, August 19, 2020 10:34
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates 
affecting 802.1X?

We were burnt last December by an updated cert with the same cert chain and
still not trusted by some devices/operating systems.  We learned documents
that referenced changes to the default web browser on an operating system
ended up with a modification in the operating system that matched the web
browser's changed behavior.  I think this is the same experience Christopher
is referencing.  We ended up having to re-onboard all of our devices at the
very last minute.  We spent more time than we should have to try to avoid
onboarding devices mid-semester when our cert expired.  (this happened right
around finals of course)

Our identity group is buying a cert to test with a month in advance. They
then cancel/revoke that cert to get money back and then order the production
cert.  This is to best ensure we test with the right root/intermediate
certificate authorities that will be on our production cert.  We still lose
about a week on the production cert between testing and install.  Ideally,
we would keep the yearly cert installation during the summer but time is
against us.




Mike Atkins
Network Engineer
Office of Information Technology
University of Notre Dame

-Original Message-
From: The EDUCAUSE Wireless Issues Community Group Listserv
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Johnson, Christopher
Sent: Wednesday, August 19, 2020 10:07 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?

I think it's going to "depend" on each Operating System for the 802.1X
authentications being affected.

The information below is more of just an FYI on what I've observed (cause I
imagine someone's going to say - If I'm going through the trouble of
installing a public Root CA that already exists - then why not go ahead and
use a Private CA).

1. Apple specifically states "This change will affect only TLS server
certificates issued from the Root CAs preinstalled with iOS, iPadOS, macOS,
watchOS, and tvOS." - so that makes me wonder if you install a public Root
CA via a mobile config for example for iOS - does that exempt it from the 1
year limitation then?

2. Chrome OS though (at least from the behavior I've seen) you can't install
a public Root that already exists on to the OS.

I don't think I would trust those "possible exceptions though". One of the
annoying things I felt with Android and Chromebook for certificate
management was If I go into the device and "Disable/Turn Off the
certificates/Set to Not Use" - then all portions of the Operating System
should not use those certificates regardless. However, from what I saw, even
if I disable some of the Public CAs - the wireless supplicant still seems to
trust them.

Christopher Johnson
Wireless Network Engineer
Office of Technology Solutions | Illinois State University
(309) 438-

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

[Tim Cappalli]

If you’re already onboarding your users, why do you continue to use a public 
cert?

A public EAP server cert should only be used when a “walk-up” enter your 
username/password experience is desired (of course that’s after your 
organization has decided that credential exposure is not a concern).

Tim

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

We were burnt last December by an updated cert with the same cert chain and
still not trusted by some devices/operating systems.  We learned documents
that referenced changes to the default web browser on an operating system
ended up with a modification in the operating system that matched the web
browser's changed behavior.  I think this is the same experience Christopher
is referencing.  We ended up having to re-onboard all of our devices at the
very last minute.  We spent more time than we should have to try to avoid
onboarding devices mid-semester when our cert expired.  (this happened right
around finals of course)

Our identity group is buying a cert to test with a month in advance. They
then cancel/revoke that cert to get money back and then order the production
cert.  This is to best ensure we test with the right root/intermediate
certificate authorities that will be on our production cert.  We still lose
about a week on the production cert between testing and install.  Ideally,
we would keep the yearly cert installation during the summer but time is
against us.




Mike Atkins
Network Engineer
Office of Information Technology
University of Notre Dame

-Original Message-
From: The EDUCAUSE Wireless Issues Community Group Listserv
 On Behalf Of Johnson, Christopher
Sent: Wednesday, August 19, 2020 10:07 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] New certificate expiration for certificates
affecting 802.1X?

I think it's going to "depend" on each Operating System for the 802.1X
authentications being affected.

The information below is more of just an FYI on what I've observed (cause I
imagine someone's going to say - If I'm going through the trouble of
installing a public Root CA that already exists - then why not go ahead and
use a Private CA).

1. Apple specifically states "This change will affect only TLS server
certificates issued from the Root CAs preinstalled with iOS, iPadOS, macOS,
watchOS, and tvOS." - so that makes me wonder if you install a public Root
CA via a mobile config for example for iOS - does that exempt it from the 1
year limitation then?

2. Chrome OS though (at least from the behavior I've seen) you can't install
a public Root that already exists on to the OS.

I don't think I would trust those "possible exceptions though". One of the
annoying things I felt with Android and Chromebook for certificate
management was If I go into the device and "Disable/Turn Off the
certificates/Set to Not Use" - then all portions of the Operating System
should not use those certificates regardless. However, from what I saw, even
if I disable some of the Public CAs - the wireless supplicant still seems to
trust them.

Christopher Johnson
Wireless Network Engineer
Office of Technology Solutions | Illinois State University
(309) 438-8444

Stay connected with ISU IT news and tips with @ISU IT Help on Facebook and
Twitter


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

[This message came from an external source. If suspicious, report to
ab...@ilstu.edu]

I was told by Sertigo that all commercial certs would be affected.  We just
bought the last 2 year expirations we could get away with for both 802.1x
and https.

The reason I am told has to do with so many smaller establishments that go
out of business before their cert expires leaving the cert as a security
vulnerability for consumers.  I just wish there was a way to allow for the
longer certs for those of us that have a long history of existence and
stability.  Such a pain.

And I am told they are debating quarterly cert replacements in the future.
That would turn cert management into a much bigger responsibility if that
were to happen.  Hopefully that doesn’t happen.

And yes, if you want to manage EAP with your own self cert, I believe you
can use a longer expiration.
 Tim

-Original Message-
From: The EDUCAUSE Wireless Issues Community Group Listserv
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Andrew Gallo
Sent: Wednesday, August 19, 2020 8:29 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] New certificate expiration for certificates
affecting 802.1X?

Does anyone know 

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

[Tim Cappalli]

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

RE: [WIRELESS-LAN] Openroaming - anyone connected?

[Tim Cappalli]

I don’t see eduroam dissolving. Each vendor’s implementation of OpenRoaming 
(assuming they integrate) is going to vary and may have cost impact. AFAIK, one 
large wireless vendor requires a very expensive subscription / platform in 
order to interconnect. If the eduroam US TLRS can handle all of that without 
need a bunch of extra stuff, that sounds like a better option.

RE: Identity

I think one very prominent use case is that residential campuses will continue 
to need some form of personal area network functionality to deal with home 
devices. You really need some form of resolvable user identity to address that.

And given some of the reactions in the previous thread about MAC randomization, 
I really don’t think people are willing to give up access to their own user’s 
identities on their campus (just my unscientific analysis )

I think its always important to separate Faculty/Staff/Non-Resident students 
from residential students. They expect drastically difference experiences.

tim


From: Jeffrey D. Sessler<mailto:j...@scrippscollege.edu>
Sent: Monday, August 17, 2020 12:45
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Openroaming - anyone connected?

I’m not trying to get out of a business, but Internet2 could eventually get out 
of the radius/eduroam business. Unless I’m mistaken, at the point an 
institution federates directly with openroaming, the need for eduroam 
diminishes. Obviously it’s going to take time, but if there is a push to adopt 
openroaming in EDU, then in say five years, does eduroam have a future?

On the identity front… As we march toward a cloud-based future, and our WiFi 
networks transformed into simple gateways to the internet, how much information 
do we need/want? How much information should we collect? After all, if the 
service is no different than at Starbucks, what does the collection of more 
information do for us?

Jeff

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Tim Cappalli
Sent: Monday, August 17, 2020 9:09 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Openroaming - anyone connected?

What business are you trying to get out of specifically? OpenRoaming is a way 
for federations of organizations and/or individual organizations to 
interconnect. Eduroam would start to mean “less” to end users, as they wouldn’t 
see an “eduroam” ESSID anymore, but there is still value in a trust framework 
for educational organizations, especially when it comes to identity.

If you decide not to provision users with your university identity, you will 
likely have no access to that users real identity. I imagine you still want 
access to identity for your own users and devices?

At its core, OR is simply a few extra elements in the profile that gets put on 
the device provisioning. OR itself, also does not provide client provisioning. 
You still need to do that, or pay for a service that will do it.

I think, personally, that there is a major lack of understanding throughout the 
industry of what OR actually is.

tim

From: Jeffrey D. Sessler<mailto:j...@scrippscollege.edu>
Sent: Monday, August 17, 2020 11:56
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Openroaming - anyone connected?

Why not the other way around, and standardize on OpenRoaming, and have 
everything else become a member of it? Do we still need eduroam at that point? 
Do we care if the client device is using their ATT, Spectrum, or college 
credentials?

I’m reminded that in EDU we often fix problems nobody cared much about at the 
time e.g. eduroam, but as the world matures, and there are perhaps better 
alternatives, why not get out of the business?  There are costs to operate 
eduroam, and if it’s no longer strategic or different from other services e.g. 
OpenRoaming, why not put those resources into something that is strategic and a 
differentiator?  Why wouldn’t Internet2 and its members focus on adoption of 
OpenRoaming rather than a new and possibly duplicative service like anyroam?

Jeff



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Philippe Hanset
Sent: Sunday, August 16, 2020 7:20 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Openroaming - anyone connected?

At least for the US, we plan to have an Open-Roaming gateway at ANYROAM.
We became member of the WBA for that purpose back in May 2020.

The idea is to simplify connectivity for schools:  you have one connection with 
ANYROAM, and all your roaming traffic
is sorted by us (Open-Roaming, eduroam, Govroam, …). No need to be turn your 
school’s RADIUS server into a complex gateway.

We are working on a document that we will post at 
anyroam.net<https://nam06.safelinks.protection.outlook.

RE: [WIRELESS-LAN] Openroaming - anyone connected?

[Tim Cappalli]

What business are you trying to get out of specifically? OpenRoaming is a way 
for federations of organizations and/or individual organizations to 
interconnect. Eduroam would start to mean “less” to end users, as they wouldn’t 
see an “eduroam” ESSID anymore, but there is still value in a trust framework 
for educational organizations, especially when it comes to identity.

If you decide not to provision users with your university identity, you will 
likely have no access to that users real identity. I imagine you still want 
access to identity for your own users and devices?

At its core, OR is simply a few extra elements in the profile that gets put on 
the device provisioning. OR itself, also does not provide client provisioning. 
You still need to do that, or pay for a service that will do it.

I think, personally, that there is a major lack of understanding throughout the 
industry of what OR actually is.

tim

From: Jeffrey D. Sessler
Sent: Monday, August 17, 2020 11:56
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Openroaming - anyone connected?

Why not the other way around, and standardize on OpenRoaming, and have 
everything else become a member of it? Do we still need eduroam at that point? 
Do we care if the client device is using their ATT, Spectrum, or college 
credentials?

I’m reminded that in EDU we often fix problems nobody cared much about at the 
time e.g. eduroam, but as the world matures, and there are perhaps better 
alternatives, why not get out of the business?  There are costs to operate 
eduroam, and if it’s no longer strategic or different from other services e.g. 
OpenRoaming, why not put those resources into something that is strategic and a 
differentiator?  Why wouldn’t Internet2 and its members focus on adoption of 
OpenRoaming rather than a new and possibly duplicative service like anyroam?

Jeff



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Philippe Hanset
Sent: Sunday, August 16, 2020 7:20 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Openroaming - anyone connected?

At least for the US, we plan to have an Open-Roaming gateway at ANYROAM.
We became member of the WBA for that purpose back in May 2020.

The idea is to simplify connectivity for schools:  you have one connection with 
ANYROAM, and all your roaming traffic
is sorted by us (Open-Roaming, eduroam, Govroam, …). No need to be turn your 
school’s RADIUS server into a complex gateway.

We are working on a document that we will post at 
anyroam.net
 in a few weeks.

Thanks,

Philippe

Philippe Hanset, CEO
www.anyroam.net
Operator of eduroam-US
+1 (865) 236-0770






On Aug 16, 2020, at 9:19 PM, Phill Solomon 
<0150915d379b-dmarc-requ...@listserv.educause.edu>
 wrote:

Hello all,

One of the items on the radar for us is OpenRoaming, is there anyone connected, 
or looking into connecting?

And if you are connected are you using it as an extension for students / staff 
or just for visitors.?

Thanks in advance,

Kind regards,

Phill Solomon
Senior Network Engineer
IS - AV & Networks
ICT Infrastructure Services, eSolutions
Planned Leave: NA



Deakin University
301 Burwood Highway, Burwood
VIC 3125, Australia.
• Phone: +61 3 924 46069 
• E-mail: 
phill.solo...@deakin.edu.au

Deakin University CRICOS Provider Code 00113B

Important Notice: The contents of this email are intended solely for the named 
addressee and are confidential; any unauthorised use, reproduction or storage 
of the contents is expressly prohibited. If you have received this email in 
error, please delete it and any attachments immediately and advise the sender 
by return email or telephone.
Deakin University does not warrant that this email and any attachments are 
error or virus free.


Important Notice: The contents of this email are intended solely for the named 
addressee and are confidential; any unauthorised use, reproduction or storage 
of the contents is expressly prohibited. If you have received this email in 
error, please delete it and any attachments immediately and advise the sender 
by return email or telephone.

Deakin University does not warrant that this email and any attachments are 
error or virus free.
**
Replies to EDUCAUSE Community Group 

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Tim Cappalli]

I imagine the device is able to detect it is the same BSSID and determine the 
MAC does not need to be changed.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Rios, Hector J 

Sent: Friday, July 31, 2020 10:19
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...


Nope. MAC addr is still the same. This is day 2. I’ve been associated to the 
same AP.



Hector Rios, Wireless Network Architect

The University of Texas at Austin







From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Jake Snyder
Sent: Friday, July 31, 2020 8:54 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...



It should change the next time it associates.

Sent from my iPhone



On Jul 30, 2020, at 1:02 PM, GT Hill mailto:g...@gthill.com>> 
wrote:



From what I understand it will keep the same MAC longer if it passing traffic 
at that 24 hour mark.



GT Hill



On Thu, Jul 30, 2020 at 1:44 PM Rios, Hector J 
mailto:hector.r...@austin.utexas.edu>> wrote:

I’ve done several tests on an iPhone 7 and there have been instances where the 
phone retains the same private MAC addr longer than 24 hours. Has anyone else 
done more testing?



Hector Rios, Wireless Network Architect

The University of Texas at Austin







From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Enfield, Chuck
Sent: Friday, July 10, 2020 4:14 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...



Ahh.  I glossed right over the 24-hour part.  That’s much less distressing, but 
I’m going to have a beer anyway.



Thanks Tim.



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 5:04 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...



But why would that change anything? A user on campus for a football game is 
there for less than 24 hours. The MAC address changes per ESSID, every 24 
hours. I don’t understand what changes here for that use case?



It really only impacts mid to long term guests. So I guess in your example, 
parents weekend may be the one that is affected. But even then, dropping the 
lease times would solve the problem. I believe many wireless vendors recommend 
a visitor lease time of 1-8 hours.



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 17:01
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Tim,

With Covid, any lease time would not be an issue. But how big were your home 
football events / tailgate parties / parent weekends at Brandeis? I’m focusing 
more on the impact of those events on the guest side of things.

Brad



From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 3:53 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...



Agreed on IPv6, but even for IPv4, I imagine most folks are running short 
leases on a visitor network, so I don’t really think much changes here. If your 
leases are 12 hours or less, there should be no impact.



tim



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 16:51
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Maybe a good use case for IPv6



From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Enfield, Chuck
Sent: Friday, July 10, 2020 3:49 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...



Uhg.  Didn’t even think about that.



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Eric LaCroix
Sent: Friday, July 10, 2020 4:48 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...



We’re all going to need to check the TTL on DHCP l

Re: aruba airplay wired servers

[Tim Cappalli]

Unless something changed since March, location based policy via CPPM for 
AirGroup does not work.

Also, AFAIK, RF neighbor & CPPM location are mutually exclusive.

From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Wednesday, July 29, 2020 at 16:17
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] aruba airplay wired servers
Seriously even with cppm. Because tac and devs have me going this way for all 
my wired airplay servers.   I mean I can do location via cli manually per 
airplay server but it doesn’t scale and tac says I have to use cppm because I 
have more than 50 wired servers.

Trent Hurt

University of Louisville


From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu>
Sent: Wednesday, July 29, 2020 4:15:43 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] aruba airplay wired servers


CAUTION: This email originated from outside of our organization. Do not click 
links, open attachments, or respond unless you recognize the sender's email 
address and know the contents are safe.

Location-based policy is not supported with wired AirGroup servers.



From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Wednesday, July 29, 2020 at 16:05
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: [WIRELESS-LAN] aruba airplay wired servers

I have setup the shared location by ap name in clearpass.  I was wondering if 
anyone knows does this assignment via ap name thru clearpass also do the share 
with rf neighbors like how you can with wireless airgroup servers.  I can’t see 
any option in clearpass for rf neighbor.  Tac has told me not to use ap group 
even with clearpass.



Thanks
Trent







Trenton Hurt, CWNE #172,ACMP,ACCP,CCNP(W),CCNA(W),CCNA(V),CCNA(R/S)

Network Analyst

University of Louisville

Phone (502) 852-1513



**
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%7Cc241e7262c604602b65608d833fc5fdd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637316506319088994=G9dDKeuYjseUw9bkID5UH53elpJct7Y9E3dFzMYjvkc%3D=0>

**
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%7Cc241e7262c604602b65608d833fc5fdd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637316506319093985=8rTb38TGecU6QXH5EiEXDYf4wD2Wjfg9yi892tZxu4U%3D=0>

**
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%7Cc241e7262c604602b65608d833fc5fdd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637316506319098976=09cWZhmXkMdoL%2BtIBQXm%2FDdgzplzqYzWOEw5JpuvoSQ%3D=0>

**
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: aruba airplay wired servers

[Tim Cappalli]

Location-based policy is not supported with wired AirGroup servers.

From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Wednesday, July 29, 2020 at 16:05
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: [WIRELESS-LAN] aruba airplay wired servers
I have setup the shared location by ap name in clearpass.  I was wondering if 
anyone knows does this assignment via ap name thru clearpass also do the share 
with rf neighbors like how you can with wireless airgroup servers.  I can’t see 
any option in clearpass for rf neighbor.  Tac has told me not to use ap group 
even with clearpass.

Thanks
Trent



Trenton Hurt, CWNE #172,ACMP,ACCP,CCNP(W),CCNA(W),CCNA(V),CCNA(R/S)
Network Analyst
University of Louisville
Phone (502) 852-1513


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

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Tim Cappalli]

It should not affect 802.1X outside of potential database bloat if your policy 
engine stores MAC addresses.

I honestly can’t remember if it was enabled for existing saved networks post 
upgrade. Will be interesting to hear others experiences.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Tuesday, July 21, 2020 at 18:16
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
This is all fascinating, I’m looking forward to getting my hands on a public 
beta.

Those “in the know” ... does this impact 1x networks as well as open? It seems 
that if you’re connecting with credentials, there’s already a trust 
relationship in place.

And is the feature enabled for networks that were configured before upgrading 
to iOS 14?

Fun times,

Norman Elton



On Tue, Jul 21, 2020 at 2:55 PM Rios, Hector J 
mailto:hector.r...@austin.utexas.edu>> wrote:
I just finished reading the “Apple Beta Software Program Agreement”. 
Interesting information:

“Don’t blog, post screen shots, tweet, or publicly post information about the 
public beta software, and don’t discuss the public beta software with or 
demonstrate it to others who are not in the Apple Beta Software Program.”

So, I need everyone to sign up to the beta software program so we can continue 
this conversation (J/K)

Hector Rios, Wireless Network Architect
The University of Texas at Austin



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Tuesday, July 21, 2020 1:06 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

 Yeah, good catch Chris! I’d be interested in seeing some field data as well. 
The only info I saw was that it changed every 24 hours, but it sounds like 
there’s a * which indicates inactivity / not associated.

It makes much more sense that it wouldn’t change if the device maintains an 
active connection as there are really no privacy concerns until the device 
disconnects and moves.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Tuesday, July 21, 2020 at 13:15
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Tim had mentioned the following: “On iOS 14, the MAC is set per ESSID and is 
changed once every 24 hours.”

Chris then mentioned that he found one iOS 14 device that, as long as it 
remains connected, the MAC remains the same, even beyond 24hrs.

Has anyone else done testing? Please share your results.

Hector Rios, Wireless Network Architect
The University of Texas at Austin



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Johnson, Christopher
Sent: Monday, July 20, 2020 10:19 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Default behavior matters indeed. Got a preview of what to expect over the 
weekend.

Found one individual that was in Aruba Airwave “12 Times” for their iPhone 14.0 
over past couple of weeks and another “6 times”. It appears that as long as the 
device remains “connected” to the network beyond the 24 hours, the MAC Address 
will remain the same. Although if they’re fully de-authenticated or move say 
into an elevator or outside (or a class phone reboot occurs in the pocket) – 
then the MAC Address will update upon establishing a new connection – that is 
just the initial observation I saw.
Christopher Johnson
Wireless Network Engineer
Office of Technology Solutions | Illinois State University
(309) 438-8444

Stay connected with ISU IT news and tips with @ISU IT Help on 
Facebook<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.facebook.com%2FISUITHelp%2F=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C812e787d6bf44c983a5508d82dc389f8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637309665991169119=PXsoY8%2BEIC%2BPM7k%2BUGHb%2FMTJDqGDXwk4poUYtk9r8%2B8%3D=0>
 and 
Twitter<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FISUITHelp=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C812e787d6bf44c983a5508d82dc389f8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637309665991179105=2pCDlSeZJHJ6MzyQJ9e2DrMbVba6%2FFaV4M%2B%2FOJ16BfU%3D=0>
From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Enfield, Chuck
Sent: Tuesday, July 14, 2020 12:36 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

[This message came from

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Tim Cappalli]

:34 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

My point wasn’t to debate Passpoint either.  I’m wondering if Apple actually 
has a plan, and if so, if they’ve bothered to tell anybody.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 4:22 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Passpoint is not just about mobile network operators. Any identity provider can 
provision a Passpoint profile. That is the whole drive behind OpenRoaming. The 
industry goal is that every user has at least 2 Passpoint profiles on their 
devices: one tied to their enterprise/school identity and the other tied to a 
personal identity. The traditional enterprise/school onboarding process stays 
largely the same, except some additional Passpoint logic is added.

Mobile network operators / cell providers are only one (optional) piece of the 
puzzle.

Probably should start a separate thread for anything deeper on Passpoint beyond 
it being a solution for network access. Don’t want to take away from the OG 
conversation.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 16:17
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Understood, but few Wi-Fi operators actually support Passpoint on their 
networks.  Since Apple is eliminating the alternatives, they either must be 
idiots (my bet) or have a proposal for what we should all being doing instead.

I still get really confused looks when I try to discuss Passpoint with my 
contacts at the major cellular providers, so it can’t possibly be a realistic 
option for most of us.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 4:07 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Not sure I follow. Passpoint is an industry-wide solution for secure Wi-Fi 
roaming. Passpoint has been supported on iOS and macOS (along with Windows and 
Android) for a number of years.

I definitely don’t follow this comment: “you can’t onboard your Apple to enable 
identity-based auth.”

tim


From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 16:04
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
So you can’t use an Apple MAC address for guest auth, and you can’t onboard 
your Apple to enable identity-based auth.  Apple must be thinking that they can 
drag the entire world, kicking and screaming, into federated authentication 
that Apple products ship knowing how to do (Passpoint, openroaming, etc.).  Do 
they have a proposal for this that I missed?

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Rios, Hector J
Sent: Friday, July 10, 2020 2:56 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [WIRELESS-LAN] MAC Randomization, a step further...

Apple is moving forward with their privacy efforts. The next step is to 
randomize MAC addresses when connecting to an AP, not just when probing. This 
is coming soon.

https://globalreachtech.com/blog-mac-randomisation-apple/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fglobalreachtech.com%2Fblog-mac-randomisation-apple%2F=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7Cc141f9922e2241c5153b08d82d99b43e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637309485473837398=%2B0Gb16K4pvn9offguMbuJRStFLgHN5zdvpeK1yoeqsQ%3D=0>

This is from Apple. Luckily, there is a way to disable private addresses. I 
just don’t know if it will be ON by default.
https://support.apple.com/en-qa/HT211227<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.apple.com%2Fen-qa%2FHT211227=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7Cc141f9922e2241c5153b08d82d99b43e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637309485473847382=sIohYcEWP0lZ6Y6b6SqZGHjHdz%2F6KD92yQ91qyFloqY%3D=0>

Happy Friday!

Hector Rios, Wireless Network Architect
The University of Texas at Austin


**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want t

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Tim Cappalli]

EAP-TTLS is simply an EAP method. What credential and subject type you use is 
up to your configuration and policy.

RE: EMMs (speaking generically), yes many need to have additional config 
options exposed for Passpoint parameters but you don't need client certificates 
for Passpoint. If no customers ask for a capability, it likely will not be 
implemented in any product. It won't be an overnight flip of the switch to 
eliminate your existing 802.1X SSID so those EMM managed devices can continue 
as they normally would. Visitors with credentials from another IdP can 
seamlessly connect in the meantime. It's a marathon, not a sprint.

Unfortunately there's been so much negativity around Passpoint over the years 
that not many people have engaged with vendors on it. Just my opinion. Outside 
of the eduroam advisory council and historical interest in the technology, I 
really have no other vested interest in the topic.

Tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of James Andrewartha 

Sent: Monday, July 20, 2020, 23:11
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

On 21/7/20 11:04 am, Tim Cappalli wrote:
> Both major Wi-Fi vendors have Passpoint offerings that are either
> available or in preview.

I'm talking about the client side. Intune doesn't even have a CA either
(no the short-lived one for conditional access doesn't count). Where's
the Microsoft supported agent that does device-specific TTLS-PAP like
you suggest?

Also 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.securew2.com%2Fblog%2Fpitfalls-of-eap-ttls-pap%2Fdata=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7Ca83f24666b4f421d719408d82d23afd8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637308978591817681sdata=AsFb0%2BDplHGzVWHxo6qWKqw9XYJuH5Md3YhdYEpQFzY%3Dreserved=0
 is the top
google result for [TTLS-PAP], admittedly it's about user credentials not
device credentials but it's still a risk.

--
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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunitydata=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7Ca83f24666b4f421d719408d82d23afd8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637308978591817681sdata=SMZUP69xXENTzXPmKbytbI%2FMYBuP3Hwk4jsSDy9D1rA%3Dreserved=0


**
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] MAC Randomization, a step further...

[Tim Cappalli]

Both major Wi-Fi vendors have Passpoint offerings that are either available or 
in preview.

Tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Monday, July 20, 2020 at 22:34
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
On 21/7/20 5:21 am, Tim Cappalli wrote:
> Passpoint solves all of these issues.

Where is the vendor support for it? Autopilot white glove doesn't even
support wireless networks at all.

--
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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunitydata=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C3cb035d18c7248779cf308d82d1ea118%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637308956870326069sdata=8LcqGwSOQ31E0JZYw3WMIcq2zVYQ9fYbb%2Bj7zl1RzGY%3Dreserved=0

**
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] WIRELESS-LAN Digest - 20 Jul 2020 to 21 Jul 2020 - Special issue (#2020-88)

[Tim Cappalli]

Agreed that there are some privacy concerns, but many are in the process of 
being addressed. I’d argue that the privacy concerns with Passpoint are no 
different than with eduroam today. At least Passpoint gives the user more 
visibility into the actual operator of the network they’re connected to. 
"Traditional" eduroam (SSID-based) is a mystical, random thing for end users.

Certificate management is not a new problem for Wi-Fi either.  Passpoint 
actually makes it a bit easier though because the profile can be lifecycle 
managed through an existing app, often with little to no user interaction.

You also don’t have to use client certs for Passpoint. Actually, right now, my 
recommendation is to not use certificate-based auth due to privacy concerns. 
Device-specific credentials with EAP-TTLS/PAP and an anonymous outer identity 
is the recommended path.

There’s really no path forward without Passpoint (unless you really don’t care 
about user experience and security).

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Monday, July 20, 2020 at 21:56
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] WIRELESS-LAN Digest - 20 Jul 2020 to 21 Jul 2020 - 
Special issue (#2020-88)
Passpoint solves some issues (less SSIDs, encryption, instant access) and then 
it brings other issues like Privacy and authentication pains
(certificate expiration, loss of credentials)

Philippe Hanset, CEO
www.anyroam.net<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.anyroam.net%2F=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C40650f86688848f66a1d08d82d193aca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637308933688101275=Gig3c46qwQ2aUHI%2FK6U%2F9nZuqDztk4xe03uzRtN3L8s%3D=0>
Operator of eduroam-US
+1 (865) 236-0770






On Jul 20, 2020, at 9:42 PM, Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu<mailto:0194c9ecac40-dmarc-requ...@listserv.educause.edu>>
 wrote:

There has been an exponential increase in Passpoint rollouts in the past 18 
months, on both the network infrastructure side as well as clients.

Ping your vendor. The more people talk about it (and ask for it), the faster it 
will be adopted and rolled out.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Monday, July 20, 2020 at 21:39
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] WIRELESS-LAN Digest - 20 Jul 2020 to 21 Jul 2020 - 
Special issue (#2020-88)
Passpoint solves all of these issues.

Tim

Count me in the fan bucket when widely deployed.  But when will that be I 
wonder?  MAC rotation increases in a few months.

I recognize institutions have different relations with their guests.  For ours 
the friction/intrusiveness of onboarding processes was considered too high a 
cost.  I know I would not want to run another institutions software on my 
device to onboard it to their Wi-Fi (and for some it is prohibited).


--
William Green, Director of Networking and Telecommunications
The University of Texas at Austin | ITS | 512-475-9295 | 
gr...@austin.utexas.edu<mailto:gr...@austin.utexas.edu>


**
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%7C40650f86688848f66a1d08d82d193aca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637308933688111264=6kuH1csU3sxYdJRWeyvYdT9tyfZM1bSsXOLfMpo%2B4BU%3D=0>
**
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%7C40650f86688848f66a1d08d82d193aca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637308933688111264=6kuH1csU3sxYdJRWeyvYdT9tyfZM1bSsXOLfMpo%2B4BU%3D=0>


**
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%7C0

Re: [WIRELESS-LAN] WIRELESS-LAN Digest - 20 Jul 2020 to 21 Jul 2020 - Special issue (#2020-88)

[Tim Cappalli]

There has been an exponential increase in Passpoint rollouts in the past 18 
months, on both the network infrastructure side as well as clients.

Ping your vendor. The more people talk about it (and ask for it), the faster it 
will be adopted and rolled out.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Monday, July 20, 2020 at 21:39
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] WIRELESS-LAN Digest - 20 Jul 2020 to 21 Jul 2020 - 
Special issue (#2020-88)
Passpoint solves all of these issues.

Tim

Count me in the fan bucket when widely deployed.  But when will that be I 
wonder?  MAC rotation increases in a few months.

I recognize institutions have different relations with their guests.  For ours 
the friction/intrusiveness of onboarding processes was considered too high a 
cost.  I know I would not want to run another institutions software on my 
device to onboard it to their Wi-Fi (and for some it is prohibited).


--
William Green, Director of Networking and Telecommunications
The University of Texas at Austin | ITS | 512-475-9295 | 
gr...@austin.utexas.edu



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

Re: MAC Randomization, a step further...

[Tim Cappalli]

Passpoint solves all of these issues.

Tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Monday, July 20, 2020 at 17:14
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

For guests, I've been tossing around the idea of an open network. No

.1x, no PSK, no captive portal. Affiliates would be encouraged to use

eduroam via SSO nag. Columbia University had a presentation on how they

are doing the open network side of this. I suspect the most difficult

part will be getting legal on board. Who has an open network? What have

your experiences been? This is only tangentially related, so feel free

to split it into a new thread.

We run an open network for guests.  It has been wonderful for guests and they 
all like it.

The major problem has been student, faculty, staff devices connect to the guest 
network (usually unbeknown to the user).  Restrictions on that network then 
cause support calls.  Google decided the network was “good” and so Android 
devices connect by default (then VPN tunnel back to Google).  We don’t want to 
block that due to guests.

But maybe there will be a new problem.  When devices have been found infected 
on any of our networks we’ve quarantined by MAC address.  Hmmm… so for our 
users we can quarantine by their user name (much less helpful to take all their 
devices offline instead of just the one infected, but hey this progress right). 
 I don’t know what we do with infected guest devices (or as our users’ device 
decides to move to the guest network because they were blocked on the main 
network) if they are randomizing between connections.  Vendors haven’t thought 
this through.  That may push a registration method with credentials for guests 
— meaning less privacy?


--
William Green, Director of Networking and Telecommunications
The University of Texas at Austin | ITS | 512-475-9295 | 
gr...@austin.utexas.edu


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

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Tim Cappalli]

There’s an endpoint cleanup interval configuration in cluster-wide parameters, 
although I’d recommend reaching out to someone at Aruba (or your NAC provider 
to ask how they recommend dealing with some of these new changes).

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Tuesday, July 14, 2020 at 12:31
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
For those of us using ClearPass to authenticate users to eduroam, does this 
mean that every iOS device will get registered as a new endpoint every day?  
For others, does your NAC store a client's MAC persistently?  I'm assuming that 
the answer to both is yes.

How can we plan for the impact of that on our databases?  Should we delete all 
iOS and Android devices after 48 hours?  Am I missing something obvious?

Jonathan Miller
Senior Network Analyst
Franklin and Marshall College


On Fri, Jul 10, 2020 at 4:37 PM Enfield, Chuck 
mailto:cae...@psu.edu>> wrote:
PS – My plan for supporting our guest network will be to tell any user who 
contacts us with an Apple device that the network is fine and they should 
contact Apple for device support.  I can’t get away with that for our 
enterprise network, but Apple is going to own the guest problem.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Enfield, Chuck
Sent: Friday, July 10, 2020 4:34 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

My point wasn’t to debate Passpoint either.  I’m wondering if Apple actually 
has a plan, and if so, if they’ve bothered to tell anybody.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 4:22 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Passpoint is not just about mobile network operators. Any identity provider can 
provision a Passpoint profile. That is the whole drive behind OpenRoaming. The 
industry goal is that every user has at least 2 Passpoint profiles on their 
devices: one tied to their enterprise/school identity and the other tied to a 
personal identity. The traditional enterprise/school onboarding process stays 
largely the same, except some additional Passpoint logic is added.

Mobile network operators / cell providers are only one (optional) piece of the 
puzzle.

Probably should start a separate thread for anything deeper on Passpoint beyond 
it being a solution for network access. Don’t want to take away from the OG 
conversation.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 16:17
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Understood, but few Wi-Fi operators actually support Passpoint on their 
networks.  Since Apple is eliminating the alternatives, they either must be 
idiots (my bet) or have a proposal for what we should all being doing instead.

I still get really confused looks when I try to discuss Passpoint with my 
contacts at the major cellular providers, so it can’t possibly be a realistic 
option for most of us.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 4:07 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Not sure I follow. Passpoint is an industry-wide solution for secure Wi-Fi 
roaming. Passpoint has been supported on iOS and macOS (along with Windows and 
Android) for a number of years.

I definitely don’t follow this comment: “you can’t onboard your Apple to enable 
identity-based auth.”

tim


From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 16:04
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
So you can’t use an Apple MAC address for guest auth, and you can’t onboard 
your Apple to enable identity-based auth.  Apple must be thinking that they can 
drag the entire world, kicking and screaming, into federated authentication 
that Apple products ship knowing how to do (Passpoint, openroaming, etc.).  Do 
they have a proposal for this that I missed?

From: The EDUCAUSE Wireless Issues Community Group Listserv 

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Tim Cappalli]

But why would that change anything? A user on campus for a football game is 
there for less than 24 hours. The MAC address changes per ESSID, every 24 
hours. I don’t understand what changes here for that use case?

It really only impacts mid to long term guests. So I guess in your example, 
parents weekend may be the one that is affected. But even then, dropping the 
lease times would solve the problem. I believe many wireless vendors recommend 
a visitor lease time of 1-8 hours.

From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Friday, July 10, 2020 at 17:01
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Tim,
With Covid, any lease time would not be an issue. But how big were your home 
football events / tailgate parties / parent weekends at Brandeis? I’m focusing 
more on the impact of those events on the guest side of things.
Brad

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 3:53 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

Agreed on IPv6, but even for IPv4, I imagine most folks are running short 
leases on a visitor network, so I don’t really think much changes here. If your 
leases are 12 hours or less, there should be no impact.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 16:51
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Maybe a good use case for IPv6

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Enfield, Chuck
Sent: Friday, July 10, 2020 3:49 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

Uhg.  Didn’t even think about that.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Eric LaCroix
Sent: Friday, July 10, 2020 4:48 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

We’re all going to need to check the TTL on DHCP leases… some of our scopes 
will get eaten alive otherwise.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of "Floyd, Brad" mailto:bfl...@mail.smu.edu>>
Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 3:42 PM
To: 
"WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>" 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Thanks Tim. I just started a conversation with my SE.
Brad

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 2:07 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

For extended visitor use cases (over 1 day), Passpoint is really the only 
feasible solution moving forward. Aruba has a Passpoint offering/service called 
Air Pass and WBA’s OpenRoaming initiative is gaining a lot of support.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 15:04
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Tim,
Anything in the works from Aruba about how best to deal with ClearPass Guest 
MAC Auth?
Thanks,
Brad

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 2:01 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

Connected MAC randomization on iOS will be enabled by default, just like on 
Android (starting in 10).

Two major differences:

  1.  iOS does not expose the randomization knob (to disable it) to end users 
during initial connection. It is available after connection in the saved 
network list
  2.  On Android (version 10 and 11), the MAC is set once per ESSID for the 
lifetime of the OS 

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Tim Cappalli]

Agreed on IPv6, but even for IPv4, I imagine most folks are running short 
leases on a visitor network, so I don’t really think much changes here. If your 
leases are 12 hours or less, there should be no impact.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Friday, July 10, 2020 at 16:51
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Maybe a good use case for IPv6

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Enfield, Chuck
Sent: Friday, July 10, 2020 3:49 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

Uhg.  Didn’t even think about that.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Eric LaCroix
Sent: Friday, July 10, 2020 4:48 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

We’re all going to need to check the TTL on DHCP leases… some of our scopes 
will get eaten alive otherwise.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of "Floyd, Brad" mailto:bfl...@mail.smu.edu>>
Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 3:42 PM
To: 
"WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>" 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Thanks Tim. I just started a conversation with my SE.
Brad

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 2:07 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

For extended visitor use cases (over 1 day), Passpoint is really the only 
feasible solution moving forward. Aruba has a Passpoint offering/service called 
Air Pass and WBA’s OpenRoaming initiative is gaining a lot of support.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 15:04
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Tim,
Anything in the works from Aruba about how best to deal with ClearPass Guest 
MAC Auth?
Thanks,
Brad

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 2:01 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

Connected MAC randomization on iOS will be enabled by default, just like on 
Android (starting in 10).

Two major differences:

  1.  iOS does not expose the randomization knob (to disable it) to end users 
during initial connection. It is available after connection in the saved 
network list
  2.  On Android (version 10 and 11), the MAC is set once per ESSID for the 
lifetime of the OS instance (aka until a factory reset). On iOS 14, the MAC is 
set per ESSID and is changed once every 24 hours.

Note that Android 11 has a developer option to enable a per-connection MAC 
which likely indicates this will enabled by default or exposed to users in 
Android 12.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 14:57
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: [WIRELESS-LAN] MAC Randomization, a step further...
Apple is moving forward with their privacy efforts. The next step is to 
randomize MAC addresses when connecting to an AP, not just when probing. This 
is coming soon.

https://globalreachtech.com/blog-mac-randomisation-apple/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fglobalreachtech.com%2Fblog-mac-randomisation-apple%2F=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C1ebf180de6a242fb0aa308d82513081c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637300110960909491=EAngi4I6yxsqvvG1BzQiNt04FeJ7B37%2Bw%2BvGvE%2BJ24w%3D=0>

This is from Apple. Luckily, there is a way to disable private addresses. I 
just don’t know if it will be ON by default.
https://support.apple.com/en-qa/HT211227<https://nam06.safelinks.protection.outlook.com/?url=https

Re: MAC Randomization, a step further...

[Tim Cappalli]

There’s really nothing for Apple to do. They’ve support Passpoint since iOS 9. 
They can’t force IdPs and network owners to start using it.

From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Friday, July 10, 2020 at 16:34
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
My point wasn’t to debate Passpoint either.  I’m wondering if Apple actually 
has a plan, and if so, if they’ve bothered to tell anybody.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 4:22 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Passpoint is not just about mobile network operators. Any identity provider can 
provision a Passpoint profile. That is the whole drive behind OpenRoaming. The 
industry goal is that every user has at least 2 Passpoint profiles on their 
devices: one tied to their enterprise/school identity and the other tied to a 
personal identity. The traditional enterprise/school onboarding process stays 
largely the same, except some additional Passpoint logic is added.

Mobile network operators / cell providers are only one (optional) piece of the 
puzzle.

Probably should start a separate thread for anything deeper on Passpoint beyond 
it being a solution for network access. Don’t want to take away from the OG 
conversation.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 16:17
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Understood, but few Wi-Fi operators actually support Passpoint on their 
networks.  Since Apple is eliminating the alternatives, they either must be 
idiots (my bet) or have a proposal for what we should all being doing instead.

I still get really confused looks when I try to discuss Passpoint with my 
contacts at the major cellular providers, so it can’t possibly be a realistic 
option for most of us.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 4:07 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Not sure I follow. Passpoint is an industry-wide solution for secure Wi-Fi 
roaming. Passpoint has been supported on iOS and macOS (along with Windows and 
Android) for a number of years.

I definitely don’t follow this comment: “you can’t onboard your Apple to enable 
identity-based auth.”

tim


From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 16:04
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
So you can’t use an Apple MAC address for guest auth, and you can’t onboard 
your Apple to enable identity-based auth.  Apple must be thinking that they can 
drag the entire world, kicking and screaming, into federated authentication 
that Apple products ship knowing how to do (Passpoint, openroaming, etc.).  Do 
they have a proposal for this that I missed?

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Rios, Hector J
Sent: Friday, July 10, 2020 2:56 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [WIRELESS-LAN] MAC Randomization, a step further...

Apple is moving forward with their privacy efforts. The next step is to 
randomize MAC addresses when connecting to an AP, not just when probing. This 
is coming soon.

https://globalreachtech.com/blog-mac-randomisation-apple/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fglobalreachtech.com%2Fblog-mac-randomisation-apple%2F=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C9437a6586fe94bd6c66908d82510a12b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637300100662871173=Fq4DnW3yW3zcKz%2ByQA84jNXKAK2oqUD0H3ZzvptbNz4%3D=0>

This is from Apple. Luckily, there is a way to disable private addresses. I 
just don’t know if it will be ON by default.
https://support.apple.com/en-qa/HT211227<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.apple.com%2Fen-qa%2FHT211227=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C9437a6586fe94bd6c66908d82510a12b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637300100662881169=MLABL7CivoKcBjJ6KKfXE9O5nyUVGo9UIabtoskwYlo%3D=0>

Happy Friday!

Hector Rios, Wireless Network Architect
The University of Texas at Austin


**
Replies to EDUCAU

Re: MAC Randomization, a step further...

[Tim Cappalli]

Passpoint is not just about mobile network operators. Any identity provider can 
provision a Passpoint profile. That is the whole drive behind OpenRoaming. The 
industry goal is that every user has at least 2 Passpoint profiles on their 
devices: one tied to their enterprise/school identity and the other tied to a 
personal identity. The traditional enterprise/school onboarding process stays 
largely the same, except some additional Passpoint logic is added.

Mobile network operators / cell providers are only one (optional) piece of the 
puzzle.

Probably should start a separate thread for anything deeper on Passpoint beyond 
it being a solution for network access. Don’t want to take away from the OG 
conversation.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Friday, July 10, 2020 at 16:17
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Understood, but few Wi-Fi operators actually support Passpoint on their 
networks.  Since Apple is eliminating the alternatives, they either must be 
idiots (my bet) or have a proposal for what we should all being doing instead.

I still get really confused looks when I try to discuss Passpoint with my 
contacts at the major cellular providers, so it can’t possibly be a realistic 
option for most of us.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 4:07 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Not sure I follow. Passpoint is an industry-wide solution for secure Wi-Fi 
roaming. Passpoint has been supported on iOS and macOS (along with Windows and 
Android) for a number of years.

I definitely don’t follow this comment: “you can’t onboard your Apple to enable 
identity-based auth.”

tim


From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 16:04
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
So you can’t use an Apple MAC address for guest auth, and you can’t onboard 
your Apple to enable identity-based auth.  Apple must be thinking that they can 
drag the entire world, kicking and screaming, into federated authentication 
that Apple products ship knowing how to do (Passpoint, openroaming, etc.).  Do 
they have a proposal for this that I missed?

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Rios, Hector J
Sent: Friday, July 10, 2020 2:56 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [WIRELESS-LAN] MAC Randomization, a step further...

Apple is moving forward with their privacy efforts. The next step is to 
randomize MAC addresses when connecting to an AP, not just when probing. This 
is coming soon.

https://globalreachtech.com/blog-mac-randomisation-apple/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fglobalreachtech.com%2Fblog-mac-randomisation-apple%2F=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C7dc10a8266d1489f29f508d8250e3718%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637300090278000554=xz6zA7IJAvcnPdUTljWJYL4wNAYrfmyzavuYZ73LJ3k%3D=0>

This is from Apple. Luckily, there is a way to disable private addresses. I 
just don’t know if it will be ON by default.
https://support.apple.com/en-qa/HT211227<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.apple.com%2Fen-qa%2FHT211227=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C7dc10a8266d1489f29f508d8250e3718%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637300090278010552=iv5ihYSgoRf4uuQ%2B6TaD5mZgg%2F89nm2MfFutXOsHqRE%3D=0>

Happy Friday!

Hector Rios, Wireless Network Architect
The University of Texas at Austin


**
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%7C7dc10a8266d1489f29f508d8250e3718%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637300090278020549=pkJdVXpiFS7S%2B%2F%2BqP60vWy%2FWZ6bP7Niyzy5hPZTQ5nc%3D=0>

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

Re: MAC Randomization, a step further...

[Tim Cappalli]

Not sure I follow. Passpoint is an industry-wide solution for secure Wi-Fi 
roaming. Passpoint has been supported on iOS and macOS (along with Windows and 
Android) for a number of years.

I definitely don’t follow this comment: “you can’t onboard your Apple to enable 
identity-based auth.”

tim


From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Friday, July 10, 2020 at 16:04
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
So you can’t use an Apple MAC address for guest auth, and you can’t onboard 
your Apple to enable identity-based auth.  Apple must be thinking that they can 
drag the entire world, kicking and screaming, into federated authentication 
that Apple products ship knowing how to do (Passpoint, openroaming, etc.).  Do 
they have a proposal for this that I missed?

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Rios, Hector J
Sent: Friday, July 10, 2020 2:56 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] MAC Randomization, a step further...

Apple is moving forward with their privacy efforts. The next step is to 
randomize MAC addresses when connecting to an AP, not just when probing. This 
is coming soon.

https://globalreachtech.com/blog-mac-randomisation-apple/

This is from Apple. Luckily, there is a way to disable private addresses. I 
just don’t know if it will be ON by default.
https://support.apple.com/en-qa/HT211227

Happy Friday!

Hector Rios, Wireless Network Architect
The University of Texas at Austin


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

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