Return-Path: 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 ; 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: References: Date: Sat, 25 Jun 2011 15:43:00 -0400 Message-ID: From: Phillip Hallam-Baker To: Peter Gutmann 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 19:43:02 -0000 --0016e68ee136917d5b04a68e8634 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 14, 2011 at 12:59 AM, Peter Gutmann wrote: > Phillip Hallam-Baker 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/ --0016e68ee136917d5b04a68e8634 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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 t= hat 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:

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


<= /div>
This is orthogonal in that it is really about replacing the two f= actor scheme. But a really good backup for two factor could allow us to add= ress 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, lik= e 128 bit worth of password.


If that type of scheme is used for the 9= 0% 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 sche= me to the accounts and the transactions where it really matters.


=A0
The only permitted auth.form should be a dynamic, cryptographic mutual auth= .
that authenticates both the client and the server. =A0There are endless des= igns
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 completel= y. 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 m= aybe get a critical mass we can leverage.

--0016e68ee136917d5b04a68e8634--