Re: [Cfrg] PAKE selection process: status after Phase 1 and following steps

Watson Ladd <watsonbladd@gmail.com> Wed, 17 July 2019 15:16 UTC

Return-Path: <watsonbladd@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 E1C19120761 for <cfrg@ietfa.amsl.com>; Wed, 17 Jul 2019 08:16:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 WNJmQP1LynMl for <cfrg@ietfa.amsl.com>; Wed, 17 Jul 2019 08:16:32 -0700 (PDT)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 6B3AD12008A for <cfrg@irtf.org>; Wed, 17 Jul 2019 08:16:32 -0700 (PDT)
Received: by mail-lf1-x133.google.com with SMTP id q26so16803037lfc.3 for <cfrg@irtf.org>; Wed, 17 Jul 2019 08:16:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Ip44QfOiPHvj1/gOivJ6fClhuMBROrTexP09MSlTLXM=; b=hq04Xd4Hy+X61mKMkKSA6GeHxY/K5I6GnEEGDq1yqiRg43VNUmCXRo84amwBGU6Vgv odPpZ/3yzY0sHSsYJJq0HukcGhQehfcTHPPMnlA8xeFkLTLqg6+leg4ludqWdsgFaFiy /wX1nCh+QkBdxliL1DGhkqbWaAJyouHkjfwIjQBw1zoOLWo6JKST9Kb52AQgMyWL6gAj qn7CE7U9flNvCka5bafIJcUYLVA8hV1CvlWR9YupW9Pj/FZytOTpp8OX2njTe402Wnev Tvwz4FXdVZBPCEjarBzuTCIwG1UV89p6xjdEl2VxJmnqW4Y49dIOl8r+bhdQeWwhmJr2 zgvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Ip44QfOiPHvj1/gOivJ6fClhuMBROrTexP09MSlTLXM=; b=P4FIquAiN1K7mO5OHZ+jf3UGuJJ4SOz26yLYE6EPAe3eH24RCHqr2m7EMu3Ry2Du2R xyD0hD9xFHAkyXHfgYc+PxZX9K8mDmQTN8nxgKUUlzXYtWni6u5QTcfOcOkqb2VUAJZ4 LpZ1pHm8f3BgOzDkce0iOFH1xxkIZUkbeEDYdSltJNLt8CaLpVRZ7WSTyVsbwXoMubE1 aeYxEgq6wU4O6KFSriwAcLhFiYaVBdaa5quaHZwv94ue5EmwY6io0iaKOHp/NlfR3Cuc Gi42aLAqUX8PiObKk3ppwReWqG20kZ7HckraWtfzcagLsWLnd/uVeA+lPzQDDHqtK8xU v3qQ==
X-Gm-Message-State: APjAAAWpiVX13NBELHmpkJ/wVoqBsjZ7ZgULYX0nu0G2kE+eSEplm2QU 0gZTurX2/iAeDOYqae0JTGOI3tO+x9J7rOYxYuTxSXk8
X-Google-Smtp-Source: APXvYqxtLt0pvThKA7SGOHJsqU/wuCZY/hhmzoseKooVOS9jxi6Hlw/IfZs0bYe47Zd3ci9xNsJewu/vk9hKhi1u9OM=
X-Received: by 2002:a19:2297:: with SMTP id i145mr17985537lfi.97.1563376590423; Wed, 17 Jul 2019 08:16:30 -0700 (PDT)
MIME-Version: 1.0
References: <CAMr0u6kxgX+gL7ABxiyDG6KiWdH0qe48R_jL+GHbQNsS0h6yYQ@mail.gmail.com> <39f25d3e-bd34-640f-6c30-6fe3108a2050@lounge.org>
In-Reply-To: <39f25d3e-bd34-640f-6c30-6fe3108a2050@lounge.org>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Wed, 17 Jul 2019 08:16:18 -0700
Message-ID: <CACsn0c=XjQuZ2_XDM_xrTQfi-TE6u=oYwbDG4-5bdD+AvF+qtg@mail.gmail.com>
To: Dan Harkins <dharkins@lounge.org>
Cc: CFRG <cfrg@irtf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/sNa-Q2BjknH8WClJLSdlpjjX9Gk>
Subject: Re: [Cfrg] PAKE selection process: status after Phase 1 and following steps
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: Wed, 17 Jul 2019 15:16:36 -0000

