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, 05 Jan 2014 00:12:23 -0800
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.
- Re: [Cfrg] Suggestion for open competition on PAK… Paul Hoffman
- [Cfrg] Dragonfly has advantages -> was Re: Reques… Paul Lambert
- [Cfrg] Suggestion for open competition on PAKE ->… Feng Hao
- Re: [Cfrg] Dragonfly has advantages -> was Re: Re… Feng Hao
- Re: [Cfrg] Suggestion for open competition on PAK… David McGrew
- Re: [Cfrg] Dragonfly has advantages -> was Re: Re… Trevor Perrin
- Re: [Cfrg] Suggestion for open competition on PAK… Trevor Perrin
- Re: [Cfrg] Suggestion for open competition on PAK… Feng Hao
- Re: [Cfrg] Suggestion for open competition on PAK… Feng Hao
- Re: [Cfrg] Suggestion for open competition on PAK… David Jacobson
- Re: [Cfrg] Suggestion for open competition on PAK… Watson Ladd
- Re: [Cfrg] Suggestion for open competition on PAK… Samuel Neves
- Re: [Cfrg] Suggestion for open competition on PAK… Dan Harkins
- Re: [Cfrg] Dragonfly has advantages Paul Lambert
- Re: [Cfrg] Dragonfly has advantages Feng Hao
- Re: [Cfrg] Dragonfly has advantages Paul Lambert
- Re: [Cfrg] Dragonfly has advantages Feng Hao