From benl@google.com Thu Jan 6 08:21:05 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DD9E3A6D79 for ; Thu, 6 Jan 2011 08:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.542 X-Spam-Level: X-Spam-Status: No, score=-103.542 tagged_above=-999 required=5 tests=[AWL=-1.566, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 yNBshy-py1n6 for ; Thu, 6 Jan 2011 08:21:04 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 672203A6C2F for ; Thu, 6 Jan 2011 08:21:03 -0800 (PST) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id p06FVrS6028006 for ; Thu, 6 Jan 2011 07:31:54 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294327914; bh=UP69RRHWGGYUU/4X7jvHl3J8mX4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=u8nc7/xQZ+AARX/yPFSLYnoxdm3MNriL6XXSM3oYTi9uTzHemKJl8EeU6i0qQkJCF DTLfKTFQS5p8DHzPhqxoA== Received: from qyk8 (qyk8.prod.google.com [10.241.83.136]) by kpbe14.cbf.corp.google.com with ESMTP id p06FUSJg007119 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 6 Jan 2011 07:31:52 -0800 Received: by qyk8 with SMTP id 8so17268430qyk.6 for ; Thu, 06 Jan 2011 07:31:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=4HF7vbiBG5YS3CoUX9wu70DOSHl4iLZrUnsX4DNBd8w=; b=BWKqmSdEvTDeyQ2eqttv3+gBNEmZ8ZTujH6HL3DADxzsmbBUAlcazFi9amXmpe/stX C8Xwy0FBWlv0jfqgUknQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hH30kqLSSKa1ZEPU9Hu/va/17y7O5RquFN4F2cWEnZwLtv6zPxOQENUmecs1T29R8b EpxWBDsyopxO1loOVpOQ== MIME-Version: 1.0 Received: by 10.229.215.135 with SMTP id he7mr2980674qcb.104.1294327911945; Thu, 06 Jan 2011 07:31:51 -0800 (PST) Received: by 10.220.88.137 with HTTP; Thu, 6 Jan 2011 07:31:51 -0800 (PST) In-Reply-To: References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> Date: Thu, 6 Jan 2011 15:31:51 +0000 Message-ID: From: Ben Laurie To: Robert Sayre Content-Type: multipart/alternative; boundary=00163630f5376a161c04992f33be X-System-Of-Record: true Cc: "apps-discuss@ietf.org" , "Roy T. Fielding" , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [http-auth] [websec] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 16:21:05 -0000 --00163630f5376a161c04992f33be Content-Type: text/plain; charset=ISO-8859-1 On 6 January 2011 01:28, Robert Sayre wrote: > > Peter Saint-Andre wrote: > > 2. In 2007, Robert Sayre put together a few slides on the topic: > > http://people.mozilla.com/~sayrer/2007/auth.html > > These are back on the Web, in case anyone missed them (probably not). > > On Sun, Dec 12, 2010 at 5:39 PM, Roy T. Fielding > wrote: > > > > Define them all and let's have a bake-off. It has been 16 years since > > HTTP auth was taken out of our hands so that the security experts could > > define something perfect. Zero progress so far. > > I think the IETF might do better to focus on a smaller problem, at > first. People often use self-signed certificates with HTTP/TLS, even > though the first thing their websites ask the user to do is type a > username and password into a form. There are some well-understood ways > to make this process more secure. Why hasn't the IETF fixed this > problem? If this smaller problem has no ready solution, then the > larger issue of authentication on the entire Web seems like a tough > nut to crack. > Two comments (one really being a response to Roy): 1. The IETF has fixed the problem, but no-one is using the fix - perhaps because it is not clear that it is the fix. I speak of RFC 4279, TLS pre-shared keys. These could be derived from a hash of the password and the site name, for example, and thus provide secure mutual authentication despite password reuse. 2. I have often heard (though I am not aware of hard evidence for this, nevertheless I find it plausible) that one reason no-one has bothered to improve HTTP auth is because no-one would use it since site owners want to control the user experience around signin. It seems to me, therefore, that HTTP is the wrong layer to fix the problem at - it needs to be pushed down into HTML or Javascript so that the page can control the look, while appropriate HTML elements or JS code can deal with the secure exchange of data. Of course, this still leaves the issue of trusted path: although we can provide elements which are safe to use, even when being phished, how does the user know those elements are actually being used, rather than simulated so as to get hold of the underlying password? The answer to this problem is hard, since it brings us back to taking the UI out of the sites hands. > It could be that the reasons for this lack of progress are > nontechnical. Just throwing that out there. > If you think UI is nontechnical, then I agree. Cheers, Ben. --00163630f5376a161c04992f33be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 6 January 2011 01:28, Robert Sayre <sayrer@gmail.com> wrote:
> Peter Saint-Andre <stpeter@stpeter.im> wrote:
> 2. In 2007, Robert Sayre put together a few slides on the topic:
> http://people.mozilla.com/~sayrer/2007/auth.html

These are back on the Web, in case anyone missed them (probably not).=

On Sun, Dec 12, 2010 at 5:39 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
>
> Define them all and let's have a bake-off. =A0It has been 16 years= since
> HTTP auth was taken out of our hands so that the security experts coul= d
> define something perfect. =A0Zero progress so far.

I think the IETF might do better to focus on a smaller problem, at
first. People often use self-signed certificates with HTTP/TLS, even
though the first thing their websites ask the user to do is type a
username and password into a form. There are some well-understood ways
to make this process more secure. Why hasn't the IETF fixed this
problem? If this smaller problem has no ready solution, then the
larger issue of authentication on the entire Web seems like a tough
nut to crack.

Two comments (one really = being a response to Roy):

1. The IETF has fixed th= e problem, but no-one is using the fix - perhaps because it is not clear th= at it is the fix. I speak of RFC 4279, TLS pre-shared keys. These could be = derived from a hash of the password and the site name, for example, and thu= s provide secure mutual authentication despite password reuse.

2. I have often heard (though I am not aware of hard ev= idence for this, nevertheless I find it plausible) that one reason no-one h= as bothered to improve HTTP auth is because no-one would use it since site = owners want to control the user experience around signin. It seems to me, t= herefore, that HTTP is the wrong layer to fix the problem at - it needs to = be pushed down into HTML or Javascript so that the page can control the loo= k, while appropriate HTML elements or JS code can deal with the secure exch= ange of data.

Of course, this still leaves the issue of trusted path:= although we can provide elements which are safe to use, even when being ph= ished, how does the user know those elements are actually being used, rathe= r than simulated so as to get hold of the underlying password?

The answer to this problem is hard, since it brings us = back to taking the UI out of the sites hands.

=A0<= /div>
It could be that the reasons for this lack of progress are
nontechnical. Just throwing that out there.

=
If you think UI is nontechnical, then I agree.

Cheers,

Ben.

--00163630f5376a161c04992f33be-- From tim-projects@sentinelchicken.org Thu Jan 6 08:30:35 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6C623A6C4F for ; Thu, 6 Jan 2011 08:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=-0.275, 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 IRuAJlf+VtA3 for ; Thu, 6 Jan 2011 08:30:35 -0800 (PST) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by core3.amsl.com (Postfix) with ESMTP id 5EF023A6E25 for ; Thu, 6 Jan 2011 08:30:35 -0800 (PST) Received: (qmail 3322 invoked from network); 6 Jan 2011 16:28:47 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 6 Jan 2011 16:28:47 -0000 Received: (qmail 23661 invoked from network); 6 Jan 2011 16:29:18 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 6 Jan 2011 16:29:18 -0000 Received: (nullmailer pid 15198 invoked by uid 1000); Thu, 06 Jan 2011 16:25:59 -0000 Date: Thu, 6 Jan 2011 08:25:59 -0800 From: Tim To: Ben Laurie Message-ID: <20110106162559.GQ6792@sentinelchicken.org> References: <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "apps-discuss@ietf.org" , "Roy T. Fielding" , websec , Robert Sayre , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [http-auth] [websec] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 16:30:35 -0000 > 1. The IETF has fixed the problem, but no-one is using the fix - perhaps > because it is not clear that it is the fix. I speak of RFC 4279, TLS > pre-shared keys. These could be derived from a hash of the password and the > site name, for example, and thus provide secure mutual authentication > despite password reuse. > > 2. I have often heard (though I am not aware of hard evidence for this, > nevertheless I find it plausible) that one reason no-one has bothered to > improve HTTP auth is because no-one would use it since site owners want to > control the user experience around signin. It seems to me, therefore, that > HTTP is the wrong layer to fix the problem at - it needs to be pushed down > into HTML or Javascript so that the page can control the look, while > appropriate HTML elements or JS code can deal with the secure exchange of > data. Yes, the user experience piece is definitely the biggest adoption problem for HTTP auth, IMO. However, I disagree that HTTP is the wrong layer. It has already been shown (by myself and others) that using HTTP authentication and controlling the user experience can largely be achieved already. A few tweaks to browser 401 response behavior (which doesn't require standards changes) and the ability for servers to force a log out are all that's left to provide to make this reliable. As for RFC 4279, I'm not really familiar with it, but I imagine the mechansims which allow for user experience customization right now with HTTP auth could easily be extended to any TLS authentication mechansim. The only requirement there would be to add some simple language allowing for this behavior in [1]. That is, allow XMLHttpRequest objects to hand the credentials they already accept off to the TLS layer, either for RFC 4279 or for SRP/TLS. > Of course, this still leaves the issue of trusted path: although we can > provide elements which are safe to use, even when being phished, how does > the user know those elements are actually being used, rather than simulated > so as to get hold of the underlying password? > > The answer to this problem is hard, since it brings us back to taking the UI > out of the sites hands. Yes, so what I've outlined above and elsewhere is a relatively simple transition path to allow adoption of better authentication standards with customizable user interfaces. But those are problematic by design. However, I'd assert that moving web applications off of cookies to some lower-layer mechanism is going to be a required first step in order to provide authentication prompts that are part of the browser, for those who need that security. tim 1. http://www.w3.org/TR/XMLHttpRequest/ From mouse@Sparkle.Rodents-Montreal.ORG Thu Jan 6 10:39:24 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CD5F3A6F43; Thu, 6 Jan 2011 10:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.792 X-Spam-Level: X-Spam-Status: No, score=-8.792 tagged_above=-999 required=5 tests=[AWL=1.196, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] 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 PImVhi95MZYY; Thu, 6 Jan 2011 10:39:23 -0800 (PST) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id CF3113A6F3A; Thu, 6 Jan 2011 10:39:22 -0800 (PST) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id NAA23900; Thu, 6 Jan 2011 13:35:40 -0500 (EST) Date: Thu, 6 Jan 2011 13:35:40 -0500 (EST) From: der Mouse Message-Id: <201101061835.NAA23900@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Thu, 6 Jan 2011 13:19:53 -0500 (EST) To: apps-discuss@ietf.org, websec@ietf.org, kitten@ietf.org, http-auth@ietf.org, saag@ietf.org, ietf-http-wg@w3.org In-Reply-To: <4D0E8148.7060607@extendedsubset.com> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.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> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <2229.1292253372.639419@puncture> <4D0DE882.50201@qbik.com> <4D0E8148.7060607@extendedsubset.com> Subject: Re: [http-auth] [saag] [websec] [apps-discuss] [kitten] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 18:39:24 -0000 > Look back far enough and you'll find all kinds of "electronic mail" > services implementing the full range of peer and end user > authentication, and sender-pays models. There was no spam on those > systems, or at least not enough that anyone felt like they needed a > word for it. There was basically no spam on open-Internet SMTP mail either, at the time. Certainly "no spam" by today's standards. > Guess why we use the one we use today. At the time, the services you deride weren't providing a significant value-add. Today? They would be. Perhaps not enough to make up for their costs; probably not, in fact, or there'd be businesses arising in that space. As a side note, it's interesting to see how well the early Internet designers built; their systems are routinely being stressed several orders of magnitude beyond what they were designed for, and are holding up remarkably well. The postal system did collapse when it started suffering from spam; that's why the paper chain mail is actually illegal in many jurisdictions - it took down the postal system, once upon a time. The telphone system would collapse if phone spam outnumbered real calls by 10, 25, 100 to 1. (Actually, in a sense they already do. I have a fax line set up, and get dozens of fax spams for every real fax. I've had to start adapting and applying my email spam fighting techniques there....) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From benl@google.com Thu Jan 6 10:45:09 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 473033A6F3C for ; Thu, 6 Jan 2011 10:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.319 X-Spam-Level: X-Spam-Status: No, score=-103.319 tagged_above=-999 required=5 tests=[AWL=-1.342, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 407DaCktdpX0 for ; Thu, 6 Jan 2011 10:45:08 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id E1FB23A6F4D for ; Thu, 6 Jan 2011 10:45:05 -0800 (PST) Received: from kpbe13.cbf.corp.google.com (kpbe13.cbf.corp.google.com [172.25.105.77]) by smtp-out.google.com with ESMTP id p06IGHHs002694 for ; Thu, 6 Jan 2011 10:16:18 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294337778; bh=tOrSd+BaLDGYpH9HsyVCcafu+oA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=nhcwIisUO7oAkg66A8rDBAHv5zLtVTeKxgwhQrGOkd1tM+8dUs0mMmYzkOc12BMsQ vRwjIWFLBdC/r+miufS3g== Received: from qyk34 (qyk34.prod.google.com [10.241.83.162]) by kpbe13.cbf.corp.google.com with ESMTP id p06IBfAx019581 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 6 Jan 2011 10:16:16 -0800 Received: by qyk34 with SMTP id 34so18859077qyk.10 for ; Thu, 06 Jan 2011 10:16:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ztYKyBRdnEWKJBsTrbql2FglzmqVhvAw6IaIUfdkB7w=; b=BxXEavN29UHyrsu3lhFh4wtPxqyyfTe7rbvsAK9O9yU8bnoEzoceDOSlCK6QPcd3dG ll62XjLsoR18WS0HmO5Q== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FCRb0q97ppk3nPf0vWscaA0RV1zaAaw54FU7Dt4Ih57ZFclnJC0C5VptKxZu+gFzH7 b9AIO/Z0ax7qhwFKRnlQ== MIME-Version: 1.0 Received: by 10.229.215.135 with SMTP id he7mr3108759qcb.104.1294337776341; Thu, 06 Jan 2011 10:16:16 -0800 (PST) Received: by 10.220.88.137 with HTTP; Thu, 6 Jan 2011 10:16:15 -0800 (PST) In-Reply-To: References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> Date: Thu, 6 Jan 2011 18:16:15 +0000 Message-ID: From: Ben Laurie To: David Morris Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "apps-discuss@ietf.org" , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [http-auth] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 18:45:09 -0000 On 6 January 2011 16:03, David Morris wrote: > > > On Thu, 6 Jan 2011, Ben Laurie wrote: > >> The answer to this problem is hard, since it brings us back to taking the UI >> out of the sites hands. > > Which is only helpful if you can somehow gaurantee that the user agent > software hasn't been compromised. Not something I'd bet on... That's rather overstating it. It's perfectly helpful when the UA software hasn't been compromised, which is a non-zero fraction of the time. When the UA s/w has been compromised I'm quite happy to fail to fix the problem: the right answer to that is to improve the robustness of the UA. From marsh@extendedsubset.com Thu Jan 6 11:49:53 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25C8F3A6F34; Thu, 6 Jan 2011 11:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 5IsN4qZgy7XQ; Thu, 6 Jan 2011 11:49:50 -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 601543A6D06; Thu, 6 Jan 2011 11:49:50 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1PavsL-0007lR-0x; Thu, 06 Jan 2011 19:51:57 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 7DDDC603D; Thu, 6 Jan 2011 19:51:54 +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: U2FsdGVkX19YqhOZiaovwLDZ2QqifW+U3NXa/nAN2Ec= Message-ID: <4D261D59.9010405@extendedsubset.com> Date: Thu, 06 Jan 2011 13:51:53 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: der Mouse References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.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> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <2229.1292253372.639419@puncture> <4D0DE882.50201@qbik.com> <4D0E8148.7060607@extendedsubset.com> <201101061835.NAA23900@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <201101061835.NAA23900@Sparkle.Rodents-Montreal.ORG> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org, websec@ietf.org, kitten@ietf.org, http-auth@ietf.org, saag@ietf.org, ietf-http-wg@w3.org Subject: Re: [http-auth] [websec] [saag] [apps-discuss] [kitten] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 19:49:54 -0000 On 01/06/2011 12:35 PM, der Mouse wrote: >> Look back far enough and you'll find all kinds of "electronic mail" >> services implementing the full range of peer and end user >> authentication, and sender-pays models. There was no spam on those >> systems, or at least not enough that anyone felt like they needed a >> word for it. > > There was basically no spam on open-Internet SMTP mail either, at the > time. Certainly "no spam" by today's standards. > >> Guess why we use the one we use today. > > At the time, the services you deride weren't providing a significant > value-add. I wasn't so much deriding them but saying there were points all over the trade-off curve and the market voted with its feet. Unambiguously. Of course, the marketing creeps followed. > Today? They would be. Perhaps not enough to make up for their costs; > probably not, in fact, or there'd be businesses arising in that space. There are plenty. It's a commoditized low-margin business these days. But the network infrastructure costs are not nearly the biggest cost once you factor in things like end-user support. E.g. http://www.google.com/search?q=hosted+vpn It occurred to me last night that one might recreate the good old days of the Internet with a VPN which allowed access to the good old folks who were on it back then. Sounds a little crass and elitist now that I propose it out loud. But imagine a global authenticated VPN where the only reason you could be banned is for spamming? Or one where you had to be at a university CS department? Or a whole set of overlapping criteria and you could choose what the membership criteria for your own view of the network? Your own personal Virtual Public Internet. > As a side note, it's interesting to see how well the early Internet > designers built; their systems are routinely being stressed several > orders of magnitude beyond what they were designed for, and are holding > up remarkably well. It is amazing, isn't it? > The postal system did collapse when it started > suffering from spam; that's why the paper chain mail is actually > illegal in many jurisdictions - it took down the postal system, once > upon a time. Nice. > The telphone system would collapse if phone spam > outnumbered real calls by 10, 25, 100 to 1. (Actually, in a sense they > already do. I have a fax line set up, and get dozens of fax spams for > every real fax. I've had to start adapting and applying my email spam > fighting techniques there....) We get so many unsolicited calls from telemarketers and robot dialers at home we don't answer the phone unless we recognize the caller ID. Sometimes family calling from roaming cell phones show up as 'unidentified caller' and we mistakenly don't answer. How much more broken can it be? - Marsh From travis+ml-http-auth@subspacefield.org Thu Jan 6 12:12:46 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D61B3A6C9B for ; Thu, 6 Jan 2011 12:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 J1JI5CqAPxjT for ; Thu, 6 Jan 2011 12:12:44 -0800 (PST) Received: from nexus.subspacefield.org (nexus.subspacefield.org [64.156.192.208]) by core3.amsl.com (Postfix) with ESMTP id B474E3A6DF5 for ; Thu, 6 Jan 2011 12:12:44 -0800 (PST) Received: by nexus.subspacefield.org (Postfix, from userid 1001) id 6B8A3234CD1; Thu, 6 Jan 2011 12:14:51 -0800 (PST) Date: Thu, 6 Jan 2011 12:14:51 -0800 From: travis+ml-http-auth@subspacefield.org To: http-auth@ietf.org Message-ID: <20110106201451.GA973@subspacefield.org> Mail-Followup-To: http-auth@ietf.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aVD9QWMuhilNxW9f" Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [http-auth] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 20:14:14 -0000 --aVD9QWMuhilNxW9f Content-Type: multipart/mixed; boundary="k1lZvvs/B4yU6o8G" Content-Disposition: inline --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This (attached) was sent to the wrong IETF HTTP auth mlist. :-) (BTW, couldn't find this one through google, the other one turns up as hit #1) --=20 Good code works on most inputs; correct code works on all inputs. My emails do not have attachments; it's a digital signature that your mail program doesn't understand. | http://www.subspacefield.org/~travis/=20 If you are a spammer, please email john@subspacefield.org to get blackliste= d. --k1lZvvs/B4yU6o8G Content-Type: message/rfc822 Content-Disposition: inline Return-Path: X-Label: travis+ml-http-auth@subspacefield.org Delivered-To: travis+ml-http-auth@subspacefield.org Received: from sexus.bitrot.info (sexus.bitrot.info [94.75.255.70]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by nexus.subspacefield.org (Postfix) with ESMTPS id B4250234C2B for ; Wed, 5 Jan 2011 16:22:07 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by sexus.bitrot.info (Postfix) with ESMTP id E8D3D1D01538 for ; Wed, 5 Jan 2011 16:22:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 2B1B53E00EB; Wed, 5 Jan 2011 16:21:53 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4y4Jza3F8Q7z; Wed, 5 Jan 2011 16:21:52 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 8349C3E0112; Wed, 5 Jan 2011 16:21:47 -0800 (PST) Delivered-To: ietf-http-auth@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 74F413E0112 for ; Wed, 5 Jan 2011 16:21:44 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4HT7otsTrp3 for ; Wed, 5 Jan 2011 16:21:40 -0800 (PST) Received: from nexus.subspacefield.org (nexus.subspacefield.org [64.156.192.208]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTPS id AC0123E00EB for ; Wed, 5 Jan 2011 16:21:40 -0800 (PST) Received: by nexus.subspacefield.org (Postfix, from userid 1001) id A9C12234C7E; Wed, 5 Jan 2011 16:21:39 -0800 (PST) Date: Wed, 5 Jan 2011 16:21:39 -0800 From: travis+ml-http-auth@subspacefield.org To: ietf-http-auth@osafoundation.org Message-ID: <20110106002139.GA28053@subspacefield.org> Mail-Followup-To: ietf-http-auth@osafoundation.org MIME-Version: 1.0 User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [ietf-http-auth] HTTP authentication: the next generation X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1690496666==" Sender: ietf-http-auth-bounces@osafoundation.org Errors-To: ietf-http-auth-bounces@osafoundation.org --===============1690496666== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I second everything that Marsh Ray said in this thread (at least, what he said on websec; I wasn't subbed here at the time). Specifically, HTTP digest was better than basic, but still had a problem with replay attacks, since HTTP is stateless. I discussed this a little he= re: http://www.subspacefield.org/security/security_concepts/index.html#tth_sEc2= 8.6.4 If you understand why a PGP-encrypted email could be sent again, you understand why HTTP Digest auth could, also. Another point; if you can memorize or comfortably enter a secret, it's not secure against many attacks: http://www.subspacefield.org/security/security_concepts/index.html#tth_sEc3= 6.5 In some cases, you can detect an online attack and therefore use a shorter secret, but really, relying on the server admin to implement this is not a very reliable strategy; no matter how good an idea it is, most people won't implement it, because the system works without it, and most people stop putting in effort when the system works. (Probably ZKPs don't have this problem, but that's another discussion). Finally, unless you're using PK, then the server has the secret you're using to authenticate, or its equivalent (if you e.g. hash a password before sending it over the wire). In most cases, this is a bad thing; it can allow the server (operator, or anyone who pwns it) to pretend to be the client, and if the customer used the password elsewhere, it could be used to impersonate them there. You might be tempted to think that combining it with the domain name (etc.) might help, but unless the client automatically does that BEFORE sending it to the server initially, it can be captured on TOFU. Same deal with password hashing and resistance-to-offline-cracking strategies - it has to be sent to the server, and unless the protocol defines how the server does this, and the client software does it once before sending it to the server, then generally the customer ends up sending the secret en clair on time of first use. IMHO, any login stuff has to be in the browser chrome. As Carsten Borman pointed out, anything in the web page can be spoofed. What we need is the output analog of the "secure attention" key, where the site can't spoof it. Marsh mentioned the secure attention key (ctl-alt-del) in NT through Vista, but it of course existed in other systems: https://secure.wikimedia.org/wikipedia/en/wiki/Secure_attention_key http://www.mjmwired.net/kernel/Documentation/SAK.txt And, whatever we use in the chrome has to become ubiquitous enough that absence of it makes people pause. This will take a while, but it means that we have to get it right the first time, because security is already too complicated for many users. I'm not sure where I heard the idea (I'd like a URL or reference), but I think what we need, if we need users to do anything to be secure, it should be a clear, simple, well-defined security ritual that they can perform each and every time. We need rituals because we need to have a simple answer to the question "what do I need to do to make sure I'm secure?" (in the context of your use case). If we can't answer that question with a clear ritual or (ideally) "you are secure by default", we have failed at security usability. --=20 Good code works on most inputs; correct code works on all inputs. My emails do not have attachments; it's a digital signature that your mail program doesn't understand. | http://www.subspacefield.org/~travis/=20 If you are a spammer, please email john@subspacefield.org to get blackliste= d. --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (OpenBSD) iQIcBAEBAgAGBQJNJQsTAAoJEGQVZZEDJt9H22UP/1H/WL+MAU8CYniCs5eIs8/d exOLsC1B5Xo/37jOLElMdhsDQkIA6IvXYdeUfGmf8Icj35DfXhC78oz7yzNBMYFI LH8U1l2ZZwY1XLEM9mQIVupzoxglBGq8dXvAzj8WeUAfip1W2M70Hsoy7neDtKp0 /QXxvKyEiVVqlPrAzwFlPGheVMxBYrXJTRnscdYaFN3f21UXLdcYjtTT8G3/ngbl Du2elzkpw85xcgRXoslin1DVSEUMw47v1ylGldd+8zdtyT2wkxHu+wl70mXIRdzg 49MhYrm1Y/7gq/1W8Mkl9g2rNHLleccSLqIWLN+mxGOzcDm647RbGtbzi4WIFBhH XN3feRBw6wUKTDDBcEbJQCxj7rUThwrFGLze8uPOSnJbLa4X8y34QW9MymaDL3Dz Hke4lTtaL2mmFbl4tyHOUFxGh2weXCyi2FpC+PXowK4Rjso6KHzQhIYrqyCQTsFV 5V6d8IHTva+RvtkCzqSNVjvx+AZ+jy12Q6myryf8xKwYf9ixkXNDkiCJAF6AvHw2 HXzLEGo4uxAziQNvdjTtn/REkIWh1hHROazp/Hb/z7N7LJBkWEU5MXSiz0lW1EJ0 qth6EjvByqvRfdvIdUWND8G/uIrplZL6TdV0jPaXWP/d6UP9ln1oA8m3/x8pY4oI vi8lwERfirFPUKjmps7T =8joH -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q-- --===============1690496666== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ietf-http-auth mailing list ietf-http-auth@osafoundation.org http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth --===============1690496666==-- --k1lZvvs/B4yU6o8G-- --aVD9QWMuhilNxW9f Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (OpenBSD) iQIcBAEBAgAGBQJNJiK6AAoJEGQVZZEDJt9HSTcQAJnTiDaDXTIcfYT5WB1TuUrA SgVs7+4wjxAshDquUBlLjfPKeSL3GxRZ95EaZ+CJVmLhbMzgI9FL46y3NayvUiMp hHfjtHxgdAp+PxmHy3diblGTU9YoXKmLdblzpfjZbX5XdQm7IQP+i2f6JuBiadze CQYBtQjX351OS+krU6ZIro8aSfXIyjhwKX5S9LyiBQofNrUSksNfIlyyVNOyoWfz bHo9LVZRlkatbftwOej8PJX9lpUmzxNMD77agIonSGtWJcWbouknc/k+5z329DBL L9PMgc2/e3kVU3jaNugSx+JOLwBZ0+N7IPB8JOymiE53xRsp3yS1VS9mI8XoA+O9 fWFgGbCqAXOG+D91XVHxzZjnFjrve0NvbQH8axT3cm1011mQRANTxwtKxQ7FqtLZ hhK+9orOEoreYetsL/ORED0qBtN5VGHrHXJ0O3+Wh+x2YLD4hwKCsphb3pPTxKiR Iw102qry9ZVmjlWCi12w71stEEIGaxsWqWFbuBqPyBoA/CiQaWD0Xu//2WKIKPwR gc5qTrtU8n9/XfCZ1ldfnWojsRhLUg6MeFCPKxXbK10N9Og+wHQVbvJUePHwjxeL 28EqV5kJAU7v8bG9XfRqAUAPwv4ywuqZhoocHe6HRrbGlvIBtY+pJkZN2hrJ0Fjj 4PWY9uvvMhqmDnBQelcU =mnWJ -----END PGP SIGNATURE----- --aVD9QWMuhilNxW9f-- From travis+ml-http-auth@subspacefield.org Thu Jan 6 14:12:40 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 336CA3A6F60 for ; Thu, 6 Jan 2011 14:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 QGUP-KEsJFc3 for ; Thu, 6 Jan 2011 14:12:39 -0800 (PST) Received: from nexus.subspacefield.org (nexus.subspacefield.org [64.156.192.208]) by core3.amsl.com (Postfix) with ESMTP id 396923A6B9E for ; Thu, 6 Jan 2011 14:12:39 -0800 (PST) Received: by nexus.subspacefield.org (Postfix, from userid 1001) id 1F069234CD1; Thu, 6 Jan 2011 14:14:45 -0800 (PST) Date: Thu, 6 Jan 2011 14:14:44 -0800 From: travis+ml-http-auth@subspacefield.org To: http-auth@ietf.org Message-ID: <20110106221444.GB3802@subspacefield.org> Mail-Followup-To: http-auth@ietf.org References: <20110106201451.GA973@subspacefield.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ftEhullJWpWg/VHq" Content-Disposition: inline In-Reply-To: <20110106201451.GA973@subspacefield.org> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [http-auth] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 22:12:40 -0000 --ftEhullJWpWg/VHq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable BTW, something may be off with this mailman. I got a message with my post, saying I wasn't subscribed, a few minutes after I got a confirmation email saying that I was. Both were delievered to the same alias. I also haven't seen anything here since subscribing but perhaps I'm jumping the gun.... it has only been 2 hours. --=20 Good code works on most inputs; correct code works on all inputs. My emails do not have attachments; it's a digital signature that your mail program doesn't understand. | http://www.subspacefield.org/~travis/=20 If you are a spammer, please email john@subspacefield.org to get blackliste= d. --ftEhullJWpWg/VHq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (OpenBSD) iQIbBAEBAgAGBQJNJj7UAAoJEGQVZZEDJt9HWYEP+LpumeHpfifdUmuqTe/XG6jQ 4eRP+4uCANVsgs0DPwNyc+sf/a/K7VQmgXs7KIfvooVPTw6lmYOhcv047VNaYp8G OP1R5ZwXJ3ZJyUNPykip7O9l8RYSOKs5vSRdb7WNxzuF8DGjFPRaRKieR/2hStyH lzw1M3lQ5fIIeC20kh5sN+EnPw9NkbJGV6MOwQ+TMpmSMMWqPgtEyiXGIC6bDaL2 94x6rjpowMJ7t41K0hiFwg84wXnGij9mA8GBmhexbMJsgT3fpkPWM4Kf6zXyuizO lbsrNmCkONd2HyG077Qe8NSAhJNIBXYCemoTtMFOPWjQmkLwl10KAlUEsni50us/ AxJ0pqHJxgBnulIGVrgK6USMOsaEzPEzMdZIpfvSTMTQFQ+G4FM8b9k5nI/2FOq+ Mc5lrxBjPWUjpXeNw9mBcrsa+aTb8AcV85g7krdru+zB9A12JMNYI3o3AZqsp7ei cwhQhIKfGmq7FGmrgzEOdn0aNKh720zVaIORarwWv8rRBYcW17X826XzKtapIKnc lgnwsTf4vcDxCyVupOX0R3qPi51yrRZ47DeMDaO4/0hqaMgytRS+Sipt/ivcAhHB YLX7oxh3CtzGhG4kRZxUnNVA8rl9SeneBuRZx5xZrpsAtAjAFCzvtEbTXCGyBjTg xfIENfMWu+I1Zn0I0+Q= =onDO -----END PGP SIGNATURE----- --ftEhullJWpWg/VHq-- From yaronf.ietf@gmail.com Fri Jan 7 00:22:22 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D19753A67DF; Fri, 7 Jan 2011 00:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 uhJL-wf+X3uj; Fri, 7 Jan 2011 00:22:22 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 51F4F3A67AC; Fri, 7 Jan 2011 00:22:21 -0800 (PST) Received: by wyf23 with SMTP id 23so18048837wyf.31 for ; Fri, 07 Jan 2011 00:24:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=bvz62BK4fx12WA6hU/WbK/IYmXIVZb/p3SDFBYoNc2U=; b=MDF1aMuJ4Y+z/44T285Lxq9VULCvQ5CayDkxd8BuJrL0W7HkQTcmju1SaI/rucgQ+B wkV05oOcnKG3HFzYxy3KdqSPAHJm2TTLOuDbTTZJFl2oMu8+CVmxx7LQS3j07BleCN19 G6W1OCki2WtDoivXxeGMBu00nWlUrX/OVy54E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=BBbgYNF5bKC3+tM3USxnTgL3ULhBA74Su7NC7uoQIFG7kEEOQY8jktEkQvQr0jAjeL DUAqJeoPIzR7wjaz3aSh5Oj5MQaEF1iCfvMXLRSwPRb2VCrDzJf+FPe8NuTEA49AB7nw ecJpb0G75tPhHMUzvtUYUEmQxEkYuX/6JKwxo= Received: by 10.227.144.9 with SMTP id x9mr5823639wbu.103.1294388666421; Fri, 07 Jan 2011 00:24:26 -0800 (PST) Received: from [10.0.0.6] (bzq-109-67-17-212.red.bezeqint.net [109.67.17.212]) by mx.google.com with ESMTPS id q18sm17451343wbe.5.2011.01.07.00.24.23 (version=SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 00:24:24 -0800 (PST) Message-ID: <4D26CDB5.3090303@gmail.com> Date: Fri, 07 Jan 2011 10:24:21 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ben Laurie References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Roy T. Fielding" , websec , Robert Sayre , "kitten@ietf.org" , "http-auth@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [http-auth] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 08:22:22 -0000 [Culling down the mailing lists] Hi Ben, No, RFC 4279 should not be used with (a hash of) human-memorable passwords, because it would be vulnerable to dictionary attacks. See http://tools.ietf.org/html/rfc4279#section-7.2. SRP, EKE and similar schemes should be used instead. Thanks, Yaron On 01/06/2011 05:31 PM, Ben Laurie wrote: [...] > > > Two comments (one really being a response to Roy): > > 1. The IETF has fixed the problem, but no-one is using the fix - perhaps > because it is not clear that it is the fix. I speak of RFC 4279, TLS > pre-shared keys. These could be derived from a hash of the password and > the site name, for example, and thus provide secure mutual > authentication despite password reuse. > [...] From benl@google.com Fri Jan 7 04:12:28 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A9513A682E for ; Fri, 7 Jan 2011 04:12:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.495 X-Spam-Level: X-Spam-Status: No, score=-104.495 tagged_above=-999 required=5 tests=[AWL=-1.518, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 fAGV0rbzvQJZ for ; Fri, 7 Jan 2011 04:12:27 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 4E51F3A6802 for ; Fri, 7 Jan 2011 04:12:27 -0800 (PST) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p07CEXt6027575 for ; Fri, 7 Jan 2011 04:14:33 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294402473; bh=ddHvYbpx8oj/DZTucKUBMRlo1fk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=NA+o30SZZZrxn4pTKBr5PZjXgY7BWmbJqDRSQlN0ritYnEu1pibGDGVh2JCDvd9Gp roFP03pkeghjRu8pDePRg== Received: from qyk33 (qyk33.prod.google.com [10.241.83.161]) by wpaz9.hot.corp.google.com with ESMTP id p07CEJkI013925 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 7 Jan 2011 04:14:32 -0800 Received: by qyk33 with SMTP id 33so17813748qyk.16 for ; Fri, 07 Jan 2011 04:14:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tilmeHWzg1zhUdTg75BSgKYV8NkD8UASZdZvrU93zak=; b=LMMXaIfCReiFZpuNn9QVdkdKdYnjIxOU22yQIS4W/asj9CYD4e4gbNZnYQxo+ekrdn 8FGii/ktL/OIvFEceOgA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LyjWj531N7H6aMeY0ZWVwuiSjteRmHAQORR8gGhS9KvvJ1rdlrTjZSRnyFCWqlUDHH YWH9D0/2l15l38TOUk0g== MIME-Version: 1.0 Received: by 10.229.95.11 with SMTP id b11mr22299686qcn.28.1294402472260; Fri, 07 Jan 2011 04:14:32 -0800 (PST) Received: by 10.220.88.137 with HTTP; Fri, 7 Jan 2011 04:14:32 -0800 (PST) In-Reply-To: <4D26CDB5.3090303@gmail.com> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <4D26CDB5.3090303@gmail.com> Date: Fri, 7 Jan 2011 12:14:32 +0000 Message-ID: From: Ben Laurie To: Yaron Sheffer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "Roy T. Fielding" , websec , Robert Sayre , "kitten@ietf.org" , "http-auth@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [http-auth] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 12:12:28 -0000 On 7 January 2011 08:24, Yaron Sheffer wrote: > [Culling down the mailing lists] > > Hi Ben, > > No, RFC 4279 should not be used with (a hash of) human-memorable password= s, > because it would be vulnerable to dictionary attacks. See > http://tools.ietf.org/html/rfc4279#section-7.2. SRP, EKE and similar sche= mes > should be used instead. Fair point, though there seem to be at least political barriers to using SRP, and EKE and friends have other issues. > > Thanks, > =A0 =A0 =A0 =A0Yaron > > On 01/06/2011 05:31 PM, Ben Laurie wrote: > [...] > >> >> >> Two comments (one really being a response to Roy): >> >> 1. The IETF has fixed the problem, but no-one is using the fix - perhaps >> because it is not clear that it is the fix. I speak of RFC 4279, TLS >> pre-shared keys. These could be derived from a hash of the password and >> the site name, for example, and thus provide secure mutual >> authentication despite password reuse. >> > [...] > From yaronf.ietf@gmail.com Fri Jan 7 04:55:13 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46F443A686E; Fri, 7 Jan 2011 04:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 L07Vm7cKoG49; Fri, 7 Jan 2011 04:55:12 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id C40053A6873; Fri, 7 Jan 2011 04:55:11 -0800 (PST) Received: by wwa36 with SMTP id 36so17450279wwa.13 for ; Fri, 07 Jan 2011 04:57:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=8wB0BVHtoZNLSagh8m1PIgBE1XzJFln/PN6afWFMKh4=; b=QTG8DuwxYK0cZzA6ewan7/LdBbZYmKKxpzg2DNm/xhX8G7uB5Q/m/C93aeI/dxnyaX eiMykX00X8Oc3ayEBouf3tPxvn7BRNgxJU6sv1PLiLKbo3nmI7wUNwH+GJ/mHmea7Ed8 nLTsxkv2Y9Q/5gTg03Y9VubfDodTM0DZiGmzI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=T09V7sxDVE5FcbtNEmBRmlCkwYQJJqg7IlHHFYQjTB8aKt33za5sqgjjIfBCWPoqxU U1r23HIBdfdMahaVbuRanLxQ134YuLZRSeLjjMPWhlSr8Cq17tUKHV0m3BOlnnl2C/Gy 8ZVIQ+/6DOVts8WRKg/hBey8kdSTErwi/HSHI= Received: by 10.227.177.10 with SMTP id bg10mr9575207wbb.148.1294405033432; Fri, 07 Jan 2011 04:57:13 -0800 (PST) Received: from [10.0.0.6] ([109.67.17.212]) by mx.google.com with ESMTPS id f35sm17642679wbf.20.2011.01.07.04.57.08 (version=SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 04:57:12 -0800 (PST) Message-ID: <4D270DA1.7020408@gmail.com> Date: Fri, 07 Jan 2011 14:57:05 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Simon Josefsson References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <4D26CDB5.3090303__44301.5923993245$1294388684$gmane$org@gmail.com> <87lj2xj592.fsf@latte.josefsson.org> In-Reply-To: <87lj2xj592.fsf@latte.josefsson.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "Roy T. Fielding" , websec , Robert Sayre , "kitten@ietf.org" , "http-auth@ietf.org" , "ietf-http-wg@w3.org Group" , Ben Laurie Subject: Re: [http-auth] [websec] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 12:55:13 -0000 Another issue is that SRP (as opposed to other protocols in this space) is not provably secure, and in fact has had relatively little cryptographic review, AFAIK. I would be glad to be proven wrong on the second point. Thanks, Yaron On 01/07/2011 01:57 PM, Simon Josefsson wrote: > One way to mitigate the dictionary attack problem is to do PBKDF#2 > processing of the password before it hits TLS-PSK. > > However I agree that TLS-SRP have superior properties, and it is widely > implemented. There is no practical reason to prefer TLS-PSK over > TLS-PSK for password-based TLS authentication. One issue is that RFC > 5054 is Informational rather than Standards Track (same issue as for > TLS-OpenPGP), which is due to political reasons. > > /Simon > > Yaron Sheffer writes: > >> [Culling down the mailing lists] >> >> Hi Ben, >> >> No, RFC 4279 should not be used with (a hash of) human-memorable >> passwords, because it would be vulnerable to dictionary attacks. See >> http://tools.ietf.org/html/rfc4279#section-7.2. SRP, EKE and similar >> schemes should be used instead. >> >> Thanks, >> Yaron >> >> On 01/06/2011 05:31 PM, Ben Laurie wrote: >> [...] >> >>> >>> >>> Two comments (one really being a response to Roy): >>> >>> 1. The IETF has fixed the problem, but no-one is using the fix - perhaps >>> because it is not clear that it is the fix. I speak of RFC 4279, TLS >>> pre-shared keys. These could be derived from a hash of the password and >>> the site name, for example, and thus provide secure mutual >>> authentication despite password reuse. >>> >> [...] From simon@josefsson.org Fri Jan 7 06:28:47 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD4083A68D7; Fri, 7 Jan 2011 06:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 oP9OxbQBMBkV; Fri, 7 Jan 2011 06:28:46 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 4DC553A68BE; Fri, 7 Jan 2011 06:28:46 -0800 (PST) Received: from latte.josefsson.org ([213.115.69.138]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p07EUT7V023012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 7 Jan 2011 15:30:31 +0100 From: Simon Josefsson To: Yaron Sheffer References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <4D26CDB5.3090303__44301.5923993245$1294388684$gmane$org@gmail.com> <87lj2xj592.fsf@latte.josefsson.org> <4D270DA1.7020408__25077.7970803485$1294405057$gmane$org@gmail.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110107:http-auth@ietf.org::GFndAU08IAgP67Rw:8ppA X-Hashcash: 1:22:110107:benl@google.com::SQghvywdCmUGonlm:BhSZ X-Hashcash: 1:22:110107:ietf-http-wg@w3.org::15dxnKRibF4RdeUL:HacJ X-Hashcash: 1:22:110107:websec@ietf.org::OgsJlC8FfpBk4Sw+:Ir1K X-Hashcash: 1:22:110107:sayrer@gmail.com::0uhHwungE9rrSt8t:Mjeq X-Hashcash: 1:22:110107:yaronf.ietf@gmail.com::GSKndXAjUb6XHs0d:GUHu X-Hashcash: 1:22:110107:fielding@gbiv.com::Db1vcS1WnfJxHa0F:eba1 X-Hashcash: 1:22:110107:kitten@ietf.org::LJT0AtYQinVS7GSd:p9dv Date: Fri, 07 Jan 2011 15:29:40 +0100 In-Reply-To: <4D270DA1.7020408__25077.7970803485$1294405057$gmane$org@gmail.com> (Yaron Sheffer's message of "Fri, 07 Jan 2011 14:57:05 +0200") Message-ID: <874o9kiy7f.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: "Roy T. Fielding" , websec , Robert Sayre , "kitten@ietf.org" , "http-auth@ietf.org" , "ietf-http-wg@w3.org Group" , Ben Laurie Subject: Re: [http-auth] [websec] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 14:28:48 -0000 The initial paper contains a security analysis with some reduction-style arguments: http://srp.stanford.edu/ndss.html#SECTION00040000000000000000 As with any crypto document from that time, it will lack in how the assumptions are stated and the reductions are made. That considered, is there something in particular that you think is missing in there? We can fix the problem with lack of review by implementing and deploying the protocol, then certainly researchers are bound to focus on it. ;-) /Simon Yaron Sheffer writes: > Another issue is that SRP (as opposed to other protocols in this > space) is not provably secure, and in fact has had relatively little > cryptographic review, AFAIK. I would be glad to be proven wrong on the > second point. > > Thanks, > Yaron > > On 01/07/2011 01:57 PM, Simon Josefsson wrote: >> One way to mitigate the dictionary attack problem is to do PBKDF#2 >> processing of the password before it hits TLS-PSK. >> >> However I agree that TLS-SRP have superior properties, and it is widely >> implemented. There is no practical reason to prefer TLS-PSK over >> TLS-PSK for password-based TLS authentication. One issue is that RFC >> 5054 is Informational rather than Standards Track (same issue as for >> TLS-OpenPGP), which is due to political reasons. >> >> /Simon >> >> Yaron Sheffer writes: >> >>> [Culling down the mailing lists] >>> >>> Hi Ben, >>> >>> No, RFC 4279 should not be used with (a hash of) human-memorable >>> passwords, because it would be vulnerable to dictionary attacks. See >>> http://tools.ietf.org/html/rfc4279#section-7.2. SRP, EKE and similar >>> schemes should be used instead. >>> >>> Thanks, >>> Yaron >>> >>> On 01/06/2011 05:31 PM, Ben Laurie wrote: >>> [...] >>> >>>> >>>> >>>> Two comments (one really being a response to Roy): >>>> >>>> 1. The IETF has fixed the problem, but no-one is using the fix - perhaps >>>> because it is not clear that it is the fix. I speak of RFC 4279, TLS >>>> pre-shared keys. These could be derived from a hash of the password and >>>> the site name, for example, and thus provide secure mutual >>>> authentication despite password reuse. >>>> >>> [...] From yaronf.ietf@gmail.com Fri Jan 7 08:34:11 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3931C3A68D0; Fri, 7 Jan 2011 08:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 MdmEHsYHNX-5; Fri, 7 Jan 2011 08:34:09 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 6CCEF3A68C0; Fri, 7 Jan 2011 08:34:07 -0800 (PST) Received: by wyf23 with SMTP id 23so18465156wyf.31 for ; Fri, 07 Jan 2011 08:36:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=f+fhP7UPeAW6UH0hkHpFz2PBxTHW8cDCICMCIxYY4y4=; b=bkAQbjgZzk7YNxPuU63NW1UzbRZ7Kv5eCS5KDn1eyGXHRiObV7DbDXiVTZXfEC7R18 4ZF3VLRiu8PSb233/p1fm2rYP+YV0iNw7AT7x4z90QzN9B2JIeg97FNIF1Pmzo9uQF0/ o3DhSuD8r5FFERLjJCBceK8KP+j9YkLdAHnjk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=b0E815ule1RlK1rqsgYuXpdVdjAgrqfNLgC9tuiKDDdTo6w7IlCoXO58vRbHlPQMhq LGNGsC3DQEVTajKdcBMyy0xZoIkfrbrGhuZiy0kzCtQq1S5fQWo/L0YG850z72IheJb/ EoOXqRNnMBryTt3rrxdWSWZ54kOOwD87dhAMo= Received: by 10.227.141.197 with SMTP id n5mr8212052wbu.100.1294416320023; Fri, 07 Jan 2011 08:05:20 -0800 (PST) Received: from [10.0.0.6] ([109.67.17.212]) by mx.google.com with ESMTPS id 11sm17773721wbj.13.2011.01.07.08.05.12 (version=SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 08:05:18 -0800 (PST) Message-ID: <4D2739B5.5060107@gmail.com> Date: Fri, 07 Jan 2011 18:05:09 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Simon Josefsson References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <4D26CDB5.3090303__44301.5923993245$1294388684$gmane$org@gmail.com> <87lj2xj592.fsf@latte.josefsson.org> <4D270DA1.7020408__25077.7970803485$1294405057$gmane$org@gmail.com> <874o9kiy7f.fsf@latte.josefsson.org> In-Reply-To: <874o9kiy7f.fsf@latte.josefsson.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "Roy T. Fielding" , websec , Robert Sayre , "kitten@ietf.org" , "http-auth@ietf.org" , "ietf-http-wg@w3.org Group" , Ben Laurie Subject: Re: [http-auth] [websec] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 16:34:11 -0000 - I am not a cryptographer, so I am treading on extremely thin ice here. - SRP is certainly better than using PSK with passwords, which is *definitely* vulnerable to dictionary attacks. - That said, I have done my little bit of due diligence (talked to the author of SRP and to several cryptographers who've played with some of these schemes). Personally, I would rather use a protocol that's been formally proven (PACE, AugPAKE, other descendants of EKE) or has had real solid cryptographic review (the original EKE). Again, I would be happy to be proven wrong on this. - Even if we start with a mathematically perfect protocol, we are bound to make design and engineering mistakes. And Marsh and his like will happily poke holes into these implementations :-) But I'd like to avoid compounding the risk with cryptographically unsound protocols. Thanks, Yaron On 01/07/2011 04:29 PM, Simon Josefsson wrote: > The initial paper contains a security analysis with some reduction-style > arguments: > > http://srp.stanford.edu/ndss.html#SECTION00040000000000000000 > > As with any crypto document from that time, it will lack in how the > assumptions are stated and the reductions are made. That considered, is > there something in particular that you think is missing in there? > > We can fix the problem with lack of review by implementing and deploying > the protocol, then certainly researchers are bound to focus on it. ;-) > > /Simon > > Yaron Sheffer writes: > >> Another issue is that SRP (as opposed to other protocols in this >> space) is not provably secure, and in fact has had relatively little >> cryptographic review, AFAIK. I would be glad to be proven wrong on the >> second point. >> >> Thanks, >> Yaron >> >> On 01/07/2011 01:57 PM, Simon Josefsson wrote: >>> One way to mitigate the dictionary attack problem is to do PBKDF#2 >>> processing of the password before it hits TLS-PSK. >>> >>> However I agree that TLS-SRP have superior properties, and it is widely >>> implemented. There is no practical reason to prefer TLS-PSK over >>> TLS-PSK for password-based TLS authentication. One issue is that RFC >>> 5054 is Informational rather than Standards Track (same issue as for >>> TLS-OpenPGP), which is due to political reasons. >>> >>> /Simon >>> >>> Yaron Sheffer writes: >>> >>>> [Culling down the mailing lists] >>>> >>>> Hi Ben, >>>> >>>> No, RFC 4279 should not be used with (a hash of) human-memorable >>>> passwords, because it would be vulnerable to dictionary attacks. See >>>> http://tools.ietf.org/html/rfc4279#section-7.2. SRP, EKE and similar >>>> schemes should be used instead. >>>> >>>> Thanks, >>>> Yaron >>>> >>>> On 01/06/2011 05:31 PM, Ben Laurie wrote: >>>> [...] >>>> >>>>> >>>>> >>>>> Two comments (one really being a response to Roy): >>>>> >>>>> 1. The IETF has fixed the problem, but no-one is using the fix - perhaps >>>>> because it is not clear that it is the fix. I speak of RFC 4279, TLS >>>>> pre-shared keys. These could be derived from a hash of the password and >>>>> the site name, for example, and thus provide secure mutual >>>>> authentication despite password reuse. >>>>> >>>> [...] From simon@josefsson.org Fri Jan 7 08:53:49 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A04343A691B; Fri, 7 Jan 2011 08:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, 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 fRYHDcNAmnt7; Fri, 7 Jan 2011 08:53:48 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 1A4573A68D0; Fri, 7 Jan 2011 08:53:46 -0800 (PST) Received: from latte.josefsson.org ([213.115.69.138]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p07GtadB029494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 7 Jan 2011 17:55:37 +0100 From: Simon Josefsson To: Yaron Sheffer References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <4D26CDB5.3090303__44301.5923993245$1294388684$gmane$org@gmail.com> <87lj2xj592.fsf@latte.josefsson.org> <4D270DA1.7020408__25077.7970803485$1294405057$gmane$org@gmail.com> <874o9kiy7f.fsf@latte.josefsson.org> <4D2739B5.5060107@gmail.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110107:sayrer@gmail.com::nKbrDoVZ8ntVn1sL:0vDu X-Hashcash: 1:22:110107:fielding@gbiv.com::Z60jztLM1WmVf/qd:5qoh X-Hashcash: 1:22:110107:http-auth@ietf.org::GkOKc/hUdEd3jjQ6:7Jem X-Hashcash: 1:22:110107:ietf-http-wg@w3.org::/a2sto5LOdFoRft1:9U3R X-Hashcash: 1:22:110107:benl@google.com::OwwzH5bedfc1Wks0:91D9 X-Hashcash: 1:22:110107:yaronf.ietf@gmail.com::QpYfSjOpmEpPPQqY:FztG X-Hashcash: 1:22:110107:kitten@ietf.org::Ztv2C0I277++hhXP:tdIu X-Hashcash: 1:22:110107:websec@ietf.org::sNFLAbNnd90XYcDs:+6RP Date: Fri, 07 Jan 2011 17:54:46 +0100 In-Reply-To: <4D2739B5.5060107@gmail.com> (Yaron Sheffer's message of "Fri, 07 Jan 2011 18:05:09 +0200") Message-ID: <87fwt4ejs9.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: "Roy T. Fielding" , websec , Robert Sayre , "kitten@ietf.org" , "http-auth@ietf.org" , "ietf-http-wg@w3.org Group" , Ben Laurie Subject: Re: [http-auth] [websec] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 16:53:49 -0000 Yaron Sheffer writes: > - I am not a cryptographer, so I am treading on extremely thin ice here. > > - SRP is certainly better than using PSK with passwords, which is > *definitely* vulnerable to dictionary attacks. One final addition here, the situation for PSK depends on the flavour and whether you are talking about active or passive attackers. The statement is true for plain PSK, but less so for DHE_PSK and RSA_PSK. Section 7.2 of 4279: For the PSK ciphersuites, an attacker can get the information required for an off-line attack by eavesdropping on a TLS handshake, or by getting a valid client to attempt connection with the attacker (by tricking the client to connect to the wrong address, or by intercepting a connection attempt to the correct address, for instance). For the DHE_PSK ciphersuites, an attacker can obtain the information by getting a valid client to attempt connection with the attacker. Passive eavesdropping alone is not sufficient. For the RSA_PSK ciphersuites, only the server (authenticated using RSA and certificates) can obtain sufficient information for an off-line attack. /Simon > - That said, I have done my little bit of due diligence (talked to the > author of SRP and to several cryptographers who've played with some of > these schemes). Personally, I would rather use a protocol that's been > formally proven (PACE, AugPAKE, other descendants of EKE) or has had > real solid cryptographic review (the original EKE). Again, I would be > happy to be proven wrong on this. > > - Even if we start with a mathematically perfect protocol, we are > bound to make design and engineering mistakes. And Marsh and his like > will happily poke holes into these implementations :-) But I'd like to > avoid compounding the risk with cryptographically unsound protocols. > > Thanks, > Yaron > > On 01/07/2011 04:29 PM, Simon Josefsson wrote: >> The initial paper contains a security analysis with some reduction-style >> arguments: >> >> http://srp.stanford.edu/ndss.html#SECTION00040000000000000000 >> >> As with any crypto document from that time, it will lack in how the >> assumptions are stated and the reductions are made. That considered, is >> there something in particular that you think is missing in there? >> >> We can fix the problem with lack of review by implementing and deploying >> the protocol, then certainly researchers are bound to focus on it. ;-) >> >> /Simon >> >> Yaron Sheffer writes: >> >>> Another issue is that SRP (as opposed to other protocols in this >>> space) is not provably secure, and in fact has had relatively little >>> cryptographic review, AFAIK. I would be glad to be proven wrong on the >>> second point. >>> >>> Thanks, >>> Yaron >>> >>> On 01/07/2011 01:57 PM, Simon Josefsson wrote: >>>> One way to mitigate the dictionary attack problem is to do PBKDF#2 >>>> processing of the password before it hits TLS-PSK. >>>> >>>> However I agree that TLS-SRP have superior properties, and it is widely >>>> implemented. There is no practical reason to prefer TLS-PSK over >>>> TLS-PSK for password-based TLS authentication. One issue is that RFC >>>> 5054 is Informational rather than Standards Track (same issue as for >>>> TLS-OpenPGP), which is due to political reasons. >>>> >>>> /Simon >>>> >>>> Yaron Sheffer writes: >>>> >>>>> [Culling down the mailing lists] >>>>> >>>>> Hi Ben, >>>>> >>>>> No, RFC 4279 should not be used with (a hash of) human-memorable >>>>> passwords, because it would be vulnerable to dictionary attacks. See >>>>> http://tools.ietf.org/html/rfc4279#section-7.2. SRP, EKE and similar >>>>> schemes should be used instead. >>>>> >>>>> Thanks, >>>>> Yaron >>>>> >>>>> On 01/06/2011 05:31 PM, Ben Laurie wrote: >>>>> [...] >>>>> >>>>>> >>>>>> >>>>>> Two comments (one really being a response to Roy): >>>>>> >>>>>> 1. The IETF has fixed the problem, but no-one is using the fix - perhaps >>>>>> because it is not clear that it is the fix. I speak of RFC 4279, TLS >>>>>> pre-shared keys. These could be derived from a hash of the password and >>>>>> the site name, for example, and thus provide secure mutual >>>>>> authentication despite password reuse. >>>>>> >>>>> [...] > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From tim-research@sentinelchicken.org Fri Jan 7 09:40:09 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 785D53A68C5 for ; Fri, 7 Jan 2011 09:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.052, 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 Gv+MT65iatfH for ; Fri, 7 Jan 2011 09:40:08 -0800 (PST) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by core3.amsl.com (Postfix) with ESMTP id 991823A691D for ; Fri, 7 Jan 2011 09:40:08 -0800 (PST) Received: (qmail 11448 invoked from network); 7 Jan 2011 17:44:41 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 7 Jan 2011 17:44:41 -0000 Received: (qmail 26929 invoked from network); 7 Jan 2011 17:45:32 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 7 Jan 2011 17:45:32 -0000 Received: (nullmailer pid 20253 invoked by uid 1000); Fri, 07 Jan 2011 17:42:13 -0000 Date: Fri, 7 Jan 2011 09:42:13 -0800 From: Tim To: Simon Josefsson Message-ID: <20110107174213.GA6792@sentinelchicken.org> References: <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <4D26CDB5.3090303__44301.5923993245$1294388684$gmane$org@gmail.com> <87lj2xj592.fsf@latte.josefsson.org> <4D270DA1.7020408__25077.7970803485$1294405057$gmane$org@gmail.com> <874o9kiy7f.fsf@latte.josefsson.org> <4D2739B5.5060107@gmail.com> <87fwt4ejs9.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87fwt4ejs9.fsf@latte.josefsson.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "kitten@ietf.org" , "http-auth@ietf.org" , websec , "ietf-http-wg@w3.org Group" Subject: Re: [http-auth] [websec] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 17:40:09 -0000 > One final addition here, the situation for PSK depends on the flavour > and whether you are talking about active or passive attackers. The > statement is true for plain PSK, but less so for DHE_PSK and RSA_PSK. > Section 7.2 of 4279: > > For the PSK ciphersuites, an attacker can get the information > required for an off-line attack by eavesdropping on a TLS handshake, > or by getting a valid client to attempt connection with the attacker > (by tricking the client to connect to the wrong address, or by > intercepting a connection attempt to the correct address, for > instance). > > For the DHE_PSK ciphersuites, an attacker can obtain the information > by getting a valid client to attempt connection with the attacker. > Passive eavesdropping alone is not sufficient. > > For the RSA_PSK ciphersuites, only the server (authenticated using > RSA and certificates) can obtain sufficient information for an > off-line attack. In the general case, I don't think it is useful to differentiate between passive and active attackers. Performing man-in-the-middle attacks is no more difficult (in a big-O sense) than performing passive attacks. In almost every modern network, these attacks require the same level of network access. Just a pet peeve of mine. cheers, tim From stpeter@stpeter.im Fri Jan 7 09:44:04 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BCA63A68D5 for ; Fri, 7 Jan 2011 09:44:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.646 X-Spam-Level: X-Spam-Status: No, score=-102.646 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, 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 K1Z41IlzoISw for ; Fri, 7 Jan 2011 09:44:03 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 0356F3A67D0 for ; Fri, 7 Jan 2011 09:44:03 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id EFE44400EE; Fri, 7 Jan 2011 11:00:41 -0700 (MST) Message-ID: <4D275160.8050605@stpeter.im> Date: Fri, 07 Jan 2011 10:46:08 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Tim References: <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <4D26CDB5.3090303__44301.5923993245$1294388684$gmane$org@gmail.com> <87lj2xj592.fsf@latte.josefsson.org> <4D270DA1.7020408__25077.7970803485$1294405057$gmane$org@gmail.com> <874o9kiy7f.fsf@latte.josefsson.org> <4D2739B5.5060107@gmail.com> <87fwt4ejs9.fsf@latte.josefsson.org> <20110107174213.GA6792@sentinelchicken.org> In-Reply-To: <20110107174213.GA6792@sentinelchicken.org> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060905010704010204050401" Cc: "http-auth@ietf.org" Subject: Re: [http-auth] [websec] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 17:44:04 -0000 This is a cryptographically signed message in MIME format. --------------ms060905010704010204050401 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 1/7/11 10:42 AM, Tim wrote: >> One final addition here, the situation for PSK depends on the flavour >> and whether you are talking about active or passive attackers. The >> statement is true for plain PSK, but less so for DHE_PSK and RSA_PSK. >> Section 7.2 of 4279: >> >> For the PSK ciphersuites, an attacker can get the information >> required for an off-line attack by eavesdropping on a TLS handshake= , >> or by getting a valid client to attempt connection with the attacke= r >> (by tricking the client to connect to the wrong address, or by >> intercepting a connection attempt to the correct address, for >> instance). >> >> For the DHE_PSK ciphersuites, an attacker can obtain the informatio= n >> by getting a valid client to attempt connection with the attacker. >> Passive eavesdropping alone is not sufficient. >> >> For the RSA_PSK ciphersuites, only the server (authenticated using >> RSA and certificates) can obtain sufficient information for an >> off-line attack. >=20 >=20 > In the general case, I don't think it is useful to differentiate > between passive and active attackers. Performing man-in-the-middle > attacks is no more difficult (in a big-O sense) than performing > passive attacks. In almost every modern network, these attacks > require the same level of network access. Good point. > Just a pet peeve of mine. My pet peeve is that folks continue to cc the following lists on their replies to this thread: Can we trim that to only, please? :) Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms060905010704010204050401 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEw NzE3NDYwOFowIwYJKoZIhvcNAQkEMRYEFO64qzlhRD6VfUm5CLKayrjQgZUGMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBzoI2tbAicG0XAfr5vF+WvEoFeqoczayNHMTzJeex8VMiMTQQNQUPYF3QN 3XMStRBtHKu9Ml6bR61GzCyhQrJyDKDnrX6/3w8MFMWana0EKiLKiLTxOFghUO1L8x8rKkGd GnZq9+rO2eaqlw9IBeP6q0Ar9KoQ9A27KpW2UDxghbxqjNM/MTHCSZZlN8waA5ctWKfV/bOH 2bx8GYKsNnG1Xmm1W4y7t32JlF5SU3941NX5dLhLChNrOjh4ZKZo4JcnvG93D9597BbPxh3w IuyVV5DyzGP2Am4LckKHkgIs76J3pRk6NQCauk0FNrVt8yTdBFRrpVlZxBxb5fDhTkR3AAAA AAAA --------------ms060905010704010204050401-- From tim-research@sentinelchicken.org Fri Jan 7 09:46:04 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2CC93A67D0 for ; Fri, 7 Jan 2011 09:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=-0.101, 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 YzLEYZJa6B-a for ; Fri, 7 Jan 2011 09:46:04 -0800 (PST) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by core3.amsl.com (Postfix) with ESMTP id BB96B3A6920 for ; Fri, 7 Jan 2011 09:46:03 -0800 (PST) Received: (qmail 11498 invoked from network); 7 Jan 2011 17:50:37 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 7 Jan 2011 17:50:37 -0000 Received: (qmail 27077 invoked from network); 7 Jan 2011 17:51:28 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 7 Jan 2011 17:51:28 -0000 Received: (nullmailer pid 20293 invoked by uid 1000); Fri, 07 Jan 2011 17:48:10 -0000 Date: Fri, 7 Jan 2011 09:48:10 -0800 From: Tim To: Peter Saint-Andre Message-ID: <20110107174810.GB6792@sentinelchicken.org> References: <4D26CDB5.3090303__44301.5923993245$1294388684$gmane$org@gmail.com> <87lj2xj592.fsf@latte.josefsson.org> <4D270DA1.7020408__25077.7970803485$1294405057$gmane$org@gmail.com> <874o9kiy7f.fsf@latte.josefsson.org> <4D2739B5.5060107@gmail.com> <87fwt4ejs9.fsf@latte.josefsson.org> <20110107174213.GA6792@sentinelchicken.org> <4D275160.8050605@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D275160.8050605@stpeter.im> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "http-auth@ietf.org" Subject: Re: [http-auth] [websec] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 17:46:04 -0000 > > In the general case, I don't think it is useful to differentiate > > between passive and active attackers. Performing man-in-the-middle > > attacks is no more difficult (in a big-O sense) than performing > > passive attacks. In almost every modern network, these attacks > > require the same level of network access. > > Good point. > > > Just a pet peeve of mine. > > My pet peeve is that folks continue to cc the following lists on their > replies to this thread: > > > > > > > Can we trim that to only, please? :) Yes, good point. Will do so in the future. tim From marsh@extendedsubset.com Fri Jan 7 11:23:08 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0B023A6927 for ; Fri, 7 Jan 2011 11:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 V-OSQOI4cTLb for ; Fri, 7 Jan 2011 11:23:06 -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 449573A68EA for ; Fri, 7 Jan 2011 11:23:06 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1PbHw0-000KLW-RF; Fri, 07 Jan 2011 19:25:12 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 19E65603D; Fri, 7 Jan 2011 19:25:09 +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+K1HJoj7LyoMtsAbmp2vtyoV+tw1k7VQw= Message-ID: <4D276895.60705@extendedsubset.com> Date: Fri, 07 Jan 2011 13:25:09 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Tim References: <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <4D26CDB5.3090303__44301.5923993245$1294388684$gmane$org@gmail.com> <87lj2xj592.fsf@latte.josefsson.org> <4D270DA1.7020408__25077.7970803485$1294405057$gmane$org@gmail.com> <874o9kiy7f.fsf@latte.josefsson.org> <4D2739B5.5060107@gmail.com> <87fwt4ejs9.fsf@latte.josefsson.org> <20110107174213.GA6792@sentinelchicken.org> In-Reply-To: <20110107174213.GA6792@sentinelchicken.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] [websec] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 19:23:09 -0000 On 01/07/2011 11:42 AM, Tim wrote: > > In the general case, I don't think it is useful to differentiate > between passive and active attackers. Performing man-in-the-middle > attacks is no more difficult (in a big-O sense) than performing > passive attacks. In almost every modern network, these attacks > require the same level of network access. > Just a pet peeve of mine. +1, I too think there is often a sense that, while passive eavesdropping is often easy (it even happens by accident, e.g. Google Streetview Wifi collection), a MitM is thought of as something that requires Mission Impossible style planning. Anyone else remember the old TV show where they'd dress up like the phone company and climb some telephone pole with a tape recorder and replay remixed bits of other conversations to mess with the target's mind? This is a dangerous enough viewpoint for endpoint defenders, but it's also common among software developers. It's even been a stated or unstated assumption in the security analysis of many a protocol, though less so now than in the past. For example, check out this classic : author = {Bruce Schneier Mudge and David Wagner}, title = {Cryptanalysis of Microsoft's PPTP Authentication Extensions (MS-CHAPv2)}, year = {1999} http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.34.8720 http://www.schneier.com/paper-pptpv2.pdf There's a trivial active attack on that authentication scheme but the authors don't even mention it! I'm not bringing this up to pick at the authors but in fact to say the opposite: these guys surely would have pointed it out if it had been considered part of the threat model. Today I think it is still useful to differentiate between passive and active attackers in talking about protocol security. If you leave that part of the discussion out, probably two things will happen: * Readers who are concerned with the possibility of active attacks might not be sure the degree to which the analysis is actually taking them into account. * Readers with an insufficient concern for active attacks might not pick up on the fact that the author is intentionally not differentiating. They might miss the opportunity to reconsider their viewpoint and it might even serve to reinforce their preconceptions. Perhaps someday in the future, we'll all agree that active attacks are a threat on equal footing and it just "goes without saying". But I don't think we're there yet. - Marsh From hallam@gmail.com Sat Jan 8 08:05:35 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED07028C116; Sat, 8 Jan 2011 08:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.394 X-Spam-Level: X-Spam-Status: No, score=-3.394 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 6gCSwpkqFCfA; Sat, 8 Jan 2011 08:05:34 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 980FE28C115; Sat, 8 Jan 2011 08:05:30 -0800 (PST) Received: by yie19 with SMTP id 19so5709246yie.31 for ; Sat, 08 Jan 2011 08:07:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=EZat7nI2OqohWyhSuZ4/WUlxZZdT1hBAk9ZOiTKdMs8=; b=IsStjSvSUvS0dPFDf1N3Ml3awrq6X6rj5PoZzGDm8t25H5pVn6+V+O8BlPF4zYXGiw 15TFFqfUG6WgkHRo9pfnC6zEIrglsN88NS7dz4gkaK9K3deHlpnk8vEW0vNrYsxJ4yyZ hWZlZEK/FamRcOPXqikvjrHHlsdrGvTmrl/lo= 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=WSyrgGBaHg3J5BznJYd6ZsF1Ar8HJ3QQhdyo4tPV51GGUNa4oJNsQCdx/zvFY8FyWK C5j2k8JRj00t4G/7PZ1MX0RU3qlQtl2dosSeNZKMm9U++nWz2mXgPU/iACBsZyYyhIrg IKFedcrAXxE3YeAiKRUmipB+NPHJj2bdEiEzY= MIME-Version: 1.0 Received: by 10.100.173.13 with SMTP id v13mr2476968ane.171.1294502858509; Sat, 08 Jan 2011 08:07:38 -0800 (PST) Received: by 10.100.31.8 with HTTP; Sat, 8 Jan 2011 08:07:38 -0800 (PST) In-Reply-To: References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> Date: Sat, 8 Jan 2011 11:07:38 -0500 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=0016e644dbc60acc57049957ef07 Cc: "apps-discuss@ietf.org" , "Roy T. Fielding" , websec , Robert Sayre , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [http-auth] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 16:05:36 -0000 --0016e644dbc60acc57049957ef07 Content-Type: text/plain; charset=ISO-8859-1 I think that Ben is right that we are solving the wrong problem. The problem is that users are asked to maintain accounts at literally HUNDREDS of accounts. And some cretins, some utter morons, some bog-brained berks think it is reasonable to tell the user to have a different password for every one! I can't remember the account names, the password is easy as I only had one (for non financial) - until those cretins at Gawker screwed up. Now I have to reset my password at all those places. We have to solve the federated auth problem and it is really, really easy: Account Name is the RFC 821/822 email address. This is what the Web has started to adopt of its own accord as a user account identifier. It is the only one that people can remember reliably. Authentication service is resolved via DNS service lookup i.e. SRV or similar. I can show people how to fix up the issues to do with use of non-canonical names. Client authenticates to authentication service using any protocol they both support. This is quite simple to implement, just stick a list of supported auth services in the DNS. We can re-use all those existing auth protocols that work (SAML would be a good choice but we don't need to be overly restrictive here.) HTTP carries a standardized, non-linkable auth token I have some ideas on how we could modify DIGEST to do this. DIGEST would not be problematic if the password had 128 bits of ergodicity and we upgraded the digest function. The reason for re-using DIGEST here would be to avoid patent encumbrances. I considered the issue of linkability at great length when writing the original DIGEST design. At the moment I am focused on getting the foundation laid. But I will try to come up with a full proposal before Prague. I know that you can achieve some of the desired authentication properties with public keys at the client. The problem is that our current use of computers has gone way beyond the one-machine-per-person paradigm On a recent trip to Europe with the family I counted that we had 10 computers with us capable of supporting IP (3 laptops, 3 iPhones, 2 Nintendos, 1 iPad and a kindle). Cardspace has some really, really great properties but they are totally lost when you try to make the service accessible from multiple machines by putting it 'in the cloud'. In fact, other than a manager, I have never found anyone who reven thinks they know what they mean by 'in the cloud' for CardSpace. I certainly have never seen an explanation I can understand. Devices get lost. Devices get stolen. We don't want to encourage that so there needs to be something more than just a certificate based client auth scheme. I think we need some form of centralized (for given account) account management in the mix so that the user can authorize/deauthorize devices for use (c.f. Amazon's Kindle account management) So there are basically two architectural options for using public key. One is to use it strictly between the client and the auth service and use a token like approach as discussed above. Another is for the auth service to issue an assertion of the form 'you can tell its fred by this public key (amongst others)'. SAML already has support for both approaches BTW. On Thu, Jan 6, 2011 at 10:31 AM, Ben Laurie wrote: > > > On 6 January 2011 01:28, Robert Sayre wrote: >> >> > Peter Saint-Andre wrote: >> > 2. In 2007, Robert Sayre put together a few slides on the topic: >> > http://people.mozilla.com/~sayrer/2007/auth.html >> >> These are back on the Web, in case anyone missed them (probably not). >> >> On Sun, Dec 12, 2010 at 5:39 PM, Roy T. Fielding >> wrote: >> > >> > Define them all and let's have a bake-off. It has been 16 years since >> > HTTP auth was taken out of our hands so that the security experts could >> > define something perfect. Zero progress so far. >> >> I think the IETF might do better to focus on a smaller problem, at >> first. People often use self-signed certificates with HTTP/TLS, even >> though the first thing their websites ask the user to do is type a >> username and password into a form. There are some well-understood ways >> to make this process more secure. Why hasn't the IETF fixed this >> problem? If this smaller problem has no ready solution, then the >> larger issue of authentication on the entire Web seems like a tough >> nut to crack. > > Two comments (one really being a response to Roy): > 1. The IETF has fixed the problem, but no-one is using the fix - perhaps > because it is not clear that it is the fix. I speak of RFC 4279, TLS > pre-shared keys. These could be derived from a hash of the password and the > site name, for example, and thus provide secure mutual authentication > despite password reuse. > 2. I have often heard (though I am not aware of hard evidence for this, > nevertheless I find it plausible) that one reason no-one has bothered to > improve HTTP auth is because no-one would use it since site owners want to > control the user experience around signin. It seems to me, therefore, that > HTTP is the wrong layer to fix the problem at - it needs to be pushed down > into HTML or Javascript so that the page can control the look, while > appropriate HTML elements or JS code can deal with the secure exchange of > data. > Of course, this still leaves the issue of trusted path: although we can > provide elements which are safe to use, even when being phished, how does > the user know those elements are actually being used, rather than simulated > so as to get hold of the underlying password? > The answer to this problem is hard, since it brings us back to taking the UI > out of the sites hands. > >> >> It could be that the reasons for this lack of progress are >> nontechnical. Just throwing that out there. > > If you think UI is nontechnical, then I agree. > Cheers, > Ben. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > -- Website: http://hallambaker.com/ --0016e644dbc60acc57049957ef07 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think that Ben is right that we are solving the wrong problem.

The= problem is that users are asked to maintain accounts at literally HUNDREDS= of accounts.

And some cretins, some utter morons, some bog-brained= berks think it is reasonable to tell the user to have a different password= for every one!


I can't remember the account names, the password is easy as I o= nly had one (for non financial) - until those cretins at Gawker screwed up.= Now I have to reset my password at all those places.


We have to= solve the federated auth problem and it is really, really easy:

Account Name is the RFC 821/822 email address.

This is what the Web has started to adopt of its own accord as= a user account identifier. It is the only one that people can remember rel= iably.

Authentication service is resolved via DNS service lookup

i.e. SRV or similar. I can show people = how to fix up the issues to do with use of non-canonical names.

Client authenticates to authentication ser= vice using any protocol they both support.

This is quite simple to implement, just stick a list of supported auth= services in the DNS.

We can re-use all those exis= ting auth protocols that work (SAML would be a good choice but we don't= need to be overly restrictive here.)

HTTP carries a standardized, non-linkable = auth token

I have so= me ideas on how we could modify DIGEST to do this. DIGEST would not be prob= lematic if the password had 128 bits of ergodicity and we upgraded the dige= st function.

The reason for re-using DIGEST here would be to avoid p= atent encumbrances. I considered the issue of linkability at great length w= hen writing the original DIGEST design.


At the moment I am focused on getting the foundation laid. B= ut I will try to come up with a full proposal before Prague.


I know that you can achieve some of the desired aut= hentication properties with public keys at the client. The problem is that = our current use of computers has gone way beyond the one-machine-per-person= paradigm

On a recent trip to Europe with the family I counted th= at we had 10 computers with us capable of supporting IP (3 laptops, 3 iPhon= es, 2 Nintendos, 1 iPad and a kindle).

Cardspace h= as some really, really great properties but they are totally lost when you = try to make the service accessible from multiple machines by putting it = 9;in the cloud'. In fact, other than a manager, I have never found anyo= ne who reven thinks they know what they mean by 'in the cloud' for = CardSpace. I certainly have never seen an explanation I can understand.=A0<= /div>

Devices get lost. Devices get stolen. We don't want= to encourage that so there needs to be something more than just a certific= ate based client auth scheme.


I thi= nk we need some form of centralized (for given account) account management = in the mix so that the user can authorize/deauthorize devices for use (c.f.= Amazon's Kindle account management)

So there are basically two architectural options for us= ing public key. One is to use it strictly between the client and the auth s= ervice and use a token like approach as discussed above. Another is for the= auth service to issue an assertion of the form 'you can tell its fred = by this public key (amongst others)'.

SAML already has support for both approaches BTW.=A0


On Thu, Jan 6, 2011 at 10:31 AM, Ben Laurie <= benl@google.com> wrote:
> >
> On 6 January 2011 01:28, Robert Sayre <sayrer@gmail.com> wrote:
>>
>> >= ; Peter Saint-Andre <stpeter@stpet= er.im> wrote:
>> > 2. In 2007, Robert Sayre put together a few slides on the top= ic:
>> > http://people.mozilla.com/~sayrer/2007/auth.html
>>
>> These are back on the Web, in case anyone missed them (probably no= t).
>>
>> On Sun, Dec 12, 2010 at 5:39 PM, Roy T. Fieldin= g <fielding@gbiv.com>
>= ;> wrote:
>> >
>> > Define them all and let's have a bake-of= f. =A0It has been 16 years since
>> > HTTP auth was taken out o= f our hands so that the security experts could
>> > define some= thing perfect. =A0Zero progress so far.
>>
>> I think the IETF might do better to focus on a smaller= problem, at
>> first. People often use self-signed certificates w= ith HTTP/TLS, even
>> though the first thing their websites ask th= e user to do is type a
>> username and password into a form. There are some well-understood = ways
>> to make this process more secure. Why hasn't the IETF = fixed this
>> problem? If this smaller problem has no ready soluti= on, then the
>> larger issue of authentication on the entire Web seems like a toug= h
>> nut to crack.
>
> Two comments (one really being = a response to Roy):
> 1. The IETF has fixed the problem, but no-one i= s using the fix - perhaps
> because it is not clear that it is the fix. I speak of RFC 4279, TLS> pre-shared keys. These could be derived from a hash of the password = and the
> site name, for example, and thus provide secure mutual auth= entication
> despite password reuse.
> 2. I have often heard (though I am not= aware of hard evidence for this,
> nevertheless I find it plausible)= that one reason no-one has bothered to
> improve HTTP auth is becaus= e no-one would use it since site owners want to
> control the user experience around signin. It seems to me, therefore, = that
> HTTP is the wrong layer to fix the problem at - it needs to be= pushed down
> into HTML or Javascript so that the page can control t= he look, while
> appropriate HTML elements or JS code can deal with the secure exchange= of
> data.
> Of course, this still leaves the issue of trusted= path: although we can
> provide elements which are safe to use, even= when being phished, how does
> the user know those elements are actually being used, rather than simu= lated
> so as to get hold of the underlying password?
> The ans= wer to this problem is hard, since it brings us back to taking the UI
> out of the sites hands.
> =A0
>>
>> It could b= e that the reasons for this lack of progress are
>> nontechnical. = Just throwing that out there.
>
> If you think UI is nontechnic= al, then I agree.
> Cheers,
> Ben.
>
> _________________________________= ______________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>
>



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


--0016e644dbc60acc57049957ef07-- From hallam@gmail.com Sat Jan 8 08:19:38 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B3AE28C13A; Sat, 8 Jan 2011 08:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 rv2k8-0ECqSB; Sat, 8 Jan 2011 08:19:36 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id DD14728C116; Sat, 8 Jan 2011 08:19:34 -0800 (PST) Received: by yxt33 with SMTP id 33so7991387yxt.31 for ; Sat, 08 Jan 2011 08:21:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=P/kVq8JqTkbriAI2YHZ98j+IH6nPYaKiXLgMS1MrhJg=; b=gj3y71kH8mkwf9cxcnOrEcJQbI+UOFHppgDDPLZGHIdfFFp2xvOoVOpWrXtvD+yUkA +LKTe3Xre6ZFVGT3kLsOPfjpJ4+FCR/k4ryZHG6UBxHuR3hliF/G0Ra32UC7Ftq25kiT CSSObZqQKWywj3P9ZvOUXBi4SBO5ct7i6a2U8= 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=akVsGITiA3khO4gDCJU1IG1XlVTf0CvbBpjMaP9HTk7XT1qtjcDuiz08xafz+rqNOS +wqrQGZtiyzvfSjsGG6J0XLtD94i1iVJMpQmw12JwA00AmVcNDKtrDrIp3Wm4HuFW/B6 MyZXCnpieOCjP1JWjS/yGhBmH0vu4YVZLrxzI= MIME-Version: 1.0 Received: by 10.101.67.16 with SMTP id u16mr15882518ank.1.1294503702896; Sat, 08 Jan 2011 08:21:42 -0800 (PST) Received: by 10.100.31.8 with HTTP; Sat, 8 Jan 2011 08:21:42 -0800 (PST) In-Reply-To: References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> Date: Sat, 8 Jan 2011 11:21:42 -0500 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=00163662e65b5f211d049958212f Cc: "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [http-auth] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 16:19:38 -0000 --00163662e65b5f211d049958212f Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 6, 2011 at 1:16 PM, Ben Laurie wrote: > On 6 January 2011 16:03, David Morris wrote: > > > > > > On Thu, 6 Jan 2011, Ben Laurie wrote: > > > >> The answer to this problem is hard, since it brings us back to taking > the UI > >> out of the sites hands. > > > > Which is only helpful if you can somehow gaurantee that the user agent > > software hasn't been compromised. Not something I'd bet on... > > That's rather overstating it. It's perfectly helpful when the UA > software hasn't been compromised, which is a non-zero fraction of the > time. > > When the UA s/w has been compromised I'm quite happy to fail to fix > the problem: the right answer to that is to improve the robustness of > the UA. +1 If the UA is stuffed then the user is totally and utterly stuffed anyway. In particular if the UA is stuffed then a forms based experience is just as stuffed. If we are going to hypothecate attack models people have to be willing to apply them to their preferred solution too. The sensible approach is to work out how to stop the user from being stuffed e.g. * Comodo's free Anti-Virus with Default Deny Protection (TM) * Use code signing + trustworthy computing * Use a restricted browser Now I have a lot of ideas on how we can tackle these, but they are not relevant to this debate. I do however have a different take on the UI issue. HTML forms did have an advantage over the pathetic UI that browsers provided for BASIC and DIGEST (most don't even tell the user which is in use). But a federated auth scheme supported at the HTTP level could be simpler still. Instead of the user having to register for each site, they register once. Instead of the user having to log in to each site they log in once per session. Instead of the site having to manage lost passwords and forgotten accounts because the user has hundreds, this problem does not exist. It is a user interface crisis that is driving this need in my view. -- Website: http://hallambaker.com/ --00163662e65b5f211d049958212f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jan 6, 2011 at 1:16 PM, Ben Laurie <benl@google.com> wrote:
On 6 January 2011 16:03, David Morris <dwm@xpasc.com> wrote:
>
>
> On Thu, 6 Jan 2011, Ben Laurie wrote:
>
>> The answer to this problem is hard, since it brings us back to tak= ing the UI
>> out of the sites hands.
>
> Which is only helpful if you can somehow gaurantee that the user agent=
> software hasn't been compromised. Not something I'd bet on...<= br>
That's rather overstating it. It's perfectly helpful when the= UA
software hasn't been compromised, which is a non-zero fraction of the time.

When the UA s/w has been compromised I'm quite happy to fail to fix
the problem: the right answer to that is to improve the robustness of
the UA.

+1

If the = UA is stuffed then the user is totally and utterly stuffed anyway.=A0
=

In particular if the UA is stuffed then a forms based e= xperience is just as stuffed. If we are going to hypothecate attack models = people have to be willing to apply them to their preferred solution too.


The sensible approach is to work out how= to stop the user from being stuffed e.g.=A0

=A0* = Comodo's free Anti-Virus with Default Deny Protection (TM)
= =A0* Use code signing + trustworthy computing
=A0* Use a restricted browser=A0

Now I have a= lot of ideas on how we can tackle these, but they are not relevant to this= debate.


I do however have a differ= ent take on the UI issue.=A0

HTML forms did have an advantage over the pathetic UI t= hat browsers provided for BASIC and DIGEST (most don't even tell the us= er which is in use).

But a federated auth scheme s= upported at the HTTP level could be simpler still. Instead of the user havi= ng to register for each site, they register once. Instead of the user havin= g to log in to each site they log in once per session. Instead of the site = having to manage lost passwords and forgotten accounts because the user has= hundreds, this problem does not exist.


It is a user interface crisis that is dr= iving this need in my view.


-- Website: http://hallambaker.com/
--00163662e65b5f211d049958212f-- From hallam@gmail.com Sat Jan 8 09:50:39 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C2C23A67FB; Sat, 8 Jan 2011 09:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 20paQQnmkSN0; Sat, 8 Jan 2011 09:50:37 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 4885D3A67E3; Sat, 8 Jan 2011 09:50:37 -0800 (PST) Received: by gxk28 with SMTP id 28so8482976gxk.31 for ; Sat, 08 Jan 2011 09:52:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=6bo8ZioF39rKL6lWvOQo5g2WqHHhQncsxAnkblyge2E=; b=jWIHeGDUOh6avcUiKYI7wTYJwXy3jV8Acwp85reJHuvwsDKt8TaSgr8SGj5bn7Q7bv jG2GSHJKVTAA9sgZKU7NZ4wuZ42O+jZbnhxcQUq74l1TCZaXmMIaC0yNxPR6LkqMfWnL tuiYH6ugrFSmbfe0lfKwHBKdlGFwnHo2lWpJk= 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=g3FpArmvl34jXqveOoAO3WWa9XUrTArhTTE14LqMm9R3QH4k7wPphX8fK/KgZnsYnM jBigHkW3i9jMtNPJtsOOxoaJFUSZhDnDiNwBUhJwN42VR72PMU6XBpttZm04NoXcFF3p +mWIZVwfHvsxDrYrql6OzS8B9K/d4dEIHJ0SA= MIME-Version: 1.0 Received: by 10.100.173.13 with SMTP id v13mr2521122ane.171.1294509165388; Sat, 08 Jan 2011 09:52:45 -0800 (PST) Received: by 10.100.31.8 with HTTP; Sat, 8 Jan 2011 09:52:45 -0800 (PST) In-Reply-To: References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> Date: Sat, 8 Jan 2011 12:52:45 -0500 Message-ID: From: Phillip Hallam-Baker To: Blaine Cook Content-Type: multipart/alternative; boundary=0016e644dbc6f623100499596635 Cc: "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , Ben Laurie , "ietf-http-wg@w3.org Group" Subject: Re: [http-auth] [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 17:50:39 -0000 --0016e644dbc6f623100499596635 Content-Type: text/plain; charset=ISO-8859-1 OAUTH and Webfinger are both pretty much as good as you can expect to achieve if you decide at the start that you are not going to modify the infrastructure. But that decision limits what you can expect to achieve. A particular problem with OAuth is that you can only use the identity providers that are supported by the particular site. So I had to use my Twitter account to play spymaster. And when Twitter got shirty and started blocking other players accounts they lost their game account and their twitter account at the same time. There are people who think I should get a facebook account just so that I can use their application. Not happening. As for WebFinger, it works, but not nearly as well as a clean DNS scheme. DNS is designed to address this problem, HTTP is not. And solving the problem with HTTP requires us to have a scheme that involves DNS + HTTP + SSL + PKIX which is rather a lot of moving parts and to make matters work some those parts are not just moving, they are changing. I think it is a very good idea to look at WebFinger and OAuth and see how to realize these approaches direct in the infrastructure. But they should be seen as starting points, not ends. On Sat, Jan 8, 2011 at 12:37 PM, Blaine Cook wrote: > Two points: > > 1. In this entire thread, no-one has mentioned OAuth. Maybe y'all > don't like it, but it's used to authenticate more HTTP requests by > volume and users than everything-except-cookies combined. You may want > to consider the design of OAuth when proceeding with these > discussions, rather than the laundry list of [completely] failed > protocols. > > 2. With respect to federated auth, especially using email address-like > identifiers, there has been a bevy of (deployed) work in this regard. > The effort is called webfinger, and is worth a look. Instead of DNS, > we use host-meta based HTTP lookups to dereference the identifiers. > Many diaspora and status.net installs are using it today, and there > are several proposals towards building a security & privacy > infrastructure on top of webfinger (webid is one such proposal whose > incorporation of client-side TLS certificates in a browser context > makes me very weary of its potential for success). > > b. > > On 8 January 2011 08:21, Phillip Hallam-Baker wrote: > > On Thu, Jan 6, 2011 at 1:16 PM, Ben Laurie wrote: > >> > >> On 6 January 2011 16:03, David Morris wrote: > >> > > >> > > >> > On Thu, 6 Jan 2011, Ben Laurie wrote: > >> > > >> >> The answer to this problem is hard, since it brings us back to taking > >> >> the UI > >> >> out of the sites hands. > >> > > >> > Which is only helpful if you can somehow gaurantee that the user agent > >> > software hasn't been compromised. Not something I'd bet on... > >> > >> That's rather overstating it. It's perfectly helpful when the UA > >> software hasn't been compromised, which is a non-zero fraction of the > >> time. > >> > >> When the UA s/w has been compromised I'm quite happy to fail to fix > >> the problem: the right answer to that is to improve the robustness of > >> the UA. > > > > +1 > > If the UA is stuffed then the user is totally and utterly stuffed anyway. > > In particular if the UA is stuffed then a forms based experience is just > as > > stuffed. If we are going to hypothecate attack models people have to be > > willing to apply them to their preferred solution too. > > > > The sensible approach is to work out how to stop the user from being > stuffed > > e.g. > > * Comodo's free Anti-Virus with Default Deny Protection (TM) > > * Use code signing + trustworthy computing > > * Use a restricted browser > > Now I have a lot of ideas on how we can tackle these, but they are not > > relevant to this debate. > > > > I do however have a different take on the UI issue. > > HTML forms did have an advantage over the pathetic UI that browsers > provided > > for BASIC and DIGEST (most don't even tell the user which is in use). > > But a federated auth scheme supported at the HTTP level could be simpler > > still. Instead of the user having to register for each site, they > register > > once. Instead of the user having to log in to each site they log in once > per > > session. Instead of the site having to manage lost passwords and > forgotten > > accounts because the user has hundreds, this problem does not exist. > > > > It is a user interface crisis that is driving this need in my view. > > > > -- > > Website: http://hallambaker.com/ > > > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > -- Website: http://hallambaker.com/ --0016e644dbc6f623100499596635 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable OAUTH and Webfinger are both pretty much as good as you can expect to achie= ve if you decide at the start that you are not going to modify the infrastr= ucture.

But that decision limits what you can expect to = achieve.


A particular problem with OAuth is that = you can only use the identity providers that are supported by the particula= r site. So I had to use my Twitter account to play spymaster. And when Twit= ter got shirty and started blocking other players accounts they lost their = game account and their twitter account at the same time.

There are people who think I should get a facebook acco= unt just so that I can use their application. Not happening.

=

As for WebFinger, it works, but not nearly as wel= l as a clean DNS scheme. DNS is designed to address this problem, HTTP is n= ot. And solving the problem with HTTP requires us to have a scheme that inv= olves DNS + HTTP + SSL + PKIX which is rather a lot of moving parts and to = make matters work some those parts are not just moving, they are changing.<= /div>


I think it is a very good idea to look a= t WebFinger and OAuth and see how to realize these approaches direct in the= infrastructure. But they should be seen as starting points, not ends.


On Sat, Jan 8, 2011 at 12:37 PM, Bl= aine Cook <romeda@= gmail.com> wrote:
Two points:

1. In this entire thread, no-one has mentioned OAuth. Maybe y'all
don't like it, but it's used to authenticate more HTTP requests by<= br> volume and users than everything-except-cookies combined. You may want
to consider the design of OAuth when proceeding with these
discussions, rather than the laundry list of [completely] failed
protocols.

2. With respect to federated auth, especially using email address-like
identifiers, there has been a bevy of (deployed) work in this regard.
The effort is called webfinger, and is worth a look. Instead of DNS,
we use host-meta based HTTP lookups to dereference the identifiers.
Many diaspora and status.ne= t installs are using it today, and there
are several proposals towards building a security & privacy
infrastructure on top of webfinger (webid is one such proposal whose
incorporation of client-side TLS certificates in a browser context
makes me very weary of its potential for success).

b.

On 8 January 2011 08:21, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> On Thu, Jan 6, 2011 at 1:16 PM, Ben Laurie <benl@google.com> wrote:
>>
>> On 6 January 2011 16:03, David Morris <dwm@xpasc.com> wrote:
>> >
>> >
>> > On Thu, 6 Jan 2011, Ben Laurie wrote:
>> >
>> >> The answer to this problem is hard, since it brings us ba= ck to taking
>> >> the UI
>> >> out of the sites hands.
>> >
>> > Which is only helpful if you can somehow gaurantee that the u= ser agent
>> > software hasn't been compromised. Not something I'd b= et on...
>>
>> That's rather overstating it. It's perfectly helpful when = the UA
>> software hasn't been compromised, which is a non-zero fraction= of the
>> time.
>>
>> When the UA s/w has been compromised I'm quite happy to fail t= o fix
>> the problem: the right answer to that is to improve the robustness= of
>> the UA.
>
> +1
> If the UA is stuffed then the user is totally and utterly stuffed anyw= ay.
> In particular if the UA is stuffed then a forms based experience is ju= st as
> stuffed. If we are going to hypothecate attack models people have to b= e
> willing to apply them to their preferred solution too.
>
> The sensible approach is to work out how to stop the user from being s= tuffed
> e.g.
> =A0* Comodo's free Anti-Virus with Default Deny Protection (TM) > =A0* Use code signing + trustworthy computing
> =A0* Use a restricted browser
> Now I have a lot of ideas on how we can tackle these, but they are not=
> relevant to this debate.
>
> I do however have a different take on the UI issue.
> HTML forms did have an advantage over the pathetic UI that browsers pr= ovided
> for BASIC and DIGEST (most don't even tell the user which is in us= e).
> But a federated auth scheme supported at the HTTP level could be simpl= er
> still. Instead of the user having to register for each site, they regi= ster
> once. Instead of the user having to log in to each site they log in on= ce per
> session. Instead of the site having to manage lost passwords and forgo= tten
> accounts because the user has hundreds, this problem does not exist. >
> It is a user interface crisis that is driving this need in my view. >
> --
> Website: http://= hallambaker.com/
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>



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

--0016e644dbc6f623100499596635-- From dwm@xpasc.com Thu Jan 6 08:01:50 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C72A63A6EFF; Thu, 6 Jan 2011 08:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 n202LIwHccwW; Thu, 6 Jan 2011 08:01:49 -0800 (PST) Received: from mail.xpasc.com (mail.xpasc.com [68.164.244.189]) by core3.amsl.com (Postfix) with ESMTP id 640053A6E48; Thu, 6 Jan 2011 08:01:49 -0800 (PST) Received: from bslepgate.xpasc.com (localhost.localdomain [127.0.0.1]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id CDB7510058A; Thu, 6 Jan 2011 08:03:55 -0800 (PST) X-Propel-Return-Path: Received: from mail.xpasc.com ([10.1.2.88]) by [127.0.0.1] ([127.0.0.1]) (port 7027) (Abaca EPG outproxy filter 3.1.2.exported $Rev: 9262 $) id iz6Urb16g3T0; Thu, 06 Jan 2011 08:03:55 -0800 Received: from xpasc.com (egate.xpasc.com [10.1.2.49]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id 97631100585; Thu, 6 Jan 2011 08:03:55 -0800 (PST) Received: from egate.xpasc.com (egate.xpasc.com [10.1.2.49]) by xpasc.com (8.13.8/8.13.8) with ESMTP id p06G3shY018211; Thu, 6 Jan 2011 08:03:54 -0800 Date: Thu, 6 Jan 2011 08:03:54 -0800 (PST) From: David Morris In-Reply-To: Message-ID: References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Propel-ID: iz6Urb16g3T0 X-Mailman-Approved-At: Sat, 08 Jan 2011 14:43:38 -0800 Cc: "apps-discuss@ietf.org" , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [http-auth] [websec] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 16:01:50 -0000 On Thu, 6 Jan 2011, Ben Laurie wrote: > The answer to this problem is hard, since it brings us back to taking the UI > out of the sites hands. Which is only helpful if you can somehow gaurantee that the user agent software hasn't been compromised. Not something I'd bet on... From marsh@extendedsubset.com Sat Jan 8 13:31:00 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05D5A3A683E; Sat, 8 Jan 2011 13:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 X4bPP+UTK2H0; Sat, 8 Jan 2011 13:30:58 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 493D93A683C; Sat, 8 Jan 2011 13:30:58 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1PbgPH-000IjG-DU; Sat, 08 Jan 2011 21:33:03 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id BB8EB603D; Sat, 8 Jan 2011 21:33:00 +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/yNdr6BhRuIy23ofn2b5a1o+UJfu2Keao= Message-ID: <4D28D80B.2020006@extendedsubset.com> Date: Sat, 08 Jan 2011 15:32:59 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 08 Jan 2011 14:43:45 -0800 Cc: "apps-discuss@ietf.org" , "Roy T. Fielding" , websec , Robert Sayre , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , Ben Laurie , "ietf-http-wg@w3.org Group" Subject: Re: [http-auth] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 21:31:00 -0000 On 01/08/2011 10:07 AM, Phillip Hallam-Baker wrote: > I think that Ben is right that we are solving the wrong problem. I think Ben is nearly always right. :-) But let me toss out a different perspective. I'll try carefully and hope that this doesn't come across as trolling, but it is a bit contrarian (hopefully in a good way). > The problem is that users are asked to maintain accounts at literally > HUNDREDS of accounts. > > And some cretins, some utter morons, some bog-brained berks think it is > reasonable to tell the user to have a different password for every one! Such users have asked to do business with hundreds of entities, so at least something is working right. The user is free to use the same password everywhere (more convenient), or use a different password at every site (more secure). Many users like to set up "domains of password re-use" among several like-sites. The user is free to decide the point on the trade-off that works for them. I use a different password for everything. I write them down on blank business cards and keep them physically secure. I have taught some small children to use this scheme and they have no trouble with it. Most web browsers and sites remember the passwords anyway so the paper is really just backup. > I can't remember the account names, the password is easy as I only had > one (for non financial) - until those cretins at Gawker screwed up. Now > I have to reset my password at all those places. So you had decided on a coarse-grained scheme: financial and non-financial. Seems reasonable on the surface. Say you have a dozen sites across which you share a password. These sites are really secure - let's estimate the probability that each one will be breached or compromised or you will accidentally login unencrypted from a public internet location is only 1 in 10 per year. Hey a 90% success rate isn't bad, right? But the probability that they will all succeed is 0.9^12 = 28% over a year. Expect to be changing that password every few months. In the case of "HUNDREDS of accounts", 0.9^200 = 0.000000001. Well, those of the sort of odds you're supposed to serve the attacker, not yourself. > We have to solve the federated auth problem and it is really, really easy: No, it borders on the impossible. > Account Name is the RFC 821/822 email address. > > This is what the Web has started to adopt of its own accord as a > user account identifier. It is the only one that people can remember > reliably. Which is why everyone just has one email address? Come on, most people have several. And often they do so for a reason, it's not just that people get new ISPs or switch for new features all the time. I train my kids to lie about their names and ages when they do stuff online. They don't have emails. You don't have a personal email and a work email at least? > Authentication service is resolved via DNS service lookup > i.e. SRV or similar. I can show people how to fix up the issues to > do with use of non-canonical names. [skipping a bunch of technical stuff] > I know that you can achieve some of the desired authentication > properties with public keys at the client. The problem is that our > current use of computers has gone way beyond the one-machine-per-person > paradigm > On a recent trip to Europe with the family I counted that we had 10 > computers with us capable of supporting IP (3 laptops, 3 iPhones, 2 > Nintendos, 1 iPad and a kindle). It was only a brief period in the history of computing that might have ever been true anyway. Before networks "user identity" hardly mattered. Immediately after networks, we got heterogeneous networks. As soon as heterogeneous networks arrived, we got single sign-on. I think the deeper problem today is that most people looking at the issue are coming from the service provider side. Their job is made greatly simpler if they can assume 1 user = 1 person = 1 email etc. So they make this assumption as much as they can get away with it. But the reality is that people don't work that way. Historically, people have had multiple identities and they presented themselves differently to different parties. This is intentional and it's not duplicitous, its part of normal social interaction. When you discuss business matters at work you give out a business card with a business phone number and address on it. When you meet people at church or school, you give people your home phone. Your home phone and address were the ones printed in the directory. So the fact that "a person" has more than one "device" is not the big problem (that's actually sometimes a desperate solution from the perspective of the user). The problem for the service provider is that they don't want to give up the simplifying assumption (and the behavioral tracking it enables) that a real person represents an atomic unit of identity. Aside from the brittleness of their security, this is one reason why centralized identity, top-down federated authentication and single-sign-on schemes are not a good plan for the web. They don't accurately model the problem domain. These schemes originated for use in corporate and university settings which, at the end of the day, have all of the protected resources owned by a single party. The universal ritual for everyone's first day at a new job is the granting of a new username, password, and email identity for use in that specific context. So single sign-on was designed so that one person could be granted access to, say, the file server, email, printer, and maybe the phone system, all within the restricted context of their "employee-ness" at one specific company. Even though multiple systems are involved, it's still fundamentally a one-to-one relationship between two identities, the person-as-employee and the company-as-employer. This doesn't map to the web with multiple persons each needing to control the mapping of their own multiple identities to multiple corporations. I don't want to pull out my US State Department-issued passport in order to leave a comment on some random blog or log into an online game. I don't want to use any of my gmail addresses for that either. Bad things happen when you force-fit the wrong model on to the design. Security and privacy are always the first to go. (Somewhere I saw the other day somebody seriously proposing using Facebook as a centralized identity authority.) More subtly, people find the system harder to use, and overall they just don't like it or trust it as much. People won't use it, or they'll use it and not like it, or they won't use it as much, or they'll figure out a way to defeat it. > Cardspace has some really, really great properties but they are totally > lost when you try to make the service accessible from multiple machines > by putting it 'in the cloud'. In fact, other than a manager, I have > never found anyone who reven thinks they know what they mean by 'in the > cloud' for CardSpace. I certainly have never seen an explanation I can > understand. Cloud is largely an experiment in making unwarranted assumptions about identity in the other direction: between the corporation and their devices. > Devices get lost. Devices get stolen. My impression is that lost and stolen devices are significant, but they're by far not the biggest security issue on the web. > We don't want to encourage that so > there needs to be something more than just a certificate based client > auth scheme. > > I think we need some form of centralized (for given account) account > management in the mix so that the user can authorize/deauthorize devices > for use (c.f. Amazon's Kindle account management) You're not going to create everybody's favorite web authentication infrastructure if it has the goal of controlling people use of their own devices. > So there are basically two architectural options for using public key. > One is to use it strictly between the client and the auth service and > use a token like approach as discussed above. Another is for the auth > service to issue an assertion of the form 'you can tell its fred by this > public key (amongst others)'. > SAML already has support for both approaches BTW. Forget the wants of corporations and websites, they exist only because of their customers and users who outnumber them a millionfold. Forget mechanisms for now, those are simple engineering once the problem is stated correctly. What do people want to do? What would they want to do if they knew to ask for it? How can we help them do it in the most secure way possible? How can we give people the tools to manage their own identities and make their own security-convenience trade-offs in the most informed way? Regards, - Marsh From romeda@gmail.com Sat Jan 8 09:35:35 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B324D3A67B5; Sat, 8 Jan 2011 09:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.349 X-Spam-Level: X-Spam-Status: No, score=-103.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 K1de9OjHbzeT; Sat, 8 Jan 2011 09:35:34 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id E3BA93A67AD; Sat, 8 Jan 2011 09:35:17 -0800 (PST) Received: by wyf23 with SMTP id 23so19276867wyf.31 for ; Sat, 08 Jan 2011 09:37:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=K/xHYytBU+XmnS87+Mqw5HmwQyDfHfNbg8QAUiR6Wps=; b=FU7xxzQDcdWQZzLfDdqfAvH5LhwNpJwDoV5kMBUDLVRqgOtgxKKTgb6scom9ELoz5U TTUnuSDNxTuODZ0ZYkw4PPEB1/Ot7pTnPBnHfVpfQRaOQEPNhr+aVxRElpsF7dqxUPEL 2bsgcy/+LYq9A9JDJzhkxvmFOqzeQlzPCk0Z8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=gNBj6PYnDHrSnvc/htfrh9KcFkHuYGy9L16H7r83JLBiGwvaWyy+HhTTfx+0WR5UXs HnoZAXB8V/u5aA50esEsA1o+wr6xcDrbrPLaZ3BQq8t8JI83jyVDCHhRiAP+n7TcVTDM j0SN1HZkPd+tBnieT7PjD7bisA2tRMECNkIJk= Received: by 10.216.59.143 with SMTP id s15mr410638wec.49.1294508241087; Sat, 08 Jan 2011 09:37:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.240.197 with HTTP; Sat, 8 Jan 2011 09:37:00 -0800 (PST) In-Reply-To: References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> From: Blaine Cook Date: Sat, 8 Jan 2011 09:37:00 -0800 Message-ID: To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 08 Jan 2011 14:43:51 -0800 Cc: "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , Ben Laurie , "ietf-http-wg@w3.org Group" Subject: Re: [http-auth] [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 17:35:35 -0000 Two points: 1. In this entire thread, no-one has mentioned OAuth. Maybe y'all don't like it, but it's used to authenticate more HTTP requests by volume and users than everything-except-cookies combined. You may want to consider the design of OAuth when proceeding with these discussions, rather than the laundry list of [completely] failed protocols. 2. With respect to federated auth, especially using email address-like identifiers, there has been a bevy of (deployed) work in this regard. The effort is called webfinger, and is worth a look. Instead of DNS, we use host-meta based HTTP lookups to dereference the identifiers. Many diaspora and status.net installs are using it today, and there are several proposals towards building a security & privacy infrastructure on top of webfinger (webid is one such proposal whose incorporation of client-side TLS certificates in a browser context makes me very weary of its potential for success). b. On 8 January 2011 08:21, Phillip Hallam-Baker wrote: > On Thu, Jan 6, 2011 at 1:16 PM, Ben Laurie wrote: >> >> On 6 January 2011 16:03, David Morris wrote: >> > >> > >> > On Thu, 6 Jan 2011, Ben Laurie wrote: >> > >> >> The answer to this problem is hard, since it brings us back to taking >> >> the UI >> >> out of the sites hands. >> > >> > Which is only helpful if you can somehow gaurantee that the user agent >> > software hasn't been compromised. Not something I'd bet on... >> >> That's rather overstating it. It's perfectly helpful when the UA >> software hasn't been compromised, which is a non-zero fraction of the >> time. >> >> When the UA s/w has been compromised I'm quite happy to fail to fix >> the problem: the right answer to that is to improve the robustness of >> the UA. > > +1 > If the UA is stuffed then the user is totally and utterly stuffed anyway. > In particular if the UA is stuffed then a forms based experience is just = as > stuffed. If we are going to hypothecate attack models people have to be > willing to apply them to their preferred solution too. > > The sensible approach is to work out how to stop the user from being stuf= fed > e.g. > =C2=A0* Comodo's free Anti-Virus with Default Deny Protection (TM) > =C2=A0* Use code signing + trustworthy computing > =C2=A0* Use a restricted browser > Now I have a lot of ideas on how we can tackle these, but they are not > relevant to this debate. > > I do however have a different take on the UI issue. > HTML forms did have an advantage over the pathetic UI that browsers provi= ded > for BASIC and DIGEST (most don't even tell the user which is in use). > But a federated auth scheme supported at the HTTP level could be simpler > still. Instead of the user having to register for each site, they registe= r > once. Instead of the user having to log in to each site they log in once = per > session. Instead of the site having to manage lost passwords and forgotte= n > accounts because the user has hundreds, this problem does not exist. > > It is a user interface crisis that is driving this need in my view. > > -- > Website: http://hallambaker.com/ > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > From sayrer@gmail.com Wed Jan 5 17:26:08 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB5A13A6E4C; Wed, 5 Jan 2011 17:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] 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 kfd7k09rhiTF; Wed, 5 Jan 2011 17:26:07 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 1C1AE3A6DD2; Wed, 5 Jan 2011 17:26:03 -0800 (PST) Received: by gxk28 with SMTP id 28so7425497gxk.31 for ; Wed, 05 Jan 2011 17:28:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SmSGVsL3s1/e2mEs3LupI5w3onGShvZ4UtUrWrsZAvc=; b=oqDjO5l9OasDvMqhtSRG5lBW5ly/sZVMnAjtawLZzAl/3BcHvbwgxm2A7LZBaVcfMN a9KveWQYf85Hokfz/WOSIeHFo5vugc3VUbSZ4nX7FUN/VFYr034yQl2lg0qKaJj1Dl2p 0X6JN5ZqZ8eGZJ643GK1sl/rs515U1g7olm48= 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:content-transfer-encoding; b=MrgU77VixIxQZ2qTzxT40ypYmHsE2NSX6bk0ijTIlvi7TaDvo2k6K4qaw7P0+/hZSX clJhXNhTjD8ISKOAGHVBWw9YYGd3FJ6Qdm2ZMA4Z4qpL51b+FZmDyeKAjVv6EA5Y0kvH Vt1pSfmVsKKdhYbvPCUzUw5ewnPuywqbjy6UQ= MIME-Version: 1.0 Received: by 10.90.4.7 with SMTP id 7mr1387636agd.100.1294277289574; Wed, 05 Jan 2011 17:28:09 -0800 (PST) Received: by 10.90.133.12 with HTTP; Wed, 5 Jan 2011 17:28:08 -0800 (PST) In-Reply-To: <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> Date: Wed, 5 Jan 2011 20:28:08 -0500 Message-ID: From: Robert Sayre To: "Roy T. Fielding" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 08 Jan 2011 14:43:58 -0800 Cc: "apps-discuss@ietf.org" , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , Alexey Melnikov , "ietf-http-wg@w3.org Group" Subject: Re: [http-auth] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 01:26:09 -0000 > Peter Saint-Andre wrote: > 2. In 2007, Robert Sayre put together a few slides on the topic: > http://people.mozilla.com/~sayrer/2007/auth.html These are back on the Web, in case anyone missed them (probably not). On Sun, Dec 12, 2010 at 5:39 PM, Roy T. Fielding wrote: > > Define them all and let's have a bake-off. =A0It has been 16 years since > HTTP auth was taken out of our hands so that the security experts could > define something perfect. =A0Zero progress so far. Hard to disagree with this assessment. It's pretty easy to define something better than the current HTTP authentication mechanisms, but pretty hard to design something more popular than forms+cookies. I've looked at this problem a little bit, and I gather the strictly technical security properties we're looking for are pretty well understood. Deployment and presentation control are the tough parts. Presentation control is actually a security trade-off--to get the control web designers want, you have to present graphics before the server has been authenticated. Also, I suspect it will be difficult to deploy a new HTTP mechanism that can withstand replay and DoS attacks, unless proxy conformance gets a lot better. So, I think those advocating TLS-only solutions might turn out to win the day, but not because the security properties on offer are particularly compelling. I think the IETF might do better to focus on a smaller problem, at first. People often use self-signed certificates with HTTP/TLS, even though the first thing their websites ask the user to do is type a username and password into a form. There are some well-understood ways to make this process more secure. Why hasn't the IETF fixed this problem? If this smaller problem has no ready solution, then the larger issue of authentication on the entire Web seems like a tough nut to crack. It could be that the reasons for this lack of progress are nontechnical. Just throwing that out there. --=20 Robert Sayre "I would have written a shorter letter, but I did not have the time." From simon@josefsson.org Fri Jan 7 03:56:37 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 932173A681A; Fri, 7 Jan 2011 03:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 pf3ZVe7Hfli6; Fri, 7 Jan 2011 03:56:36 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 0B3843A6802; Fri, 7 Jan 2011 03:56:35 -0800 (PST) Received: from latte.josefsson.org ([213.115.69.138]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p07BwHLE016162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 7 Jan 2011 12:58:18 +0100 From: Simon Josefsson To: Yaron Sheffer References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <4D26CDB5.3090303__44301.5923993245$1294388684$gmane$org@gmail.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110107:yaronf.ietf@gmail.com::8nDH00IPo3MDcAi5:0OkO X-Hashcash: 1:22:110107:benl@google.com::dHOlZwuujRml5L2l:22Js X-Hashcash: 1:22:110107:ietf-http-wg@w3.org::rU0voKwWmjJ0QWHV:4WYj X-Hashcash: 1:22:110107:fielding@gbiv.com::t/XSArwNppLa4r67:8VPg X-Hashcash: 1:22:110107:websec@ietf.org::cdv3XLGXhP86BgxX:H38W X-Hashcash: 1:22:110107:sayrer@gmail.com::fmh47cJIN2zlmH47:Ki/j X-Hashcash: 1:22:110107:http-auth@ietf.org::N8uIJ3hvQ1W7Sazv:X+gA X-Hashcash: 1:22:110107:kitten@ietf.org::FgG+yHbN3JD0r9Uq:kmyB Date: Fri, 07 Jan 2011 12:57:29 +0100 In-Reply-To: <4D26CDB5.3090303__44301.5923993245$1294388684$gmane$org@gmail.com> (Yaron Sheffer's message of "Fri, 07 Jan 2011 10:24:21 +0200") Message-ID: <87lj2xj592.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean X-Mailman-Approved-At: Sat, 08 Jan 2011 14:44:01 -0800 Cc: "Roy T. Fielding" , websec , Robert Sayre , "kitten@ietf.org" , "http-auth@ietf.org" , "ietf-http-wg@w3.org Group" , Ben Laurie Subject: Re: [http-auth] [websec] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 11:56:37 -0000 One way to mitigate the dictionary attack problem is to do PBKDF#2 processing of the password before it hits TLS-PSK. However I agree that TLS-SRP have superior properties, and it is widely implemented. There is no practical reason to prefer TLS-PSK over TLS-PSK for password-based TLS authentication. One issue is that RFC 5054 is Informational rather than Standards Track (same issue as for TLS-OpenPGP), which is due to political reasons. /Simon Yaron Sheffer writes: > [Culling down the mailing lists] > > Hi Ben, > > No, RFC 4279 should not be used with (a hash of) human-memorable > passwords, because it would be vulnerable to dictionary attacks. See > http://tools.ietf.org/html/rfc4279#section-7.2. SRP, EKE and similar > schemes should be used instead. > > Thanks, > Yaron > > On 01/06/2011 05:31 PM, Ben Laurie wrote: > [...] > >> >> >> Two comments (one really being a response to Roy): >> >> 1. The IETF has fixed the problem, but no-one is using the fix - perhaps >> because it is not clear that it is the fix. I speak of RFC 4279, TLS >> pre-shared keys. These could be derived from a hash of the password and >> the site name, for example, and thus provide secure mutual >> authentication despite password reuse. >> > [...] From zedshaw@zedshaw.com Sat Jan 8 11:47:45 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 834943A6818; Sat, 8 Jan 2011 11:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.352 X-Spam-Level: X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RDNS_DYNAMIC=0.1] 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 gH1qQ8WU6rNZ; Sat, 8 Jan 2011 11:47:44 -0800 (PST) Received: from mail.zedshaw.com (67-207-134-146.slicehost.net [67.207.134.146]) by core3.amsl.com (Postfix) with ESMTP id 562A03A6814; Sat, 8 Jan 2011 11:47:43 -0800 (PST) Received: by mail.zedshaw.com (Postfix, from userid 1000) id 55D6D1D87C1; Sat, 8 Jan 2011 11:49:52 -0800 (PST) Date: Sat, 8 Jan 2011 11:49:52 -0800 From: "Zed A. Shaw" To: Blaine Cook Message-ID: <20110108194952.GS12542@zedshaw> Mail-Followup-To: "Zed A. Shaw" , Blaine Cook , Phillip Hallam-Baker , Ben Laurie , "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" References: <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Sat, 08 Jan 2011 14:44:07 -0800 Cc: "apps-discuss@ietf.org" , Phillip Hallam-Baker , David Morris , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , Ben Laurie , "ietf-http-wg@w3.org Group" Subject: Re: [http-auth] [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 20:17:52 -0000 On Sat, Jan 08, 2011 at 09:37:00AM -0800, Blaine Cook wrote: > Two points: > > 1. In this entire thread, no-one has mentioned OAuth. Maybe y'all > don't like it, but it's used to authenticate more HTTP requests by > volume and users than everything-except-cookies combined. You may want > to consider the design of OAuth when proceeding with these > discussions, rather than the laundry list of [completely] failed > protocols. I don't normally respond, just being a lurker, but this statement is competely wrong Blaine. OAuth may be used for more requests, but not more sites. It's used on a tiny number of sites, with OpenID being used on way many more, and even then, not nowhere near the number of websites that form based authentication and browser authentication methods. Don't equate twitter having a ton of traffic to OAuth being some kind of raving success, and sure as hell don't evaluate the technical merits of something by its popularity. > 2. With respect to federated auth, especially using email address-like > identifiers, there has been a bevy of (deployed) work in this regard. > The effort is called webfinger, and is worth a look. Instead of DNS, > we use host-meta based HTTP lookups to dereference the identifiers. > Many diaspora and status.net installs are using it today, and there > are several proposals towards building a security & privacy > infrastructure on top of webfinger (webid is one such proposal whose > incorporation of client-side TLS certificates in a browser context > makes me very weary of its potential for success). While I agree that TLS client side isn't going to work, none of the proposed authentication methods will work without a change to browsers to support a way for two websites to establish a session in the browser. If that feature existed you would cut down on a lot of the complexity of things like OpenID and OAuth. -- Zed A. Shaw http://zedshaw.com/ From romeda@gmail.com Sat Jan 8 17:27:45 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 878EC28C157; Sat, 8 Jan 2011 17:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.349 X-Spam-Level: X-Spam-Status: No, score=-104.349 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 1CHuczRPWZBj; Sat, 8 Jan 2011 17:27:43 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 716E728C0D8; Sat, 8 Jan 2011 17:27:42 -0800 (PST) Received: by wwa36 with SMTP id 36so18596520wwa.13 for ; Sat, 08 Jan 2011 17:29:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=afxLGSrBPz4bvHwp6VG7sozjob/7t1YO0xeVPH7/4wU=; b=LAQdyT9SddL8nJPhVQM29j6ZoZWBU/E9RdL3dcQirexwAxBPozXDZ7R8vOxplF5rDX pFjcIvOVsoXraVaAoigoriOzby1Vb5bpOibBUZFxefgem0XrfG3Rn9ZgZZb3HPJCgqNi R8mjqJHHWIO0driOK5UwZbhB8m9IcGUiv4KRQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=W00D/vRaeMJ9JFN6mWMx9sDgFjHR+OAwMhDTnEtxnjcdIaIr5rkVlZ7DByNvMeDYzG 5/zSOQnpfLw3pRace51aLC/URn3bISpnzt4Im8calKLP9JFUc4/cInuXHJkc/AsqHLnA Cp3q0SjBiSJ/ix2U6AtTOIZ27Ltj1Pjqyu1Q0= Received: by 10.216.142.101 with SMTP id h79mr26233429wej.49.1294536590896; Sat, 08 Jan 2011 17:29:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.240.197 with HTTP; Sat, 8 Jan 2011 17:29:29 -0800 (PST) In-Reply-To: <20110108194952.GS12542@zedshaw> References: <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <20110108194952.GS12542@zedshaw> From: Blaine Cook Date: Sat, 8 Jan 2011 17:29:29 -0800 Message-ID: To: "Zed A. Shaw" , Blaine Cook , Phillip Hallam-Baker , Ben Laurie , "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 08 Jan 2011 20:31:22 -0800 Subject: Re: [http-auth] [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 01:27:45 -0000 On 8 January 2011 11:49, Zed A. Shaw wrote: > On Sat, Jan 08, 2011 at 09:37:00AM -0800, Blaine Cook wrote: > I don't normally respond, just being a lurker, but this statement is > competely wrong Blaine. =C2=A0OAuth may be used for more requests, but no= t > more sites. =C2=A0It's used on a tiny number of sites, with OpenID being = used > on way many more, and even then, not nowhere near the number of websites > that form based authentication and browser authentication methods. > > Don't equate twitter having a ton of traffic to OAuth being some kind of > raving success, and sure as hell don't evaluate the technical merits of > something by its popularity. Agreed - though, facebook is also using oauth-based (not 1.0, but essentially the same approach) logins, and there are a number of other sites that do provide oauth-based login infrastructure. Moreover, the nudge towards oauth is intended with the movement towards a new auth infrastructure in mind. We'd need some kind of discovery / negotiation mechanism on top to make it not the one-or-two-companies-own-the-web play that login-over-oauth is now. (c.f. OpenID Connect). b. > While I agree that TLS client side isn't going to work, none of the > proposed authentication methods will work without a change to browsers > to support a way for two websites to establish a session in the browser. > If that feature existed you would cut down on a lot of the complexity of > things like OpenID and OAuth. Again, agreed. ;-) for the record, I don't think that OAuth itself is a suitable replacement for HTTP authorisation, but wanted to stir the pot, especially away from overwrought technical solutions that don't actually solve anyone's needs. b. From benl@google.com Sun Jan 9 05:42:05 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AA083A69A4 for ; Sun, 9 Jan 2011 05:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.834 X-Spam-Level: X-Spam-Status: No, score=-103.834 tagged_above=-999 required=5 tests=[AWL=-0.857, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 zZcU8LJifwdF for ; Sun, 9 Jan 2011 05:42:04 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 852343A69AB for ; Sun, 9 Jan 2011 05:42:04 -0800 (PST) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id p09DiEGl019077 for ; Sun, 9 Jan 2011 05:44:14 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294580654; bh=/mk8a9m6BHBI1j9A8YYpAAJT3g0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=rBd7e5LDKWOIj5qUWv3wG0oA2pnQGelokPC4sYnssr7Zzj8vz/Z6UYrf25BqbH1/I wOBB+UrZDr/XjglaTzg2Q== Received: from vws10 (vws10.prod.google.com [10.241.21.138]) by kpbe14.cbf.corp.google.com with ESMTP id p09DiCwa013732 for ; Sun, 9 Jan 2011 05:44:12 -0800 Received: by vws10 with SMTP id 10so7299669vws.0 for ; Sun, 09 Jan 2011 05:44:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZRWqqE2GC4FvKBmajUqrY7ravsT74mc/cg/K4kzh7cM=; b=GcGbegD1O4aILaEJyw/n4kMpuLQjeb5LMacygSf0Zp49ph4nEnffspaTdOBCTWDX8Y A1EW0TKeMxpuyF7lmcZg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WX+kK4B4G3HeErl5S2/G/I1bA3Ykj3FXsZiU9f1dd+V96cJhNoRJYYontlCDmNFKW/ qNFiploG2G8enySMzZHg== MIME-Version: 1.0 Received: by 10.220.202.131 with SMTP id fe3mr8379018vcb.183.1294580652479; Sun, 09 Jan 2011 05:44:12 -0800 (PST) Received: by 10.220.88.137 with HTTP; Sun, 9 Jan 2011 05:44:12 -0800 (PST) In-Reply-To: References: <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <20110108194952.GS12542@zedshaw> Date: Sun, 9 Jan 2011 13:44:12 +0000 Message-ID: From: Ben Laurie To: Blaine Cook Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Mailman-Approved-At: Sun, 09 Jan 2011 10:31:44 -0800 Cc: "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "Zed A. Shaw" , "http-auth@ietf.org" , "saag@ietf.org" , Phillip Hallam-Baker , "ietf-http-wg@w3.org Group" Subject: Re: [http-auth] [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 13:42:05 -0000 On 9 January 2011 01:29, Blaine Cook wrote: > On 8 January 2011 11:49, Zed A. Shaw wrote: >> On Sat, Jan 08, 2011 at 09:37:00AM -0800, Blaine Cook wrote: >> I don't normally respond, just being a lurker, but this statement is >> competely wrong Blaine. =A0OAuth may be used for more requests, but not >> more sites. =A0It's used on a tiny number of sites, with OpenID being us= ed >> on way many more, and even then, not nowhere near the number of websites >> that form based authentication and browser authentication methods. >> >> Don't equate twitter having a ton of traffic to OAuth being some kind of >> raving success, and sure as hell don't evaluate the technical merits of >> something by its popularity. > > Agreed - though, facebook is also using oauth-based (not 1.0, but > essentially the same approach) logins, and there are a number of other > sites that do provide oauth-based login infrastructure. > > Moreover, the nudge towards oauth is intended with the movement > towards a new auth infrastructure in mind. We'd need some kind of > discovery / negotiation mechanism on top to make it not the > one-or-two-companies-own-the-web play that login-over-oauth is now. > (c.f. OpenID Connect). > > b. > >> While I agree that TLS client side isn't going to work, none of the >> proposed authentication methods will work without a change to browsers >> to support a way for two websites to establish a session in the browser. >> If that feature existed you would cut down on a lot of the complexity of >> things like OpenID and OAuth. > > Again, agreed. ;-) > > for the record, I don't think that OAuth itself is a suitable > replacement for HTTP authorisation, but wanted to stir the pot, > especially away from overwrought technical solutions that don't > actually solve anyone's needs. Towards ones that are ripe for phishing and have no privacy protections? I don't believe that's a good direction. From romeda@gmail.com Sun Jan 9 08:49:58 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92D3E3A677E; Sun, 9 Jan 2011 08:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.682 X-Spam-Level: X-Spam-Status: No, score=-104.682 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 E-915Pk+xrKV; Sun, 9 Jan 2011 08:49:57 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 806623A6816; Sun, 9 Jan 2011 08:49:56 -0800 (PST) Received: by wyf23 with SMTP id 23so19771279wyf.31 for ; Sun, 09 Jan 2011 08:52:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=WIm+nFsAde/ye4Tom3yY4aVsYWqIxOmEG0wpwlytdzI=; b=Clwy4B80sy6LoL3fprCaKqTJWjn5jUnpqvWX13saEtPhxSf5b7x8DxNHBQSjcDcjCd lfcG5pVl93HS5iW0GIedlgBOnavigJXk4i2/IydnDkOElogTRR0AhkBJJLExNslRhjcb 3VhXaddZVP6P01QaxCJX/3QLZLRMHhtPUbNbY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=SCyIoxVnZRbGdpwm6boOG67l5B48h3JNw3U4Qv7Uwv2Fgk2Zdex0rweQm3owUIDeF7 p6Z+OnAy9Cb1o11hDx+iBjjsxaDOGtwHOfDokx3hRjYxfdoNN0LQ+E37lyu16j3Dhpyk refSLACQIk5R32y/JZB1jn0f41uSaOrFKq+z4= Received: by 10.216.177.9 with SMTP id c9mr26823431wem.34.1294591283468; Sun, 09 Jan 2011 08:41:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.240.197 with HTTP; Sun, 9 Jan 2011 08:40:54 -0800 (PST) In-Reply-To: References: <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <20110108194952.GS12542@zedshaw> From: Blaine Cook Date: Sun, 9 Jan 2011 08:40:54 -0800 Message-ID: To: Ben Laurie Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Sun, 09 Jan 2011 10:31:44 -0800 Cc: "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "Zed A. Shaw" , "http-auth@ietf.org" , "saag@ietf.org" , Phillip Hallam-Baker , "ietf-http-wg@w3.org Group" Subject: Re: [http-auth] [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 16:49:58 -0000 > Towards ones that are ripe for phishing and have no privacy > protections? I don't believe that's a good direction. *shrug* If the alternative is Facebook handling everyone's logins, it can't get much worse, can it? b. From john-ietf@jck.com Sun Jan 9 10:19:58 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 261273A67DF; Sun, 9 Jan 2011 10:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.091 X-Spam-Level: X-Spam-Status: No, score=-103.091 tagged_above=-999 required=5 tests=[AWL=-0.492, BAYES_00=-2.599, 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 zf1MTOuKT715; Sun, 9 Jan 2011 10:19:57 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id A1B653A67D4; Sun, 9 Jan 2011 10:19:56 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Pbzu1-0009d1-SY; Sun, 09 Jan 2011 13:22:06 -0500 Date: Sun, 09 Jan 2011 13:22:04 -0500 From: John C Klensin To: Marsh Ray Message-ID: In-Reply-To: <4D28D80B.2020006@extendedsubset.com> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <4D28D80B.2020006@extendedsubset.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Sun, 09 Jan 2011 10:31:44 -0800 Cc: apps-discuss@ietf.org, "Roy T. Fielding" , websec , Robert Sayre , kitten@ietf.org, http-auth@ietf.org, saag@ietf.org, Ben Laurie , "ietf-http-wg@w3.org Group" Subject: Re: [http-auth] [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 18:19:58 -0000 --On Saturday, January 08, 2011 15:32 -0600 Marsh Ray wrote: > On 01/08/2011 10:07 AM, Phillip Hallam-Baker wrote: >> I think that Ben is right that we are solving the wrong >> problem. > > I think Ben is nearly always right. :-) > > But let me toss out a different perspective. I'll try > carefully and hope that this doesn't come across as trolling, > but it is a bit contrarian (hopefully in a good way). >... Well, actually, I think this is constructive, useful, and rather nicely describes the other side of the problem. I would add that one important variation on "Person = Identity = Email address" has historically involved the use of subaddresses. Not only do they help considerably with mail management (pretty much their original purpose) but they provide an additional (weak but convenient) measure against email fraud and identify theft attempts (if I know that mail from my bank is going to be addressed to "john+12345@example.com" because that is the only address they have, then it is pretty clear where mail that supposedly comes from them but is addressed to "john+LargeRetailer@example.com" should be routed. Obviously, if an address that is used for only one vendor or correspondent gets into the hands of a spammer, it is lots easier to fix that problem as well. Address-per-correspondent also makes password-per-correspondent much easier too. Lots of web sites and providers have been really resistant to that approach. I had assumed before this that the problem was just stupidity, but parts of your comments could be expanded to lead to the inference that having me use more than one address is not in their interests. Whatever becomes of that tradeoff, the IETF should not, IMO, be doing things that encourage them in directions that reduce our privacy and ability to control our identities. >... > Which is why everyone just has one email address? Come on, > most people have several. And often they do so for a reason, > it's not just that people get new ISPs or switch for new > features all the time. I train my kids to lie about their > names and ages when they do stuff online. They don't have > emails. > > You don't have a personal email and a work email at least? >... exactly. with the emphasis on "at least" >... > Bad things happen when you force-fit the wrong model on to the > design. Security and privacy are always the first to go. > (Somewhere I saw the other day somebody seriously proposing > using Facebook as a centralized identity authority.) More > subtly, people find the system harder to use, and overall they > just don't like it or trust it as much. People won't use it, > or they'll use it and not like it, or they won't use it as > much, or they'll figure out a way to defeat it. Indeed. In all of the really significant cases, probably the latter. If I had a nickel for every sticky note with a password (sometimes slightly-disguised) stuck to a screen... But those notes are precisely a workaround for "you have to change your password frequently, you can't share passwords between systems, and we will insist by various means that you passwords are strong and that a given password is not obviously derivable from its predecessors" policies. >... john From zedshaw@zedshaw.com Sun Jan 9 10:30:28 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D43043A682E; Sun, 9 Jan 2011 10:30:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.017 X-Spam-Level: X-Spam-Status: No, score=-1.017 tagged_above=-999 required=5 tests=[AWL=-1.369, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RDNS_DYNAMIC=0.1] 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 chFn4LkdQ-SK; Sun, 9 Jan 2011 10:30:27 -0800 (PST) Received: from mail.zedshaw.com (67-207-134-146.slicehost.net [67.207.134.146]) by core3.amsl.com (Postfix) with ESMTP id 0C01F3A67FB; Sun, 9 Jan 2011 10:30:25 -0800 (PST) Received: by mail.zedshaw.com (Postfix, from userid 1000) id 28BF81D87C1; Sun, 9 Jan 2011 10:32:37 -0800 (PST) Date: Sun, 9 Jan 2011 10:32:37 -0800 From: "Zed A. Shaw" To: Ben Laurie Message-ID: <20110109183236.GZ12542@zedshaw> Mail-Followup-To: "Zed A. Shaw" , Ben Laurie , Blaine Cook , Phillip Hallam-Baker , "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" References: <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <20110108194952.GS12542@zedshaw> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Sun, 09 Jan 2011 10:31:44 -0800 Cc: "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , Blaine Cook , Phillip Hallam-Baker , "ietf-http-wg@w3.org Group" Subject: Re: [http-auth] [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 18:30:29 -0000 On Sun, Jan 09, 2011 at 01:44:12PM +0000, Ben Laurie wrote: > > for the record, I don't think that OAuth itself is a suitable > > replacement for HTTP authorisation, but wanted to stir the pot, > > especially away from overwrought technical solutions that don't > > actually solve anyone's needs. > > Towards ones that are ripe for phishing and have no privacy > protections? I don't believe that's a good direction. Ripe for phishing? I must have missed a whole conversation in all this cross posting, because last I checked none of the proposed solutions prevent phishing. If you can phish one site you can phish another. It's not the sites or the protocol that causes phishing, or whether you've got a billion redirects or diffie-helman to the hilt. OpenID or Oauth or plain-old-form-auth don't prevent or cause phishing. What causes phishing is users have no idea that two websites are different. As proof of this, I present to you the ReadWriteWeb/Facebook Login fiasco: http://www.readwriteweb.com/archives/facebook_wants_to_be_your_one_true_login.php This article became the #1 search result for "facebook login" for a short period of time on google. Not only did the users not realize RWW was *not* the facebook login, but they created accounts, logged in, and then complained that they didn't like the new facebook in the article comments. Yes, they thought RWW was the new facebook. They are totally different websites, with different designs and purposes, yet people had no idea. You may say that's a small sample, but this was done unintentionally. RWW didn't even try to change their site. A determined attacker can go much much farther than just this with a purposeful design that mimics the facebook login. And, this was people *logging in* to facebook, effectively using their direct login (which is also the connect login). That shows right there they have no idea where they're logging in to what, and that OpenID, OAuth, or any auth system doesn't help them. -- Zed A. Shaw http://zedshaw.com/ From benl@google.com Sun Jan 9 11:24:30 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D3DD3A67FB for ; Sun, 9 Jan 2011 11:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.782 X-Spam-Level: X-Spam-Status: No, score=-103.782 tagged_above=-999 required=5 tests=[AWL=-0.805, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 30vJEwkVK-Ns for ; Sun, 9 Jan 2011 11:24:30 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 222F73A67D4 for ; Sun, 9 Jan 2011 11:24:29 -0800 (PST) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p09JQeBX027937 for ; Sun, 9 Jan 2011 11:26:41 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294601201; bh=P5fHISLk/lO2e3DNf66/oc7YEsw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Content-Type:Content-Transfer-Encoding; b=PuQmFlWbVYawOFrLTZ/LrUFAq55f+GfhsiVxF0YbjckWLJRi8y9K+Ixn8bn7bXsY+ LgsG/fMzVjVwa2Ljo4RtQ== Received: from vws6 (vws6.prod.google.com [10.241.21.134]) by wpaz9.hot.corp.google.com with ESMTP id p09JLZgS024729 for ; Sun, 9 Jan 2011 11:26:39 -0800 Received: by vws6 with SMTP id 6so7419535vws.6 for ; Sun, 09 Jan 2011 11:21:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=huqt9woLFjVdG0rNeZu+5K/N6b16t1pAHbnnc7jOhbE=; b=sDgpLwAvCSPX/1UhP1lfxPZeJThR7bpM+mQosqvme2HLR0gXUfChWxoo1RAN4X70ik A6mw1b4SxGFWnvfPfp+w== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=PcgNAAYdrsTihx9s+Vw7rPx3d7e6QjPs3bRNsD0aOk3tvZrb869ZxPlOzLtgTVgSEK XRAZf2E+CitZ3OWQwfBA== MIME-Version: 1.0 Received: by 10.220.200.13 with SMTP id eu13mr8472527vcb.148.1294600895187; Sun, 09 Jan 2011 11:21:35 -0800 (PST) Received: by 10.220.88.137 with HTTP; Sun, 9 Jan 2011 11:21:34 -0800 (PST) In-Reply-To: <20110109183236.GZ12542@zedshaw> References: <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <20110108194952.GS12542@zedshaw> <20110109183236.GZ12542@zedshaw> Date: Sun, 9 Jan 2011 19:21:34 +0000 Message-ID: From: Ben Laurie To: "Zed A. Shaw" , Ben Laurie , Blaine Cook , Phillip Hallam-Baker , "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Mailman-Approved-At: Sun, 09 Jan 2011 12:01:27 -0800 Subject: Re: [http-auth] [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 19:24:30 -0000 On 9 January 2011 18:32, Zed A. Shaw wrote: > On Sun, Jan 09, 2011 at 01:44:12PM +0000, Ben Laurie wrote: >> > for the record, I don't think that OAuth itself is a suitable >> > replacement for HTTP authorisation, but wanted to stir the pot, >> > especially away from overwrought technical solutions that don't >> > actually solve anyone's needs. >> >> Towards ones that are ripe for phishing and have no privacy >> protections? I don't believe that's a good direction. > > Ripe for phishing? =A0I must have missed a whole conversation in all this > cross posting, because last I checked none of the proposed solutions > prevent phishing. > > If you can phish one site you can phish another. =A0It's not the sites or > the protocol that causes phishing, or whether you've got a billion > redirects or diffie-helman to the hilt. =A0OpenID or Oauth or > plain-old-form-auth don't prevent or cause phishing. > > What causes phishing is users have no idea that two websites are > different. Whilst I do not disagree with this claim, you are wrong. There are protocols which effectively prevent phishing - so long as password entry is done in an unspoofable UI. I am sure that you will respond that UI can be spoofed as easily as a website can be, and I'm almost ready to agree with that, given that we still don't have a good answer to that, however, my one small ray of hope in this regard is that there's only one UI we need to make unspoofable as opposed to a million websites. And, what's more, we don't really need to invoke it every time a user logs in to a website - really what we want is for the user to authenticate to their device and have the device handle the rest. OpenID and OAuth are particularly nasty, even by today's standards, because they provide a trivial route for the phisher to do a perfect MitM attack on the IdP. From stpeter@stpeter.im Sun Jan 9 12:10:53 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F2523A681D for ; Sun, 9 Jan 2011 12:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.14 X-Spam-Level: X-Spam-Status: No, score=-102.14 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 ztxKJ6tNL6VR for ; Sun, 9 Jan 2011 12:10:52 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id DCD8F3A6811 for ; Sun, 9 Jan 2011 12:10:51 -0800 (PST) Received: from squire.local (dsl-251-175.dynamic-dsl.frii.net [216.17.251.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D3F43400EE; Sun, 9 Jan 2011 13:27:46 -0700 (MST) Message-ID: <4D2A16CD.30107@stpeter.im> Date: Sun, 09 Jan 2011 13:13:01 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Zed A. Shaw" , Ben Laurie , Blaine Cook , Phillip Hallam-Baker , David Morris , "http-auth@ietf.org" References: <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <20110108194952.GS12542@zedshaw> <20110109183236.GZ12542@zedshaw> In-Reply-To: <20110109183236.GZ12542@zedshaw> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010402060604000100020607" Subject: Re: [http-auth] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 20:10:54 -0000 This is a cryptographically signed message in MIME format. --------------ms010402060604000100020607 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 1/9/11 11:32 AM, Zed A. Shaw wrote: > On Sun, Jan 09, 2011 at 01:44:12PM +0000, Ben Laurie wrote: >>> for the record, I don't think that OAuth itself is a suitable >>> replacement for HTTP authorisation, but wanted to stir the pot, >>> especially away from overwrought technical solutions that don't >>> actually solve anyone's needs. >> >> Towards ones that are ripe for phishing and have no privacy >> protections? I don't believe that's a good direction. >=20 > Ripe for phishing? I must have missed a whole conversation in all this= > cross posting,=20 And please start cc'ing only http-auth@ietf.org, not all the other lists.= > because last I checked none of the proposed solutions > prevent phishing. I agree that performing a threat analysis for phishing attacks, and proposing solutions to reduce the attack surface, is quite out of scope for HTTP authentication, OAuth, etc. > If you can phish one site you can phish another. It's not the sites or= > the protocol that causes phishing, or whether you've got a billion > redirects or diffie-helman to the hilt. OpenID or Oauth or > plain-old-form-auth don't prevent or cause phishing. >=20 > What causes phishing is users have no idea that two websites are > different.=20 Or, indeed, that any given site is "the same" across time. Server certificates attempt to do this, but it's not clear to me how many nontechnical users understand certificates, either. > As proof of this, I present to you the ReadWriteWeb/Facebook > Login fiasco: >=20 > http://www.readwriteweb.com/archives/facebook_wants_to_be_your_one_true= _login.php >=20 > This article became the #1 search result for "facebook login" for a > short period of time on google. >=20 > Not only did the users not realize RWW was *not* the facebook login, bu= t > they created accounts, logged in, and then complained that they didn't > like the new facebook in the article comments. Yes, they thought RWW > was the new facebook. They are totally different websites, with > different designs and purposes, yet people had no idea. >=20 > You may say that's a small sample, but this was done unintentionally. > RWW didn't even try to change their site. A determined attacker can go= > much much farther than just this with a purposeful design that mimics > the facebook login. >=20 > And, this was people *logging in* to facebook, effectively using their > direct login (which is also the connect login). That shows right there= > they have no idea where they're logging in to what, and that OpenID, > OAuth, or any auth system doesn't help them. +1 Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms010402060604000100020607 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEw OTIwMTMwMVowIwYJKoZIhvcNAQkEMRYEFJt5DZHAde09OfHjEkV6dCK9r1QxMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCTgNeyvs3qHKYOTISfFAFbJEy8bdU0tZ+uFrrZdlNi/bz2hZ2zfpprJxjl iZc4CPHMFzFazgRK7+arNTDFAnbxiboAac4klHjHywevU67JN57XCmBroFWKzMdYJipLJBYd dO2bDSQKpFpCOc6DFtNCMggamOnBNioWN3wZlrEpH0vCcmTzwShjVmY5vxVvQlYAUTViNVkY Xrf+GL8w5KYHGsY/KFcW42kVcn52keTbcJfW6yU8CX+0W/lUQlEbyu3QjALgGbPLra4qOVeT SDq8SzBcJWmva3YpoHOLCTdnIDEOlAILLfFB7zlQjOZygtEqZK7o2h7Sgcd0yhF1fhL3AAAA AAAA --------------ms010402060604000100020607-- From zedshaw@zedshaw.com Sun Jan 9 12:14:17 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25F773A681D; Sun, 9 Jan 2011 12:14:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.017 X-Spam-Level: X-Spam-Status: No, score=-1.017 tagged_above=-999 required=5 tests=[AWL=-1.369, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RDNS_DYNAMIC=0.1] 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 SnMopMB45VYx; Sun, 9 Jan 2011 12:14:16 -0800 (PST) Received: from mail.zedshaw.com (67-207-134-146.slicehost.net [67.207.134.146]) by core3.amsl.com (Postfix) with ESMTP id 3E8FE3A6810; Sun, 9 Jan 2011 12:14:16 -0800 (PST) Received: by mail.zedshaw.com (Postfix, from userid 1000) id 864A91D87C1; Sun, 9 Jan 2011 12:16:27 -0800 (PST) Date: Sun, 9 Jan 2011 12:16:27 -0800 From: "Zed A. Shaw" To: Ben Laurie Message-ID: <20110109201627.GC12542@zedshaw> Mail-Followup-To: "Zed A. Shaw" , Ben Laurie , Blaine Cook , Phillip Hallam-Baker , "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" References: <20110108194952.GS12542@zedshaw> <20110109183236.GZ12542@zedshaw> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Sun, 09 Jan 2011 12:17:52 -0800 Cc: "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , Blaine Cook , Phillip Hallam-Baker , "ietf-http-wg@w3.org Group" Subject: Re: [http-auth] [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 20:14:17 -0000 On Sun, Jan 09, 2011 at 07:21:34PM +0000, Ben Laurie wrote: > Whilst I do not disagree with this claim, you are wrong. There are > protocols which effectively prevent phishing - so long as password > entry is done in an unspoofable UI. Alright, to avoid any "violent agreement", can you point me at any documentation you have on your proposed solution? -- Zed A. Shaw http://zedshaw.com/ From zedshaw@zedshaw.com Sun Jan 9 12:31:57 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4C853A684B for ; Sun, 9 Jan 2011 12:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.991 X-Spam-Level: X-Spam-Status: No, score=-0.991 tagged_above=-999 required=5 tests=[AWL=-1.943, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_23=0.6, RDNS_DYNAMIC=0.1] 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 BeRSfOcIjXpA for ; Sun, 9 Jan 2011 12:31:56 -0800 (PST) Received: from mail.zedshaw.com (67-207-134-146.slicehost.net [67.207.134.146]) by core3.amsl.com (Postfix) with ESMTP id 4B0503A684A for ; Sun, 9 Jan 2011 12:31:56 -0800 (PST) Received: by mail.zedshaw.com (Postfix, from userid 1000) id E7F291D87C1; Sun, 9 Jan 2011 12:34:07 -0800 (PST) Date: Sun, 9 Jan 2011 12:34:07 -0800 From: "Zed A. Shaw" To: Peter Saint-Andre Message-ID: <20110109203407.GF12542@zedshaw> References: <20110108194952.GS12542@zedshaw> <20110109183236.GZ12542@zedshaw> <4D2A16CD.30107@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D2A16CD.30107@stpeter.im> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "http-auth@ietf.org" , Blaine Cook , David Morris , Ben Laurie , Phillip Hallam-Baker Subject: Re: [http-auth] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 20:31:57 -0000 On Sun, Jan 09, 2011 at 01:13:01PM -0700, Peter Saint-Andre wrote: > And please start cc'ing only http-auth@ietf.org, not all the other lists. Oh, I'm sorry, I figure since this entire conversation has been cross posted into 9 mailing lists and people that everyone was just alright with the insane cross posting nobody really wants. If you can get everyone else to stop it then I'll more than gladly quit doing it. -- Zed A. Shaw http://zedshaw.com/ From hallam@gmail.com Sun Jan 9 13:30:40 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF9423A6836 for ; Sun, 9 Jan 2011 13:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 g3vi9gGsBw-L for ; Sun, 9 Jan 2011 13:30:38 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 64B803A681C for ; Sun, 9 Jan 2011 13:30:38 -0800 (PST) Received: by yie19 with SMTP id 19so5986985yie.31 for ; Sun, 09 Jan 2011 13:32:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=4/TNrKi/ibB5rgM6pqAEJMfRZCva7yJil1ycSbMszR4=; b=JUZM5yL9/1OAzuDjCXZOsE5FcPcQAvGFgbetW4mw60+tEzIJbuFROLd0xOGlqm/So9 CvYuKQPxX8q786LUgJkQqxe3d1SmJvuN6cAzza7XycBR+z9oSatLGH+DTUrIKTXrB2yL FMI36Eq6oC3fGAUfByqQV0UQ2uBkcyck2YhI0= 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=BpxFpTd2XRARAx3z09HbzuQ2MUEWADsfpGtPFgCuUBol/Z8dAr3r98zPLEoJefS1ml xJ5x/r3y4JKR2OTMwm9QKEMNFuo7OeBHgjExTyb+AF/NOFDVAW/Vnti3fo+sAcAsAg75 s0xG1IRKlURU7emJYcj1sS0h5Z2p2ta45g7K0= MIME-Version: 1.0 Received: by 10.100.93.6 with SMTP id q6mr4328204anb.69.1294608769818; Sun, 09 Jan 2011 13:32:49 -0800 (PST) Received: by 10.100.31.8 with HTTP; Sun, 9 Jan 2011 13:32:49 -0800 (PST) In-Reply-To: References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <4D28D80B.2020006@extendedsubset.com> Date: Sun, 9 Jan 2011 16:32:49 -0500 Message-ID: From: Phillip Hallam-Baker To: John C Klensin Content-Type: multipart/alternative; boundary=0016e6434bced9202c0499709758 Cc: http-auth@ietf.org Subject: Re: [http-auth] [websec] [apps-discuss] [saag] [kitten] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 21:30:40 -0000 --0016e6434bced9202c0499709758 Content-Type: text/plain; charset=ISO-8859-1 I think there is a big difference between having the ability to separate out accounts into separate buckets and having to remember what account identifier you used at a site because your preferred one turned out to be unavailable. What I think important is that the user experience a single account identifier. This need not require the same identifier be presented to the sites. For example, when I begin a session in the browser I might enter hallam@gmail.com but when I go to the site ietf.org they might see the identifier * hallam@gmail.com * ietf+hallam@gmail.com * 2983hwd989h23r298y293y23++@gmail.com<2983hwd989h23r298y293y23%2B%2B@gmail.com> The selection being made according to what I specify when I register with the site. In some cases I may want to use a universal identifier. In others I may wish the identifier to be linkable to my other identifiers but want data to be easily filtered/separated. In still others I may want the site to know nothing more about me than that I am the same person who visited previously and that I use a particular authentication service. The work/home thing gets us into the realm of implicit authorization since a very common requirement is to restrict access to people with accounts at a particular site. For example, I am currently permitted to access CABForum Web sites by virtue of my current employment. I most likely also have access to various sites round the net because I established an account when authorized under a previous employer who probably never knew to inform them that I am no longer authorized. So I can imagine cases where it would matter if I subscribed under an @ gmail.com account or @defaultdenysecurity.com or @comodo.com. If we are going to support this type of interaction it would imply that the protocol interaction is going to have to look something like: 1) Browser contacts site 2) Site tells browser that authentication is desired 3) Browser contacts user's active authentication services to see what accounts are registered 4) [Optional user interaction to ask what identity to use] 5) Browser provides selected credential to site Another possibility would be that the browser-site interaction would always make use of a blinded credential but that the site might be permitted to retrieve a profile that included a universal identifier of some sort. If I am registering for the Huffington post they can whistle for my mailing address. Contrawise if I am registering for UPS or DHL then I am quite likely to want them to know my mailing addresses. Note however that a 'profile' is not the same thing as an 'identity' since the first is a term that we can all understand and the second is a buzzword that leads to people talking piffle. On Sun, Jan 9, 2011 at 1:22 PM, John C Klensin wrote: > > > --On Saturday, January 08, 2011 15:32 -0600 Marsh Ray > wrote: > > > On 01/08/2011 10:07 AM, Phillip Hallam-Baker wrote: > >> I think that Ben is right that we are solving the wrong > >> problem. > > > > I think Ben is nearly always right. :-) > > > > But let me toss out a different perspective. I'll try > > carefully and hope that this doesn't come across as trolling, > > but it is a bit contrarian (hopefully in a good way). > >... > > Well, actually, I think this is constructive, useful, and rather > nicely describes the other side of the problem. > > I would add that one important variation on "Person = Identity = > Email address" has historically involved the use of > subaddresses. Not only do they help considerably with mail > management (pretty much their original purpose) but they provide > an additional (weak but convenient) measure against email fraud > and identify theft attempts (if I know that mail from my bank is > going to be addressed to "john+12345@example.com" > because that > is the only address they have, then it is pretty clear where > mail that supposedly comes from them but is addressed to > "john+LargeRetailer@example.com " should > be routed. Obviously, > if an address that is used for only one vendor or correspondent > gets into the hands of a spammer, it is lots easier to fix that > problem as well. > > Address-per-correspondent also makes password-per-correspondent > much easier too. > > Lots of web sites and providers have been really resistant to > that approach. I had assumed before this that the problem was > just stupidity, but parts of your comments could be expanded to > lead to the inference that having me use more than one address > is not in their interests. Whatever becomes of that tradeoff, > the IETF should not, IMO, be doing things that encourage them in > directions that reduce our privacy and ability to control our > identities. > > >... > > Which is why everyone just has one email address? Come on, > > most people have several. And often they do so for a reason, > > it's not just that people get new ISPs or switch for new > > features all the time. I train my kids to lie about their > > names and ages when they do stuff online. They don't have > > emails. > > > > You don't have a personal email and a work email at least? > >... > > exactly. with the emphasis on "at least" > > >... > > Bad things happen when you force-fit the wrong model on to the > > design. Security and privacy are always the first to go. > > (Somewhere I saw the other day somebody seriously proposing > > using Facebook as a centralized identity authority.) More > > subtly, people find the system harder to use, and overall they > > just don't like it or trust it as much. People won't use it, > > or they'll use it and not like it, or they won't use it as > > much, or they'll figure out a way to defeat it. > > Indeed. In all of the really significant cases, probably the > latter. If I had a nickel for every sticky note with a password > (sometimes slightly-disguised) stuck to a screen... But those > notes are precisely a workaround for "you have to change your > password frequently, you can't share passwords between systems, > and we will insist by various means that you passwords are > strong and that a given password is not obviously derivable from > its predecessors" policies. > > >... > > john > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > -- Website: http://hallambaker.com/ --0016e6434bced9202c0499709758 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think there is a big difference between having the ability to separate ou= t accounts into separate buckets and having to remember what account identi= fier you used at a site because your preferred one turned out to be unavail= able.


What I think important is that the user exper= ience a single account identifier. This need not require the same identifie= r be presented to the sites.

For example, when I b= egin a session in the browser I might enter hallam@gmail.com but when I go to the site ietf.org they might see the identifier


The selection being made according to what I specify wh= en I register with the site. In some cases I may want to use a universal id= entifier. In others I may wish the identifier to be linkable to my other id= entifiers but want data to be easily filtered/separated. In still others I = may want the site to know nothing more about me than that I am the same per= son who visited previously and that I use a particular authentication servi= ce.


The work/home thing gets us into the rea= lm of implicit authorization since a very common requirement is to restrict= access to people with accounts at a particular site.=A0

For example, I am currently permitted to access CABForum Web sites by = virtue of my current employment. I most likely also have access to various = sites round the net because I established an account when authorized under = a previous employer who probably never knew to inform them that I am no lon= ger authorized.


So I can imagine cases where it would ma= tter if I subscribed under an @gmail.com a= ccount or @defaultdenysecurity.c= om or @comodo.com.


If we are going to support this type of = interaction it would imply that the protocol interaction is going to have t= o look something like:

1) Browser contacts site
2) Site tells browser that authentication is desired
3) Brow= ser contacts user's active authentication services to see what accounts= are registered
4) [Optional user interaction to ask what identit= y to use]
5) Browser provides selected credential to site


Another possibility would be that the browser-site interaction would= always make use of a blinded credential but that the site might be permitt= ed to retrieve a profile that included a universal identifier of some sort.=

If I am registering for the Huffington post they can wh= istle for my mailing address. Contrawise if I am registering for UPS or DHL= then I am quite likely to want them to know my mailing addresses.


Note however that a 'profile' is= not the same thing as an 'identity' since the first is a term that= we can all understand and the second is a buzzword that leads to people ta= lking piffle.


On Sun, Jan 9, 2011 at 1= :22 PM, John C Klensin <john-ietf@jck.com> wrote:


--On Saturday, January 08, 2011 15:32 -0600 Marsh Ray
<marsh@extendedsubset.com> wrote:

> On 01/08/2011 10:07 AM, Phillip Hallam-Baker wrote:
>> I think that Ben is right that we are solving the wrong
>> problem.
>
> I think Ben is nearly always right. :-)
>
> But let me toss out a different perspective. I'll try
> carefully and hope that this doesn't come across as trolling,
> but it is a bit contrarian (hopefully in a good way).
>...

Well, actually, I think this is constructive, useful, and rather
nicely describes the other side of the problem.

I would add that one important variation on "Person =3D Identity =3D Email address" has historically involved the use of
subaddresses. =A0Not only do they help considerably with mail
management (pretty much their original purpose) but they provide
an additional =A0(weak but convenient) measure against email fraud
and identify theft attempts (if I know that mail from my bank is
going to be addressed to "= john+12345@example.com" because that
is the only address they have, then it is pretty clear where
mail that supposedly comes from them but is addressed to
"john+LargeRetaile= r@example.com" should be routed. =A0 Obviously,
if an address that is used for only one vendor or correspondent
gets into the hands of a spammer, it is lots easier to fix that
problem as well.

Address-per-correspondent also makes password-per-correspondent
much easier too.

Lots of web sites and providers have been really resistant to
that approach. =A0I had assumed before this that the problem was
just stupidity, but parts of your comments could be expanded to
lead to the inference that having me use more than one address
is not in their interests. =A0 =A0Whatever becomes of that tradeoff,
the IETF should not, IMO, be doing things that encourage them in
directions that reduce our privacy and ability to control our
identities.

>...
> Which is why everyone just has one email address? Come on,
> most people have several. And often they do so for a reason,
> it's not just that people get new ISPs or switch for new
> features all the time. I train my kids to lie about their
> names and ages when they do stuff online. They don't have
> emails.
>
> You don't have a personal email and a work email at least?
>...

exactly. =A0with the emphasis on "at least"

>...
> Bad things happen when you force-fit the wrong model on to the
> design. Security and privacy are always the first to go.
> (Somewhere I saw the other day somebody seriously proposing
> using Facebook as a centralized identity authority.) More
> subtly, people find the system harder to use, and overall they
> just don't like it or trust it as much. People won't use it, > or they'll use it and not like it, or they won't use it as
> much, or they'll figure out a way to defeat it.

Indeed. =A0In all of the really significant cases, probably the
latter. =A0If I had a nickel for every sticky note with a password
(sometimes slightly-disguised) stuck to a screen... =A0But those
notes are precisely a workaround for "you have to change your
password frequently, you can't share passwords between systems,
and we will insist by various means that you passwords are
strong and that a given password is not obviously derivable from
its predecessors" policies.

>...

=A0 john

_______________________________________________
websec mailing list
websec@ietf.org
= https://www.ietf.org/mailman/listinfo/websec



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

--0016e6434bced9202c0499709758-- From marsh@extendedsubset.com Sun Jan 9 13:05:34 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F29593A6845; Sun, 9 Jan 2011 13:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 RF7L6vdLdzC4; Sun, 9 Jan 2011 13:05:33 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 1441E3A682A; Sun, 9 Jan 2011 13:05:33 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1Pc2UI-000AWy-T8; Sun, 09 Jan 2011 21:07:43 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 02A48603E; Sun, 9 Jan 2011 21:07:39 +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+pKk0IBf7xKDzPcNEDSwquAheGbBpfV5Q= Message-ID: <4D2A239C.6040801@extendedsubset.com> Date: Sun, 09 Jan 2011 15:07:40 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Zed A. Shaw" , Ben Laurie , Blaine Cook , Phillip Hallam-Baker , "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" References: <20110108194952.GS12542@zedshaw> <20110109183236.GZ12542@zedshaw> <20110109201627.GC12542@zedshaw> In-Reply-To: <20110109201627.GC12542@zedshaw> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 09 Jan 2011 13:52:44 -0800 Subject: Re: [http-auth] [websec] [apps-discuss] [saag] [kitten] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 21:05:34 -0000 On 01/09/2011 02:16 PM, Zed A. Shaw wrote: > On Sun, Jan 09, 2011 at 07:21:34PM +0000, Ben Laurie wrote: >> Whilst I do not disagree with this claim, you are wrong. There are >> protocols which effectively prevent phishing - so long as password >> entry is done in an unspoofable UI. > > Alright, to avoid any "violent agreement", can you point me at any > documentation you have on your proposed solution? As you pointed out Zed, phishing isn't something that happens to a protocol or an application - it's something the user decides to do. Phishing can be said to have been prevented only when the user can be relied upon to refuse to enter his password into an insecure box. Now there may be some useful mitigations at the app or protocol level. For example, my bank asks for my username and then shows me a familiar picture (e.g., a rocking horse) that is supposed to prevent phishing. This stops phishing only in the sense that it requires the attacker to use a CGI proxy app rather than simple static phishing site. For some sites that probably cuts down on the rate of phishing attacks quite a bit. But something so easy to bypass is likely to depend on a steady supply of easier targets keeping the attackers busy. If I wanted that kind of security for my car, I should try to convince everyone else in town to leave theirs unlocked with the keys in the ignition. I don't think it will be useful against a determined, targeted attack. On 01/09/2011 02:13 PM, Peter Saint-Andre wrote: > > And please start cc'ing only http-auth@ietf.org, not all the other > lists. You're trying to convince users not to do something that the interface begs them to do, like hit 'reply all', or trying out every password they know. It's not part of the protocol. - Marsh From stpeter@stpeter.im Sun Jan 9 13:56:30 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16FD73A6847 for ; Sun, 9 Jan 2011 13:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.136 X-Spam-Level: X-Spam-Status: No, score=-102.136 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 AgNJkQm1WRO5 for ; Sun, 9 Jan 2011 13:56:28 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 7FFA33A6835 for ; Sun, 9 Jan 2011 13:56:28 -0800 (PST) Received: from squire.local (dsl-251-175.dynamic-dsl.frii.net [216.17.251.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 475DB400EE; Sun, 9 Jan 2011 15:13:23 -0700 (MST) Message-ID: <4D2A2F7C.502@stpeter.im> Date: Sun, 09 Jan 2011 14:58:20 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Marsh Ray References: <20110108194952.GS12542@zedshaw> <20110109183236.GZ12542@zedshaw> <20110109201627.GC12542@zedshaw> <4D2A239C.6040801@extendedsubset.com> In-Reply-To: <4D2A239C.6040801@extendedsubset.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060104050008000205040607" Cc: Phillip Hallam-Baker , David Morris , "http-auth@ietf.org" , Blaine Cook , Ben Laurie Subject: Re: [http-auth] [websec] [apps-discuss] [saag] [kitten] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 21:56:30 -0000 This is a cryptographically signed message in MIME format. --------------ms060104050008000205040607 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 1/9/11 2:07 PM, Marsh Ray wrote: > On 01/09/2011 02:16 PM, Zed A. Shaw wrote: >> On Sun, Jan 09, 2011 at 07:21:34PM +0000, Ben Laurie wrote: >>> Whilst I do not disagree with this claim, you are wrong. There are >>> protocols which effectively prevent phishing - so long as password >>> entry is done in an unspoofable UI. >> >> Alright, to avoid any "violent agreement", can you point me at any >> documentation you have on your proposed solution? >=20 > As you pointed out Zed, phishing isn't something that happens to a > protocol or an application - it's something the user decides to do. >=20 > Phishing can be said to have been prevented only when the user can be > relied upon to refuse to enter his password into an insecure box. >=20 > Now there may be some useful mitigations at the app or protocol level. > For example, my bank asks for my username and then shows me a familiar > picture (e.g., a rocking horse) that is supposed to prevent phishing. > This stops phishing only in the sense that it requires the attacker to > use a CGI proxy app rather than simple static phishing site. How about petnames? > For some sites that probably cuts down on the rate of phishing attacks > quite a bit. But something so easy to bypass is likely to depend on a > steady supply of easier targets keeping the attackers busy. If I wanted= > that kind of security for my car, I should try to convince everyone els= e > in town to leave theirs unlocked with the keys in the ignition. I don't= > think it will be useful against a determined, targeted attack. >=20 > On 01/09/2011 02:13 PM, Peter Saint-Andre wrote: >> >> And please start cc'ing only http-auth@ietf.org, not all the other >> lists. >=20 > You're trying to convince users not to do something that the interface > begs them to do, like hit 'reply all', or trying out every password the= y > know. It's not part of the protocol. Which is why I keep replying to messages in this thread and trimming the cc list as I do so. :) Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms060104050008000205040607 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEw OTIxNTgyMFowIwYJKoZIhvcNAQkEMRYEFOWLY6NIbHfaFIE7FLCAkFy1nMPiMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCrTSx32yAeX9GsNxcCvq342SxzTznN9JfQ5qIQwagUaL6+NBeNUfBtokw4 6klPxph4X02sRl1SDvZtYWnCwQc9O+mydO8KmPKmPvfDIxZ41ep+qItZSgCTf+ba1yu57QiW w+RkAg60smxMAMeGr/oqx9ONVa9rvwWV59mPa9OaJtIdAMQVk7gfVCJT1sIdz8RFB1BlXUqj 71rMrKQlFvSDk4zg1orDHxiOolkpi5Y2waSthAlTwC9YDQyI/foGc4p3IgrbwS3DiKgDQSMt OI8zuH7OqnTrry/R4dDR88U5/WhKymn9W20uq/2/VJ02LMtU1EWthlIRCalgrtb0m/DkAAAA AAAA --------------ms060104050008000205040607-- From benl@google.com Sun Jan 9 14:00:44 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CE1A3A6857 for ; Sun, 9 Jan 2011 14:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.135 X-Spam-Level: X-Spam-Status: No, score=-104.135 tagged_above=-999 required=5 tests=[AWL=-1.158, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 ztRTLH1nNdnY for ; Sun, 9 Jan 2011 14:00:43 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id E8E743A67D4 for ; Sun, 9 Jan 2011 14:00:42 -0800 (PST) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id p09M2sYt023647 for ; Sun, 9 Jan 2011 14:02:54 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294610574; bh=TWHYWRJmbXsEdJXtF0rqocPRcZw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Content-Type; b=NUCcYVT+Waec9wVbcd85XyIWYfHb+6aAHe8FwZuupvzbsmG6ia69KdxfJi4VY4R8p vQQ5vdaJvkpS7N6lmU37Q== Received: from vws12 (vws12.prod.google.com [10.241.21.140]) by hpaq7.eem.corp.google.com with ESMTP id p09M2q2o012443 for ; Sun, 9 Jan 2011 14:02:52 -0800 Received: by vws12 with SMTP id 12so7513605vws.4 for ; Sun, 09 Jan 2011 14:02:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=cOAabtG4p9SzwHBXcYT3YTdTNTFUyxmyT5EALZB15KY=; b=DB5ei9pRtVZupM85jfu+osbg6VCOLRNHjn83CewcQVLsKPMKYh18qorK321CAzGsV2 +a2prv7Yvz1ak1RpFrlQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=cVwHDWMIb1vFSEow0juZQxJOPsQqILXHrncyC1T/iUeoocdYpLVj7jdMwbGmAOZAEa IQYVYaWCWLbzMVwOpsnA== MIME-Version: 1.0 Received: by 10.220.200.13 with SMTP id eu13mr8511043vcb.148.1294610569844; Sun, 09 Jan 2011 14:02:49 -0800 (PST) Received: by 10.220.88.137 with HTTP; Sun, 9 Jan 2011 14:02:49 -0800 (PST) In-Reply-To: <20110109201627.GC12542@zedshaw> References: <20110108194952.GS12542@zedshaw> <20110109183236.GZ12542@zedshaw> <20110109201627.GC12542@zedshaw> Date: Sun, 9 Jan 2011 22:02:49 +0000 Message-ID: From: Ben Laurie To: "Zed A. Shaw" , Ben Laurie , Blaine Cook , Phillip Hallam-Baker , "apps-discuss@ietf.org" , David Morris , "http-auth@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: Re: [http-auth] [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 22:00:44 -0000 On 9 January 2011 20:16, Zed A. Shaw wrote: > On Sun, Jan 09, 2011 at 07:21:34PM +0000, Ben Laurie wrote: >> Whilst I do not disagree with this claim, you are wrong. There are >> protocols which effectively prevent phishing - so long as password >> entry is done in an unspoofable UI. > > Alright, to avoid any "violent agreement", can you point me at any > documentation you have on your proposed solution? Several have already been mentioned: EKE, SRP and zero-knowledge proofs in general. > > -- > Zed A. Shaw > http://zedshaw.com/ > From stpeter@stpeter.im Sun Jan 9 14:12:02 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F01FC3A67D4 for ; Sun, 9 Jan 2011 14:12:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, 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 hlynTgVu-Scs for ; Sun, 9 Jan 2011 14:12:00 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id CDD993A6847 for ; Sun, 9 Jan 2011 14:12:00 -0800 (PST) Received: from squire.local (dsl-251-175.dynamic-dsl.frii.net [216.17.251.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 19FE5400EE; Sun, 9 Jan 2011 15:28:55 -0700 (MST) Message-ID: <4D2A3331.6060603@stpeter.im> Date: Sun, 09 Jan 2011 15:14:09 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ben Laurie References: <20110108194952.GS12542@zedshaw> <20110109183236.GZ12542@zedshaw> <20110109201627.GC12542@zedshaw> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050507090700040808060400" Cc: "http-auth@ietf.org" , Blaine Cook , David Morris , Phillip Hallam-Baker Subject: Re: [http-auth] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 22:12:02 -0000 This is a cryptographically signed message in MIME format. --------------ms050507090700040808060400 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 1/9/11 3:02 PM, Ben Laurie wrote: > On 9 January 2011 20:16, Zed A. Shaw wrote: >> On Sun, Jan 09, 2011 at 07:21:34PM +0000, Ben Laurie wrote: >>> Whilst I do not disagree with this claim, you are wrong. There are >>> protocols which effectively prevent phishing - so long as password >>> entry is done in an unspoofable UI. >> >> Alright, to avoid any "violent agreement", can you point me at any >> documentation you have on your proposed solution? >=20 > Several have already been mentioned: EKE, SRP and zero-knowledge > proofs in general. True. Do we have running code with any of these for HTTP or other application technologies (e.g., TLS-SRP [RFC 5054] for IMAP or XMPP)? Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms050507090700040808060400 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEw OTIyMTQwOVowIwYJKoZIhvcNAQkEMRYEFK1odmfhf8QxbwUMC3PnosoJ4zpxMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQA0JDxRZLuk0qSPhmabLo5etEREcfwE9zcYqT0aqkuFcMXb/A8wzRSDr9Zg VPYa+7SFntfdLMDtmHsxdizFQxIHcRbxK00WjRfxffb5tX+KJEepEmnI0zoOKLoYV9Awf3at PI35Kg4eXLa8QhGC3pBce6wf81Qabp1UaW8T7ScG/2xl4BSOFebya/nG6X/pIpSfW+E/14Le kX/Qq+pcKPr/UCXsT+f0HfT0WrckI12ECUGHbXQjrVyFWZcS/XMsmbCoxV7QBbklle9Fo7R4 1/iPJud/Qq0fTKtqA6U1lNigpWUuwucSQG5AdYnXINV6El3QHmXsR0gAMNRsOzNP9amrAAAA AAAA --------------ms050507090700040808060400-- From dwm@xpasc.com Sun Jan 9 16:32:55 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 798183A6862 for ; Sun, 9 Jan 2011 16:32:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.115 X-Spam-Level: X-Spam-Status: No, score=-3.115 tagged_above=-999 required=5 tests=[AWL=-0.515, 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 ZDjeTdhWC7rS for ; Sun, 9 Jan 2011 16:32:54 -0800 (PST) Received: from mail.xpasc.com (mail.xpasc.com [68.164.244.189]) by core3.amsl.com (Postfix) with ESMTP id A10E53A6860 for ; Sun, 9 Jan 2011 16:32:54 -0800 (PST) Received: from bslepgate.xpasc.com (localhost.localdomain [127.0.0.1]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id E68B1100585; Sun, 9 Jan 2011 16:35:06 -0800 (PST) X-Propel-Return-Path: Received: from mail.xpasc.com ([10.1.2.88]) by [127.0.0.1] ([127.0.0.1]) (port 7027) (Abaca EPG outproxy filter 3.1.2.exported $Rev: 9262 $) id iz6Urb1a0z60; Sun, 09 Jan 2011 16:35:06 -0800 Received: from xpasc.com (egate.xpasc.com [10.1.2.49]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id E5D50100584; Sun, 9 Jan 2011 16:35:05 -0800 (PST) Received: from egate.xpasc.com (egate.xpasc.com [10.1.2.49]) by xpasc.com (8.13.8/8.13.8) with ESMTP id p0A0Ypki026509; Sun, 9 Jan 2011 16:35:03 -0800 Date: Sun, 9 Jan 2011 16:34:51 -0800 (PST) From: David Morris To: Peter Saint-Andre In-Reply-To: <4D2A2F7C.502@stpeter.im> Message-ID: References: <20110108194952.GS12542@zedshaw> <20110109183236.GZ12542@zedshaw> <20110109201627.GC12542@zedshaw> <4D2A239C.6040801@extendedsubset.com> <4D2A2F7C.502@stpeter.im> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Propel-ID: iz6Urb1a0z60 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] [websec] [apps-discuss] [saag] [kitten] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 00:32:55 -0000 On Sun, 9 Jan 2011, Peter Saint-Andre wrote: > Which is why I keep replying to messages in this thread and trimming the > cc list as I do so. :) Trim the people ... really ... if someone isn't interested enought to subscribe, they don't need a copy and I don't need multiples. I left you on to underscore my point. When I made one comment in this thread, I removed all individuals. But I'm still back. From travis+ml-http-auth@subspacefield.org Sun Jan 9 18:44:34 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1592728C0E3 for ; Sun, 9 Jan 2011 18:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.292 X-Spam-Level: X-Spam-Status: No, score=-1.292 tagged_above=-999 required=5 tests=[AWL=-1.107, BAYES_40=-0.185] 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 Ez2fOMceYF15 for ; Sun, 9 Jan 2011 18:44:32 -0800 (PST) Received: from nexus.subspacefield.org (nexus.subspacefield.org [64.156.192.208]) by core3.amsl.com (Postfix) with ESMTP id E3E3028C0D9 for ; Sun, 9 Jan 2011 18:44:32 -0800 (PST) Received: by nexus.subspacefield.org (Postfix, from userid 1001) id E9EFB234C7D; Sun, 9 Jan 2011 18:46:43 -0800 (PST) Date: Sun, 9 Jan 2011 18:46:43 -0800 From: travis+ml-http-auth@subspacefield.org To: http-auth@ietf.org Message-ID: <20110110024643.GB20587@subspacefield.org> Mail-Followup-To: http-auth@ietf.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vGgW1X5XWziG23Ko" Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [http-auth] Obama & DoC thinking about "internet ID" for US citizens X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 02:44:34 -0000 --vGgW1X5XWziG23Ko Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I hate to bring up something with such a political thrust, but apparently Obama is considering having Commerce create an "identity ecosystem". Quoting: The Obama administration is currently drafting what it's calling the National Strategy for Trusted Identities in Cyberspace, which Locke said will be released by the president in the next few months. (An early version was publicly released last summer.) http://www.cbsnews.com/8301-501465_162-20027837-501465.html --=20 Good code works on most inputs; correct code works on all inputs. My emails do not have attachments; it's a digital signature that your mail program doesn't understand. | http://www.subspacefield.org/~travis/=20 If you are a spammer, please email john@subspacefield.org to get blackliste= d. --vGgW1X5XWziG23Ko Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (OpenBSD) iQIcBAEBAgAGBQJNKnMSAAoJEGQVZZEDJt9H+LQQAKhrToN3lxqrCqSK2fPMZtp9 4ADKoMQCJB5Dr9Ogdg3ZnP6nOJxNODyO/LwoGF2k6XQGD16ar4hj5js5bHOWZIJy +zxcP94Mc3IrZ4uU8ujxoWFOCeUCGqEt3QBdWzf5JCCZ6aDpeHR84MJXI4s7KKGH I3gmmem3xjm7egnYoHNexhpuEbS+a0/SgKUQlg0wAk0j4FHo2nllum+c1ePHJGmB D8tGu335yhjECYR1sL5P2DFAd3ldM13zfOk7B9gO0Qq4MvtD2eIp5+FnmmblLq9e XuGI7x4+8ynieh7tEDLDSlonn9QBubE1ExViK8Dk6+tkIof/WHphw9kaxVM/Wc6l 9XX904KABzM+VelK+9gU0ub1WAQ0lf0ybqkbtgdvcnNnHfSK0RGOajakr7dPb9oK 3cC05QM+4ODOYBxtP5RHZJ5E2ON5Df1CNZfqTPlsqK8TzBa5OzWtkQ+mpyfz64QM 9yemJKtT/I8SXl+18fDs/o2RvrRbc5lPFT74aGfvk/wtKeAifBljQeCF5PxwC7Bk lunfxp2bzkfWNGhN1d6fR1CHSsUPNyyDfuBvaVgo8x6flnvp6cWXrJQ4afJMTKHV KM3qRUl4Ty/IAwh/BjDT6I4caDuahbKY/kYRn9U3T52xbW3Jg0zLlTdzbskeS3PT qvSvxHCpemWiGEJivkPG =bE69 -----END PGP SIGNATURE----- --vGgW1X5XWziG23Ko-- From dsr@w3.org Mon Jan 10 03:08:13 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFF3428C132 for ; Mon, 10 Jan 2011 03:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 K0UudagDU-q3 for ; Mon, 10 Jan 2011 03:08:12 -0800 (PST) Received: from lewis.sophia.w3.org (gw.sophia.w3.org [193.51.208.72]) by core3.amsl.com (Postfix) with ESMTP id 0592928C14A for ; Mon, 10 Jan 2011 03:08:11 -0800 (PST) Received: from dsl-217-155-168-222.zen.co.uk ([217.155.168.222] helo=[192.168.1.3]) by lewis.sophia.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PcFdh-0003YN-JZ; Mon, 10 Jan 2011 11:10:17 +0000 From: Dave Raggett To: Phillip Hallam-Baker In-Reply-To: References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <4D28D80B.2020006@extendedsubset.com> Content-Type: text/plain; charset="UTF-8" Organization: W3C Date: Mon, 10 Jan 2011 11:10:18 +0000 Message-ID: <1294657818.2445.64.camel@ivy> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: John C Klensin , http-auth@ietf.org Subject: Re: [http-auth] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 11:08:13 -0000 On Sun, 2011-01-09 at 16:32 -0500, Phillip Hallam-Baker wrote: > I think there is a big difference between having the ability to > separate out accounts into separate buckets and having to remember > what account identifier you used at a site because your preferred one > turned out to be unavailable. > > What I think important is that the user experience a single account > identifier. This need not require the same identifier be presented to > the sites. > > For example, when I begin a session in the browser I might enter > hallam@gmail.com but when I go to the site ietf.org they might see the > identifier > > * hallam@gmail.com > * ietf+hallam@gmail.com > * 2983hwd989h23r298y293y23++@gmail.com Presumably, you aren't requiring the id to be an email address in all cases? A long randomly chosen identifier specific for use with a given site may be preferable, especially if the issue of enabling constrained linkability is dealt with separately, e.g. through cryptographic means, and in many cases a user identifier isn't really needed at all! The initial authentication to the device/browser session is an entirely different matter. Here we need to make the credential easy for people to use as well as being strong enough for the job of protecting access to all of the user's sites. A further consideration is allowing the user to sign on from different devices. This leads to storing the context in the cloud in an encrypted form, and being very careful with the key, i.e. it isn't stored anywhere and certainly isn't passed to the server(s), and is strong enough to make dictionary attacks impractical. There is also the challenge of devices without a user interface (e.g. sensors or actuators), but which nonetheless need to authenticate themselves for access to external services. You can think of this as a class of HTTP user agent where the user is absent. > The selection being made according to what I specify when I register > with the site. In some cases I may want to use a universal identifier. > In others I may wish the identifier to be linkable to my other > identifiers but want data to be easily filtered/separated. In still > others I may want the site to know nothing more about me than that I > am the same person who visited previously and that I use a particular > authentication service. > > The work/home thing gets us into the realm of implicit authorization > since a very common requirement is to restrict access to people with > accounts at a particular site. > > For example, I am currently permitted to access CABForum Web sites by > virtue of my current employment. I most likely also have access to > various sites round the net because I established an account when > authorized under a previous employer who probably never knew to inform > them that I am no longer authorized. which is where zero knowledge proof based upon strong credentials is handy. Proving that you are currently a bona fide member of some group as defined by some suitable criteria shouldn't force you to provide a linkable identity, not even one linkable across sessions with the same server. Put it another way, not every authentication needs to involve the user agent providing an identifier on behalf of the user. > So I can imagine cases where it would matter if I subscribed under an > @gmail.com account or @defaultdenysecurity.com or @comodo.com. > > If we are going to support this type of interaction it would imply > that the protocol interaction is going to have to look something like: > > 1) Browser contacts site > 2) Site tells browser that authentication is desired > 3) Browser contacts user's active authentication services to see what > accounts are registered > 4) [Optional user interaction to ask what identity to use] > 5) Browser provides selected credential to site This is essentially the model used in the Firefox/weave account manager, where (2) is handled above the level of HTTP, see: https://wiki.mozilla.org/Labs/Weave/Identity/Account_Manager > Another possibility would be that the browser-site interaction would > always make use of a blinded credential but that the site might be > permitted to retrieve a profile that included a universal identifier > of some sort. Perhaps instead of "universal identifier" you mean some attribute that clients are required to possess? For example, proof that you live in the local city, or perhaps proof that you at least 21 years old and have a good credit rating. > If I am registering for the Huffington post they can whistle for my > mailing address. Contrawise if I am registering for UPS or DHL then I > am quite likely to want them to know my mailing addresses. It could be that the Huffington post offer a reduced price by enabling advertisers to target you accurately. This raises interesting challenges in the degree of tracking/linkability you agree to when signing up for the service. Do they really need to track your activities in detail, or is it sufficient for a third party to provide a credential attesting that you belong to some marketing profile. > Note however that a 'profile' is not the same thing as an 'identity' > since the first is a term that we can all understand and the second is > a buzzword that leads to people talking piffle. Indeed, "identity" as a term obscures the real and varied requirements for authentication. -- Dave Raggett http://www.w3.org/People/Raggett From dsr@w3.org Mon Jan 10 03:28:46 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DE5628C13B for ; Mon, 10 Jan 2011 03:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.266 X-Spam-Level: X-Spam-Status: No, score=-7.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 pVt2M6NdAT3B for ; Mon, 10 Jan 2011 03:28:45 -0800 (PST) Received: from lewis.sophia.w3.org (gw.sophia.w3.org [193.51.208.72]) by core3.amsl.com (Postfix) with ESMTP id B2D8228C134 for ; Mon, 10 Jan 2011 03:28:45 -0800 (PST) Received: from dsl-217-155-168-222.zen.co.uk ([217.155.168.222] helo=[192.168.1.3]) by lewis.sophia.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PcFxc-0003k2-Ur; Mon, 10 Jan 2011 11:30:53 +0000 From: Dave Raggett To: Peter Saint-Andre In-Reply-To: <4D2A3331.6060603@stpeter.im> References: <20110108194952.GS12542@zedshaw> <20110109183236.GZ12542@zedshaw> <20110109201627.GC12542@zedshaw> <4D2A3331.6060603@stpeter.im> Content-Type: text/plain; charset="UTF-8" Organization: W3C Date: Mon, 10 Jan 2011 11:30:54 +0000 Message-ID: <1294659054.2445.84.camel@ivy> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: Blaine Cook , "http-auth@ietf.org" , Ben Laurie , David Morris , Phillip Hallam-Baker Subject: Re: [http-auth] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 11:28:46 -0000 On Sun, 2011-01-09 at 15:14 -0700, Peter Saint-Andre wrote: > > Several have already been mentioned: EKE, SRP and zero-knowledge > > proofs in general. > > True. Do we have running code with any of these for HTTP or other > application technologies (e.g., TLS-SRP [RFC 5054] for IMAP or XMPP)? I have a demo developed together with IBM Zurich Labs for zero knowledge proofs with a Firefox extension using LiveConnect to access the Java-based idemix library on the client for proof construction, and verifying proofs server-side with idemix via Tomcat as a backend-server to the Apache2 web server, see: http://www.w3.org/QA/2010/11/boosting_privacy_online_-_anon.html This is layered on top of HTTP, but there is no reason why we couldn't standardize how to exchange proof specifications (the site's advertised requirements for authentication) and proofs at the HTTP level, but perhaps the layered approach makes sense as it can be readily applied to other transport protocols? In other words, HTTP would provide a standard framework for exchanging proof specifications and proofs, but stopping short of requiring a specific format for these. Of course these formats would still require standardization, but that can be done in a decoupled fashion. Note that the question of how users authenticates to the device to unlock their credentials is an entirely separate issue, see the above link for some ideas. -- Dave Raggett http://www.w3.org/People/Raggett From simon@josefsson.org Mon Jan 10 09:34:03 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D0DC3A6A67 for ; Mon, 10 Jan 2011 09:34:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.932 X-Spam-Level: X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, 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 ricXqQX3Erh5 for ; Mon, 10 Jan 2011 09:34:02 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id A2A263A681B for ; Mon, 10 Jan 2011 09:34:01 -0800 (PST) Received: from latte.josefsson.org ([213.115.69.138]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0AHZwxe006343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 10 Jan 2011 18:35:59 +0100 From: Simon Josefsson To: Peter Saint-Andre References: <20110108194952.GS12542@zedshaw> <20110109183236.GZ12542@zedshaw> <20110109201627.GC12542@zedshaw> <4D2A3331.6060603@stpeter.im> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110110:benl@google.com::1zTt/1DbCfkr6Eav:CXp X-Hashcash: 1:22:110110:hallam@gmail.com::9uw3w/oJn1qvvhkD:5c6V X-Hashcash: 1:22:110110:romeda@gmail.com::EeEAZlBh9koyVl0o:KvaG X-Hashcash: 1:22:110110:stpeter@stpeter.im::A6CNKkFqOGmMOj59:gkfT X-Hashcash: 1:22:110110:http-auth@ietf.org::UmRZCNk4JUByj2FU:VyzW X-Hashcash: 1:22:110110:dwm@xpasc.com::ltCOcqDMpPXgJcsx:UxMS Date: Mon, 10 Jan 2011 18:35:57 +0100 In-Reply-To: <4D2A3331.6060603@stpeter.im> (Peter Saint-Andre's message of "Sun, 09 Jan 2011 15:14:09 -0700") Message-ID: <87sjx0d5ky.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: Blaine Cook , "http-auth@ietf.org" , Ben Laurie , David Morris , Phillip Hallam-Baker Subject: Re: [http-auth] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 17:34:03 -0000 Peter Saint-Andre writes: >> Several have already been mentioned: EKE, SRP and zero-knowledge >> proofs in general. > > True. Do we have running code with any of these for HTTP or other > application technologies (e.g., TLS-SRP [RFC 5054] for IMAP or XMPP)? There is mod_gnutls for Apache that supports TLS-SRP. I've been using mod_gnutls in production on several busy sites for years without issues, but I haven't used the TLS-SRP features. The support is pretty old/stable, it is in Debian lenny. http://www.outoforder.cc/projects/apache/mod_gnutls/ /Simon From asteingruebl@paypal-inc.com Tue Jan 11 11:35:47 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95AEE3A6A82 for ; Tue, 11 Jan 2011 11:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.175 X-Spam-Level: X-Spam-Status: No, score=-8.175 tagged_above=-999 required=5 tests=[AWL=0.942, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8] 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 j6OIKXckHucY for ; Tue, 11 Jan 2011 11:35:45 -0800 (PST) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by core3.amsl.com (Postfix) with ESMTP id A69213A6809 for ; Tue, 11 Jan 2011 11:35:45 -0800 (PST) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:Date: Subject:Thread-Topic:Thread-Index:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=H4M41r34UiNFKQckQgCqwXp9vkcXne1Hqrqd+5La/h7aiVGFvw383as+ sskk4gavtNPMFo2bGABYXSuz9rhzayLL8J5beRDjkXLhmpBL1yZEQJAIf LhSVMbzZe2ZnZnB; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1294774683; x=1326310683; h=from:to:date:subject:message-id:references:in-reply-to: content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Marsh=20Ray=20,=20" Zed=20A.=20Shaw"=20,=0D=0A=09Ben=20L aurie=20,=20Blaine=20Cook=20,=20Phillip=0D=0A=20Hallam-Baker=20,=20David=20Morris=20,=0D=0A=09"http-aut h@ietf.org"=20|Date:=20Tue,=2011=20Ja n=202011=2012:38:01=20-0700|Subject:=20RE:=20[websec]=20[ apps-discuss]=20[saag]=20[kitten]=20HTTP=20authentication :=0D=0A=20the=20next=20generation|Message-ID:=20<5EE049BA 3C6538409BBE6F1760F328ABEB19FA711D@DEN-MEXMS-001.corp.eba y.com>|References:=20=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=09<20110108194952.GS12542@z edshaw>=0D=0A=09=0D=0A=09=0D=0A=09<2011010918 3236.GZ12542@zedshaw>=0D=0A=09=0D=0A=09<20110109 201627.GC12542@zedshaw>=20<4D2A239C.6040801@extendedsubse t.com>|In-Reply-To:=20<4D2A239C.6040801@extendedsubset.co m>|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=VGMUlOj6KXyQr81DDVcVIUpkAFCY6Beng/iRKuo46/c=; b=AWZrq2t1tB2I1Lc2DnwGuvrKq1iAPslo+4cDQ5ytsXDuDSOOKXdYGGpG gqEhAqXZ2sdPn3Cct10G5wwWwuBhic+L5Uk+RxvgkGlTK58u690L3Qq+Y lAb2GD/uQR7RO3E; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.60,308,1291622400"; d="scan'208";a="763057" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-MEXHT-003.corp.ebay.com) ([10.101.112.212]) by den-mipot-002.corp.ebay.com with ESMTP; 11 Jan 2011 11:38:03 -0800 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-003.corp.ebay.com ([10.241.17.54]) with mapi; Tue, 11 Jan 2011 12:38:02 -0700 From: "Steingruebl, Andy" To: Marsh Ray , "Zed A. Shaw" , Ben Laurie , Blaine Cook , Phillip Hallam-Baker , David Morris , "http-auth@ietf.org" Date: Tue, 11 Jan 2011 12:38:01 -0700 Thread-Topic: [websec] [apps-discuss] [saag] [kitten] HTTP authentication: the next generation Thread-Index: AcuwQq5KO1oz2PcFR+KTLv3tyaxSkABgyTWA Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB19FA711D@DEN-MEXMS-001.corp.ebay.com> References: <20110108194952.GS12542@zedshaw> <20110109183236.GZ12542@zedshaw> <20110109201627.GC12542@zedshaw> <4D2A239C.6040801@extendedsubset.com> In-Reply-To: <4D2A239C.6040801@extendedsubset.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: gd9x08Z0/SZjZ7qjbpPs2w== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Subject: Re: [http-auth] [websec] [apps-discuss] [saag] [kitten] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 19:35:47 -0000 > -----Original Message----- > From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On > Behalf Of Marsh Ray >=20 > As you pointed out Zed, phishing isn't something that happens to a protoc= ol > or an application - it's something the user decides to do. >=20 > Phishing can be said to have been prevented only when the user can be > relied upon to refuse to enter his password into an insecure box. I think the "easiest" example to think of is a HTTPS with mutual-auth. If = the password only unlocks the cert, and you do mutual auth, then your passw= ord isn't relevant for logging in directly, and spoofed sites don't have a = replayable credential even if they also do mutual-auth. Deployable - well, that is what we're discussing isn't it? But a scheme li= ke this does in a certain sense eliminate password theft. Not other phishi= ng such as just asking for all of your CC data on a spoofed webpage, but it= does at least protect some authenticators. Or am I answering the wrong question? PS. Just cc'd the http-auth WFG From benl@google.com Tue Jan 11 11:39:00 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8B3A3A6A5A for ; Tue, 11 Jan 2011 11:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.088 X-Spam-Level: X-Spam-Status: No, score=-104.088 tagged_above=-999 required=5 tests=[AWL=-1.111, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 R+5aN2ewj3eT for ; Tue, 11 Jan 2011 11:38:59 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id AECB23A67E7 for ; Tue, 11 Jan 2011 11:38:59 -0800 (PST) Received: from kpbe13.cbf.corp.google.com (kpbe13.cbf.corp.google.com [172.25.105.77]) by smtp-out.google.com with ESMTP id p0BJfGOu003508 for ; Tue, 11 Jan 2011 11:41:16 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294774876; bh=UL0IPxiLX967emVgBa2+cD2fKOw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=iVHyLUhT1GJ5jYETkowbo2bzwL6aL3mofxw5NQW0Ivx2TWl8DjOI+c9Qwt6ZBllnx 6m5jntDoBHkza+I83S5dQ== Received: from qyk32 (qyk32.prod.google.com [10.241.83.160]) by kpbe13.cbf.corp.google.com with ESMTP id p0BJdcNv014205 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 11 Jan 2011 11:41:15 -0800 Received: by qyk32 with SMTP id 32so3123938qyk.2 for ; Tue, 11 Jan 2011 11:41:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wmGpv8Z68jTmkIAp+pMhkr8++SzIiz0cxiGdWrpeU/k=; b=uaY9WRdKRAP64z4/RpCyKP/NqqaKxeo0upL2YyrO5oJEHf3qCqNJ8wH9YZvFvNc4ja e/FV1pCy5Siq+nCgL1uw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YZuQXK9NyT/HMWLbYjPhIh3R0/ygwlBrUXEPAhkZltCy1kTPkP5mxggYODvKDkNrnN NUqALxdcQzvmqwxQKIiw== MIME-Version: 1.0 Received: by 10.224.73.134 with SMTP id q6mr7922qaj.220.1294774874963; Tue, 11 Jan 2011 11:41:14 -0800 (PST) Received: by 10.220.88.137 with HTTP; Tue, 11 Jan 2011 11:41:14 -0800 (PST) In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEB19FA711D@DEN-MEXMS-001.corp.ebay.com> References: <20110108194952.GS12542@zedshaw> <20110109183236.GZ12542@zedshaw> <20110109201627.GC12542@zedshaw> <4D2A239C.6040801@extendedsubset.com> <5EE049BA3C6538409BBE6F1760F328ABEB19FA711D@DEN-MEXMS-001.corp.ebay.com> Date: Tue, 11 Jan 2011 19:41:14 +0000 Message-ID: From: Ben Laurie To: "Steingruebl, Andy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: David Morris , "http-auth@ietf.org" , Blaine Cook , Phillip Hallam-Baker Subject: Re: [http-auth] [websec] [apps-discuss] [saag] [kitten] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 19:39:00 -0000 On 11 January 2011 19:38, Steingruebl, Andy w= rote: >> -----Original Message----- >> From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On >> Behalf Of Marsh Ray >> >> As you pointed out Zed, phishing isn't something that happens to a proto= col >> or an application - it's something the user decides to do. >> >> Phishing can be said to have been prevented only when the user can be >> relied upon to refuse to enter his password into an insecure box. > > I think the "easiest" example to think of is a HTTPS with mutual-auth. = =A0If the password only unlocks the cert, and you do mutual auth, then your= password isn't relevant for logging in directly, and spoofed sites don't h= ave a replayable credential even if they also do mutual-auth. > > Deployable - well, that is what we're discussing isn't it? =A0But a schem= e like this does in a certain sense eliminate password theft. =A0Not other = phishing such as just asking for all of your CC data on a spoofed webpage, = but it does at least protect some authenticators. > > Or am I answering the wrong question? No, I think that's exactly the point. > > PS. Just cc'd the http-auth WFG > From tytso@mit.edu Thu Jan 13 10:25:19 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AC3B3A6BC5; Thu, 13 Jan 2011 10:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 juOwH3Aiz1Kx; Thu, 13 Jan 2011 10:25:18 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by core3.amsl.com (Postfix) with ESMTP id C5E403A6A5E; Thu, 13 Jan 2011 10:25:17 -0800 (PST) X-AuditID: 12074423-b7bd0ae000000a00-16-4d2f441cdfc6 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-6.mit.edu (Symantec Brightmail Gateway) with SMTP id E4.10.02560.C144F2D4; Thu, 13 Jan 2011 13:27:40 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id p0DIRd4p016603; Thu, 13 Jan 2011 13:27:40 -0500 Received: from [192.168.1.196] (c-71-194-208-146.hsd1.il.comcast.net [71.194.208.146]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p0DIRAXG003778 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 13 Jan 2011 13:27:36 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Theodore Tso In-Reply-To: Date: Thu, 13 Jan 2011 13:27:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <45F97DFD-3AAB-44DE-8DC9-3694608EB740@mit.edu> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAARcg5EE= X-Mailman-Approved-At: Thu, 13 Jan 2011 10:28:24 -0800 Cc: "apps-discuss@ietf.org" , "Roy T. Fielding" , websec , Robert Sayre , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , Ben Laurie , "ietf-http-wg@w3.org Group" Subject: Re: [http-auth] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 18:25:19 -0000 On Jan 8, 2011, at 11:07 AM, Phillip Hallam-Baker wrote: > I think that Ben is right that we are solving the wrong problem. >=20 > The problem is that users are asked to maintain accounts at literally = HUNDREDS of accounts.=20 >=20 > And some cretins, some utter morons, some bog-brained berks think it = is reasonable to tell the user to have a different password for every = one! >=20 > I can't remember the account names, the password is easy as I only had = one (for non financial) - until those cretins at Gawker screwed up. Now = I have to reset my password at all those places. The fact that web sites, like Gawker, will screw up, is why you need to = maintain different passwords at every single one. And at least Gawker = admitted that they screwed up, and told everyone to change their = passwords once this came out. Many large corporations would have tried = to stonewall and claim their security is perfect or at least not = publicize the security breach to their users. Personally, I think the horse left the barn a long, long time ago, and = this is not a problem we can fix today. What I use for my non-financial = accounts is the LastPass plugin, which scans HTML form pages looking for = username/password form fields, and if it finds them, looks up the = username/password in a database which is stored in the cloud in an = encrypted fashion, and populates them into HTML form. It also will = automatically generate nice, long, random passwords for every site when = you change your password, and allows you easily use long, = hard-to-memorize (and thus secure) passwords that are different for = every single web site. The only reason why I don't use it for my financial web sites is because = it's a closed source browser plugin, so I can't audit it to make sure = it's not stashing away passwords and publishing them to the manufacturer = via some covert channel. But if they want to steal my Financial Times = and Economists logins, hey, they can be my guest. It may be ugly that we're dealing with this at the HTML/presentation = battle, but any other solution will take years to roll out, and the = issues of trust and liability which to date have doomed any large-scale = PKI rollout are going to bite us here. And in a federated scheme, the = question of which federated entities a user should trust to potentially = give access to *all* of their web sites is still at best a research = problem. So at least for web security, maybe the best we can do is to = make things easier for the browser or browser plugins to manage = different accounts at hundreds of different web sites. This may = ultimately be an easier, and be a much more easily deployable, solution = than some kind of federated authentication proposal. -- Ted From marsh@extendedsubset.com Fri Jan 14 09:05:16 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B06A53A6BA3; Fri, 14 Jan 2011 09:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 yVAyY+betpQV; Fri, 14 Jan 2011 09:05:15 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 74AE43A6B9A; Fri, 14 Jan 2011 09:05:15 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1Pdn7h-0004Py-OE; Fri, 14 Jan 2011 17:07:37 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 4809C603E; Fri, 14 Jan 2011 17:07:33 +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: U2FsdGVkX18lbvaEQEauG/YHYvKNkaHDVNFTUVsfTMQ= Message-ID: <4D3082D5.6070801@extendedsubset.com> Date: Fri, 14 Jan 2011 11:07:33 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 14 Jan 2011 18:55:27 -0800 Cc: apps-discuss@ietf.org, benl@google.com, dwm@xpasc.com, websec@ietf.org, kitten@ietf.org, http-auth@ietf.org, ietf-http-wg@w3.org, romeda@gmail.com, hallam@gmail.com, saag@ietf.org Subject: Re: [http-auth] [saag] [websec] [apps-discuss] [kitten] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 17:05:16 -0000 On 01/13/2011 08:24 PM, Peter Gutmann wrote: > Marsh Ray writes: > >> Phishing can be said to have been prevented only when the user can >> be relied upon to refuse to enter his password into an insecure >> box. > > I think you need to phrase that more generally, "when the user can be > relied upon to not authenticate to the wrong site", because there's > more ways of authenticating around than just typing a string into a > web form. I was trying to be as general as possible but still thinking in terms of phising for passwords. (This conversation has bounced around a bit between "better HTTP password authentication don't you dare mention client certificates" and "open-minded discussion of login authentication methods". I'm happy to contribute to whatever, but we risk miscommunication-mistaken-for-disagreement unless we settle on the scope first.) The term "authenticate to the wrong site" has completely different meaning depending on whether or not we're talking about capture-and-reuse credentials like passwords or whether or not we're assuming encryption which authenticates the server to the user (https). So I was thinking of "password into insecure box" as being more general. Maybe the attack somehow doesn't even involve the "wrong site", maybe bad guy injects something into the right site instead? > For example some password managers do site-specifc > passwords, so even if you go to the wrong site you can't accidentally > provide your credentials for the correct site. OMG, I can't stand it when I type the right password (for something else) into the wrong box. I admit that I have not always immediately changed that password when I've done it into a computer I also sort-of trusted (but in a different scope). > Site images rate > more as a security gimmick than any real security measure. It'd be interesting to know if banks get an actual reduction in the rate of phishing from that. On 01/13/2011 08:33 PM, Peter Gutmann wrote: > Phillip Hallam-Baker writes: > >> Such users have asked to do business with hundreds of entities, so >> at least something is working right. > > Actually they haven't asked to to business with most of them, but > are required to have an account for > user-tracking/spam-defeating/who-knows-what purposes. Yep. I guess I was counting things like Slashdot and Twitter as "doing business", even though it wasn't a monetary transaction. There is some value stored in those credentials, or at least pain-in-the butt potential costs to me if they were compromised for some reason. > If browsers > provided a basic "generate a random password just for this site" > feature, as many password managers have been doing for years and > years, then we could focus on the tiny fraction of sites where > authentication really matters. That would be convenient, but how many people back up the password manager in their browser? I don't, I prefer to write them down. I use multiple computers and multiple browsers. No browser has every password. Encouraging them to be centralized in the browser seems less than ideal, since it's the browser that gets pwned more than anything else. > Two major problems that we initially > need to overcome are: > > 1. Browsers (I'm using this as a generic for "client-side software") > treat all passwords as being equal, from your high-value banking > one to your throwaway knitting-patterns-blog one. Yes, I agree that's a big problem. I don't think we should think of them as being fully-ordered on a dimension of 'value' however. For example, let's say I have: A. Password for current employer's single-sign-on Kerberos/Active Directory infrastructure. B. Password I use at job-hunting website C. Password I use for my pseudonym where I flame newbies and post obscene patterns on the knitting patterns blog. My work desktop computer will most likely be backdoored by my employer. They may not care about C, but I care greatly that they do not find B. I log in to the employer from a home PC or smartphone from a VPN A. I may have a sense of responsibility about protecting A, but apparently I'm looking for a new job anyway. I'm more interested that prospective employers don't find out about C. From a public internet terminal I may not care at all about accessing C because it doesn't seem plausible that it would associate back with my professional identity. > 2. Browsers (ditto) have close to zero support for even the most > basic password management that any number of plugins and add-ons have > had for years (the Firefox 3.6 password manager is, AFAICT, unchanged > since the Netscape 2.0 one from fifteen years ago). It works sort of OK for me. But I'm only happy with it because I wouldn't trust it with all of my passwords regardless of how . > If we could start to address this, and at least begin to bound the > problem, we've made a start. Theorising about blue-sky solutions > isn't useful when we haven't even defined the real problem we're > trying to solve. Yes, let's resist the attraction of actual solutions until we have defined the problem to death. The possible solutions and their pros and cons of will usually be obvious by that point. - Marsh From marsh@extendedsubset.com Fri Jan 14 09:24:36 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27C0C3A6BA3; Fri, 14 Jan 2011 09:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 zqPHCjGSpFEG; Fri, 14 Jan 2011 09:24:35 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id A0FAF3A6BB4; Fri, 14 Jan 2011 09:24:31 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1PdnQM-000EKn-PO; Fri, 14 Jan 2011 17:26:54 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 0015C603E; Fri, 14 Jan 2011 17:26:50 +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: U2FsdGVkX19CXS3o05S/+ZXWLvW9ImCQ+6e1DVdiVUQ= Message-ID: <4D30875B.5050109@extendedsubset.com> Date: Fri, 14 Jan 2011 11:26:51 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 14 Jan 2011 18:55:27 -0800 Cc: apps-discuss@ietf.org, benl@google.com, dwm@xpasc.com, websec@ietf.org, kitten@ietf.org, http-auth@ietf.org, ietf-http-wg@w3.org, romeda@gmail.com, hallam@gmail.com, saag@ietf.org Subject: Re: [http-auth] [saag] [websec] [apps-discuss] [kitten] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 17:24:36 -0000 On 01/14/2011 04:12 AM, Peter Gutmann wrote: > > Who says there's a password involved? It's equally appropriate for public- > key/certificate-based auth, "sign this challenge" for example. I think "when > the user can be relied upon to not authenticate to the wrong site" covers most > of the bases and is technology- and mechanism-neutral. What is being authenticated? How much of the surrounding context is being assumed or implied, and how much is actually being authenticated? Who is doing the authentication? What capabilities will the result be used to authorize? These are real questions that go to the heart of the problem. I don't believe that they have been reconsidered in the context of today's computing environment. Give a description of the semantics of the "sign this challenge" act, without presupposing agreement on definitions we take for granted like "authentication", "login", "session", etc. I suspect the result would sound absurd enough that we would want to throw out the whole thing and start over. I suspect we avoid this exercise because we realize this subconsciously, or at least avoid saying it out loud. I suspect that this is a big part of why we find the problem intractable. - Marsh From benl@google.com Fri Jan 14 01:58:03 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64C763A6A0D for ; Fri, 14 Jan 2011 01:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.736 X-Spam-Level: X-Spam-Status: No, score=-103.736 tagged_above=-999 required=5 tests=[AWL=-0.759, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 Kif8fnqeVRSf for ; Fri, 14 Jan 2011 01:58:03 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 025C53A6ACE for ; Fri, 14 Jan 2011 01:57:58 -0800 (PST) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id p0EA0K6s016552 for ; Fri, 14 Jan 2011 02:00:20 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294999223; bh=4HjEKMmA6PPVeYrCzXGB9XJoaJc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=GmJKIfgm4XoZxi0fkwXjYBmeXpnczspfH/bkp42/RDeUw4yU4otsx8Cv9r44+K128 S0WsxhgkeJLIs9/bBFo5w== Received: from qwj9 (qwj9.prod.google.com [10.241.195.73]) by hpaq3.eem.corp.google.com with ESMTP id p0E9x8uv022429 for ; Fri, 14 Jan 2011 02:00:19 -0800 Received: by qwj9 with SMTP id 9so2545470qwj.41 for ; Fri, 14 Jan 2011 02:00:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pOv0POGRSp4j8mzD5VRvAxYScXGJeD+JAQmTzfFsha8=; b=QlnWNTYdpnVqArTKVax8JGp+chiH908UHFXhpfKJHxQ9pdwSR1UnDQoKzHvmANLchD riQVXwbbQy5wyTvopi9Q== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Q42xBptqqqWzKPqxAdm9MCgsaqciCJPxGka8QYv4t96iB5eQwqPkGq1k2ZkcK6qwBU uC7s/RdAorxzTno2ce0Q== MIME-Version: 1.0 Received: by 10.229.95.11 with SMTP id b11mr537655qcn.28.1294999218581; Fri, 14 Jan 2011 02:00:18 -0800 (PST) Received: by 10.220.88.137 with HTTP; Fri, 14 Jan 2011 02:00:18 -0800 (PST) In-Reply-To: References: <4D2A239C.6040801@extendedsubset.com> Date: Fri, 14 Jan 2011 10:00:18 +0000 Message-ID: From: Ben Laurie To: Peter Gutmann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Mailman-Approved-At: Fri, 14 Jan 2011 18:56:20 -0800 Cc: apps-discuss@ietf.org, dwm@xpasc.com, websec@ietf.org, kitten@ietf.org, http-auth@ietf.org, ietf-http-wg@w3.org, romeda@gmail.com, hallam@gmail.com, saag@ietf.org Subject: Re: [http-auth] [saag] [websec] [apps-discuss] [kitten] HTTP authentication: the next generation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 09:58:03 -0000 On 14 January 2011 02:24, Peter Gutmann wrote: > Marsh Ray writes: > >>Phishing can be said to have been prevented only when the user can be rel= ied >>upon to refuse to enter his password into an insecure box. > > I think you need to phrase that more generally, "when the user can be rel= ied > upon to not authenticate to the wrong site", because there's more ways of > authenticating around than just typing a string into a web form. =A0For e= xample > some password managers do site-specifc passwords, so even if you go to th= e > wrong site you can't accidentally provide your credentials for the correc= t > site. That phrasing is only correct if the authentication method leaks the passwo= rd... > >>For example, my bank asks for my username and then shows me a familiar >>picture (e.g., a rocking horse) that is supposed to prevent phishing. Thi= s >>stops phishing only in the sense that it requires the attacker to use a C= GI >>proxy app rather than simple static phishing site. > > ... or display a broken-image GIF, or a message that the award-winning > security whatsit is being upgraded and will be back soon, or ... > > (this is from a real-world evaluation of the (in-)effectiveness of site > images, I can dig up the ref if required). =A0Site images rate more as a > security gimmick than any real security measure. Exactly. From y.oiwa@aist.go.jp Wed Jan 19 17:22:59 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCB2D28C126 for ; Wed, 19 Jan 2011 17:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 WBnfVxgGxmDV for ; Wed, 19 Jan 2011 17:22:58 -0800 (PST) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by core3.amsl.com (Postfix) with ESMTP id 75E0528C139 for ; Wed, 19 Jan 2011 17:22:58 -0800 (PST) Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id p0K1PcbM024008; Thu, 20 Jan 2011 10:25:39 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: from smtp3.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id p0K1PcFp007061; Thu, 20 Jan 2011 10:25:38 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: by smtp3.aist.go.jp with ESMTP id p0K1PcIP019656; Thu, 20 Jan 2011 10:25:38 +0900 (JST) env-from (y.oiwa@aist.go.jp) Message-ID: <4D378F12.10807@aist.go.jp> Date: Thu, 20 Jan 2011 10:25:38 +0900 From: Yutaka OIWA Organization: RCIS, AIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "http-auth@ietf.org" X-Enigmail-Version: 1.1.1 Sender: oiwa@rcis.jp Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [http-auth] Updated test implementations for HTTP Mutual authentication proposal X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 01:22:59 -0000 Dear all, we recently updated our test implementation for HTTP Mutual authentication. The Firefox-based browser and Apache server module is available from . The implementations are updated to conform the most recent specification. We're currently preparing another set of reference implementations which are completely written in a human-readable :-) language (Ruby). It can be used as a debugging and testing references. There is a small on-line trial website available from the above URL. Please give it a try (including our proposed user interface designs), and we appreciate your feedbacks. Thanks, Yutaka -- Yutaka OIWA, Ph.D. Research Scientist Research Center for Information Security (RCIS) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From hhalpin@w3.org Sun Jan 30 11:04:42 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04A3D3A6851 for ; Sun, 30 Jan 2011 11:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 yqOdGcXz2eK6 for ; Sun, 30 Jan 2011 11:04:41 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id 25B5F3A684C for ; Sun, 30 Jan 2011 11:04:38 -0800 (PST) Received: from www-data by jay.w3.org with local (Exim 4.69) (envelope-from ) id 1Pjccn-0007aT-Pt for http-auth@ietf.org; Sun, 30 Jan 2011 14:07:49 -0500 Received: from 41.141.196.192 (SquirrelMail authenticated user hhalpin) by webmail-mit.w3.org with HTTP; Sun, 30 Jan 2011 19:07:49 -0000 (GMT) Message-ID: <1c2bbcf25744cc1b9a8627f2a9bd66a3.squirrel@webmail-mit.w3.org> Date: Sun, 30 Jan 2011 19:07:49 -0000 (GMT) From: "Harry Halpin" To: http-auth@ietf.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [http-auth] HTTP Auth Next BOF at IETF Prague deadline Monday/Possible W3C Workshop? X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 19:04:42 -0000 Everyone, I have been impressed with the discussion so far here - although it has died down recently. There seems to me to be no giant technical holes in mutual-auth, and almost anything would be better than current HTTP Auth Basic. The way I see it is that there seems to two problems: 1) Login forms in HTML are by nature insecure, and the resulting cookie can be hijacked. 2) But Web developers are unwilling to let browser chrome take over log-in, and cookie/security management in the browser is uneven at best. The solution that gives us some security while letting Web developers still control login UI. My feeling is that this may very well be some form of allowing the authorization done in the browser via some kind of secure form/javascript, but I believe this is an open research question. Links to information would be appreciate. The problem must be tackled ASAP and it cannot be impossible. We may just need some more people in the room. The W3C has recently taken a keen interest in this area, and would be happy to organize a workshop on this theme to see if browser vendors and the WebApps/HTML5 WG are interested. I'm happy to take the lead on organizing such a workshop somewhere near the browser vendors ASAP. That can help us mange problem 2). However, the relevant issues about HTTP Auth and a draft design (I'm happy to start with MutualAuth, but very open) need to be sorted ASAP to get a tech design to overcome 1), and a proposal from the IETF on the table would definitely help get the attention I think of browser folks and Webapp developers. Would people be up for a HTTP Auth BOF at the next IETF meeting in Prague? The deadline for BOF requests is Monday [1]. I and others from the W3C will be there. If the HTTP Auth BOF has already happened too many times, let's call it WebAuth, and be specific about the browser/javascript aspect and looking at new solutions. Anyone else up for this? If so, who wants to request the BOF? Request should be done today/tomorrow. [1] http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF80 cheers, harry From y.oiwa@aist.go.jp Mon Jan 31 00:17:24 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF6173A6B34 for ; Mon, 31 Jan 2011 00:17:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 4s86zDAytgSY for ; Mon, 31 Jan 2011 00:17:24 -0800 (PST) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by core3.amsl.com (Postfix) with ESMTP id C65C83A6B2D for ; Mon, 31 Jan 2011 00:17:23 -0800 (PST) Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id p0V8KYHC008089; Mon, 31 Jan 2011 17:20:34 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: from smtp1.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id p0V8KY1M007663; Mon, 31 Jan 2011 17:20:34 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: by smtp1.aist.go.jp with ESMTP id p0V8KW7L002057; Mon, 31 Jan 2011 17:20:33 +0900 (JST) env-from (y.oiwa@aist.go.jp) Message-ID: <4D4670CF.7060301@aist.go.jp> Date: Mon, 31 Jan 2011 17:20:31 +0900 From: Yutaka OIWA Organization: RCIS, AIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Harry Halpin References: <1c2bbcf25744cc1b9a8627f2a9bd66a3.squirrel@webmail-mit.w3.org> In-Reply-To: <1c2bbcf25744cc1b9a8627f2a9bd66a3.squirrel@webmail-mit.w3.org> X-Enigmail-Version: 1.1.1 Sender: oiwa@rcis.jp Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: http-auth@ietf.org Subject: Re: [http-auth] HTTP Auth Next BOF at IETF Prague deadline Monday/Possible W3C Workshop? X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 08:17:25 -0000 Dear Harry, # I've just arrived to Tokyo/Narita from Austin and writing in the airport. +1 ... I really like to have a meeting at Prague! I already sent Peter a mail personally, but not in a IETF-formal way. I do not have enough expertise on the IETF procedures and helps from experts are really needed. But if no one else is appropriate, I would be able to take a role. I think HTTP-auth have nothing in the past to block new activities in the IETF. On 2011/01/31 4:07, Harry Halpin wrote: > Everyone, > > I have been impressed with the discussion so far here - although it has > died down recently. There seems to me to be no giant technical holes in > mutual-auth, and almost anything would be better than current HTTP Auth > Basic. > > The way I see it is that there seems to two problems: > > 1) Login forms in HTML are by nature insecure, and the resulting cookie > can be hijacked. > > 2) But Web developers are unwilling to let browser chrome take over > log-in, and cookie/security management in the browser is uneven at best. > > The solution that gives us some security while letting Web developers > still control login UI. My feeling is that this may very well be some form > of allowing the authorization done in the browser via some kind of secure > form/javascript, but I believe this is an open research question. Links to > information would be appreciate. > > The problem must be tackled ASAP and it cannot be impossible. We may just > need some more people in the room. The W3C has recently taken a keen > interest in this area, and would be happy to organize a workshop on this > theme to see if browser vendors and the WebApps/HTML5 WG are interested. > I'm happy to take the lead on organizing such a workshop somewhere near > the browser vendors ASAP. That can help us mange problem 2). > > However, the relevant issues about HTTP Auth and a draft design (I'm happy > to start with MutualAuth, but very open) need to be sorted ASAP to get a > tech design to overcome 1), and a proposal from the IETF on the table > would definitely help get the attention I think of browser folks and > Webapp developers. > > Would people be up for a HTTP Auth BOF at the next IETF meeting in Prague? > The deadline for BOF requests is Monday [1]. I and others from the W3C > will be there. If the HTTP Auth BOF has already happened too many times, > let's call it WebAuth, and be specific about the browser/javascript aspect > and looking at new solutions. Anyone else up for this? > > If so, who wants to request the BOF? Request should be done today/tomorrow. > > [1] http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF80 > > > > cheers, > harry > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth -- Yutaka OIWA, Ph.D. Research Scientist Research Center for Information Security (RCIS) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From hhalpin@w3.org Mon Jan 31 02:42:01 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB6913A690C for ; Mon, 31 Jan 2011 02:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 8TJyuZYF6nA1 for ; Mon, 31 Jan 2011 02:42:00 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id 9E96F3A690A for ; Mon, 31 Jan 2011 02:42:00 -0800 (PST) Received: from www-data by jay.w3.org with local (Exim 4.69) (envelope-from ) id 1PjrFv-0001OW-SX; Mon, 31 Jan 2011 05:45:12 -0500 Received: from 41.251.0.44 (SquirrelMail authenticated user hhalpin) by webmail-mit.w3.org with HTTP; Mon, 31 Jan 2011 10:45:12 -0000 (GMT) Message-ID: In-Reply-To: <4D4670CF.7060301@aist.go.jp> References: <1c2bbcf25744cc1b9a8627f2a9bd66a3.squirrel@webmail-mit.w3.org> <4D4670CF.7060301@aist.go.jp> Date: Mon, 31 Jan 2011 10:45:12 -0000 (GMT) From: "Harry Halpin" To: "Yutaka OIWA" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: http-auth@ietf.org Subject: Re: [http-auth] HTTP Auth Next BOF at IETF Prague deadline Monday/Possible W3C Workshop? X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 10:42:01 -0000 > Dear Harry, > > # I've just arrived to Tokyo/Narita from Austin and writing in the > airport. > > +1 ... I really like to have a meeting at Prague! > I already sent Peter a mail personally, but not in a IETF-formal way. > I do not have enough expertise on the IETF procedures and helps from > experts are > really needed. But if no one else is appropriate, I would be able to take > a role. Another idea would be to hold an informal bar-BOF at Prague if the BOF can't be put together quickly enough as a bar-BOF would require less work and give us more time to bake the tech ideas or charter. I'll leave this decision in the hands of more experienced IETF folks. I'll push things hard to get a W3C workshop together ASAP, and a double-combo of an IETF and W3C effort sounds promising to me. Following the conversaton on the list, I'm still unclear on the next _exact_ tech steps, but I think its straightforward that HTTP Auth needs fixing and that the browsers will eventually in the long-term play a role, so we need to start outreach and organization ASAP. > > I think HTTP-auth have nothing in the past to block new activities in the > IETF. > > > On 2011/01/31 4:07, Harry Halpin wrote: >> Everyone, >> >> I have been impressed with the discussion so far here - although it >> has >> died down recently. There seems to me to be no giant technical holes in >> mutual-auth, and almost anything would be better than current HTTP Auth >> Basic. >> >> The way I see it is that there seems to two problems: >> >> 1) Login forms in HTML are by nature insecure, and the resulting cookie >> can be hijacked. >> >> 2) But Web developers are unwilling to let browser chrome take over >> log-in, and cookie/security management in the browser is uneven at best. >> >> The solution that gives us some security while letting Web developers >> still control login UI. My feeling is that this may very well be some >> form >> of allowing the authorization done in the browser via some kind of >> secure >> form/javascript, but I believe this is an open research question. Links >> to >> information would be appreciate. >> >> The problem must be tackled ASAP and it cannot be impossible. We may >> just >> need some more people in the room. The W3C has recently taken a keen >> interest in this area, and would be happy to organize a workshop on this >> theme to see if browser vendors and the WebApps/HTML5 WG are interested. >> I'm happy to take the lead on organizing such a workshop somewhere near >> the browser vendors ASAP. That can help us mange problem 2). >> >> However, the relevant issues about HTTP Auth and a draft design (I'm >> happy >> to start with MutualAuth, but very open) need to be sorted ASAP to get a >> tech design to overcome 1), and a proposal from the IETF on the table >> would definitely help get the attention I think of browser folks and >> Webapp developers. >> >> Would people be up for a HTTP Auth BOF at the next IETF meeting in >> Prague? >> The deadline for BOF requests is Monday [1]. I and others from the W3C >> will be there. If the HTTP Auth BOF has already happened too many >> times, >> let's call it WebAuth, and be specific about the browser/javascript >> aspect >> and looking at new solutions. Anyone else up for this? >> >> If so, who wants to request the BOF? Request should be done >> today/tomorrow. >> >> [1] http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF80 >> >> >> >> cheers, >> harry >> >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth > > -- > Yutaka OIWA, Ph.D. Research > Scientist > Research Center for Information Security > (RCIS) > National Institute of Advanced Industrial Science and Technology > (AIST) > Mail addresses: , > > OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 > 46B5] > From y.oiwa@aist.go.jp Mon Jan 31 03:51:28 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ABA83A6900 for ; Mon, 31 Jan 2011 03:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 Wf29tuXZ-wRf for ; Mon, 31 Jan 2011 03:51:26 -0800 (PST) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by core3.amsl.com (Postfix) with ESMTP id C46723A68A7 for ; Mon, 31 Jan 2011 03:51:25 -0800 (PST) Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id p0VBsbXp000410; Mon, 31 Jan 2011 20:54:37 +0900 (JST) env-from (y.oiwa@aist.go.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aist.go.jp; s=aist; t=1296474878; bh=GzI+2tCUeNAB9vQmy8oPXXI0kIppboWIJT8QIBTVyis=; h=From:Date:Message-ID; b=LIbfvNyv5aWxqplPpcWmiGOt9HdcLXhC2V/GoP7gUHbDWvTBFwGIBtw1FyLFijGmq A4V8vzrvhOmRtDwgzYE35OYo101IGRIc+yIYred/maVC2FyN7R9/irBGHBWOJXrAYg YRJt7rx6WjFI6asSEbF6ixAbzBS5naIbHr50EBjU= Received: from smtp2.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id p0VBsbcD023072; Mon, 31 Jan 2011 20:54:37 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: by smtp2.aist.go.jp with ESMTP id p0VBsbUm000723; Mon, 31 Jan 2011 20:54:37 +0900 (JST) env-from (y.oiwa@aist.go.jp) To: "Harry Halpin" References: <1c2bbcf25744cc1b9a8627f2a9bd66a3.squirrel@webmail-mit.w3.org> <4D4670CF.7060301@aist.go.jp> From: Yutaka OIWA Date: Mon, 31 Jan 2011 20:54:37 +0900 In-Reply-To: (Harry Halpin's message of "Mon\, 31 Jan 2011 10\:45\:12 -0000 \(GMT\)") Message-ID: <87pqrd5lvm.fsf@bluewind.rcis.aist.go.jp> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: http-auth@ietf.org Subject: Re: [http-auth] HTTP Auth Next BOF at IETF Prague deadline Monday/Possible W3C Workshop? X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 11:51:28 -0000 Dear Harry and all, "Harry Halpin" writes: > Another idea would be to hold an informal bar-BOF at Prague if the BOF > can't be put together quickly enough as a bar-BOF would require less work > and give us more time to bake the tech ideas or charter. I'll leave this > decision in the hands of more experienced IETF folks. In both ways, anyway, we will need a good-direction proposal and agenda. It is hard for me to write a "good" one, but I made a "bad" :-) one as a starting point. Please consider it for improvements and rephrasing. Thanks Harry for providing a very good descriptions which I've used as a staring point. * Things to consider: - agenda not yet written - goal: currently ambiguous (intentionally); to discuss, or to form WG? -------- Description: The current authentication methods used in the Web system is prone to various serious vulnerabilities, including password eavesdropping, password stealing, session hijack, and phishing. Because of the lack of a good/secure support for web application authentication in the HTTP layer, people tends to use HTML forms for authentication, which are by nature insecure. This problem should be solved as soon as possible to mitigate the impact of Web authentication-related frauds to the Internet users. However, to solve this problem, the resulting technologies should be carefully designed so that these will be well deployable to the real-world applications. Recently we have several new proposals for securing Web/HTTP authentications, some of which has a proposed drafts. In addition, the work of the HTTPBIS working group is about to finish, and it will require some maintenance works for the HTTP existing authentication mechanism, at least the registrations to IANA. The purpose of the proposed BoF is to pursue creation of IETF working groups on various HTTP authentication issues. The possible topics of the future working group may include the following topics: * Introduction of much more secure authentication mechanisms as extensions to the HTTP. * Introduction of technologies which will enable more sophisticated use of HTTP authentication in application layer. * Research on the secure ways of Web/HTML authentications and required protocol-side support for them * Maintenance of existing HTTP authentication extensions (other than Basic and Digest), either checking its httpbis-conforming or making it historic. * Proposing addition of authentication schemes to the IANA registry as proposed by httpbis. Both BoF and possible future working group expect well coordination with W3C's effort on the related topics. BoF proposed agenda: * Topics to be discussed in the future working group * TBD Logistical informations: BoF Chairs: TBD BOF Proponents: Harry Halpin, Yutaka OIWA, ... (TBD) People expected: 50 Length of session: 90min Conflicts to avoid: Working Groups in the APP and SEC areas WebEX: no Responsible AD: Peter Saint-Andre, Alexey Melnikov (tentative) Goal: to pursue creation of IETF working groups Drafts: http://tools.ietf.org/html/draft-oiwa-http-mutualauth-08; more to be discussed Mailing List: HTTP http-auth mailing list Mailing List Archive: http://www.ietf.org/mail-archive/web/http-auth/ -------- -- Yutaka OIWA, Ph.D. Research Scientist Research Center for Information Security (RCIS) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From stpeter@stpeter.im Mon Jan 31 09:39:32 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9427A3A6977 for ; Mon, 31 Jan 2011 09:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.643 X-Spam-Level: X-Spam-Status: No, score=-102.643 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, 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 gheoRHkBnEAb for ; Mon, 31 Jan 2011 09:39:31 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 776CA3A6807 for ; Mon, 31 Jan 2011 09:39:31 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 982C7400F6; Mon, 31 Jan 2011 10:59:27 -0700 (MST) Message-ID: <4D46F497.2000005@stpeter.im> Date: Mon, 31 Jan 2011 10:42:47 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Harry Halpin References: <1c2bbcf25744cc1b9a8627f2a9bd66a3.squirrel@webmail-mit.w3.org> <4D4670CF.7060301@aist.go.jp> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000006060903070700060205" Cc: http-auth@ietf.org Subject: Re: [http-auth] HTTP Auth Next BOF at IETF Prague deadline Monday/Possible W3C Workshop? X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 17:39:32 -0000 This is a cryptographically signed message in MIME format. --------------ms000006060903070700060205 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 1/31/11 3:45 AM, Harry Halpin wrote: >> Dear Harry, >> >> # I've just arrived to Tokyo/Narita from Austin and writing in the >> airport. >> >> +1 ... I really like to have a meeting at Prague! >> I already sent Peter a mail personally, but not in a IETF-formal way. >> I do not have enough expertise on the IETF procedures and helps from >> experts are >> really needed. But if no one else is appropriate, I would be able to = take >> a role. >=20 > Another idea would be to hold an informal bar-BOF at Prague if the BOF > can't be put together quickly enough as a bar-BOF would require less wo= rk > and give us more time to bake the tech ideas or charter. I'll leave thi= s > decision in the hands of more experienced IETF folks. I think that a "bar bof" / informal side meeting at the Prague IETF meeting makes the most sense, followed by focused discussions on this list and then a WG-forming BoF at IETF 81 (if we think that's needed). I say that because I don't think we're quite ready to form a working group, but we have important technical topics to discuss. We could hold a non-WG-forming BoF ("exploratory BoF") but an informal side meeting might be less pressured and therefore more productive -- in my experience it's best to hold a BoF when you have a strong proposal about forming a WG. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms000006060903070700060205 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEz MTE3NDI0N1owIwYJKoZIhvcNAQkEMRYEFAP6RIJWFq+XoG8BNZUpZiWu921kMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQABtDIlPVtk7jSGFu3zbgXvLVJbl40ihoiwRPPYwsbozYrzNUCYGH91+eI4 wZTFfZ5Nvz/2O+Gd/PHSjTZEWoQnv+lNspxcLneToG3kgZ9eJrLk4o672vCwjY9AhDEbaEhP vTARWlJavqJy1tfQYelpCXRKNc9FdMM83z5xexUNb6AV64Iny1mC4DB4TamkwbExXEhbwas/ BKeSfDlINhNOh7v5qOa+b3Lz4l1B5IKL4Xu+LAVU45j2ZlYQuyF0XJBcs7aB4yyXoi8hMcJe bnZ/UCvkcqZjYeXDnZXrajx3y85flGCV/rL6B+Dhx37CE+dHg84Pe/zg6F7VSApWrOlFAAAA AAAA --------------ms000006060903070700060205-- From stpeter@stpeter.im Mon Jan 31 10:32:02 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D12CA3A6977 for ; Mon, 31 Jan 2011 10:32:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.641 X-Spam-Level: X-Spam-Status: No, score=-102.641 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, 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 UA8--pQ2QzUO for ; Mon, 31 Jan 2011 10:32:01 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id C2BBB3A6847 for ; Mon, 31 Jan 2011 10:32:01 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 86008400F6; Mon, 31 Jan 2011 11:51:58 -0700 (MST) Message-ID: <4D4700E3.9010700@stpeter.im> Date: Mon, 31 Jan 2011 11:35:15 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Yutaka OIWA References: <1c2bbcf25744cc1b9a8627f2a9bd66a3.squirrel@webmail-mit.w3.org> <4D4670CF.7060301@aist.go.jp> <87pqrd5lvm.fsf@bluewind.rcis.aist.go.jp> In-Reply-To: <87pqrd5lvm.fsf@bluewind.rcis.aist.go.jp> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050204080602090300060608" Cc: http-auth@ietf.org Subject: Re: [http-auth] HTTP Auth Next BOF at IETF Prague deadline Monday/Possible W3C Workshop? X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 18:32:02 -0000 This is a cryptographically signed message in MIME format. --------------ms050204080602090300060608 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Yutaka, thanks for the strawman! This is a good start, and I would like to see some discussion of it on the list leading up to IETF 80. On 1/31/11 4:54 AM, Yutaka OIWA wrote: > Dear Harry and all, >=20 > "Harry Halpin" writes: >=20 >> Another idea would be to hold an informal bar-BOF at Prague if the BOF= >> can't be put together quickly enough as a bar-BOF would require less w= ork >> and give us more time to bake the tech ideas or charter. I'll leave th= is >> decision in the hands of more experienced IETF folks. >=20 > In both ways, anyway, we will need a good-direction proposal and > agenda. It is hard for me to write a "good" one, but I made a "bad" :-= ) > one as a starting point. >=20 > Please consider it for improvements and rephrasing. Thanks Harry for > providing a very good descriptions which I've used as a staring point. >=20 > * Things to consider: >=20 > - agenda not yet written > - goal: currently ambiguous (intentionally); to discuss, or to form = WG? >=20 > -------- > Description: >=20 > The current authentication methods used in the Web system is prone to > various serious vulnerabilities, including password eavesdropping, > password stealing, session hijack, and phishing. Because of the lack > of a good/secure support for web application authentication in the > HTTP layer, people tends to use HTML forms for authentication, which > are by nature insecure. >=20 > This problem should be solved as soon as possible to mitigate the > impact of Web authentication-related frauds to the Internet > users. However, to solve this problem, the resulting technologies > should be carefully designed so that these will be well deployable to > the real-world applications. >=20 > Recently we have several new proposals for securing Web/HTTP > authentications, some of which has a proposed drafts. In addition, > the work of the HTTPBIS working group is about to finish, and it will > require some maintenance works for the HTTP existing authentication > mechanism, at least the registrations to IANA. >=20 > The purpose of the proposed BoF is to pursue creation of IETF working > groups on various HTTP authentication issues. The possible topics of > the future working group may include the following topics: >=20 > * Introduction of much more secure authentication mechanisms as > extensions to the HTTP. >=20 > * Introduction of technologies which will enable more sophisticated > use of HTTP authentication in application layer. >=20 > * Research on the secure ways of Web/HTML authentications and > required protocol-side support for them >=20 > * Maintenance of existing HTTP authentication extensions (other than > Basic and Digest), either checking its httpbis-conforming or making > it historic. >=20 > * Proposing addition of authentication schemes to the IANA registry > as proposed by httpbis. >=20 > Both BoF and possible future working group expect well coordination wit= h > W3C's effort on the related topics. >=20 >=20 > BoF proposed agenda: >=20 > * Topics to be discussed in the future working group >=20 > * TBD >=20 > Logistical informations: >=20 > BoF Chairs: TBD > BOF Proponents: Harry Halpin, Yutaka OIWA, ... (TBD) > People expected: 50 > Length of session: 90min > Conflicts to avoid: Working Groups in the APP and SEC areas > WebEX: no > Responsible AD: Peter Saint-Andre, Alexey Melnikov (tentative) > Goal: to pursue creation of IETF working groups > Drafts: http://tools.ietf.org/html/draft-oiwa-http-mutualauth-08; more= to be discussed > Mailing List: HTTP http-auth mailing list > Mailing List Archive: http://www.ietf.org/mail-archive/web/http-auth/ > -------- >=20 --------------ms050204080602090300060608 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEz MTE4MzUxNVowIwYJKoZIhvcNAQkEMRYEFBE5XDeri2bQ6b3WhODkEw9mXKyOMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCavdSLCFepwksM90YtKJJpcoJoqefPG5F6DrAJ4/rtK5B/C3ZUm2sXyVNu 3Fc5aqhzgMwRH+0igZCKViLRTzkLtd3khpdne7vCnY77KZDU5cH4v7vko22S7PvH9k6FAdZq TK+QZAzx6mt1/RIHYBgXNZS5zvDJuy7axzRFotjEUyrMjUWpk5FqgY6W3cgOiPUIk1T1LKVc fdATZsHf1cqJSwQ0UQUTVoSWiwWG6DKYGRJrkQkOXePYbbYqdV+vD0uwbnL79ez3DC6RXtnv Wa5eMI7i7CnJX8LOh7gT0BcbuVWk8MrLSeaFn0UifCDTbdphFZwngduJ5eA4ehkTsoAmAAAA AAAA --------------ms050204080602090300060608-- From y.oiwa@aist.go.jp Mon Jan 31 15:40:06 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 803E03A6C26 for ; Mon, 31 Jan 2011 15:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 2unMpQw87hhS for ; Mon, 31 Jan 2011 15:40:05 -0800 (PST) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by core3.amsl.com (Postfix) with ESMTP id 3F1713A6848 for ; Mon, 31 Jan 2011 15:40:05 -0800 (PST) Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id p0VNhIe9004946; Tue, 1 Feb 2011 08:43:19 +0900 (JST) env-from (y.oiwa@aist.go.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aist.go.jp; s=aist; t=1296517399; bh=3mpAHGJ4u6e7+x00IXtPxYU7Z5Imp+eJUPJmWD8/Qeg=; h=From:Date:Message-ID; b=pTQ5DDDBLT0mEBtf6t52mFzTnAqgOy+QqioE/gXLXDsmL8bmtZfvRdEmDWkd/aB1f QTa3MiSoqcbmQ34QGa9Sixu1vn/mrnerGaTzBbmrN6wfx6m6ydGk3EETAxNe5nEn36 +hHmBoJAszIgyFi9lSrgpXVBNvL+ojipPdVNNU3E= Received: from smtp2.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id p0VNhIH6004334; Tue, 1 Feb 2011 08:43:18 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: by smtp2.aist.go.jp with ESMTP id p0VNhH6k012770; Tue, 1 Feb 2011 08:43:18 +0900 (JST) env-from (y.oiwa@aist.go.jp) To: Peter Saint-Andre References: <1c2bbcf25744cc1b9a8627f2a9bd66a3.squirrel@webmail-mit.w3.org> <4D4670CF.7060301@aist.go.jp> <4D46F497.2000005@stpeter.im> From: Yutaka OIWA Date: Tue, 01 Feb 2011 08:43:17 +0900 In-Reply-To: <4D46F497.2000005@stpeter.im> (Peter Saint-Andre's message of "Mon\, 31 Jan 2011 10\:42\:47 -0700") Message-ID: <87y660tzai.fsf@bluewind.rcis.aist.go.jp> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: http-auth@ietf.org Subject: Re: [http-auth] HTTP Auth Next BOF at IETF Prague deadline Monday/Possible W3C Workshop? X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 23:40:06 -0000 Dear all I agree that we need more to make focus on the topics to be discussed in the future working group. # Honestly speaking I feel a little sad this moment, but I have to # agree that haste is from the devil. By the way, I listed up some possible topics in the previous mail. In last few months people, "including me", were very active in discussing their own ideas of securing the Web, and it was very interesting. However, at this moment, for each "proposal" we need to figure out how it can be implemented in the real world seamlessly, how it can be implemented as a protocol specification in RFC, whether it can be a IETF topic or have to be discussed in more wider people, and many others. We also have to take care of how the collaborations should take part with other working groups (such as OAUTH, and ABFAB), especially for the federation-based and protocol-stack-based (such as using SASL in Web) solutions. That is one of the reasons that I wrote some of the topics in a very abstract way, such as "Research on the secure ways of Web/HTML authentications and required protocol-side support for them". If you have some concrete ideas for securing Web, your feedbacks on the proposed topics list are really really needed. I would be able to add it to the list of possible topics then. And of course, if you have any good idea I really love to see an Internet-draft on it so that we can understand it more deeply and start discussion on it. All Regards, Yutaka -- Yutaka OIWA, Ph.D. Research Scientist Research Center for Information Security (RCIS) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From hhalpin@w3.org Mon Jan 31 16:20:14 2011 Return-Path: X-Original-To: http-auth@core3.amsl.com Delivered-To: http-auth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4EB43A6CB6 for ; Mon, 31 Jan 2011 16:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 60GP9jyPZ9F5 for ; Mon, 31 Jan 2011 16:20:13 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id 787673A68E7 for ; Mon, 31 Jan 2011 16:20:13 -0800 (PST) Received: from www-data by jay.w3.org with local (Exim 4.69) (envelope-from ) id 1Pk41i-0007aV-Cq; Mon, 31 Jan 2011 19:23:22 -0500 Received: from 41.141.97.122 (SquirrelMail authenticated user hhalpin) by webmail-mit.w3.org with HTTP; Tue, 1 Feb 2011 00:23:22 -0000 (GMT) Message-ID: <1385b41f6965a65682e17ad4308867c3.squirrel@webmail-mit.w3.org> In-Reply-To: <87y660tzai.fsf@bluewind.rcis.aist.go.jp> References: <1c2bbcf25744cc1b9a8627f2a9bd66a3.squirrel@webmail-mit.w3.org> <4D4670CF.7060301@aist.go.jp> <4D46F497.2000005@stpeter.im> <87y660tzai.fsf@bluewind.rcis.aist.go.jp> Date: Tue, 1 Feb 2011 00:23:22 -0000 (GMT) From: "Harry Halpin" To: "Yutaka OIWA" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: http-auth@ietf.org Subject: Re: [http-auth] HTTP Auth Next BOF at IETF Prague deadline Monday/Possible W3C Workshop? X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 00:20:14 -0000 > Dear all > > I agree that we need more to make focus on the topics to be discussed > in the future working group. > > # Honestly speaking I feel a little sad this moment, but I have to > # agree that haste is from the devil. > > By the way, I listed up some possible topics in the previous mail. In > last few months people, "including me", were very active in discussing > their own ideas of securing the Web, and it was very interesting. > However, at this moment, for each "proposal" we need to figure out how > it can be implemented in the real world seamlessly, how it can be > implemented as a protocol specification in RFC, whether it can be a > IETF topic or have to be discussed in more wider people, and many > others. We also have to take care of how the collaborations should > take part with other working groups (such as OAUTH, and ABFAB), > especially for the federation-based and protocol-stack-based (such as > using SASL in Web) solutions. That is one of the reasons that I wrote > some of the topics in a very abstract way, such as "Research on the > secure ways of Web/HTML authentications and required protocol-side > support for them". If you have some concrete ideas for securing Web, > your feedbacks on the proposed topics list are really really needed. > I would be able to add it to the list of possible topics then. > > And of course, if you have any good idea I really love to see an > Internet-draft on it so that we can understand it more deeply and > start discussion on it. I think MutualAuth is a good starting place, although the issue of browser chrome is still worrisome and a major halting point. As HTTP Auth is obviously broken in its current state, the ideal situation would be something more or less like MutualAuth from the protocol side combined with broader based effort on the client-side to go after "low-hanging fruit" here - i.e. cookie management, ID management, SSL/certs, Javascript security (OK, that one is tough), APIs to make it easier to deploy and try to get a unified user-experience on authorisation across various clients. It's all easy enough to say, but will require a real effort to get done. It's ambitious, I admit - but after the situation in Tunisia in particular where there was a massive man-in-the-middle attack against more or less the entire population! - I think the time is right even if the exact technical solution is not completely clear right now. I'm sure we have enough collective intelligence between the IETF and other concerned parties to make something real, and I think current events may increase both user concern and implementer desire to get things actually in users hands. > > All Regards, > > Yutaka > > -- > Yutaka OIWA, Ph.D. Research > Scientist > Research Center for Information Security > (RCIS) > National Institute of Advanced Industrial Science and Technology > (AIST) > Mail addresses: , > > OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 > 46B5] >