Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Turner, Ryan H]

Are you referring to the serial?   Would Chad be willing to post his ulang for 
thr freeRadius config?

Ryan Turner
Head of Networking, ITS
The University of North Carolina at Chapel Hill
+1 919 274 7926 Mobile
+1 919 445 0113 Office

On Aug 6, 2020, at 5:02 PM, Philippe Hanset 
<005cd62f91b7-dmarc-requ...@listserv.educause.edu> wrote:

 About EAP-TLS blocking ...
You do not need to revoke a cert (too painful indeed for operator and user). 
Chad wrote a hook for the Anyroam service that identifies the certificate’s 
fingerprint. So If a device misbehaves, you can just block the device via the 
certificate’s fingerprint. With one certificate per device, you end up with the 
same as a SIM card (or the good ol MAC address :)

Philippe Hanset, CEO
ANYROAM LLC
www.anyroam.net
www.eduroam.us
+1 (865) 236-0770

On Aug 6, 2020, at 11:29 AM, Turner, Ryan H  wrote:


The other issue comes in with blocking devices.  On open networks/PSK networks, 
this will make isolating bad devices really difficult.  We have relied on MAC 
address blocks for over a decade.  They work very well.  Yes, you can get a 
determined individual that can get past/change their MAC address.  But that is 
going to be a tiny fraction of cases, and MAC blocking is an effective way of 
blocking a bad device.

We require registration for our PSK network.  So the private MAC addresses will 
be blocked effectively there.  But we haven’t required registration on eduroam 
(our primary), because we have identity in the certificate.  We chose not to 
use OCSP (but we can), but if we revoke a cert, we have to also block the user 
from getting another certificate (2 steps, instead of one, which is why we have 
stayed with MAC blocking).  We could require folks to register for eduroam, but 
that is such a nasty thing to do to the users.   Gr.  Not an easy fix.

Ryan

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Enfield, Chuck
Sent: Thursday, August 6, 2020 11:14 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

I’ll also add that identity is what makes a private network private.  Yes, you 
can check identity at connection time then throw it away and still remain 
private, but that’s never been an option for us when designing services with 
our risk, legal and info security departments.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Julian Y Koh
Sent: Thursday, August 06, 2020 10:59 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

On Aug 6, 2020, at 09:51, Enfield, Chuck 
mailto:cae...@psu.edu>> wrote:

How can we fulfill DMCA requirements when we can’t even identify a device, let 
alone the user?  If you want to remain anonymous, use a different network.

IANAL, and I don’t even play one on TV, but my admittedly old understanding of 
the DMCA is that it’s not necessarily mandating that you have to be able to 
identify every single device on your network.  Indeed, some institutions’ 
responses to DMCA notices has been that they don’t have the necessary 
information to be able to take action.  So IMO, assuming (which is dangerous) 
that I’m correct, that if MAC randomization puts an undue burden and/or large 
obstacles on your ability to track down a device/user and cut it off from the 
network, the DMCA alone shouldn’t be seen as a mandate to try to disable MAC 
randomization.

--
Julian Y. Koh
Associate Director, Telecommunications and Network Services
Northwestern Information Technology

2020 Ridge Avenue #331
Evanston, IL 60208
+1-847-467-5780
Northwestern IT Web Site: 
>
PGP Public Key: 
>


**
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: [External] Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Hunter Fuller]

Ryan,

We have a flag you can set that will hide you from the UAH directory and
cause us to never reveal that you're a student ("FERPA hold"). One can
assume that privacy-conscious students might set this flag. By that metric,
12% of our students are privacy-conscious.

HTH

--
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 Thu, Aug 6, 2020 at 6:03 PM Turner, Ryan H 
wrote:

