Re: Basic Authentication behavior

John Franks <john@math.nwu.edu> wrote:
>On Mon, 8 Sep 1997, Foteos Macrides wrote:
>> 
>> 	The actual URL in your test suite is:
>> 
>> 	http://digest-test.agranat.com/171503568/basic_multiple/step2.html
>> 
>> which matches my "libwww heritage" UA's template, "/2887613/basic_multiple/*"
>> for Basic realm "basic_m1", so it sends the seemingly appropriate (but from
>> your perspective, inappropriate) WWW-Authenticate request header for that
>> Basic realm,[...]
>
>Is this a typo?  /171503568 doesn't match /2887613.  I don't know if
>any browsers would try the same credentials for these two quite
>different URL's.  But this is an issue Scott's test doesn't cover.

	Fortunately, the UA uses computer chips, not degenerating neurons,
will "see" what's actually there, not what was "intended" to be there, and
will not make a mistake about the "templates". :)


>> [...] That particular implied/inferred template "trick" carries
>> with it the "security risk" (assume https URLs so you don't miss
>> the point simply because it's Basic Access Authentication) that
>> providers not aware of it might assign two resources intended to
>> be in different Basic realms to symbolic URL paths which yield the
>> same implied/inferred template, as you are doing in your test, and
>> those two resources are managed by different "providers" at that
>> host, who should not be getting each others' authentication info.
> 
>I think it is always risky to have two authentication realms on the
>same server managed by different "providers" as one could simply claim
>to be in the realm of the other.  The spec says:
>
>  "The realm value (case-sensitive), in combination with the canonical
>  root URL (see section 5.1.2) of the server being accessed, defines the
>  protection space."
>
>and I interpret this to mean the realm + hostname part of the URL
>determine the protection space.  Even if the template behavior you
>describe is common, some browsers might not provide it.

	Neither the HTTP/1.0 RFC, nor HTTP/1.1 RFC, nor revisions
through draft -08, say anything about the path of the request
associated with Basic Access Authentication, i.e, do not correspond
to what Ari actually had implemented and has explained in a recent
message.   With Ari's implementation, there would be no problem
offering different providers protected realms on the same server,
in that they would also be assigned different limbs of a symbolic
path space:

	http://the.host.com/provider1/*
	http://the.host.com/provider2/*

(where "provider1" and "provider2" would acutally be strings with
semantic connotations about the two providers, at least for the
ASCII-speaking Webizens, and could be mapped to their respective
file system path limbs).  If someone tried to spoof that, they'd
simply cause provider1 or provider2 to get a bad request, but
with the appropriate authentication based on the two, distinguishable
templates for the symbolic URL paths.  The WebMaster for that site,
of course, would have to approve both providers' realm values, before
adding them to the configuration, making sure those don't conflict.
The same realm value for a different http[s] host[:port] would not
be a problem, either, because all templates are specific with respect
to those URL fields.


>> John Franks <john@math.nwu.edu> wrote:
>> >I believe that there is common current practice which is different from
>> >this, but I think there is no need to discuss the algorithm the client
>> >uses to pick the template as that is an implementation decision.
>> >
>> 	John does not spell out that other "common current practice".
>> I don't know if those UAs pass Scott's test.  
>
>I believe that current Netscape browsers after successfully supplying
>credentials for http://host/foo/index.html will use a "template"
>more like "/foo*/*".  In particular they will send the same 
>credentials for a request to http://host/foobar/index.html.

	I presume UAs which truthfully send the "Mozilla" product token
in their User-Agent header would use "/*" as the template for a path
of "/foo", and "/foo/*" for a path of "/foo/" (and there can be only
one wildcard token in the template, so it definitely would not be
"/foo*/*").  If the UA sent   http[s]://host[:port]/foo   and that
were mapped to a directory, the UA should get back redirection for
http[s]://host:[:port]/foo/   and the correct template would be
established on subsequent return of a challenge.

	Note also, based on Ari's reply about proxy authentication
as originally implemented by the Netscape servers, that though a
realm=value is required with a proxy authentication challenge, the
actual value is "irrelevant", because the template is "*".  If the
proxy returned a challenge with a new value, a configuration change
for that proxy should be inferred by the UA, and the realm value for
that proxy's (server specific) "*" template simply "updated" (i.e.,
seemingly "forgotten", but not due to degenerating neurons :).

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

Received on Monday, 8 September 1997 14:58:32 UTC