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

Re: Basic Authentication behavior

From: Foteos Macrides <MACRIDES@sci.wfbr.edu>
Date: Mon, 08 Sep 1997 14:02:10 -0500 (EST)
To: lawrence@agranat.com
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <01INEHOG41YA000DWQ@SCI.WFBR.EDU>
Scott Lawrence <lawrence@agranat.com> wrote:
>>>>>> Scott Lawrence <lawrence@agranat.com> wrote:
>
>SDL> It has been our observation that most browsers handle multiple
>SDL> realms in the same server poorly; once they have established a set
>SDL> of credentials for a given server, they will always send that set
>SDL> until it fails.  If the failure presents a new realm, most browsers
>SDL> forget the credentials for the first realm.
>
>>>>>> "FM" == Foteos Macrides <MACRIDES@SCI.WFBR.EDU> writes:
>
>FM> I'm a bit concerned that the logic you (and John, and Jim)
>FM> are bringing to this issue, and reflected in your "event" test, may
>FM> be on the verge of creating a post hoc logic versus current practice
>FM> pickle, homologous to that for redirection.
>
>FM> It is classic libwww behavior to guess a template for a Basic
>FM> realm, and that is current practice for software which has it as a
>FM> heritage.
>
>  I evidently didn't make clear what I was objecting to; I don't have
>  any problem with the behaviour you describe for libwww in terms of
>  guessing the protection space; in fact, I don't have any problem
>  with the client sending the realm credentials on any request to a
>  new URL in the same server until they are refused (regardless of
>  hierarchy - I prefer not to get too hung up on the URL space as a
>  tree).

	And evidently I didn't make clear that you are not taking into
account the "template" logic used for that behavior, and thus *do*
have a problem with it, as well as a potentially avoidable security
problem, or at least one which should be explained adequately in the
HTTP/1.1 specs.


>  Here is the case I have a problem with (removing headers not
>  relevant to this discussion):
>
>  First request - no credentials supplied:
>
>    > GET http://server/demo.html HTTP/1.1
>
>    < HTTP/1.1 401 Unauthorized
>    < WWW-Authenticate: Basic realm="Demonstration"

	Let's stick with what you actually have in the test via:
	
	EmWeb Authentication Interoperability Tests
	http://digest-test.agranat.com/test_list.html


	The URL which returns a Basic challange is:
	
	http://digest-test.agranat.com/2887613/basic_multiple/step1.html

via the header:

	WWW-Authenticate: Basic realm="basic_m1"

so my "libwww heritage" UA associates template "/2887613/basic_multiple/*"
with Basic realm "basic_m1".


>  Second request, same URL with credentials:
>
>    > GET http://server/demo.html HTTP/1.1
>    > Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
>
>    < HTTP/1.1 200 OK

	Because it is the same URL (but could have been one at that
level or deeper in the symbolic path hierarchy), the template for that
host[:port] with scheme "http" matches it, and so my "libwww heritage"
UA includes an Authorization request header with the BASE64 encoded
username and password for Basic realm "basic_m1".


>  Third request - a new URL, client sends same credentials (same
>  server, so I think this is ok, some would say they shouldn't be sent
>  unless the path had a common root - not my current point).
				       ????????????????????
				       
	But my point, from the perspective that IETF WGs should seek
to generate specifications which yield maximum possible interoperability,
and include adequately detailed "implementation notes" where there are
problems, is that you are not adequately taking into account the use of
templates by a substantial number of deployed UAs.


>  Server returns a new realm value:
>
>    > GET http://server/other.html HTTP/1.1
>    > Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
>
>    < HTTP/1.1 401 Unauthorized
>    < WWW-Authenticate: Basic realm="Different"

	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, to avoid the seemingly pointless network overhead, and perhaps
per packet $costs, of getting back a 401 and having to send the request
again.


>  Fourth request - establish good credentials for the 'Different'
>  realm:
>
>    > GET http://server/other.html HTTP/1.1
>    > Authorization: Basic QWxhZGRpbjpvcGXXXXXXXQ==
>
>    < HTTP/1.1 200 OK
>
>  Now the user returns to the original URL: (http://server/demo.html),
>  which the client learned in the first request was in realm
>  'Demonstration'.  Clients we have tested will have forgotten this
>  and send the credentials for realm 'Different', and when they get
>  the 401 response will reprompt the user for the 'Demonstration'
>  realm again.

	Your test returned a 401 with response (entity ?) header:

	WWW-Authenticate: Basic realm="basic_m2"

The URL was:

	 http://digest-test.agranat.com/171503568/basic_multiple/step2.html
	 
which my "libwww heritage" UA still treats as having template
"/171503568/basic_multiple/*".  So it "updates" its structures to
associate that template with realm "basic_m2" instead of "basic_m1",
which from your perspective is "forgetting" (a "bug" ?).  However,
HTTP is a Basic-ally (pun :) stateless protocol, and no cookies or
other documented (more or less :) "tricks" to add some degree of
State Management were used, i.e., only the "libwww heritage trick"
of associating templates with Basic realms.  So as far as my
"libwww heritage" UA is concerned, you might well have reconfigured
your server between those two request with the same implied template
but a new, different Basic realm, and the UA is simply taking the
new information into account, and correspondingly "correcting" its
behavior, based on a "sorta State Management trick" to minimized
network overhead and possible per packet $costs.

	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.


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.
>
>A sentence in the spec to the effect that "credential guessing"
>is common current practice might be useful.  It might affect how
>suspicious one should be of failed authentication attempts.

	John does not spell out that other "common current practice".
I don't know if those UAs pass Scott's test.  I suspect (based on
past experience) that John's suggestion to say no more than that
"credential guessing is common current practice" in the HTTP/1.1
spec will be considered "wise".  And so I still am concerned that a
homolog of the 301/302 interoperability pickle is in the making,
might have been avoided, but won't be.

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
Received on Monday, 8 September 1997 11:06:51 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:00 EDT