SPAKE2+, an Augmented PAKE
Apple Inc.
One Apple Park Way
Cupertino, California 95014
United States of America
ttaubert@apple.com
caw@heapingbits.net
Internet-Draft
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.
Discussion Venues
Source for this draft and an issue tracker can be found at
https://github.com/chris-wood/draft-bar-cfrg-spake2plus.
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 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 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 extent.
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 authentication factor.
This password-based key exchange protocol appears in and is proven secure in .
It is compatible with any prime-order group and relies only on group operations, making it simple and computationally efficient.
Predetermined parameters for a selection of commonly used groups are also provided.
This document has content split out from a related document specifying SPAKE2 .
Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in .
Definition of SPAKE2+
Offline Initialization
Let G be a group in which the computational Diffie-Hellman (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 (per-group) length for prime field DH.
We fix two elements M and N in the prime-order subgroup of G as defined
in the table in this document for common groups, as well as a generator P
of the (large) prime-order 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 eight-byte little-
endian number. Finally, let nil represent an empty string, i.e.,
len(nil) = 0.
KDF is a key-derivation 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 .
Let PBKDF be a Password-Based Key Derivation Function designed to slow down brute-force attackers.
Brute-force resistance may be obtained through various computation hardness parameters such as memory or CPU cycles,
and are typically configurable.
Scrypt and Argon2 are common examples of PBKDF functions.
PBKDF and hardness parameter selection are out of scope of this document.
specifies variants of KDF, MAC, and Hash
suitable for use with the protocols contained herein.
Let A and B be two parties. A and B may also have digital
representations of the parties' identities such as Media Access Control addresses
or other names (hostnames, usernames, etc). A and B 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 higher-level protocol which negotiates the use of a particular PAKE. Another
example is the inclusion of PBKDF parameters and the application name.
Including those would ensure that both parties agree upon the same set of supported
protocols and use the same PBKDF parameters and therefore prevent downgrade and
cross-protocol attacks. Specification of precise context values is out of scope for this document.
Protocol Flow
SPAKE2+ is a two round protocol that establishes a shared secret with an
additional round for key confirmation. Prior to invocation, A and B are provisioned with
information such as the input password needed to run the protocol.
A preamble exchange may occur in order to communicate identities, protocol version and PBKDF parameters related to the verification value.
Details of the preamble phase are out of scope of this document.
During the first round, A, the prover, sends a public share pA
to B, the verifier, and B responds with its own public share pB. Both A and B 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, B sends a key confirmation message cB to A, and A responds
with its own key confirmation message cA. (Note that pB and cB 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 pA) | pA |
|-------------------------->|
| pB | (compute pB)
|<--------------------------|
| |
| (derive secrets) | (compute cB)
| cB |
|<--------------------------|
(compute cA) | cA |
|-------------------------->|
]]>
SPAKE2+
Let w0 and w1 be two integers derived by hashing the password pw with the
identities of the two participants, A and B. Specifically, compute
w0s || w1s = PBKDF(len(pw) || pw || len(A) || A || len(B) || B),
and then w0 = w0s mod p and w1 = w1s mod p.
If both identities A and B are absent, then w0s || w1s = PBKDF(pw), i.e.,
the length prefix is omitted as in .
If one or both identities A and B are unknown at the time of deriving w0 and w1,
w0s and w1s are computed as if the unknown identities were absent. They however
SHOULD be included in the transcript TT if the parties exchange those
prior to or as part of the protocol flow.
The party B stores the verification value pair L=w1*P and w0.
Note that standards such as NIST.SP.800-56Ar3 suggest taking mod p of a
hash value that is 64 bits longer than that needed to represent p to remove
statistical bias introduced by the modulation. Protocols using this specification must define
the method used to compute w0 and w1: it may be necessary to carry out various
forms of normalization of the password before hashing .
The hashing algorithm SHOULD be a PBKDF so as to slow down brute-force
attackers.
When executing SPAKE2+, A selects x uniformly at random from the
numbers in the range [0, p), and lets X=x*P+w0*M, then transmits pA=X to
B. Upon receipt of X, B computes h*X and aborts if the result is equal
to I. B then selects y uniformly at random from the numbers in [0, p),
then computes Y=y*P+w0*N, and transmits pB=Y to A. Upon receipt of Y,
A computes h*Y and aborts if the result is equal to I.
A computes Z as h*x*(Y-w0*N), and V as h*w1*(Y-w0*N). B computes Z as
h*y*(X-w0*M) and V as h*y*L. Both share Z and V as common values.
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 application-specific customization string shared between both
parties and MUST precede the remaining transcript. It might contain the
name and version number of the higher-level 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
the empty octet string. If both A and B are absent, then both lengths are zero
and both A and B will be empty octet strings. In applications where identities
are not implicit, A and B SHOULD always be non-empty. 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, A and B compute shared secrets Ka, Ke, KcA,
and KcB as specified in . B MUST send A a key confirmation message cB
so both parties agree upon these shared secrets. This confirmation message cB
is computed as a MAC over the received share (pA) using KcB. Specifically, B
computes cB = MAC(KcB, pA), where MAC is also a secure PRF. After receipt and
verification of B's confirmation message, A MUST send B a confirmation message
using a MAC computed equivalently except with the use of pB and KcA. B MUST NOT
send application data to A until it has received and verified the confirmation
message. Key confirmation verification requires recomputation of the MAC 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 A and B. Both parties use TT to
derive shared symmetric secrets Ke and Ka as Ke || Ka = Hash(TT). The length of each
key is equal to half of the digest output, e.g., |Ke| = |Ka| = 128 bits for SHA-256.
If the required key size is less than half the digest output, e.g. when using SHA-512
to derive two 128-bit keys, the digest output MAY be truncated.
Both endpoints use Ka to derive subsequent MAC keys for key confirmation messages.
Specifically, let KcA and KcB be the MAC keys used by A and B, respectively.
A and B compute them as KcA || KcB = KDF(nil, Ka, "ConfirmationKeys")
The length of each of KcA and KcB is equal to half of the KDF
output, e.g., |KcA| = |KcB| = 128 bits for HKDF-SHA256. If half of the KDF
output size exceeds the required key size for the chosen MAC, e.g. when using
HKDF-SHA512 as the KDF and CMAC-AES-128 as the MAC, the KDF output MAY be truncated.
The resulting key schedule for this protocol, given transcript TT, is as follows.
Hash(TT) = Ka || Ke
Ka -> KDF(nil, Ka, "ConfirmationKeys") = KcA || KcB
]]>
A and B output Ke as the shared secret from the protocol. Ka and its derived keys (KcA and KcB)
are not used for anything except key confirmation.
Ciphersuites
This section documents SPAKE2+ ciphersuite configurations. A ciphersuite
indicates a group, cryptographic hash algorithm, and pair of KDF and MAC functions, e.g.,
SPAKE2+-P256-SHA256-HKDF-HMAC. This ciphersuite indicates a SPAKE2+ protocol instance over
P-256 that uses SHA256 along with HKDF and HMAC
for G, Hash, KDF, and MAC functions, respectively.
G |
Hash |
KDF |
MAC |
P-256 |
SHA256 |
HKDF |
HMAC |
P-256 |
SHA512 |
HKDF |
HMAC |
P-384 |
SHA256 |
HKDF |
HMAC |
P-384 |
SHA512 |
HKDF |
HMAC |
P-521 |
SHA512 |
HKDF |
HMAC |
edwards25519 |
SHA256 |
HKDF |
HMAC |
edwards448 |
SHA512 |
HKDF |
HMAC |
P-256 |
SHA256 |
HKDF |
CMAC-AES-128 |
P-256 |
SHA512 |
HKDF |
CMAC-AES-128 |
The following points represent permissible point generation seeds
for the groups listed in the Table above,
using the algorithm presented in .
These bytestrings are compressed points as in
for curves from .
For P256:
~~~
M =
02886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12f
seed: 1.2.840.10045.3.1.7 point generation seed (M)
N =
03d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f98baa1292b49
seed: 1.2.840.10045.3.1.7 point generation seed (N)
~~~
For P384:
~~~
M =
030ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba366434b363d3dc
36f15314739074d2eb8613fceec2853
seed: 1.3.132.0.34 point generation seed (M)
N =
02c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca21518f9c543bb
252c5490214cf9aa3f0baab4b665c10
seed: 1.3.132.0.34 point generation seed (N)
~~~
For P521:
~~~
M =
02003f06f38131b2ba2600791e82488e8d20ab889af753a41806c5db18d37d85608
cfae06b82e4a72cd744c719193562a653ea1f119eef9356907edc9b56979962d7aa
seed: 1.3.132.0.35 point generation seed (M)
N =
0200c7924b9ec017f3094562894336a53c50167ba8c5963876880542bc669e494b25
32d76c5b53dfb349fdf69154b9e0048c58a42e8ed04cef052a3bc349d95575cd25
seed: 1.3.132.0.35 point generation seed (N)
~~~
For edwards25519:
~~~
M =
d048032c6ea0b6d697ddc2e86bda85a33adac920f1bf18e1b0c6d166a5cecdaf
seed: edwards25519 point generation seed (M)
N =
d3bfb518f44f3430f29d0c92af503865a1ed3281dc69b35dd868ba85f886c4ab
seed: edwards25519 point generation seed (N)
~~~
For edwards448:
~~~
M =
b6221038a775ecd007a4e4dde39fd76ae91d3cf0cc92be8f0c2fa6d6b66f9a12
942f5a92646109152292464f3e63d354701c7848d9fc3b8880
seed: edwards448 point generation seed (M)
N =
6034c65b66e4cd7a49b0edec3e3c9ccc4588afd8cf324e29f0a84a072531c4db
f97ff9af195ed714a689251f08f8e06e2d1f24a0ffc0146600
seed: edwards448 point generation seed (N)
~~~
IANA Considerations
No IANA action is required.
Security Considerations
SPAKE2+ appears in and is proven secure in .
Beyond the cofactor multiplication checks to ensure that elements received from
a peer are in the prime order subgroup of G, they also MUST be checked for group
membership as failure to properly validate group elements can lead to attacks.
The choices of random numbers MUST BE uniform. Randomly generated values (e.g., x and y)
MUST NOT be reused; such reuse may permit dictionary attacks on the password.
Acknowledgements
Thanks to Ben Kaduk and Watson Ladd, from which this specification originally emanated.
References
Normative References
The Twin-Diffie Hellman Problem and Applications
Security analysis of SPAKE2+
Elliptic Curve Cryptography, Standards for Efficient Cryptography Group, ver. 2
SPAKE2, a PAKE
This document describes SPAKE2 which is a protocol for two parties that share a password to derive a strong shared key with no risk of 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.
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.
US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)
Federal Information Processing Standard, FIPS
The scrypt Password-Based Key Derivation Function
This document specifies the password-based key derivation function scrypt. The function derives one or more secret keys from a secret string. It is based on memory-hard functions, which offer added protection against attacks using custom hardware. The document also provides an ASN.1 schema.
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.
HMAC-based Extract-and-Expand 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: Keyed-Hashing 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, SHA-1, 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 AES-CMAC Algorithm
The National Institute of Standards and Technology (NIST) has recently specified the Cipher-based Message Authentication Code (CMAC), which is equivalent to the One-Key CBC MAC1 (OMAC1) submitted by Iwata and Kurosawa. This memo specifies an authentication algorithm based on CMAC with the 128-bit Advanced Encryption Standard (AES). This new authentication algorithm is named AES-CMAC. The purpose of this document is to make the AES-CMAC algorithm conveniently available to the Internet Community. This memo provides information for the Internet community.
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. [STANDARDS-TRACK]
Edwards-Curve Digital Signature Algorithm (EdDSA)
This document describes elliptic curve signature scheme Edwards-curve 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.
Informative References
Unknown Key Share Attacks on uses of TLS with the Session Description Protocol (SDP)
This document describes unknown key-share attacks on the use of Datagram Transport Layer Security for the Secure Real-Time Transport Protocol (DTLS-SRTP). Similar attacks are described on the use of DTLS-SRTP with the identity bindings used in Web Real-Time Communications (WebRTC) and SIP identity. These attacks are difficult to mount, but they cause a victim to be mislead about the identity of a communicating peer. Mitigation techniques are defined that implementations of RFC 8122 are encouraged to deploy.
Algorithm used for Point Generation
This section describes the algorithm that was used to generate
the points (M) and (N) in the table in .
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 P-512. 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 low-order 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 57-byte input has the least-significant 7 bits of the
last byte set to zero, and for edwards25519 the 32-byte 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 test vectors for SPAKE2+ using
the P256-SHA256-HKDF-HMAC and P256-SHA256-HKDF-CMAC ciphersuites. (Choice of PBKDF is omitted
and values for w and w0,w1 are provided directly.) All points are
encoded using the uncompressed format, i.e., with a 0x04 octet
prefix, specified in A and B identity strings
are provided in the protocol invocation.