W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997


From: David W. Morris <dwm@xpasc.com>
Date: Tue, 25 Nov 1997 08:49:57 -0800 (PST)
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.GSO.3.96.971125084427.17481A-100000@shell1.aimnet.com>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4818

On Tue, 25 Nov 1997, Marc Salomon wrote:

> Recycling existing authentication techniques, a server can change the
> realm under which a namespace is protected over time while authenticating
> against the same credentials.  After the server timed out authorization,
> it could challenge a client against a different realm over the same
> PATH_INFO namespace (the realm perhaps corresponding to
> $domain.$timestamp) and force verifiable reauthentication. 
> Only the most reckless clients would try to guess that a set of distinct
> realms over the same namespace were "similar"  enough to reuse
> credentials.  Sloppy clients could make a much safer bet and reuse
> credentials for the same realm, same namespace case, effectively ignoring
> the proposed message.  I experimented with this a few years ago with
> Mosaic and Netscape (v <= 2.0) and I recall that they both stacked up
> realms and would send as many authorization responses as realms
> authorized. 
> The implementation costs on the server side would be only slightly more
> expensive than keeping enough state to know when to send a

The problem with this suggestion is that it makes an already confusing
and user unfriendly prompt even less obvious to the end user. Since 
the realm is the only clue the server can give to the user as to what
they are being asked to login to, I dislike any scheme which requires
arbitrarily distinguished realm values.

Dave Morris
Received on Tuesday, 25 November 1997 08:55:27 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:21 UTC