Re: [Cfrg] CPace feedback regarding the identity handling

"Hao, Feng" <Feng.Hao@warwick.ac.uk> Tue, 09 June 2020 20:48 UTC

Return-Path: <Feng.Hao@warwick.ac.uk>
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 C9F763A0865 for <cfrg@ietfa.amsl.com>; Tue, 9 Jun 2020 13:48:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 iKJoAdjrFYvq for <cfrg@ietfa.amsl.com>; Tue, 9 Jun 2020 13:48:22 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10087.outbound.protection.outlook.com [40.107.1.87]) (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 F07803A0861 for <cfrg@irtf.org>; Tue, 9 Jun 2020 13:48:21 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eA2Qc0uNd3GuBT4vnoL6tcl8RmjlxPK52jJAFZIdu2LgS940IVSX2hgKeETeyh8OOl+qefXXam5zkKT0eUSxzMiNAul4+fkjSzhRxt12QfmhZEXv3LB0KQ4Op/yn0D5JOEUyYbOKcd7dHu59xyCPHgiUjGIkq5j4mDEUdQJIU7YJXtEVPbXt9E9IeTjwHKNkAWehgqpFNZp++tvuSPQjXJHQozVXMHY2PPdETJGDYNck6p5lO5jsrzpN5aLPaFaiW7mlnksBq1ve36lhL80DokCP9gwrrU7pv9EaXJzI/a97qnCw/PWdb6Fg/fZMVqo4iHxC5NCexnEAbvf/rreH/g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3J2W297rLOsNXm5rv6OJi6ZUGrvWzE2tBamEouesfoc=; b=QWeATObQiso14ipa1pGtC5cmzmnUrwmvkSP4ulUIhahbyoMRe6KNTWCNdzGMhefyKuBWjRoqGeWyeeV1c0kbNWb/V8pcznwUTowsBqXaGdcO0uFufPXvuG2q/CmBy7Uc3j1LHMTucsiVJiHPGrWUjnQaYIYV3SzRhagNTY3s1YinJRdWWHsp4mxOgU9YsotcOEzBMmFQuJyrtVCbUAVI7yBGxbIO11RW3S32bpYNWZhpfjSVG5AqvMtTB3by7AYlpD7SgVAQVwfYJrJ29maeItcG8wCz6NZPlk/AsWnzVMElkp0HoJNdr9HdyDux+ryi1FmEWxnXZWfl/SX2Pjo4Ww==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=warwick.ac.uk; dmarc=pass action=none header.from=warwick.ac.uk; dkim=pass header.d=warwick.ac.uk; arc=none
Received: from VI1PR01MB4285.eurprd01.prod.exchangelabs.com (2603:10a6:803:65::27) by VI1PR01MB3806.eurprd01.prod.exchangelabs.com (2603:10a6:802:5d::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Tue, 9 Jun 2020 20:48:18 +0000
Received: from VI1PR01MB4285.eurprd01.prod.exchangelabs.com ([fe80::dd1c:bb47:e1be:cc52]) by VI1PR01MB4285.eurprd01.prod.exchangelabs.com ([fe80::dd1c:bb47:e1be:cc52%6]) with mapi id 15.20.3066.019; Tue, 9 Jun 2020 20:48:18 +0000
From: "Hao, Feng" <Feng.Hao@warwick.ac.uk>
To: =?utf-8?B?QmrDtnJuIEhhYXNl?= <bjoern.haase@endress.com>, =?utf-8?B?QmrDtnJuIEhhYXNl?= <bjoern.m.haase@web.de>
CC: "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: [Cfrg] CPace feedback regarding the identity handling
Thread-Index: AdY+j4PcV/IRjdNZTzK8UubyPmwE8wAGCseA
Date: Tue, 9 Jun 2020 20:48:18 +0000
Message-ID: <608DB23A-E040-4838-A727-FB26A57796AA@live.warwick.ac.uk>
References: <AM0PR05MB4786646AE85B46AC15C4488B83820@AM0PR05MB4786.eurprd05.prod.outlook.com>
In-Reply-To: <AM0PR05MB4786646AE85B46AC15C4488B83820@AM0PR05MB4786.eurprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_Enabled=True; MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_SiteId=52daf2a9-3b73-4da4-ac6a-3f81adc92b7e; MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_Owner=bjoern.haase@endress.com; MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_SetDate=2020-06-09T19:01:41.0962105Z; MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_Name=Not Protected; MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_Application=Microsoft Azure Information Protection; MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_ActionId=ea7fac49-fbf4-497f-9db6-7da2f57e0267; MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_Extended_MSFT_Method=Automatic
user-agent: Microsoft-MacOutlook/16.37.20051002
authentication-results: endress.com; dkim=none (message not signed) header.d=none;endress.com; dmarc=none action=none header.from=warwick.ac.uk;
x-originating-ip: [86.1.47.16]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f1800f14-362c-427b-a9e2-08d80cb6705e
x-ms-traffictypediagnostic: VI1PR01MB3806:
x-microsoft-antispam-prvs: <VI1PR01MB38060078E258E7692E421B34D6820@VI1PR01MB3806.eurprd01.prod.exchangelabs.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 042957ACD7
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: WrCkV2ubxVf4aPNPZLXrLzBGX7TvnJChxBeyNHaG+nMQ2EfAW9+tpcBFCbSR+PR7cgBw9lpyzyHGdBS2d60/mOdwweSPuCMsoAyqa42zyCY0pSXW5hD224tPjC0RY2vROgZq3fbZTkqeFSVzSzPlJyf2MZs/9iFkmrdcQZE4SQ2tRJzNGlQw4iq/ecfkwxV06vM7zmh8F3nbWQ7XbEm6p7g9+fkkFRn0Ylx/so0kJyomsKUPdGIG72bM6hgfiJY4jynzS5QyIfcMElmGHFi48uvNseJu1yg1fKysH4n9JvPObsXywVjOYFxY432OsZ39vmc3bcn1xedXUSuDmnb7QzE3gjsVjIzCc5MPasvhEGxST2HQHoxZ8ghJcfZHyvGspkfTcvsGYpHUL46BIIa9LQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR01MB4285.eurprd01.prod.exchangelabs.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(396003)(366004)(39860400002)(136003)(86362001)(6506007)(26005)(478600001)(786003)(66446008)(66574014)(8676002)(186003)(110136005)(8936002)(83380400001)(15974865002)(5660300002)(316002)(71200400001)(33656002)(2906002)(4326008)(45080400002)(66556008)(64756008)(91956017)(76116006)(966005)(6486002)(66946007)(6512007)(66476007); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: UFHz0aEFvRP+3RgkZ9c69GdmXAudLJOmCIdIYKqk+HpzrzMPOoERac0r4RieOrlJXvV+cP0v0NCl3O8Rch9A2JIBjoWaQoZR08iyeaNApRc20QJ247HOjAu4RTP03ZqbC7O59Tsydrt/zZ4+Aa9DBiQYVewIqzik6KIi/o837fRUAsAbfsQ5vG3UOk8XcNCPUdRMJY78rul15v4zr2r0iCQKn0xiaYynd4oG37gZoXpBEw50dTruJgHFnxhALWzXmPg1jJ/0+LODs6sU8cfbnPkW2Ps5uG3XTVioOCY/EwahlNZ7/Rivr722e0PPXSCgWQl6q0wH4LSUPISSNdTHi3b0/p8yVtuXSLLlOMqBaOq3L/EKeNR9sn+Cr+2WrDRHryAn75b0oLrHYz5xQpEAK+XBoCxzfNdUp8Cfks53+ubxyDw8ltY9aj8SMInQ6QZBsQqGpEzqONQqa48WIPbk+RNUeJOovTMShzuhFeaoT7A=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <0A8856E314DB174497873631AC919315@eurprd01.prod.exchangelabs.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: warwick.ac.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: f1800f14-362c-427b-a9e2-08d80cb6705e
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2020 20:48:18.0639 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 09bacfbd-47ef-4465-9265-3546f2eaf6bc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: xzGSTeepY0O+xkOrjONu7NumbxR5ewHGojMpyTbGyBjhrH6YfZlWDZHqa16StGbbzIdR9gETzYdyjF5vh0IlEzNhJ5T0LVHU3rB+Idnn43M=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR01MB3806
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/CjhQFIQAAVI2X_nNI35DwXphDPQ>
Subject: Re: [Cfrg] CPace feedback regarding the identity handling
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
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, 09 Jun 2020 20:48:25 -0000

Dear Bjorn,

Thanks for your response. I understand it's an implicit assumption that you make in your paper. I just wanted to highlight it explicitly so people are aware of the potential difficulty in the implementation and the fact that this is not how PAKE normally works. I don't think the use of a GUI program as you suggested does any help to resolve this fundamental issue. Note that this issue doesn’t apply to other PAKE protocols.

Your suggestion of including the identities into the KDF to resolve this issue is reasonable, but that will be a different protocol. Btw, that is exactly what we did in the design of the patched SPEKE in ISO/IEC 11770-4:2017 (https://arxiv.org/pdf/1802.04900.pdf).

Cheers,
Feng

On 09/06/2020, 20:01, "Björn Haase" <bjoern.haase@endress.com> wrote:

    Dear Hao,

    Regarding your remark regarding the structure of the channel identifier, the device Identities A, B were not meant to be memorized or typed by the end user by us but are meant to be inputs available in some binary form by the computers that run the protocol.

    For instance A and B might be a string shown in a GUI control of a login message "You are requested to authenticate to the server device A='someServerIdentityName', please enter the password for this specific server". 

    The implicit assumption of CPace is that in some form the server identity information needs to be available in some digital form at protocol start at least for the initiator. This holds at least if a password is to be entered on a human user GUI control. The user needs to be given this information before choosing the right password for the remote unit.

    A and B possibly could also be MAC addresses, Hardware serial numbers or the like in case of machine-machine interfaces. The name "Channel Identifier" CI indicates that it should specify in some way which end points are to be connected and possibly, if there are more than one active interconnections, which one among these interconnections.

    Including this in the input string CI avoids the need to keep these strings as part of the state of the CPace protocol and reduces memory consumption, but requires that A and B are available upon protocol start. In the current definition, the only state that a CPace player needs to keep during for an active session is the session ID and the secret exponent (ya or yb).

    Without any impact on the proof A and B could alternatively also be transmitted together with Ya and Yb in the protocol messages and integrated in the final hash in the transcript. This comes at the cost of slightly larger state. For the proof correctness, the requirement is that the CPace result ISK needs to be bound to the identities.

    Without the A/B identifiers, relay attacks in the style of the "selfie" attack on TLS would be feasible and the proof would not hold because a such a relay attack would become possible in the real world but not possible in the ideal world.

    Regarding the question whether to include the A/B information better initially or better in the final hash is probably worth a discussion.

    Yours, 

    Björn



    Mit freundlichen Grüßen I Best Regards 

    Dr. Björn Haase 


    Senior Expert Electronics | TGREH Electronics Hardware

    Endress+Hauser Liquid Analysis

    Endress+Hauser Conducta GmbH+Co.KG | Dieselstrasse 24 | 70839 Gerlingen | Germany
    Phone: +49 7156 209 377 | Fax: +49 7156 209 221
    bjoern.haase@endress.com |  www.conducta.endress.com 





    Endress+Hauser Conducta GmbH+Co.KG
    Amtsgericht Stuttgart HRA 201908
    Sitz der Gesellschaft: Gerlingen
    Persönlich haftende Gesellschafterin:
    Endress+Hauser Conducta Verwaltungsgesellschaft mbH
    Sitz der Gesellschaft: Gerlingen
    Amtsgericht Stuttgart HRA 201929
    Geschäftsführer: Dr. Manfred Jagiella


    Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, wenn wir personenbezogene Daten von Ihnen erheben.
    Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis (https://www.endress.com/de/cookies-endress+hauser-website) nach.





    Disclaimer: 

    The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer. This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such.



    -----Ursprüngliche Nachricht-----
    Von: Cfrg <cfrg-bounces@irtf.org> Im Auftrag von Hao, Feng
    Gesendet: Dienstag, 9. Juni 2020 13:16
    An: Björn Haase <bjoern.m.haase@web.de>
    Cc: cfrg@irtf.org
    Betreff: Re: [Cfrg] Comments on the CPace proof and the CFRG PAKE selection process

    Dear Bjorn (and CFRG),

    I hope you are all well.

    I raised one question about CPace during the selection process, however I don't think it has been properly addressed. Also I don't know whether the selection panel have actually taken this into account. Given that the selection process has finished and that CPace will likely be fielded, I feel we (everyone on CRFG) still have the responsibility to make sure all the technical claims in CPace are accurate and that the protocol can indeed be implemented securely and efficiently.

    CPace modifies SPEKE by adding a random string (session ID) in the first flow. It claims to be one-round and UC-Secure.

    However, the design of CPace is based on an "unusual" assumption: namely, each party should know the shared password and the other party's identity even before any communication in key exchange takes place. I say this is "unusual" as no other PAKE protocols make the same assumption, as far as I can tell. 

    The "standard" assumption (e.g., as defined in ISO/IEC 11770-4) in PAKE is that a user only needs to memorize a shared password. The identities are established in-flow as part of the key exchange process and are verified based on the equality of the two passwords supplied by the two parties. This is reflected in all the PAKE designs that I know - but with exception of CPace.

    One implication for the "unusual" assumption in CPace is that now a user not only needs to memorize a password, but also memorize the other party's "exact" identity which is to going to be used in the key exchange. However, when a key exchange session fails, it's simply impossible to distinguish whether the failure is due to the use of the wrong password or the user mis-remembering the other party's identity. This will impose severe difficulties in the implementation, e.g., defending against online dictionary attacks.

    The other issue I raised in the earlier discussion in this list is that from the protocol design perspective, CPace is under-specified: there is no specification in the discrete logarithm setting, and several critical efficiency/security questions have been abstracted away by the idealization of hash-to-curve (which is yet to be established). 

    Best regards,
    Feng


    _______________________________________________
    Cfrg mailing list
    Cfrg@irtf.org
    https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg&amp;data=02%7C01%7Cbjoern.haase%40endress.com%7Cde190fc13b26402f113208d80c668bd7%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C1%7C637272981885924039&amp;sdata=Jj39ka13ASLKkMKsMjqllavkRfR1AbO6r0v%2BBMuDpAY%3D&amp;reserved=0