W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2001

RE: Resolving Digest authentication issue

From: Larry Masinter <LMM@acm.org>
Date: Fri, 2 Nov 2001 08:43:54 -0800
To: "Jim Whitehead" <ejw@cse.ucsc.edu>
Cc: <w3c-dist-auth@w3.org>
> Thus, I propose the following authentication requirements:
> * Basic MUST NOT be used unless the connection is secure. Secure is
> 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:
   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 11:45:07 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:24 UTC