Subject: Re: Authentication and Site Licenses and the Janet Cache
Daniel Feenberg (feenberg@nber.org)
Date: Fri, 26 Feb 1999 13:53:22 -0500 (EST)
Date: Fri, 26 Feb 1999 13:53:22 -0500 (EST) From: Daniel Feenberg <feenberg@nber.org> Message-Id: <199902261853.NAA28325@nber.nber.org> To: arl-ejournal@arl.org Subject: Re: Authentication and Site Licenses and the Janet Cache
(About our experiences with the Janet cache)
Ezri Carlebach <e.carlebach@acu.ac.uk> writes:
>
> The procedure you've outlined would effectively kill Janet's caching
> strategy for your site. If enough sites do this, Janet will "retaliate"
> by pointing port 81 at the off-campus cache, and you're right back
> where you started. Then you pick up on port 82...
I hope Janet doesn't think of us as an enemy to retaliate against.
We do not mark our files non-cacheable, and are quite eager for
subscribers to cache them. I understand there is a header "proxy
revalidate" specified in the HTTP 1.1 specification that requests Janet
seek authorization from our web site before redistributing copies of
our protected pages. If we could take advantage of this facility it
would provide better service to our English clients at no cost to
ourselves. Obviously that is desirable. We would be glad to mark
Janet as authorized for the protected pages and mark those pages "proxy
revalidate", if someone from Janet would give us (informal) assurance
that the revalidation function is implemented. So far, they have not
suggested this. We have no wish for single campus caches to revalidate.
> This isn't the first time I've seen this discussion hashed out. Last
> time I saw it, an engineer at Cisco got involved (don't ask me how).
> His take on the matter was that in the current Internet environment,
> where more and more aggressive, user transparent, server side caching is
> being carried out, authentication via subnet is fundamentally flawed.
CISCO was concerned that web servers were using IP addresses for session
tracking, and thought people should use cookies instead. I agree. But
that argument doesn't have much to do with using network numbers for
site license authentication. I do want to reiterate for this list that
passwords are not a substitute for network numbers when the function is
implementing a site license. The situation is quite different from
protecting a personal shell account. In the latter case the user has an
incentive to keep the password confidential, while in the former case,
the password will inevitably end up posted on the bulletin board. And
as a publisher, I probably *want* that to happen. After all, if no one
is using our protected pages, the library probably won't renew the
subscription. We have to make it easy for users, and we are willing
to see a little leakage around the edges if that is the price.
Another proposal (made by Martin Hamilton of JANET), is for us to
recognize the http "Via" header, which records the chain of caches
through which any request has come. Since we expect that most
universities maintain at least one on-campus cache that is consulted
before queries are passed on to the off-campus (JANET) cache, we can
check for the authorization of the first cache in the chain. As long
as that cache is somewhere in the authorized domain, we will offer the
protected page. As I write this we have about 72 hours of experience
with "Via" headers, and I can only see one request with a chain leading
back to an English university. It is supposed to be deleted only where
a request passes through a firewall, or it may be that the following
explains why longer chains are so rare.
As it happens, the solution that actually happened was that Martin
Hamilton put us on a list of "sites not to forward to off-campus caches"
that he maintains at Janet. It appears that (nearly) all of the English
universities use this list to maintain the ACLs in their cache engines,
so I stopped receiving complaints from English users several days before
the "VIA" header code was implemented in our server. Because the "VIA"
code requires no actions at the remote user site, we are keeping it in
hopes that it will reduce problems in the future, at other sites.
I am aware that HTTP headers are easily forged, but that is not a
serious concern to us at this time. We are more interested in
encouraging widespread use of the web site.
Daniel Feenberg
feenberg@nber.org
National Bureau of Ecnomic Research
This archive was generated by hypermail 2a16 : Wed Dec 22 1999 - 09:15:06 EST