Subject: Resolving Digest authentication issue

From: "Jim Whitehead" <[email-masked]>
Date: Thu, 1 Nov 2001 17:52:37 -0800

Jason Crawford pointed out to me that we never resolved the Digest
authentication issue, so let me take a stab at it. If you quibble with the
wording below, don't just say you don't like it -- suggest some alternate
wording.

Dylan Barrel [1] and Alan Kent [2] describe the issues with supporting
Digest authentication on the server, and their contention that support for
Digest is unacceptable:

[1] http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0062.html
[2] http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0087.html

I clarified the meaning of "supports Digest authentication" in [3]:

[3] http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0073.html

I think Matt Timmerman's post [4] has the start of a solution:

[4] http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0080.html

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.

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

* Digest SHOULD be used when the connection is insecure, such as a non-TLS
connection over the Internet.

Client requirements: MUST support Digest
Server requirements: SHOULD support Digest, but it is acceptable for Digest
authentication to be disabled by default. It SHOULD be possible for an
administrator to configure a server to use Digest.

* Additional authentication schemes beyond Basic and Digest MAY be
supported, whether or not described in an IETF specification. Implementors
should be aware that use of other authentication schemes guarantees some
level of non-interoperation of that authentication scheme, since all WebDAV
clients and servers cannot be expected to support that authentication
scheme.

So, for example, it's OK for people to support NTLM.

* Finally, to guarantee some level of authentication will be possible: a
server MUST at minimum support either Basic OR Digest. A server SHOULD
support Basic AND Digest.

Note that the terms MUST and SHOULD are being used as defined in RFC 2119:

1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

For example, I would say that Dylan and Matt have carefully weighed the
implications of Digest support, and so if they decided not to support Digest
under the language above, this would meet the letter and the spirit of the
proposed language.

Comments?

- Jim

---

From: Alan Kent <[email-masked]>
Date: Fri, 2 Nov 2001 13:52:54 +1100

> support Basic AND Digest.
...
> - Jim

Sounds good to me.
Alan

---

From: "Stefan Eissing" <[email-masked]>
Date: Fri, 2 Nov 2001 11:24:08 +0100

Fine with me.

//Stefan

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jim Whitehead
> Sent: Friday, November 02, 2001 2:53 AM
> To: [email-masked]
> Subject: Resolving Digest authentication issue
>
>
>

---

From: "Dylan Barrell" <[email-masked]>
Date: Fri, 2 Nov 2001 10:32:29 -0500

Sounds good to me too...

--Dylan

> [mailto:[email-masked]]On Behalf Of Alan Kent
> Sent: Thursday, November 01, 2001 9:53 PM
> To: [email-masked]
> Subject: Re: Resolving Digest authentication issue
>
>

---

From: "Matt Timmermans" <[email-masked]>
Date: Fri, 2 Nov 2001 11:38:08 -0500

I like it.

> Sent: Thursday, November 01, 2001 8:53 PM
> To: [email-masked]
> [1] 
> http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0062.html
> [2] 
> http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0087.html
> 
> [3] 
> http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0073.html
> 
> [4] 
> http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0080.html
>

---

From: "Larry Masinter" <[email-masked]>
Date: Fri, 2 Nov 2001 08:43:54 -0800

> 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: "Dylan Barrell" <[email-masked]>
Date: Fri, 2 Nov 2001 12:05:20 -0500

If we have to choose one, then I vote for Basic/SSL/TLS

--Dylan

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

---

From: "Jim Whitehead" <[email-masked]>
Date: Fri, 2 Nov 2001 09:58:01 -0800

> appropriate for those networks aren't the domain of the IETF.

All true. My purpose was to characterize times when someone might reasonably
deploy and use Basic authentication. It's naive to assume that Basic will
not be used, and so having the protocol state "don't do this thing that
everyone does" makes it seem out of touch.

>    servers MUST support one or the other (or both)

This is essentially what I was proposing. I think you are proposing we go
further and add "clients MUST only use Basic when using SSL/TLS". After all,
if a client supports basic with SSL/TLS, then it of course supports Basic
when not using SSL/TLS. But, I think adding additional constraints goes too
far -- what if a different transport security mechanism is introduced,
perhaps as part of IPv6? It would be better to say, "clients MUST only use
Basic over a secure connection", which then gets us back to the definition
of a secure connection.

> to see which options each supports.

The solution is to place the responsibility of supporting as many
authentication schemes as possible on the client. This frees the server to
pick the one that best serves its needs. That's why I like your choice (b),
since clients MUST support Basic and Digest, while servers only must support
one of the two.  This, then, meets the condition of interoperability without
the user needing to do detailed protocol analysis.

- Jim