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

Carsten Bormann <cabo@tzi.org> Mon, 13 December 2010 12:12 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB5B63A6D9E; Mon, 13 Dec 2010 04:12:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.316
X-Spam-Level:
X-Spam-Status: No, score=-106.316 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlx35im81SA2; Mon, 13 Dec 2010 04:12:35 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id A20C03A6DAA; Mon, 13 Dec 2010 04:12:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oBDCE5FS003904; Mon, 13 Dec 2010 13:14:05 +0100 (CET)
Received: from [192.168.217.101] (p5489B2BC.dip.t-dialin.net [84.137.178.188]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 908AF497; Mon, 13 Dec 2010 13:14:04 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <2229.1292239384.281779@puncture>
Date: Mon, 13 Dec 2010 13:14:03 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org>
References: <4D02AF81.6000907@stpeter.im> <p06240809c928635499e8@[10.20.30.150]> <ADDEC353-8DE6-408C-BC75-A50B795E2F6C@checkpoint.com> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <A23730A9-728B-4533-96D7-0B62496CC98A@checkpoint.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture>
To: General discussion of application-layer protocols <apps-discuss@ietf.org>, http-auth@ietf.org
X-Mailer: Apple Mail (2.1082)
Cc: Common Authentication Technologies - Next Generation <kitten@ietf.org>, websec <websec@ietf.org>, saag@ietf.org, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Subject: Re: [apps-discuss] [kitten] [saag] HTTP authentication: the next generation
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Dec 2010 12:12:36 -0000

On Dec 13, 2010, at 12:23, Dave Cridland wrote:

> every webapp currently uses a form

Yes.  Nice demonstration of conflicting requirements.

As a webapp developer, I want to control the user interface during authentication.
Leaving the user alone with the bland and unforgiving browser user interface for HTTP auth is suicide.
I want to provide extra buttons for forgotten passwords, maybe even password hints, and a "sign up" method.
HTML/CSS/JS lends itself well to providing such a friendly user interface.

As a security geek, I recognize this as exactly the problem that creates the potential for phishing.
Having the user type credentials into a random form is never going to be secure, HSTS notwithstanding.

Maybe the only way to address both requirements is to have something in HTML/CSS/JS that addresses authentication interactions.
Replacing <input type="password"/> for the 21st century.  This would allow web app designers to design a nice context for this interaction, and would allow running security protocols that are binding themselves to a browser-server security association that may be identical to or different from the TLS envelope.  "Storing passwords" in the browser might turn into storing those security associations.

This is not "HTTP authentication", but it might be more useful in the long run.
We'll need the browser people to start any such effort.

Gruesse, Carsten

PS.: And I'd still like to have some better form of authentication for machine-to-machine that can be independent from the TLS envelope.  But that is a completely different animal.