RE: Digest Authentication

> -----Original Message-----
> From: Jim Whitehead
>
> 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.

All right.  By this definition, our server already supports Digest, even
though it won't be available in most installations.  There are unattractive
ways of installing it that pass through Digest authentication in the Web
servers we bind to.

However, I _know_ that any customer who is expecting "Digest" in his
WWW-Authenticate headers will think me a weasel if I provide this
explanation -- even if I can demonstrate that Jim Says It's OK.

Is there an authoritative reference I can point to that details this
interpretation of "must support the Digest authentication scheme"?  If not,
can we have a public authoritative erratum that spells it out?

I'm pretty sure that anybody who just reads the spec is going to expect the
Digest scheme in WWW-Authenticate, and will expect clients to know how to
respond.


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

Agreed, but this can be addressed with the standard cop-out that says that
normal HTTP authentication methods are used, that choosing one is
out-of-scope, that security is important for WebDAV, and that, therefore,
Basic over the Web is inappropriate.

The Digest requirement still performs no useful function.  I suggested that
it set only _upper_ bounds on security, and you replied that even those
don't exist.

Received on Tuesday, 23 October 2001 14:46:01 UTC