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
--