Re: [apps-discuss] [kitten] [saag] HTTP authentication: the next generation

Dave Cridland <> Mon, 13 December 2010 11:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6325F28C0D0; Mon, 13 Dec 2010 03:21:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.532
X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zj7BugRYLD1g; Mon, 13 Dec 2010 03:21:33 -0800 (PST)
Received: from ( [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by (Postfix) with ESMTP id 63DCA3A6CD9; Mon, 13 Dec 2010 03:21:32 -0800 (PST)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id E14FD1168112; Mon, 13 Dec 2010 11:23:08 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CPfyXaB0kJvE; Mon, 13 Dec 2010 11:23:04 +0000 (GMT)
Received: from puncture ( [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by (Postfix) with ESMTPA id 43BFF1168110; Mon, 13 Dec 2010 11:23:04 +0000 (GMT)
References: <> <p06240809c928635499e8@[]> <> <> <> <> <> <> <> <> <2229.1292235952.971571@puncture> <>
In-Reply-To: <>
MIME-Version: 1.0
Message-Id: <2229.1292239384.281779@puncture>
Date: Mon, 13 Dec 2010 11:23:04 +0000
From: Dave Cridland <>
To: Adrien de Croy <>, Yoav Nir <>, General discussion of application-layer protocols <>, websec <>, Common Authentication Technologies - Next Generation <>, "" <>, "" <>, " Group" <>, Eliot Lear <>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Subject: Re: [apps-discuss] [kitten] [saag] HTTP authentication: the next generation
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Dec 2010 11:21:34 -0000

On Mon Dec 13 10:55:11 2010, Adrien de Croy wrote:
> for instance what would you propose for non-browsers, which perform  
> a large proportion of all HTTP transactions.
I agree a solution is needed for non-browsers (including IPP, for  
example). I disagree this needs to be, or should be, the same as a  
solution for web apps. I disagree that non-browser security is even a  
major priority at this point in time - it's adequately served by TLS  
and client certificates and/or Basic auth, depending on the security  
model desired - this latter I appreciate is a personal opinion.

However there is no doubt at all that current webapp deployments are  
in need of a serious improvement in security, given that these  
generally use TLS only during authentication itself, and use  
plaintext usernames and passwords for the authentication itself.

> Also, it seems like it would make the problem about a billion times  
> worse putting the auth into the application, where there are no  
> standards, and therefore it would need to be re-implemented for  
> each different application... kinda like what we have now already.

Yet every webapp currently uses a form, and it's so close a standard  
that browsers can, and do, spot login forms and allow the credentials  
to be cached. As such, I fail to see why we wouldn't want to place  
better authentication at that layer, where it's quite likely to be  
actually used.

> SASL is an orthogonal concept.  It's just a framework to negotiate  
> auth, whether that's over HTTP or something else.  So, it's a bit  
> of a red herring in this.

Right, that's fair enough.

> The trick is to get the application to actually use the auth of the  
> protocol.

Yes, but the problem is that existing, deployed, webapps could use  
Basic right now - they all just ask for a username and password after  
all. Yet none of them do, in part because of integration issues, but  
mostly I suspect due to usability and branding issues.

We could deploy some more advanced mechanisms in HTTP auth tomorrow,  
and nobody would use those either.

Dave Cridland - -
  - acap://
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade