Re: Draft 01 of HTTP/1.0

At 1:09 AM 12/21/94, Brian Behlendorf wrote:
>If, instead of a string, we specified exactly where (both by hostname and
>by path) the password authentication is valid, there's be no ambiguity as
>to when the browser automatically resends the authentication information.

This is predicated on the assumption that all data being served is coming
from a traditional file system and that's what the path represents. It
would be very tedious to have to specify authentication rules for every
record in a database, for example. A specific server (or client)
implementation of HOW authentication realms are defined doesn't seem
germain to the HTTP/1.0 discussion. What a particular string in a httpd
config file means is up to a specific server implementation to determine,
not the HTTP/1.0 standard.

The current standard is clear about when to send an authentication header.
It's sent in response to an authentication request from a server. In an
entirely separate transaction, the server receives the second request and
validates whether or not the authentication info is valid. This allows the
client to send authentication info whenever the CLIENT feels it is
required. I'm not sure I understand why you care if a client sends improper
authentication info for a realm it has wandered into. It is equivalent to
sending no information at all, which is acceptable.

How the server is mapping configuration info for security (a "string") to
the actual authentication of data it serves is completely transparent to
the client. Even a scheme as simple as having the client always send the
last valid authentication info to the same server until it fails for a
link, then switching to the new info supplied by the user, works just fine.
Whether a server interprets a "AuthName" command as a string to match, an
exact path, a complete URL, or something entirely different is something
for a NCSA httpd server to decide. All the client needs to know is that the
authentication info it supplied is invalid. Don't forget that httpd is only
one of MANY server implementations, and they don't all define
authentication realms the same way, or with the same definition of what
constitutes a realm.

Your assumption that "realms" have some meaning in the context of the
HTTP/1.0 protocol is probably forcing the standard to do something that is
properly the domain of client and server implementations of security and
not their HTTP implementation. Namely, define what constitutes a security
realm for all client and server implementations. Given the infinite variety
and structure of data that can be served via HTTP, it seems inappropriate
to try to accomodate a specific interpretation of what constitutes a
"realm" into the standard.

Current clients make a generic assumption based on the hierarchy present in
a URL (and this does NOT mean they are assuming that these are
subdirectories in a file system) regarding when to send the last used
authentication info. This is all they can safely do, given the requirement
that the interpretation of a path portion of a URL is the sole domain of a
server. Clients that try to interpret a URL as a series of Unix
subdirectories ending in a file name and then do something cute with that
info won't last very long with the servers coming down the pipe.

The same is true for realm interpretations. As far as the client is
concerned, the realm info present in the server's authentication reply
serves two purposes. The first is as a prompt for the client user. The
second is as a way to easily look up authentication already entered that
may be maintained internally to the client at runtime.

>> Was this section written to reflect current practice, or was it written to
>> be better than current practice?
>
>The above clearly does not describe current practice, but is definitely
>something I'd like to see in 1.1.

No, it doesn't reflect current practice. It does reflect an opinion of a
future *implementation*. There's nothing wrong with discussing future
implementation possibilities in the context of the HTTP standard. But,
trying to capture implementation specific details of HTTP clients and
servers in a protocol standard is different than trying to capture the
semantics of the authentication exchange and it shouldn't be done.

To sum up. Clients cannot know the authentication info they send (or fail
to send) is inappropriate for the realm they are accessing until they try.
So, clients make some smart assumptions about when to send authentication
info to avoid hassling users with password requests for every URL. What
constitutes a "realm" is an implementation-specific detail of the SERVER
and the client cannot know how the server has partitioned its data with
respect to security. This is just good practice when trying to develop
secure systems. Clients are only told that their access attempt failed. Not
why, or what the actual structure on the server looks like. Just that they
failed. Given this, it seems impossible to define ahead of time WHEN a
client should send authentication info. I think the current practice, and
current HTTP/1.0 standard accomodates these requirements just fine.

-----------------------------------------------------------------------
Chuck Shotton
cshotton@oac.hsc.uth.tmc.edu                           "I am NOT here."

Received on Wednesday, 21 December 1994 04:54:28 UTC