RE: Security Issues (was JSTOR) Pt. 2.

["John Durno" <jdurno@ola.bc.ca>]

liblicense-l@lists.yale.edu writes:

>Actually there are a couple of easy ways to extend access to
>IP-authenticated resources to remote users, such as alumni groups, or in
>our case physican faculty in off-campus hospital locations.  If you want
>to provide access to a limited set of ip-restricted resources, Ezproxy
>works fine.  If you want to provide complete access to campus resources,
>various providers offer VPN solutions.

True, but that isn't quite what I was getting at. I was referring to a
scenario in which an institution wanted to give network access to users
that were NOT covered by database licence agreements, for example by
continuing to act as an internet service provider for their students after
graduation. This isn't a particularly far-fetched example; a number of
schools do this.

In this scenario, if alumni were to be assigned an institutional IP
address when they connected via the campus ISP, this in turn could allow
them to access licensed resources they weren't really entitled to use.

Of course, one can immediately think of workarounds for this problem (such
as reserving a separate pool of IP addresses for alumni dial-in accounts,
or shelling out for licences that cover alumni access), but the point I
was trying to make was that IP-based access in itself does not allow for
very fine-grained control should an institution want to assign different
sets of permissions to different groups of users.


>-----Original Message-----
>From:	John Durno [mailto:jdurno@ola.bc.ca]
>Sent:	Fri 12/13/2002 9:23 AM
>To:	liblicense-l@lists.yale.edu
>Subject:	Re: Security Issues (was JSTOR) Pt. 2.
>
>Ann Okerson writes:
>
>>The ori ginal question is this:  if we know that IP authentication has=20
>>this particular problem, then when should we continue to use it, and=20
>>when/how should we be either abandoning it or trying to improve it?=20
>...
>
>We are probably stuck with IP address authentication for the next few
>years, but we should at least be thinking about what will replace it.
>
>As mentioned earlier, IP address authentication has one distinct
>advantage: it communicates nothing about the user except that they have
>access to a particular network. In such an environment it is very
>difficult to determine which individual users are accessing what 
>content. Not impossible, but generally more trouble than it would be
>worth.
>
>However, the main reason why IP authentication has become the baseline 
>for providing access to research databases is that it is very simple to
>implement. The client network doesn't have to configure their network at
>all, they just have to supply some numbers to the remote host. On the
>server side, there is obviously a certain amount of recordkeeping
>involved, but basically, nothing is simpler than checking the IP address
>of an incoming request against a bunch of IPs stored in a database.
>
>However, IP authentication is a pretty blunt instrument. As noted 
>earlier in the discussion, it isn't very secure: it's open to spoofing,
>and one misconfigured proxy server anywhere on any subscriber's network
>can = create a significant breach.
>
>One other problem that hasn't been mentioned yet, but which might be an
>issue for some institutions: what if you want to give network access to 
>a group of people who aren't covered by your database licence agreements,
>for example alumni? There probably are workarounds for this, such as
>reserving a pool of your IP addresses for the purpose, but this can be
>difficult to implement depending on your network architecture.
>
>So what might replace IP authentication? It's too early to say, but 
>there are a number of possibilities. Certainly the problem of user
>authentication extends way beyond library users accessing research
>databases. Microsoft, the Sun-led Liberty Alliance, and AOL are all
>developing solutions to the problem, although many pundits are concerned
>that their solutions will make a disturbing amount of personal data
>available to commercial interests. But if one of these solutions becomes
>widely accepted as a defacto standard in the world of commerce, there 
>will probably be some pressure for libraries to adopt it as well.
>
>One initiative that sounds quite promising is Shibboleth (
>http://shibboleth.internet2.edu/index.html ), described on their web site
>as "an open source implementation to support inter-institutional sharing
>of web resources subject to access controls." It retains the main
>advantage of IP authentication, in that Shibboleth makes it possible to
>maintain the privacy of the user by restricting the amount of personal
>information communicated between client and server, while at the same time
>providing finer-grained control if required. It would definitely address
>the problems with IP authentication that have been discussed here.
>
>The downside is that Shibboleth is not as easy to implement as IP
>authentication in that it will require significant configuration on both
>the client and the server side. But then, nothing will be as easy to
>implement as basic IP address authentication.
>
>John Durno
>Email:   jdurno@ola.bc.ca