Re: [Cfrg] Suggestion for open competition on PAKE -> Was Re: Dragonfly has advantages

"Dan Harkins" <dharkins@lounge.org> Sun, 05 January 2014 08:12 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076A61ACCEE for <cfrg@ietfa.amsl.com>; Sun, 5 Jan 2014 00:12:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level:
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5lVFUq36_bW for <cfrg@ietfa.amsl.com>; Sun, 5 Jan 2014 00:12:31 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 38CBC1AC828 for <cfrg@irtf.org>; Sun, 5 Jan 2014 00:12:31 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 54DF210224008; Sun, 5 Jan 2014 00:12:23 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sun, 5 Jan 2014 00:12:23 -0800 (PST)
Message-ID: <c48eae38a0cfdd41309ca80aac70b417.squirrel@www.trepanning.net>
In-Reply-To: <52C839D8.6010504@cisco.com>
References: <CEEDD67B.22CC7%feng.hao@newcastle.ac.uk> <52C839D8.6010504@cisco.com>
Date: Sun, 5 Jan 2014 00:12:23 -0800 (PST)
From: "Dan Harkins" <dharkins@lounge.org>
To: "David McGrew" <mcgrew@cisco.com>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: Trevor Perrin <trevp@trevp.net>, "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Suggestion for open competition on PAKE -> Was Re: Dragonfly has advantages
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 05 Jan 2014 08:12:33 -0000

  Hi David,

On Sat, January 4, 2014 8:42 am, David McGrew wrote:
> As a side note, I personally would also like to see
> guidance/documentation on how PAKEs can best be used, and I agree with
> your comment about bootstrapping authentication.  Replacing a raw
> username/password exchange inside of TLS with a PAKE would be good, and
> using a PAKE for password-based certificate enrollment would be good.
> Replacing certificate based authentication with a PAKE would be not so
> good.

  I agree with everything above.

  PAKEs are useful because they provide a certain amount of security even
in the presence of weak, low-entropy passwords. And passwords are easy
and simple to use for people who are not computer savvy much less crypto
clueful, they are intuitive to use. So PAKEs can provide a kind of misuse
resistance.

  PAKEs are also useful for bootstrapping and for things like certificate
enrollment. In fact, it is securing an RFC 7030 exchange that prompted
me to push so hard for TLS-pwd. The fact is that if someone does not
have a certificate then he probably also lacks a suitable trust anchor
database with which to properly secure a certificate-based TLS exchange
to enroll with a CA (any step that populates the trust anchor database
can be used to just give the user a certificate and be done with it). And
in that case they will do is accept an unverified self-signed certificate
and use HTTP digest authentication right before they say "give me the
CA's certificate that I will trust from now on". I know this because I've
seen people deploy this nonsense.

  In addition, when someone is requesting certification of a public
key it makes sense to authenticate using a PAKE with the same group--
384 bit prime ECC for a certified public key, then 384 bit prime ECC with
the PAKE. The group used in the PAKE can't be fixed to the password.

  So we need ECC support in a balanced PAKE. And we needed it a
few months ago when RFC 7030 got published.

  No one should ever use a PAKE in lieu of a certificate-based
authentication scheme provided that the certificate can be, and is,
properly validated. I certainly was not suggesting dragonfly for that
use.

  regards,

  Dan.