Re: Straw-man charter for http-bis

Henrik Nordstrom <henrik@henriknordstrom.net> Mon, 11 June 2007 03:23 UTC

Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxaVV-0006WQ-4A; Sun, 10 Jun 2007 23:23:53 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HxaVU-0006WL-4G for discuss-confirm+ok@megatron.ietf.org; Sun, 10 Jun 2007 23:23:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxaVT-0006WD-R0 for discuss@apps.ietf.org; Sun, 10 Jun 2007 23:23:51 -0400
Received: from av7-2-sn3.vrr.skanova.net ([81.228.9.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxaVS-0003EA-9H for discuss@apps.ietf.org; Sun, 10 Jun 2007 23:23:51 -0400
Received: by av7-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 4C41338145; Mon, 11 Jun 2007 05:23:01 +0200 (CEST)
Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av7-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 3087637F9B; Mon, 11 Jun 2007 05:23:01 +0200 (CEST)
Received: from henriknordstrom.net (81-233-163-21-no84.tbcn.telia.com [81.233.163.21]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 73FA037E43; Mon, 11 Jun 2007 05:23:46 +0200 (CEST)
Received: from [192.168.1.2] (henriknordstrom.net [192.168.1.2]) by henriknordstrom.net (8.12.11.20060308/8.12.8) with ESMTP id l5B3NiHq006821; Mon, 11 Jun 2007 05:23:44 +0200
Subject: Re: Straw-man charter for http-bis
From: Henrik Nordstrom <henrik@henriknordstrom.net>
To: Lisa Dusseault <lisa@osafoundation.org>
In-Reply-To: <8DD2BD5A-9068-43C3-973E-382FAD2E0EA8@osafoundation.org>
References: <BA772834-227A-4C1B-9534-070C50DF05B3@mnot.net> <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> <1181250794.24162.109.camel@henriknordstrom.net> <46696B98.1090201@cisco.com> <1181342059.4818.63.camel@henriknordstrom.net> <8DD2BD5A-9068-43C3-973E-382FAD2E0EA8@osafoundation.org>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-3bVeNkNhMDqXW/snEWE2"
Date: Mon, 11 Jun 2007 05:23:44 +0200
Message-Id: <1181532224.3389.47.camel@henriknordstrom.net>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6)
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on henriknordstrom.net
X-Virus-Status: Clean
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
Cc: Apps Discuss <discuss@apps.ietf.org>, Mark Nottingham <mnot@mnot.net>, Chris Newman <Chris.Newman@Sun.COM>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Eliot Lear <lear@cisco.com>
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org

sön 2007-06-10 klockan 14:10 -0700 skrev Lisa Dusseault:



> Digest has a bad reputation particularly among Web App developers for
> a number of reasons, some inherent to the design and specification,
> some stemming from implementation and deployment choices.

Nearly all is implementation.

> http://www.xml.com/pub/a/2003/12/17/dive.html:  "most web hosting
> providers don't turn on digest authentication (it requires an Apache
> module that is not on by default). Even if Bob's ISP had

Implementation.

> http://blogs.msdn.com/drnick/archive/2006/05/12/understanding-http-authentication.aspx: "Digest authentication requires the use of Windows domain accounts.

Plain untrue, unless you restrict your view of Digest to the Microsoft
IIS implementation in which case it's implementation.


> http://www.imc.org/atom-syntax/mail-archive/msg06103.html: " (1) Some
> web-servers remove the WWW-Authenticate header before passing it to a
> CGI program."

Implementation. Well, CGI is not the proper interface to implement
authentication schemes, but it's implementation in the sense that web
servers is a bit poor in allowing applications to set the authentication
requirements in a sensible manner. But it is fully doable with only a
little effort.

> http://www.imc.org/atom-protocol/mail-archive/msg00836.html: "do all
> digest and WSSE implementations require server-side access to
> clear-text passwords or is that just a weakness of the implementations
> I looked at?"

No, the realm specific H(A1) is required.

> http://www.imc.org/atom-syntax/mail-archive/msg00139.html:  "I'm a
> small site, security is very much a concern and my host does not
> provide Digest and won't do so." 

Implementation.

> Thus it's hard for an administrator to use today's Web server software
> and Digest authentication, and still have an application-specific
> database of usernames/passwords.  The server software gets in the way
> -- it may even be easier for the Web App developer to implement
> something non-standard like WSSE than have to rely on built-in
> functions.

Thats all implementation. Web servers don't make it easy for
applications to use/control HTTP authentication. So applications don't
use it.

CGI is not the proper interface for HTTP authentication. It's the web
servers responsibility to handle the fine details of HTTP (including
authentication) and the CGIs responsibility to provide content &
applications.

> i18n is also a problem:
> http://www.agileprogrammer.com/eightytwenty/archive/2006/05/04/14280.aspx

Yes, this is a specifications problem inherent to both Basic and Digest,

> And for humour on the situation:
> http://bitworking.org/news/Problems_with_HTTP_Authentication_Interop

Yes, there is lots of broken Digest implementations around either not
reading the specs, not caring to implement anything but the absolute
minimum required for a conditionally compliant implementation, not
testing their implementation, or sticking to old specs considered
obsolete and broken. And pressure from users that things must work even
with the broken implementations as the users consider the broken browser
implementations unfixable. Don't know how many times I have asked users
to file a bug report with vendor X and always receive the same answer
"no, it's of no use. we must work around the bug somehow".

Regards
Henrik