RE: Digest Authentication

> This is still quite unclear.  What are the testable properties of a server
> that "Supports the digest authentication scheme"?

The testable property is this:

It must be possible to configure the server, without writing new code, such
that it will return a Digest authentication challenge for a GET on given
resource R.

It is possible to create a falsifiable test of this property.

> I trust you can see how it follows from my reading.  "The server requires
> NTLM" means that NTLM is the only scheme presented in
> WWW-Authenticate.  If Digest MUST be present in WWW-Authenticate, then the
> server cannot require NTLM.

Again, RFC 2518 does not mandate that Digest MUST be present in every
WWW-Authenticate header, only that it must be possible to configure that
server to make this so.

> > > It also implies that WebDAV servers cannot exist in authenticated
> > > environments that are _too_secure_ to support Digest.
> >
> > I disagree. Following RFC 2518, someone deploying a DAV
> > server could disable Digest authentication, require connections
> > only via SSL, and only allow Basic authentication.
>
> So there is no way to determine from the client side whether or
> not a server "supports the Digest authentication scheme"?  That is
> very odd.

No, the client only has the ability to determine which authentication
schemes are currently active on a specific resource, by examining the
WWW-Authenticate header.

Even if the client could determine that Digest was supported, but not turned
on for a particular resource, what would it do with that information? Having
this information wouldn't lead to greater interoperability.

> You're saying that if I run my server in an environment that doesn't allow
> me to present Digest in the WWW-Authenticate headers, then that's OK, as
> long as there's a checkbox for Digest somewhere and I've unchecked it?

Correct. (Assuming you mean the checkbox is on the server).

> But the server would become mysteriously non-compliant if I
> customized it for my environment by removing the checkbox, and that
> Digest implementation that isn't used?  It would become non-compliant,
> even though it's functionally equivalent?!

My personal opinion is that if the checkbox controlled a process that
swapped in/out a code library implementing the server-side storage of
passwords (and possibly resulted in data conversion of a password database
to a new format), that would be acceptable. That is, you could have a
running server executable that was incapable of Digest, so long as there was
an easy process (i.e., one that does not involve writing code) for changing
that executable so that it could support Digest. In operational environments
where Digest was not acceptable, the Digest code would never be merged into
the server executable.

Alternately, it might even be OK to have to go back to the installation disk
to get Digest support added.

What is unacceptable is for a user of a server to have to write code to get
Digest support. The goal is to make it "relatively easy" for a server
operator to enable/disable Digest authentication support on their server.

> Even if this was reasonable, it would be outside the scope of a protocol
> specification.

I have to agree with Phill here. The political reality of the IESG is such
that an application protocol specification will not be approved if the only
mechanism for sending passwords over the wire is in the clear. My techical
opinion is that the current "Basic over SSL" or Digest choices are the
weakest possible requirements that will allow the specification to be
accepted. This is why I was encouraging people to develop a new, more
acceptable form of HTTP authentication technology.

But, the IETF has a long history of pragmatism, and so they would be
amenable to arguments about the lack of suitability of Digest. However, I do
feel you have an uphill climb to convince people that the problems with
Digest are inherent to the protocol, and not merely a peculiarity of your
particular implementation. The path of argumentation usually runs:

Person A: For implementation architecture X, Digest has the following bad
properties.
Person B: Ah, but if you do your implementation this way (...), you don't
have that problem.
Person A: Well, that may be true, but it would be difficult/costly to do it
that way.
Person B: Well then, your objection isn't to the protocol, it's to the
expense of implementing the protocol. That is, it's not a technical
argument, it's an economic one.

Now, you could present evidence that enough people have enough problems with
the implementation that it does imply a problem with the protocol, but
that's a tough argument to make.

- Jim

Received on Tuesday, 23 October 2001 13:59:08 UTC