> Personally this just doesn’t resonate to me.  How many students care about
> privacy concerns every time they sign up for the latest social data mining
> app?
>
> Ryan Turner
> Head of Networking, ITS
> The University of North Carolina at Chapel Hill
> +1 919 274 7926 Mobile
> +1 919 445 0113 Office
>
> On Aug 6, 2020, at 3:36 PM, Tim Cappalli <
> 0194c9ecac40-dmarc-requ...@listserv.educause.edu> wrote:
>
> 
>
> Sure, everyone has their motives for privacy. But tracking a device by MAC
> address across networks is a huge and very real issue. Think about
> everywhere you see the XFINITY SSID. Every Comcast cable modem in the
> country broadcasts it. What a massive tracking domain if you have it saved
> on your phone. Those are the things Google and Apple are trying to prevent.
> Has really nothing to do with their own internal platform operation.
>
>
>
> That is why just setting a MAC per-SSID doesn’t cut it. But as per usual,
> the networking industry didn’t take this seriously 5+ years ago and OS
> vendors now have to back out of privacy preserving changes or face
> ridiculous (and IMO unnecessary) backlash.
>
>
>
> tim
>
>
>
> *From: *The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> *Date: *Thursday, August 6, 2020 at 15:26
> *To: *WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> *Subject: *Re: [WIRELESS-LAN] MAC Randomization, a step further...
>
> Our lawyers tell me that we’re responsible for takedowns by virtue of it
> being on our network.  If the content is on host we manage we would just
> remove the content, but If it’s not our host, which is usually the case,
> then we have to remove the host from the network.
>
>
>
> FWIW, I’m not losing sleep over the liability issue.  We’re not putting
> the MAC auth genie back in the bottle any time soon, so the university is
> just going to live with that risk until we have a better option.  Besides,
> since we got a border firewall, takedowns have become really rare.  I’m
> more concerned about providing a quality connection and support experience
> for our users and getting compromised devices off the network.  The point
> of my original comment wasn’t really to debate DMCA, but to challenge Tim’s
> objection to disabling privacy settings.  There are good reasons to disable
> them for our networks on a per SSID basis, and if our users want to use the
> MAC auth network in the res halls, that’s what they’ll have to do.
>
>
>
> I also find it ironic that Apple and Google pretend to care about our
> privacy.  What they care about is our perception of their products.  If
> they actually cared about our privacy they would collect far less of our
> data than they do.  I’m not offended by it, but my position is
> fundamentally the same as theirs – if you’re unwilling to sacrifice your
> privacy, don’t use our stuff.
>
>
>
> *From:* The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Jeffrey D. Sessler
> *Sent:* Thursday, August 06, 2020 2:36 PM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* Re: [WIRELESS-LAN] MAC Randomization, a step further...
>
>
>
> Chuck,
>
>
>
> What DMCA requirements do you speak of?  As an ISP there is very little we
> technically have to do, but many EDU’s go above and beyond the
> requirements.  We have far more requirements if copyrighted information is
> being hosted on systems we own, but when it’s an end-user, there are little
> to no obligations, and if MAC address randomization makes it impossible,
> then there is nothing more one has to do under the DMCA.
>
>
>
> Jeff
>
>
>
> *From: *The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> *Date: *Thursday, August 6, 2020 at 7:52 AM
> *To: *WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> *Subject: *Re: [WIRELESS-LAN] MAC Randomization, a step further...
>
> How can we fulfill DMCA requirements when we can’t even identify a device,
> let alone the user?  If you want to remain anonymous, use a different
> network.
>
>
>
> *From:* The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Tim Cappalli
> *Sent:* Thursday, August 06, 2020 10:45 AM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* Re: [WIRELESS-LAN] MAC Randomization, a step further...
>
>
>
> Yikes. I hope network operators are not asking users to disable user
> 

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Philippe Hanset]

About EAP-TLS blocking ...
You do not need to revoke a cert (too painful indeed for operator and user). 
Chad wrote a hook for the Anyroam service that identifies the certificate’s 
fingerprint. So If a device misbehaves, you can just block the device via the 
certificate’s fingerprint. With one certificate per device, you end up with the 
same as a SIM card (or the good ol MAC address :)

