SPAKE2+, an Augmented PAKE
draft-bar-cfrg-spake2plus-00

Document Type Active Internet-Draft (individual)
Last updated 2020-03-09
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         T. Taubert
Internet-Draft                                                   C. Wood
Intended status: Informational                               Apple, Inc.
Expires: September 10, 2020                                March 9, 2020

                       SPAKE2+, an Augmented PAKE
                      draft-bar-cfrg-spake2plus-00

Abstract

   This document describes SPAKE2+, a Password Authenticated Key
   Exchange (PAKE) protocol run between two parties for deriving a
   strong shared key with no risk of disclosing the password.  SPAKE2+
   is an augmented PAKE protocol, as only one party has knowledge of the
   password.  This method is simple to implement, compatible with any
   prime order group and is computationally efficient.

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 September 10, 2020.

Copyright Notice

   Copyright (c) 2020 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

Taubert & Wood         Expires September 10, 2020               [Page 1]
Internet-Draft         SPAKE2+, an Augmented PAKE             March 2020

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   3
   3.  Definition of SPAKE2+ . . . . . . . . . . . . . . . . . . . .   3
   4.  Key Schedule and Key Confirmation . . . . . . . . . . . . . .   6
   5.  Ciphersuites  . . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   Appendix A.  Algorithm used for Point Generation  . . . . . . . .  11
   Appendix B.  Test Vectors . . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   This document describes SPAKE2+, a Password Authenticated Key
   Exchange (PAKE) protocol run between two parties for deriving a
   strong shared key with no risk of disclosing the password.  SPAKE2+
   is an augmented PAKE protocol, as only one party makes direct use of
   the password during the execution of the protocol.  The other party
   only needs a verification value at the time of the protocol execution
   instead of the password.  The verification value can be computed
   once, during an offline initialization phase.  The party using the
   password directly would typically be a client, and acts as a prover,
   while the other party would be a server, and acts as verifier.

   The protocol is augmented in the sense that it provides some
   resilience to the compromise or extraction of the verification value.
   The design of the protocol forces the adversary to recover the
   password from the verification value to successful execute the
   protocol.  Hence this protocol can be advantageously combined with a
   salted Password Hashing Function to increase the cost of the recovery
   and slow down attacks.  The verification value cannot be used
   directly to successfully run the protocol as a prover, making this
   protocol more robust than balanced PAKEs which don't benefit from
   Password Hashing Functions to the same extend.

   This augmented property is especially valuable in scenarios where the
   execution of the protocol is constrained and the adversary can not
   query the salt of the password hash function ahead of the attack.
   Constraints may consist in being in physical proximity through a
   local network or when initiation of the protocol requires a first
Show full document text