Re: [websec] [saag] [http-auth] re-call for IETF http-auth BoF

Phillip Hallam-Baker <hallam@gmail.com> Sat, 25 June 2011 19:43 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D7611E80EE; Sat, 25 Jun 2011 12:43:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.193
X-Spam-Level:
X-Spam-Status: No, score=-3.193 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGcVhVG5NeYA; Sat, 25 Jun 2011 12:43:01 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4A53211E80C6; Sat, 25 Jun 2011 12:43:01 -0700 (PDT)
Received: by yie30 with SMTP id 30so2200598yie.31 for <multiple recipients>; Sat, 25 Jun 2011 12:43:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MFHdBK32C3XwT8oIhBOB4GMZ4tdBPq24yvGvTqLuBuY=; b=yBzPTU+GMYfQDyt7GV9SCw81lw+d3RYhHGmnt3BWuoUN07Sj5vQJW83Lh3tafBaQt3 F0zeeSfc6SJ7+a+lvArplV9pncBhcgXhgPpwGLx04FgkmaXbnzqSf9uQYlnHaccoVp6f l9/Nf7xZErnnevlA0CQGwNNQCPuBLIc1klkzo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=a5GUIM6oFDC8KbslUUFzr14B79ICtigylmiagvPzDTU6hVFg8KgnwZI7Ri3ARHTyAI 9Ds9X5+UxkrICUuVVISMKI7sICU20NlyM93//00Y0WSov6rS0Zo8+i89lmhxBQtr0JDY JXW8kxJuSszt1Cl2eRkNxK32ShM/A4xqS/JKU=
MIME-Version: 1.0
Received: by 10.101.148.37 with SMTP id a37mr5041806ano.150.1309030980090; Sat, 25 Jun 2011 12:43:00 -0700 (PDT)
Received: by 10.100.111.17 with HTTP; Sat, 25 Jun 2011 12:43:00 -0700 (PDT)
In-Reply-To: <E1QWLjG-0007nd-EG@login01.fos.auckland.ac.nz>
References: <BANLkTi=9TZU=pguCGhLHY+=GbCNjR6w-dA@mail.gmail.com> <E1QWLjG-0007nd-EG@login01.fos.auckland.ac.nz>
Date: Sat, 25 Jun 2011 15:43:00 -0400
Message-ID: <BANLkTimSwF_OHCcVv1wgC-t8nf7A-vJr=A@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Content-Type: multipart/alternative; boundary="0016e68ee136917d5b04a68e8634"
Cc: public-identity@w3.org, http-auth@ietf.org, websec@ietf.org
Subject: Re: [websec] [saag] [http-auth] re-call for IETF http-auth BoF
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Jun 2011 19:43:02 -0000

On Tue, Jun 14, 2011 at 12:59 AM, Peter Gutmann
<pgut001@cs.auckland.ac.nz>wrote:

> Phillip Hallam-Baker <hallam@gmail.com> writes:
>
> >what would we want HTTP authentication to look like?
>
> I have a suggestion for what it shouldn't look like: Any method that hands
> over the password (or a password-equivalent like a password in hashed form)
> as
> current browsers do should be banned outright, and anyone who implements
> hand-over-the-password should killed and eaten to prevent them from passing
> on
> the genes.
>

Take a look at the following draft:
https://tools.ietf.org/html/draft-hallambaker-owcp-00

The basic idea is that putting SecurID type schemes on an iPhone is using a
Deep Blue to play pong.


This is orthogonal in that it is really about replacing the two factor
scheme. But a really good backup for two factor could allow us to address
some of the issues with single factor.

For example, browser generates a strong public keypair, uses same to
authenticate to an 'account management service'. This stores single factor
passwords on behalf of the user. Really big ones, like 128 bit worth of
password.


If that type of scheme is used for the 90% of accounts that don't matter to
me (no really, I don't care who uses my NYT account, only they care) we can
reserve the second factor scheme to the accounts and the transactions where
it really matters.




> The only permitted auth.form should be a dynamic, cryptographic mutual
> auth.
> that authenticates both the client and the server.  There are endless
> designs
> for this sort of thing around so the precise form isn't too important, as
> long
> as it's not hand-over-the-password.
>

Agree completely. But that is not the problem that is blocking us here. The
central issue is how to get deployment and that is hard.

If we could maybe get a toehold on this problem by getting a free
replacement for second factor out there that is also better, we can maybe
get a critical mass we can leverage.


-- 
Website: http://hallambaker.com/