Philippe Hanset, CEO
ANYROAM LLC
www.anyroam.net
www.eduroam.us
+1 (865) 236-0770

On Aug 6, 2020, at 11:29 AM, Turner, Ryan H  wrote:


The other issue comes in with blocking devices.  On open networks/PSK networks, 
this will make isolating bad devices really difficult.  We have relied on MAC 
address blocks for over a decade.  They work very well.  Yes, you can get a 
determined individual that can get past/change their MAC address.  But that is 
going to be a tiny fraction of cases, and MAC blocking is an effective way of 
blocking a bad device.
 
We require registration for our PSK network.  So the private MAC addresses will 
be blocked effectively there.  But we haven’t required registration on eduroam 
(our primary), because we have identity in the certificate.  We chose not to 
use OCSP (but we can), but if we revoke a cert, we have to also block the user 
from getting another certificate (2 steps, instead of one, which is why we have 
stayed with MAC blocking).  We could require folks to register for eduroam, but 
that is such a nasty thing to do to the users.   Gr.  Not an easy fix.
 
Ryan
 
From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Enfield, Chuck
Sent: Thursday, August 6, 2020 11:14 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
 
I’ll also add that identity is what makes a private network private.  Yes, you 
can check identity at connection time then throw it away and still remain 
private, but that’s never been an option for us when designing services with 
our risk, legal and info security departments.
 
From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Julian Y Koh
Sent: Thursday, August 06, 2020 10:59 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
 
On Aug 6, 2020, at 09:51, Enfield, Chuck  wrote:
 
How can we fulfill DMCA requirements when we can’t even identify a device, let 
alone the user?  If you want to remain anonymous, use a different network.
 
IANAL, and I don’t even play one on TV, but my admittedly old understanding of 
the DMCA is that it’s not necessarily mandating that you have to be able to 
identify every single device on your network.  Indeed, some institutions’ 
responses to DMCA notices has been that they don’t have the necessary 
information to be able to take action.  So IMO, assuming (which is dangerous) 
that I’m correct, that if MAC randomization puts an undue burden and/or large 
obstacles on your ability to track down a device/user and cut it off from the 
network, the DMCA alone shouldn’t be seen as a mandate to try to disable MAC 
randomization.  

-- 
Julian Y. Koh
Associate Director, Telecommunications and Network Services
Northwestern Information Technology
 
2020 Ridge Avenue #331
Evanston, IL 60208
+1-847-467-5780
Northwestern IT Web Site: 
PGP Public Key: 
 
**
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: [WIRELESS-LAN] MAC Randomization, a step further...

[Philippe Hanset]

For local users with 802.1X you can disable username authentication and for 
roaming users with 802.1X, Hopefully CUI (Chargeable User Identity) will become 
more mainstream and you can block by CUI (Needs to be supported in RADIUS).
 MAC address was never designed to identify, but we all found it very useful 
for that purpose :)... time to change !

Philippe Hanset, CEO
ANYROAM LLC
www.anyroam.net
www.eduroam.us
+1 (865) 236-0770

On Aug 6, 2020, at 11:03 AM, Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu> wrote:


And you can continue to do that with the randomized MAC and tell them you took 
action against the device identifier that was presented at the time in 
question. Nothing changes in that regard 
 
Julian’s response is my understanding as well.
 
From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Thursday, August 6, 2020 at 11:00
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

We could always take down a device by MAC address.  It was weak, but it allowed 
us to say we did something.
 
From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Tim Cappalli
Sent: Thursday, August 06, 2020 10:55 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
 
Not sure how this really changes anything if you never had a strong user 
identity in the first place.
 
 
From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Thursday, August 6, 2020 at 10:51
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

How can we fulfill DMCA requirements when we can’t even identify a device, let 
alone the user?  If you want to remain anonymous, use a different network.
 
