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

"Stanislav V. Smyshlyaev" <smyshsv@gmail.com> Tue, 04 October 2016 06:45 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 90B791294F4 for <cfrg@ietfa.amsl.com>; Mon, 3 Oct 2016 23:45:16 -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 o3qz7fQcu_Gg for <cfrg@ietfa.amsl.com>; Mon, 3 Oct 2016 23:45:14 -0700 (PDT)
Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 0CC95127A91 for <cfrg@irtf.org>; Mon, 3 Oct 2016 23:45:14 -0700 (PDT)
Received: by mail-io0-x234.google.com with SMTP id i202so63416515ioi.2 for <cfrg@irtf.org>; Mon, 03 Oct 2016 23:45:14 -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=kN1vhpf5uELL9DwXdq10LxdSY01Db7LhoKcJTE/6xaI=; b=mx34phXXkoTbwpqVqbLGiqVSqH85Y8I4fSvawM9poGmMphq3vjSTl54VARooSgtc/f Vj/yYlwPS2S1IjRGbXt5WZMnm0mS5lHJwSNwS9S0ni0vQk49ERT2sr7avXRUjIbffyYa lEVHqw4XvOTTQUNWqw2GlEal8s7wxwZzd1f7Pgozv55v+DhVejnrpABv61W8y163/lI/ GjnOfg4JSeqU5gUR9Pehrwhbm5M760cW3ALKFVUFrf+P6r9C6YDaA+uawiD9p2i7m+/f BBU7sJEvjtZkrDnzyfUx15LpNcF2IZPstPyXgxWWTl3wXgm+LeUyyVsuvmcbJZwPHAaH HWXw==
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=kN1vhpf5uELL9DwXdq10LxdSY01Db7LhoKcJTE/6xaI=; b=LR4fI/d5mEMeVRVpsRbdvkG3OVmgcrQy+2xHqtAZowo8TVv649uS8a8X6X7InGOZYn TeAu1nwyrU7qCDyDiaHz3zMTxz/50HcGm4/LOP8cvGd8UOVjBZZQXUvbrQp5djlEf0N/ fBK1O78e0Ug+qUB++lDpLW9m2ESgI9tJ5Zy6n7ymWvj06vTCRsU0wQH9G+z4RASPXv8y SmmqKeXPH2hs7t9d804KFfx3l/RalKNo1bgY8m+XWswrOBqYvO5zD9ISKezXrTJrmd03 C1Ha0aMaDSAnSJsL/8/pz6fs9dt6eJQdNp/hS2/t7M/zMrmjsxOmSyaZYbUNAV1czF2G 6ZPA==
X-Gm-Message-State: AA6/9RnMcNHpaJmyZkiHCcKS0yN+xImJQTYy7L/3jyfXS96k19ciNTdIDB6sC8T9BD3bG8kHjYuHrj3avbsvyQ==
X-Received: by 10.107.132.217 with SMTP id o86mr2745151ioi.81.1475563513260; Mon, 03 Oct 2016 23:45:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.225.44 with HTTP; Mon, 3 Oct 2016 23:45:12 -0700 (PDT)
In-Reply-To: <CAMr0u6k4U0fsXV2jHxam6Lk0OmmDS1NkV9Z43QF3sjJinW7fPQ@mail.gmail.com>
References: <D41831C3.A2964%paul@marvell.com> <CAMr0u6k4U0fsXV2jHxam6Lk0OmmDS1NkV9Z43QF3sjJinW7fPQ@mail.gmail.com>
From: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Date: Tue, 04 Oct 2016 09:45:12 +0300
Message-ID: <CAMr0u6ngTf+_eW_qhVz0G_jUNHUqPEMyQO+4A3xrqCh2tRe6FQ@mail.gmail.com>
To: Paul Lambert <paul@marvell.com>
Content-Type: multipart/alternative; boundary="001a113f85d40d541a053e04675a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/iZfeavjVuZkxxhbv1gfO4gEeV8k>
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:45:16 -0000

Dear Paul,

Just a small remark: I'm sure that in the second message you wanted to send
"encrypt( key=sk_BA, ((y_B, P_B), ...) )", not "encrypt( key=sk_BA, ((x_B,
P_B), ...) )" (and "y_A, P_A" correspondigly). Otherwise you would obtain
exactly the same problem as before.

Best regards,
Stanislav



2016-10-04 9:05 GMT+03:00 Stanislav V. Smyshlyaev <smyshsv@gmail.com>:

> 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>:
>
>> 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-pke
>> x-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>:
>>
>>>
>>> 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
>>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>
>