Subject: Re: Resolving Digest authentication issue

From: "Jason Crawford" <[email-masked]>
Date: Fri, 2 Nov 2001 08:49:04 -0500

Sounds good to me.

------------------------------------------
Phone: 914-784-7569,   [email-masked]

---

From: "Clemm, Geoff" <[email-masked]>
Date: Fri, 2 Nov 2001 12:05:02 -0500

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:[email-masked]]
Sent: Friday, November 02, 2001 11:44 AM
To: Jim Whitehead
Cc: [email-masked]
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.

---

From: "Clemm, Geoff" <[email-masked]>
Date: Fri, 2 Nov 2001 13:15:48 -0500

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:[email-masked]]
Sent: Friday, November 02, 2001 12:05 PM
To: [email-masked]
Subject: RE: Resolving Digest authentication issue

Cheers,
Geoff

-----Original Message-----
From: Larry Masinter [mailto:[email-masked]]
Sent: Friday, November 02, 2001 11:44 AM
To: Jim Whitehead
Cc: [email-masked]
Subject: RE: Resolving Digest authentication issue

defined

---

From: "Jason Crawford" <[email-masked]>
Date: Tue, 6 Nov 2001 12:59:04 -0500

So we agree that Larry's option (b) is what we prefer to go with and that
Jim Whitehead's proposal, which multiple people have supported, falls in
category (b).

The remaining question seems to be whether we will include any language
about a secure network.   The text was...

  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.

  Client requirements: MUST support Basic, SSL/TLS support is STRONGLY
  RECOMMENDED
  Server requirements: SHOULD support Basic, SSL/TLS support is STRONGLY
  RECOMMENDED

Instead perhaps we can say something *like* the following...

  Basic MUST NOT be used unless the connection is secure.  The recommended
  method for securing a connection is TLS.

  Client requirements: MUST support Basic, SSL/TLS support is STRONGLY
  RECOMMENDED
  Server requirements: SHOULD support Basic, SSL/TLS support is STRONGLY
  RECOMMENDED

J.