]>
SPAKE2+, an Augmented PAKE
Apple Inc.
One Apple Park Way
Cupertino, California 95014
United States of America
ttaubert@apple.com
caw@heapingbits.net
InternetDraft
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.
This document was produced outside of the IETF and IRTF, and represents the opinions of the authors.
Publication of this document as an RFC in the Independent Submissions Stream does not imply endorsement
of SPAKE2+ by the IETF or IRTF.
Discussion Venues
Source for this draft and an issue tracker can be found at
.
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 record corresponding to the other party's registration at the time of the protocol execution instead of the password.
This record can be computed once, during an offline registration 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 registration record.
The design of the protocol forces the adversary to recover the password from the record to successfully 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 record 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 extent.
This augmented property is especially valuable in scenarios where the execution of the protocol is constrained
and the adversary cannot 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 authentication factor.
This document has content split out from a related document specifying SPAKE2 ,
which is a symmetric PAKE protocol, where both parties have knowledge of the password.
SPAKE2+ is the asymmetric or augmented version of SPAKE2, wherein only one party has knowledge of the password.
SPAKE2+ is specified separately in this document because the use cases for symmetric and augmented PAKEs
are different, and therefore warrant different technical specifications. Neither SPAKE2 nor SPAKE2+
was selected as the result of the CFRG PAKE selection competition. However, this passwordbased key exchange
protocol appears in and is proven secure in . It is compatible with any
primeorder group and relies only on group operations, making it simple and computationally efficient.
Thus, it was felt that publication was beneficial to make the protocol available for wider consideration.
This document was produced outside of the IETF and IRTF, and represents the opinions of the authors.
Publication of this document as an RFC in the Independent Submissions Stream does not imply endorsement
of SPAKE2+ by the IETF or IRTF.
Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 when, and only when, they appear in all
capitals, as shown here.
Definition of SPAKE2+
Let G be a group in which the computational DiffieHellman (CDH)
problem is hard. Suppose G has order p*h where p is a large prime;
h will be called the cofactor. Let I be the unit element in
G, e.g., the point at infinity if G is an elliptic curve group. We denote the
operations in the group additively. We assume there is a representation of
elements of G as byte strings: common choices would be SEC1
uncompressed or compressed for elliptic curve groups or big
endian integers of a fixed (pergroup) length for prime field DH.
We fix a generate P of (large) primeorder subgroup of G. P is specified
in the document defining the group, and so we do not repeat it here.
 denotes concatenation of strings. We also let len(S) denote the
length of a string in bytes, represented as an eightbyte little
endian number. Finally, let nil represent an empty string, i.e.,
len(nil) = 0.
KDF is a keyderivation function that takes as input a salt, intermediate
keying material (IKM), info string, and derived key length L to derive a
cryptographic key of length L.
MAC is a Message Authentication Code algorithm that takes a secret key and
message as input to produce an output.
Let Hash be a hash function from arbitrary strings to bit strings of a fixed length. Common choices
for Hash are SHA256 or SHA512 .
specifies variants of KDF, MAC, and Hash
suitable for use with the protocols contained herein.
Let there be two parties, a prover and a verifier. Their identities, denoted as
idProver and idVerifier, may also have digital representations such as Media Access Control addresses
or other names (hostnames, usernames, etc). The parties may share additional data
(the context) separate from their identities which they may want to include in
the protocol transcript.
One example of additional data is a list of supported protocol versions if SPAKE2+ were
used in a higherlevel protocol which negotiates the use of a particular PAKE. Another
example is the inclusion of the application name. Including those would ensure that
both parties agree upon the same set of supported protocols and therefore prevent downgrade and
crossprotocol attacks. Specification of precise context values is out of scope for this document.
Protocol Overview
SPAKE2+ is a two round protocol that establishes a shared secret with an
additional round for key confirmation. Prior to invocation, both parties are
provisioned with information such as the input password needed to run the
protocol. The registration phase may include communicating identities, protocol
version and other parameters related to the registration record; see
for details.
During the first round, the prover sends a public share shareP to the verifier, which in turn
responds with its own public share shareV. Both parties then derive a shared secret
used to produce encryption and authentication keys. The latter are used during the second
round for key confirmation. ( details the key derivation and confirmation steps.)
In particular, the verifier sends a key confirmation message confirmV to the prover,
which in turn responds with its own key confirmation message confirmP.
(Note that shareV and confirmV MAY be sent in the same message.)
Both parties MUST NOT consider the protocol complete prior to receipt and
validation of these key confirmation messages.
A sample trace is shown below.

 
 (setup protocol) 
