]> 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. 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 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 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 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. 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 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 a generate P of (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 . 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 higher-level 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 cross-protocol 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, p-1], which is modeled as a random oracle in . The registration phase also produces two random elements M and N in the prime-order 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. Pre-computed 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 Password-Based Key Derivation Function (PBKDF), which is a 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 Argon2id are common examples of PBKDFs. Absent an application-specific 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 P-256 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, p-1], 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 prime-order subgroup of G; see for details. The verifier then selects y uniformly at random from the integers in [0, p-1], 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 prime-order 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 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 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 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, both parties compute shared secrets K_auth, K_enc, 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() = SHA-256. 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() = SHA-256. For CMAC-AES, each confirmation key MUST be of length k, where k is the chosen AES key size, e.g., 128 bits for CMAC-AES-128. 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_enc as an authenticated shared secret as needed. For example, applications MAY derive one or more AEAD keys and nonces from K_enc 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., P256-SHA256-HKDF-HMAC-SHA256. 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. 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
P-256	SHA256	HKDF-SHA256	HMAC-SHA256
P-256	SHA512	HKDF-SHA512	HMAC-SHA512
P-384	SHA256	HKDF-SHA256	HMAC-SHA256
P-384	SHA512	HKDF-SHA512	HMAC-SHA512
P-521	SHA512	HKDF-SHA512	HMAC-SHA512
edwards25519	SHA256	HKDF-SHA256	HMAC-SHA256
edwards448	SHA512	HKDF-SHA512	HMAC-SHA512
P-256	SHA256	HKDF-SHA256	CMAC-AES-128
P-256	SHA512	HKDF-SHA512	CMAC-AES-128

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 prime-order 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 small-order 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 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. 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. 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. Federal Information Processing Standard, FIPS 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. 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. 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 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. 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. 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] Informative References 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. This document describes the Argon2 memory-hard function for password hashing and proof-of-work applications. We provide an implementer-oriented 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. 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 misled about the identity of a communicating peer. This document defines mitigation techniques 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 . This algorithm produces M and N such that they are indistinguishable from two random points in the prime-order 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 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 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.