Re: [apps-discuss] [http-auth] [websec] HTTP authentication: the next generation
Tim Morgan <tim-research@sentinelchicken.org> Tue, 14 December 2010 17:11 UTC
Return-Path: <tim-research@sentinelchicken.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 5453F3A6FB5 for <apps-discuss@core3.amsl.com>; Tue, 14 Dec 2010 09:11:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level:
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 fOjfk1niLTsr for <apps-discuss@core3.amsl.com>; Tue, 14 Dec 2010 09:11:15 -0800 (PST)
Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by core3.amsl.com (Postfix) with ESMTP id A97773A6FB6 for <apps-discuss@ietf.org>; Tue, 14 Dec 2010 09:11:12 -0800 (PST)
Received: (qmail 10544 invoked from network); 14 Dec 2010 17:23:07 -0000
Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 14 Dec 2010 17:23:07 -0000
Received: (qmail 24957 invoked from network); 14 Dec 2010 17:16:30 -0000
Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 14 Dec 2010 17:16:30 -0000
Received: (nullmailer pid 6184 invoked by uid 1000); Tue, 14 Dec 2010 17:12:50 -0000
Date: Tue, 14 Dec 2010 09:12:50 -0800
From: Tim Morgan <tim-research@sentinelchicken.org>
To: Marsh Ray <marsh@extendedsubset.com>
Message-ID: <20101214171250.GB5009@sentinelchicken.org>
References: <4D02AF81.6000907@stpeter.im> <4D02BDB3.7060801@extendedsubset.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4D02BDB3.7060801@extendedsubset.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Mailman-Approved-At: Wed, 15 Dec 2010 08:03:58 -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] [http-auth] [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: Tue, 14 Dec 2010 17:11:20 -0000
Hi Marsh, > IMHO, authentication just doesn't belong at the HTTP layer. Hmm, can't necessarily disagree there... However, I think having it in the next layer up (POST requests/cookies) is even worse. > 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. HTTP isn't good at being stateful, but it is. One could argue that even just Basic auth alone adds state. Cookies add state, and we have connection state. Ultimately, a non-security form of state management buys a security protocol nothing. I think time and again we have found that relying on insecure underlying state mechanisms in a secure protocol will bring about insecurities. Secure protocols need their own state management independent of the underlying layers. > 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? Agreed. > 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. Right, and this needs to change, IMHO. While I'd love to see lots more adoption of TLS client certificates, I don't think it will ever completely supplant username/password pairs. This is because most people don't understand certificates while everyone understands usernames and passwords. Also, there are some real differences in use cases which will create problems for some sites. > 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? That's pretty much the solution that Yutaka OIWA and the other Mutual auth folks have come up with. You have a protocol over HTTP which mutually guarantees the server and client have the same password without leaking the password (this prevents phishing even if users don't look at the domain name) and this cryptographic process is tied to the TLS server certificate to prevent MitM. Could the same security properties be achieved with TLS and say, SRP? Probably. The hurdle that SRP has is the user interface. Users and web developers are accustomed to being able to build their own login forms. Now that we (the security community) let them get away with this foolishness, we can't really take it away from them again. Very few web developers will give up the ability to build a branded, custom login form just to use something more secure like SRP over TLS. So, how would you go about making it usable with HTML login forms? I'm not sure. What I *have* investigated in the past is the ability to do HTTP authentication with custom HTML login forms. I've found it's not only possible right now, but the tools to do it (XMLHttpRequest, mostly) are becoming standardized in a way that makes it well-defined. So, there we could have a reasonable tradeoff between usability and improved security if we pushed for HTML login forms with Mutual auth. > 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. Yes, exactly. So we've already covered how there are many protocols and protocol frameworks which are secure and integrate well with this, that, or the other backend system. Why aren't these adopted already? It all comes down to how easy it is for web developers to present a "user friendly" login process. I think we have enough good crypto out there. We should focus on how to make that crypto easier to deploy. Regards, tim
- Re: [apps-discuss] HTTP authentication: the next … Mark Nottingham
- [apps-discuss] HTTP authentication: the next gene… Peter Saint-Andre
- Re: [apps-discuss] [saag] HTTP authentication: th… Paul Hoffman
- Re: [apps-discuss] [kitten] HTTP authentication: … Nicolas Williams
- Re: [apps-discuss] [saag] HTTP authentication: th… Henry B. Hotz
- Re: [apps-discuss] [websec] HTTP authentication: … Marsh Ray
- Re: [apps-discuss] [kitten] [saag] HTTP authentic… Josh Howlett
- Re: [apps-discuss] [kitten] [saag] HTTP authentic… Alexey Melnikov
- Re: [apps-discuss] [kitten] [saag] HTTP authentic… Josh Howlett
- Re: [apps-discuss] [kitten] [saag] HTTP authentic… Luke Howard
- Re: [apps-discuss] [kitten] [saag] HTTP authentic… Yaron Sheffer
- Re: [apps-discuss] [saag] HTTP authentication: th… Yoav Nir
- Re: [apps-discuss] [saag] HTTP authentication: th… Yoav Nir
- Re: [apps-discuss] [kitten] [saag] HTTP authentic… Yoav Nir
- Re: [apps-discuss] [kitten] [saag] HTTP authentic… Yoav Nir
- Re: [apps-discuss] [kitten] [saag] HTTP authentic… Alexey Melnikov
- Re: [apps-discuss] [kitten] [saag] HTTP authentic… Eliot Lear
- Re: [apps-discuss] [kitten] [saag] HTTP authentic… Roy T. Fielding
- Re: [apps-discuss] [kitten] [saag] HTTP authentic… Dave Cridland
- Re: [apps-discuss] [kitten] [saag] HTTP authentic… Dave Cridland
- Re: [apps-discuss] [kitten] [saag] HTTP authentic… Eliot Lear
- Re: [apps-discuss] [kitten] [saag] HTTP authentic… Carsten Bormann
- Re: [apps-discuss] [kitten] [saag] HTTP authentic… Eliot Lear
- Re: [apps-discuss] [kitten] [saag] HTTP authentic… Dave Cridland
- Re: [apps-discuss] [websec] HTTP authentication: … Julian Reschke
- Re: [apps-discuss] [kitten] [saag] HTTP authentic… Adrien de Croy
- Re: [apps-discuss] [saag] [kitten] HTTP authentic… Alan DeKok
- Re: [apps-discuss] [websec] [saag] HTTP authentic… Ben Laurie
- Re: [apps-discuss] [kitten] [saag] HTTP authentic… Dave Raggett
- Re: [apps-discuss] [websec] [kitten] [saag] HTTP … Marsh Ray
- Re: [apps-discuss] [kitten] [saag] HTTP authentic… Tim Morgan
- Re: [apps-discuss] [saag] [websec] [kitten] HTTP … Yaron Sheffer
- Re: [apps-discuss] [kitten] [saag] HTTP authentic… Yoav Nir
- Re: [apps-discuss] [websec] [kitten] [saag] HTTP … Yoav Nir
- Re: [apps-discuss] [saag] [websec] [kitten] HTTP … Yoav Nir
- Re: [apps-discuss] [http-auth] [websec] [saag] [k… Henry B. Hotz
- Re: [apps-discuss] [http-auth] [websec] [saag] HT… Henry B. Hotz
- Re: [apps-discuss] [websec] [saag] [kitten] HTTP … Marsh Ray
- Re: [apps-discuss] [kitten] [saag] HTTP authentic… Nicolas Williams
- Re: [apps-discuss] [kitten] [saag] HTTP authentic… Nicolas Williams
- Re: [apps-discuss] [saag] [websec] [kitten] HTTP … Steven Bellovin
- Re: [apps-discuss] [saag] [websec] [kitten] HTTP … John C Klensin
- Re: [apps-discuss] [http-auth] [websec] HTTP auth… Tim Morgan
- Re: [apps-discuss] [saag] [websec] [kitten] HTTP … John C Klensin
- Re: [apps-discuss] [saag] [kitten] HTTP authentic… Joel Jaeggli
- Re: [apps-discuss] [http-auth] [saag] [websec] [k… Marsh Ray
- Re: [apps-discuss] [saag] [websec] [kitten] HTTP … der Mouse
- Re: [apps-discuss] [http-auth] [saag] [websec] [k… der Mouse
- Re: [apps-discuss] [http-auth] [saag] [websec] [k… Tim
- Re: [apps-discuss] [websec] [kitten] [saag] HTTP … Adrien de Croy
- Re: [apps-discuss] [websec] [kitten] [saag] HTTP … Phillip Hallam-Baker
- Re: [apps-discuss] [websec] [kitten] [saag] HTTP … Nathan
- Re: [apps-discuss] [saag] [websec] [kitten] HTTP … Adrien de Croy
- Re: [apps-discuss] [saag] [websec] [kitten] HTTP … Ben Laurie
- Re: [apps-discuss] [saag] [websec] [kitten] HTTP … Ben Laurie
- Re: [apps-discuss] [saag] [websec] [kitten] HTTP … Josh Howlett
- Re: [apps-discuss] [websec] [saag] [kitten] HTTP … Marsh Ray
- Re: [apps-discuss] [saag] [websec] [kitten] HTTP … Jeffrey Hutzelman
- Re: [apps-discuss] [saag] [websec] [kitten] HTTP … Phillip Hallam-Baker
- Re: [apps-discuss] [websec] [kitten] [saag] HTTP … Ben Laurie
- Re: [apps-discuss] [websec] [kitten] [saag] HTTP … David Morris
- Re: [apps-discuss] [kitten] [saag] HTTP authentic… Robert Sayre
- Re: [apps-discuss] [websec] [kitten] [saag] HTTP … Tim
- Re: [apps-discuss] [saag] [websec] [kitten] HTTP … Ben Laurie
- Re: [apps-discuss] [websec] [saag] [kitten] HTTP … Marsh Ray
- Re: [apps-discuss] [saag] [websec] [kitten] HTTP … der Mouse
- Re: [apps-discuss] [saag] [websec] [kitten] HTTP … Phillip Hallam-Baker
- Re: [apps-discuss] [saag] [websec] [kitten] HTTP … Phillip Hallam-Baker
- Re: [apps-discuss] [saag] [websec] [kitten] HTTP … Blaine Cook
- Re: [apps-discuss] [saag] [websec] [kitten] HTTP … Phillip Hallam-Baker
- Re: [apps-discuss] [saag] [websec] [kitten] HTTP … Ben Laurie
- Re: [apps-discuss] [http-auth] [saag] [websec] [k… Marsh Ray
- Re: [apps-discuss] [saag] [websec] [kitten] HTTP … Blaine Cook
- Re: [apps-discuss] [saag] [websec] [kitten] HTTP … Blaine Cook
- Re: [apps-discuss] [saag] [websec] [kitten] HTTP … Ben Laurie
- Re: [apps-discuss] [saag] [websec] [kitten] HTTP … Marsh Ray
- Re: [apps-discuss] [saag] [websec] [kitten] HTTP … Marsh Ray
- Re: [apps-discuss] [saag] [websec] [kitten] HTTP … Theodore Tso