Subject: Re: Recognizing a WebDAV enabled client

From: Julian Reschke <[email-masked]>
Date: Sat, 01 Jul 2006 09:48:31 +0200

Michael Wechner schrieb:
>> Well, so far there are no different versions, so the server doesn't 
>> need to know.
> 
> but I guess there will be someday ;-)

I think that if this happens the working group made a grave mistake.

>> If a spec revision or an extension should introduce a change where the 
>> server does need to know, the client *then* can send the DAV request 
>> header, as defined in 
>> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-15.html#dav-header>. 
>>
> 
> ok. Do you know by any chance why BIND in particular is using this header?

Sure. It's needed to that a client can communicate to the server that it 
knows about the status code 208, which a server may use to collapse 
repeating information in a PROPFIND response (see 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-14.html#rfc.section.7.1>).

>>> Also the server might want to deliver a different response, e.g. if 
>>> the GET request is being issued from a regular Web-Browser,
>>> then the server might respond with a common (X)HTML, but if the GET 
>>> request is being issued from Cadaver or OpenOffice then
>>> the server might respond with an ODT file.
>>
>> Well, that's what the HTTP "Accept" request header is for.
> 
> right, this might makes sense for formats. But I would argue with 
> another usecase, namely Custom Authentication
> instead of HTTP authentication (BASIC or DIGEST).

"Custom" authentication basically is authentication that bypasses 
RFC2617. I know it's common, but it's not covered by IETF specs right 
now. I agree that this is a problem that needs to be worked on, but I 
fail to see how this is a WebDAV problem.

In particular, for WebDAV it's quite simple: the server should always do 
RFC2617-based authentication if the request method is OPTIONS or PROPFIND.

Things get harder with non-browser based protocols such as AtomPut that 
do *not* use specific verbs.

> Let's assume a resource is protected and a server would like to offer 
> custom authentication, e.g. it would send
> a HTML to a regular browser and some WebDAV specific XML to a WebDAV 
> enabled client, whereas I haven't digged into
> WebDAV far enough how something like this could be handled by the WebDAV 
> spec.

The WebDAV spec doesn't care, and doesn't need to.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sat, 01 Jul 2006 09:52:03 +0200

Michael Wechner schrieb:

>> Are there any specific incompatibility issues you are aware of ?
> no, but I could imagine there will be if there will be more than one 
> version of WebDAV and so I think it should
> me mandatory for clients to send the DAV header.

Sorry, that doesn't make any sense.

In RFC2518, the DAV header is defined as a response header. Usage as 
request header is undefined.

In RFC2518bis, the spec allows other extensions to use the DAV header as 
a request header. But even in this case, this is only allowed if the 
spec clearly defines what it means for a specific compliance code to be 
sent, such as in 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-14.html#rfc.section.8.2>.

Sending it for anything else simply does not make any sense (at this 
point of time).

Best regards, Julian

---

From: Manfred Baedke <[email-masked]>
Date: Mon, 03 Jul 2006 11:03:02 +0200

Hi Michael,

> WebDAV far enough how something like this could be handled by the 
> WebDAV spec.
as Julian pointed out, this form of authentication is not covered by any 
specification, so there is no reliable way for a generic client to 
handle it anyway (besides the fact that authentication has nothing to do 
with WebDAV).

Regards,
Manfred

---

From: Michael Wechner <[email-masked]>
Date: Mon, 03 Jul 2006 15:51:10 +0200

Manfred Baedke wrote:
> as Julian pointed out, this form of authentication is not covered by 
> any specification, 

I think that's what confused me resp. I wanted to mix stuff which I have 
to agree doesn't make sense.

> so there is no reliable way for a generic client to handle it anyway 

well, if there would be a standard than I don't think this should be a 
problem. My suggestion would be that
the client sends a WWW-Authenticate header of its supported 
authentication schemes to the server and
the server then checks if one of the client's suggested authentication 
schemes is support by the server
and is able to respond appropriately resp. responding with an exception 
in the sense, that none of the suggested
authentication schemes is supported.

It seems to me that "WWW-Authenticate" is similar to "Accept" and that 
the client should make this suggestion first
and let the server react to it.

WDYT?
> (besides the fact that authentication has nothing to do with WebDAV).

agreed.

Thanks for clarifying

Michi

-- 
Michael Wechner
Wyona      -   Open Source Content Management   -    Apache Lenya
http://www.wyona.com                      http://lenya.apache.org
[email-masked]                        [email-masked]
+41 44 272 91 61

---

From: Manfred Baedke <[email-masked]>
Date: Mon, 03 Jul 2006 16:20:35 +0200

Hi Michael,
> and is able to respond appropriately resp. responding with an 
> exception in the sense, that none of the suggested

The use of WWW-Authenticate as a request header is unspecified.
Usually, it works just the other way round: the client makes an 
unauthenticated request, then the server responds with status 401, 
sending an WWW-Authenticate header containing at least one auth challenge:

http://www.greenbytes.de/tech/webdav/rfc2616.html#status.401

Of course, the client can try preemptive authentication in it's initial 
request.

Regards,
Manfred

---

From: Michael Wechner <[email-masked]>
Date: Mon, 03 Jul 2006 16:21:29 +0200

> I think that if this happens the working group made a grave mistake.

grave mistakes can happen all the time, so I think one should be 
prepared from the very beginning

(thinking about the Titanic or Goedel's incompleteness theorem, whereas 
I don't think Goedel's theorem is wrong, but
it rather shows nicely that unexpectable stuff can happen ... ;-)
>
>>> If a spec revision or an extension should introduce a change where 
>>> the server does need to know, the client *then* can send the DAV 
>>> request header, as defined in 
> Sure. It's needed to that a client can communicate to the server that 
> it knows about the status code 208, which a server may use to collapse 

thanks for the explanation
> fail to see how this is a WebDAV problem.

agreed, but are you aware of anyone trying to solve the problem of 
"custom" authentication?
>
> In particular, for WebDAV it's quite simple: the server should always 
> do RFC2617-based authentication if the request method is OPTIONS or 
> PROPFIND.
>
> Things get harder with non-browser based protocols such as AtomPut 
> that do *not* use specific verbs.

well, I am coming from a similar background ;-)
> The WebDAV spec doesn't care, and doesn't need to.