From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Tim Cappalli
Sent: Thursday, August 06, 2020 10:45 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
 
Yikes. I hope network operators are not asking users to disable user privacy 
protections. That is a slippery slope.
 
tim
 
From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Thursday, August 6, 2020 at 10:40
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Was sent this link yesterday, might help some.
 
https://community.cisco.com/t5/security-documents/random-mac-address-how-to-deal-with-it-using-ise/ta-p/4049321
 
 
Blake Brown
Infrastructure Manager - MHCC
 
 
From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Norman Elton 

Sent: Thursday, August 6, 2020 5:48 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
 
External Email

>> I have heard that on the latest beta that came out Tuesday the randomization 
>> will only happen once per SSID and not change as well.
 
Oh? We will definitely be testing that. Can you share your source? My phone is 
still on Beta 3, and I don't have an update available for Beta 4 yet. I suppose 
I have to wait for my ticket to ride.
 
Thanks for the tip,
 
Norman
 
On Thu, Aug 6, 2020 at 6:55 AM Walter Reynolds  wrote:
I have heard that on the latest beta that came out Tuesday the randomization 
will only happen once per SSID and not change as well.


Walter Reynolds
Network Architect
Information and Technology Services
University of Michigan
(734) 615-9438
 
On Wed, Aug 5, 2020, 9:09 PM Norman Elton  wrote:
>> Depending on your tolerance for the disruption you could implement a network 
>> access policy blocking access to the
>> range of local MAC's and intercept with a captive portal with instructions 
>> on how to turn this off. However, I can't imagine
>> this being sustainable.
 
Newer Androids use the same MAC address range for their randomization 
algorithm. Unlike iOS; however, their MAC address is randomized once per SSID, 
and doesn't change over time. We already see a large number of private mac 
addresses on our campus, I anecdotally confirmed a handful of them are Android 
users, and confirmed the MAC remains consistent.
 
Long story short, if you're looking to restrict randomized MAC addresses, or 
even report on their usage, you'll find more than just iOS users :-/
 
There is a fine line between "troubleshooting" and "tracking". Unfortunately, 
preventing malicious tracking is going to impact our helpful troubleshooting. 
As an EAP-TLS campus, we're going to attempt to de-dupe the randomized MAC 
addresses using the certificate serial number. This way, if someone calls on 
Monday to complain about a problem on Saturday, at least we have someplace to 
start.
 
Norman
 
 
On Mon, Aug 3, 2020 at 10:28 AM John Turner  wrote:
Update on my testing. 
 
I created an 802.1X network and connected my ios14 phone to it - over the 10 
days or so the phone has pretty much just sat - 

RE: [WIRELESS-LAN] MAC Randomization, a step further...

[Turner, Ryan H]

The other issue comes in with blocking devices.  On open networks/PSK networks, 
this will make isolating bad devices really difficult.  We have relied on MAC 
address blocks for over a decade.  They work very well.  Yes, you can get a 
determined individual that can get past/change their MAC address.  But that is 
going to be a tiny fraction of cases, and MAC blocking is an effective way of 
blocking a bad device.

We require registration for our PSK network.  So the private MAC addresses will 
be blocked effectively there.  But we haven’t required registration on eduroam 
(our primary), because we have identity in the certificate.  We chose not to 
use OCSP (but we can), but if we revoke a cert, we have to also block the user 
from getting another certificate (2 steps, instead of one, which is why we have 
stayed with MAC blocking).  We could require folks to register for eduroam, but 
that is such a nasty thing to do to the users.   Gr.  Not an easy fix.

Ryan

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Enfield, Chuck
Sent: Thursday, August 6, 2020 11:14 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

I’ll also add that identity is what makes a private network private.  Yes, you 
can check identity at connection time then throw it away and still remain 
private, but that’s never been an option for us when designing services with 
our risk, legal and info security departments.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Julian Y Koh
Sent: Thursday, August 06, 2020 10:59 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

