I think your legal needs to revisit their position. There are a number of great articles about the EDU requirements of DMCA. A university is every bit the ISP, and in fact, there is no legal obligation under the DMCA for student enforcement as you are but the transit for their data. Most all campuses use it as a teaching moment, but it’s not a requirement. You also have no obligation to identify someone – If you rotate logs every 15 days and the request comes in on the 16th day, you can respond that you have no data. This is also no obligation to match an IP with a person.
Jeff From: "wireless-lan@listserv.educause.edu<mailto:wireless-lan@listserv.educause.edu>" <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> on behalf of Mike Cunningham <mike.cunning...@pct.edu<mailto:mike.cunning...@pct.edu>> Reply-To: "wireless-lan@listserv.educause.edu<mailto:wireless-lan@listserv.educause.edu>" <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> Date: Tuesday, March 1, 2016 at 9:31 AM To: "wireless-lan@listserv.educause.edu<mailto:wireless-lan@listserv.educause.edu>" <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> Subject: Re: [WIRELESS-LAN] Self-registered MAC device bypass- worth the headaches? Talk to your campus legal office before opening your wifi to the world. We asked ours about this and were strongly advised against it. Contracting with a local telecom company to provide free wifi would be better. A college or university is not an ISP like a Verizon or AT&T or Comcast is. If someone is abusing the campus network you’re responsible for their action. If law enforcement comes knocking on your door asking about network traffic originating from you campus you need to be able to point to a person or at least a room and say “there”. If it was a guest on campus for a short period of time you still need to be able to identify who that guest was. At least that is the interpretation of current law according to our legal office. Mike Cunningham Pennsylvania College of Technology From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of David R. Morton Sent: Tuesday, March 01, 2016 12:21 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] Self-registered MAC device bypass- worth the headaches? Joel, thanks for the detailed reply. I agree that Personal PSK is an interesting idea, but it may fall apart at scale (we see 200k+ devices per week), security, implementation or other burdens. My thoughts about on boarding, user name as part of the credential/password have been along the same lines as yours. While we wouldn’t put all of their devices on the same VLAN, I would see them being able to access their printers, chrome cast, AppleTV, etc. The later is already possible using something like ClearPass and AirGroup. We’ve been engaged in some conversations with our vendor about how to solve this problem, but so far there isn’t anything to report. As an aside, we are also keeping an eye on MAC randomization and how this might impact systems based on MAC for authentication and other headaches. David David Morton Director, Mobile Communications Service Owner: Wi-Fi, Mobile & HuskyTV University of Washington dmor...@u.washington.edu<mailto:dmor...@u.washington.edu> tel 206.221.7814 On Mar 1, 2016, at 9:02 AM, Coehoorn, Joel <jcoeho...@york.edu<mailto:jcoeho...@york.edu>> wrote: Ruckus supports a PPSK variant, as well. I'm just gonna put this out there. I have this idea in my head for an ideal wifi service. It starts with personal pre-shared key (PPSK), but it's something I don't believe is possible yet with any vendor. Step one is to create a unique key prefix for each user, effectively embedding a username value (the prefix) into the same field as the key/password. The prefix would be as short as possible, perhaps as small as three characters, in order to keep entry into devices simple. The purpose of this prefix is to allow users to choose their own wifi password, while still ensuring that each PSK value is unique and identifiable to a given user. If we don't value allowing users to choose their own wifi passwords, we could instead generate and assign them, and just map back the assigned key to the user.. but I believe there is value in this. Users would onboard by first connecting to a portal available via open/limited ssid to claim their key. They would have to log in with their traditional username/password. The portal would then prompt them for a key suffix (their wifi password), and then show them the complete key (prefix + suffix), which would be registered with our system. It would also have options to show them history for devices authenticated using their key, expire an old/create a new key using the same prefix, and other typical account management options. Once created, that key could be used with anything that supports traditional PSK connections. One important feature that I'd like to see as part of this, and what I think helps make this idea unique, is that devices authenticated with the same PPSK should always end up with the same vlan id. In this way, a student would be able to, for example, connect to a desktop in his room from the phone/tablet he brought to class and grab a file he forget to show an instructor. It also makes things like wireless printers, long the bane or our existence, almost reasonable in terms of setup and support. By keeping a prefix that's unique to each user, or mapping all key assignments back to the user, we can still always know who is responsible for a given device. We could do things like get a report of keys that authenticate more than, say, 6 devices to monitor for key abuse, expire keys when there is a problem, engage a known user when expiring old keys is not enough, and even map users to specific vlan pools for network policy enforcement. We could also create keys for events or specially classes of device (security cameras, door locks, wifi phones, etc). Additionally, per-user keys means each user's over-the-air signals have different encryption keys, preventing things like firesheep from working. This is just about all the things we do with 802.1x today, but in a form that's much friendlier to the consumer devices we have to support. This plan effectively embeds a username (the prefix) and a password (suffix) into the same value, with our without the prefix, so some of the same security concerns apply, but these are solvable problems. We just need to get vendors on board with the idea. [http://www.york.edu/Portals/0/Images/Logo/YorkCollegeLogoSmall.jpg] Joel Coehoorn Director of Information Technology 402.363.5603 jcoeho...@york.edu<mailto:jcoeho...@york.edu> The mission of York College is to transform lives through Christ-centered education and to equip students for lifelong service to God, family, and society On Tue, Mar 1, 2016 at 10:20 AM, David R. Morton <dmor...@uw.edu<mailto:dmor...@uw.edu>> wrote: Matt, Bill and others, You’d indicated that you have instructions for most common devices, is this something that you can share. Like others, we have a manual registration process (built on ClearPass), but it does require the MAC in order to complete the registration. The Amazon Echo is now relatively straightforward, as it shows up in the Alexa app after you’ve connected your phone to the Echo. To find it, users open the Alexa app, go to settings, choose the device and scroll all the way down to the bottom of the screen. There it will show you the software version, serial number and MAC address. All of that said, I haven’t been able to test the latest versions to see if you can do all of this without needing to connect to the Internet. If you aren’t we are back at square one and have to take it off site to get through the initial setup, which is a real pain. Another device we’ve had a lot of issues with is the newest AppleTV. Again I haven’t checked the latest update so this may have changed, but when it first came out, you had to do a little dance to get the MAC. The dance had you connect it to wired, navigate to the network settings when the MAC address and then remove the wired cable. This would put the device back into Wi-Fi mode and would display the Wi-Fi MAC. Then you are able to manually register it and go through the complete process. Chromecast has had a few other issues, mostly related to dropping sessions and making poor AP choices. This whole discussion has got me thinking and brings up a topic that I think that the industry needs to address. There is a growing number of devices that don’t support 802.1x and the number those devices will continue to as Internet of Things and more consumer devices make it onto our campuses. We need a better, easier way for our students, faculty and staff to connect appropriate devices to the network. Using a captive portal is one way to try to get around these restrictions and get the devices on the network, but as this thread demonstrates it brings other difficulties. Some schools use a PSK network to onboard non-802.1x devices, but this too has problems. While it makes it easy for the user to get devices on the network, there isn’t a good way to track the owner of that device. It also raises and issue of why anyone would go through the 802.1x process when they can just put their devices on the PSK network. Putting restrictions on the PSK network will help, but still not a great solution. \ David David Morton Director, Mobile Communications Service Owner: Wi-Fi, Mobile & HuskyTV University of Washington dmor...@u.washington.edu<mailto:dmor...@u.washington.edu> tel 206.221.7814<tel:206.221.7814> On Mar 1, 2016, at 7:21 AM, Williams, Matthew <mwill...@kent.edu<mailto:mwill...@kent.edu>> wrote: Our helpdesk folks sat down and wrote up documents on how to find the MAC addresses for as many devices as they could. We haven’t done any instructions for the Amazon Echoes yet. We hit the most common devices and are waiting to see what tickets we get for devices that we missed so we can build them into our registration page. Our registration page was written in-house and the developers set it up to display the instructions for finding the MAC address, including screen shots, based on the device that you selected in the drop down. Respectfully, Matt From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Thomas Carter Sent: Tuesday, March 1, 2016 10:01 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@listserv.educause.edu> Subject: Re: [WIRELESS-LAN] Self-registered MAC device bypass- worth the headaches? This is something we struggle with, especially being a small school. Keeping up with the latest Chromecast/Roku/Amazon Echo, etc devices is near impossible. A big thank you to product designers who put the MAC on a label on the outside. Thomas Carter Network & Operations Manager Austin College From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman Sent: Tuesday, March 1, 2016 8:12 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: [WIRELESS-LAN] Self-registered MAC device bypass- worth the headaches? Hi Everyone, Not looking for a lot of input on all of the things you CAN do- just asking a focused question for those that are doing it. We're piloting the ability for students to self-register games, TVs, Roku, etc. but am astounded at how hard some devices are to find MAC addresses for from the user side. Amazon Echo is notorious, also fighting with a Roku 2. No labels, not easy to find in menu. Sure, you can find all of this on APs, but that isn't "self-service" for self-registration. Anyone have thoughts, comments, scars, suggestions? I know Clearpass and ISE can fingerprint, but I'm finding that's far from accurate at times, and again- doesn't help with "register YOUR device by MAC" for users that can't see what network admins use. -Lee Badman Lee H. Badman Network Architect/Wireless TME ITS, Syracuse University 315.443.3003<tel:315.443.3003> ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
