draft-irtf-cfrg-opaque-13.txt   draft-irtf-cfrg-opaque-14.txt 
Network Working Group D. Bourdrez Network Working Group D. Bourdrez
Internet-Draft Internet-Draft
Intended status: Informational H. Krawczyk Intended status: Informational H. Krawczyk
Expires: 20 June 2024 AWS Expires: 25 September 2024 AWS
K. Lewi K. Lewi
Meta Meta
C. A. Wood C. A. Wood
Cloudflare, Inc. Cloudflare, Inc.
18 December 2023 24 March 2024
The OPAQUE Asymmetric PAKE Protocol The OPAQUE Augmented PAKE Protocol
draft-irtf-cfrg-opaque-13 draft-irtf-cfrg-opaque-14
Abstract Abstract
This document describes the OPAQUE protocol, a secure asymmetric This document describes the OPAQUE protocol, an augmented (or
password-authenticated key exchange (aPAKE) that supports mutual asymmetric) password-authenticated key exchange (aPAKE) that supports
authentication in a client-server setting without reliance on PKI and mutual authentication in a client-server setting without reliance on
with security against pre-computation attacks upon server compromise. PKI and with security against pre-computation attacks upon server
In addition, the protocol provides forward secrecy and the ability to compromise. In addition, the protocol provides forward secrecy and
hide the password from the server, even during password registration. the ability to hide the password from the server, even during
This document specifies the core OPAQUE protocol and one password registration. This document specifies the core OPAQUE
instantiation based on 3DH. protocol and one instantiation based on 3DH.
Discussion Venues Discussion Venues
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at Source for this draft and an issue tracker can be found at
https://github.com/cfrg/draft-irtf-cfrg-opaque. https://github.com/cfrg/draft-irtf-cfrg-opaque.
Status of This Memo Status of This Memo
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 20 June 2024. This Internet-Draft will expire on 25 September 2024.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
skipping to change at page 2, line 31 skipping to change at page 2, line 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5
1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Cryptographic Dependencies . . . . . . . . . . . . . . . . . 6 2. Cryptographic Dependencies . . . . . . . . . . . . . . . . . 6
2.1. Oblivious Pseudorandom Function . . . . . . . . . . . . . 6 2.1. Oblivious Pseudorandom Function . . . . . . . . . . . . . 6
2.2. Key Derivation Function and Message Authentication 2.2. Key Derivation Function and Message Authentication
Code . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Code . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Hash Functions . . . . . . . . . . . . . . . . . . . . . 8 2.3. Hash Functions . . . . . . . . . . . . . . . . . . . . . 8
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Offline Registration . . . . . . . . . . . . . . . . . . 9 3.2. Registration . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Online Authenticated Key Exchange . . . . . . . . . . . . 10 3.3. Online Authenticated Key Exchange . . . . . . . . . . . . 10
4. Client Credential Storage and Key Recovery . . . . . . . . . 11 4. Client Credential Storage and Key Recovery . . . . . . . . . 11
4.1. Key Recovery . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Key Recovery . . . . . . . . . . . . . . . . . . . . . . 13
4.1.1. Envelope Structure . . . . . . . . . . . . . . . . . 13 4.1.1. Envelope Structure . . . . . . . . . . . . . . . . . 13
4.1.2. Envelope Creation . . . . . . . . . . . . . . . . . . 13 4.1.2. Envelope Creation . . . . . . . . . . . . . . . . . . 13
4.1.3. Envelope Recovery . . . . . . . . . . . . . . . . . . 14 4.1.3. Envelope Recovery . . . . . . . . . . . . . . . . . . 14
5. Offline Registration . . . . . . . . . . . . . . . . . . . . 15 5. Registration . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Registration Messages . . . . . . . . . . . . . . . . . . 17 5.1. Registration Messages . . . . . . . . . . . . . . . . . . 17
5.2. Registration Functions . . . . . . . . . . . . . . . . . 17 5.2. Registration Functions . . . . . . . . . . . . . . . . . 17
5.2.1. CreateRegistrationRequest . . . . . . . . . . . . . . 18 5.2.1. CreateRegistrationRequest . . . . . . . . . . . . . . 18
5.2.2. CreateRegistrationResponse . . . . . . . . . . . . . 18 5.2.2. CreateRegistrationResponse . . . . . . . . . . . . . 18
5.2.3. FinalizeRegistrationRequest . . . . . . . . . . . . . 19 5.2.3. FinalizeRegistrationRequest . . . . . . . . . . . . . 19
6. Online Authenticated Key Exchange . . . . . . . . . . . . . . 20 6. Online Authenticated Key Exchange . . . . . . . . . . . . . . 20
6.1. AKE Messages . . . . . . . . . . . . . . . . . . . . . . 23 6.1. AKE Messages . . . . . . . . . . . . . . . . . . . . . . 23
6.2. AKE Functions . . . . . . . . . . . . . . . . . . . . . . 24 6.2. AKE Functions . . . . . . . . . . . . . . . . . . . . . . 24
6.2.1. GenerateKE1 . . . . . . . . . . . . . . . . . . . . . 24 6.2.1. GenerateKE1 . . . . . . . . . . . . . . . . . . . . . 24
6.2.2. GenerateKE2 . . . . . . . . . . . . . . . . . . . . . 25 6.2.2. GenerateKE2 . . . . . . . . . . . . . . . . . . . . . 25
skipping to change at page 3, line 18 skipping to change at page 3, line 18
6.4.3. 3DH Client Functions . . . . . . . . . . . . . . . . 35 6.4.3. 3DH Client Functions . . . . . . . . . . . . . . . . 35
6.4.4. 3DH Server Functions . . . . . . . . . . . . . . . . 37 6.4.4. 3DH Server Functions . . . . . . . . . . . . . . . . 37
7. Configurations . . . . . . . . . . . . . . . . . . . . . . . 39 7. Configurations . . . . . . . . . . . . . . . . . . . . . . . 39
8. Application Considerations . . . . . . . . . . . . . . . . . 40 8. Application Considerations . . . . . . . . . . . . . . . . . 40
9. Implementation Considerations . . . . . . . . . . . . . . . . 42 9. Implementation Considerations . . . . . . . . . . . . . . . . 42
9.1. Implementation Safeguards . . . . . . . . . . . . . . . . 42 9.1. Implementation Safeguards . . . . . . . . . . . . . . . . 42
9.2. Error Considerations . . . . . . . . . . . . . . . . . . 43 9.2. Error Considerations . . . . . . . . . . . . . . . . . . 43
10. Security Considerations . . . . . . . . . . . . . . . . . . . 43 10. Security Considerations . . . . . . . . . . . . . . . . . . . 43
10.1. Notable Design Differences . . . . . . . . . . . . . . . 44 10.1. Notable Design Differences . . . . . . . . . . . . . . . 44
10.2. Security Analysis . . . . . . . . . . . . . . . . . . . 47 10.2. Security Analysis . . . . . . . . . . . . . . . . . . . 47
10.3. Related Protocols . . . . . . . . . . . . . . . . . . . 48 10.3. Identities . . . . . . . . . . . . . . . . . . . . . . . 48
10.4. Identities . . . . . . . . . . . . . . . . . . . . . . . 48 10.4. Export Key Usage . . . . . . . . . . . . . . . . . . . . 49
10.5. Export Key Usage . . . . . . . . . . . . . . . . . . . . 50 10.5. Static Diffie-Hellman Oracles . . . . . . . . . . . . . 49
10.6. Static Diffie-Hellman Oracles . . . . . . . . . . . . . 50 10.6. Random-Key Robust MACs . . . . . . . . . . . . . . . . . 50
10.7. Random-Key Robust MACs . . . . . . . . . . . . . . . . . 50 10.7. Input Validation . . . . . . . . . . . . . . . . . . . . 50
10.8. Input Validation . . . . . . . . . . . . . . . . . . . . 50 10.8. OPRF Key Stretching . . . . . . . . . . . . . . . . . . 50
10.9. OPRF Key Stretching . . . . . . . . . . . . . . . . . . 51 10.9. Client Enumeration . . . . . . . . . . . . . . . . . . . 51
10.10. Client Enumeration . . . . . . . . . . . . . . . . . . . 51 10.10. Protecting the Registration Masking Key . . . . . . . . 51
10.11. Protecting the Registration Masking Key . . . . . . . . 52 10.11. Password Salt and Storage Implications . . . . . . . . . 52
10.12. Password Salt and Storage Implications . . . . . . . . . 52 10.12. AKE Private Key Storage . . . . . . . . . . . . . . . . 52
10.13. AKE Private Key Storage . . . . . . . . . . . . . . . . 52 10.13. Client Authentication Using Credentials . . . . . . . . 52
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
12.1. Normative References . . . . . . . . . . . . . . . . . . 53 12.1. Normative References . . . . . . . . . . . . . . . . . . 53
12.2. Informative References . . . . . . . . . . . . . . . . . 53 12.2. Informative References . . . . . . . . . . . . . . . . . 53
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 57 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 57
Appendix B. Alternate Key Recovery Mechanisms . . . . . . . . . 57 Appendix B. Alternate Key Recovery Mechanisms . . . . . . . . . 57
Appendix C. Alternate AKE Instantiations . . . . . . . . . . . . 58 Appendix C. Alternate AKE Instantiations . . . . . . . . . . . . 57
C.1. HMQV Instantiation Sketch . . . . . . . . . . . . . . . . 58 C.1. HMQV Instantiation Sketch . . . . . . . . . . . . . . . . 58
C.2. SIGMA-I Instantiation Sketch . . . . . . . . . . . . . . 59 C.2. SIGMA-I Instantiation Sketch . . . . . . . . . . . . . . 59
Appendix D. Test Vectors . . . . . . . . . . . . . . . . . . . . 59 Appendix D. Test Vectors . . . . . . . . . . . . . . . . . . . . 59
D.1. Real Test Vectors . . . . . . . . . . . . . . . . . . . . 60 D.1. Real Test Vectors . . . . . . . . . . . . . . . . . . . . 60
D.1.1. OPAQUE-3DH Real Test Vector 1 . . . . . . . . . . . . 60 D.1.1. OPAQUE-3DH Real Test Vector 1 . . . . . . . . . . . . 60
D.1.2. OPAQUE-3DH Real Test Vector 2 . . . . . . . . . . . . 63 D.1.2. OPAQUE-3DH Real Test Vector 2 . . . . . . . . . . . . 63
D.1.3. OPAQUE-3DH Real Test Vector 3 . . . . . . . . . . . . 66 D.1.3. OPAQUE-3DH Real Test Vector 3 . . . . . . . . . . . . 66
D.1.4. OPAQUE-3DH Real Test Vector 4 . . . . . . . . . . . . 69 D.1.4. OPAQUE-3DH Real Test Vector 4 . . . . . . . . . . . . 69
D.1.5. OPAQUE-3DH Real Test Vector 5 . . . . . . . . . . . . 72 D.1.5. OPAQUE-3DH Real Test Vector 5 . . . . . . . . . . . . 72
D.1.6. OPAQUE-3DH Real Test Vector 6 . . . . . . . . . . . . 74 D.1.6. OPAQUE-3DH Real Test Vector 6 . . . . . . . . . . . . 74
skipping to change at page 4, line 20 skipping to change at page 4, line 20
This makes the password vulnerable to server mishandling, including This makes the password vulnerable to server mishandling, including
accidentally logging the password or storing it in plaintext in a accidentally logging the password or storing it in plaintext in a
database. Server compromise resulting in access to these plaintext database. Server compromise resulting in access to these plaintext
passwords is not an uncommon security incident, even among security- passwords is not an uncommon security incident, even among security-
conscious organizations. Moreover, plaintext password authentication conscious organizations. Moreover, plaintext password authentication
over secure channels such as TLS is also vulnerable to cases where over secure channels such as TLS is also vulnerable to cases where
TLS may fail, including PKI attacks, certificate mishandling, TLS may fail, including PKI attacks, certificate mishandling,
termination outside the security perimeter, visibility to TLS- termination outside the security perimeter, visibility to TLS-
terminating intermediaries, and more. terminating intermediaries, and more.
Asymmetric (or Augmented) Password Authenticated Key Exchange (aPAKE) Augmented (or Asymmetric) Password Authenticated Key Exchange (aPAKE)
protocols are designed to provide password authentication and protocols are designed to provide password authentication and
mutually authenticated key exchange in a client-server setting mutually authenticated key exchange in a client-server setting
without relying on PKI (except during client registration) and without relying on PKI (except during client registration) and
without disclosing passwords to servers or other entities other than without disclosing passwords to servers or other entities other than
the client machine. A secure aPAKE should provide the best possible the client machine. A secure aPAKE should provide the best possible
security for a password protocol. Indeed, some attacks are security for a password protocol. Indeed, some attacks are
inevitable, such as online impersonation attempts with guessed client inevitable, such as online impersonation attempts with guessed client
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
skipping to change at page 4, line 42 skipping to change at page 4, line 42
the password. Crucially important is for the password protocol to the password. Crucially important is 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 that is secure against pre- This document describes OPAQUE, an aPAKE that is secure against pre-
computation attacks (as defined in [JKX18]). OPAQUE provides forward computation attacks (as defined in [JKX18]). OPAQUE provides forward
secrecy with respect to password leakage while also hiding the secrecy with respect to password leakage while also hiding the
password from the server, even during password registration. OPAQUE password from the server, even during password registration. OPAQUE
allows applications to increase the difficulty of offline dictionary allows applications to increase the difficulty of offline dictionary
attacks via iterated hashing or other key stretching schemes. OPAQUE attacks via iterated hashing or other key-stretching schemes. OPAQUE
is also extensible, allowing clients to safely store and retrieve is also extensible, allowing clients to safely store and retrieve
arbitrary application data on servers using only their password. arbitrary application data on servers using 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
recovery mechanism, and an authenticated key exchange (AKE) protocol. recovery mechanism, and an authenticated key exchange (AKE) protocol.
It can be seen as a "compiler" for transforming any suitable AKE It can be seen as a "compiler" for transforming any suitable AKE
protocol into a secure aPAKE protocol. (See Section 10 for protocol into a secure aPAKE protocol. (See Section 10 for
requirements of the OPRF and AKE protocols.) This document specifies requirements of the OPRF and AKE protocols.) This document specifies
one OPAQUE instantiation based on [TripleDH]. Other instantiations one OPAQUE instantiation based on [TripleDH]. Other instantiations
skipping to change at page 5, line 20 skipping to change at page 5, line 20
OPAQUE consists of two stages: registration and authenticated key OPAQUE consists of two stages: registration and authenticated key
exchange. In the first stage, a client registers its password with exchange. In the first stage, a client registers its password with
the server and stores information used to recover authentication the server and stores information used to recover authentication
credentials on the server. Recovering these credentials can only be credentials on the server. Recovering these credentials can only be
done with knowledge of the client password. In the second stage, a done with knowledge of the client password. In the second stage, a
client uses its password to recover those credentials and client uses its password to recover those credentials and
subsequently uses them as input to an AKE protocol. This stage has subsequently uses them as input to an AKE protocol. This stage has
additional mechanisms to prevent an active attacker from interacting additional mechanisms to prevent an active attacker from interacting
with the server to guess or confirm clients registered via the first with the server to guess or confirm clients registered via the first
phase. Servers can use this mechanism to safeguard registered phase. Servers can use this mechanism to safeguard registered
clients against this type of enumeration attack; see Section 10.10 clients against this type of enumeration attack; see Section 10.9 for
for more discussion. more discussion.
The name OPAQUE is a homonym of O-PAKE where O is for Oblivious. The The name OPAQUE is a homonym of O-PAKE where O is for Oblivious. The
name OPAKE was taken. name OPAKE was taken.
This draft complies with the requirements for PAKE protocols set This draft complies with the requirements for PAKE protocols set
forth in [RFC8125]. forth in [RFC8125].
1.1. Requirements Notation 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 7, line 4 skipping to change at page 7, line 4
Nseed bytes, respectively, where Nn = Nseed = 32. Nseed bytes, respectively, where Nn = Nseed = 32.
2.1. Oblivious Pseudorandom Function 2.1. Oblivious Pseudorandom Function
An Oblivious Pseudorandom Function (OPRF) is a two-party protocol An Oblivious Pseudorandom Function (OPRF) is a two-party protocol
between client and server for computing a PRF, where the PRF key is between client and server for computing a PRF, where the PRF key is
held by the server and the input to the function is provided by the held by the server and the input to the function is provided by the
client. The client does not learn anything about the PRF other than client. The client does not learn anything about the PRF other than
the obtained output and the server learns nothing about the client's the obtained output and the server learns nothing about the client's
input or the function output. This specification depends on the input or the function output. This specification depends on the
prime-order OPRF construction specified in [OPRF], draft version -21, prime-order OPRF construction specified in [RFC9497], using the OPRF
using the OPRF mode (0x00) from [OPRF], Section 3.1. mode (0x00) from [RFC9497], Section 3.1.
The following OPRF client APIs are used: The following OPRF client APIs are used:
* Blind(element): Create and output (blind, blinded_element), * Blind(element): Create and output (blind, blinded_element),
consisting of a blinded representation of input element, denoted consisting of a blinded representation of input element, denoted
blinded_element, along with a value to revert the blinding blinded_element, along with a value to revert the blinding
process, denoted blind. process, denoted blind.
* Finalize(element, blind, evaluated_element): Finalize the OPRF * Finalize(element, blind, evaluated_element): Finalize the OPRF
evaluation using input element, random inverter blind, and evaluation using input element, random inverter blind, and
evaluation output evaluated_element, yielding output oprf_output. evaluation output evaluated_element, yielding output oprf_output.
Moreover, the following OPRF server APIs are used: Moreover, the following OPRF server APIs are used:
* BlindEvaluate(k, blinded_element): Evaluate blinded input element * BlindEvaluate(k, blinded_element): Evaluate blinded input element
blinded_element using input key k, yielding output element blinded_element using input key k, yielding output element
evaluated_element. This is equivalent to the BlindEvaluate evaluated_element. This is equivalent to the BlindEvaluate
function described in [OPRF], Section 3.3.1, where k is the function described in [RFC9497], Section 3.3.1, where k is the
private key parameter. private key parameter.
* DeriveKeyPair(seed, info): Create and output (sk, pk), consisting * DeriveKeyPair(seed, info): Create and output (sk, pk), consisting
of a private and public key derived deterministically from a seed of a private and public key derived deterministically from a seed
and info parameter, as described in [OPRF], Section 3.2. and info parameter, as described in [RFC9497], Section 3.2.
Finally, this specification makes use of the following shared APIs Finally, this specification makes use of the following shared APIs
and parameters: and parameters:
* SerializeElement(element): Map input element to a fixed-length * SerializeElement(element): Map input element to a fixed-length
byte array. byte array.
* DeserializeElement(buf): Attempt to map input byte array buf to an * DeserializeElement(buf): Attempt to map input byte array buf to an
OPRF group element. This function can raise a DeserializeError OPRF group element. This function can raise a DeserializeError
upon failure; see [OPRF], Section 2.1 for more details. upon failure; see [RFC9497], Section 2.1 for more details.
* Noe: The size of a serialized OPRF group element output from * Noe: The size of a serialized OPRF group element output from
SerializeElement. SerializeElement.
* Nok: The size of an OPRF private key as output from DeriveKeyPair. * Nok: The size of an OPRF private key as output from DeriveKeyPair.
2.2. Key Derivation Function and Message Authentication Code 2.2. Key Derivation Function and Message Authentication Code
A Key Derivation Function (KDF) is a function that takes some source A Key Derivation Function (KDF) is a function that takes some source
of initial keying material and uses it to derive one or more of initial keying material and uses it to derive one or more
skipping to change at page 8, line 15 skipping to change at page 8, line 15
* Extract(salt, ikm): Extract a pseudorandom key of fixed length Nx * Extract(salt, ikm): Extract a pseudorandom key of fixed length Nx
bytes from input keying material ikm and an optional byte string bytes from input keying material ikm and an optional byte string
salt. salt.
* Expand(prk, info, L): Expand a pseudorandom key prk using the * Expand(prk, info, L): Expand a pseudorandom key prk using the
optional string info into L bytes of output keying material. optional string info into L bytes of output keying material.
* Nx: The output size of the Extract() function in bytes. * Nx: The output size of the Extract() function in bytes.
This specification also makes use of a random-key robust Message This specification also makes use of a random-key robust Message
Authentication Code (MAC). See Section 10.7 for more details on this Authentication Code (MAC). See Section 10.6 for more details on this
property. The API and parameters for the random-key robust MAC are property. The API and parameters for the random-key robust MAC are
as follows: as follows:
* MAC(key, msg): Compute a message authentication code over input * MAC(key, msg): Compute a message authentication code over input
msg with key key, producing a fixed-length output of Nm bytes. msg with key key, producing a fixed-length output of Nm bytes.
* Nm: The output size of the MAC() function in bytes. * Nm: The output size of the MAC() function in bytes.
2.3. Hash Functions 2.3. Hash Functions
skipping to change at page 9, line 13 skipping to change at page 9, line 13
mutually authenticated key exchange. mutually authenticated key exchange.
3.1. Setup 3.1. Setup
Prior to both stages, the client and server agree on a configuration Prior to both stages, the client and server agree on a configuration
that fully specifies the cryptographic algorithm dependencies that fully specifies the cryptographic algorithm dependencies
necessary to run the protocol; see Section 7 for details. The server necessary to run the protocol; see Section 7 for details. The server
chooses a pair of keys (server_private_key and server_public_key) for chooses a pair of keys (server_private_key and server_public_key) for
the AKE, and chooses a seed (oprf_seed) of Nh bytes for the OPRF. the AKE, and chooses a seed (oprf_seed) of Nh bytes for the OPRF.
The server can use server_private_key and server_public_key with The server can use server_private_key and server_public_key with
multiple clients. The server can also opt to use different seeds for multiple clients. The server can also opt to use a different seed
each client, so long as they are maintained across the registration for each client (i.e. each client can be assigned a single seed), so
and online AKE stages, and kept consistent for each client (since an long as they are maintained across the registration and online AKE
inconsistent mapping of clients to seeds could leak information as stages, and kept consistent for each client (since an inconsistent
described in Section 10.10). mapping of clients to seeds could leak information as described in
Section 10.9).
3.2. Offline Registration 3.2. Registration
Registration is the only stage in OPAQUE that requires a server- Registration is the only stage in OPAQUE that requires a server-
authenticated channel with confidentiality and integrity: either authenticated channel with confidentiality and integrity: either
physical, out-of-band, PKI-based, etc. physical, out-of-band, PKI-based, etc.
The client inputs its credentials, which include its password and The client inputs its credentials, which include its password and
user identifier, and the server inputs its parameters, which include user identifier, and the server inputs its parameters, which include
its private key and other information. its private key and other information.
The client output of this stage is a single value export_key that the The client output of this stage is a single value export_key that the
skipping to change at page 12, line 14 skipping to change at page 12, line 14
* server_public_key: The encoded server public key for the AKE * server_public_key: The encoded server public key for the AKE
protocol. protocol.
* client_identity: The client identity. This is an application- * client_identity: The client identity. This is an application-
specific value, e.g., an e-mail address or an account name. If specific value, e.g., an e-mail address or an account name. If
not specified, it defaults to the client's public key. not specified, it defaults to the client's public key.
* server_identity: The server identity. This is typically a domain * server_identity: The server identity. This is typically a domain
name, e.g., example.com. If not specified, it defaults to the name, e.g., example.com. If not specified, it defaults to the
server's public key. See Section 10.4 for information about this server's public key. See Section 10.3 for information about this
identity. identity.
A subset of these credential values are used in the A subset of these credential values are used in the
CleartextCredentials structure as follows: CleartextCredentials structure as follows:
struct { struct {
uint8 server_public_key[Npk]; uint8 server_public_key[Npk];
uint8 server_identity<1..2^16-1>; uint8 server_identity<1..2^16-1>;
uint8 client_identity<1..2^16-1>; uint8 client_identity<1..2^16-1>;
} CleartextCredentials; } CleartextCredentials;
skipping to change at page 15, line 39 skipping to change at page 15, line 39
cleartext_credentials = CreateCleartextCredentials(server_public_key, cleartext_credentials = CreateCleartextCredentials(server_public_key,
client_public_key, server_identity, client_identity) client_public_key, server_identity, client_identity)
expected_tag = MAC(auth_key, concat(envelope.nonce, cleartext_credentials)) expected_tag = MAC(auth_key, concat(envelope.nonce, cleartext_credentials))
If !ct_equal(envelope.auth_tag, expected_tag) If !ct_equal(envelope.auth_tag, expected_tag)
raise EnvelopeRecoveryError raise EnvelopeRecoveryError
return (client_private_key, cleartext_credentials, export_key) return (client_private_key, cleartext_credentials, export_key)
In the case of EnvelopeRecoveryError being raised, all previously- In the case of EnvelopeRecoveryError being raised, all previously-
computed intermediary values in this function MUST be deleted. computed intermediary values in this function MUST be deleted.
5. Offline Registration 5. Registration
The registration process proceeds as follows. The client inputs the The registration process proceeds as follows. The client inputs the
following values: following values:
* password: The client's password. * password: The client's password.
* creds: The client credentials, as described in Section 4. * creds: The client credentials, as described in Section 4.
The server inputs the following values: The server inputs the following values:
skipping to change at page 16, line 46 skipping to change at page 16, line 46
Section 5.1 describes the formats for the above messages, and Section 5.1 describes the formats for the above messages, and
Section 5.2 describes details of the functions and the corresponding Section 5.2 describes details of the functions and the corresponding
parameters referenced above. parameters referenced above.
At the end of this interaction, the server stores the record object At the end of this interaction, the server stores the record object
as the credential file for each client along with the associated as the credential file for each client along with the associated
credential_identifier and client_identity (if different). Note that credential_identifier and client_identity (if different). Note that
the values oprf_seed and server_private_key from the server's setup the values oprf_seed and server_private_key from the server's setup
phase must also be persisted. The oprf_seed value SHOULD be used for phase must also be persisted. The oprf_seed value SHOULD be used for
all clients; see Section 10.10. The server_private_key may be unique all clients; see Section 10.9. The server_private_key may be unique
for each client. for each client.
Both client and server MUST validate the other party's public key Both client and server MUST validate the other party's public key
before use. See Section 10.8 for more details. Upon completion, the before use. See Section 10.7 for more details. Upon completion, the
server stores the client's credentials for later use. Moreover, the server stores the client's credentials for later use. Moreover, the
client MAY use the output export_key for further application-specific client MAY use the output export_key for further application-specific
purposes; see Section 10.5. purposes; see Section 10.4.
5.1. Registration Messages 5.1. Registration Messages
This section contains definitions of the RegistrationRequest, This section contains definitions of the RegistrationRequest,
RegistrationResponse, and RegistrationRecord messages exchanged RegistrationResponse, and RegistrationRecord messages exchanged
between client and server during registration. between client and server during registration.
struct { struct {
uint8 blinded_message[Noe]; uint8 blinded_message[Noe];
} RegistrationRequest; } RegistrationRequest;
skipping to change at page 18, line 9 skipping to change at page 18, line 9
5.2. Registration Functions 5.2. Registration Functions
This section contains definitions of the functions used by client and This section contains definitions of the functions used by client and
server during registration, including CreateRegistrationRequest, server during registration, including CreateRegistrationRequest,
CreateRegistrationResponse, and FinalizeRegistrationRequest. CreateRegistrationResponse, and FinalizeRegistrationRequest.
5.2.1. CreateRegistrationRequest 5.2.1. CreateRegistrationRequest
To begin the registration flow, the client executes the following To begin the registration flow, the client executes the following
function. This function can fail with an InvalidInputError error function. This function can fail with an InvalidInputError error
with negligibile probability. A different input password is with negligible probability. A different input password is necessary
necessary in the event of this error. in the event of this error.
CreateRegistrationRequest CreateRegistrationRequest
Input: Input:
- password, an opaque byte string containing the client's password. - password, an opaque byte string containing the client's password.
Output: Output:
- request, a RegistrationRequest structure. - request, a RegistrationRequest structure.
- blind, an OPRF scalar value. - blind, an OPRF scalar value.
skipping to change at page 18, line 34 skipping to change at page 18, line 34
def CreateRegistrationRequest(password): def CreateRegistrationRequest(password):
(blind, blinded_element) = Blind(password) (blind, blinded_element) = Blind(password)
blinded_message = SerializeElement(blinded_element) blinded_message = SerializeElement(blinded_element)
Create RegistrationRequest request with blinded_message Create RegistrationRequest request with blinded_message
return (request, blind) return (request, blind)
5.2.2. CreateRegistrationResponse 5.2.2. CreateRegistrationResponse
To process the client's registration request, the server executes the To process the client's registration request, the server executes the
following function. This function can fail with a DeriveKeyPairError following function. This function can fail with a DeriveKeyPairError
error with negligible probability. In this case, application can error with negligible probability. In this case, applications can
choose a new credential_identifier for this registration record and choose a new credential_identifier for this registration record and
re-run this function. re-run this function.
CreateRegistrationResponse CreateRegistrationResponse
Input: Input:
- request, a RegistrationRequest structure. - request, a RegistrationRequest structure.
- server_public_key, the server's public key. - server_public_key, the server's public key.
- credential_identifier, an identifier that uniquely represents the credential. - credential_identifier, an identifier that uniquely represents the credential.
- oprf_seed, the seed of Nh bytes used by the server to generate an oprf_key. - oprf_seed, the seed of Nh bytes used by the server to generate an oprf_key.
skipping to change at page 21, line 40 skipping to change at page 21, line 40
client's registration. client's registration.
* credential_identifier: An identifier that uniquely represents the * credential_identifier: An identifier that uniquely represents the
credential. credential.
* oprf_seed: The seed used to derive per-client OPRF keys. * oprf_seed: The seed used to derive per-client OPRF keys.
The client receives two outputs: a session secret and an export key. The client receives two outputs: a session secret and an export key.
The export key is only available to the client and may be used for The export key is only available to the client and may be used for
additional application-specific purposes, as outlined in additional application-specific purposes, as outlined in
Section 10.5. Clients and servers MUST NOT use the output export_key Section 10.4. Clients MUST NOT use the output export_key before
before authenticating the peer in the authenticated key exchange authenticating the peer in the authenticated key exchange protocol.
protocol. See Appendix B for more details about this requirement. See Appendix B for more details about this requirement. The server
The server receives a single output: a session secret matching the receives a single output: a session secret matching the client's.
client's.
The protocol runs as shown below: The protocol runs as shown below:
Client Server Client Server
------------------------------------------------------ ------------------------------------------------------
ke1 = GenerateKE1(password) ke1 = GenerateKE1(password)
ke1 ke1
-------------------------> ------------------------->
skipping to change at page 28, line 10 skipping to change at page 28, line 10
This section describes the CreateCredentialRequest, This section describes the CreateCredentialRequest,
CreateCredentialResponse, and RecoverCredentials functions used for CreateCredentialResponse, and RecoverCredentials functions used for
credential retrieval. credential retrieval.
6.3.2.1. CreateCredentialRequest 6.3.2.1. CreateCredentialRequest
The CreateCredentialRequest is used by the client to initiate the The CreateCredentialRequest is used by the client to initiate the
credential retrieval process, and it produces a CredentialRequest credential retrieval process, and it produces a CredentialRequest
message and OPRF state. Like CreateRegistrationRequest, this message and OPRF state. Like CreateRegistrationRequest, this
function can fail with an InvalidInputError error with negligibile function can fail with an InvalidInputError error with negligible
probability. However, this should not occur since registration (via probability. However, this should not occur since registration (via
CreateRegistrationRequest) will fail when provided the same password CreateRegistrationRequest) will fail when provided the same password
input. input.
CreateCredentialRequest CreateCredentialRequest
Input: Input:
- password, an opaque byte string containing the client's password. - password, an opaque byte string containing the client's password.
Output: Output:
skipping to change at page 32, line 43 skipping to change at page 32, line 43
Section 7, as well as groups covered by test vectors in Appendix D, Section 7, as well as groups covered by test vectors in Appendix D,
are described in the following sections. are described in the following sections.
6.4.1.1. 3DH ristretto255 6.4.1.1. 3DH ristretto255
This section describes the implementation of the Diffie-Hellman key This section describes the implementation of the Diffie-Hellman key
exchange functions based on ristretto255, as defined in [RISTRETTO]. exchange functions based on ristretto255, as defined in [RISTRETTO].
* DeriveDiffieHellmanKeyPair(seed): This function is implemented as * DeriveDiffieHellmanKeyPair(seed): This function is implemented as
DeriveKeyPair(seed, "OPAQUE-DeriveDiffieHellmanKeyPair"), where DeriveKeyPair(seed, "OPAQUE-DeriveDiffieHellmanKeyPair"), where
DeriveKeyPair is as specified in [OPRF], Section 3.2. The public DeriveKeyPair is as specified in [RFC9497], Section 3.2. The
value from DeriveKeyPair is encoded using SerializeElement from public value from DeriveKeyPair is encoded using SerializeElement
Section 2.1 of [OPRF]. from Section 2.1 of [RFC9497].
* DiffieHellman(k, B): Implemented as scalar multiplication as * DiffieHellman(k, B): Implemented as scalar multiplication as
described in Section 4 of [RISTRETTO] after decoding B from its described in Section 4 of [RISTRETTO] after decoding B from its
encoded input using the Decode function in Section 4.3.1 of encoded input using the Decode function in Section 4.3.1 of
[RISTRETTO]. The output is then encoded using the [RISTRETTO]. The output is then encoded using the
SerializeElement function of the OPRF group described in [OPRF], SerializeElement function of the OPRF group described in
Section 2.1. [RFC9497], Section 2.1.
6.4.1.2. 3DH P-256 6.4.1.2. 3DH P-256
This section describes the implementation of the Diffie-Hellman key This section describes the implementation of the Diffie-Hellman key
exchange functions based on NIST P-256, as defined in [NISTCurves]. exchange functions based on NIST P-256, as defined in [NISTCurves].
* DeriveDiffieHellmanKeyPair(seed): This function is implemented as * DeriveDiffieHellmanKeyPair(seed): This function is implemented as
DeriveKeyPair(seed, "OPAQUE-DeriveDiffieHellmanKeyPair"), where DeriveKeyPair(seed, "OPAQUE-DeriveDiffieHellmanKeyPair"), where
DeriveKeyPair is as specified in [OPRF], Section 3.2. The public DeriveKeyPair is as specified in [RFC9497], Section 3.2. The
value from DeriveKeyPair is encoded using SerializeElement from public value from DeriveKeyPair is encoded using SerializeElement
Section 2.1 of [OPRF]. from Section 2.1 of [RFC9497].
* DiffieHellman(k, B): Implemented as scalar multiplication as * DiffieHellman(k, B): Implemented as scalar multiplication as
described in [NISTCurves], after decoding B from its encoded input described in [NISTCurves], after decoding B from its encoded input
using the compressed Octet-String-to-Elliptic-Curve-Point method using the compressed Octet-String-to-Elliptic-Curve-Point method
according to [NISTCurves]. The output is then encoded using the according to [NISTCurves]. The output is then encoded using the
SerializeElement function of the OPRF group described in [OPRF], SerializeElement function of the OPRF group described in
Section 2.1. [RFC9497], Section 2.1.
6.4.1.3. 3DH Curve25519 6.4.1.3. 3DH Curve25519
This section describes the implementation of the Diffie-Hellman key This section describes the implementation of the Diffie-Hellman key
exchange functions based on Curve25519, as defined in [Curve25519]. exchange functions based on Curve25519, as defined in [Curve25519].
* DeriveDiffieHellmanKeyPair(seed): This function is implemented by * DeriveDiffieHellmanKeyPair(seed): This function is implemented by
returning the private key k based on seed (of length Nseed = 32 returning the private key k based on seed (of length Nseed = 32
bytes), as described in Section 5 of [Curve25519], as well as the bytes), as described in Section 5 of [Curve25519], as well as the
result of DiffieHellman(k, B), where B is the base point of result of DiffieHellman(k, B), where B is the base point of
skipping to change at page 39, line 29 skipping to change at page 39, line 29
def AuthServerFinalize(ke3): def AuthServerFinalize(ke3):
if !ct_equal(ke3.client_mac, state.expected_client_mac): if !ct_equal(ke3.client_mac, state.expected_client_mac):
raise ClientAuthenticationError raise ClientAuthenticationError
return state.session_key return state.session_key
7. Configurations 7. Configurations
An OPAQUE-3DH configuration is a tuple (OPRF, KDF, MAC, Hash, KSF, An OPAQUE-3DH configuration is a tuple (OPRF, KDF, MAC, Hash, KSF,
Group, Context) such that the following conditions are met: Group, Context) such that the following conditions are met:
* The OPRF protocol uses the "base mode" variant of [OPRF] and * The OPRF protocol uses the "base mode" variant of [RFC9497] and
implements the interface in Section 2. Examples include implements the interface in Section 2. Examples include
ristretto255-SHA512 and P256-SHA256. ristretto255-SHA512 and P256-SHA256.
* The KDF, MAC, and Hash functions implement the interfaces in * The KDF, MAC, and Hash functions implement the interfaces in
Section 2. Examples include HKDF [RFC5869] for the KDF, HMAC Section 2. Examples include HKDF [RFC5869] for the KDF, HMAC
[RFC2104] for the MAC, and SHA-256 and SHA-512 for the Hash [RFC2104] for the MAC, and SHA-256 and SHA-512 for the Hash
functions. If an extensible output function such as SHAKE128 functions. If an extensible output function such as SHAKE128
[FIPS202] is used then the output length Nh MUST be chosen to [FIPS202] is used then the output length Nh MUST be chosen to
align with the target security level of the OPAQUE configuration. align with the target security level of the OPAQUE configuration.
For example, if the target security parameter for the For example, if the target security parameter for the
skipping to change at page 41, line 23 skipping to change at page 41, line 23
* Client and server identities: As described in Section 4, clients * Client and server identities: As described in Section 4, clients
and servers are identified with their public keys by default. and servers are identified with their public keys by default.
However, applications may choose alternate identities that are However, applications may choose alternate identities that are
pinned to these public keys. For example, servers may use a pinned to these public keys. For example, servers may use a
domain name instead of a public key as their identifier. Absent domain name instead of a public key as their identifier. Absent
alternate notions of identity, applications SHOULD set these alternate notions of identity, applications SHOULD set these
identities to nil and rely solely on public key information. identities to nil and rely solely on public key information.
* Configuration and envelope updates: Applications may wish to * Configuration and envelope updates: Applications may wish to
update or change their configuration or other parameters which update or change their configuration or other parameters that
affect the client's RegistrationRecord over time. Some reasons affect the client's RegistrationRecord over time. Some reasons
for changing these are to use different cryptographic algorithms, for changing these are to use different cryptographic algorithms,
e.g., a different KSF with improved parameters, or to update key e.g., a different KSF with improved parameters, or to update key
material that is cryptographically bound to the material that is cryptographically bound to the
RegistrationRecord, such as the server's public key RegistrationRecord, such as the server's public key
(server_public_key). Any such change will require users to re- (server_public_key). Any such change will require users to re-
register to create a new RegistrationRecord. Supporting these register to create a new RegistrationRecord. Supporting these
types of updates can be helpful for applications which anticipate types of updates can be helpful for applications that anticipate
such changes in their deployment setting. such changes in their deployment setting.
* Password hardening parameters: Key stretching is done to help * Password hardening parameters: Key stretching is done to help
prevent password disclosure in the event of server compromise; see prevent password disclosure in the event of server compromise; see
Section 10.9. There is no ideal or default set of parameters, Section 10.8. There is no ideal or default set of parameters,
though relevant specifications for KSFs give some reasonable though relevant specifications for KSFs give some reasonable
defaults. defaults.
* Enumeration prevention: As described in Section 6.3.2.2, if * Enumeration prevention: As described in Section 6.3.2.2, if
servers receive a credential request for a non-existent client, servers receive a credential request for a non-existent client,
they SHOULD respond with a "fake" response to prevent active they SHOULD respond with a "fake" response to prevent active
client enumeration attacks. Servers that implement this client enumeration attacks. Servers that implement this
mitigation SHOULD use the same configuration information (such as mitigation SHOULD use the same configuration information (such as
the oprf_seed) for all clients; see Section 10.10. In settings the oprf_seed) for all clients; see Section 10.9. In settings
where this attack is not a concern, servers may choose to not where this attack is not a concern, servers may choose to not
support this functionality. support this functionality.
* Handling password changes: In the event of a password change, the * Handling password changes: In the event of a password change, the
client and server can run the offline registration phase using the client and server can run the registration phase using the new
new password as a fresh instance (ensuring to resample all random password as a fresh instance (ensuring to resample all random
values). The resulting registration record can then replace the values). The resulting registration record can then replace the
previous record corresponding to the client's old password previous record corresponding to the client's old password
registration. registration.
9. Implementation Considerations 9. Implementation Considerations
This section documents considerations for OPAQUE implementations. This section documents considerations for OPAQUE implementations.
This includes implementation safeguards and error handling This includes implementation safeguards and error handling
considerations. considerations.
skipping to change at page 44, line 44 skipping to change at page 44, line 44
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
registered users. Second, it removes the need for client registered users. Second, it removes the need for client
applications to generate private keys during registration. applications to generate private keys during registration.
Instead, this responsibility is handled by OPAQUE, thereby Instead, this responsibility is handled by OPAQUE, thereby
simplifying the client interface to the protocol. simplifying the client interface to the protocol.
* Envelopes are masked with a per-user masking key as a way of * Envelopes are masked with a per-user masking key as a way of
preventing client enumeration attacks. See Section 10.10 for more preventing client enumeration attacks. See Section 10.9 for more
details. This extension is not needed for the security of OPAQUE details. This extension is not needed for the security of OPAQUE
as an aPAKE but only used to provide a defense against enumeration as an aPAKE but only used to provide a defense against enumeration
attacks. In the analysis, the masking key can be simulated as a attacks. In the analysis, the masking key can be simulated as a
(pseudo) random key. This change was made to support real-world (pseudo) random key. This change was made to support real-world
use cases where client or user enumeration is a security (or use cases where client or user enumeration is a security (or
privacy) risk. privacy) risk.
* Per-user OPRF keys are derived from a client identity and cross- * Per-user OPRF keys are derived from a client identity and cross-
user PRF seed as a mitigation against client enumeration attacks. user PRF seed as a mitigation against client enumeration attacks.
See Section 10.10 for more details. The analysis of OPAQUE See Section 10.9 for more details. The analysis of OPAQUE assumes
assumes OPRF keys of different users are independently random or OPRF keys of different users are independently random or
pseudorandom. Deriving these keys via a single PRF (i.e., with a pseudorandom. Deriving these keys via a single PRF (i.e., with a
single cross-user key) applied to users' identities satisfies this single cross-user key) applied to users' identities satisfies this
assumption. This change was made to support real-world use cases assumption. This change was made to support real-world use cases
where client or user enumeration is a security (or privacy) risk. where client or user enumeration is a security (or privacy) risk.
Note that the derivation of the OPRF key via a PRF keyed by
oprf_seed and applied to the unique credential_identifier ensures
the critical requirement of the per-user OPRF keys being unique
per client.
* The protocol outputs an export key for the client in addition to a * The protocol outputs an export key for the client in addition to a
shared session key that can be used for application-specific shared session key that can be used for application-specific
purposes. This key is a pseudorandom value derived from the purposes. This key is a pseudorandom value derived from the
client password (among other values) and has no influence on the client password (among other values) and has no influence on the
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 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.
* The protocol admits application-specific context information * The protocol admits application-specific context information
configured out-of-band in the AKE transcript. This allows domain configured out-of-band in the AKE transcript. This allows domain
separation between different application uses of OPAQUE. This is separation between different application uses of OPAQUE. This is
a mechanism for the AKE component and is best practice for domain a mechanism for the AKE component and is best practice for domain
separation between different applications of the protocol. This separation between different applications of the protocol. This
skipping to change at page 46, line 15 skipping to change at page 46, line 26
* [JKX18] comments on a defense against offline dictionary attacks * [JKX18] comments on a defense against offline dictionary attacks
upon server compromise or honest-but-curious servers. The authors upon server compromise or honest-but-curious servers. The authors
suggest implementing the OPRF phase as a threshold OPRF [TOPPSS], suggest implementing the OPRF phase as a threshold OPRF [TOPPSS],
effectively forcing an attacker to act online or to control at effectively forcing an attacker to act online or to control at
least t key shares (among the total n), where t is the threshold least t key shares (among the total n), where t is the threshold
number of shares necessary to recombine the secret OPRF key, and number of shares necessary to recombine the secret OPRF key, and
only then be able to run an offline dictionary attack. This only then be able to run an offline dictionary attack. This
implementation only affects the server and changes nothing for the implementation only affects the server and changes nothing for the
client. Furthermore, if the threshold OPRF servers holding these client. Furthermore, if the threshold OPRF servers holding these
keys are separate from the authentication server, then recovering keys are separate from the authentication server, then recovering
all n shares would still not suffice to run an offline dictionnary all n shares would still not suffice to run an offline dictionary
attack without access to the client record database. However, attack without access to the client record database. However,
this mechanism is out of scope for this document. this mechanism is out of scope for this document.
The following list enumerates notable differences and refinements The following list enumerates notable differences and refinements
from the original cryptographic design in [JKX18] and the from the original cryptographic design in [JKX18] and the
corresponding CFRG document [I-D.krawczyk-cfrg-opaque-03] that were corresponding CFRG document [I-D.krawczyk-cfrg-opaque-03] that were
made to make this specification suitable for interoperable made to make this specification suitable for interoperable
implementations. implementations.
* [JKX18] used a generic prime-order group for the DH-OPRF and HMQV * [JKX18] used a generic prime-order group for the DH-OPRF and HMQV
operations, and includes necessary prime-order subgroup checks operations, and includes necessary prime-order subgroup checks
when receiving attacker-controlled values over the wire. This when receiving attacker-controlled values over the wire. 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
[I-D.irtf-cfrg-voprf], Section 2.1. This specification also [RFC9497], Section 2.1. This specification also delegates OPRF
delegates OPRF group choice and operations to group choice and operations to [RFC9497]. As such, the prime-
[I-D.irtf-cfrg-voprf]. As such, the prime-order group as used in order group as used in the OPRF and 3DH as specified in this
the OPRF and 3DH as specified in this document both adhere to the document both adhere to the requirements as [JKX18].
requirements as [JKX18].
* [JKX18] specified DH-OPRF (see Appendix B) to instantiate the OPRF * [JKX18] specified DH-OPRF (see Appendix B) to instantiate the OPRF
functionality in the protocol. A critical part of DH-OPRF is the functionality in the protocol. A critical part of DH-OPRF is 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 the [I-D.irtf-cfrg-voprf], which is functionality based on the [RFC9497], which is identical to the
identical to the DH-OPRF functionality in [JKX18] and, concretely, DH-OPRF functionality in [JKX18] and, concretely, uses the hash-
uses the hash-to-curve functions in [I-D.irtf-cfrg-hash-to-curve]. to-curve functions in [RFC9380]. All hash-to-curve methods in
All hash-to-curve methods in [I-D.irtf-cfrg-hash-to-curve] are [RFC9380] are compliant with the requirement in [JKX18], namely,
compliant with the requirement in [JKX18], namely, that the output that the output be a member of the prime-order group.
be a member of the prime-order group.
* [JKX18] and [I-D.krawczyk-cfrg-opaque-03] both used HMQV as the * [JKX18] and [I-D.krawczyk-cfrg-opaque-03] both used HMQV as the
AKE for the protocol. However, this document fully specifies 3DH AKE for the protocol. However, this document fully specifies 3DH
instead of HMQV (though a sketch for how to instantiate OPAQUE instead of HMQV (though a sketch for how to instantiate OPAQUE
using HMQV is included in Appendix C.1). Since 3DH satisfies the using HMQV is included in Appendix C.1). Since 3DH satisfies the
essential requirements for the AKE as described in [JKX18] and essential requirements for the AKE as described in [JKX18] and
[I-D.krawczyk-cfrg-opaque-03], as recalled in Section 10.2, this [I-D.krawczyk-cfrg-opaque-03], as recalled in Section 10.2, this
change preserves the overall security of the protocol. 3DH was change preserves the overall security of the protocol. 3DH was
chosen for its simplicity and ease of implementation. chosen for its simplicity and ease of implementation.
* The DH-OPRF and HMQV instantiation of OPAQUE in [JKX18], Figure 12 * The DH-OPRF and HMQV instantiation of OPAQUE in [JKX18], Figure 12
uses a different transcript than that which is described in this uses a different transcript than that which is described in this
specification. In particular, the key exchange transcript specification. In particular, the key exchange transcript
specified in Section 6.4 is a superset of the transcript as specified in Section 6.4 is a superset of the transcript as
defined in [JKX18]. This was done to align with best practices, defined in [JKX18]. This was done to align with best practices,
such as is done for key exchange protocols like TLS 1.3 [RFC8446]. such as is done for key exchange protocols like TLS 1.3 [RFC8446].
skipping to change at page 47, line 41 skipping to change at page 47, line 49
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 pre- al. [JKKX16]. None of these papers considered security against pre-
computation attacks or presented a proof of aPAKE security (not even computation attacks or presented a proof of aPAKE security (not even
in a weak model). in a weak model).
The KCI property required from AKE protocols for use with OPAQUE The KCI property required from AKE protocols for use with OPAQUE
states that knowledge of a party's private key does not allow an states that knowledge of a party's private key does not allow an
attacker to impersonate others to that party. This is an important attacker to impersonate others to that party. This is an important
security property achieved by most public-key based AKE protocols, security property achieved by most public-key-based AKE protocols,
including protocols that use signatures or public key encryption for including protocols that use signatures or public key encryption for
authentication. It is also a property of many implicitly authentication. It is also a property of many implicitly
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
skipping to change at page 48, line 15 skipping to change at page 48, line 24
In [JKX18], security is proven for one instance (i.e., one key) of In [JKX18], security is proven for one instance (i.e., one key) 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, in particular against servers that choose the same OPRF separation, in particular 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 [JKX18] the protocol in the multi-key setting; the OPAQUE analysis in [JKX18]
assumes single server-key instances. Adding server_identityto the assumes single server-key instances. Adding server_identity to the
OPRF input provides domain separation for clients that reuse the OPRF input provides domain separation for clients that reuse the same
sameclient_identity` across different server instantiations. client_identity across different server instantiations.
10.3. Related Protocols
Despite the existence of multiple designs for (PKI-free) aPAKE
protocols, none of these protocols are secure against pre-computation
attacks. This includes protocols that have recent analyses in the UC
model such as AuCPace [AuCPace] and SPAKE2+ [SPAKE2plus]. In
particular, none of these protocols can use the standard technique
against pre-computation that combines secret random values ("salt")
into the one-way password mappings. Either these protocols do not
use a salt at all or, if they do, they transmit the salt from server
to client in the clear, hence losing the secrecy of the salt and its
defense against pre-computation.
We note that as shown in [JKX18], these protocols, and any aPAKE in
the model from [GMR06], can be converted into an aPAKE secure against
pre-computation attacks at the expense of an additional OPRF
execution.
Beyond AuCPace and SPAKE2+, the most widely deployed PKI-free aPAKE
is SRP [RFC2945], which is vulnerable to pre-computation attacks,
lacks proof of security, and is less efficient than OPAQUE.
Moreover, SRP requires a ring as it mixes addition and multiplication
operations, and thus does not work over standard elliptic curves.
OPAQUE is therefore a suitable replacement for applications that use
SRP.
10.4. 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
to server is outside the scope of this protocol, and it is up to an to server is outside the scope of this protocol, and it is up to an
application to choose how this identity should be delivered (for application to choose how this identity should be delivered (for
skipping to change at page 50, line 5 skipping to change at page 49, line 32
protected by the authentication from the envelope. Then, the client protected by the authentication from the envelope. Then, the client
can verify that the client_identity and server_identity contained in can verify that the client_identity and server_identity contained in
its envelope match the client_identity and server_identity supplied its envelope match the client_identity and server_identity supplied
by the server. by the server.
However, if this extra layer of verification is unnecessary for the However, if this extra layer of verification is unnecessary for the
application, then simply leaving client_identity and server_identity application, then simply leaving client_identity and server_identity
unspecified (and using client_public_key and server_public_key unspecified (and using client_public_key and server_public_key
instead) is acceptable. instead) is acceptable.
10.5. Export Key Usage 10.4. Export Key Usage
The export key can be used (separately from the OPAQUE protocol) to The export key can be used (separately from the OPAQUE protocol) to
provide confidentiality and integrity to other data which only the provide confidentiality and integrity to other data which only the
client should be able to process. For instance, if the client wishes client should be able to process. For instance, if the client wishes
to store secrets with a third party, then this export key can be used to store secrets with a third party, then this export key can be used
by the client to encrypt these secrets so that they remain hidden by the client to encrypt these secrets so that they remain hidden
from a passive adversary that does not have access to the server's from a passive adversary that does not have access to the server's
secret keys or the client's password. secret keys or the client's password.
10.6. Static Diffie-Hellman Oracles 10.5. Static Diffie-Hellman Oracles
While one can expect the practical security of the OPRF function While one can expect the practical security of the OPRF function
(namely, the hardness of computing the function without knowing the (namely, the hardness of computing the function without knowing the
key) to be in the order of computing discrete logarithms or solving key) to be in the order of computing discrete logarithms or solving
Diffie-Hellman, Brown and Gallant [BG04] and Cheon [Cheon06] show an Diffie-Hellman, Brown and Gallant [BG04] and Cheon [Cheon06] show an
attack that slightly improves on generic attacks. For typical attack that slightly improves on generic attacks. For typical
curves, the attack requires an infeasible number of calls to the OPRF curves, the attack requires an infeasible number of calls to the OPRF
or results in insignificant security loss; see [OPRF] for more or results in insignificant security loss; see [RFC9497] for more
information. For OPAQUE, these attacks are particularly impractical information. For OPAQUE, these attacks are particularly impractical
as they translate into an infeasible number of failed authentication as they translate into an infeasible number of failed authentication
attempts directed at individual users. attempts directed at individual users.
10.7. Random-Key Robust MACs 10.6. Random-Key Robust MACs
The random-key robustness property for a MAC states that, given two The random-key robustness property for a MAC states that, given two
random keys k1 and k2, it is infeasible to find a message m such that random keys k1 and k2, it is infeasible to find a message m such that
MAC(k1, m) = MAC(k2, m). Note that in general, not every MAC MAC(k1, m) = MAC(k2, m). Note that in general, not every MAC
function is key-robust. In particular, GMAC (which underlies GCM) function is key-robust. In particular, GMAC (which underlies GCM)
does not satisfy key-robustness, whereas HMAC with a collision- does not satisfy key-robustness, whereas HMAC with a collision-
resistant hash function does satisfy key-robustness. resistant hash function does satisfy key-robustness.
An application can choose to use a non-key-robust MAC within the AKE An application can choose to use a non-key-robust MAC within the AKE
portion of the protocol described in Section 6.4, but it MUST use a portion of the protocol described in Section 6.4, but it MUST use a
key-robust MAC for the creation of the auth_tag parameter in key-robust MAC for the creation of the auth_tag parameter in
Section 4.1.2. Section 4.1.2.
10.8. Input Validation 10.7. Input Validation
Both client and server MUST validate the other party's public key(s) Both client and server MUST validate the other party's public key(s)
used for the execution of OPAQUE. This includes the keys shared used for the execution of OPAQUE. This includes the keys shared
during the offline registration phase, as well as any keys shared during the registration phase, as well as any keys shared during the
during the online key agreement phase. The validation procedure online key agreement phase. The validation procedure varies
varies depending on the type of key. For example, for OPAQUE depending on the type of key. For example, for OPAQUE instantiations
instantiations using 3DH with P-256, P-384, or P-521 as the using 3DH with P-256, P-384, or P-521 as the underlying group,
underlying group, validation is as specified in Section 5.6.2.3.4 of validation is as specified in Section 5.6.2.3.4 of [keyagreement].
[keyagreement]. This includes checking that the coordinates are in This includes checking that the coordinates are in the correct range,
the correct range, that the point is on the curve, and that the point that the point is on the curve, and that the point is not the point
is not the point at infinity. Additionally, validation MUST ensure at infinity. Additionally, validation MUST ensure the Diffie-Hellman
the Diffie-Hellman shared secret is not the point at infinity. shared secret is not the point at infinity.
10.9. OPRF Key Stretching 10.8. OPRF Key Stretching
Applying a key stretching function to the output of the OPRF greatly Applying a key stretching function to the output of the OPRF greatly
increases the cost of an offline attack upon the compromise of the increases the cost of an offline attack upon the compromise of the
credential file at the server. Applications SHOULD select parameters credential file on the server. Applications SHOULD select parameters
for the KSF that balance cost and complexity across different client for the KSF that balance cost and complexity across different client
implementations and deployments. Note that in OPAQUE, the key implementations and deployments. Note that in OPAQUE, the key
stretching function is executed by the client, as opposed to the stretching function is executed by the client, as opposed to the
server in traditional password hashing scenarios. This means that server in traditional password hashing scenarios. This means that
applications must consider a tradeoff between the performance of the applications must consider a tradeoff between the performance of the
protocol on clients (specifically low-end devices) and protection protocol on clients (specifically low-end devices) and protection
against offline attacks after a server compromise. against offline attacks after a server compromise.
10.10. Client Enumeration 10.9. Client Enumeration
Client enumeration refers to attacks where the attacker tries to Client enumeration refers to attacks where the attacker tries to
learn whether a given user identity is registered with a server or learn whether a given user identity is registered with a server or
whether a re-registration or change of password was performed for whether a re-registration or change of password was performed for
that user. OPAQUE counters these attacks by requiring servers to act that user. OPAQUE counters these attacks by requiring servers to act
with unregistered client identities in a way that is with unregistered client identities in a way that is
indistinguishable from their behavior with existing registered indistinguishable from their behavior with existing registered
clients. Servers do this by simulating a fake CredentialResponse as clients. Servers do this by simulating a fake CredentialResponse as
specified in Section 6.3.2.2 for unregistered users, and also specified in Section 6.3.2.2 for unregistered users, and also
encrypting CredentialResponse using a masking key. In this way, real encrypting CredentialResponse using a masking key. In this way, real
skipping to change at page 51, line 43 skipping to change at page 51, line 28
leakage (e.g., timing attacks) from helping differentiate these leakage (e.g., timing attacks) from helping differentiate these
operations from a regular server response. Note that this may operations from a regular server response. Note that this may
introduce possible abuse vectors since the server's cost of introduce possible abuse vectors since the server's cost of
generating a CredentialResponse is less than that of the client's generating a CredentialResponse is less than that of the client's
cost of generating a CredentialRequest. Server implementations may cost of generating a CredentialRequest. Server implementations may
choose to forego the construction of a simulated credential response choose to forego the construction of a simulated credential response
message for an unregistered client if these client enumeration message for an unregistered client if these client enumeration
attacks can be mitigated through other application-specific means or attacks can be mitigated through other application-specific means or
are otherwise not applicable for their threat model. are otherwise not applicable for their threat model.
OPAQUE does not prevent against this type of attack during the OPAQUE does not prevent this type of attack during the registration
registration flow. Servers necessarily react differently during the flow. Servers necessarily react differently during the registration
registration flow between registered and unregistered clients. This flow between registered and unregistered clients. This allows an
allows an attacker to use the server's response during registration attacker to use the server's response during registration as an
as an oracle for whether a given client identity is registered. oracle for whether a given client identity is registered.
Applications should mitigate against this type of attack by rate Applications should mitigate against this type of attack by rate
limiting or otherwise restricting the registration flow. limiting or otherwise restricting the registration flow.
10.11. Protecting the Registration Masking Key 10.10. Protecting the Registration Masking Key
The user enumeration prevention method described in this document The user enumeration prevention method described in this document
uses a symmetric encryption key, masking_key, generated and sent to uses a symmetric encryption key, masking_key, generated and sent to
the server by the client during registration. This requires a the server by the client during registration. This requires a
confidential channel between client and server during registration, confidential channel between client and server during registration,
e.g., using TLS [RFC8446]. If the channel is only authenticated e.g., using TLS [RFC8446]. If the channel is only authenticated
(this is a requirement for correct identification of the parties), a (this is a requirement for correct identification of the parties), a
confidential channel can be established using public-key encryption, confidential channel can be established using public-key encryption,
e.g., with HPKE [RFC9180]. However, the details of this mechanism e.g., with HPKE [RFC9180]. However, the details of this mechanism
are out of scope of this document. are out of scope for this document.
10.12. Password Salt and Storage Implications 10.11. Password Salt and Storage Implications
In OPAQUE, the OPRF key acts as the secret salt value that ensures In OPAQUE, the OPRF key acts as the secret salt value that ensures
the infeasibility of pre-computation attacks. No extra salt value is the infeasibility of pre-computation attacks. No extra salt value is
needed. Also, clients never disclose their passwords to the server, needed. Also, clients never disclose their passwords to the server,
even during registration. Note that a corrupted server can run an even during registration. Note that a corrupted server can run an
exhaustive offline dictionary attack to validate guesses for the exhaustive offline dictionary attack to validate guesses for the
client's password; this is inevitable in any (single-server) aPAKE client's password; this is inevitable in any (single-server) aPAKE
protocol. It can be avoided in the case of OPAQUE by resorting to a protocol. It can be avoided in the case of OPAQUE by resorting to a
multi-server threshold OPRF implementation, e.g., [TOPPSS]. multi-server threshold OPRF implementation, e.g., [TOPPSS].
Furthermore, if the server does not sample the PRF seed with Furthermore, if the server does not sample the PRF seed with
sufficiently high entropy, or if it is not kept hidden from an sufficiently high entropy, or if it is not kept hidden from an
adversary, then any derivatives from the client's password may also adversary, then any derivatives from the client's password may also
be susceptible to an offline dictionary attack to recover the be susceptible to an offline dictionary attack to recover the
original password. original password.
Some applications may require learning the client's password for Some applications may require learning the client's password to
enforcing password rules. Doing so invalidates this important enforce password rules. Doing so invalidates this important security
security property of OPAQUE and is NOT RECOMMENDED, unless it is not property of OPAQUE and is NOT RECOMMENDED, unless it is not possible
possible for applications to move such checks to the client. Note for applications to move such checks to the client. Note that
that limited checks at the server are possible to implement, e.g., limited checks at the server are possible to implement, e.g.,
detecting repeated passwords upon re-registrations or password detecting repeated passwords upon re-registrations or password
change. change.
In general, passwords should be selected with sufficient entropy to In general, passwords should be selected with sufficient entropy to
avoid being susceptible to recovery through dictionary attacks, both avoid being susceptible to recovery through dictionary attacks, both
online and offline. online and offline.
10.13. AKE Private Key Storage 10.12. AKE Private Key Storage
Server implementations of OPAQUE do not need access to the raw AKE Server implementations of OPAQUE do not need access to the raw AKE
private key. They only require the ability to compute shared secrets private key. They only require the ability to compute shared secrets
as specified in Section 6.4.2. Thus, applications may store the as specified in Section 6.4.2. Thus, applications may store the
server AKE private key in a Hardware Security Module (HSM) or server AKE private key in a Hardware Security Module (HSM) or
similar. Upon compromise of the OPRF seed and client envelopes, this similar. Upon compromise of the OPRF seed and client envelopes, this
would prevent an attacker from using this data to mount a server would prevent an attacker from using this data to mount a server
spoofing attack. Supporting implementations need to consider spoofing attack. Supporting implementations need to consider
allowing separate AKE and OPRF algorithms in cases where the HSM is allowing separate AKE and OPRF algorithms in cases where the HSM is
incompatible with the OPRF algorithm. incompatible with the OPRF algorithm.
10.13. Client Authentication Using Credentials
For scenarios in which the client has access to private state that
can be persisted across registration and login, the client can back
up the randomized_password variable (as computed in Section 5.2.3) so
that upon a future login attempt, the client can authenticate to the
server using randomized_password instead of the original password.
This can be achieved by supplying an arbitrary password as input to
CreateCredentialRequest in the login phase, and then using
randomized_password from the backup in RecoverCredentials (invoked by
GenerateKE3) rather than computing it from the password.
This provides an advantage over the regular authentication flow for
login in that if randomized_password is compromised, an adversary
cannot use this value to successfully impersonate the server to the
client during login. The drawback is that it is only applicable to
settings where randomized_password can be treated as a credential
which can be stored securely after registration and retrieved upon
login.
11. IANA Considerations 11. IANA Considerations
This document makes no IANA requests. This document makes no IANA requests.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.irtf-cfrg-voprf]
Davidson, A., Faz-Hernandez, A., Sullivan, N., and C. A.
Wood, "Oblivious Pseudorandom Functions (OPRFs) using
Prime-Order Groups", Work in Progress, Internet-Draft,
draft-irtf-cfrg-voprf-21, 21 February 2023,
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
voprf-21>.
[OPRF] Davidson, A., Faz-Hernandez, A., Sullivan, N., and C. A.
Wood, "Oblivious Pseudorandom Functions (OPRFs) using
Prime-Order Groups", Work in Progress, Internet-Draft,
draft-irtf-cfrg-voprf-21, 21 February 2023,
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
voprf-21>.
[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,
<https://www.rfc-editor.org/rfc/rfc2104>. <https://www.rfc-editor.org/rfc/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/rfc/rfc4086>. <https://www.rfc-editor.org/rfc/rfc4086>.
[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/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9497] Davidson, A., Faz-Hernandez, A., Sullivan, N., and C. A.
Wood, "Oblivious Pseudorandom Functions (OPRFs) Using
Prime-Order Groups", RFC 9497, DOI 10.17487/RFC9497,
December 2023, <https://www.rfc-editor.org/rfc/rfc9497>.
12.2. Informative References 12.2. Informative References
[ARGON2] Biryukov, A., Dinu, D., Khovratovich, D., and S. [ARGON2] 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/rfc/rfc9106>. <https://www.rfc-editor.org/rfc/rfc9106>.
[AuCPace] Haase, B. and B. Labrique, "AuCPace: Efficient verifier- [AuCPace] Haase, B. and B. Labrique, "AuCPace: Efficient verifier-
based PAKE protocol tailored for the IIoT", based PAKE protocol tailored for the IIoT",
skipping to change at page 55, line 8 skipping to change at page 55, line 8
making password-based key exchange resilient to server making password-based key exchange resilient to server
compromise", CRYPTO , 2006. compromise", CRYPTO , 2006.
[HJKW23] Hesse, J., Jarecki, S., Krawczyk, H., and C. Wood, [HJKW23] Hesse, J., Jarecki, S., Krawczyk, H., and C. Wood,
"Password-Authenticated TLS via OPAQUE and Post-Handshake "Password-Authenticated TLS via OPAQUE and Post-Handshake
Authentication", EUROCRYPT , 2023. Authentication", EUROCRYPT , 2023.
[HMQV] Krawczyk, H., "HMQV: A high-performance secure Diffie- [HMQV] Krawczyk, H., "HMQV: A high-performance secure Diffie-
Hellman protocol", CRYPTO , 2005. Hellman protocol", CRYPTO , 2005.
[I-D.irtf-cfrg-hash-to-curve]
Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R. S.,
and C. A. Wood, "Hashing to Elliptic Curves", Work in
Progress, Internet-Draft, draft-irtf-cfrg-hash-to-curve-
16, 15 June 2022, <https://datatracker.ietf.org/doc/html/
draft-irtf-cfrg-hash-to-curve-16>.
[I-D.krawczyk-cfrg-opaque-03] [I-D.krawczyk-cfrg-opaque-03]
"The OPAQUE Asymmetric PAKE Protocol", n.d., "The OPAQUE Asymmetric PAKE Protocol", n.d.,
<https://datatracker.ietf.org/doc/html/draft-krawczyk- <https://datatracker.ietf.org/doc/html/draft-krawczyk-
cfrg-opaque-03>. cfrg-opaque-03>.
[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)",
IEEE European Symposium on Security and Privacy , 2016. IEEE European Symposium on Security and Privacy , 2016.
skipping to change at page 56, line 10 skipping to change at page 55, line 48
[PAKE-Selection] [PAKE-Selection]
"CFRG PAKE selection process repository", n.d., "CFRG PAKE selection process repository", n.d.,
<https://github.com/cfrg/pake-selection>. <https://github.com/cfrg/pake-selection>.
[PBKDF2] Kaliski, B., "PKCS #5: Password-Based Cryptography [PBKDF2] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, Specification Version 2.0", RFC 2898,
DOI 10.17487/RFC2898, September 2000, DOI 10.17487/RFC2898, September 2000,
<https://www.rfc-editor.org/rfc/rfc2898>. <https://www.rfc-editor.org/rfc/rfc2898>.
[RFC2945] Wu, T., "The SRP Authentication and Key Exchange System",
RFC 2945, DOI 10.17487/RFC2945, September 2000,
<https://www.rfc-editor.org/rfc/rfc2945>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/rfc/rfc5869>. <https://www.rfc-editor.org/rfc/rfc5869>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2", "PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016, RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/rfc/rfc8017>. <https://www.rfc-editor.org/rfc/rfc8017>.
skipping to change at page 56, line 36 skipping to change at page 56, line 22
April 2017, <https://www.rfc-editor.org/rfc/rfc8125>. April 2017, <https://www.rfc-editor.org/rfc/rfc8125>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>. <https://www.rfc-editor.org/rfc/rfc8446>.
[RFC9180] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid [RFC9180] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180, Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,
February 2022, <https://www.rfc-editor.org/rfc/rfc9180>. February 2022, <https://www.rfc-editor.org/rfc/rfc9180>.
[RFC9380] Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R. S.,
and C. A. Wood, "Hashing to Elliptic Curves", RFC 9380,
DOI 10.17487/RFC9380, August 2023,
<https://www.rfc-editor.org/rfc/rfc9380>.
[RISTRETTO] [RISTRETTO]
de Valence, H., Grigg, J., Hamburg, M., Lovecruft, I., de Valence, H., Grigg, J., Hamburg, M., Lovecruft, I.,
Tankersley, G., and F. Valsorda, "The ristretto255 and Tankersley, G., and F. Valsorda, "The ristretto255 and
decaf448 Groups", Work in Progress, Internet-Draft, draft- decaf448 Groups", Work in Progress, Internet-Draft, draft-
irtf-cfrg-ristretto255-decaf448-08, 5 September 2023, irtf-cfrg-ristretto255-decaf448-08, 5 September 2023,
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg- <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
ristretto255-decaf448-08>. ristretto255-decaf448-08>.
[SCRYPT] Percival, C. and S. Josefsson, "The scrypt Password-Based [SCRYPT] Percival, C. and S. Josefsson, "The scrypt Password-Based
Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914, Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914,
skipping to change at page 57, line 29 skipping to change at page 57, line 20
WhatsApp, "Security of End-to-End Encrypted Backups", WhatsApp, "Security of End-to-End Encrypted Backups",
n.d., <https://www.whatsapp.com/security/ n.d., <https://www.whatsapp.com/security/
WhatsApp_Security_Encrypted_Backups_Whitepaper.pdf>. WhatsApp_Security_Encrypted_Backups_Whitepaper.pdf>.
Appendix A. Acknowledgments Appendix A. Acknowledgments
We are indebted to the OPAQUE reviewers during CFRG's aPAKE selection We are indebted to the OPAQUE reviewers during CFRG's aPAKE selection
process, particularly Julia Hesse and Bjorn Tackmann. This draft has process, particularly Julia Hesse and Bjorn Tackmann. This draft has
benefited from comments by multiple people. Special thanks to benefited from comments by multiple people. Special thanks to
Richard Barnes, Dan Brown, Matt Campagna, Eric Crockett, Paul Grubbs, Richard Barnes, Dan Brown, Matt Campagna, Eric Crockett, Paul Grubbs,
Fredrik Kuivinen, Payman Mohassel, Jason Resch, Greg Rubin, and Nick Fredrik Kuivinen, Stefan Marsiske, Payman Mohassel, Marta Mularczyk,
Sullivan. Hugo Krawczyk wishes to thank his OPAQUE co-authors Stas Jason Resch, Greg Rubin, and Nick Sullivan. Hugo Krawczyk wishes to
Jarecki and Jiayu Xu without whom this work would have not been thank his OPAQUE co-authors Stas Jarecki and Jiayu Xu without whom
possible. this work would have not been possible.
Appendix B. Alternate Key Recovery Mechanisms Appendix B. Alternate Key Recovery Mechanisms
Client authentication material can be stored and retrieved using Client authentication material can be stored and retrieved using
different key recovery mechanisms. Any key recovery mechanism that different key recovery mechanisms. Any key recovery mechanism that
encrypts data in the envelope MUST use an authenticated encryption encrypts data in the envelope MUST use an authenticated encryption
scheme with random key-robustness (or key-committing). Deviating scheme with random key-robustness (or key-committing). Deviating
from the key-robustness requirement may open the protocol to attacks, from the key-robustness requirement may open the protocol to attacks,
e.g., [LGR20]. This specification enforces this property by using a e.g., [LGR20]. This specification enforces this property by using a
MAC over the envelope contents. MAC over the envelope contents.
skipping to change at page 58, line 31 skipping to change at page 58, line 18
derived from it) with a quantum-safe encryption function. However, derived from it) with a quantum-safe encryption function. However,
the only effect of a break of the OPRF by a future quantum attacker the only effect of a break of the OPRF by a future quantum attacker
would be the ability of this attacker to run at that time an would be the ability of this attacker to run at that time an
exhaustive dictionary attack against the old user's password and only exhaustive dictionary attack against the old user's password and only
for users whose envelopes were harvested while in use (in the case of for users whose envelopes were harvested while in use (in the case of
OPAQUE run over a TLS channel with the server, harvesting such OPAQUE run over a TLS channel with the server, harvesting such
envelopes requires targeted active attacks). envelopes requires targeted active attacks).
C.1. HMQV Instantiation Sketch C.1. HMQV Instantiation Sketch
An HMQV instantiation would work similar to OPAQUE-3DH, differing An HMQV instantiation would work similarly to OPAQUE-3DH, differing
primarily in the key schedule [HMQV]. First, the key schedule primarily in the key schedule [HMQV]. First, the key schedule
preamble value would use a different constant prefix -- "HMQV" preamble value would use a different constant prefix -- "HMQV"
instead of "3DH" -- as shown below. instead of "3DH" -- as shown below.
preamble = concat("HMQV", preamble = concat("HMQV",
I2OSP(len(client_identity), 2), client_identity, I2OSP(len(client_identity), 2), client_identity,
KE1, KE1,
I2OSP(len(server_identity), 2), server_identity, I2OSP(len(server_identity), 2), server_identity,
KE2.credential_response, KE2.credential_response,
KE2.auth_response.server_nonce, KE2.auth_response.server_nonce,
skipping to change at page 59, line 25 skipping to change at page 59, line 13
Likewise, s would be computed as follows: Likewise, s would be computed as follows:
hashInput = concat(I2OSP(len(epkS), 2), epkS, hashInput = concat(I2OSP(len(epkS), 2), epkS,
I2OSP(len(info), 2), info, I2OSP(len(info), 2), info,
I2OSP(len("server"), 2), "server") I2OSP(len("server"), 2), "server")
s = Hash(hashInput) mod L s = Hash(hashInput) mod L
Hash is the same hash function used in the main OPAQUE protocol for Hash is the same hash function used in the main OPAQUE protocol for
key derivation. Its output length (in bits) must be at least L. key derivation. Its output length (in bits) must be at least L.
Both parties should perform validation (as in Section 10.8) on each Both parties should perform validation (as in Section 10.7) on each
other's public keys before computing the above parameters. other's public keys before computing the above parameters.
C.2. SIGMA-I Instantiation Sketch C.2. SIGMA-I Instantiation Sketch
A [SIGMA-I] instantiation differs more drastically from OPAQUE-3DH A [SIGMA-I] instantiation differs more drastically from OPAQUE-3DH
since authentication uses digital signatures instead of Diffie- since authentication uses digital signatures instead of Diffie-
Hellman. In particular, both KE2 and KE3 would carry a digital Hellman. In particular, both KE2 and KE3 would carry a digital
signature, computed using the server and client private keys signature, computed using the server and client private keys
established during registration, respectively, as well as a MAC, established during registration, respectively, as well as a MAC,
where the MAC is computed as in OPAQUE-3DH. where the MAC is computed as in OPAQUE-3DH.
skipping to change at page 60, line 13 skipping to change at page 60, line 8
computed during the authentication of an unknown or unregistered computed during the authentication of an unknown or unregistered
user. Note that masking_key, client_private_key, and user. Note that masking_key, client_private_key, and
client_public_key are used as additional inputs as described in client_public_key are used as additional inputs as described in
Section 6.3.2.2. client_public_key is used as the fake record's Section 6.3.2.2. client_public_key is used as the fake record's
public key, and masking_key for the fake record's masking key public key, and masking_key for the fake record's masking key
parameter. parameter.
All values are encoded in hexadecimal strings. The configuration All values are encoded in hexadecimal strings. The configuration
information includes the (OPRF, Hash, KSF, KDF, MAC, Group, Context) information includes the (OPRF, Hash, KSF, KDF, MAC, Group, Context)
tuple, where the Group matches that which is used in the OPRF. These tuple, where the Group matches that which is used in the OPRF. These
test vectors were generated using draft-21 of [OPRF]. The KSF used test vectors were generated using [RFC9497]. The KSF used for each
for each test vector is the identity function (denoted Identity), test vector is the identity function (denoted Identity), which
which returns as output the input message supplied to the function returns as output the input message supplied to the function without
without any modification, i.e., msg = Stretch(msg). any modification, i.e., msg = Stretch(msg).
D.1. Real Test Vectors D.1. Real Test Vectors
D.1.1. OPAQUE-3DH Real Test Vector 1 D.1.1. OPAQUE-3DH Real Test Vector 1
D.1.1.1. Configuration D.1.1.1. Configuration
OPRF: ristretto255-SHA512 OPRF: ristretto255-SHA512
Hash: SHA512 Hash: SHA512
KSF: Identity KSF: Identity
 End of changes. 75 change blocks. 
190 lines changed or deleted 169 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/