- From: Dylan Barrell <dbarrell@opentext.com>
- Date: Fri, 2 Nov 2001 12:05:20 -0500
- To: "Larry Masinter" <LMM@acm.org>, "Jim Whitehead" <ejw@cse.ucsc.edu>
- Cc: <w3c-dist-auth@w3.org>
If we have to choose one, then I vote for Basic/SSL/TLS --Dylan > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Larry Masinter > 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 12:06:31 UTC