Re: Draft 01 of HTTP/1.0

>> 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.
>
>If browsers actually did this, almost every file reteival on our site
>would require two separate connections.

Browsers work this way now and it only requires n+1 connections for n
requests to the same realm, with the extra connection being the first one
that failed and required that the server respond with a "Not Authorized."
Are you sure you're clear on how authentication handshaking currently
works? Maybe I wasn't typing clearly. It WAS early in the morning!

>> 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.
>
>But then what happens?

The server tells the client that it needs to authenticate for the current
realm. If the client doesn't have a current password for the realm, it must
prompt the user. This is what all clients do now. Do you feel this needs to
change? If so, how and why? This is as simple a handshake as can be defined
and I cannot see how you can make it any more efficient.

Client says, "Let me have this file"
Server says, "No, give me a valid password first."
Client says, "User, gimme a password"
Client says, "Server, gimme the file, here's the password."
Server says, "OK"
  -or-
Server says, "No, give me a password first.", and the process repeats.

OR, the client already has a password for what it thinks is the current
realm. Then,

Client says, "Let me have this file, here's a password"
Server says, "OK"
  -or-
Server says, "No, give me a valid password first.", and the process repeats
as in the first example.


>Does the browser 1) retry a previous password, or
>2) prompt the user for another password?  If it's 1), then we need some
>heuristic for determining which previous password to use

That's what the REALM is for.

>, and sending the
>wrong password would be a security risk.

Sending ANY password is a security risk. I see what you are getting at,
however. It's only a REAL risk if the realm spans multiple servers. In
practical, real-world terms, I can only see realms that span multiple
servers as being huge, administrative nightmares. Why not just implement a
Kerberized (or YP) server and let all the distributed servers share a
password file?

> A simple string as the realm key is dangerous

You are obviously attaching more importance to the realm than I am. My
interpretation is that a realm is simply a way to subdivide the content
provided by a single server (or common content across multiple servers). It
gives a user a hint about which password to type in, and it tells a client
which cached password it should try. As far as clients are concerned, it's
simply a key for a table look-up or a prompt string for the user. Is there
more to it than that?

> - the only secure way is "okay, you've connected to me,
>now you may use this same password here, here, and here".  2) is
>unacceptible for those who want to create a seamless authentication space.

What exactly is "seamless authentication space", and from whose perspective
is it seamless? The user, the client, or the server?

>> 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.
>
>But it's not, in current practice.  Try this.  Telnet to www.hotwired.com
>port 80, and issue the command "GET /Login/ HTTP/1.0\n\n".  You'll see:
>
>WWW-Authenticate: Basic realm="HotWired!"
>When clients get that the first time, they usually ask the user "enter
>your name and password for "HotWired!"".  So, I don't see how you can say
>it's transparent.
>

To WWW client software, it is a meaningless string of characters to be
compared with other meaningless strings or displayed to a user. It's
semantic meaning to a WWW server is invisible (transparent) to the client.
The fact that a user can see it with a telnet session is irrelevant. It
reveals nothing about the security of the server, or what that string
relates to on a server.

>> 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.
>
>That's not current practice.  I can set up two different realms on my
>server here, set up links between them, and users should only ever have
>to type their passwords twice to bounce between them.

You are confusing the behavior of a specific server implementation, Unix
file system specifics, and the logical concept of "realms" in the HTTP
standard. It's not the HTTP standard's fault if httpd is not implemented
consistently.

>  The client
>distinguishes between them by the realm string.  That just happens to be
>the way things are defined now.

What else is the realm string for, as far as the client is concerned? I
feel like I must be missing something obvious here, because it appears very
simple.

>> 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.
>
>If you're saying turn it over to the HTTP-security working group, fine.
>If you're saying it doesn't belong in HTTP, I disagree.

I'm saying that the semantics of what a realm string means to a server is
implementation specific, just like what the path portion of a URL means to
a server is implementation specific. You are saying (as best I can tell)
that the implementation details of realms should become part of the HTTP
standard. I'm saying that what a server maps realm "strings" to is none of
the client's business, is semantically meaningless to the client, and
therefore is no more part of the HTTP standard than how to interpret the
path portion of URLs is.

>...
>> 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.
>
>And for HTTP/1.1 we're trying to make the process more intelligent, since
>the heuristic for that "look up" and retry step is too vague right now.

Please elaborate on what is vague about them. It seems relatively
straightforward to implement both clients and servers from the current
standard. It wasn't hard when I tried it, and wasn't at all ambiguous,
unless you mean that the term "realm" is imprecise with respect to its
mapping to one/many servers.

>We're defining current practice, which is clearly different from what
>Chuck thinks is the best way to do this.

I must have been drunk when I was typing this morning. What I thought I
typed was a very clear description of current practice, in response to
something I saw as an inappropriate direction for a future standard. I am
fairly certain that I understand what current practice is. I know I
understand the challenge/response exchange that happens between clients and
servers, because I've built it more than once.

> Current practice is what allows
>our server to only require the user to enter their password once for
>almost all actions, and whether Chuck believes it or not clients do use
>the realm string to differentiate between authentication areas.

I said this repeatedly in my previous post. I agree 100% that clients use
the realm string to determine what password to send. It's just that it has
no meaning to the client in terms of how the server implements the division
of data amongst realms. It is simply a key into a table of passwords that
have previously been entered by the user. Was this confusing in my earlier
letter?

>  Future
>versions of the spec should expand upon this instead of deprecating it -
>I think we all agree that requiring the user to type the same name and
>password for every access to the same authentication space is a bad idea,
>yet being "promiscuous" in throwing names and passwords about is also
>undesireable.

I am unaware of any current client that repeatedly asks users for passwords
when accessing files in the same authentication space. However, I disagree
that throwing bad passwords at the SAME server is much of a security risk.
If realms span servers, yes, I agree. But in CURRENT PRACTICE, this isn't
the case.

[snip]
>*       Note: The realm may not span more than one hostname.

Agreed.

>
>Okay, I think that defines current practice better than what was there.
>It doesn't make any suggestions about when clients should try and guess
>that a given URL will need authentication ahead of time, but it also
>preserves the enter-password-just-once mechanism.  Browser writers should
>write their code carefully to avoid a retry loop like the one Netscape had
>in one of their early betas.
>
>Does this solve it?

Looks fine to me. (Were we agreeing all along? I hate it when that happens!)

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

Received on Wednesday, 21 December 1994 16:55:52 UTC