On Aug 6, 2020, at 09:51, Enfield, Chuck 
mailto:cae...@psu.edu>> wrote:

How can we fulfill DMCA requirements when we can’t even identify a device, let 
alone the user?  If you want to remain anonymous, use a different network.

IANAL, and I don’t even play one on TV, but my admittedly old understanding of 
the DMCA is that it’s not necessarily mandating that you have to be able to 
identify every single device on your network.  Indeed, some institutions’ 
responses to DMCA notices has been that they don’t have the necessary 
information to be able to take action.  So IMO, assuming (which is dangerous) 
that I’m correct, that if MAC randomization puts an undue burden and/or large 
obstacles on your ability to track down a device/user and cut it off from the 
network, the DMCA alone shouldn’t be seen as a mandate to try to disable MAC 
randomization.

--
Julian Y. Koh
Associate Director, Telecommunications and Network Services
Northwestern Information Technology

2020 Ridge Avenue #331
Evanston, IL 60208
+1-847-467-5780
Northwestern IT Web Site: 
>
PGP Public Key: 
>


**
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] MAC Randomization, a step further...

[Enfield, Chuck]

I’ll also add that identity is what makes a private network private.  Yes, you 
can check identity at connection time then throw it away and still remain 
private, but that’s never been an option for us when designing services with 
our risk, legal and info security departments.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Julian Y Koh
Sent: Thursday, August 06, 2020 10:59 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

On Aug 6, 2020, at 09:51, Enfield, Chuck 
mailto:cae...@psu.edu>> wrote:

How can we fulfill DMCA requirements when we can’t even identify a device, let 
alone the user?  If you want to remain anonymous, use a different network.

IANAL, and I don’t even play one on TV, but my admittedly old understanding of 
the DMCA is that it’s not necessarily mandating that you have to be able to 
identify every single device on your network.  Indeed, some institutions’ 
responses to DMCA notices has been that they don’t have the necessary 
information to be able to take action.  So IMO, assuming (which is dangerous) 
that I’m correct, that if MAC randomization puts an undue burden and/or large 
obstacles on your ability to track down a device/user and cut it off from the 
network, the DMCA alone shouldn’t be seen as a mandate to try to disable MAC 
randomization.

--
Julian Y. Koh
Associate Director, Telecommunications and Network Services
Northwestern Information Technology

2020 Ridge Avenue #331
Evanston, IL 60208
+1-847-467-5780
Northwestern IT Web Site: 
>
PGP Public Key: 
>


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

[Green, William C]

Yikes. I hope network operators are not asking users to disable user privacy 
protections. That is a slippery slope.

tim

User privacy is one goal.  It is not absolute.  There are many that must be 
evaluated and weighted in different environments with an institution's goals 
(e.g. security, operations, funding, etc).

The OS vendors are changing expected behavior many goals are built upon, it 
will take some time to figure out what all the implications are.


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

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Blake Brown]

Good point Tim and that would be us. However we are getting ready to migrate to 
Meraki wireless this month, away from Cisco, and slowly reopening for some on 
campus classes. We didn't have some of the "tracking" functionality with our 
Cisco deployment but will with our Meraki.

COVID has thrown another requirement for "tracking" users on the campus which 
is currently done completely manually (paper) by the classroom instructors. I 
was hoping to automate some of this or at least be able to provide limited 
contact tracing information for a given period, longer than 24 hours, if 
requested.

Has anyone on the list worked through COVID contact tracing with their systems 
yet? If so what were some of the key takeaways you learned from it? Good and 
bad.


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

Sent: Thursday, August 6, 2020 8:06 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

External Email


There are identity requests, and take downs.  Identity requests are frequent 
and come with little to know liability.  Take downs are less frequent, but 
failing to take down protected content makes the service provider liable.  Or 
plan for take downs when we can’t identify a user is to block the device.  If 
we can’t identify either we’ve got a liability problem.  It may not be a large 
risk, but I don’t think our lawyers will like it.



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Julian Y Koh
Sent: Thursday, August 06, 2020 10:59 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...



