Re: [Cfrg] SPM2 -> was Re: SPAKE2+mbDH a PAKE+PKA

"Stanislav V. Smyshlyaev" <smyshsv@gmail.com> Tue, 04 October 2016 06:05 UTC

Return-Path: <smyshsv@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5641295C9 for <cfrg@ietfa.amsl.com>; Mon, 3 Oct 2016 23:05:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 p7TwqwSYd3Ah for <cfrg@ietfa.amsl.com>; Mon, 3 Oct 2016 23:05:07 -0700 (PDT)
Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B144B12944D for <cfrg@irtf.org>; Mon, 3 Oct 2016 23:05:06 -0700 (PDT)
Received: by mail-it0-x22d.google.com with SMTP id j69so140418377itb.0 for <cfrg@irtf.org>; Mon, 03 Oct 2016 23:05:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BYEFZWYizy2ZUmCMwPeQa2vtARInqrmPNliBO0rVC9M=; b=0Pt0zOEXRHJBpkL81NRm2dYigCwDdfDx/+MqB0nOjUJhJUsFV+8YQ4gkGh1ui/vwGf te1uZa38KJ6KuO5LHqVLNL4AkmLDubWfxYE3P3eWYoI08MWSM63K3PYaZ2KiJbJm4UFg n1GqmZunA20oD1wQZImyx8V9LRmSOOI1NGU1hnWDJjxRR8hdeSkqmMHkViN1SQEWQrTF NKaoRNHWqebIteTmoq/clKaGKghLq7tuvB4+gVbzw+Fnk2mMcjEdZCwC2GaynD3AIG5l ZyNSoCMuEA862EpdkkxiKbz2c+44xJ9JvCts+Zn+lLxpVaO1OLicsOw4gnubPzSWiZjV Ou0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BYEFZWYizy2ZUmCMwPeQa2vtARInqrmPNliBO0rVC9M=; b=SZFBysxXzDOsNNqnEu9SalDHAXGlRzl6yABcSDp0j3WXUAFJLJVMSof50EGt607Ovs ad84pBjGqQ0WXSa5IdIwFmahbgBnlhTvQXVDSzzqtBFwJxvab4bO8gFBDUTG7XTFhFMq BaDiRAtygjPVuZEZdlcgbqKOWmBmn7uUV/kFPDKCb8pqkzJa0GyHYEORqn6yyi1nUUTh yDdAOyhyhKsDM0k63eOoXNdMwKf7ZH6juaUv6NScNX+ePFB/zmNAE3uyza6iZXbiK1I2 iz0ZAUj60JSgsuco53NDQsADi+PimyEEMHZnmfYnk2wQTXDxLDGDHUHUaWZJ3Fw0ydiX 5DvA==
X-Gm-Message-State: AA6/9RmXzigIY5hpKSidvGVd2ElNNgN45P7CxdaWwQroVqfparI2OnjaLAKanzVLjejXrBCq1OKgn7yoE+1O9Q==
X-Received: by 10.36.224.137 with SMTP id c131mr2519440ith.10.1475561105770; Mon, 03 Oct 2016 23:05:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.225.44 with HTTP; Mon, 3 Oct 2016 23:05:05 -0700 (PDT)
In-Reply-To: <D41831C3.A2964%paul@marvell.com>
References: <D41831C3.A2964%paul@marvell.com>
From: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Date: Tue, 4 Oct 2016 09:05:05 +0300
Message-ID: <CAMr0u6k4U0fsXV2jHxam6Lk0OmmDS1NkV9Z43QF3sjJinW7fPQ@mail.gmail.com>
To: Paul Lambert <paul@marvell.com>
Content-Type: multipart/alternative; boundary=94eb2c19e25e8dd38c053e03d73d
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/VU6T09qG1VWYVwpcTioUdP8VUw0>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] SPM2 -> was Re: SPAKE2+mbDH a PAKE+PKA
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Oct 2016 06:05:11 -0000

Dear Paul,

Thank you for the new version!

I'll try to review it and reply in a couple of days.

Kindest regards,
Stanislav


2016-10-04 2:05 GMT+03:00 Paul Lambert <paul@marvell.com>om>:

