W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2001

RE: Digest Authentication

From: Matt Timmermans <mtimmerm@opentext.com>
Date: Tue, 23 Oct 2001 12:16:14 -0400
To: "'Jim Whitehead'" <ejw@cse.ucsc.edu>, "'WebDAV'" <w3c-dist-auth@w3.org>
Message-ID: <000801c15bde$0a1462a0$d482a8c0@mt2k>


> -----Original Message-----
> From: Jim Whitehead [mailto:ejw@cse.ucsc.edu]
> Sent: Monday, October 22, 2001 7:59 PM
> [...]
> The intent was to ensure that:
> (a) all server implementations were capable, if properly
> configured, of
> performing Digest authentication.
> [...]

This is still quite unclear.  What are the testable properties of a server
that "Supports the digest authentication scheme"?

The way I read it, "MUST support the Digest authentication scheme" says that
the server must return Digest as an available scheme in its
"WWW-Authenticate" headers, and that it must allow access to clients that
generate appropriate Digest responses.  This is the way you _want_ me to
read your specs, because if I don't read them this way, we run in to the
kind of troubles we have below.

> 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.

IIS can only be configured to present Digest in WWW-Authenticate if your
user database is in stored in Active Directory.  Does IIS still support
Digest, or does (IIS+Active directory) support Digest?  If I send IIS an
OPTIONS, does it have the right to claim DAV-compliance if Active directory
isn't installed?  If DoD gets a special version of IIS that disables the
Basic and Digest options, because DoD only allows their public-key scheme,
does that version support Digest?

> > 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.

I trust you can see how it follows from my reading.  "The server requires
NTLM" means that NTLM is the only scheme presented in WWW-Authenticate.  If
Digest MUST be present in WWW-Authenticate, then the server cannot require
NTLM.

> > 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.

If a client will only answer NTLM authentication requests, then it requires
NTLM.   That means that if a server only allows Basic and Digest, then you
can't access it with that client.  In high-security environments, this is a
perfectly reasonable thing for the client to do, because the client might
have a responsibility to protect the user's password.

> > 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.

So there is no way to determine from the client side whether or not a server
"supports the Digest authentication scheme"?  That is very odd.

You're saying that if I run my server in an environment that doesn't allow
me to present Digest in the WWW-Authenticate headers, then that's OK, as
long as there's a checkbox for Digest somewhere and I've unchecked it?  But
the server would become mysteriously non-compliant if I customized it for my
environment by removing the checkbox, and that Digest implementation that
isn't used?  It would become non-compliant, even though it's functionally
equivalent?!

Even if this was reasonable, it would be outside the scope of a protocol
specification.
Received on Tuesday, 23 October 2001 12:17:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:58 GMT