Re: [Cfrg] Another PAKE question

Yoav Nir <ynir@checkpoint.com> Thu, 09 January 2014 08:00 UTC

Return-Path: <ynir@checkpoint.com>
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 3B8061AE143 for <cfrg@ietfa.amsl.com>; Thu, 9 Jan 2014 00:00:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.439
X-Spam-Level:
X-Spam-Status: No, score=-7.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_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 VFlczKj5kh_o for <cfrg@ietfa.amsl.com>; Thu, 9 Jan 2014 00:00:35 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C0BDB1AE08E for <cfrg@irtf.org>; Thu, 9 Jan 2014 00:00:34 -0800 (PST)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id s0980NWT003584; Thu, 9 Jan 2014 10:00:24 +0200
X-CheckPoint: {52CE51D4-0-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.110]) by IL-EX10.ad.checkpoint.com ([169.254.2.120]) with mapi id 14.03.0123.003; Thu, 9 Jan 2014 10:00:23 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Dan Harkins <dharkins@lounge.org>
Thread-Topic: [Cfrg] Another PAKE question
Thread-Index: AQHPDQFcMPcnbhPjVUeB5uP0j163gJp73FEAgAAJ2gA=
Date: Thu, 9 Jan 2014 08:00:22 +0000
Message-ID: <45B947F7-A018-4F52-BA1D-667B35FF4026@checkpoint.com>
References: <B17D6E18-898E-44EF-94EF-A4419BDE908A@checkpoint.com> <53bf7ac99fb17e4f9333d42fea20505c.squirrel@www.trepanning.net>
In-Reply-To: <53bf7ac99fb17e4f9333d42fea20505c.squirrel@www.trepanning.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.21.3]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <EBD61BF1CB8C9947AFBCDEDB4D3AC966@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Another PAKE question
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: Thu, 09 Jan 2014 08:00:37 -0000

On Jan 9, 2014, at 9:25 AM, Dan Harkins <dharkins@lounge.org>
 wrote:

> 
>  Hi Yoav,
> 
> On Wed, January 8, 2014 10:09 pm, Yoav Nir wrote:
>> Hi
>> 
>> I almost feel like I'm asking for trouble after the roast that Dan went
>> through, but some on this list might want to consider another PAKE going
>> through an IETF working group.
> 
>  While I think you are definitely asking for trouble, it's good that you do.
> Trying to fly under the radar would not be a good thing.
> 
>> HTTP-Auth is making experimental authentication mechanisms for the HTTP
>> layer. One of those is a PAKE. If people here on the CFRG list would like
>> to comment on it, that would be great. We can have some discussion here,
>> but ultimately, comments criticisms and suggestions should go to the
>> HTTP-auth list (details below).
>> 
>> The draft in question is called "Mutual Authentication Protocol for HTTP".
>> 
>> Link: http://tools.ietf.org/html/draft-ietf-httpauth-mutual-01
> 
>  It doesn't look like that draft specifies a PAKE. It seems to specify the
> exchange of data that can be used by a PAKE, but not necessarily.

Right. I forgot to link to the auxiliary algorithm draft:
http://tools.ietf.org/html/draft-oiwa-httpauth-mutual-algo-01


> Section
> 11 states:
> 
>    Cryptographic authentication algorithms which are used with this
>    protocol will be defined separately..
> 
>    All algorithm used with this protocol SHOULD provide secure mutual
>    authentication between client and servers, and generate a
>    cryptographically strong shared secret value z, equivalently strong
>    to or stronger than the hash function H. If any passwords (or pass-
>    phrases or any equivalents, i.e. weak secrets) are involved, these
>    SHOULD NOT be guessable from any data transmitted in the protocol,
>    even if an attacker (either an eavesdropper or an active server)
>    knows the possible thoroughly-searchable candidate list of the
>    passwords.
> 
> That SHOULD and SHOULD NOT mean that it could actually use an
> authentication algorithm that doesn't provide mutual authentication
> and that is susceptible to an off-line dictionary attack. You might
> want to make those a MUST and MUST NOT.
> 
>  So where is the separately defined protocol that this draft uses?
> 
>  Also, figure 5 seems almost like a joke. Is this protocol _really_
> that complicated? A security protocol that complicated seems like
> a recipe for disaster.
> 
>  regards,
> 
>  Dan.
> 
>> Yoav
>> co-chair of HTTP-Auth
>> 
>> Mailing list details:
>> * http-auth List Information:
>> https://www.ietf.org/mailman/listinfo/http-auth
>> * http-auth List Archives:
>> http://www.ietf.org/mail-archive/web/http-auth/current/maillist.html
>> * http-auth Posting Address (requires registration): http-auth@ietf.org
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> http://www.irtf.org/mailman/listinfo/cfrg
>> 
> 
> 
> Email secured by Check Point