Re: [http-auth] [saag] re-call for IETF http-auth BoF
Nico Williams <nico@cryptonector.com> Mon, 06 June 2011 21:22 UTC
Return-Path: <nico@cryptonector.com>
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF20511E81BB for <http-auth@ietfa.amsl.com>; Mon, 6 Jun 2011 14:22:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRFG77HHU80i for <http-auth@ietfa.amsl.com>; Mon, 6 Jun 2011 14:22:39 -0700 (PDT)
Received: from homiemail-a28.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA3011E8175 for <http-auth@ietf.org>; Mon, 6 Jun 2011 14:22:39 -0700 (PDT)
Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 5257F1B405F for <http-auth@ietf.org>; Mon, 6 Jun 2011 14:22:36 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=PX1SP74TJNwqilS2QfPvPlWu2sVruYL4v6+/kDIEMc+r 867I9B7y0ueN26f0aND8pdNvj2z8wLrQvL3+3MpHk8OIykHgyykNTAEX7Q5IypGx ZMhSnXyY8wJDofZBK1iE7GqlB+y91HXBGtxOyvphXii9iZ3kgqnsalpR+TBF6QE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=4UC4scKnEk6TY1qZgP1WRJBUBys=; b=sjj9Dj0GO1i LWQQ/IKIxgdet/LkevyHvxMskw7V9Qx+eseDofPZRwlGJ0ig+QeNQnJOtTev3ON2 4jlOOj2JOALOOYDAqtiC/zgL/6yjuAxIEatBbnhoDoAfni6+h9gww35t4NE0fWz/ 1+N5B/cdoDGa5NnHDFPFl1JENDVyB9uQ=
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 1F9E31B4058 for <http-auth@ietf.org>; Mon, 6 Jun 2011 14:22:36 -0700 (PDT)
Received: by vws12 with SMTP id 12so3922729vws.31 for <http-auth@ietf.org>; Mon, 06 Jun 2011 14:22:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.175.36 with SMTP id bx4mr2040734vdc.21.1307395355427; Mon, 06 Jun 2011 14:22:35 -0700 (PDT)
Received: by 10.52.112.163 with HTTP; Mon, 6 Jun 2011 14:22:35 -0700 (PDT)
In-Reply-To: <20110606170256.GF1565@sentinelchicken.org>
References: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> <A89D85D0-00AB-4F21-8841-6707E9CDCFC4@gmx.net> <20110606170256.GF1565@sentinelchicken.org>
Date: Mon, 06 Jun 2011 16:22:35 -0500
Message-ID: <BANLkTi=qM6y=J-8w-zmCvu=tXSomUrrs2w@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Tim <tim-research@sentinelchicken.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: http-auth@ietf.org
Subject: Re: [http-auth] [saag] re-call for IETF http-auth BoF
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: HTTP authentication methods <http-auth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-auth>, <mailto:http-auth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-auth>
List-Post: <mailto:http-auth@ietf.org>
List-Help: <mailto:http-auth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-auth>, <mailto:http-auth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jun 2011 21:22:42 -0000
On Mon, Jun 6, 2011 at 12:02 PM, Tim <tim-research@sentinelchicken.org> wrote: > In general authentication theory terms, using passwords is relying on > "something you know" (SYK) whereas certificates rely on "something you > have" (SYH). By moving toward password management in the browser, you > turn something you know into something you have. Well, I wouldn't call that "general authentication theory" :) Passwords are either something you know, or something you have, or even both. Because let's face it: users can (and do!) write passwords down, and as soon as they are written down they become "something you have". Also, password managers typically have a master password, so, what's, uh the deal? It strikes me as silly to say that passwords are something you know, as if users might never write them down. Indeed, nowadays some security experts urge users to write their passwords down as a way to enable stronger passwords -- not a bad idea, IMO. A bigger problem with passwords as something you have is the need to carry them. If they're in a browser password manager, well, we need a way to export (and import) the thing. Also, there's no way to securely use a password manager on an untrusted system (or, for that matter, to securely use a password on an untrusted system). In other words, this is hardly the biggest problem we have. The biggest problems we have, IMO, are: - local security (malware) - the lack of strong authentication protocols on the web - the lack of mutual authentication (TLS server certs don't cut it) I'd be perfectly happy with passwords if we had ZKPPs or strengthened password protocols. But we don't. DIGEST doesn't cut it, and we have not much else on the web, not with mutual authentication anyways. > The SYH solutions are very attractive from a security perspective and > from a usability perspective. If it were sufficiently standardized, > browsers can use certificates or random passwords for each site and > users don't have to worry about it. (Of course once we move to a SYH > password model, then what is the point in using passwords at all > again?) Passwords do have the benefit that they work everywhere. Smartcards requre that they be carried around. Fortunately users now have powerful computers with them at all times (i.e., mobile phones). Unfortunately these are powerful computers, with all attendant local security problems. (Also, not everyone carries their phones with them at all times. My daughter certainly doesn't, for example. So we need to be careful here.) > However, SYK will always have a place in the world. There are many > situations where users simply want to be able to type in something > they've memorized. Passwords will never go away completely for this > reason. Add into that the fact that far more average users understand > username/password systems than certificates, and you will have a hard > time convincing the world to switch off of passwords even in > applications that would work prefectly well with SYH. One could always used passwords to authenticate to an online CA or keystore (think SACRED). > To me, the best way forward is to offer seemless integration of SYH > and SYK systems, both allowing for federated authentication and all of > the advanced features everyone seems to want these days. If you > convince application developers and browser vendors to switch to such > a framework, then you also eliminate some barriers to entry for > switching some sites and users to switch away from passwords (or at > least user-chosen passwords). I proposed an authentication framework (based on existing ones) two weeks ago. It turns out that even when there's no fundamental objections to a proposal (or even any objections at all), the fact is that it's hard to get momentum going for any real solutions if those would require either significant investment or just significant re-thinking, or any sort of leap-of-faith. (For example, in my proposal there's a leap-of-faith that not only will mutual authentication help, but that it's feasible to have such a thing on an Internet scale. I don't have proof either way -- it's just a conjecture, though many of us believe that it is correct, but that may not be enough. For another example, I believe my proposal is relatively simple to implement, but I've to convince others of this, and that, for the moment, seems difficult. This is not a complaint -- it is an illustration of the difficulty in achieving change here. Lots of smart people have been working on these problems for many years, and yet we're still more or less stuck with mid-90s technology -- it's not for want of effort or good ideas, but that momentum is difficult to change.) > As a first step to this proposed master plan, the new SYK model must > be more secure than what we are using now, in order to convince people > to move away from web forms to the new system. Protecting against > phishing attacks, which are rampant these days, is one great way to do > that. How would you protect against phishing attacks via a new authentication system? I'm serious. I believe it's possible to improve the situation significantly that way, and I have my reasons, but I want to hear yours. Nico --
- Re: [http-auth] [saag] re-call for IETF http-auth… Yutaka OIWA
- Re: [http-auth] [saag] re-call for IETF http-auth… Tim
- Re: [http-auth] [saag] re-call for IETF http-auth… Nico Williams
- [http-auth] re-call for IETF http-auth BoF Yutaka OIWA
- Re: [http-auth] re-call for IETF http-auth BoF Harry Halpin
- Re: [http-auth] [saag] re-call for IETF http-auth… Hannes Tschofenig
- Re: [http-auth] [saag] re-call for IETF http-auth… Nico Williams
- Re: [http-auth] [saag] re-call for IETF http-auth… Tim
- Re: [http-auth] [saag] re-call for IETF http-auth… Marsh Ray
- Re: [http-auth] [saag] re-call for IETF http-auth… Nico Williams
- Re: [http-auth] [saag] re-call for IETF http-auth… Nico Williams
- Re: [http-auth] [saag] re-call for IETF http-auth… Stephen Farrell
- Re: [http-auth] [saag] re-call for IETF http-auth… Nico Williams
- Re: [http-auth] [saag] re-call for IETF http-auth… Marsh Ray
- Re: [http-auth] [saag] re-call for IETF http-auth… Nico Williams
- Re: [http-auth] re-call for IETF http-auth BoF Yutaka OIWA
- Re: [http-auth] re-call for IETF http-auth BoF Yutaka OIWA
- Re: [http-auth] re-call for IETF http-auth BoF Julian Reschke
- [http-auth] Fwd: re-call for IETF http-auth BoF Yutaka OIWA
- Re: [http-auth] [websec] re-call for IETF http-au… Phillip Hallam-Baker
- Re: [http-auth] [websec] re-call for IETF http-au… Alexey Melnikov
- Re: [http-auth] [saag] [websec] re-call for IETF … Peter Gutmann
- Re: [http-auth] [saag] [websec] re-call for IETF … Nico Williams
- Re: [http-auth] [websec] [saag] re-call for IETF … Stephen Farrell
- Re: [http-auth] [websec] [saag] re-call for IETF … Nico Williams
- Re: [http-auth] [saag] [websec] re-call for IETF … Yutaka OIWA
- Re: [http-auth] [saag] [websec] re-call for IETF … Nico Williams
- Re: [http-auth] [saag] [websec] re-call for IETF … Yutaka OIWA
- Re: [http-auth] [saag] [websec] re-call for IETF … Nico Williams
- Re: [http-auth] [saag] [websec] re-call for IETF … KIHARA, Boku
- [http-auth] Fwd: [saag] [websec] re-call for IETF… KIHARA, Boku
- Re: [http-auth] [websec] Fwd: [saag] re-call for … Thomas Roessler
- Re: [http-auth] [saag] [websec] re-call for IETF … Nico Williams
- Re: [http-auth] [saag] [websec] re-call for IETF … Yutaka OIWA
- Re: [http-auth] [saag] [websec] re-call for IETF … Yutaka OIWA
- Re: [http-auth] [saag] [websec] re-call for IETF … Nico Williams
- Re: [http-auth] [saag] [websec] re-call for IETF … Peter Gutmann
- Re: [http-auth] [saag] [websec] re-call for IETF … Nico Williams
- Re: [http-auth] [saag] [websec] re-call for IETF … Josh Howlett
- Re: [http-auth] [saag] [websec] Fwd: re-call for … Marc Williams
- Re: [http-auth] [saag] [websec] Fwd: re-call for … SHIMIZU, Kazuki
- Re: [http-auth] [saag] [websec] Fwd: re-call for … GOGWIM, JOEL GODWIN
- Re: [http-auth] [saag] [websec] Fwd: re-call for … Nico Williams
- Re: [http-auth] [saag] [websec] Fwd: re-call for … Henry B. Hotz
- Re: [http-auth] [saag] [websec] Fwd: re-call for … Yutaka OIWA
- Re: [http-auth] [saag] [websec] Fwd: re-call for … Yutaka OIWA
- Re: [http-auth] [saag] [websec] Fwd: re-call for … Yaron Sheffer
- Re: [http-auth] [websec] [saag] Fwd: re-call for … Marsh Ray
- Re: [http-auth] [websec] [saag] Fwd: re-call for … Stephen Farrell
- Re: [http-auth] [saag] [websec] Fwd: re-call for … Nico Williams
- Re: [http-auth] [saag] [websec] re-call for IETF … Phillip Hallam-Baker
- Re: [http-auth] [websec] [saag] re-call for IETF … Thomas Fossati
- Re: [http-auth] [websec] [saag] re-call for IETF … Nico Williams
- Re: [http-auth] [saag] [websec] re-call for IETF … Henry B. Hotz