Thank you Dan for providing the answers. I apologize for my slow response.

On Wed, Jul 17, 2019 at 12:25 AM Dan Harkins <dharkins@lounge.org>; wrote:
>
>
>   Hello,
>
>   Below are the responses for SPEKE to the RFC 8125 PAKE requirements
> and the additional questions.
>
>   regards,
>
>   Dan.
>
> ---------------------------------------------------------------------
>
>    REQ1:  A PAKE scheme MUST clearly state its features regarding
>           balanced/augmented versions.
>
> SPEKE is a balanced PAKE but it can easily be made augmented (e.g. the
> B-SPEKE protocol).
>
>    REQ2:  A PAKE scheme SHOULD come with a security proof and clearly
>           state its assumptions and models.
>
> A security proof for SPEKE in the random oracle model based on a new
> assumption, "the Decision Inverted-Additive Diffie-Hellman" was
> published in:
>
> Philip MacKenzie, On the Security of the SPEKE Password-Authenticated Key Exchange Protocol,
> Cryptology ePrint Archive, Report 2001/057, 2001, https://eprint.iacr.org/2001/057
>
>    REQ3:  The authors SHOULD show how to protect their PAKE scheme
>           implementation in hostile environments, particularly, how to
>           implement their scheme in constant time to prevent timing
>           attacks.
>
> SPEKE uses a password-derived generator to perform a Diffie-Hellman key exchange.
> Derivation of this generator can be done in constant time using a CFRG-approved
> hash-to-element technique.
>
>    REQ4:  If the PAKE scheme is intended to be used with ECC, the
>           authors SHOULD discuss their requirements for a potential
>           mapping or define a mapping to be used with the scheme.
>
> SPEKE can be used with ECC and, as noted under REQ3, an appropriate hash-to-curve
> algorithm can be used to obtain the password-derived generator.
>
>    REQ5:  The authors of a PAKE scheme MAY discuss its design choice
>           with regard to performance, i.e., its optimization goals.
>
> In addition to the operations necessary to map the password to a generator, SPEKE
> reuires two modular exponentiations.
>
> Another benefit of SPEKE is that as a balanced PAKE it just requires the same
> password to be provisioned on the two peers. There is no secure channel between
> them that is assumed to exist or have existed and there are no storage requirements
> placed on implementations.
>
>    REQ6:  The authors of a scheme MAY discuss variations of their scheme
>           that allow the use in special application scenarios.  In
>           particular, techniques that facilitate long-term (public) key
>           agreement are encouraged.
>
> (Note: this is not being written by the author of the scheme).
>
> Techniques to facilitate long-term public key agreement can be built on top of
> SPEKE much in the same way that PKEX built on top of SPAKE2. Because there is
> no requirement for a secure channel to provision SPEKE there is no catch-22.
>
>    REQ7:  Authors of a scheme MAY discuss special ideas and solutions on
>           privacy protection of its users.
>
> SPEKE provides no privacy protection but it doesn't preclude it either. It could
> be possible to implement a scheme similar to that used by TLS-PWD (RFC 8492)
> at the cost of a secure channel at provisioning time.
>
>    REQ8:  The authors MUST follow the IRTF IPR policy
>           <https://irtf.org/ipr>;.
>
> SPEKE was patented with U.S. Patent 6,226,383. That patent expired in March 2007.
> There are no other patents that are known to apply to SPEKE.
>
> Additional questions from Stanislav Smyshlyaev on 5 July 2019
>
>     How does it meet the "SHOULD" requirements of RFC 8125?
>
> I do believe so, yes.
>
>     Does it meet "crypto agility" requirements, not fixing any particular primitives
>     and/or parameters?
>
> Very much so.
>
>     What setting is the PAKE suitable for, which applications does it have?
>         "Peer communication" (where both ends share the same password) or "client-server"
>     (where the server does not store the password but only a one-way function of the
>     password)?
>
> As a balanced PAKE, SPEKE is suitable for peer communications. It can also be implemented
> in a true peer-to-peer protocol where there are no "initiators" and "responders".
>
>         A nomination should specify for which use-cases the protocol is recommended ("PAKE
>     as a more-secure replacement for a PSK on a machine-2-machine interface" or "PAKE
>     for securely accessing a remote HMI interface server (e.g. a web server) without
>     configured WEB-PKI certificates").
>
> This is definitely a more secure replacement for a PSK. Any kind of deployment where each
> side agrees on a passcode/passphrase, from establishing keys to secure routing messages
> to IoT devices with a limited UI. Any application that traditionally was done with "enter
> password here".
>
>         Can two communicating parties initiate the key exchange process at the same time,
>     or must it always be the case that only one party can initiate the process?
>
> SPEKE could be adapted into such a key exchange, such as the (abandoned) IKEv3 proposal.
>
>         Is it suitable to be considered as a standalone scheme?
>
> Yes.
>
>         Can it be integrated into IKEv2? TLS Handshake? Any other protocols?
>
> IKEv2 definitely. As a balanced PAKE it is perfect for this. For TLS it could be made
> to work but honestly an augmented PAKE would be better for TLS. For other protocols,
> it would be ideal for LAKE or an ACE protocol.
>
>     Is there a publicly available security proof? If yes,
>         Are there known problems with the proof?
>
> Not that I know of.
>
>         Is the considered security model relevant for all applications that PAKE is intended
>     for (e.g., if a PAKE is to be used in TLS Handshake, it is important that the TLS
>     adversary model is considered for the PAKE)?
>
> I believe so.
>
>         Does it allow to be sure in sufficient level of security for common values of
>     password lengths?
>
> Yes.
>
>     Security assessment.
>         Does its security depend on any nontrivial implementation properties? Are they
>     clearly stated in the document?
>
> No.
>
>         Does the PAKE have precomputation security (for augmented PAKEs)?
>
> N/A
>
>         If the PAKE relies on the assumption of a trusted setup - more specifically, the
>     discrete logarithm relationship between the two group elements in the system setup
>     MUST be unknown - in anticipation of the worst but not impossible scenario, the
>     authors should clearly state the security implications when the discrete logarithm
>     relationship becomes known, and the subsequent mitigation measures.
>
> N/A
>
>     Performance assessment.
>         What's with the “round efficiency” of the PAKE? In a standard two/multi-party secure
>     computation setting, the “round” is defined as a step in which all parties can
>     complete operations at the same time without depending on each other. In practice,
>     a 2-round protocol could be implemented as 2 flows or 3 flows depending on the
>     application context, but that’s more the implementation detail.
>
> The SPEKE protocol is simply a Diffie-Hellman but to do a secure PAKE it is necessary to
> confirm the established keys. So this would be a 3- or 4-message exchange.
>
>         How many operations of each type (scalar multiplications, inversions in finite
>     fields, hash calculations etc.) are made by each side?
>
> Excluding the hash-to-element calculations to derive the shared generator there are
> two modular exponentiations/point multiplications to derive the shared secret and
> two keyed hash calls for key confirmation.
>
>
>     Which recommendations for secure usage can be given?
>         Is it defined how the explicit key confirmation is performed/must be performed
>     externally? Are there clear statements whether this procedure is optional or
>     mandatory?
>
> Key confirmation is mandatory.
>
>         Can any recommendations on using iterated hashing (e.g., with Scrypt) with the
>     PAKE be given?
>
> No.
>
>         Can any recommendations to avoid a user enumeration attack be given?
>
> Throttle back on negotiations when unsuccessful authentication attempts exceed some threshold
> and simulate the protocol with random data when an "invalid" username is presented.
>
>
>
> On 7/4/19 11:38 PM, Stanislav V. Smyshlyaev wrote:
>
> Dear CFRG,
>
> The first phase of the PAKE selection process is over.
>
> We've obtained the following nominations (by e-mails directly to the chairs or to the CFRG mailing list).
>
> SPAKE2 (nominated by Watson Ladd and Benjamin Kaduk), balanced;
> OPAQUE (nominated by Hugo Krawczyk), augmented;
> J-PAKE (nominated by Feng Hao), balanced;
> SPEKE (nominated by Dan Harkins), balanced;
> AuCPace (nominated by Björn Haase), augmented;
> CPace (nominated by Björn Haase), balanced;
> VTBPEKE (nominated by Guilin Wang), augmented;
> "SPAKE2+EE with blind salt"/BSPAKE (nominated by Steve (steve@tobtu.com), augmented.
>
> Please send an e-mail to cfrg-chairs@ietf.org if your nomination was lost or, on the contrary, if your personal opinion about good properties of some PAKE was misinterpreted as a nomination.
> Also, please let the chairs know if some of the proposed questions to be considered is not present in the list further in the current message (several groups of questions were merged, since essentially they were about the same things - but if some parts have been lost, please let the chairs know, so the list will be updated before the end of phase 2 of the selection process).
>
>
> Dear Watson, Benjamin, Hugo, Feng, Dan, Björn, Guilin and Steve,
>
> According to the plan of PAKE selection process, now we're on phase 2, which will last until the 19th of July.
> To give the reviewers (on the future steps of the process) as much information about each PAKE, as possible, the designers of the protocols (or the persons who nominated them) should prepare papers (as separate PDFs or just in a form of a message to the CFRG mailing list or to the CFRG chairs) with:
> a.      expanded answers for all positions of RFC 8125 regarding their PAKEs;
> b.      their own opinions on the following questions (they does not need to be complete: for example, a designer of a PAKE might not be an expert in TLS and might not be able to reply how his PAKE can be incorporated in TLS 1.3):
>
> How does it meet the "SHOULD" requirements of RFC 8125?
> Does it meet "crypto agility" requirements, not fixing any particular primitives and/or parameters?
> What setting is the PAKE suitable for, which applications does it have?
>
> "Peer communication" (where both ends share the same password) or "client-server" (where the server does not store the password but only a one-way function of the password)?
> A nomination should specify for which use-cases the protocol is recommended ("PAKE as a more-secure replacement for a PSK on a machine-2-machine interface" or "PAKE for securely accessing a remote HMI interface server (e.g. a web server) without configured WEB-PKI certificates").
> Can two communicating parties initiate the key exchange process at the same time, or must it always be the case that only one party can initiate the process?
> Is it suitable to be considered as a standalone scheme?
> Can it be integrated into IKEv2? TLS Handshake? Any other protocols?
>
> Is there a publicly available security proof? If yes,
>
> Are there known problems with the proof?
> Is the considered security model relevant for all applications that PAKE is intended for (e.g., if a PAKE is to be used in TLS Handshake, it is important that the TLS adversary model is considered for the PAKE)?
> Does it allow to be sure in sufficient level of security for common values of password lengths?
>
> Security assessment.
>
> Does its security depend on any nontrivial implementation properties? Are they clearly stated in the document?
> Does the PAKE have precomputation security (for augmented PAKEs)?
> If the PAKE relies on the assumption of a trusted setup - more specifically, the discrete logarithm relationship between the two group elements in the system setup MUST be unknown - in anticipation of the worst but not impossible scenario, the authors should clearly state the security implications when the discrete logarithm relationship becomes known, and the subsequent mitigation measures.
>
> Performance assessment.
>
> What's with the “round efficiency” of the PAKE? In a standard two/multi-party secure computation setting, the “round” is defined as a step in which all parties can complete operations at the same time without depending on each other. In practice, a 2-round protocol could be implemented as 2 flows or 3 flows depending on the application context, but that’s more the implementation detail.
> How many operations of each type (scalar multiplications, inversions in finite fields, hash calculations etc.) are made by each side?
>
> Which recommendations for secure usage can be given?
>
> Is it defined how the explicit key confirmation is performed/must be performed externally? Are there clear statements whether this procedure is optional or mandatory?
> Can any recommendations on using iterated hashing (e.g., with Scrypt) with the PAKE be given?
> Can any recommendations to avoid a user enumeration attack be given?
>
> Best regards,
> Stanislav Smyshlyaev
>
> _______________________________________________
> 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



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.