Company-owned devices don't always have the opportunity to be onboarded by
staff before the device gets into the hands of the end user, especially in this
current environment where everything is drop-shipped from the vendor or service
provider and never even touches corporate headquarters.
There are also plenty of examples of tools that the employee needs to do their
job that are not provided by the business. Office furniture for home offices
is the perfect example in this current environment.
-----Original Message-----
From: The EDUCAUSE Wireless Issues Community Group Listserv
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> On Behalf Of Jeffrey D. Sessler
Sent: Thursday, April 22, 2021 12:04 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] WPA3/OWE as campus solution?
On 2021-04-21 21:30:53+0000, 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
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 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+0000, 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 (told you I was going to use it more).
Right now, if you connect on eduroam (VT affiliate or a roaming user), as a
sponsored guest, or with a (MAC) registered device, you end up in the same
network. Lets call it the accountable network.
If you connect as a self-sponsored guest, you end up in a different network.
Let's call it the unaccountable network.
The unaccountable network is a different routing instance, with clearly
segmented IP space, where the traffic is basically hairpinned at the border.
_Both_ networks are zero-trust. With the accountable network, we are telling
sysadmins that we can additionally answer the question, "who is this?" given an
IP/timestamp. Those in the unaccountable network should be treated as coming
from the villainous wilderness that is the Internet. Among other things, this
allows for writing some really coarse ACLs that mostly filter out noise.
Let's take another detour on some core considerations for our guest network.
We've decided that someone should be able to walk on campus and be able to use
the wireless network. Maybe that takes some self-sponsoring, maybe not, but
they can get on the network without us providing credentials for them. This
means there is an open(ish) network with unreliable or no identity sitting
right next to our .1X network.
So what does that mean for enforcement? Effectively, reliable authentication
is already optional. Adding a captive portal to the open network doesn't change
that. Zero-trust and the accountable vs unaccountable network split helps quite
a bit here, and I think it's pretty obvious why.
On 2021-04-21 21:30:53+0000, 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.
I don't think I've made that specific claim, but I have made a similar one
(though not in this thread, I think), that users don't deal with "enrollment"
outside of campus (pre-graduation), referring to restaurants, public venues,
hotels, etc.
Either way, I see where you are coming from. It is not something I had
considered before. I do not find it compelling. I'm not going to make my users
miserable because someone else's network experience is painful.
As a final thought, it is my estimation that captive portals and mac auth are
on their way out industry wide. (Why is a rambling for another
time.) I'd rather be on the front edge of that wave than get caught by
surprise, and I suspect the users would agree.
Well, I rambled _a lot_ in this email. Congrats if you made it to the end, I
guess. If I had more time, it would have been shorter.
--
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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunity&data=04%7C01%7Cch.anderson%40NORTHEASTERN.EDU%7C3805ce4b90014de65ca608d905a84cb2%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637547042668633763%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yQUrZSNhxaUXzkTUFT5x7Nhv%2B21xnEJOjRO6I76U4oI%3D&reserved=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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunity&data=04%7C01%7Cch.anderson%40NORTHEASTERN.EDU%7C3805ce4b90014de65ca608d905a84cb2%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637547042668633763%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yQUrZSNhxaUXzkTUFT5x7Nhv%2B21xnEJOjRO6I76U4oI%3D&reserved=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
