- From: Clemm, Geoff <gclemm@rational.com>
- Date: Fri, 2 Nov 2001 13:15:48 -0500
- To: w3c-dist-auth@w3.org
Oops. My preferred choice (server MUST support either Digest or Basic-with-SSL/TLS) was option (b), not option (c)). The problem with saying just "a secure transport mechanism" is that this doesn't help a client know what secure transport mechanisms it needs to support in order to interoperate. Cheers, Geoff -----Original Message----- From: Clemm, Geoff [mailto:gclemm@Rational.Com] Sent: Friday, November 02, 2001 12:05 PM To: w3c-dist-auth@w3.org Subject: RE: Resolving Digest authentication issue I agree with Larry. The statement made in the protocol should just be a simple "A WebDAV server MUST support xxx". Since an argument has been made that "A WebDAV server MUST support digest" is not acceptable, the only choice I see is option (c), namely: "A WebDAV server MUST support either Digest or Basic-with-SSL/TLS". The fact that an interoperable client must support both Digest and Basic-with-SSL/TLS follows from this statement about the server, and therefore is redundant. All that additional language about when to use Digest vs Basic is standard security info just obscures the basic interoperability issue, and should occur in the authentication protocol definitions, not in the WebDAV spec. Cheers, Geoff -----Original Message----- From: Larry Masinter [mailto:LMM@acm.org] Sent: Friday, November 02, 2001 11:44 AM To: Jim Whitehead Cc: w3c-dist-auth@w3.org Subject: RE: Resolving Digest authentication issue > Thus, I propose the following authentication requirements: > > * Basic MUST NOT be used unless the connection is secure. Secure is defined > to be TLS over the Internet, a physically secure network, or a network > behind a well-administered firewall. In most IETF circles, it is believed that "well-administered firewall" is a fleeting circumstance: you might have one today, but it's unlikely to remain that way for long. It is also believed that the only "physically secure network" is one that you make with wirecutters -- snipping all the cables, and that the specifications for things appropriate for those networks aren't the domain of the IETF. That's why, in general, no IETF standards-track document can assume such things. (If you want to deploy a system that makes those assumptions, that's fine, you just can't say that there's an IETF standard that it's compliant with). So I think the acceptable choices (as far as IETF goes) are: a) clients and servers MUST support Digest (what we have now) b) clients MUST support BOTH Digest and basic-with-SSL/TLS servers MUST support one or the other (or both) c) clients MUST support one or the other (or both) servers MUST support both Digest and basic-with-SSL/TLS (since it is the server implementors squawking about Digest, I don't think this will fly) d) There are two standards: WebDAV-with-digest WebDAV-with-SSL/TLS An implementation (client or server) supports either or both. The two protocols are not interoperable, of course, so you should be careful to say which you have. In all of these cases, you can support other authentication mechanisms too, but it doesn't guarantee interoperability. I don't have a preference for what the standard should say, except that I believe that it's important that users should be able to tell whether a client will interoperate with a server without having to do some kind of protocol analysis to see which options each supports.
Received on Friday, 2 November 2001 13:16:25 UTC