Subject: Interop issue: how can clients force authentication?

From: Ilya Kirnos <[email-masked]>
Date: Mon, 16 Sep 2002 16:35:44 -0700

Clients currently have no reliable means of forcing the server to
authenticate them (they can try to preemptively send credentials, but
this works only for basic auth, not for digest).  This can lead to
situations where the client finds out that it was required to
authenticate too late and only after doing lots of work, such as when
putting a large file only to get a 401 back at the end of the transfer.

To address this problem, it was proposed to add a Force-Authenticate
OPTIONS header which would force a compliant server to issue an
authentication challenge to the client, a la:

Force-Authenticate = "Force-Authenticate" ":" ("T" | "F")

The Force-Authenticate header would be used with the OPTIONS method to
specify that the client wants to be
challenged for authentication credentials to the resource identified by
the Request-URI.  A value of "T"
indicates that a compliant DAV server MUST respond with a 401
Unauthorized status code (see
[RFC2068], section 10.4.2) if the resource identified by the Request-URI
is protected, i.e., there exists a  DAV method (read,  write, or
otherwise) that may result in a 401 response for this Request-URI.  Put
another way, if the server does *not* respond with a 401, it is
guaranteeing to the client that any DAV operation it may want to apply
to the Request-URI will not return a 401.

This means that the client has a way of finding out beforehand whether
it needs credentials to perform an operation, and the server has the
option of saying "no credentials necessary" if it is sure that in fact
no credentials are necessary (for example, servers that have no access
control at all, if any such exist).  I thought it was important to keep
this option open, although I suspect that most servers would always want
to challenge since they couldn't really be sure.

Comments?

-ilya

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 16 Sep 2002 17:36:40 -0700

Authorization is granted/denied based on the method of the request.
There might even be different challenges per method.  In other words,
this idea won't work for HTTP.

The original idea of OPTIONS was that, if the client wished to test the
options for a specific request, then it would include that request's
request-line and headers in the body of the OPTIONS request.  The server
would then look at the body to determine what the options would be and
report that back to the client.  However, since the WG did not want to
define the format of such a response, the feature got dropped.

The alternative was to simply issue the request with Expect: 100-continue.

I don't know if that is sufficient for your problem, but I do know that
using a T/F request header field on OPTIONS is not.  A minimum would be
to list the methods in that field instead.  I also suggest finding a
less verbose field name.

....Roy

---

From: Stefan Eissing <[email-masked]>
Date: Tue, 17 Sep 2002 11:20:55 +0200

Ilya,

> putting a large file only to get a 401 back at the end of the transfer.

A bad user experience, agreed.

However it would be more elegant if the client could send
the request without the server executing it and checking thus
the authentication for the specific method call. That would also
give any intermediates, like proxies, a chance to determine if
they need any authorization.

My idea would be to use the IF header for this purpose. A client
can send a request with an invalid lock token in the IF header.
The server, being DAV-compliant, will never execute the request.

Now this solution depends on the order of authentication vs. IF
header check. Therefore my proposal depends on

- does every known server check authentication before lock tokens?
- could 2518bis say something like: "All user authentication SHOULD
   take place before other request headers like IF are processed."?

//Stefan

---

From: Ilya Kirnos <[email-masked]>
Date: Tue, 17 Sep 2002 12:17:34 -0700

> this idea won't work for HTTP.

right, i was hoping to finesse the issue by saying that if any method needed
authentication, the server should challenge.  however, if challenges differ
for different methods, then obviously this won't work.

> to list the methods in that field instead.  I also suggest finding a

sounds like an idea to me, but if in fact it is common for servers to have
different challenges for different methods, then we have a whole new set of
problems.  would the order of the list of methods determine which challenge is
returned?  do clients have to issue this OPTIONS request for each new
operation they try to do (i.e., i sent a list that had PUT first for my last
operation, but now i'm about to do a PROPPATCH -- do i have to send a new list
that has PROPPATCH first?).

perhaps in its response the server could return which methods the challenge
would cover if successfully answered.  so the sequence would look like:

request:

OPTIONS /blah HTTP/1.1
Host: blah
Force-Authenticate: PUT, PROPPATCH, etc...

response:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: ....
Authenticate-Methods: PUT, PROPPATCH, etc...

and now the client can send a PUT, PROPPATCH, or etc... if it has the right
credential for the challenge.