thanks for clarifying

All the best

Michi

---

From: Michael Wechner <[email-masked]>
Date: Mon, 03 Jul 2006 16:48:54 +0200

Manfred Baedke wrote:
> Hi Michael,
>
> what's really bad about programmatic clients and form based 
> authentication is the fact that the form comes with status code 200, 
> telling the client that everything is fine, and there is really no 
> realiable way for the client to tell wether the response body is the 
> intended content or a login form. Form based authentication, as it is 
> widely used nowadays, is broken by design. Don't use it.

ok, but what is the alternative? BASIC and DIGEST also have issues ;-)

Thanks

Michi

---

From: Manfred Baedke <[email-masked]>
Date: Mon, 03 Jul 2006 16:42:21 +0200

Hi Michael,

Regards,
Manfred

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 5 Jul 2006 17:14:00 -0700

We'll be talking about HTTP Authentication issues a lot at the IETF  
meetings next week in Montreal.  Mark Nottingham has scheduled a  
Wednesday Bar BoF on HTTP changes including authentication, and  
there's the "Web Authentication Enhancements" BoF on Friday which has  
combined the topics of cross-site authentication and anti-phishing  
measures.

Other authentication problems people have brought up include Digest's  
issues with offline dictionary attacks, and poor i18n support in  
Basic and Digest.

The idea of clients suggesting what authentication they'd like to use  
doesn't come up often.  Typically servers have security policies  
determined by the level of sensitivity of their content/usage, and  
dictate what authentication and encryption the client needs to use.   
That's why we're increasingly seeing requirements that clients MUST  
support TLS, Digest and Basic -- so that servers have a chance of  
interoperability while also setting minimum security policies.

Lisa

On Jul 3, 2006, at 6:51 AM, Michael Wechner wrote:

>>> Let's assume a resource is protected and a server would like to  
>>> offer custom authentication, e.g. it would send
>>> a HTML to a regular browser and some WebDAV specific XML to a  
>>> WebDAV enabled client, whereas I haven't digged into
>> as Julian pointed out, this form of authentication is not covered  
>> by any specification,
>
> I think that's what confused me resp. I wanted to mix stuff which I  
> have to agree doesn't make sense.
>
> well, if there would be a standard than I don't think this should  
> be a problem. My suggestion would be that
> the server then checks if one of the client's suggested  
> authentication schemes is support by the server
> It seems to me that "WWW-Authenticate" is similar to "Accept" and  
> that the client should make this suggestion first

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 31 Jul 2006 08:09:50 -0700

On Jul 3, 2006, at 7:48 AM, Michael Wechner wrote:

>> authentication is the fact that the form comes with status code  
>> 200, telling the client that everything is fine, and there is  
>> really no realiable way for the client to tell wether the response  
>> body is the intended content or a login form. Form based  
>> authentication, as it is widely used nowadays, is broken by  
>> design. Don't use it.
>

This thread has come up other times and places - I'm sort of curios  
to understand what people view as  the issues of Digest inside TLS?