Subject: RE: Interop issue: how can clients force authentication?

From: "Clemm, Geoff" <[email-masked]>
Date: Tue, 17 Sep 2002 22:57:15 -0400

From: Ilya Kirnos [mailto:[email-masked]]

   Julian Reschke wrote:

   > Try a PUT with known-to-fail If header first (-> Stefan's
   > proposal).

I agree that Stefan's proposal is the most appealing.

   maybe.  what's known to fail?

   > An invalid lock token, an invalid ETag, ...

Actually, I'd suggest a simple logical contradition, i.e.:

If: ("A" Not "A")

   again, i'd like to stay away from a dependency on locking if
   possible, and etags support isn't required if i recall correctly.

etag support isn't required, and locking support isn't required,
but support for the If header is required.

So I suggest we check whether any server which does the If check
before it does an authentication check.  It certainly shouldn't,
since the success or failure of the If check tells you something
about the resource which you probably shouldn't know if you are
not authenticated.

I would have no objection to adding a statement to 2518bis that
states that a server SHOULD do authentication checks before any
If checks.

Cheers,
Geoff

---

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 17 Sep 2002 23:14:29 -0700

> Actually, I'd suggest a simple logical contradition, i.e.:
...
> but support for the If header is required.

I'm not so sure a server will implement the If header if it doesn't
implement locking.  I'd agree it's required, but it may not be there.
And there's certainly no requirement now that servers do authentication
checks when they do If checks.  That's not required by RFC2518 -- e.g.
if the If test fails because it's logically impossible, then why bother
authenticating?

This seems like trying to fit a round peg in a square hole.

---

From: Stefan Eissing <[email-masked]>
Date: Wed, 18 Sep 2002 10:23:29 +0200

Am Mittwoch den, 18. September 2002, um 08:14, schrieb Lisa Dusseault:

> ....

First, I bet that 100% of all non-broken, existing servers do
authentication checks before looking at the request resource and
its properities like locks. It's the sensible thing to do, as a
user might not even have read permission on the resource. So
one probably should prevent him/her from finding out about the lock
status of the resource.

Second, there is no requirement at the moment. But then, we are
talking about new requirements for servers. The orginal proposal
wants to introduce a new HTTP header, if I remember correctly.
If checking authentication first is the sensible thing to do
for security reasons, then 2518 bis should say so.

If you compare the two existing proposal, you'd find that
the invalid IF Header will work against all current servers
which:
1) check IF header (that will be all servers with locking)
2) check authentication before everything else

whereas the new Enforce Header will only work against
future servers which implement the feature.

It would therefore be interesting to hear what client implementors
think about the two proposals.

> This seems like trying to fit a round peg in a square hole.

Engineering answer: that is no problem if the diameter is
equal or less than the side of the square.

//Stefan

---

From: "Lisa Dusseault" <[email-masked]>
Date: Wed, 18 Sep 2002 09:29:28 -0700

> one probably should prevent him/her from finding out about the lock

No, and why should they?  There's nothing in RFC2518 that requires
servers to support locks only for authenticated users.  If a resource is
publicly writable, there may be nothing to prevent unauthenticated users
from taking out locks and using lock tokens.  Recall that the If header
can also be used with ETags, which are not at all associated with how a
user is authenticated.

Also, recall that in order to "do authentication checks", the server
must respond to the client with a 401 with the WWW-Authenticate header,
then the client must make another request.  

Of course if the client sent its authentication information on the first
request, the server is likely to check it.  However, the client can't
even send its authentication information if it doesn't yet know whether
the server supports digest or basic, or what realm, nonce, etc.  That's
why Ilya wants to be able to ask the server to reply with a
WWW-Authenticate header.  

Lisa