From my experience with HTTP server configurations, most challenges tend to
cover either all write methods or none (at least if the configuration is done
properly), but this would leave the door open for those that do something
different.

-ilya

---

From: Ilya Kirnos <[email-masked]>
Date: Tue, 17 Sep 2002 12:20:50 -0700

>    take place before other request headers like IF are processed."?

i'm not sure this would work, since DAV servers don't even have to support
locking to be compliant.

-ilya

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 17 Sep 2002 21:46:52 +0200

Some thoughts....

1) Do we really have an interop issue at all? From what I hear, it's
considered a problem that when submitting a large PUT, you may not hear
about the 401 before you have sent the whole request. So that's "just" a
performance issue (actually, a known one).

2) If there *would be* consensus that we need this kind of
you-wikll-have-to-authenticate-for-PUT signalling, I'd propose to make this
a live property. Just issue a PROPFIND on it in case you want to know. No
new request header (-> HTTP header namespace unaffected), no new OPTIONS
semantics, no new compliance class.

3) Finally -- we should be looking for *existing* ways to solve this problem
for RFC2518bis. For instance:

3a) Try a PROPPATCH first -- if you can't change the metadata, it's likely
that you won't be able to change the content either.

3b) Try a zero-length PUT first.

3c) Try a LOCK first.

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

...and so on.

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Ilya Kirnos
> Sent: Tuesday, September 17, 2002 9:18 PM
> To: Roy T. Fielding
> Cc: Webdav WG
> Subject: Re: Interop issue: how can clients force authentication?
>
>
>
>
> "Roy T. Fielding" wrote:
>

---

From: Ilya Kirnos <[email-masked]>
Date: Tue, 17 Sep 2002 15:24:29 -0700

> performance issue (actually, a known one).

that's just one example, although a pretty severe one.  in general, i believe
it's a must that clients have a way to authenticate themselves when they wish.

> semantics, no new compliance class.

we discussed something like this in the WG meeting.  an OPTIONS header seemed
like a cleaner approach to me.

> for RFC2518bis. For instance:

we also discussed this in the meeting and rejected in turn each method that came
up.   none of them seemed reliable/clean enough, but i'm willing to hear
suggestions.  (see my comments below)

> that you won't be able to change the content either.

likely, but not certain.  and now you've possibly changed the metadata.

> 3b) Try a zero-length PUT first.

probably would work, but leaves a file behind (remember, i just wanted to
authenticate, not necessarily upload anything.)

> 3c) Try a LOCK first.

servers don't have to support locking.

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

maybe.  what's known to fail?

-ilya

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 18 Sep 2002 01:38:06 +0200

> Sent: Wednesday, September 18, 2002 12:24 AM
> To: Julian Reschke
> Cc: Webdav WG

I think at this point you should make clear what problem you want to solve.

From what I hear now, you want to authenticate, but not for a specific
method call on a specific resource. What is this supposed to *mean*? What
principals are known may depend on the request URI. Whether (and as who)
you need to authenticate to apply a certain method to a resource depends on
the resource *and* the method.

In general, the answer -- you'lll have to try.

So please restate what was considered to be an actual interop problem.

> like a cleaner approach to me.

Cleaner in what way? I have listed a few reasons not to use OPTIONS (I even
forgot to mention that it'll save you a roundtrip in case you have to do a
PROPFIND first anyway).

> authenticate, not necessarily upload anything.)

Right. Lesson learned -- it doesn't make sense to try to come up for
workarounds until the problem is clearly stated.

> servers don't have to support locking.

Yes. Servers don't have to support authentication either.

> maybe.  what's known to fail?

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

---

From: "Eric Sedlar" <[email-masked]>
Date: Tue, 17 Sep 2002 17:26:23 -0700

What we do is to send the authentication challenge for any method other than
GET or HEAD or OPTIONS.  I recall from the interop event that a number of
other servers did the same thing.

Most clients issue a LOCK or PROPFIND first and avoid this problem, but
perhaps this could be spelled out in the spec.

--Eric

----- Original Message -----
From: "Julian Reschke" <[email-masked]>
To: "Ilya Kirnos" <[email-masked]>; "Webdav WG"
<[email-masked]>
Sent: Tuesday, September 17, 2002 12:46 PM
Subject: RE: Interop issue: how can clients force authentication?