(compute shareP)  shareP 
>
 shareV  (compute shareV)
<
 
 (derive secrets)  (compute confirmV)
 confirmV 
<
(compute confirmP)  confirmP 
>
]]>
Offline Registration
The registration phase computes the values w0 and w1, as well as the registration
record L=w1*P. w0 and w1 are derived by hashing the password pw with the identities
of the two participants. w0 and the record L are then shared with the verifier and
stored as part of the registration record associated with the prover. The prover
SHOULD derive w0 and w1 from the password before the protocol begins. Both w0 and
w1 are derived using a function with range [0, p1], which is modeled as a random
oracle in .
The registration phase also produces two random elements M and N in the primeorder
subgroup of G. The algorithm for selecting M and N is defined in .
Importantly, this algorithm chooses M and N such that their discrete logs are not
known. Precomputed values for M and N are listed in for each
group. Applications MAY use different M and N values provided they are computed,
e.g., using different input seeds to the algorithm in , as random elements
for which the discrete log is unknown.
Applications using this specification MUST define the method used to compute w0 and w1.
For example, it may be necessary to carry out various forms of normalization of the
password before hashing . This section contains requirements and default
recommendations for computing w0 and w1.
The RECOMMENDED method for generating w0 and w1 is via a PasswordBased Key
Derivation Function (PBKDF), which is a function designed to slow down bruteforce
attackers. Bruteforce resistance may be obtained through various computation hardness
parameters such as memory or CPU cycles, and are typically configurable.
Scrypt and Argon2id are common examples of PBKDFs.
Absent an applicationspecific profile, RECOMMENDED parameters (N, r, p)
for Scrypt are (32768,8,1), and RECOMMENDED parameters for Argon2id
are in Section 4 of .
Each half of the output of the PBKDF will be interpreted as an integer and reduced
modulo p. To control bias, each half must be of length at least ceil(log2(p)) + k
bits, with k >= 64. Reducing such integers mod p gives bias at most 2^k for any
p; this bias is negligible for any k >= 64.
The minimum total output length of the PBKDF then is 2 * (ceil(log2(p)) + k) bits.
For example, given the prime order of the P256 curve, the output of the PBKDF
SHOULD be at least 640 bits or 80 bytes.
Given a PBKDF, password pw, and identities idProver and idVerifier, the RECOMMENDED
method for computing w0 and w1 is as follows:
If an identity is unknown at the time of computing w0s or w1s, its length is given
as zero and the identity itself is represented as the empty octet string. If both
idProver and idVerifier are unknown, then their lengths are given as zero and both
identities will be represented as empty octet strings. idProver and idVerifier are
included in the transcript TT as part of the protocol flow.
Online Authentication
The online SPAKE2+ protocol runs between the prover and verifier to produce a
single shared secret upon completion. To begin, the prover selects x uniformly
at random from the integers in [0, p1], computes the public share shareP=X,
and transmits it to the verifier.
Upon receipt of X, the verifier checks the received element for group membership
and aborts if X is not in the large primeorder subgroup of G; see
for details. The verifier then selects y uniformly at random from the integers
in [0, p1], computes the public share shareV=Y and transmits it to the prover.
Upon receipt of Y, the prover checks the received element for group membership
and aborts if Y is not in the large primeorder subgroup of G.
Both participants compute Z and V that are now shared as common values.
The prover computes:
The verifier computes:
The multiplication by the cofactor h prevents small subgroup confinement attacks.
All proofs of security hold even if the discrete log of the fixed group element
N is known to the adversary. In particular, one MAY set N=I, i.e. set N to the
unit element in G.
It is essential that both Z and V be used in combination with the transcript to
derive the keying material. The protocol transcript encoding is shown below.
Context is an applicationspecific customization string shared between both
parties and MUST precede the remaining transcript. It might contain the
name and version number of the higherlevel protocol, or simply the name and version
number of the application. The context MAY include additional data such as the
chosen ciphersuite and PBKDF parameters like the iteration count or salt.
The context and its length prefix MAY be omitted.
If an identity is absent, its length is given as zero and the identity itself
is represented as the empty octet string. If both identities are absent, then
their lengths are given as zero and both are represented as empty octet strings.
In applications where identities are not implicit, idProver and idVerifier SHOULD always be
nonempty. Otherwise, the protocol risks Unknown Key Share attacks (discussion
of Unknown Key Share attacks in a specific protocol is given in ).
Upon completion of this protocol, both parties compute shared secrets K_main,
K_shared, K_confirmP, and K_confirmV as specified in . The verifier MUST send a key
confirmation message confirmV to the prover so both parties can confirm that they
agree upon these shared secrets. After receipt and verification of the verifier's
confirmation message, the prover MUST respond with its confirmation message.
The verifier MUST NOT send application data to the prover until it has received
and verified the confirmation message. Key confirmation verification requires
recomputation of confirmP or confirmV and checking for equality against that which was
received.
Key Schedule and Key Confirmation
The protocol transcript TT, as defined in , is unique and secret to
the participants. Both parties use TT to derive the shared symmetric secret K_main from the
protocol. The length of K_main is equal to the length of the digest output, e.g., 256 bits
for Hash() = SHA256. The confirmation keys K_confirmP and K_confirmV, as well as the shared
key K_shared are derived from K_main.
Neither K_main nor its derived confirmation keys are used for anything except key
derivation and confirmation and MUST be discarded after the protocol execution.
Applications MAY derive additional keys from K_shared as needed.
The length of each confirmation key is dependent on the MAC function of the chosen
ciphersuite. For HMAC, the RECOMMENDED key length is equal to the output length of
the digest output, e.g., 256 bits for Hash() = SHA256. For CMACAES, each
confirmation key MUST be of length k, where k is the chosen AES key size,
e.g., 128 bits for CMACAES128.
Both endpoints MUST employ a MAC that produces pseudorandom tags for key confirmation.
K_confirmP and K_confirmV are symmetric keys used to compute tags confirmP and
confirmV over the public key shares received from the other peer earlier.
Once key confirmation is complete, applications MAY use K_shared as an authenticated
shared secret as needed. For example, applications MAY derive one or more AEAD
keys and nonces from K_shared for subsequent application data encryption.
Ciphersuites
This section documents SPAKE2+ ciphersuite configurations. A ciphersuite
indicates a group, cryptographic hash algorithm, and pair of KDF and MAC functions, e.g.,
P256SHA256HKDFHMACSHA256. This ciphersuite indicates a SPAKE2+ protocol instance over
P256 that uses SHA256 along with HKDF and HMAC
for G, Hash, KDF, and MAC functions, respectively. Since the choice of PBKDF
and its parameters for computing w0 and w1 and distributing does not affect
interoperability, the PBKDF is not included as part of the ciphersuite.
If no MAC algorithm is used in the key confirmation phase, its respective column
in Table 1 can be ignored and the ciphersuite name will contain no MAC
identifier.
G 
Hash 
KDF 
MAC 
P256 
SHA256 
HKDFSHA256 
HMACSHA256 
P256 
SHA512 
HKDFSHA512 
HMACSHA512 
P384 
SHA256 
HKDFSHA256 
HMACSHA256 
P384 
SHA512 
HKDFSHA512 
HMACSHA512 
P521 
SHA512 
HKDFSHA512 
HMACSHA512 
edwards25519 
SHA256 
HKDFSHA256 
HMACSHA256 
edwards448 
SHA512 
HKDFSHA512 
HMACSHA512 
P256 
SHA256 
HKDFSHA256 
CMACAES128 
P256 
SHA512 
HKDFSHA512 
CMACAES128 
The following points represent permissible point generation seeds for the groups listed
in Table 1, using the algorithm presented in . These bytestrings are
compressed points as in for curves from and . Note that
these values are identical to those used in the companion SPAKE2 specification .
For P256:
For P384:
For P521:
For edwards25519:
For edwards448:
IANA Considerations
No IANA action is required.
Security Considerations
SPAKE2+ appears in and is proven secure in .
The ephemeral randomness used by the prover and verifier MUST be
generated using a cryptographically secure PRNG.
Elements received from a peer MUST be checked for group membership: failure to
properly deserialize and validate group elements can lead to attacks. An endpoint
MUST abort the protocol if any received public value is not a member of the
large primeorder subgroup of G. Multiplication of a public value V by the
cofactor h will yield the identity element I whenever V is an element of a
smallorder subgroup. Consequently, prover and verifier MUST abort the protocol
upon of any received value V such that V*h = I. Failure to do so may lead to subgroup
confinement attacks.
Acknowledgements
Thanks to Ben Kaduk and Watson Ladd, from which this specification originally emanated.
References
Normative References
The TwinDiffie Hellman Problem and Applications
Security analysis of SPAKE2+
Elliptic Curve Cryptography, Standards for Efficient Cryptography Group, ver. 2
SPAKE2, a PAKE
Sealance
Akamai Technologies
This document describes SPAKE2 which is a protocol for two parties
that share a password to derive a strong shared key without
disclosing the password. This method is compatible with any group,
is computationally efficient, and SPAKE2 has a security proof. This
document predated the CFRG PAKE competition and it was not selected,
however, given existing use of variants in Kerberos and other
applications it was felt publication was beneficial. Applications
that need a symmetric PAKE (password authenticated key exchange) and
where hashing onto an elliptic curve at execution time is not
possible can use SPAKE2. This document is a product of the Crypto
Forum Research Group (CFRG) in the IRTF.
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
US Secure Hash Algorithms (SHA and SHAbased HMAC and HKDF)
Federal Information Processing Standard, FIPS
Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords
This document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on Stringprep (RFC 3454). The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. This document obsoletes RFC 7613.
HMACbased ExtractandExpand Key Derivation Function (HKDF)
This document specifies a simple Hashed Message Authentication Code (HMAC)based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.
HMAC: KeyedHashing for Message Authentication
This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind
The AESCMAC Algorithm
The National Institute of Standards and Technology (NIST) has recently specified the Cipherbased Message Authentication Code (CMAC), which is equivalent to the OneKey CBC MAC1 (OMAC1) submitted by Iwata and Kurosawa. This memo specifies an authentication algorithm based on CMAC with the 128bit Advanced Encryption Standard (AES). This new authentication algorithm is named AESCMAC. The purpose of this document is to make the AESCMAC algorithm conveniently available to the Internet Community. This memo provides information for the Internet community.
EdwardsCurve Digital Signature Algorithm (EdDSA)
This document describes elliptic curve signature scheme Edwardscurve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.
Elliptic Curve Cryptography Subject Public Key Information
This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDSTRACK]
Informative References
The scrypt PasswordBased Key Derivation Function
This document specifies the passwordbased key derivation function scrypt. The function derives one or more secret keys from a secret string. It is based on memoryhard functions, which offer added protection against attacks using custom hardware. The document also provides an ASN.1 schema.
Argon2 MemoryHard Function for Password Hashing and ProofofWork Applications
This document describes the Argon2 memoryhard function for password hashing and proofofwork applications. We provide an implementeroriented description with test vectors. The purpose is to simplify adoption of Argon2 for Internet protocols. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.
Unknown KeyShare Attacks on Uses of TLS with the Session Description Protocol (SDP)
This document describes unknown keyshare attacks on the use of Datagram Transport Layer Security for the Secure RealTime Transport Protocol (DTLSSRTP). Similar attacks are described on the use of DTLSSRTP with the identity bindings used in Web RealTime Communications (WebRTC) and SIP identity. These attacks are difficult to mount, but they cause a victim to be misled about the identity of a communicating peer. This document defines mitigation techniques that implementations of RFC 8122 are encouraged to deploy.
Protocol Flow
This section describes the flow of the SPAKE2+ protocol, including computations
and mandatory checks performed by the prover and verifier. The constants M, N,
P, p, and h are defined by the chosen ciphersuite.
Prover
The Prover's behavior consists of two functions, ProverInit and ProverFinish, which
are described below.
Verifier
The Verifier's behavior consists of a single function, VerifierFinish, which
is described below.
Transcript Computation
Both Prover and Verifier share the same function to compute the protocol
transcript, ComputeTranscript, which is described below.
Key Schedule Computation
Both Prover and Verifier share the same function to compute
the key schedule, ComputeKeySchedule, which is described below.
Protocol Run
A full SPAKE2+ protocol run initiated by the prover will look as follows,
where Transmit and Receive are shorthand for sending and receiving
a message to the peer:
Algorithm used for Point Generation
This section describes the algorithm that was used to generate
the points M and N in the table in . This algorithm
produces M and N such that they are indistinguishable from two random
points in the primeorder subgroup of G, where the discrete log
of these points is unknown. See for additional
details on this requirement.
For each curve in the table below, we construct a string
using the curve OID from (as an ASCII
string) or its name,
combined with the needed constant, for instance "1.3.132.0.35
point generation seed (M)" for P512. This string is turned
into a series of blocks by hashing with SHA256, and hashing that
output again to generate the next 32 bytes, and so on. This
pattern is repeated for each group and value, with the string
modified appropriately.
A byte string of length equal to that of an encoded group
element is constructed by concatenating as many blocks as are
required, starting from the first block, and truncating to the
desired length. The byte string is then formatted as required
for the group. In the case of Weierstrass curves, we take the
desired length as the length for representing a compressed point
(section 2.3.4 of ),
and use the loworder bit of the first byte as the sign bit.
In order to obtain the correct format, the value of the first
byte is set to 0x02 or 0x03 (clearing the first six bits
and setting the seventh bit), leaving the sign bit as it was
in the byte string constructed by concatenating hash blocks.
For the curves a different procedure is used.
For edwards448 the 57byte input has the leastsignificant 7 bits of the
last byte set to zero, and for edwards25519 the 32byte input is
not modified. For both the curves the
(modified) input is then interpreted
as the representation of the group element.
If this interpretation yields a valid group element with the
correct order (p), the (modified) byte string is the output. Otherwise,
the initial hash block is discarded and a new byte string constructed
from the remaining hash blocks. The procedure of constructing a
byte string of the appropriate length, formatting it as
required for the curve, and checking if it is a valid point of the correct
order, is repeated
until a valid element is found.
The following python snippet generates the above points,
assuming an elliptic curve implementation following the
interface of Edwards25519Point.stdbase() and
Edwards448Point.stdbase() in Appendix A of :
Test Vectors
This section contains various test vectors for SPAKE2+.
(Choice of PBKDF is omitted and values for w0 and w1 are provided directly.)
All points are encoded using the uncompressed format, i.e., with a 0x04 octet
prefix, specified in . idProver and idVerifier identity strings
are provided in the protocol invocation.