On Aug 6, 2020, at 09:51, Enfield, Chuck 
mailto:cae...@psu.edu>> wrote:



How can we fulfill DMCA requirements when we can’t even identify a device, let 
alone the user?  If you want to remain anonymous, use a different network.



IANAL, and I don’t even play one on TV, but my admittedly old understanding of 
the DMCA is that it’s not necessarily mandating that you have to be able to 
identify every single device on your network.  Indeed, some institutions’ 
responses to DMCA notices has been that they don’t have the necessary 
information to be able to take action.  So IMO, assuming (which is dangerous) 
that I’m correct, that if MAC randomization puts an undue burden and/or large 
obstacles on your ability to track down a device/user and cut it off from the 
network, the DMCA alone shouldn’t be seen as a mandate to try to disable MAC 
randomization.

--

Julian Y. Koh

Associate Director, Telecommunications and Network Services

Northwestern Information Technology



2020 Ridge Avenue #331

Evanston, IL 60208

+1-847-467-5780

Northwestern IT Web Site: 
>

PGP Public Key: 
>



**
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] MAC Randomization, a step further...

[Enfield, Chuck]

There are identity requests, and take downs.  Identity requests are frequent 
and come with little to know liability.  Take downs are less frequent, but 
failing to take down protected content makes the service provider liable.  Or 
plan for take downs when we can’t identify a user is to block the device.  If 
we can’t identify either we’ve got a liability problem.  It may not be a large 
risk, but I don’t think our lawyers will like it.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Julian Y Koh
Sent: Thursday, August 06, 2020 10:59 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

On Aug 6, 2020, at 09:51, Enfield, Chuck 
mailto:cae...@psu.edu>> wrote:

How can we fulfill DMCA requirements when we can’t even identify a device, let 
alone the user?  If you want to remain anonymous, use a different network.

IANAL, and I don’t even play one on TV, but my admittedly old understanding of 
the DMCA is that it’s not necessarily mandating that you have to be able to 
identify every single device on your network.  Indeed, some institutions’ 
responses to DMCA notices has been that they don’t have the necessary 
information to be able to take action.  So IMO, assuming (which is dangerous) 
that I’m correct, that if MAC randomization puts an undue burden and/or large 
obstacles on your ability to track down a device/user and cut it off from the 
network, the DMCA alone shouldn’t be seen as a mandate to try to disable MAC 
randomization.

--
Julian Y. Koh
Associate Director, Telecommunications and Network Services
Northwestern Information Technology

2020 Ridge Avenue #331
Evanston, IL 60208
+1-847-467-5780
Northwestern IT Web Site: 
>
PGP Public Key: 
>


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

[Julian Y Koh]

On Aug 6, 2020, at 09:51, Enfield, Chuck 
mailto:cae...@psu.edu>> wrote:

How can we fulfill DMCA requirements when we can’t even identify a device, let 
alone the user?  If you want to remain anonymous, use a different network.

IANAL, and I don’t even play one on TV, but my admittedly old understanding of 
the DMCA is that it’s not necessarily mandating that you have to be able to 
identify every single device on your network.  Indeed, some institutions’ 
responses to DMCA notices has been that they don’t have the necessary 
information to be able to take action.  So IMO, assuming (which is dangerous) 
that I’m correct, that if MAC randomization puts an undue burden and/or large 
obstacles on your ability to track down a device/user and cut it off from the 
network, the DMCA alone shouldn’t be seen as a mandate to try to disable MAC 
randomization.

--
Julian Y. Koh
Associate Director, Telecommunications and Network Services
Northwestern Information Technology

2020 Ridge Avenue #331
Evanston, IL 60208
+1-847-467-5780
Northwestern IT Web Site: 
PGP Public Key: 


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