Feedback on Bug 18

See <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=18>.

The current text on ietf.webdav.org has the following new appendix:

-- cut --
Appendix D.  Guidance for Clients Desiring to Authenticate

    Many WebDAV clients already implemented have account settings
    (similar to the way email clients store IMAP account settings).
    Thus, the WebDAV client would be able to authenticate with its first
    couple requests to the server, provided it had a way to get the
    authentication challenge from the server with realm name, nonce and
    other challenge information.  Note that the results of some requests
    might vary according to whether the client is authenticated or not --
    a PROPFIND might return more visible resources if the client is
    authenticated, yet not fail if the client is anonymous.

    There are a number of ways the client might be able to trigger the
    server do provide an authentication challenge.  This appendix
    describes a couple approaches that seem particularly likely to work.

    The first approach is to perform a request that ought to require
    authentication.  However, it's possible that a server might handle
    any request even without authentication, so to be entirely safe the
    client could add a conditional header to ensure that even if the
    request passes permissions checks it's not actually handled by the
    server.  An example of following this approach would be to use a PUT
    request with an "If-Match" header with a made-up ETag value.  This
    approach might fail to result in an authentication challenge if the
    server does not test authorization before testing conditionals as is
    required (see Section 8.1.3), or if the server does not need to test
    authorization.

    Example - forcing auth challenge with write request

    >>Request

      PUT /forceauth.txt HTTP/1.1
      Host: www.example.com
      If-Match: "xxx"
      Content-Type: text/plain
      Content-Length: 0


    The second approach is to use an Authorization header (defined in
    [RFC2617]) which is likely to be rejected by the server but which
    will then prompt a proper authentication challenge.  For example, the
    client could start with a PROPFIND request containing an
    Authorization header containing a made-up Basic userid:password
    string or with actual plausible credentials.  This approach relies on
    the server responding with a "401 Unauthorized" along with a
    challenge if it receives an Authorization header with an unrecognized
    username, invalid password, or if it doesn't even handle Basic
    authentication.  This seems likely to work because of the
    requirements of RFC2617:

    "If the origin server does not wish to accept the credentials sent
    with a request, it SHOULD return a 401 (Unauthorized) response.  The
    response MUST include a WWW-Authenticate header field containing at
    least one (possibly new) challenge applicable to the requested
    resource."

    Example - forcing auth challenge with Authorization header

    >>Request

      PROPFIND /docs/ HTTP/1.1
      Host: www.example.com
      Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
      Content-type: application/xml; charset="utf-8"
      Content-Length: xxxx

      [body omitted]
-- cut --

Observations:

1)

    request with an "If-Match" header with a made-up ETag value.  This
    approach might fail to result in an authentication challenge if the
    server does not test authorization before testing conditionals as is
    required (see Section 8.1.3), or if the server does not need to test
    authorization.

-> Why are we considering servers that do not implement this spec here?

2)

    other challenge information.  Note that the results of some requests
    might vary according to whether the client is authenticated or not --
    a PROPFIND might return more visible resources if the client is
    authenticated, yet not fail if the client is anonymous.

-> I checked with Apache/mod_dav, and for a resource that allows 
anonymous read access (such as <http://www.webdav.org/bind/>), sending 
an Authorization header does *not* trigger Authentication; it's simply 
ignored.

Received on Wednesday, 28 December 2005 13:49:54 UTC