rfc9383v6.txt		rfc9383.txt
	Independent Submission T. Taubert		Independent Submission T. Taubert
	Request for Comments: 9383 Apple Inc.		Request for Comments: 9383 Apple Inc.
	Category: Informational C. A. Wood		Category: Informational C. A. Wood
	ISSN: 2070-1721 May 2023		ISSN: 2070-1721 September 2023
	SPAKE2+, an Augmented Password-Authenticated Key Exchange (PAKE)		SPAKE2+, an Augmented Password-Authenticated Key Exchange (PAKE)
	Protocol		Protocol
	Abstract		Abstract
	This document describes SPAKE2+, a Password-Authenticated Key		This document describes SPAKE2+, a Password-Authenticated Key
	Exchange (PAKE) protocol run between two parties for deriving a		Exchange (PAKE) protocol run between two parties for deriving a
	strong shared key with no risk of disclosing the password. SPAKE2+		strong shared key with no risk of disclosing the password. SPAKE2+
	is an augmented PAKE protocol, as only one party has knowledge of the		is an augmented PAKE protocol, as only one party has knowledge of the
	skipping to change at line 89 ¶		skipping to change at line 89 ¶
	This document describes SPAKE2+, a Password-Authenticated Key		This document describes SPAKE2+, a Password-Authenticated Key
	Exchange (PAKE) protocol run between two parties for deriving a		Exchange (PAKE) protocol run between two parties for deriving a
	strong shared key with no risk of disclosing the password. SPAKE2+		strong shared key with no risk of disclosing the password. SPAKE2+
	is an augmented PAKE protocol, as only one party makes direct use of		is an augmented PAKE protocol, as only one party makes direct use of
	the password during the execution of the protocol. The other party		the password during the execution of the protocol. The other party
	only needs a record corresponding to the first party's registration		only needs a record corresponding to the first party's registration
	at the time of the protocol execution instead of the password. This		at the time of the protocol execution instead of the password. This
	record can be computed once, during an offline registration phase.		record can be computed once, during an offline registration phase.
	The party using the password directly would typically be a client and		The party using the password directly would typically be a client and
	would act as a prover, while the other party would be a server and		would act as a Prover, while the other party would be a server and
	would act as a verifier.		would act as a Verifier.
	The protocol is augmented in the sense that it provides some		The protocol is augmented in the sense that it provides some
	resilience against the compromise or extraction of the registration		resilience against the compromise or extraction of the registration
	record. The design of the protocol forces the adversary to recover		record. The design of the protocol forces the adversary to recover
	the password from the record to successfully execute the protocol.		the password from the record to successfully execute the protocol.
	Hence, this protocol can be advantageously combined with a salted		Hence, this protocol can be advantageously combined with a salted
	Password Hashing Function to increase the cost of the recovery and		Password Hashing Function to increase the cost of the recovery and
	slow down attacks. The record cannot be used directly to		slow down attacks. The record cannot be used directly to
	successfully run the protocol as a prover, making this protocol more		successfully run the protocol as a Prover, making this protocol more
	robust than balanced PAKEs, which don't benefit from Password Hashing		robust than balanced PAKEs, which don't benefit from Password Hashing
	Functions to the same extent.		Functions to the same extent.
	This augmented property is especially valuable in scenarios where the		This augmented property is especially valuable in scenarios where the
	execution of the protocol is constrained and the adversary cannot		execution of the protocol is constrained and the adversary cannot
	query the salt of the Password Hashing Function ahead of the attack.		query the salt of the Password Hashing Function ahead of the attack.
	For example, a constraint may be when physical proximity through a		For example, a constraint may be when physical proximity through a
	local network is required or when a first authentication factor is		local network is required or when a first authentication factor is
	required for initiation of the protocol.		required for initiation of the protocol.
	skipping to change at line 168 ¶		skipping to change at line 168 ¶
	KDF is a key derivation function that takes as input a salt, input		KDF is a key derivation function that takes as input a salt, input
	keying material (IKM), info string, and derived key length L to		keying material (IKM), info string, and derived key length L to
	derive a cryptographic key of length L. MAC is a Message		derive a cryptographic key of length L. MAC is a Message
	Authentication Code algorithm that takes a secret key and message as		Authentication Code algorithm that takes a secret key and message as
	input to produce an output. Let Hash be a hash function from		input to produce an output. Let Hash be a hash function from
	arbitrary strings to bit strings of a fixed length. Common choices		arbitrary strings to bit strings of a fixed length. Common choices
	for Hash are SHA256 or SHA512 [RFC6234]. Section 4 specifies		for Hash are SHA256 or SHA512 [RFC6234]. Section 4 specifies
	variants of KDF, MAC, and Hash suitable for use with the protocols		variants of KDF, MAC, and Hash suitable for use with the protocols
	contained herein.		contained herein.
	Let there be two parties, a prover and a verifier. Their identities,		Let there be two parties, a Prover and a Verifier. Their identities,
	denoted as idProver and idVerifier, may also have digital		denoted as idProver and idVerifier, may also have digital
	representations such as Media Access Control addresses or other names		representations such as Media Access Control addresses or other names
	(hostnames, usernames, etc.). The parties may share additional data		(hostnames, usernames, etc.). The parties may share additional data
	(the context) separate from their identities, which they may want to		(the context) separate from their identities, which they may want to
	include in the protocol transcript. One example of additional data		include in the protocol transcript. One example of additional data
	is a list of supported protocol versions if SPAKE2+ were used in a		is a list of supported protocol versions if SPAKE2+ were used in a
	higher-level protocol that negotiates the use of a particular PAKE.		higher-level protocol that negotiates the use of a particular PAKE.
	Another example is the inclusion of the application name. Including		Another example is the inclusion of the application name. Including
	these data points would ensure that both parties agree upon the same		these data points would ensure that both parties agree upon the same
	set of supported protocols and therefore prevents downgrade and		set of supported protocols and therefore prevents downgrade and
	skipping to change at line 191 ¶		skipping to change at line 191 ¶
	3.1. Protocol Overview		3.1. Protocol Overview
	SPAKE2+ is a two-round protocol that establishes a shared secret with		SPAKE2+ is a two-round protocol that establishes a shared secret with
	an additional round for key confirmation. Prior to invocation, both		an additional round for key confirmation. Prior to invocation, both
	parties are provisioned with information such as the input password		parties are provisioned with information such as the input password
	needed to run the protocol. The registration phase may include		needed to run the protocol. The registration phase may include
	communicating identities, protocol version, and other parameters		communicating identities, protocol version, and other parameters
	related to the registration record; see Section 3.2 for details.		related to the registration record; see Section 3.2 for details.
	During the first round, the prover sends a public share, shareP, to		During the first round, the Prover sends a public share, shareP, to
	the verifier, which in turn responds with its own public share,		the Verifier, which in turn responds with its own public share,
	shareV. Both parties then derive a shared secret used to produce		shareV. Both parties then derive a shared secret used to produce
	encryption and authentication keys. The latter are used during the		encryption and authentication keys. The latter are used during the
	second round for key confirmation. (Section 3.4 details the key		second round for key confirmation. (Section 3.4 details the key
	derivation and confirmation steps.) In particular, the verifier		derivation and confirmation steps.) In particular, the Verifier
	sends a key confirmation message, confirmV, to the prover, which in		sends a key confirmation message, confirmV, to the Prover, which in
	turn responds with its own key confirmation message, confirmP. (Note		turn responds with its own key confirmation message, confirmP. (Note
	that shareV and confirmV MAY be sent in the same message.) Both		that shareV and confirmV MAY be sent in the same message.) Both
	parties MUST NOT consider the protocol complete prior to receipt and		parties MUST NOT consider the protocol complete prior to receipt and
	validation of these key confirmation messages.		validation of these key confirmation messages.
	A sample trace is shown below.		A sample trace is shown below.
	Prover Verifier		Prover Verifier
	| (registration) |		| (registration) |
	skipping to change at line 227 ¶		skipping to change at line 227 ¶
	| confirmV |		| confirmV |
	|<--------------------------|		|<--------------------------|
	(compute confirmP) | confirmP |		(compute confirmP) | confirmP |
	|-------------------------->|		|-------------------------->|
	3.2. Offline Registration		3.2. Offline Registration
	The registration phase computes the values w0 and w1, as well as the		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		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		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		record L are then shared with the Verifier and stored as part of the
	registration record associated with the prover. The prover SHOULD		registration record associated with the Prover. The Prover SHOULD
	derive w0 and w1 from the password before the protocol begins. Both		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		w0 and w1 are derived using a function with range [0, p-1], which is
	modeled as a random oracle in [SPAKE2P-Analysis].		modeled as a random oracle in [SPAKE2P-Analysis].
	The registration phase also produces two random elements, M and N, 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		the prime-order subgroup of G. The algorithm for selecting M and N
	is defined in Appendix B. Importantly, this algorithm chooses M and		is defined in Appendix B. Importantly, this algorithm chooses M and
	N such that their discrete logs are not known. Precomputed values		N such that their discrete logs are not known. Precomputed values
	for M and N are listed in Section 4 for each group. Applications MAY		for M and N are listed in Section 4 for each group. Applications MAY
	use different M and N values, provided they are computed, e.g., using		use different M and N values, provided they are computed, e.g., using
	skipping to change at line 287 ¶		skipping to change at line 287 ¶
	If an identity is unknown at the time of computing w0s or w1s, its		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 an		length is given as zero and the identity itself is represented as an
	empty octet string. If both idProver and idVerifier are unknown,		empty octet string. If both idProver and idVerifier are unknown,
	then their lengths are given as zero and both identities will be		then their lengths are given as zero and both identities will be
	represented as empty octet strings. idProver and idVerifier are		represented as empty octet strings. idProver and idVerifier are
	included in the transcript TT as part of the protocol flow.		included in the transcript TT as part of the protocol flow.
	3.3. Online Authentication		3.3. Online Authentication
	The online SPAKE2+ protocol runs between the prover and verifier to		The online SPAKE2+ protocol runs between the Prover and Verifier to
	produce a single shared secret upon completion. To begin, the prover		produce a single shared secret upon completion. To begin, the Prover
	selects x uniformly at random from the integers in [0, p-1], computes		selects x uniformly at random from the integers in [0, p-1], computes
	the public share shareP=X, and transmits it to the verifier.		the public share shareP=X, and transmits it to the Verifier.
	x <- [0, p-1]		x <- [0, p-1]
	X = x*P + w0*M		X = x*P + w0*M
	Upon receipt of X, the verifier checks the received element for group		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		membership and aborts if X is not in the large prime-order subgroup
	of G; see Section 6 for details. The verifier then selects y		of G; see Section 6 for details. The Verifier then selects y
	uniformly at random from the integers in [0, p-1], computes the		uniformly at random from the integers in [0, p-1], computes the
	public share shareV=Y, and transmits it to the prover. Upon receipt		public share shareV=Y, and transmits it to the Prover. Upon receipt
	of Y, the prover checks the received element for group membership and		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.		aborts if Y is not in the large prime-order subgroup of G.
	y <- [0, p-1]		y <- [0, p-1]
	Y = y*P + w0*N		Y = y*P + w0*N
	Both participants compute Z and V; Z and V are then shared as common		Both participants compute Z and V; Z and V are then shared as common
	values. The prover computes:		values. The Prover computes:
	Z = h*x*(Y - w0*N)		Z = h*x*(Y - w0*N)
	V = h*w1*(Y - w0*N)		V = h*w1*(Y - w0*N)
	The verifier computes:		The Verifier computes:
	Z = h*y*(X - w0*M)		Z = h*y*(X - w0*M)
	V = h*y*L		V = h*y*L
	The multiplication by the cofactor h prevents small subgroup		The multiplication by the cofactor h prevents small subgroup
	confinement attacks. All proofs of security hold even if the		confinement attacks. All proofs of security hold even if the
	discrete log of the fixed group element N is known to the adversary.		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.		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		It is essential that both Z and V be used in combination with the
	skipping to change at line 356 ¶		skipping to change at line 356 ¶
	identity itself is represented as an empty octet string. If both		identity itself is represented as an empty octet string. If both
	identities are absent, then their lengths are given as zero and both		identities are absent, then their lengths are given as zero and both
	are represented as empty octet strings. In applications where		are represented as empty octet strings. In applications where
	identities are not implicit, idProver and idVerifier SHOULD always be		identities are not implicit, idProver and idVerifier SHOULD always be
	non-empty. Otherwise, the protocol risks unknown key-share attacks		non-empty. Otherwise, the protocol risks unknown key-share attacks
	(discussion of unknown key-share attacks in a specific protocol is		(discussion of unknown key-share attacks in a specific protocol is
	given in [RFC8844]).		given in [RFC8844]).
	Upon completion of this protocol, both parties compute shared secrets		Upon completion of this protocol, both parties compute shared secrets
	K_main, K_shared, K_confirmP, and K_confirmV as specified in		K_main, K_shared, K_confirmP, and K_confirmV as specified in
	Section 3.4. The verifier MUST send a key confirmation message,		Section 3.4. The Verifier MUST send a key confirmation message,
	confirmV, to the prover so both parties can confirm that they agree		confirmV, to the Prover so both parties can confirm that they agree
	upon these shared secrets. After receipt and verification of the		upon these shared secrets. After receipt and verification of the
	verifier's confirmation message, the prover MUST respond with its		Verifier's confirmation message, the Prover MUST respond with its
	confirmation message. The verifier MUST NOT send application data to		confirmation message. The Verifier MUST NOT send application data to
	the prover until it has received and verified the confirmation		the Prover until it has received and verified the confirmation
	message. Key confirmation verification requires recomputation of		message. Key confirmation verification requires recomputation of
	confirmP or confirmV and checking for equality against the data that		confirmP or confirmV and checking for equality against the data that
	was received.		was received.
	3.4. Key Schedule and Key Confirmation		3.4. Key Schedule and Key Confirmation
	The protocol transcript TT, as defined in Section 3.3, is unique and		The protocol transcript TT, as defined in Section 3.3, is unique and
	secret to the participants. Both parties use TT to derive the shared		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		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() =		equal to the length of the digest output, e.g., 256 bits for Hash() =
	skipping to change at line 525 ¶		skipping to change at line 525 ¶
	seed: edwards448 point generation seed (N)		seed: edwards448 point generation seed (N)
	5. IANA Considerations		5. IANA Considerations
	This document has no IANA actions.		This document has no IANA actions.
	6. Security Considerations		6. Security Considerations
	SPAKE2+ appears in [TDH] and is proven secure in [SPAKE2P-Analysis].		SPAKE2+ appears in [TDH] and is proven secure in [SPAKE2P-Analysis].
	The ephemeral randomness used by the prover and verifier MUST be		The ephemeral randomness used by the Prover and Verifier MUST be
	generated using a cryptographically secure Pseudorandom Number		generated using a cryptographically secure Pseudorandom Number
	Generator (PRNG).		Generator (PRNG).
	Elements received from a peer MUST be checked for group membership:		Elements received from a peer MUST be checked for group membership:
	failure to properly deserialize and validate group elements can lead		failure to properly deserialize and validate group elements can lead
	to attacks. An endpoint MUST abort the protocol if any received		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.		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		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		identity element I whenever V is an element of a small-order
	subgroup. Consequently, the prover and verifier MUST abort the		subgroup. Consequently, the Prover and Verifier MUST abort the
	protocol upon receiving any value V such that V*h = I. Failure to do		protocol upon receiving any value V such that V*h = I. Failure to do
	so may lead to subgroup confinement attacks.		so may lead to subgroup confinement attacks.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-		[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
	Hashing for Message Authentication", RFC 2104,		Hashing for Message Authentication", RFC 2104,
	DOI 10.17487/RFC2104, February 1997,		DOI 10.17487/RFC2104, February 1997,
	skipping to change at line 587 ¶		skipping to change at line 587 ¶
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation,		[RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation,
	Enforcement, and Comparison of Internationalized Strings		Enforcement, and Comparison of Internationalized Strings
	Representing Usernames and Passwords", RFC 8265,		Representing Usernames and Passwords", RFC 8265,
	DOI 10.17487/RFC8265, October 2017,		DOI 10.17487/RFC8265, October 2017,
	<https://www.rfc-editor.org/info/rfc8265>.		<https://www.rfc-editor.org/info/rfc8265>.
	[RFC9382] Ladd, W. and B. Kaduk, Ed., "SPAKE2, a PAKE", RFC 9382,		[RFC9382] Ladd, W., "SPAKE2, a Password-Authenticated Key Exchange",
	DOI 10.17487/RFC9382, May 2023,		RFC 9382, DOI 10.17487/RFC9382, September 2023,
	<https://www.rfc-editor.org/info/rfc9382>.		<https://www.rfc-editor.org/info/rfc9382>.
	[SEC1] Standards for Efficient Cryptography Group, "SEC 1:		[SEC1] Standards for Efficient Cryptography Group, "SEC 1:
	Elliptic Curve Cryptography", version 2.0, May 2009,		Elliptic Curve Cryptography", version 2.0, May 2009,
	<https://secg.org/sec1-v2.pdf>.		<https://secg.org/sec1-v2.pdf>.
	[SPAKE2P-Analysis]		[SPAKE2P-Analysis]
	Shoup, V., "Security analysis of SPAKE2+", March 2020,		Shoup, V., "Security analysis of SPAKE2+", March 2020,
	<https://eprint.iacr.org/2020/313.pdf>.		<https://eprint.iacr.org/2020/313.pdf>.
	skipping to change at line 626 ¶		skipping to change at line 626 ¶
	[RFC9106] Biryukov, A., Dinu, D., Khovratovich, D., and S.		[RFC9106] Biryukov, A., Dinu, D., Khovratovich, D., and S.
	Josefsson, "Argon2 Memory-Hard Function for Password		Josefsson, "Argon2 Memory-Hard Function for Password
	Hashing and Proof-of-Work Applications", RFC 9106,		Hashing and Proof-of-Work Applications", RFC 9106,
	DOI 10.17487/RFC9106, September 2021,		DOI 10.17487/RFC9106, September 2021,
	<https://www.rfc-editor.org/info/rfc9106>.		<https://www.rfc-editor.org/info/rfc9106>.
	Appendix A. Protocol Flow		Appendix A. Protocol Flow
	This section describes the flow of the SPAKE2+ protocol, including		This section describes the flow of the SPAKE2+ protocol, including
	computations and mandatory checks performed by the prover and		computations and mandatory checks performed by the Prover and
	verifier. The constants M, N, P, p, and h are defined by the chosen		Verifier. The constants M, N, P, p, and h are defined by the chosen
	ciphersuite.		ciphersuite.
	A.1. Prover		A.1. Prover
	The Prover implements two functions, ProverInit and ProverFinish,		The Prover implements two functions, ProverInit and ProverFinish,
	which are described below.		which are described below.
	def ProverInit(w0):		def ProverInit(w0):
	// Compute prover key share		// Compute Prover key share
	x <- [0, p-1]		x <- [0, p-1]
	X = x*P + w0*M		X = x*P + w0*M
	return (x, X)		return (x, X)
	def ProverFinish(w0, w1, x, Y):		def ProverFinish(w0, w1, x, Y):
	if not_in_subgroup(Y):		if not_in_subgroup(Y):
	raise "invalid input"		raise "invalid input"
	// Compute shared values		// Compute shared values
	Z = h*x*(Y - w0*N)		Z = h*x*(Y - w0*N)
	skipping to change at line 660 ¶		skipping to change at line 660 ¶
	A.2. Verifier		A.2. Verifier
	The Verifier implements a single function, VerifierFinish, which is		The Verifier implements a single function, VerifierFinish, which is
	described below.		described below.
	def VerifierFinish(w0, L, X):		def VerifierFinish(w0, L, X):
	if not_in_subgroup(X):		if not_in_subgroup(X):
	raise "invalid input"		raise "invalid input"
	// Compute verifier key share		// Compute Verifier key share
	y <- [0, p-1]		y <- [0, p-1]
	Y = y*P + w0*N		Y = y*P + w0*N
	// Compute shared values		// Compute shared values
	Z = h*y*(X - w0*M)		Z = h*y*(X - w0*M)
	V = h*y*L		V = h*y*L
	return (Z, V)		return (Z, V)
	A.3. Transcript Computation		A.3. Transcript Computation
	skipping to change at line 701 ¶		skipping to change at line 701 ¶
	the key schedule, ComputeKeySchedule, which is described below.		the key schedule, ComputeKeySchedule, which is described below.
	def ComputeKeySchedule(TT):		def ComputeKeySchedule(TT):
	K_main = Hash(TT)		K_main = Hash(TT)
	K_confirmP || K_confirmV = KDF(nil, K_main, "ConfirmationKeys")		K_confirmP || K_confirmV = KDF(nil, K_main, "ConfirmationKeys")
	K_shared = KDF(nil, K_main, "SharedKey")		K_shared = KDF(nil, K_main, "SharedKey")
	return K_confirmP, K_confirmV, K_shared		return K_confirmP, K_confirmV, K_shared
	A.5. Protocol Run		A.5. Protocol Run
	A full SPAKE2+ protocol run initiated by the prover will look as		A full SPAKE2+ protocol run initiated by the Prover will look as
	follows, where Transmit and Receive are shorthand for sending and		follows, where Transmit and Receive are shorthand for sending and
	receiving a message to the peer:		receiving a message to the peer:
	Prover(Context, idProver, idVerifier, w0, w1):		Prover(Context, idProver, idVerifier, w0, w1):
	(x, X) = ProverInit(w0)		(x, X) = ProverInit(w0)
	Transmit(X)		Transmit(X)
	Y = Receive()		Y = Receive()
	(Z, V) = ProverFinish(w0, w1, x, Y)		(Z, V) = ProverFinish(w0, w1, x, Y)
	TT = ComputeTranscript(Context, idProver, idVerifier, X, Y,		TT = ComputeTranscript(Context, idProver, idVerifier, X, Y,
	Z, V, w0)		Z, V, w0)
End of changes. 23 change blocks.
	34 lines changed or deleted		34 lines changed or added
This html diff was produced by rfcdiff 1.48.