> ..and so on.

---

From: Ilya Kirnos <[email-masked]>
Date: Tue, 17 Sep 2002 18:38:56 -0700

> In general, the answer -- you'lll have to try.

okay.  this answer is currently not sufficient, for example in the case of a
large PUT.  whether it's an interop or a performance problem, i believe it's
something that needs to be addressed.  if there is something already in the spec
that solves the problem, i would be happy to use it.

> So please restate what was considered to be an actual interop problem.

clients need a way to authenticate themselves before performing a potentially
expensive operation.  the only such operation that has come up in
interoperability testing thus far is a large PUT, but it is conceivable that
clients will need this for other operations as well.

> forgot to mention that it'll save you a roundtrip in case you have to do a

it was largely based on intuition.  i guess i'd have to see the exact proposal
for this new property to tell you exactly, but if it turns out to be
satisfactory, i'd be happy to use it.

> Yes. Servers don't have to support authentication either.

i don't see your point.  these issues are orthogonal: a server may want support
authentication but not locking, so i'd like to divorce authentication from
locking if at all possible.

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

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

-ilya

---

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 17 Sep 2002 19:10:42 -0700

> this answer is currently not sufficient, for example in the case of a
> large PUT.  whether it's an interop or a performance problem, i
believe
> it's
> something that needs to be addressed.  if there is something already
in
> the spec

There are other problems. In a collection, an unauthenticated user may
have sufficient privilege to see some (publicly visible) resources, but
not others. A PROPFIND to this collection would therefore not reveal all
child resources.  Also, a PROPFIND might return only some publicly
visible properties, not others which might be considered slightly
"sensitive" (like quota?) and not revealed to unauthenticated users.

A PUT to a new resource may be accepted even from anonymous users, but
if the user is unauthenticated, the new resource cannot be initialized
in the same way.  For example, the owner may not set to the user who
created it, or the new resource may go to the collection owner for
approval.

There may be other methods which an unauthenticated user can receive a
success response, but which would work even better if the user were
authenticated.

Can anybody come up with other clever ways for the client to try to
authenticate?  E.g. is it possible for a client to send a reasonable
Digest authentication header with its first request (probably a
PROPFIND, but whatever method happens to be first), and if the
information therein (e.g. realm) is bad, the server responds with the
WWW-Authenticate header with the correct prompting?  That doesn't quite
solve Ilya's performance problem, but perhaps the HTTP 1.1. Continue
mechanism would solve that specific issue.

Lisa

---

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

Am Mittwoch den, 18. September 2002, um 04:10, schrieb Lisa Dusseault:

> [...]

As someone on the list already pointed out, the client cannot
guess a valid Digest Authentication header. It's one main strength
of digest authentication that the client is not able to do this.
Otherwise an attacker might be able to use a replay attack.

I'm not sure however what a server will do upon seeing a nonsense
Authenticate header from the client. Will it always send a challenge
back? (Unfortunately we cannot make this a requirement in WebDAV
since this belongs in another RFC).

//Stefan

---

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

Am Mittwoch den, 18. September 2002, um 03:38, schrieb Ilya Kirnos:

> believe it's

Well, as someone (Roy?) mentioned, the Expect header in RFC 2616 servs
that pupose.

//Stefan

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 18 Sep 2002 10:37:05 +0200

Lisa,

I think this...:

> ...
> ...

makes it clear that we need some more time to precisely describe what the
actual problem is. It's an interesting problem, and I suppose it needs to be
discussed in relation to the ACL spec. However I don't think there's any
reason to declare it an interop problem just to rush a quick workaround into
RFC2518bis.

---

From: "Eric Sedlar" <[email-masked]>
Date: Wed, 18 Sep 2002 11:09:56 -0700

Authentication is explicitly out of the scope of the ACL spec.
Authentication is assumed to be handled at the HTTP level, and there are
already plenty of schemes for this.

--Eric

----- Original Message -----
From: "Julian Reschke" <[email-masked]>
To: "Lisa Dusseault" <[email-masked]>; "'Ilya Kirnos'"
<[email-masked]>
Cc: "'Webdav WG'" <[email-masked]>
Sent: Wednesday, September 18, 2002 1:37 AM
Subject: RE: Interop issue: how can clients force authentication?

..