- From: Jösh <josh@bluescreen.org>
- Date: Thu, 25 Oct 2001 05:48:53 -0400
- To: "Jim Whitehead" <ejw@cse.ucsc.edu>, <mtimmerm@opentext.com>, <w3c-dist-auth@w3.org>
Here are my thoughts on this. Its a bit late for me, so they might be a bit jumbled.. For those in a hurry, my short answer is: I think that at this time, Digest is no longer the right minimum requirement. Is there some way we can just require an "IETF recognized 'non-plaintext over the wire' authentication system" , such as Digest, Kerberos or SSL+Basic"? My longer explanations... On what/who the requirement applies to... The Requirement applies to implementation, not operation. If you ship a product that claims that it complies with WEBDAV RFC, it must support Digest in the shipped form. If you dont support Digest, then you are not completely compliant. Frankly, I dont think this is such a big deal these days. I imagine a product box or spec that says "Supports WebDAV * " with a footnote below somewhere effectively saying: "* Compliant with RFC XXXX except for Digest Authentication" or "* Conditionally compliant with RFC XXXX. This product does not support Digest" I think its reasonable to have customized versions of products that may only be conditionally compliant. As for servers in operation, it is well known that Operational Policy in an organization may cause a product to be configured in such as way that it does not interoperate with another compliant product. Many specs today seem to have a set of "features" and a minumum required set to be supported, which apply to products claiming compliance yet operators can configure them out of compliance. There is probably some work that should be done to find good language to describe this and differentiate it from "real" requirements that must always be true in both implementation and operation. On Digest as the right choice for the requirement: IMHO, the spirit was "Anyone procuring a product that claims WebDAV RFC compliant must be able to be configured to use a non-plaintext authentication that is recognized by the IETF" Unfortunately, requiring SSL would have been too painful both because it is/was not IPR free and that it is/was considered too hard/heavyweight to require. As a result, Digest was available to be used to solve this problem. Digest was created to fix this problem, of plaintext passwords *over the wire*. I dont think it was obvious at the time how much its implementation would complicate how passwords are stored in practice. Today, I would think that requiring SSL+basic would be less of a hardship than Digest. In my own experience, I know that implementing SSL (for the encryption part at least) was relatively simple and isolated from the rest of the system. In fact, it can be done in a way that applications can use SSL with almost no code changes, similar to socks. Implementing Digest in Windows/IIS was very difficult, since IIS uses authentication integrated with system accounts. Prior to Digest, system passwords were stored in a hash that was incompatible with the digest hash. So some pretty serious architectural changes had to be made to support digest in a non-hacky way. It seems that Daryl has come to a similar realization. I think that at this time, Digest is no longer the right minimum requirement. Is there some way we can just require an "IETF recognized 'non-plaintext over the wire' authentication system, such as Digest, Kerberos or SSL+Basic"? On Testability: Basic Authentication is a required part of HTTP/1.1, testing for that is the same problem as testing for Digest. Depending on your perspective, this reduces to a previously unsolved (or solved) problem. :)
Received on Thursday, 25 October 2001 05:46:32 UTC