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

RE: Resolving Digest authentication issue

From: Clemm, Geoff <gclemm@rational.com>
Date: Fri, 2 Nov 2001 13:15:48 -0500
Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AD49@SUS-MA1IT01>
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.


-----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.


-----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
> 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 13:16:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:24 UTC