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