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

Paul Lambert <paul@marvell.com> Tue, 04 October 2016 07:44 UTC

Return-Path: <paul@marvell.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 7DEB21295E7 for <cfrg@ietfa.amsl.com>; Tue, 4 Oct 2016 00:44:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 sFf9k4Fcdl7m for <cfrg@ietfa.amsl.com>; Tue, 4 Oct 2016 00:44:42 -0700 (PDT)
Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02F241295E2 for <cfrg@irtf.org>; Tue, 4 Oct 2016 00:44:41 -0700 (PDT)
Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u947ee4J005146; Tue, 4 Oct 2016 00:44:39 -0700
Received: from sc-exch01.marvell.com ([199.233.58.181]) by mx0b-0016f401.pphosted.com with ESMTP id 25uy8atu2u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 04 Oct 2016 00:44:39 -0700
Received: from SC-EXCH03.marvell.com (10.93.176.83) by SC-EXCH01.marvell.com (10.93.176.81) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 4 Oct 2016 00:44:37 -0700
Received: from SC-EXCH03.marvell.com ([fe80::6cb0:4dfa:f3f3:b8b6]) by SC-EXCH03.marvell.com ([fe80::6cb0:4dfa:f3f3:b8b6%21]) with mapi id 15.00.1104.000; Tue, 4 Oct 2016 00:44:37 -0700
From: Paul Lambert <paul@marvell.com>
To: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Thread-Topic: [Cfrg] SPM2 -> was Re: SPAKE2+mbDH a PAKE+PKA
Thread-Index: AQHSHgrdOKDNID9LN0iPY9SSrJS9bKCX6jeA
Date: Tue, 4 Oct 2016 07:44:37 +0000
Message-ID: <D418A094.A29E7%paul@marvell.com>
References: <D41831C3.A2964%paul@marvell.com> <CAMr0u6k4U0fsXV2jHxam6Lk0OmmDS1NkV9Z43QF3sjJinW7fPQ@mail.gmail.com> <CAMr0u6ngTf+_eW_qhVz0G_jUNHUqPEMyQO+4A3xrqCh2tRe6FQ@mail.gmail.com>
In-Reply-To: <CAMr0u6ngTf+_eW_qhVz0G_jUNHUqPEMyQO+4A3xrqCh2tRe6FQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.5.160527
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.94.250.30]
Content-Type: multipart/alternative; boundary="_000_D418A094A29E7paulmarvellcom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-04_01:, , signatures=0
X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610040134
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/sx2xM_0jSyeiACp9FdQQMd-sPOA>
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 07:44:44 -0000



Dear Stanislav,


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.

Thanks! I missed making this variable change … appreciate your catching this error.

This update also made the shared key calculation more exactly match the SPAKE2 RFC and I missed changing the terms in this hash in a couple places.

These are now fixed in: https://mentor.ieee.org/802.11/dcn/16/11-16-1329-01-00ai-pkex-alternatives.ppt

Best Regards,

Paul



Best regards,
Stanislav



2016-10-04 9:05 GMT+03:00 Stanislav V. Smyshlyaev <smyshsv@gmail.com<mailto: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<mailto: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-pkex-alternatives.ppt

Best Regards,

Paul


From: Paul Lambert <paul@marvell.com<mailto:paul@marvell.com>>
Date: Monday, October 3, 2016 at 11:49 AM
To: "smyshsv@gmail.com<mailto:smyshsv@gmail.com>" <smyshsv@gmail.com<mailto:smyshsv@gmail.com>>
Cc: "cfrg@irtf.org<mailto:cfrg@irtf.org>" <cfrg@irtf.org<mailto: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<mailto: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<mailto: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-cryptographic-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<mailto:Cfrg@irtf.org>
https://www.irtf.org/mailman/listinfo/cfrg











_______________________________________________
Cfrg mailing list
Cfrg@irtf.org<mailto:Cfrg@irtf.org>
https://www.irtf.org/mailman/listinfo/cfrg