Re: Wireless Guest Access

[Matt Arthur <arthur () WUSTL EDU>]

Thanks for the good discussion.  To answer Joe's particular comment
below, we would set up this ESSID to ONLY have access to http, port 80
traffic so their access to our university would be the same as if they
were coming in from off-campus.

It sounds like most of you are doing some kind of 'sponsored' guest
access (which is what we do for our current system), but how do parents
and prospective students find someone to 'sponsor' them?

And, do you think (assuming the technical security problems are taken
care of) there is large political (or legal) risk in simply allowing
folks to come in and use a non-login guest account?

Thanks,
Matt

Matthew K Arthur, CISSP
Director, NTS-Enterprise Networks
Washington University in St. Louis
W: 314.935.7388, F:314.935.7142

> -----Original Message-----
> From: Joe St Sauver [mailto:joe () OREGON UOREGON EDU]
> Sent: Thursday, September 28, 2006 12:24 PM
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Subject: Re: [SECURITY] Wireless Guest Access
>
> Hi,
>
> > We've had a guest wireless access plan in place for about a year
now. The
> > guests have to be "sponsored" by a University dept. The sponsor
controls when
> > they have access to the net (day, time of day). We don't restrict
where they
> > go once they connect. They do have to login to connect to the net so
we have
> > an audit trail.
>
> Any concerns about guest access to faculty/staff/student-only licensed
> proprietary content or proprietary software?
>
> I've seen a number of instances where access to those sort of
resources
> is controlled *not* by a formal AAA system that tracks roles and
controls
> access on a granular basis, but simply by CIDR netblock (or heaven
> forfend, by rDNS). Thus, if a guest gets access to the network, say
for
> reading their email back home or surfing the web, they also get access
> to all the institutionally-licensed goodies, too.
>
> I suppose you could probably require guests to agree not to access
stuff
> they're not supposed to access as a condition of logging on, but
defining
> precisely what that might be might only serve to highlight those
licensed
> resources and provide a sort of "shopping list" for those of dubious
> integrity.
>
> Oh yes: and just to save folks the trouble of writing, yes, obviously
this
> is *not* a new problem unique to wireless guest access deployments
(for
> example, it has always been a problem which has existed for open wired
> jacks in publicly accessible spaces, or for residential network
connections
> that end up shared with friends who aren't currently attending the
> institution, just to mention a couple of well known scenarios).
>
> Regards,
>
> Joe