RE: Digest Authentication

> The offending sentence is in paragraph 3 of 17.1, where it says "WebDAV
> applications MUST support the Digest authentication scheme".

I wrote this section of 2518.

The intent was to ensure that:
(a) all server implementations were capable, if properly configured, of
performing Digest authentication.
(b) all client implementations were capable of responding to a Digest
authentication challenge, if issued by a server.

The rationale behind this was the IETF's stated policy of not approving new
protocols that sent username/password pairs over the wire in the clear.

Note, however, that RFC 2518 does NOT say that servers must USE Digest,
merely that they "support" (i.e., "implement") it. RFC 2518 also does NOT
say that you cannot implement or use other authentication technologies. IIS
5, for example, can be configured to use NTLM, and/or Digest, and/or Basic.

We recognized that there are a wide, wide range of deployment scenarios, and
we could not, a priori, predict what they would be like. Thus we left the
decision on whether to actually use Digest to the people deploying WebDAV
servers. And, yes, we did realize that initially, most DAV use would involve
Basic authentication over the open Internet, or within an intranet.

> For a server application, a reasonable interpretation of this directive
> means that a client can authenticate with any WebDAV server using Digest
> authentication.

The cause-effect is a little skewed here. The interpretation is that it must
be possible to configure a client such that it can respond to a Digest
authentication challenge issued by the server.

> This implies (in the strong sense) that a server _cannot_
> require stronger authentication.

I do not see how this follows. IIS 5/6 is a counter-example of a server that
has successfully implemented an additional authentication scheme, NTLM, in
addition to Digest and Basic.

> It similarly implies that a client _cannot_ require stronger
> authentication.

In a challenge-response authentication scheme, I don't see how a client can
require *anything*.  A client could be configured to refuse to answer a
challenge in a particular authentication scheme (say, Basic), but not
answering is a different beast from *requiring* a specific authentication
scheme.

> It also implies that WebDAV servers cannot exist in authenticated
> environments that are _too_secure_ to support Digest.

I disagree. Following RFC 2518, someone deploying a DAV server could disable
Digest authentication, require connections only via SSL, and only allow
Basic authentication.

> I'm willing to accept that IETF and W3C policies would forbid sending
> passwords in the clear, and I'll admit to not having done an exhaustive
> search, but I cannot believe that it is the policy of either IETF
> or W3C to forbid organizational requirements for strong authentication
> mechanisms.

Correct. But, you're making a strawman out of 2518 that isn't true. Nothing
in 2518 prevents the use of stronger (or any) authentication schemes other
than Basic and Digest. Since Digest is unsatisfactory to a large number of
implementors, we felt that it was quite likely that new authentication
schemes would be developed over time, and wanted to make sure we could
accommodate them.

> Appropriate wording would be "If a WebDAV client
> application supports the Basic authentication scheme, then it must also
> support Digest, and must choose to use Digest over Basic in all
> circumstances where the server permits both".

Actually, this is too strong, since Basic over SSL is reasonably secure.

- Jim

Received on Monday, 22 October 2001 20:03:15 UTC