RE: Digest Authentication

At 11:04 AM -0700 10/23/01, Jim Whitehead wrote:
>  > 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?
>
>Just thought of another example. The Apache server "supports" Digest
>authentication, even though the process of enabling it involves installing a
>new module (mod_auth_digest). In the case of Apache, it is possible to
>create a  server that does not have any Digest authentication code in the
>running server executable.
>
>Thus, Apache is an existence proof of "supporting" Digest, while not
>compromising security in environments where characteristics of the Digest
>implementation are unacceptable.
>

I'm sorry, but this response seems like it completely misses the 
point that Dylan is making about testability.  There is no principled 
way to distinguish between altering a configuration file and "writing 
code," and I very much doubt that you could come up with language 
that makes this distinction that this group is willing to put into 
the spec.  Without such language, there is no way to test server 
compliance with the requirement that a server "MUST support digest 
authentication without the server administrator writing code," which 
is apparently what you meant the spec to say (as opposed to what it 
actually says, which I would argue is more naturally interpreted as 
"no server configuration can be considered a compliant WebDAV server 
unless all challenges it issues against its WebDAV URLs contain a 
WWW-authentication header specifying digest authentication.")

I also believe that this discussion, so far, misses the larger point 
someone raise a while ago about "WebDAV has *nothing* to say about 
authentication."  I believe that:

1. WebDAV is intended to be a pure HTTP 1.1 extension (as explicitly 
defined and allowed for in the HTTP 1.1 spec).

2. Like all "good extensions" :^),  it should have absolutely nothing 
in it except specification of the semantics of its extension methods 
and the semantics of its extension headers.

3. The IETF concern about future protocol specs requiring stronger 
authentication than basic makes perfect sense for protocols that are 
not HTTP extensions but can't sensibly be taken as a mandate for HTTP 
extensions: such protocols ARE simply a form of HTTP 1.1.

To see point 3 clearly, consider that WebDAV servers needn't 
implement digest over the GET, HEAD, and POST methods, because those 
methods are HTTP 1.1 methods and so their semantics can't be 
redefined by the WebDAV spec.  Putting a requirement for digest 
authentication in the WebDAV spec is a no-op except for the extension 
methods, and thus does not promote security in any effective way.

I believe that if the IETF really wants servers that obey its 
protocols to enforce something stronger than basic, then the security 
group had better write a very short RFC that updates 2068 and says 
"HTTP 1.1 servers, including those that implement HTTP 1.1 
extensions, MUST implement either digest or a more secure 
authentication scheme whenever they require authentication for a 
request made over an insecure connection."  Then they should move as 
quickly as possible to promote that RFC along the standards track. 
Holding HTTP 1.1 extensions hostage to a policy that's not applied to 
HTTP 1.1 is a non-starter position: there will never be any HTTP 1.1 
extension that supports as much authenticated traffic as plain old 
HTTP 1.1 does.

     dan
-- 
Daniel Brotsky, Adobe Systems
tel 408-536-4150, pager 877-704-4062
2-way pager email: <mailto:page-dbrotsky@adobe.com>

Received on Wednesday, 24 October 2001 04:09:48 UTC