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

Marsh Ray <marsh@extendedsubset.com> Fri, 10 December 2010 23:52 UTC

Return-Path: <marsh@extendedsubset.com>
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 4C52628C16B; Fri, 10 Dec 2010 15:52:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Level:
X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599]
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 3T0nlJOeG43h; Fri, 10 Dec 2010 15:52:58 -0800 (PST)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 6FEB928C13D; Fri, 10 Dec 2010 15:52:58 -0800 (PST)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1PRCnG-0007jy-Mx; Fri, 10 Dec 2010 23:54:30 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id BC33060C7; Fri, 10 Dec 2010 23:54:28 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1/98GPaWAVDLHrWGRfLI2yC8jrjm0RWGOw=
Message-ID: <4D02BDB3.7060801@extendedsubset.com>
Date: Fri, 10 Dec 2010 17:54:27 -0600
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>
References: <4D02AF81.6000907@stpeter.im>
In-Reply-To: <4D02AF81.6000907@stpeter.im>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Sat, 11 Dec 2010 08:09:49 -0800
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, websec@ietf.org, "kitten@ietf.org" <kitten@ietf.org>, http-auth@ietf.org, saag@ietf.org, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Subject: Re: [apps-discuss] [websec] 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: Fri, 10 Dec 2010 23:52:59 -0000

On 12/10/2010 04:53 PM, Peter Saint-Andre wrote:
> Is it time to start thinking about next-generation authentication
> technologies for HTTP?

No? :-)

IMHO, authentication just doesn't belong at the HTTP layer.

HTTP is inherently bad at being stateful. Stateless interfaces can be 
fantastic, but it doesn't support the "login session" concept that most 
people have in mind when they talk about authentication.

Unless you're properly using TLS, you have no reason to believe that the 
byte you just received is from the same party as the previous byte you 
received. So under those circumstances, what exactly are you 
authenticating, and to whom?

I use a lot of web sites and none of them do authentication via HTTP. 
Every single one of them expects a username/password via HTTP(s) POST 
variables and returns a cookie of varying duration.

But what could we possibly do for a stateless, unMACed protocol like 
HTTP, except integrate and bind it better with a lower layer providing 
real integrity?

I think what the world needs are ways for web apps (literally, the Ruby 
code) to easily work with the strongly-authenticated identities which 
are supported at the TLS layer. TLS already supports "sessions" and 
"client authentication", but for whatever reasons they're not being 
utilized. We should make using those facilities as easy for web 
developers as doing cookie-based logins.

Improving the "authentication" for a protocol lacking basic message 
integrity would just be giving a false sense of security. It's like 
improving the login authentication for telnet or FTP sessions.

But I do think there are lots of improvements waiting to be made in the 
right directions.

- Marsh