- From: Jim Whitehead <ejw@cse.ucsc.edu>
- Date: Tue, 23 Oct 2001 10:55:12 -0700
- To: <mtimmerm@opentext.com>, "'WebDAV'" <w3c-dist-auth@w3.org>
> This is still quite unclear. What are the testable properties of a server > that "Supports the digest authentication scheme"? The testable property is this: It must be possible to configure the server, without writing new code, such that it will return a Digest authentication challenge for a GET on given resource R. It is possible to create a falsifiable test of this property. > 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. Again, RFC 2518 does not mandate that Digest MUST be present in every WWW-Authenticate header, only that it must be possible to configure that server to make this so. > > > 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. No, the client only has the ability to determine which authentication schemes are currently active on a specific resource, by examining the WWW-Authenticate header. Even if the client could determine that Digest was supported, but not turned on for a particular resource, what would it do with that information? Having this information wouldn't lead to greater interoperability. > 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? Correct. (Assuming you mean the checkbox is on the server). > 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?! My personal opinion is that if the checkbox controlled a process that swapped in/out a code library implementing the server-side storage of passwords (and possibly resulted in data conversion of a password database to a new format), that would be acceptable. That is, you could have a running server executable that was incapable of Digest, so long as there was an easy process (i.e., one that does not involve writing code) for changing that executable so that it could support Digest. In operational environments where Digest was not acceptable, the Digest code would never be merged into the server executable. Alternately, it might even be OK to have to go back to the installation disk to get Digest support added. What is unacceptable is for a user of a server to have to write code to get Digest support. The goal is to make it "relatively easy" for a server operator to enable/disable Digest authentication support on their server. > Even if this was reasonable, it would be outside the scope of a protocol > specification. I have to agree with Phill here. The political reality of the IESG is such that an application protocol specification will not be approved if the only mechanism for sending passwords over the wire is in the clear. My techical opinion is that the current "Basic over SSL" or Digest choices are the weakest possible requirements that will allow the specification to be accepted. This is why I was encouraging people to develop a new, more acceptable form of HTTP authentication technology. But, the IETF has a long history of pragmatism, and so they would be amenable to arguments about the lack of suitability of Digest. However, I do feel you have an uphill climb to convince people that the problems with Digest are inherent to the protocol, and not merely a peculiarity of your particular implementation. The path of argumentation usually runs: Person A: For implementation architecture X, Digest has the following bad properties. Person B: Ah, but if you do your implementation this way (...), you don't have that problem. Person A: Well, that may be true, but it would be difficult/costly to do it that way. Person B: Well then, your objection isn't to the protocol, it's to the expense of implementing the protocol. That is, it's not a technical argument, it's an economic one. Now, you could present evidence that enough people have enough problems with the implementation that it does imply a problem with the protocol, but that's a tough argument to make. - Jim
Received on Tuesday, 23 October 2001 13:59:08 UTC