> Dear Stanislav,
>
> Based on your comments, I’ve made another cut at combining SPAKE2 and
> mbDH. This should not have the problem you identified in the earlier
> version. The combination more directly performs the protocols in parallel.
>
> https://mentor.ieee.org/802.11/dcn/16/11-16-1329-00-00ai-
> pkex-alternatives.ppt
>
> Best Regards,
>
> Paul
>
>
> From: Paul Lambert <paul@marvell.com>
> Date: Monday, October 3, 2016 at 11:49 AM
> To: "smyshsv@gmail.com" <smyshsv@gmail.com>
> Cc: "cfrg@irtf.org" <cfrg@irtf.org>
> Subject: Re: [Cfrg] SPAKE2+mbDH a PAKE+PKA
>
>
> Dear Stanislav,
>
> Thank you very much for your time and effort to review this proposal. I
> greatly appreciate your insights.
>
> Thank you for your comments and for the updated version of the slides.
> Since you agree with my thoughts about the importance of defining "encrypt"
> properties, let's remember this question.
>
> After another careful reading of the protocol now I have a concern about
> it that seems very important to me.
>
> In the original SPAKE2 (as well as in SESPAKE and AugPAKE etc) there is an
> important property (that is even proven for SPAKE2 and SESPAKE) of absence
> of password leakage problems in the cases when the resulting session keys
> are revealed (in real life - when the session key is misused and
> compromised somehow). It is extremely important since session keys often
> get compromised in real life and no one wants to leak authentication data
> with them.
>
>
> I agree with your concerns. The property of preventing password leakage
> when session keys are exposed may not be applicable to every application,
> but it’s still an important attribute. Most importantly …   The combining
> of two security primitives should retain all of the properties of the
> original two primitives.
>
>
> And the proposed protocol lacks this property: if sk_AB is compromised,
> then x_A and P_A are known to adversary too - thus he knows w*M_A and can
> find short secret pw by dictionary attack.
>
> Thus in the current version any agreed session key compromise would lead
> to long-term password compromise, that seems to be a really bad property.
>
>
> I see now that the ephemeral mask in SPAKE2 with the masked public key
> from mbDH have contradictory requirements. The mbDH requires the subsequent
> exposure of the mask to prove possession of the public key. SPAKE2 requires
> that the mask never be exposed even if encrypted under a session key. This
> type of replacement of terms is a flawed construction technique.
>
> A more direct combination of protocol mechanisms would be to perform them
> both in parallel without significant modification to either base mechanism.
> The calculation of the shared key(s) could be performed jointly for some
> efficiency benefits without impacting the combined security
> characteristics.
>
>
> I'll be thankful for your comments on this concern. Please correct me, if
> I missed something in your description.
>
>
> No, your concerns are well founded and show that I violated my own design
> goals for building on existing mechanisms. In my enthusiasm to save a point
> multiple and a few bytes, the proposed design broke a subtile, but
> fundamental security property of SPAKE2.
>
> Best Regards,
>
> Paul
>
>
> Kindest regards,
> Stanislav Smyshlyaev
> *От: *Paul Lambert
> *Отправлено: *четверг, 29 сентября 2016 г., 11:54
> *Кому: *Stanislav V. Smyshlyaev
> *Копия: *cfrg@irtf.org
> *Тема: *Re: [Cfrg] SPAKE2+mbDH a PAKE+PKA
>
>
> Dear Stanislav,
>
>
> Thank you for these links – they give a slightly new viewpoint on PAKEs
> applications (I think the most discussed question will be "for which
> applications will combining public keys and passwords be most useful?").
>
> Yes … it may be useful as a type of ‘introduction’ process.
>
>
> An editorial comment on the description of the protocol in the slides: it
> seemts that after the second message A should check that "R_B - w*M_B ==
> x_B * P_B", not "R_B == x_B * P_B" as it is shown now. Similarly with the
> B's check.
>
>
> And a tiny remark: there is a misprint in the plaintext that A encrypts on
> sk_AB for the third message: "(x_A, P_A)" should be there, not "(m_A, P_A)".
>
>
> Many thanks for catching my errors!
>
> I’ve updated the figures and reposted: https://mentor.ieee.
> org/802.11/dcn/16/11-16-1142-06-00ai-cryptographic-review-and-pkex.ppt
>
>
> About the protocol itself, I'll try my best to give you our opinion today
> or tomorrow.
>
> At a glance, it seems to be useful to add some specific requirements for
> the used "encrypt" functions now or some concrete cipher modes (e.g. GCM or
> CTR + HMAC)
>
>
> Yes, this is not clear. The notation slide mentions  AEAD encryption but
> could say more on requirements. The ‘additional data’ is not being used, so
> AEAD is not strictly required. For concrete examples, I’m considering
> AES-SIV or GCM-SIV or something similar.
>
>
> due to the words "decrypt is successful" (is it a real data authentication
> or just some padding check?). EMVco used to check PIN-blocks just by
> correctness of ECB decryption of IUN, so we should have more details here.
>
>
> Yes, exactly.  The decryption provides the validity check for the password
> based authentication and does need a better description.
>
> Best Regards,
>
> Paul
>
>
> Kindest regards,
> Stanislav
>
>
>
> 2016-09-29 4:25 GMT+03:00 Paul Lambert <paul@marvell.com>om>:
>
>>
>> The PKEX protocol ( https://tools.ietf.org/html/draft-harkins-pkex-00 )
>> provides PAKE functionality (with SPAKE2) and adds public key
>> authentication (PAKE+PKA).
>>
>> In looking at alternatives to PKEX, combining an existing and evaluated
>> authenticated public key exchange with a PAKE seems like an interesting
>> design path. To this end, the SPAKE2 protocol (
>> https://tools.ietf.org/html/draft-irtf-cfrg-spake2-03 ) combines nicely
>> with mutually blinded Diffie-Hellman (mbDH). Blinded DH (bDH) is described
>> in https://www.emvco.com/specifications.aspx?id=285
>>
>> A brief description of the resulting SPAKE2+mbDH protocol is contained in
>> slides 13 to 18 of:
>>
>>         https://mentor.ieee.org/802.11/dcn/16/11-16-1142-04-00ai-cry
>> ptographic-rev
>> iew-and-pkex.ppt
>> <https://mentor.ieee.org/802.11/dcn/16/11-16-1142-04-00ai-cryptographic-review-and-pkex.ppt>
>>
>> Comments would be appreciated.
>>
>> If this protocol seems useful an RFC could be developed.
>>
>> Paul
>>
>>
>>
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/cfrg
>>
>
>
>
>
>
>
>
>
>
>