rfc9807v2.txt		rfc9807.txt
	skipping to change at line 171 ¶		skipping to change at line 171 ¶
	passwords and offline dictionary attacks upon the compromise of a		passwords and offline dictionary attacks upon the compromise of a
	server and leakage of its credential file. In the latter case, the		server and leakage of its credential file. In the latter case, the
	attacker learns a mapping of a client's password under a one-way		attacker learns a mapping of a client's password under a one-way
	function and uses such a mapping to validate potential guesses for		function and uses such a mapping to validate potential guesses for
	the password. It is crucially important for the password protocol to		the password. It is crucially important for the password protocol to
	use an unpredictable one-way mapping. Otherwise, the attacker can		use an unpredictable one-way mapping. Otherwise, the attacker can
	pre-compute a deterministic list of mapped passwords leading to		pre-compute a deterministic list of mapped passwords leading to
	almost instantaneous leakage of passwords upon server compromise.		almost instantaneous leakage of passwords upon server compromise.
	This document describes OPAQUE, an aPAKE protocol that is secure		This document describes OPAQUE, an aPAKE protocol that is secure
	against pre-computation attacks (as defined in [JKX18Full]). OPAQUE		against pre-computation attacks (as defined in [JKX18]). OPAQUE
	provides forward secrecy with respect to password leakage while also		provides forward secrecy with respect to password leakage while also
	hiding the password from the server, even during password		hiding the password from the server, even during password
	registration. OPAQUE allows applications to increase the difficulty		registration. OPAQUE allows applications to increase the difficulty
	of offline dictionary attacks via iterated hashing or other key-		of offline dictionary attacks via iterated hashing or other key-
	stretching schemes. OPAQUE is also extensible, allowing clients to		stretching schemes. OPAQUE is also extensible, allowing clients to
	safely store and retrieve arbitrary application data on servers using		safely store and retrieve arbitrary application data on servers using
	only their password.		only their password.
	OPAQUE is defined and proven as the composition of three		OPAQUE is defined and proven as the composition of three
	functionalities: an Oblivious Pseudorandom Function (OPRF), a key		functionalities: an Oblivious Pseudorandom Function (OPRF), a key
	skipping to change at line 2007 ¶		skipping to change at line 2007 ¶
	only the correct password can unlock the private key while at the		only the correct password can unlock the private key while at the
	same time avoiding potential offline guessing attacks. This general		same time avoiding potential offline guessing attacks. This general
	composability property provides great flexibility and enables a		composability property provides great flexibility and enables a
	variety of OPAQUE instantiations, from optimized performance to		variety of OPAQUE instantiations, from optimized performance to
	integration with existing authenticated key exchange protocols such		integration with existing authenticated key exchange protocols such
	as TLS.		as TLS.
	10.1. Notable Design Differences		10.1. Notable Design Differences
	The specification as written here differs from the original		The specification as written here differs from the original
	cryptographic design in [JKX18Full] and the corresponding CFRG		cryptographic design in [JKX18] and the corresponding CFRG document
	document [Krawczyk20], both of which were used as input to the CFRG		[Krawczyk20], both of which were used as input to the CFRG PAKE
	PAKE competition. This section describes these differences,		competition. This section describes these differences, including
	including their motivation and explanation as to why they preserve		their motivation and explanation as to why they preserve the provable
	the provable security of OPAQUE based on [JKX18Full].		security of OPAQUE based on [JKX18].
	The following list enumerates important functional differences that		The following list enumerates important functional differences that
	were made as part of the protocol specification process to address		were made as part of the protocol specification process to address
	application or implementation considerations.		application or implementation considerations.
	* Clients construct envelope contents without revealing the password		* Clients construct envelope contents without revealing the password
	to the server, as described in Section 5, whereas the servers		to the server, as described in Section 5, whereas the servers
	construct envelopes in [JKX18Full]. This change adds to the		construct envelopes in [JKX18]. This change adds to the security
	security of the protocol. [JKX18Full] considered the case where		of the protocol. [JKX18] considered the case where the envelope
	the envelope was constructed by the server for reasons of		was constructed by the server for reasons of compatibility with
	compatibility with previous Universal Composability (UC) security		previous Universal Composability (UC) security modeling. [HJKW23]
	modeling. [HJKW23] analyzes the registration phase as specified		analyzes the registration phase as specified in this document.
	in this document. This change was made to support registration		This change was made to support registration flows where the
	flows where the client chooses the password and wishes to keep it		client chooses the password and wishes to keep it secret from the
	secret from the server, and it is compatible with the variant in		server, and it is compatible with the variant in [JKX18] that was
	[JKX18Full] that was originally analyzed.		originally analyzed.
	* Envelopes do not contain encrypted credentials. Instead,		* Envelopes do not contain encrypted credentials. Instead,
	envelopes contain information used to derive client private key		envelopes contain information used to derive client private key
	material for the AKE. This change improves the assumption behind		material for the AKE. This change improves the assumption behind
	the protocol by getting rid of equivocality and random key		the protocol by getting rid of equivocality and random key
	robustness for the encryption function. The random-key robustness		robustness for the encryption function. The random-key robustness
	property defined in Section 2.2 is only needed for the MAC		property defined in Section 2.2 is only needed for the MAC
	function. This change was made for two reasons. First, it		function. This change was made for two reasons. First, it
	reduces the number of bytes stored in envelopes, which is a		reduces the number of bytes stored in envelopes, which is a
	helpful improvement for large applications of OPAQUE with many		helpful improvement for large applications of OPAQUE with many
	skipping to change at line 2079 ¶		skipping to change at line 2079 ¶
	security analysis (it can be simulated with a random output).		security analysis (it can be simulated with a random output).
	This change was made to support more application use cases for		This change was made to support more application use cases for
	OPAQUE, such as the use of OPAQUE for end-to-end encrypted		OPAQUE, such as the use of OPAQUE for end-to-end encrypted
	backups; see [WhatsAppE2E].		backups; see [WhatsAppE2E].
	* The AKE protocol describes a 3-message protocol where the third		* The AKE protocol describes a 3-message protocol where the third
	message includes client authentication material that the server is		message includes client authentication material that the server is
	required to verify. This change (from the original 2-message		required to verify. This change (from the original 2-message
	protocol) was made to provide explicit client authentication and		protocol) was made to provide explicit client authentication and
	full forward security. The 3-message protocol is analyzed in		full forward security. The 3-message protocol is analyzed in
	[JKX18Full].		[JKX18].
	* The protocol admits optional application-layer client and server		* The protocol admits optional application-layer client and server
	identities. In the absence of these identities, the client and		identities. In the absence of these identities, the client and
	server are authenticated against their public keys. Binding		server are authenticated against their public keys. Binding
	authentication to identities is part of the AKE part of OPAQUE.		authentication to identities is part of the AKE part of OPAQUE.
	The type of identities and their semantics are application-		The type of identities and their semantics are application-
	dependent and independent of the protocol analysis. This change		dependent and independent of the protocol analysis. This change
	was made to simplify client and server interfaces to the protocol		was made to simplify client and server interfaces to the protocol
	by removing the need to specify additional identities alongside		by removing the need to specify additional identities alongside
	their corresponding public authentication keys when not needed.		their corresponding public authentication keys when not needed.
	skipping to change at line 2110 ¶		skipping to change at line 2110 ¶
	and indexing into the registration record storage called the		and indexing into the registration record storage called the
	credential_identifier. This allows clients to change their		credential_identifier. This allows clients to change their
	application-layer identity (client_identity) without inducing		application-layer identity (client_identity) without inducing
	server-side changes, e.g., by changing an email address associated		server-side changes, e.g., by changing an email address associated
	with a given account. This mechanism is part of the derivation of		with a given account. This mechanism is part of the derivation of
	OPRF keys via a single PRF. As long as the derivation of		OPRF keys via a single PRF. As long as the derivation of
	different OPRF keys from a single PRF has different PRF inputs,		different OPRF keys from a single PRF has different PRF inputs,
	the protocol is secure. The choice of such inputs is up to the		the protocol is secure. The choice of such inputs is up to the
	application.		application.
	* [JKX18Full] comments on a defense against offline dictionary		* [JKX18] comments on a defense against offline dictionary attacks
	attacks upon server compromise or honest-but-curious servers. The		upon server compromise or honest-but-curious servers. The authors
	authors suggest implementing the OPRF phase as a threshold OPRF		suggest implementing the OPRF phase as a threshold OPRF [TOPPSS],
	[TOPPSS], effectively forcing an attacker to act online or control		effectively forcing an attacker to act online or control at least
	at least t key shares (of the total n), where t is the threshold		t key shares (of the total n), where t is the threshold number of
	number of shares necessary to recombine the secret OPRF key. Only		shares necessary to recombine the secret OPRF key. Only then
	then would an attacker be able to run an offline dictionary		would an attacker be able to run an offline dictionary attack.
	attack. This implementation only affects the server and changes		This implementation only affects the server and changes nothing
	nothing for the client. Furthermore, if the threshold OPRF		for the client. Furthermore, if the threshold OPRF servers
	servers holding these keys are separate from the authentication		holding these keys are separate from the authentication server,
	server, then recovering all n shares would still not suffice to		then recovering all n shares would still not suffice to run an
	run an offline dictionary attack without access to the client		offline dictionary attack without access to the client record
	record database. However, this mechanism is out of scope for this		database. However, this mechanism is out of scope for this
	document.		document.
	The following list enumerates notable differences and refinements		The following list enumerates notable differences and refinements
	from the original cryptographic design in [JKX18Full] and the		from the original cryptographic design in [JKX18] and the
	corresponding CFRG document [Krawczyk20] that were made to make this		corresponding CFRG document [Krawczyk20] that were made to make this
	specification suitable for interoperable implementations.		specification suitable for interoperable implementations.
	* [JKX18Full] used a generic prime-order group for the DH-OPRF and		* [JKX18] used a generic prime-order group for the DH-OPRF and HMQV
	HMQV operations, and includes necessary prime-order subgroup		operations, and includes necessary prime-order subgroup checks
	checks when receiving attacker-controlled values over the wire.		when receiving attacker-controlled values over the wire. This
	This specification instantiates the prime-order group used for 3DH		specification instantiates the prime-order group used for 3DH
	using prime-order groups based on elliptic curves as described in		using prime-order groups based on elliptic curves as described in
	Section 2.1 of [RFC9497]. This specification also delegates OPRF		Section 2.1 of [RFC9497]. This specification also delegates OPRF
	group choice and operations to Section 4 of [RFC9497]. As such,		group choice and operations to Section 4 of [RFC9497]. As such,
	the prime-order group as used in the OPRF and 3DH as specified in		the prime-order group as used in the OPRF and 3DH as specified in
	this document both adhere to the requirements in [JKX18Full].		this document both adhere to the requirements in [JKX18].
	* [JKX18Full] specified DH-OPRF (see Appendix B) to instantiate the		* Appendix B of [JKX18] specified DH-OPRF to instantiate the OPRF
	OPRF functionality in the protocol. A critical part of DH-OPRF is		functionality in the protocol. A critical part of DH-OPRF is the
	the hash-to-group operation, which was not instantiated in the		hash-to-group operation, which was not instantiated in the
	original analysis. However, the requirements for this operation		original analysis. However, the requirements for this operation
	were included. This specification instantiates the OPRF		were included. This specification instantiates the OPRF
	functionality based on Section 3.3.1 of [RFC9497], which is		functionality based on Section 3.3.1 of [RFC9497], which is
	identical to the DH-OPRF functionality in [JKX18Full] and,		identical to the DH-OPRF functionality in [JKX18] and, concretely,
	concretely, uses the hash-to-curve functions in [RFC9380]. All		uses the hash-to-curve functions in [RFC9380]. All hash-to-curve
	hash-to-curve methods in [RFC9380] are compliant with the		methods in [RFC9380] are compliant with the requirement in
	requirement in [JKX18Full], namely, that the output be a member of		[JKX18], namely, that the output be a member of the prime-order
	the prime-order group.		group.
	* [JKX18Full] and [Krawczyk20] both used HMQV as the AKE for the		* [JKX18] and [Krawczyk20] both used HMQV as the AKE for the
	protocol. However, this document fully specifies 3DH instead of		protocol. However, this document fully specifies 3DH instead of
	HMQV (though a sketch for how to instantiate OPAQUE using HMQV is		HMQV (though a sketch for how to instantiate OPAQUE using HMQV is
	included in Appendix B.1). Since 3DH satisfies the essential		included in Appendix B.1). Since 3DH satisfies the essential
	requirements for the AKE protocol as described in [JKX18Full] and		requirements for the AKE protocol as described in [JKX18] and
	[Krawczyk20], as recalled in Section 10.2, this change preserves		[Krawczyk20], as recalled in Section 10.2, this change preserves
	the overall security of the protocol. 3DH was chosen for its		the overall security of the protocol. 3DH was chosen for its
	simplicity and ease of implementation.		simplicity and ease of implementation.
	* The DH-OPRF and HMQV instantiation of OPAQUE as shown in Figure 12		* The DH-OPRF and HMQV instantiation of OPAQUE as shown in Figure 12
	[JKX18Full] uses a different transcript than that which is		[JKX18] uses a different transcript than that which is described
	described in this specification. In particular, the key exchange		in this specification. In particular, the key exchange transcript
	transcript specified in Section 6.4 is a superset of the		specified in Section 6.4 is a superset of the transcript as
	transcript as defined in [JKX18Full]. This was done to align with		defined in [JKX18]. This was done to align with best practices,
	best practices, like what is done for key exchange protocols like		like what is done for key exchange protocols like TLS 1.3
	TLS 1.3 [RFC8446].		[RFC8446].
	* Neither [JKX18Full] nor [Krawczyk20] included wire format details		* Neither [JKX18] nor [Krawczyk20] included wire format details for
	for the protocol, which is essential for interoperability. This		the protocol, which is essential for interoperability. This
	specification fills this gap by including such wire format details		specification fills this gap by including such wire format details
	and corresponding test vectors; see Appendix C.		and corresponding test vectors; see Appendix C.
	10.2. Security Analysis		10.2. Security Analysis
	Jarecki et al. [JKX18Full] proved the security of OPAQUE (modulo the		Jarecki et al. [JKX18] proved the security of OPAQUE (modulo the
	design differences outlined in Section 10.1) in a strong aPAKE model		design differences outlined in Section 10.1) in a strong aPAKE model
	that ensures security against precomputation attacks and is		that ensures security against precomputation attacks and is
	formulated in the UC framework [Canetti01] under the random oracle		formulated in the UC framework [Canetti01] under the random oracle
	model. This assumes security of the OPRF function and the underlying		model. This assumes security of the OPRF function and the underlying
	key exchange protocol.		key exchange protocol.
	OPAQUE's design builds on a line of work initiated in the seminal		OPAQUE's design builds on a line of work initiated in the seminal
	paper of Ford and Kaliski [FK00] and is based on the HPAKE protocol		paper of Ford and Kaliski [FK00] and is based on the HPAKE protocol
	of Xavier Boyen [Boyen09] and the (1,1)-PPSS protocol from Jarecki et		of Xavier Boyen [Boyen09] and the (1,1)-PPSS protocol from Jarecki et
	al. [JKKX16]. None of these papers considered security against		al. [JKKX16]. None of these papers considered security against
	skipping to change at line 2206 ¶		skipping to change at line 2206 ¶
	authenticated protocols, e.g., HMQV, but not all of them. We also		authenticated protocols, e.g., HMQV, but not all of them. We also
	note that key exchange protocols based on shared keys do not satisfy		note that key exchange protocols based on shared keys do not satisfy
	the KCI requirement, hence they are not considered in the OPAQUE		the KCI requirement, hence they are not considered in the OPAQUE
	setting. We note that KCI is needed to ensure a crucial property of		setting. We note that KCI is needed to ensure a crucial property of
	OPAQUE. Even upon compromise of the server, the attacker cannot		OPAQUE. Even upon compromise of the server, the attacker cannot
	impersonate the client to the server without first running an		impersonate the client to the server without first running an
	exhaustive dictionary attack. Another essential requirement from AKE		exhaustive dictionary attack. Another essential requirement from AKE
	protocols for use in OPAQUE is to provide forward secrecy (against		protocols for use in OPAQUE is to provide forward secrecy (against
	active attackers).		active attackers).
	In [JKX18Full], security is proven for one instance (i.e., one key)		In [JKX18], security is proven for one instance (i.e., one key) of
	of the OPAQUE protocol, and without batching. There is currently no		the OPAQUE protocol, and without batching. There is currently no
	security analysis available for the OPAQUE protocol described in this		security analysis available for the OPAQUE protocol described in this
	document in a setting with multiple server keys or batching.		document in a setting with multiple server keys or batching.
	As stated in Section 9.1, incorporating client_identity adds domain		As stated in Section 9.1, incorporating client_identity adds domain
	separation, particularly against servers that choose the same OPRF		separation, particularly against servers that choose the same OPRF
	key for multiple clients. The client_identity as input to the OPRF		key for multiple clients. The client_identity as input to the OPRF
	also acts as a key identifier that would be required for a proof of		also acts as a key identifier that would be required for a proof of
	the protocol in the multi-key setting; the OPAQUE analysis in		the protocol in the multi-key setting; the OPAQUE analysis in [JKX18]
	[JKX18Full] assumes single server-key instances. Adding		assumes single server-key instances. Adding server_identity to the
	server_identity to the OPRF input provides domain separation for		OPRF input provides domain separation for clients that reuse the same
	clients that reuse the same client_identity across different server		client_identity across different server instantiations.
	instantiations.
	10.3. Identities		10.3. Identities
	AKE protocols generate keys that need to be uniquely and verifiably		AKE protocols generate keys that need to be uniquely and verifiably
	bound to a pair of identities. In the case of OPAQUE, those		bound to a pair of identities. In the case of OPAQUE, those
	identities correspond to client_identity and server_identity. Thus,		identities correspond to client_identity and server_identity. Thus,
	it is essential for the parties to agree on such identities,		it is essential for the parties to agree on such identities,
	including an agreed bit representation of these identities as needed.		including an agreed bit representation of these identities as needed.
	Note that the method of transmission of client_identity from client		Note that the method of transmission of client_identity from client
	skipping to change at line 2539 ¶		skipping to change at line 2538 ¶
	Hellman Protocol", Cryptology ePrint Archive, Paper		Hellman Protocol", Cryptology ePrint Archive, Paper
	2005/176, 2005, <https://eprint.iacr.org/2005/176>.		2005/176, 2005, <https://eprint.iacr.org/2005/176>.
	[JKKX16] Jarecki, S., Kiayias, A., Krawczyk, H., and J. Xu,		[JKKX16] Jarecki, S., Kiayias, A., Krawczyk, H., and J. Xu,
	"Highly-Efficient and Composable Password-Protected Secret		"Highly-Efficient and Composable Password-Protected Secret
	Sharing (Or: How to Protect Your Bitcoin Wallet Online)",		Sharing (Or: How to Protect Your Bitcoin Wallet Online)",
	2016 IEEE European Symposium on Security and Privacy		2016 IEEE European Symposium on Security and Privacy
	(EuroS&P), pp. 276-291, DOI 10.1109/EuroSP.2016.30, 2016,		(EuroS&P), pp. 276-291, DOI 10.1109/EuroSP.2016.30, 2016,
	<https://doi.org/10.1109/EuroSP.2016.30>.		<https://doi.org/10.1109/EuroSP.2016.30>.
	[JKX18Full]		[JKX18] Jarecki, S., Krawczyk, H., and J. Xu, "OPAQUE: An
	Jarecki, S., Krawczyk, H., and J. Xu, "OPAQUE: An
	Asymmetric PAKE Protocol Secure Against Pre-Computation		Asymmetric PAKE Protocol Secure Against Pre-Computation
	Attacks", Cryptology ePrint Archive, Paper 2018/163, 2018,		Attacks", Cryptology ePrint Archive, Paper 2018/163, 2018,
	<https://eprint.iacr.org/2018/163>.		<https://eprint.iacr.org/2018/163>.
	[keyagreement]		[keyagreement]
	Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R.		Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R.
	Davis, "Recommendation for Pair-Wise Key-Establishment		Davis, "Recommendation for Pair-Wise Key-Establishment
	Schemes Using Discrete Logarithm Cryptography",		Schemes Using Discrete Logarithm Cryptography",
	DOI 10.6028/nist.sp.800-56ar3, NIST SP 800-56Ar3, April		DOI 10.6028/nist.sp.800-56ar3, NIST SP 800-56Ar3, April
	2018, <https://doi.org/10.6028/nist.sp.800-56ar3>.		2018, <https://doi.org/10.6028/nist.sp.800-56ar3>.
End of changes. 18 change blocks.
	63 lines changed or deleted		61 lines changed or added
This html diff was produced by rfcdiff 1.48.