[Search] [txt|xml|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
Crypto Forum Research Group                                   Y. Sheffer
Internet-Draft                                                    Intuit
Intended status: Informational                          October 31, 2019
Expires: May 3, 2020


                   Review of the CFRG PAKE Proposals
                   draft-sheffer-cfrg-pake-review-00

Abstract

   This draft consists of the author's review of the password-
   authenticated key exchange (PAKE) protocols, as submitted to the
   IRTF's CFRG.  All opinions here are the author's alone.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 3, 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





Sheffer                    Expires May 3, 2020                  [Page 1]


Internet-Draft             Sheffer PAKE Review              October 2019


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Disclaimer  . . . . . . . . . . . . . . . . . . . . . . .   2
     1.2.  Conventions used in this document . . . . . . . . . . . .   3
   2.  Preliminaries . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Protocol Completeness and Clarity . . . . . . . . . . . .   3
     2.2.  Integration into Existing Protocols . . . . . . . . . . .   4
   3.  Detailed Review . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Balanced Algorithms . . . . . . . . . . . . . . . . . . .   4
       3.1.1.  SPAKE2  . . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.2.  J-PAKE  . . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.3.  SPEKE . . . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.4.  CPace . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Augmented Algorithms  . . . . . . . . . . . . . . . . . .   5
       3.2.1.  OPAQUE  . . . . . . . . . . . . . . . . . . . . . . .   5
       3.2.2.  AuCPace . . . . . . . . . . . . . . . . . . . . . . .   5
       3.2.3.  VTBPEKE . . . . . . . . . . . . . . . . . . . . . . .   5
       3.2.4.  BSPAKE  . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Informative References  . . . . . . . . . . . . . . . . . . .   6
   Appendix A.  Document History . . . . . . . . . . . . . . . . . .   8
     A.1.  draft-sheffer-cfrg-pake-review-00 . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   The CFRG took upon itself to review multiple proposed PAKE algorithms
   and select zero or more of them as suitable for general use in IETF
   protocols.  Eight protocols were submitted for consideration, and
   they are listed on the CFRG GitHub repository:
   https://github.com/cfrg/pake-selection.

   Over the last few months multiple reviews were submitted to the CFRG,
   evaluating the protocols' cryptographic quality as well as their
   engineering properties.  As the last stage of this process, members
   of the CFRG Crypto Review Panel were asked to provide summary
   reviews, and this document is the author's contribution as a Panel
   member.

1.1.  Disclaimer

   The author is not a cryptographer.  Specifically, I do not have the
   skills to prove security of such protocols, nor even to evaluate the
   quality of such proofs.  I do, however, possess a reasonable amount
   of experience in integrating cryptography into protocols, including
   PAKE-based algorithms [RFC6124] [RFC6631].




Sheffer                    Expires May 3, 2020                  [Page 2]


Internet-Draft             Sheffer PAKE Review              October 2019


1.2.  Conventions used in this document

   This is essentially an opinion piece and does not employ any
   normative language.

2.  Preliminaries

   Before diving into the individual protocols, I would like to get two
   important points out of the way.

2.1.  Protocol Completeness and Clarity

   CFRG has published in the past some protocols in enough detail that
   they can be implemented by a non-expert developer.  A good example is
   [RFC7748].  Of the eight PAKE submissions, in my opinion only one
   comes close to this level of rigor.  Whatever protocols are selected,
   CFRG must make it clear that such selection is conditional on the
   algorithms being republished in a detailed format.  CFRG must not
   leave this task to the IETF working groups, because that would both
   duplicate work and introduce a major risk of inadvertent errors that
   invariably manifest themselves as vulnerabilities.

   Ironically, I can quote the abstract of one of the submissions to
   support this position: "We observe that the original SPEKE
   specification is subtly different from those defined in the ISO/IEC
   11770-4 and IEEE 1363.2 standards.  We show that those differences
   have critical security implications by presenting two new attacks on
   SPEKE: an impersonation attack and a key-malleability attack."  In
   other words, an under-specified protocol resulted in two different
   standards, both of them vulnerable.  This is ironic because the paper
   from which this is quoted is not itself a rigorous description of the
   protocol that it attempts to fix.

   I would propose that each of the selected protocols be published as
   an RFC, containing:

   o  A detailed description of the protocol, to a level that can be
      implemented by developers who are not security experts.
   o  Test vectors to ensure interoperability.
   o  Recommendations on integrating with higher-level protocols:
      supported identity fields and recommendations on how they should
      be protected, session ID and "exporter" integration, secure
      capability and parameter negotiation, conditions on whether and
      how "optional" protocol exchanges can be eliminated.
   o  Mandated auxiliary primitives, such as hash-to-curve and memory-
      hard iterated hashing.





Sheffer                    Expires May 3, 2020                  [Page 3]


Internet-Draft             Sheffer PAKE Review              October 2019


2.2.  Integration into Existing Protocols

   The IPsec/IKE community has always been interested in PAKE as a
   component, both for remote access and for peer-to-peer VPN
   deployments.  This to me justifies the selection of both a balanced
   and an augmented PAKE, assuming good candidates exist.  It also means
   that the integration of such protocols into IKEv2 is relatively
   straightforward.

   On the other hand, the TLS community has been less receptive to PAKE
   solutions, and as a result, the properties required from the protocol
   for proper integration are not as clear.  It is possible that the
   most common deployment will be a combination of TLS, PAKE and OAuth.
   Arguably we should take the combination into account when defining
   the PAKE portion of the protocol, and resist the temptation to only
   consider the narrow integration of a PAKE protocol into TLS 1.3.

3.  Detailed Review

   As mentioned above, I believe we should select one balanced and one
   augmented PAKE protocol.

3.1.  Balanced Algorithms

3.1.1.  SPAKE2

   This protocol is the best documented of all the candidates.  On the
   down side, it relies on a set of parameters that present a high value
   target for factorization once a quantum computer is available to an
   adversary, and that would break all instances of this protocol.

3.1.2.  J-PAKE

   This algorithm is an outlier in its complexity, which also implies a
   significant performance penalty.  For this reason I don't think it
   would be a realistic selection.

3.1.3.  SPEKE

   SPEKE has been around for a long time, which is an advantage.  But
   the quoted paper describes several attacks on concrete
   specifications/implementations, and Karthik's review casts doubts
   about the validity of the security proof presented for this protocol.
   As far as I can tell, the mailing list discussion has not fully
   clarified which exact version of the protocol is proposed and which
   published security proof applies to it.  Specifically, does [Hao2018]
   apply?




Sheffer                    Expires May 3, 2020                  [Page 4]


Internet-Draft             Sheffer PAKE Review              October 2019


3.1.4.  CPace

   CPace is not specified as a stand-alone protocol, but rather needs to
   be extracted out of the AuCPace specification.  Moreover, it adds a
   mandatory (though trivial) message round to establish a session ID.
   This extra round may or may not be subsumed by the higher-level
   protocol.  Having said that, it comes with an actual security proof
   and no magic parameters.

3.2.  Augmented Algorithms

3.2.1.  OPAQUE

   OPAQUE is described as a generic framework, with two instantiations,
   and will have to be narrowed down when standardized.  The protocol is
   secure against pre-computation attacks.  This is a good thing of
   course, however I am not sure how serious this attack is in practice:
   while servers are often breached with attackers gaining bulk access
   to hashed passwords, I don't think it is common for attackers to
   record multiple salt exchanges and use them in a follow-on attack.
   OPAQUE comes with a security proof.  OPAQUE is well documented, with
   a separate draft [I-D.sullivan-tls-opaque] on its integration into
   TLS.

3.2.2.  AuCPace

   The protocol has two versions, the main paper and Appendix C ("Strong
   AuCPace"), which is resistant to pre-computation attacks.  It is
   unclear which one is nominated.

3.2.3.  VTBPEKE

   This 2017 paper extends SPEKE into a balanced PEKE that can be proven
   even for elliptic curves, and then again into a verifier-based (i.e.,
   augmented) PAKE named VTBPEKE.  It has a few "magic" constants which
   are potentially of concern - I didn't see any mention of how they
   should be generated.

3.2.4.  BSPAKE

   This protocol is somewhat loosely specified, with no security proof
   (or even security justification/intuition) provided.  So it is hard
   to be convinced of its fit for purpose.








Sheffer                    Expires May 3, 2020                  [Page 5]


Internet-Draft             Sheffer PAKE Review              October 2019


4.  Conclusions

   As noted, I think the Research Group should recommend one balanced
   and one augmented algorithm.

   Before presenting my conclusions, I would like to clarify my view
   about quantum resistance in this context.  Steve Thomas defines
   "quantum annoying" as: an attacker with a quantum computer needs to
   solve a DLP per password guess.  IMO this is too high of a bar, and
   once we get to the point where this is a real risk we will need to
   migrate to PQC for these protocols.  However I think that even now, a
   protocol where a single DLP solve would break _all_ instances of the
   protocol, is too risky to adopt.

   Of the balanced algorithms, I would recommend CPace.  I think the
   extra round trip is a reasonable price to pay for a formally proven
   protocol.  To me the potential quantum vulnerability of the SPAKE2
   parameters is a showstopper.

   Of the augmented algorithms, I will follow the Mozilla report and
   recommend OPAQUE, which appears to be the best fit into TLS, and is
   also a good fit into IKEv2.

5.  Informative References

   [Hao2018]  Hao, F., Metere, R., Shahandashti, S., and C. Dong,
              "Analyzing and Patching SPEKE in ISO/IEC", IEEE
              Transactions on Information Forensics and Security Vol.
              13, pp. 2844-2855, DOI 10.1109/tifs.2018.2832984, November
              2018.

   [I-D.sullivan-tls-opaque]
              Sullivan, N., Krawczyk, H., Friel, O., and R. Barnes,
              "Usage of OPAQUE with TLS 1.3", draft-sullivan-tls-
              opaque-00 (work in progress), March 2019.

   [RFC6124]  Sheffer, Y., Zorn, G., Tschofenig, H., and S. Fluhrer, "An
              EAP Authentication Method Based on the Encrypted Key
              Exchange (EKE) Protocol", RFC 6124, DOI 10.17487/RFC6124,
              February 2011, <https://www.rfc-editor.org/info/rfc6124>.

   [RFC6631]  Kuegler, D. and Y. Sheffer, "Password Authenticated
              Connection Establishment with the Internet Key Exchange
              Protocol version 2 (IKEv2)", RFC 6631,
              DOI 10.17487/RFC6631, June 2012,
              <https://www.rfc-editor.org/info/rfc6631>.





Sheffer                    Expires May 3, 2020                  [Page 6]


Internet-Draft             Sheffer PAKE Review              October 2019


   [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
              for Security", RFC 7748, DOI 10.17487/RFC7748, January
              2016, <https://www.rfc-editor.org/info/rfc7748>.
















































Sheffer                    Expires May 3, 2020                  [Page 7]


Internet-Draft             Sheffer PAKE Review              October 2019


Appendix A.  Document History

A.1.  draft-sheffer-cfrg-pake-review-00

   o  Initial version.

Author's Address

   Yaron Sheffer
   Intuit

   EMail: yaronf.ietf@gmail.com







































Sheffer                    Expires May 3, 2020                  [Page 8]