Subject: I command you to support Digest!!!

From: "Jösh" <[email-masked]>
Date: Thu, 25 Oct 2001 05:48:53 -0400

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

---

From: "Larry Masinter - [email-masked]" <[email-masked]>
Date: Thu, 25 Oct 2001 08:20:24 -0700

In any specification or standard, if you have two options
A or B that don't interoperate, you don't get an "interoperable"
standard if some people support A but not B, and other people
support B but not A.  The goal of standards is that there's
general interoperability.

So a server that only supports basic with SSL may be "secure
enough", but it's not "interoperable enough".

The standards group must choose a baseline that is both
"secure enough" and "interoperable enough". So far, the group
chose "must support Digest". If you change it to "must support
Digest OR basic+SSL" on the server side, then you're mandating
"must support Digest AND basic+SSL" on the client side.

This is nice for server implementors but maybe not as nice for
client implementors.

---

From: "Matt Timmermans" <[email-masked]>
Date: Thu, 25 Oct 2001 12:31:16 -0400

> -----Original Message-----
> From: Larry Masinter
> [...]

You wouldn't want to tell clients that they have to respond to any
particular scheme, because a client might be used in a more restrictive
environment.

It is no trouble at all, however, to require _clients_ to support (really
support!) Digest if they support Basic, because there are no _client-side_
security parameters that Basic meets, but Digest doesn't.

---

From: "Jösh" <[email-masked]>
Date: Thu, 25 Oct 2001 16:58:37 -0400

----- Original Message -----
From: "Larry Masinter - [email-masked]" <[email-masked]>
To: "Jösh" <[email-masked]>; "Jim Whitehead" <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Thursday, October 25, 2001 11:20 AM
Subject: RE: I command you to support Digest!!!

> This is nice for server implementors but maybe not as nice for
Thats a pretty good observation.  However, i think digest
for server implementors is *hard* while digest for client
implementors is *easy*.
I think that might be a good plan..

---

From: Alan Kent <[email-masked]>
Date: Fri, 26 Oct 2001 09:50:41 +1000

> for server implementors is *hard* while digest for client

For some of our sites, replace *hard* with *impossible*.
We do not control the database of user names and passwords.
We do not have access to the password, a hashed form of it,
or anything. We can only supply details and get back details
about the user. Period. For these sites it is impossible to support
digest authentication. The customers in these cases *will not*
accept having a second copy of the user database. They went
to a lot of effort to get single sign on across the organisation.

This is my problem, not WebDAV's. I just thought it was worth
pointing out again. There was lots of discussion about how
you can store hashed versions of the passwords and so its safer
etc. However, in many large organisations there is a single
group controlling authentication etc and they fight tooth
and nail to keep that control - and often rightly so. If
security is important, you have to keep your security db
secure.

Alan